ALternate NETCON location for presynaptic voltage source

[refriend]

Hello,

My question/idea basically concerns NEURON's default process used to connect a target synapse to a source. By default I refer to networks built via NEURONS's GUI.

Despite it generally being bad form to do so, I have placed my actual question at the end of this post so that you may first understand where I am coming from.

My understanding of NEURON is that the actual process of creating a new NetCon can be traced down to each cell template's connect2target function. I have included a biophysical connect2target() since an artificial example would be a moot point:

Code: Select all

obfunc connect2target() { localobj nc //$o1 target point process, optional $o2 returned NetCon
	  soma nc = new NetCon(&v(1), $o1) 
	  nc.threshold = 10 // default threshold 
	  if (numarg() == 2) { $o2 = nc } // for backward compatibility
	  return nc
	}

This means that whenever cells are synaptically linked via nc_append(), the target(section:synapse) uses the source soma's voltage (the 1 end in this example) as its input for threshold evaluation. Then the specified delay accounts for the time from presynaptic vesicle release to ionic absorption.

Great.

But what about when you wish to account for the AP's propogation delay from the AP source to presynaptic button? It appears a pre-synapse (to described in NMODL) should be inserted in the source cell; and the connect2target() would then be amended to use a source(section:synapse) combination like the target.

Am I loco?.. has this already been accomplished? I'd hate to reinvent the wheel or break some unseen elegance of NEURON. BTW... I do realize that this method of linking to a presynapstic location will increase the computational overhead per http://www.neuron.yale.edu/neuron/stati ... tml#NetCon.

Thanks,
Rich

[ted]

The GUI tools address the most common situation, in which a presynaptic cell with a single spike trigger zone projects via axonal branches (which may be of various lengths (conduction latencies)) to multiple targets. This is represented by multiple NetCons that monitor a spike trigger zone in the presynaptic cell, and project to their target synaptic mechanisms with different delays. The delays eliminate the need to simulate spike propagation along the axon from trigger zone, along the main axonal trunk and into each of its distal ramifications, ultimately reaching the various presynaptic boutons. Each NetCon may have its own individual delay.

Less common is dendrodendritic synaptic transmission, in which there are multiple sites in the presynaptic cell where local depolarization may cause transmitter release that will affect a single synaptic target. In this case, the correspondence between "presynaptic cell" and "spike source" is not 1:1 but 1:N, where N is the number of dendritic sites from which transmitter may be released. One could start with a cell template generated by the GUI, then modify it so that one could use an integer to specify which spike source one means when calling connect2target. Then connect2target with that integer as its argument would spawn a NetCon that watches that particular spike source; in this case an appropriate delay for such a NetCon would be ~1 ms. Thinking ahead to the possibility that one's model might be ported to parallel hardware, it would make sense to follow a strategy similar to what is presented in Hines, M.L. and Carnevale, N.T. "Translating network models to parallel hardware in NEURON" (preprint available from http://www.neuron.yale.edu/neuron/bib/nrnpubs.html), i.e. immediately after creating each presynaptic cell, assign a unique "global identifier" integer (gid) to each of its spike sources.

Did this answer your question?

[refriend]

Thank you. We are definitely talking the same game. I had something much more complex in mind, but the more I think about it the more I like part of the simplicity in your design. More importantly, I wanted to ensure that I was not 'going against the flow' and working against something inherent to NEURON's design... that would definitely bite me when I extend my program to parallel computing.

Thanks.