General Considerations

Network Creation

MIIND is designed to simulate circuits of neural populations, and provides tools to analyse the simulation results. Simulations can be described in C++ and XML and a Python interface is foreseen. Here, we describe the workflow in a platform independent way. Below, we will describe the design specifications for each platform.

The concept of a network is central to MIIND. From the user perspective a network is a directed graph, where we associated each vertex with a Node and each edge with a Connection. The type of Connection must be stated for a simulation, and its definition is the first step in any workflow. A Connection Type can be a single floating point number, or something more complex, like a tuple of floating points. Each Node is associated with an Algorithm; each edge is associated with a Connection.

After the specification of the connection type, the network is built. This happens in several steps, described here. In the MIIND workflow Algorithm instances are selected first. Each Algorithm instance has a type; its type determines its state and the algorithm used to evolve that state. An Algorithm has an AlgorithmParameter. Two Algorithm instances can be of the same type, but can differ in their AlgorithmParameters. For example, a WilsonCowanAlgorithm is of a different type than a GeomAlgorithm; two GeomAlgorithm instances may or may not have different GeomParameters. AlgorithmParameters can be named, and if they are named they can be shared by different Algorithm Instances. If they are not named, they are an implicit part of the Algorithm definition, and cannot be shared.

Each Algorithm instance has a Name (an algorithm name), that is unique within the simulation. A Node has a unique identifier: an non-negative integer number, reflecting the order in which they were created. A Node can have a Name (a node name) that must be unique within the simulation: no other node may have that name. A Node is associated with one and only one Algorithm Instance; different Nodes may be associated with the same Algorithm Instance. An Algorithm can have system parameter, which selects a particular implementation of an Algorithm, when mutiple implementations are available. It can also have a version, when multiple versions of an implementation are provided.

Connections are used to pass NodeStates, a single floating point number, from one Node to another. a Node can be connected to many other Nodes via Connections. A Node can ask its Algorithm to interpret its input and all Algorithms in the network must be compatible with the type of Connection. The simulation user is responsible for selecting the Connection type and for selection Algorithm types that are consistent with the Connection type.

Node instances are created in order and are numbered uniquely in order of creation. Upon creation, a Node must be associated with an Algorithm instance. After all nodes have been created, nodes are connected: for a Connection, the input and output node are specified and also a tuple of floating points representing its value. Upon completion of the connections, the network is considered to be complete.

Some workflows will require an explicit instantiation of a Network instance -e.g. in C++ it must be instantiated, but it is not required by this specification as all Nodes within one simulation are required to refer to the same network, and the collection of all nodes and connections determine the network.

Simulation Running

A Simulation is specified by a SimulationParameter, which species

a floating point begin_time.
a floating point end_time.
a string base_name: this is the name that will be used for the log file, which will be '<basename>.log' and the simulation results.
a floating point step_time, specifying the basic time step of the simulation; this parameter requires special consideration and may phased out (see the discussion in The network time step).
a boolean onscreen determines whether online visualization should be used (default: false). This is a hint, in some workflows online visualization may not make sense; consult concrete workflows.
a state object, describing whether which densities should be written out when (see below)
a floating point report_time, when the simulation time exceeds a multiple of report time firing rates, and where appropriate densities are written into the simulation file.

The state object contains the following variables:

a boolean withstate determines whether densities should be written out or not (default: false)
a list of node names, or node ids, that specifies the densities of which nodeswill be written out (default: all)
a time interval during which densities will be written out (default all)

The network time step

It is clear that the network simulation as a whole must proceed in a fixed time step. Geometric binning algorithms are created with a certain time step as parameter. For now, we will require that all Algorithms are able to report this parameter, and that the network checks whether all Algorithms use the same time step. If this procedure is acceptable, there is no need for a network time step parameter as user will be reminded to use consistent meshes. In future use, the following consideration is possible: meshes take considerable effort to generate, and if the time steps are mutiple of each other, a slighly more complex simulation loop might be in order. In that case a network time step parameter makes sense, as it allows the network to make checks about the sensibility of different time steps provided by each simulation. Hence, it will not be phased out for now.

So the following erquirements will be enforced: Algorithms will report their time step;the network will enforce that all algorithms use the same time step and that this is the network time step; the workflow will flag a user attempt to set a different network step time as an error, and will not perform simulation.

Simulation Results

The simulation log and a firing rates results file will be produced in the same directory where the executable is run. The firing rates are stored in one results file. The file can be organised per node, with a graph for each node, where the graph is labeled by the node name provided by the user; if the user didn't provide on by the node's creation id. Alternatively, the file can be organised in time slices with a firing rate given for each node, for each time slice, again labeled by node name if the user provided one.

Density results for one dimensional populations can be written into the same file as the firing rates. Densities must be labeled by node and time slice. Due to the large amount of information present in two dimensional densities, it is necessary to write each density in its own file. We require that densities be written to a separate directory and that within that directory density files are labeled by node (name or id when name not provided and time slice.

Design of the XML Workflow

The XML workflow is a concrete instantiation of the design descibed in the last section.

A simulation is delimited by a "<Simulation> ... </Simulation>" tags.
The type of a Connection is specified by a WeightType definition, e.g. "<WeightType>DelayedConnection</WeightType>".
The XML specification of Algorithms and AlgorithmParameters matches the C++ class definitions one-on-one, i.e. the XML syntax for the following definition of a NeuronParameter:
```
  <NeuronParameter>
  <t_membrane>50e-3</t_membrane>
  <t_refractive>0</t_refractive>
  <V_threshold>1.0</V_threshold>
  <V_reset>0</V_reset>
  <V_reversal>0</V_reversal>
  </NeuronParameter>  
```
can directly be inferred from the C++ interface from GeomLib::NeuronParameter. So any algorithm can be constructed from Available Algorithms in MIIND which links through to the relevant C++ definitions.