Spikegenerator precise time patch

[jgarridoalcazar]

The following pyNN code produces an issue when running with NEST backend:

import pyNN.nest as sim
sim.setup(timestep=0.1)
exc_stim = sim.Population(1, sim.SpikeSourceArray, cellparams={'spike_times': [353538.4]})

Internally pyNN defines 'precise_times' property of the spike_generator model to true and the assertion fails when using large times.

By scaling the machine epsilon according to the magnitude of the values being used solves this issue. It is also recommended in the documentation of the epsilon function (http://en.cppreference.com/w/cpp/types/numeric_limits/epsilon).

[abigailm]

Is this even a NEST issue, or exclusively a NEST issue? As the default parameter in NEST is set to False, shouldn't PyNN do likewise?

[apdavison]

@jgarridoalcazar can you post the error message which appears?

@abigailm it does seem to be a NEST issue; all PyNN is doing here, I think, is calling SetStatus on a built-in NEST model.

[abigailm]

@apdavison yes, but if it is calling SetStatus and setting a parameter that is by default False in NEST to True, without the PyNN user explicitly stating this, then this is a surprising side effect, isn't it?

[abigailm]

@apdavison Obviously assertions failing is not good. So it is also a NEST problem. But I still don't think PyNN should be quietly adjusting default values.

[apdavison]

@abigailm So you think that PyNN should always use the same default values as NEST? The PyNN default is to always prioritize accuracy / cross-simulator compatibility over performance.

I may well be missing something here, but I don't see that this is a PyNN problem at all. As long as "True" is a valid value for the parameter, any user could set it to this value in PyNEST or sli.

[jgarridoalcazar]

@apdavison The exact error I get when I use that code is the following one:

Assertion failed: (offset >= 0.0), function assert_valid_spike_time_and_insert_, file ../../nest-2.10.0/models/spike_generator.cpp, line 159.

The same issue is also open in pyNN github at (NeuralEnsemble/PyNN#399) with no solution so far.

I can also say that if we try to reproduce the error (using some more or less equivalent) pyNEST code it runs with no issue at all, so I guess that pyNN internally rounds/approximates/calculates a similar value (but with different internal representation).

import nest
import numpy
nest.SetDefaults('spike_generator', {'precise_times': True})
nest.Create('spike_generator', 1, params={'spike_times': numpy.array([ 353538.4])})

But in any case, the value pyNN produces should be valid for NEST even though we cannot reproduce that exact value (or the internal representation) without using pyNN, so I guess the bug is related to NEST.

[heplesser]

@apdavison @abigailm @jgarridoalcazar I had a look at the code and this is a NEST issue related to how we handle rounding errors. It just never surfaced so far, I suppose, since no-one used such large spike times. I will create a fix shortly.

[jgarridoalcazar]

Thanks @heplesser. At least for my use case the code of this pull request seems to solve the issue

[abigailm]

@apdavison Unless the PyNN default is to select the precise versions of the neuron models (which have different names), I don't think changing the parameter default to True is enhancing either accuracy or cross-simulator compatibility, as the grid-based versions will ignore any off-grid component of the received spikes. So in this case, it seems that the principle of least surprise would suggest that PyNN should not re-set this default, and instead let users opt in to off-grid computations. But I also may be missing something here. And I re-iterate that this is not as big a deal as NEST generating an error for what should be a valid spike time assignment.

[apdavison]

@abigailm Sorry, I wasn't clear. PyNN does indeed select the precise versions of the models where these are available.

[heplesser]

@jgarridoalcazar I hadn't realized you had filed with as a PR, I thought it was an issue. I have now created a PR towards your PR that adds a regression test. Once you merge my PR, it will appear here and we can start the code review.

In order to trigger the assertion from NEST without PyNN, I had to specify the spike time as 353538.4 0.1 sub to create a number with "bad numerics".

[jgarridoalcazar]

@heplesser I have already merged your additions. Thanks!!

[abigailm]

@apdavison then it completely makes sense for PyNN to set the precise parameter to True by default, and I withdraw all assertions to the contrary :)

[heplesser]

👍 from me. If @abigailm is also happy with the fix, we are ready to merge.

[abigailm]

yup 👍