The general philosophy of running a simulation is to configure the system of neurons, then observe their behavior for some time. To configure the system, however, is a complex task. The biological neurons are rather irregular (from the viewpoint of mathematics), so the simplest approach is taken: a set of (interdependent) configuration files (and subfile hierarchy) is used. When starting a simulation, the config files are read as described in section Settings. This chapter tells which configuration files are present and what it their expected contents.
As part of configuration, a list of ".ini" files is provided. Acually, the simulator uses two files: Simulator.ini and Neurons.ini.
The simulator internally works either with simple sequence number or ClusterAddress_t identifiers (say, in form of "Example.Proc.GP_XX", where "GP" means scGridPoint, and XX is is simple sequence number), which are not comfortable for working with neuronal simulations. Because of this, alias names can be defined. The file 'Neurons.ini' contains lines of form
NewName=OldName
That is, the user can define some alias that has for it some reasonable meaning, and it is mapped by the simulator to some internally used one. For example,
Neuron1=scExample.Proc.GP_07 Neuron2= Neuron3=Neuron1
define that out system comprises altogether two neurons. The simulator internally works with names such as "scExample.Proc.GP_07", which is essentially a simple sequence number (a unique ID), generated by the simulator. The first line means that the user wants to use a neuron with name "Neuron1", and that he wants to the neuron having ID 7.
The second line means that the user want to use a neuron with name "Neuron2", and does not care which sequence number the neuron has. The simulator will choose one of the still available ones.
The third line means that for some reason (say, in some configuration files the same neuron has another name) the user wants to introduce one more name for the same neuron. Both (or more) alias names will refer to the same physical neuron.
Take care, however, with those names. The simulator not necessarily executes the lines in the same sequence as you wrote the assignements. It may happen that the second line is executed first, and it may happen that the simulator maps "Neuron2" to the physical neuron "scExample.Proc.GP_07". After that, when the first line is executed, and you definitely named that you want to map "Neuron1" to ""scExample.Proc.GP_07", both "Neuron1" and "Neuron2" will refer to the same physical neuron. Even, because of the third line, the third neuron will refer to the same neuron. The best practice is to use either the explicite mapping, or implicite mapping, but not both. The simulator gives warnings, and it is the user's responsibility to decide if the noticed issue matters or not.
This file is a source of other ".ini" files. The entries found in the 'Neurons.ini' file mean that the simulator will look for settings file for those entries, i.e., a file with name "Neuron1.ini", where it looks for settings related to neuron aliased as "Neuron1'. Again, the simulator accesses those files in some arbitrary order, and sets the neuron's parameters both from file "Neuron1.ini' and "Neuron3.ini". It is the user's responsibility again, to provide (or not provide) the needed files.
Take also care that the ".ini" files have platform-independent contents and some systems do not distinguish lower/upper case letters. Because of this feature, on a different platform differently spelled ".ini" files shall be not found or duplicated.
The neurons may belong to one (or more) assemblies. One can define the possible assemblies in file "Assemblies.ini". This is a simple list, containg entries such as
Alias1 Alias2
The possible assemblies are simple lists of neurons. A neuron cand be member of several assemblies.
In the neuron initialization files different keyword/value pairs can be listed.
The neurons can be connected to partner neurons, and their connection parameters are listed in the ".ini" file of representing the neuron. For example, the "Neuron1.ini" file has the content
Works=3 [Neuron2] ConnectTime=100 [Neuron3] ConnectTime=90 [Group] Assembly1 Assembly2
Here, the words in square brackets "[]" represent groups of settings. In the example above, one keyword-value pair "Works=3" and three "child goups" are listed. They are describing the neuron as a single entity, such as threshold, mode, frequence, etc. for the detailed list of possible values see section Parameters.
The connection of the neurons can be described formally as a group, that is "[Neuron2]" means that the neuron "Neuron1" is connected to Neuron2, with the parameters listed in that group. Of course, only groups having name listed in "Neurons.ini" files are legal. See also section Connections.
In the example file above, "Neuron1" is connected to "Neuron2" and "Neuron3" (which, in this example, is mapped to "Neuron1") In this way a one-way connection can be created from "Neuron1" to "Neuron2". Our "Neuron1" can send messages to "Neuron2". To send Messages in the opposite direction, file "Neuron2.ini" must contain lines such as
[Neuron1] ConnectTime=100
A neuron can belong to multiple groups This feature can be used differently in different fields. For example, biological neurons can belong to different assemblies (maybe to more than one). Technical neurons can belong to various layers, with various connections. Because of this, using grouping depends on the user, it is not constrained at all.
The "file"NeuronX.ini" file can contain entries such as
[Group] Assembly1 Assembly2
that makes the neuron member of the listed assemblies, that is, it can be directed also by "collective" instructions. To belong to a group means that group-related operations are executed by all members of the assembly.
In all files (except "Neurons.ini") the key-value pairs without a group (at the top of the file) change some feature of the object (simulator or neuron). The feature has some default parameter (provided compile time), and it is overwritten by the value provided; maybe several times as decribed in section The "Hello World" of settings. Parameters related to neuron 'NeuronX' can be present, such as
Potential=65.4 Threshold=50
These settings replace the corresponding operating parameters of the neuron, provided that the keyword found, the value is of proper format and is in the allowed range.
Neural connection can be described simply by listing the partner neuron in the file of the sender neuron.
Parameter "ConnectTime" provides the time distance of the two partners. When needed, the neuron in question will send the timed message immediately, and the receiver neuron puts the message in a simlated time-ordered queue, and will delay its processing as the message requested. The time is of crucial importance in simulating both biological and technical neurons. This method of handling enables biological neurons to fire really "at the same time", and technical neurons can imitate different technical connection parameters.
Parameter "ConnectWeight" sets in the partner "Neuron2" to that value. The value is saturated at [-1024,1023]. It means that the neuron multiplies the received input by this weight
Parameter "ConnectStrength" is set in "Neuron1", for this connection. The value is saturated at [-1024,1023]. It is usually not changed during simulation, but it can be used to simulate special effects; such as aging).
The neurons communicate via using point-to-point, timed messages (scIGP_Message). The timing prescribes the expected arrival time
For biological neurons, the spikes are represented as timed messages, sent from a neuer to a neurer. The receiving neurer puts the message in its timed message queue, and will process the message exactly at the requested time.
For technical neurons, the messages are interpreted as a change in the corresponding level, and the time information can be used to describe time delay stemming out from the technical implementation of the network.
1.8.17 
