izhikevich2004.py failing with PyNN 0.9.0 & NEST 2.10.0

[pgleeson]

izhikevich2004.py has been updated & tested with Neuron & Brian on PyNN 0.9.0, but fails with this version of PyNN and NEST 2.10.0.

The first issue is that

sim.setup(timestep=time_step, min_delay=time_step)

is no longer compatible. I'm not sure whether just taking out min_delay here is recommended? When it is removed, there is an error related to the ramp current for plot R:

Traceback (most recent call last):
  File "izhikevich2004.py", line 418, in <module>
    scalebar_level=0.5)
  File "izhikevich2004.py", line 96, in run_simulation
    injectedCurrent = sim.StepCurrentSource(times=times, amplitudes=amps)
  File "/usr/local/lib/python2.7/dist-packages/pyNN/nest/standardmodels/electrodes.py", line 35, in __init__
    self.set_native_parameters(parameter_space)
  File "/usr/local/lib/python2.7/dist-packages/pyNN/nest/standardmodels/electrodes.py", line 74, in set_native_parameters
    'amplitude_times': times})
  File "/home/padraig/opt/nest/lib/python2.7/site-packages/nest/lib/hl_api_helper.py", line 138, in stack_checker_func
    return f(*args, **kwargs)
  File "/home/padraig/opt/nest/lib/python2.7/site-packages/nest/lib/hl_api_info.py", line 171, in SetStatus
    sr('Transpose { arrayload pop SetStatus } forall')
  File "/home/padraig/opt/nest/lib/python2.7/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 SetStatus_id: Setting status of a 'step_current_generator' with GID 4: Amplitude times must strictly increasing.

Other simulators seem to be happy with the arrays generated for times/amplitudes, and the times do look like they're strictly increasing.

The code ran successfully on PyNN 0.8.2 and NEST 2.10.0

Any insight on this @apdavison, @appukuttan-shailesh?

[appukuttan-shailesh]

@pgleeson : I am testing this on PyNN 0.9.0 and NEST 2.12.0. I didn't get the first error (with min_delay), so possibly that's been handled in the recent version of NEST. But yes I do get the second error regarding the amplitude times.

It seems to be a problem with pyNN.NEST. There is a difference between the amplitude 'times' being passed by the model and that handled by pyNN.NEST. For example:

Model times =  [   0.   10.  100.]
PYNN times =  [  0.     9.99  99.99]

And this seems to be linked to global_time_step. When I change the variable from 0.01 to 0.1, we get:

Model times =  [   0.   10.  100.]
PYNN times =  [  0.     9.9  99.9]

So it appears to reduce one time step from each timestamp supplied. This eventually causes the problem of non-increasing timestamps:

Model times =  [  0.00000000e+00   1.00000000e-02   2.00000000e-02 ...,   3.12500000e+02
   3.12510000e+02   4.00000000e+02]
PYNN times =  [  0.00000000e+00   0.00000000e+00   1.00000000e-02 ...,   3.12490000e+02
   3.12500000e+02   3.99990000e+02]

The first two pyNN values being same.

@apdavison : This is to do with _delay_correction() in pyNN.NEST.

[pgleeson]

Thanks @appukuttan-shailesh.

[pgleeson]

Reopening this issue. It was accidentally closed by text in this commit: 85571b8

[appukuttan-shailesh]

The recent PyNN fix resolves this.
NEST output for Izhikevich Model:

[appukuttan-shailesh]

@pgleeson : This (I believe) is now fixed, and could be closed.

[pgleeson]

Thanks @appukuttan-shailesh. I'll leave this open for now, as the OMV tests which were failing (currently) require pointing to a specific tagged release of PyNN: https://github.com/OpenSourceBrain/osb-model-validation/blob/master/omv/engines/getpynn.py.

I'll update the versions of NEST, PyNN etc. on OMV and test all projects again, which will be over the next few weeks.