Voltage dependent STDP rules (e.g. Clopath Rule)

[seeholza]

Introduction

There has been recent interest expressed in context of the Human Brain Project to have more complex STDP rules available in NEST. As part of this, I am currently trying to figure out some possibilities for implementing voltage based STDP rules in NEST, e.g. synapses that update their weight depending on the (current) postsynaptic voltage, and would like to encourage some discussion here.

The voltage dependence of the rule leads to all kinds of complications with event-based updating, especially since the weight update of the synapse can also be 'triggered' by the crossing of the postsynaptic voltage above a threshold (see Model below).

Below are the model details and some ideas on how to approach this. I would be grateful for any discussion, and especially other approaches that I am missing.

Model

This is slightly simplified from Eq. (3) in Clopath C, Gerstner W. Voltage and Spike Timing Interact in STDP - A Unified Model. Frontiers in synaptic neuroscience. 2010;2:25–25.

where

• X(t): presynaptic spike train
• \bar{x}(t): filtered presynaptic spike train
• u(t): postsynaptic voltage
• \bar{u}(t): filtered postsynaptic voltage
• thetas: constants

Note: the LTP update depends only on continuous pre and post synaptic quantities (voltage, voltage filters, spike filters), and is not (as common in most models) triggered by pre or postsynaptic spike-times.

Ideas

Locally store history of postsynaptic voltage & trigger update by event

The most NESTian approach to this would probably to store a history of the postsynaptic voltage, to allow the computation of filters and postsynaptically triggered updates (keeping only the filter at the postsynaptic neuron will not allow you to compute the LTP terms: see the term in red in the equation above) when a synapse is updated between presynaptic spikes.

The needed length of this history will, however, need to be as long as the time between presynaptic spikes (since synapses are only updated on presynaptic spikes and would need the full history).

While the LTP update depends on continuous quantities of the postsynaptic node, the periods during which the condition is met are mostly relatively short (the theta_+ threshold is close to the spiking threshold). One workaround would be implementing a "trigger" from the postsynaptic neuron if this term crosses from positive to negative, that causes a synapse to update itself, accessing the voltage history stored on the postsynaptic neuron that is only as long as the time during which the term was positive.

Access postsynaptic voltage from continuously updated synapses

Using the same continously updating connection model one could simply access the postsynaptic voltage at every time step to check thresholds, and build filters.

I see a problem with the communications overhead though, if the Synapse (this is a Node pretending to be a Synapse) and the postsynaptic Node are not on the same process.

GapJunctions onto continuously updated synapses

We recently developed a NEST model that replaces a synapse by a combination of nodes and synapses, tricking our way around the event-based connections in NEST. Such a continuously updated synapse (internally, a Node), could receive a type of GapJunction connection from the postsynaptic neuron, thereby giving it continuous access to the postsynaptic voltage and allowing it to keep a filter of the voltage at the synapse, as well as access the voltage at every timestep.

However, this would need be a unidirectional GapJunction, and the GapJunction implementation seems to be quite involved to ensure the bidirectionality. Could this be simplified to apply it to this case?

[heplesser]

@flinz You raise very interesting issues which we should discuss properly. I think a presentation and initial discussion at the next Open NEST Developer Video Conference (17 Oct) would be a good start if that fits for you. We could also arrange a group session on this topic during the NEST User Workshop in November.

Concerning the last point (unidirectional GapJunctions): We introduced the requirement of symmetric connections to prevent users from accidentally creating unidirectional gap junctions and thus end up with scientifically meaningless results. If there is a proper use for unidirectional information flow, and we can find a way to ensure unidirectional gap junctions are created only where they really make sense, we could allow them.

[james4424]

@flinz @heplesser I have also generalized the original clopath voltage plasticity rule to account for anti-hebbian plasticity observe at distal dendrites of the layer 5 pyramidal neuron (see attached poster). This is one of the experiments that cannot be accounted for in the original paper. poster_ver6_1.pdf

The generalized model can be expressed as: dW/dt = -ASd(t)[Ud-Qd] + BSp(t)[U-Qp]*[Up-Qd] whereby A,B are constants for LTD and LTP respectively, Sd,Sp are filtered pre-synaptic spike-trains with time constants tau_d,tau_p, Ud, Up are filtered local membrane potential with tau_d,tau_p, Qd, Qp are thresholds, and U is the local membrane potential. []is the ramp function.

This is a generalized form as Sd(t) with tau_d = 0 is again the pre-synaptic spike train.

In the NEST set-up, weight update is only necessary at the single time-point of arrival of pre-synaptic spike. However, for the purpose of the original or generalized voltage plasticity, weight update would be necessary upon pre-synaptic spike arrival for the duration of the time window that the filtered pre-synaptic spikes or other terms remain positive. Hence while the length of the history (from previous pre-synaptic till this current pre-synaptic spike) remains unchanged, weight update will need access to the post-synaptic local membrane potential history for the duration between pre-synaptic spikes, but also the above-mentioned time-window right after the most recent pre-synaptic spike.

I am not sure if it can be further simplified unless we make modifications to the voltage rule.

One consideration why such a time-window is necessary is the scenario of heterosynaptic plasticity, whereby 2 pre-synaptic spikes arrive at 2 synapses, A and B, that are in the same compartment, one after another. The 2nd spike arriving at synapse B would result in further plasticity in synapse A, if the plasticity terms are still positive, especially so if the spikes occur in quick succession.

I have also implemented a multi-compartment neuron model with calcium spike that explicity models the voltage transient of the action potential (in soma compartment) and calcium spike(in distal compartment), (https://github.com/nest/nest-simulator/pull/241) such that [U-Qp] may last more than a single time-step, further necessitating such a time-window.

I look forward to further discussions.

[MariaCervera]

@heplesser Has there been any development of such models since the issue was raised? I would be interested in trying them if there are any available models for testing. Thanks a lot.

[heplesser]

@MariaCervera None that I am aware of, unfortunately.

[abigailm]

There is a person at Jülich working on this. I will encourage him to share his status.

[MariaCervera]

@heplesser Ok, thank you! @abigailm That would be great, thanks.

[jstapmanns]

@MariaCervera In the course of the NEST activities in the Human Brain Project, we aim at implementing the Clopath-rule in NEST. This can be considered as a step towards an implementation of the more complex third factor plasticity rule for multi compartment models by Urbanzcik and Senn. We are currently working on a prototype implementation of the Clopath rule in order to find out how to efficiently implement the synaptic dynamics in an event-driven update scheme for synapses (cf. Introduction by @flinz). As soon as this implementation is ported to NEST and available for testing, we will inform you.

[seeholza]

@jstapmanns @abigailm That's great to hear, thanks for the update - I had heard from @diesmann that this was in the works. I am happy to review when it's ripe!

[heplesser]

@ddahmen @janhahne @jstapmanns Could you report on status?

[janhahne]

@flinz @heplesser The status is that we finished the implementation and created a PR #1095. We are happy about any review/input.

[heplesser]

Closing as #1095 has been merged a little while ago.