Hi all,
I am wondering whether it's possible to add some randomness to NetCon's delay parameter. Right now, I have cell A receiving excitation from cell B and the delay parameter lets me set the latency between when cell B's membrane potential crosses threshold and when cell A receives the excitation. But I want there to be a inter-trial jitter in that latency - i.e. every time cell B potential crosses threshold, it would randomly pick from a range of possible latency values and excite cell A after that latency (and the next time it's triggered, it would have a different latency, etc.).
I hope that made sense. Please let me know if you would like any more information or clarification and thanks so much for your help!
A
Adding randomness to NetCon "delay"
-
- Site Admin
- Posts: 6384
- Joined: Wed May 18, 2005 4:50 pm
- Location: Yale University School of Medicine
- Contact:
Re: Adding randomness to NetCon "delay"
Is cell B an artificial spiking cell, or is it a biophysical model cell i.e. a model implemented with sections that integrates "real" synaptic currents? Does B project to just one target synapse on one other cell, or does it project to multiple synaptic mechanisms? If the latter, should all of the elicited postsynaptic responses show jitter, and if yes, should they all show the same jitter or should it be different? i.e. is the jitter in cell B's spike time (as it would be if B receives synaptic background "noise"), or is the jitter intrinsic to the synaptic mechanisms themselves (as it would be if, say, vesicle docking and release varied from one presynaptic spike to the next).
-
- Posts: 4
- Joined: Wed Jul 25, 2012 1:31 pm
Re: Adding randomness to NetCon "delay"
Hi,
Thanks for the rapid response. To answer your questions,
Cell A is a single compartment biophysical model with real synaptic currents.
Both of these synapses use NetCon
Just to clarify a little bit further:
Imagine that cells A and C are located far away from each other physically. Cell B drives both of these cells, but it's very close to A (and thus, far from B). So when B fires, A experiences its postsynaptic event before C does (let's say, 3ms vs 13ms). But, there's also a jitter across multiple B->A events and also a jitter across multiple B->C events (and these are not identical jitters). e.g. when B fires at t1, A responds at t1+2ms, and C responds at t1+15ms, then when B fires again at t2, A responds at t2+4ms, and C responds at t2+11ms, etc... (i.e. C always responds later than A, the jitter in the two synapses are independent).
I would ideally want to specify a range of values for the B->A delay (e.g. 2ms to 4ms at 0.1ms intervals) and a different range of values for the B->C delay (e.g. 11ms to 15ms at 0.1ms intervals) and these two events would independently sample from this distribution to determine each time a synaptic event occurs.
Thanks again for your help and please ask me further questions if anything doesn't make sense. Thanks!
A
Thanks for the rapid response. To answer your questions,
Ooops. I misspoke when I wrote the original question - cell B is an artificial spiking cell (a NetStim), so there's no "membrane potential crossing threshold"ted wrote:Is cell B an artificial spiking cell, or is it a biophysical model cell i.e. a model implemented with sections that integrates "real" synaptic currents?
Cell A is a single compartment biophysical model with real synaptic currents.
Cell B projects onto A and another cell (cell C - it's another single compartment biophysical cell)ted wrote:Does B project to just one target synapse on one other cell, or does it project to multiple synaptic mechanisms?
Both of these synapses use NetCon
Yes, I would like to have the responses in both A and C show jitter and ideally have different jitters (independent of each other).ted wrote:If the latter, should all of the elicited postsynaptic responses show jitter, and if yes, should they all show the same jitter or should it be different?
Just to clarify a little bit further:
Imagine that cells A and C are located far away from each other physically. Cell B drives both of these cells, but it's very close to A (and thus, far from B). So when B fires, A experiences its postsynaptic event before C does (let's say, 3ms vs 13ms). But, there's also a jitter across multiple B->A events and also a jitter across multiple B->C events (and these are not identical jitters). e.g. when B fires at t1, A responds at t1+2ms, and C responds at t1+15ms, then when B fires again at t2, A responds at t2+4ms, and C responds at t2+11ms, etc... (i.e. C always responds later than A, the jitter in the two synapses are independent).
I would ideally want to specify a range of values for the B->A delay (e.g. 2ms to 4ms at 0.1ms intervals) and a different range of values for the B->C delay (e.g. 11ms to 15ms at 0.1ms intervals) and these two events would independently sample from this distribution to determine each time a synaptic event occurs.
Thanks again for your help and please ask me further questions if anything doesn't make sense. Thanks!
A
-
- Site Admin
- Posts: 6384
- Joined: Wed May 18, 2005 4:50 pm
- Location: Yale University School of Medicine
- Contact:
Re: Adding randomness to NetCon "delay"
Forget about the 0.1 ms interval stuff--it introduces an unnecessary complication that isn't helpful for the implementation.
Start by thinking about a spike source "src" that projects to a single target "tgt" with fixed delay "del"src generates events at times ti.
NetCon nc delivers events to tgt at times ti* = ti+nc.delay, where nc.delay = del.
A simple, direct way to implement jitter would be to interpose an artificial spiking cell "mid" between src and tgt.mid would be an instance of a new class of artificial spiking cell that responds to an input event by launching a self event that returns after latency tjit. The value of tjit can be drawn from a pseudorandom number generator ("rng")--uniform distribution over a range [a,b] where a>0 makes the most sense, but negexp would also be possible. Arrival of a self event makes mid generate an output event that can be conveyed by a NetCon to a target. Total latency from src to tgt is
nc0.delay + tjit + nc1.delay
If a model that uses this strategy is ever parallelized, for the sake of efficiency one should make sure that nc0.delay = nc1.delay so that each processor can execute for as long as possible before spike exchange is necessary; a similar consideration applies for mutithreaded execution.
A side comment: the "weight" of the projection from src to tgt is specified by nc1.weight; nc0.weight is irrelevant.
Your model network would then look like this:
A <-- midA <-- B --> midC --> C
To ensure statistical independence of the jitter along each path (important for reproducibility and debugging), each mid* cell could be paired with its own pseudorandom sequence generator instance.
A possible alternative implementation might be to eliminate the "mid" cell and build the jitter into tgt itself. Each input event would make tgt launch a self event that returns after a latency drawn from a rng. This requires only one NetCon per src->tgt path, reduces the size of the event queue, and allows longer run times between spike exchanges. With regard to overhead for dealing with events per se, this seems marginally superior to using a "mid" cell. However, the savings is illusory--what this approach saves in one area it loses in another, by limiting each tgt instance to receiving just one input stream; if two or more input streams converge on a single tgt, I don't see how to preserve statistical independence of their jitter. This imposes a big performance hit if tgt is a biophysical synaptic mechanism governed by one or more ODEs or kinetic reactions, because each new equation that requires numerical integration is much more costly than putting another event in the event queue. And if tgt is an artificial spiking cell, and each jittered stream requires its own tgt instance, with its own self events and output events that must be managed, where's the savings in that?
Start by thinking about a spike source "src" that projects to a single target "tgt" with fixed delay "del"
Code: Select all
nc
src-->tgt
NetCon nc delivers events to tgt at times ti* = ti+nc.delay, where nc.delay = del.
A simple, direct way to implement jitter would be to interpose an artificial spiking cell "mid" between src and tgt.
Code: Select all
nc0 nc1
src-->mid-->tgt
nc0.delay + tjit + nc1.delay
If a model that uses this strategy is ever parallelized, for the sake of efficiency one should make sure that nc0.delay = nc1.delay so that each processor can execute for as long as possible before spike exchange is necessary; a similar consideration applies for mutithreaded execution.
A side comment: the "weight" of the projection from src to tgt is specified by nc1.weight; nc0.weight is irrelevant.
Your model network would then look like this:
A <-- midA <-- B --> midC --> C
To ensure statistical independence of the jitter along each path (important for reproducibility and debugging), each mid* cell could be paired with its own pseudorandom sequence generator instance.
A possible alternative implementation might be to eliminate the "mid" cell and build the jitter into tgt itself. Each input event would make tgt launch a self event that returns after a latency drawn from a rng. This requires only one NetCon per src->tgt path, reduces the size of the event queue, and allows longer run times between spike exchanges. With regard to overhead for dealing with events per se, this seems marginally superior to using a "mid" cell. However, the savings is illusory--what this approach saves in one area it loses in another, by limiting each tgt instance to receiving just one input stream; if two or more input streams converge on a single tgt, I don't see how to preserve statistical independence of their jitter. This imposes a big performance hit if tgt is a biophysical synaptic mechanism governed by one or more ODEs or kinetic reactions, because each new equation that requires numerical integration is much more costly than putting another event in the event queue. And if tgt is an artificial spiking cell, and each jittered stream requires its own tgt instance, with its own self events and output events that must be managed, where's the savings in that?
-
- Posts: 4
- Joined: Wed Jul 25, 2012 1:31 pm
Re: Adding randomness to NetCon "delay"
Hi,
Thanks for the help! The implementation using 'mid' sounds like it would work perfectly for my purposes. I'll work on the new class and get back to you if things don't work out. Thanks a lot!
A
Thanks for the help! The implementation using 'mid' sounds like it would work perfectly for my purposes. I'll work on the new class and get back to you if things don't work out. Thanks a lot!
A
-
- Site Admin
- Posts: 6384
- Joined: Wed May 18, 2005 4:50 pm
- Location: Yale University School of Medicine
- Contact:
Re: Adding randomness to NetCon "delay"
Getting the code right can be tricky. Don't hesitate to ask if you have questions.