min_delay error with NEST 2.10

[Silmathoron]

Config: Python 3.5, NEST 2.10.0 and PyNN 0.8.0

Trying to run the example file from the doc with NEST I ran into the following problem:

running python ex.py nest returned

    sim.setup(timestep=0.01, min_delay=1.0)
  File "/usr/lib/python3.5/site-packages/pyNN/nest/__init__.py", line 128, in setup
    simulator.state.set_delays(min_delay, max_delay)
  File "/usr/lib/python3.5/site-packages/pyNN/nest/simulator.py", line 94, in set_delays
    'max_delay': max_delay})
  File "/home/me/.nest-2.10.0-install/lib/python3.5/site-packages/nest/lib/hl_api_helper.py", line 138, in stack_checker_func
    return f(*args, **kwargs)
  File "/home/me/.nest-2.10.0-install/lib/python3.5/site-packages/nest/lib/hl_api_models.py", line 91, in SetDefaults
    sr('/{0} exch SetDefaults'.format(model))
  File "/home/me/.nest-2.10.0-install/lib/python3.5/site-packages/nest/__init__.py", line 79, in catching_sli_run
    raise _kernel.NESTError("{0} in {1}{2}".format(errorname, commandname, message))
pynestkernel.NESTError: BadProperty in SetDefaults_l_D: Setting status of prototype 'gap_junction': gap_junction connection has no delay

The error goes away without sim.setup(timestep=0.01, min_delay=1.0), using sim.setup(timestep=0.01) only.

[kristoforcarlson]

I am having a similar problem. However, removing the delay arguments will not allow me to run the program.

Config: Python 2.7.6, NEST 2.10.0, and PyNN 0.8.1

Running the same example from the doc with NEST I received the following error after running:

python izh_neurons.py nest

Please re-compile NEST using --with-libneurosim=PATH
Traceback (most recent call last):
  File "izh_neurons.py", line 24, in <module>
    sim.setup(timestep=0.01, min_delay=1.0)
  File "/usr/local/lib/python2.7/dist-packages/pyNN/nest/__init__.py", line 131, in setup
    simulator.state.set_delays(min_delay, max_delay)
  File "/usr/local/lib/python2.7/dist-packages/pyNN/nest/simulator.py", line 98, in set_delays
    'max_delay': max_delay})
  File "/opt/nest/lib/x86_64-linux-gnu/python2.7/site-packages/nest/lib/hl_api_helper.py", line 230, in  stack_checker_func
return f(*args, **kwargs)
  File "/opt/nest/lib/x86_64-linux-gnu/python2.7/site-packages/nest/lib/hl_api_models.py", line 123, in SetDefaults
    sr('/{0} exch SetDefaults'.format(model))
  File "/opt/nest/lib/x86_64-linux-gnu/python2.7/site-packages/nest/__init__.py", line 91, in catching_sli_run
    errorname, commandname, message))
pynestkernel.NESTError: DictError in SetDefaults_l_D: Unused dictionary items:  min_delay max_delay

[mschmidt87]

@Silmathoron : This bug was fixed via #392 which is contained in PyNN 0.8.1. Could you upgrade to 0.8.1 and try running the script again?

@kristoforcarlson : I could not reproduce this error using python 2.7.9, PyNN 0.8.1 and NEST 2.10.0.
The error seems to occur when PyNN is trying to set min_delay and max_delay for all synapse models (except gap_junction, gap_junction_lbl). Can you put a print statement (print synapse_model) just before line 96 in pyNN/nest/simulation.py and paste the output of the script here?

[mschmidt87]

@kristoforcarlson : Are you sure that you are using the release version 2.10 of NEST? Did you download the source from here: http://nest-simulator.org/download/ ?

I have the suspicion that you might be using a developer version (e.g. the current master from github) of NEST, where the min_delay and max_delay entries were removed from the status dictionaries of the synapses. This makes the master currently incompatible with the current PyNN code and we are working on fixing this issue.

The developer versions of NEST currently also returns '2.10.0' as version number, which is a confusing bug that will be fixed soon.

[Silmathoron]

Sorry for the late reply,
updating PyNN to 0.8.1 indeed solves part of the problem, however I now cannot plot the figures:

Traceback (most recent call last):
  File "compare_aeif_cond_exp.py", line 57, in <module>
     from pyNN.utility.plotting import Figure, Panel
  File "/usr/lib/python3.5/site-packages/pyNN/utility/plotting.py", line 23, in <module>
    from sys import maxint
