The general philosophy of running a simulation is to configure the system specifically for your modules connected in the way you liked, then observe their behavior for some time. To configure the system, however, is a complex task. The subsystems and modules 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 The list of settings files.
The simplest way to comprehend how the system of settings works, is to consider the operation of a graphic windowing system, say the main window of the simulator. The main window has – among others – size and position. They can be described by parameters "size" and "pos", respectively. They both can be described in form "(x,y)" value pairs. The config files can contain lines, such as
MainWindow/size=(1200,800)
It is assumed, that that the simulator has a hierarchy of users. The boss (or the institute) may prefer values such as
MainWindow/size=(2400,1600)
The user, in general, may use setting such as
MainWindow/size=(1000,600)
but in some (say demo) project he wants to use
MainWindow/size=(1500,900)
The simulator, by default, sets the size (according to)
MainWindow/size=(1024,700)
The program has an application-wide configuration file, see section Work settings, say
InstallDir/.config/TACsimV0.0/Simulator.ini
The simulator initially sets its window size to (1024,700), and with that, the system is ready to operate. However, the application checks if that application-wide configuration file is present. If yes, and it contains the mentioned configuration line, the application sets the window size to (2400,1600).
After that, it checks if in the work directory, say in
~/TACsimV0.0/Simulator.ini
if the user has that file and the corresponding config line (he has no such high-resolution monitor) and if so, the sets the window size to (1000,600).
The user, may however make some project, where resolution (1500,900) is preferred. So, if the user starts the application from Anypath (the project path), and file
AnyPath/Simulator.ini
exists, with the 'MainWindow' config line, the simulator will start with main window size (1500,900).
If any of the mentioned config files are missing, the setup procedure skips overwriting that value. If all files are absent, the main window comes up with size (1024,700), with no offset time at all.
When the user exits from the simulation, the program can save that value, in the same form, but only in the project file. That is, a user cannot overwrite neither organization's setting nor his own user's default setting. If after exiting, he runs the simulator again from the same project file, the output 'Simulator.ini' of the previous run will be used and input project settings, i.e., the program will continue with the setting he used when he exited previously. However, if he runs the simulator from a different project subdirectory in the meantime, that project will start up with settings found in that subdirectory, and will overwrite that configuration. This project, next time, will start with the last settings, stored in this subdirectory.
It is worth to make a saved copy of the settings file(s), before starting a simulation. If the simulator makes some strange move, it will save those wrong settings values, and your previous settings are lost. Also, you may copy (partly or entirely) the '.ini' files or edit the files, line by line. Take care, however: a typing mistake may result in loosing that config line.
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. Actually, the simulator uses different number of files, with different names. Usually, at least file Simulator.ini is in use. For details see the settings files section in your the package you use.
The simulator internally works either
Neither of them is very user-friendly (maybe except electronic engineers). The sequence numbers result in name asuch as "2/1" (meaning the 1st thread of second module, or, for the same scHThread, "{0,4}=(7.N:N)/1", meaning then it has position coordinates x=0, y=4.
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.
1.8.17 
