SANNDRA - Synchronous Artificial Neuronal Network Distributed Runtime Algorithm

1.2.0

Historical Remarks and Introduction

SANNDRA was born when MasPar MP1 that I was using for my Master's thesis rested in peace few months before my defense. I needed to port my code on Linux with minimal changes, so I started to write SANNDRA as a partial SIMD emulation. It was (and still is) intended to run a long iterative loop through relatively simple computation done in parallel on many similar elements. It went far beyond SIMD in the sense that now the computations done on different elements should not be anywhere near similarity, but they are still perfectly synchronized for the data exchange. On a sequential computer this leads to an unavoidable performance loss due to synchronization of elements, but ensures that these elements get correct input signals.

Each element can have an access to the output of any other element. This design makes SANNDRA capable of numerical integration of large systems of non-homogeneous differential equations, although it can be put to much simpler use like iterative solving systems of algebraic equations or image processing, when each element represents a pixel. The possible wide range of use keeps SANNDRA as a separately distributed library, while main use and testing of it is done in the KInNeSS (KDE Integrated NeuroSimulation Software) project. This results in class naming that has neural flavor in it. Since most of these classes are implementing one or the other mathematical formula, they obviously can be used in non-neural systems.

Key Design Features

SANNDRA extensively uses polymorphism to achieve the combination of flexibility and performance. The system of equations is combined together from pieces provided by the user code. A set of standard building blocks is provided by the library, and user can always derive the additional blocks from those that are provided. Once combined, the system can be solved independently of what its actual structure is. There is a slight computational overhead in polymorphism, since a direct function call is a bit faster than a virtual call. For a homogeneous system, when the function for such direct call can be determined at compillation time, using polymorphism would be disadvantageous. Since in SANNDRA we cannot determine the appropriate direct call during compillation, the choice is between polymorphism and some other kind of run-time detection of the right method to call. In this case polymorphism clearly is the best choice.

How to use SANNDRA

To use SANNDRA, the application should create an TSim object either directly or through inheritance. This is the main simulator that controls the solution process. The application should also create at least one population (TLayer). Populations handle the output of the computational elements, both when they need to exchange the data and when they need to output it to disk. User implementation of TLayer derivative can add screen output. It is not required, but highly recommended to create separate populations for subsets of elements that use the same equation and keep these populations homogeneous.

After the populations are created, create computational elements (TUnit). You need to provide TUnit with the equation for it (TEquation). Since TEquation is just a formula that does not contain element-specific data, you can share single TEquation object between multiple elements (but see the note on SMP and thread safety in TUnit::TUnit()). After the element is created, you should add it to the simulation controller by calling TSim::addUnit(). Either during the creation (if you inherit from TUnit) or after it you should add the dependencies between elements using TUnit::addDependency() methods.

The example order to create the population of neuronal compartments can be:

All three of those are independent, so the order between them does not matter. Then,


Generated on Sat Mar 5 14:56:42 2005 for SANNDRA by doxygen 1.3.8