search

brian-team / brian2

Brian is a free, open source simulator for spiking neural networks.
http://briansimulator.org
Other
932 stars 220 forks source link

Event-based monitoring of synaptic variables #731

Open mstimberg opened 8 years ago

mstimberg commented 8 years ago

In models with synaptic plasticity, it would often be interesting to record the value of synaptic variables whenever a pre- or post-synaptic event arrives at a synapse. Quoted from a post by Maxwell Edison on the mailing list (https://groups.google.com/d/msg/brian-development/I-3g9wmGNr8/S_HPeh2_BQAJ):

I want to do something like this,

monitor = EventMonitor( source=synapses , event='spike_pre' , variables=('w', 'p') )

where, synapses := a synapses object 'spike_pre' := a spike event at the presynapse; 'w' := the synaptic weight; 'p' := neurotransmitter release probability (given a short-term plasticity model).

This still needs some thought on the implementation but also on the syntax level (e.g. we'd probably need a way to specify when exactly the variables are recorded, i.e. before or after the execution of the pre/post statements).

Another alternative would be to 1) allow simple statements (instead of only assignments) in pre/post code and 2) to have a record function that can be explicitly called in pre/post code.

A post-2.0 issue, but if we come up with a nice solution, this can be a very useful feature I think.

thesamovar commented 8 years ago

I like the syntax in the OP. I don't like the idea of allowing simple statments / record function in pre/post code. It feels like it's mixing levels a bit and would need us to modify codegen too much. Other than that it seems pretty simple, we'd record i and j (and k if necessary) as well as the variables they want at the time slot they specify (could this not be just one of our default time slot names?).

mstimberg commented 8 years ago

I like the syntax in the OP. I don't like the idea of allowing simple statments / record function in pre/post code. It feels like it's mixing levels a bit and would need us to modify codegen too much.

I don't think it would be too much work on the codegen side but I agree that it is not ideal. It would be inconsistent with our general concept that you can attach monitors to existing objects without modifying them. The only practical advantage of that approach would be that you could record intermediate values in between statements -- but this is a real corner use case and you could work around the restriction by introducing a new state variable that stores this intermediate value.

Other than that it seems pretty simple, we'd record i and j (and k if necessary) as well as the variables they want

It's not trivial from the implementation side (that's why I think this should certainly be post-2.0): we'd have to generalize the monitor template or have a new template for this use case (Synpases are not a SpikeSource and don't have a direct spikespace equivalent). Also it might be cleaner to have a new class, say SynapticEventMonitor because it works slightly differently.

at the time slot they specify (could this not be just one of our default time slot names?).

Sure, but we'll have to decide about which timeslot (I think before_synapses is the most natural choice) -- and again this is a difference to a standard EventMonitor where events are recorded in the time slot where they are emitted.

thesamovar commented 8 years ago

OK, let's discuss in more detail post-2.0.

mstimberg commented 6 years ago

As this came up recently on the mailing list again, I documented a workaround using user-defined functions: https://gist.github.com/mstimberg/c85ce1b20ef401e85b42e702c7e159aa