ImportError: cannot import name 'maxint'

Also the script raises the following warnings:

1. for connectivity

CSAConnector: libneurosim support not available in NEST.
Falling back on PyNN's default CSAConnector.
Please re-compile NEST using --with-libneurosim=PATH
somewhere/python3.5/site-packages/nest/lib/hl_api_helper.py:61: UserWarning: 
DivergentConnect is deprecated and will be removed in a future version of NEST.
Please use Connect instead!

2. regarding min_delay:

Jun 28 16:05:29 Scheduler::simulate [Warning]: 
    The requested simulation time is not an integer multiple of the minimal 
    delay in the network. This may result in inconsistent results under the 
    following conditions: (i) A network contains more than one source of 
    randomness, e.g., two different poisson_generators, and (ii) Simulate is 
    called repeatedly with simulation times that are not multiples of the 
    minimal delay.

[apdavison]

Traceback (most recent call last):
File "compare_aeif_cond_exp.py", line 57, in
from pyNN.utility.plotting import Figure, Panel
File "/usr/lib/python3.5/site-packages/pyNN/utility/plotting.py", line 23, in
from sys import maxint
ImportError: cannot import name 'maxint'

This is fixed in the master branch. If you're using Python 3, replace from sys import maxint with from sys import maxsize as maxint

[apdavison]

warnings:

1. for connectivity

you can ignore these warnings unless you want to use the CSAConnector class, in which case you will get a large speedup if you build NEST with libneurosim support

[Silmathoron]

Ok, I'm good with the error and the 1st warning, thanks!
Any idea where the 2nd comes from?

[mschmidt87]

I can comment on the 2nd one:
Let's imagine you have a simulation with two sources of randomness, e.g. two different Poisson generators.
In NEST, each thread has only one random number generator which provides all sources of randomness (in our case the 2 Poisson generators) with random numbers one after the other in each time interval of min_delay length.

Let's say you have a min_delay=1.5ms and simulate for 1.5 ms. Then the thread draws random numbers for the first Poisson generators for a time interval of 1.5 ms and then for the 2nd generator. So, like this:

1.5ms	1.5ms
PG1	PG2

Now you compare this to a case where you first simulate for 1ms and then for 0.5 ms. Then the thread first draws random numbers for 1ms for Poisson generator1 , then for 1ms for Poisson generator 2, and then the same for 0.5 ms first for Poisson generator 1 and then for generator 2.

1ms	1ms	0.5ms	0.5ms
PG1	PG2	PG1	PG2

So the random numbers in the first 0.5ms of PG2 are the same as in the last 0.5ms of PG1 in the first simulation. The two simulations will not yield the same spikes as in the first simulations you simulate 1.5ms with the same random seed in both cases.

This is because NEST uses one random number generator per thread (for performance reasons) and draws random numbers for its sources of randomness one after the other in each time interval of min_delay length.

This will only have an effect if you compare two simulations where you interrupt one of the two simulations, as in the example (case 1: 1.5ms simulation, case 2: simulate for 1ms, interrupt, simulate another 0.5ms).
If you only look at one simulation, the results and the statistics of the random sources will be correct.

[Silmathoron]

Ok, sorry, maybe my question was not clear: I understand why it would be a problem; what I don't understand is why it is complaining about "non integer multiple" since in the example I have

sim.setup(timestep=0.01, min_delay=1.0)

and

sim.run(100.0)

which should satisfy the requirement "simtime is an integer multiple of min_delay"...

[mschmidt87]

I see. If I see this correctly, the reason is to be found in line 141 of nest/simulator.py:
simtime += self.dt # we simulate past the real time by one time step, otherwise NEST doesn't give us all the recorded data

Thus, if you specify 100 ms simulation time, pyNN will make NEST actually run for 100.ms+dt, to get all spikes that happened between 0.ms and 100.ms, including the time step of 100.ms. Otherwise NEST will only give spikes with a maximal time step of 100. ms - dt. I am currently not sure what the reason for this is.

[Silmathoron]

Ok, this is indeed the reason why this is happening, thanks! And this is indeed a problem with NEST (the need for one additional timestep to get the whole data); maybe I should raise an issue on the NEST tracker, I'll investigate this.

[kristoforcarlson]

@mschmidt87 I think you are correct: I believe I was using the developer's edition of NEST. I will try the release edition and see if that works. That bug in the developer's edition that returns 2.10.0 should probably be fixed as it's definitely helpful for troubleshooting issues etc. Thanks for your help.