search

brian-team / brian2genn

Brian 2 frontend to the GeNN simulator
http://brian2genn.readthedocs.io/
GNU General Public License v2.0
46 stars 16 forks source link

Support TimedArray and rethink approach to run_regularly #96

Closed mstimberg closed 4 years ago

mstimberg commented 4 years ago

Supporting TimedArray is one of the main missing features that prevents some users from using brian2genn for their models (see e.g. #95 ). One of the major use cases for TimedArray is to implement stimuli varying in time, often on a slow time scale and implemented via a run_regulary operation.

Currently, we support a single run_regulary operation for NeuronGroup which gets inserted into the Neuron kernel. Given that the dt of run_regularly operations is typically orders of magnitude larger than the simulation time step, I wonder whether we should not change this approach and simply perform all run_regularly operations on the CPU, re-using the standard C++ standalone implementation. I guess performance-wise that wouldn't change anything? It would also take care of #58 and we could support TimedArray in these run_regularly operations at least.

tnowotny commented 4 years ago

I think performance - wise, running on the CPU would not pose much of an issue. However, I think there may be complications with reusing C++ standalone code: We are translating some of the state variables and parameters from a Brian-like format to a GeNN format, in particular synaptic weights. Any operations on those would have to be done on the GeNN data structures, not the original Brian2 ones - unless we want to translate back and forth for each run_regularly operation. This may well need subtle modifications of the C++ standalone code. In any case, we would have to take care of correct data synchronisation between GPU and CPU data, of course.

But outside these caveats it would be great to be able to support timed arrays.

mstimberg commented 4 years ago

Good point about the synaptic weights – I guess as a first step we could exclude them from the variables you are allowed to use/change in a run_regularly operation? This would still leave a number of valid use cases.

tnowotny commented 4 years ago

Agreed, that would work and still be quite useful. for the synapse weights it is essentially just a question of re-indexing correctly ... might not be trivial to plug into the current C++ standalone pipeline ... I need to think about it a bit longer ... would you be happy to attempt a first implementation excluding code that changes synaptic weights?

mstimberg commented 4 years ago

I'll see what I can do!