This page only tells general aspects. To find out how to apply it to one of the packets, please see the corresponding chapter in the selected packet.
It is always a crucial point when using a new system (such as this simulator) to start as quickly as possible. Simulating something that drastically differs from the objects of computing, was never simple, and persisted to be a hard case also with this simulator. Biological systems 'live', they change their features in time, and a true model must be able to implement that feature: neurons are not processors and neuronal networks and not computer networks.
For neuronal simulation, a special method was developed, based on a technology, that is primarily used in the electronic design industry. It separates the operating time (when the action in reality happens) from the computing time (how much computing time is needed to compute the corresponding states). In this way, the simulated process may run in the many-years range (say a geology model) or in the femtoseconds range (atomic processes); the computing will all the time reflect the correct (virtual) time of the simulated process, independently from that the computing takes microseconds or days.
The kernel of the application is essentially an electronic design (a specific ASIC chip can be built upon it), so it has its own rules. For neuronal researchers, this feature should be hidden, and this package makes its best to do that. Simulating a SystemC design, however, was never simple, so it is really worth to read this basic introductory information.
It is, in general, a good practice to use the concept of "project subdirectory", i.e. to keep all the files related to a simulation in a separate subdirectory. The concept of The work directory serves this goal: you can put all your files, your notes, pictures, etc. in the The work directory subdirectory, and generate the results in The output directory subdirectory.
The best policy is to create a new subdirectory for a new project (simulation session), and start the simulator from that directory. The program will create data and output directories as described in section The work directory. After that you may copy your files needed for the simulation in the data subdirectory. Of course you can create the data subdirectory in advance, and in that case the program will use that directory as data directory. You may also want to write your per project settings to the corresponding subdirectory, see section How to configure ScQtSimNeurer through its settings files.
Please notice that data is different from settings. Basically, your simulation will only use settings as described in How to configure TAC simulators through its settings files, but – depending on your actual simulation – the application may need data from those subdirectories. For your efficiency it is important to comprehend the conventions used in connection with settings. Failing to do so, may produce disappointing results and mis-evaluating the simulator.
The results will be written in the output subdirectory. The log file (see section The log directory) goes in the temporary directory.
The program sets up, utilizes and changes dynamically numerous settings, both relating to the apperance of the program and its operation (i.e. the behavior of your simulation). Normally, users expect to provide the facility, that when entering the application next time, it will continue where at the previous time the user exited. This goal is reached through using 'QSettings', This operation is transparent for the user.
The settings are well-defined and grouped key-value pairs, which can be made persistent between evaluation sessions. When the user exits the tool, the actual settings are saved in a file in the project directory and next time they are loaded again. This means that the user may continue the next session exactly with the same settings that were used in the past session, furthermore that in the meantime, can run another project with different settings. The detailed operation is described in scqSimulator::readSettings. The system of settings files is decribed in chapter How to configure TAC simulators through its settings files.
Please notice that the subdirectory name contains also the version number of the application, i.e. you can use different settings for different program versions. And of course, you are free to copy manually the settings to a properly named file when you start with a new version. These files are different per user and per program version.
You may want to work with several projects, each having their own settings, so a project-wide settings may also be necessary. There is a way to make your settings persistent. Altogether, four actions may change the settings. First, there are settings used when configuring, compiling and/or starting the program, these are the default values. Second, if the program finds the application-wide settings files, it reads them and sets the corresponding values, actually overwriting the default values. Third, if the user-wide settings files exists, the program reads the settings and sets the corresponding values (actually overwrites the application-wide settings). Fourth, if the project-wide settings file exists, the program reads the settings and sets the corresponding values (actually overwrites the user-wide settings). Finally, during utilization, (in interactive mode) the user can change many of the settings, actually overwiting any former value.
When exiting the program, the recent settings are saved in the project-wide settings file (only there, the rests remain unchanged). When starting the application next time, those project-wide settings will be loaded as the last of the chain. Because of this, you should keep a reserve copy of the project-wide settings: it is used by the program both as input and output.
The user may save this project-wide settings file (or parts of it), by simply copying that contents into the corresponding higher-level directory. The settings file can be edited. Take care, however, to not change the syntax. If reading the key-value pair fails, the default value will be used.
This handling enables safe team work: the user (with proper systems-level protection) can set any settings, can have his default settings and experimental settings, while cannot destroy the group's or institution's settings.
It is part of the configuration to provide a definition of a string such as
#define INI_FILES "MainWindow Aliases Connections"
where the words inside quitations are interpreted as a list of ".ini" files, i.e. the simulator expects those files, and reads their contents as decribed in section How to configure TAC simulators through its settings files.
The end-user distribution kit comprises different components, the most important ones are the executable files.
The simulator itself, comes in two versions. The graphic interface of course works in an interactive way and shows enough information for the user to 'see' how the internal parts of NEURER work. The command-line interface produces only textual screen output and is not interactive.
The third component is essential only for developers. The testing interface is mainly for the developer, but you may run it if you suspect some operating detail. Of course, first the tests must be extended with the test case you want.
The simulators and test programs use logging facilities extensively, so studying and documenting their behavior is easy. The logging feature (based on Qt5 logging system) means that the applications write information about the important actions and events as discribed in The log directory, with all relevant data and a time stamp. The system mirrors those notes on the screen and partly in the status line, too.
Since both the ideas and their implementation are quite unusual, the fourth component provides a kind of tutorial. Some example object and source code files, you can start with, are also delivered with the system (see section The examples directory). Their detailed operation is explained in this document. The best way to utilize them is to execute the object codes in the simulator, and read the explanations from the guide.
The executable is located in the 'bin/' subdirectory, so it can be started with the command
<b>/<InstallDir>/<simulator>_GUI</b>
The Qt5 toolkit [3] is used to provide an attractive GUI for the simulator. I comprises different views, tabs, etc
The executable is located in the 'bin/' subdirectory, so it can be started with the command
<b>/<InstallDir>/<simulator>_CLI</b>
The only interactivity is starting the program, so it starts with the settings as described in section How to configure TAC simulators through its settings files After that, the simulation runs to completion, and produces a log file in the subdirectory, where the executable was invoked from, as describen in section Logging the simulation activity.
Components of the system undergo serious systematic testing. It is mainly interesting for the developers. Depending on the operation mode, selected during compilation, different components and different actions are tested. Unit testing program executes a lot of internal functionality tests as well as built-in "object files", and results of testing are written to both the screen and a log file.
The executable is located in the 'bin/' subdirectory, so it can be started with the command
<b>/<InstallDir>/<simulator>_TEST</b>
In response, the application prints a summary of the tests executed, including the number of the test and test cases, and whether all of them run successfully.
The simulator records your actions, parameters, their sequence, and other information in a file "PROJECT_NAME_PROJECT_VERSION_date_time.log" file in temporary directory Temporary directory. The file contains different messages, of which you shall consider the information messages, and maybe warnings and errors.
If everything goes OK, you do not need that file at all. However, if you are in doubt what operations you executed already, which order of operations you used or actually which parameters used at an operation, you are free to use that file. If you suspect an error in the operation of the tool, just send the log file to the maintainer. It is also a good idea to consult the file where the different files and directories are actually located.
Notice that the contents of the log file is duplicated in the log window (both in the GUI and CLI version), so you can notice issues immediately, but there is no need to bother with copying or saving some details of tha log info.
The best way of getting familiar with the ways how the simulator van be used, is to work through the examples. The examples are available through the 'File' menu (GUI version) or can be provided as the first argument provided for the program (both CLI and GUI versions).
1.8.17 
