Delayed processing of pre-synaptic spikes

[jlubo]

I need an interface for delayed processing of pre-synaptic spikes. The enhancement should enable a pre-synaptic spike to trigger multiple events in the same post-synaptic neuron at different delay times (in my case, specifically, these are a postsynaptic potential after short delay and an increase in calcium concentration after longer delay, as described here).

To summarize, it would be great to have something like the POST_EVENT block with its time argument, just that it should be called at a certain time after a pre-synaptic spike.

[schmitts]

Making multiple connections with different synaptic delays is not sufficient? These could be connected to different synapse mechanisms.

[jlubo]

I don't think so - those synapses would have to communicate somehow (the calcium is needed for changes in synaptic weight).

Also, even if such a workaround were possible, there would be a lot of redundancy so I guess a proper implementation would be better in terms of performance.

[jlubo]

We found that the following workaround does the job.

We used two connections to the same postsynaptic neuron with different (pseudo) weights 1 and -1 and different delay times d0 and d1:

[arbor.connection((src,"spike_detector1"), "syn_exc_calcium_plasticity", 1, d0), \
arbor.connection((src,"spike_detector1"), "syn_exc_calcium_plasticity", -1, d1)]

which can be processed in one and the same synapse mechanism as follows:

NET_RECEIVE(weight) {
	if (weight > 0) {
		: postsynaptic potential evoked by presynaptic spike
	}
	else {
		: increase of calcium amount evoked by presynaptic spike
	}
}

[schmitts]

I think we can close the issue and think about writing an AEP for allowing additional payloads/slots in connections.

[jlubo]

The workaround mentioned above works if there is only one item in "syn_exc_calcium_plasticity" and thus the policy arbor.selection_policy.univalent is used.

If, however, "syn_exc_calcium_plasticity" holds more than one item, another solution is required because the then applicable policy arbor.selection_policy.round_robin will change the current item by every call of arbor.connection().

This is solved by PR #1868, which introduces the new policy arbor.selection_policy.round_robin_halt. Two connections to the same synapse mechanism can then be defined via:

[arbor.connection((src,"spike_detector1"), ("syn_exc_calcium_plasticity", arbor.selection_policy.round_robin_halt), 1, d0), \
arbor.connection((src,"spike_detector1"), ("syn_exc_calcium_plasticity", arbor.selection_policy.round_robin), -1, d1)]

[thorstenhater]

As this is related to a PR is this still needed? If not, please dismiss this and the PR.