JanVogelsang
commented
1 year ago There is a maximum number of synapse types allowed per simulation, which can be modified by setting the HPC or non-HPC compiler flag. This is caused by the limited number of bits being used for the syn_id.
| Flag | Bitsize | Number of synapse types |
|---|---|---|
| TARGET_BITS_SPLIT_STANDARD | 9 | 512 |
| TARGET_BITS_SPLIT_HPC | 6 | 64 |
| Same goes with number of possible threads and number of ranks: | Flag | Bitsize | Number of threads |
|---|---|---|---|
| TARGET_BITS_SPLIT_STANDARD | 9 | 512 | |
| TARGET_BITS_SPLIT_HPC | 10 | 1024 |
| Flag | Bitsize | Number of ranks |
|---|---|---|
| TARGET_BITS_SPLIT_STANDARD | 18 | 262144 |
| TARGET_BITS_SPLIT_HPC | 20 | 1048576 |
There is also a limitation on the maximum possible resolution h relative to the min_delay. 14 Bits are reserved for the so-called lag, which leads to the following condition:
min_delay < 16384*h
This will normally be no real limitation, but as the resolution could be set to very low in theory, we should add this limitation for completeness.
The longest delay in the network has to be lower than
max_delay < 2097152*h
The maximum number of nodes is 2^62.
github-actions[bot]
There are a few limitations regarding the networks one can use with NEST and the parameters for each neuron or synapse, due to the implementation of the kernel of NEST. There should be a page listing all these limitations and potentially also provide ways of alleviating some restrictions, by the use of compiler flags for example.
First, some of these limitations should be collected in this issue.
Also, there are various warning or error messages being thrown at the user when he enters parameter combinations that don't work with NEST. All those should be added to this document, so that users will know which models will work before they fully implement them and get an error.