multi-compartment artificial integrate and fire cells

[mctavish]

I need to construct artificial/LIF cells with event-driven dendritic trees and I would like to get feedback on the appropriate strategy.

My current thought is to have two objects: Some LIF object and DEND_SEG, a segment of dendrite. My meta-object cell would use the LIF as its soma and then I will connect some DEND_SEGs to the soma via NetCons. Additionally, DEND_SEGs will concatenate and branch via NetCons. Therefore, the LIF/soma will send/receive events from attached DEND_SEGs and DEND_SEGs will send/receive synaptic events and events from adjacent DEND_SEGs.

Now, while I see how I can write a LIF and DEND_SEG objects in MODL, it seems my meta-object cell would have to be done in hoc/python, where it specifies the actual morphology and parameters of a given meta-object cell.

Is this correct, and a good way to proceed, or does somebody have a more refined method?

Thanks,
Tom

[Raj]

Whether that is a good way to proceed depends entirely on your objectives.

The main thing to realize is that you probably want to be able to access the metacells as separate units during the simulation. Then it is wise to have the LIF and DEND_SEG's managed by a single objects and writing a template would be the way to go. Rather than building the network from these cells, it might however be easier to hand the LIF and DEND_SEGs to these metacell objects during the network construction. This however depends a lot on the objectives of your simulation and the conceptual model that you try to implement.

[ted]

I need to construct artificial/LIF cells with event-driven dendritic trees and I would like to get feedback on the appropriate strategy.

My current thought is to have two objects: Some LIF object and DEND_SEG, a segment of dendrite. My meta-object cell would use the LIF as its soma and then I will connect some DEND_SEGs to the soma via NetCons. Additionally, DEND_SEGs will concatenate and branch via NetCons. Therefore, the LIF/soma will send/receive events from attached DEND_SEGs and DEND_SEGs will send/receive synaptic events and events from adjacent DEND_SEGs.

There's more than a bit of cognitive dissonance in the notion of event-based
communication between compartments. The usual reason to represent a cell with
multiple compartments is to emulate the "diffusion" of electrical or chemical signals
through space. This implies a close coupling between compartments that requires
communication of floating point values at each time step. Might as well stick with the
discretized cable equation, implemented with the usual branched tree of sections, and
cook up a "spike" mechanism that just watches for v at the trigger zone to reach a
threshold, at which point it genreates a "spike event" and resets v at that point to some
resting level. There's not much computational savings in doing this, however, because
there's still an ODE to solve for each compartment.

On the other hand, maybe you really don't want any communication between cell regions
until the local v crosses some threshold. If that's the case, it makes sense to represent a
cell as a bunch of subunits that use event-based communication.

[Raj]

Ted,

There is a nice example why you might want to do this available on ModelDB:
http://senselab.med.yale.edu/modeldb/Sh ... odel=20212

Stating that certain CA1 pyramidal cells can be replaced by a two layer network.

Raj

[mctavish]

Thanks for the replies.

What I will be evaluating is dendritic branches that backpropagate action potentials and receive IPSPs. (The mitral cell). IPSPs received on one dendrite can prevent the action potential from backpropagating along the remainder of the dendritic branch. It is this behavior, in a network context, that I will be modeling and exploring. Therefore, I think I can stick with my original plan, and hopefully I'm not too confused on the event-based communication, and see how it goes.

Tom

[ted]

dendritic branches that backpropagate action potentials and receive IPSPs. (The mitral cell). IPSPs received on one dendrite can prevent the action potential from backpropagating along the remainder of the dendritic branch.

When it comes time to publish, you'll need a good rationale to avoid fatal objections from
referees. The obvious one will be some variant of "by abandoning the cable equation, you
have thrown out the baby with the bathwater."

[mctavish]

Ted, I think I understand your concern, because as I start to delve into the NetCon class, I'm up against a wall and it appears that I will throw the baby out with the bathwater because I do not see how to modify the weight vector of NetCons dynamically.

I want a dendritic segment to be able to broadcast to its adjacent segments what its membrane potential is. Additionally, to make the signal so that it does not recursively send to its senders (I want inhibitory input to radiate out and decay from the synaptic location, for example.) I'd like to dynamically set other fields in the weight message.

Ideally, this would be the API:

Code: Select all

: weight is the membrane potential of the sender (Different values could signal APs vs membrane fluctuations)
: sender_id is the id of the sender
: sender_of_sender is the id of the sender of the message to this sender
NET_RECEIVE(weight, sender_id, sender_of_sender_id) {
  if(sender_of_sender_id != my_id) { : Avoid looping the message if we sent or propagated it
    adjustMyMembranePotential(weight)
    for i in AllMyNetCons {
      netCon[i].weightVec[0]=myMembranePotential
      netCon[i].weightVec[1]=my_id
      netCon[i].weightVec[2]=sender_id
    }
    net_event(t)
  }
}

What it comes down to is somehow having the object gain access to its NetCons and dynamically setting its weight values. I see that in NET_RECEIVE that the weight vector is passed in by reference, so one can modify input parameters, but I want to modify the weight vector on output. How might this be possible?

[ted]

The first question is whether it even makes sense to try to do this. Is the sending of
messages supposed to occur on every fadvance()? If that's the case, what you have
in mind is close to how GENESIS deals with electrotonus (except when the "Hines method"
is used). Please note that this is inherently an "explicit" method, which may force very
short dt for the sake of stability if compartments are small. If communication is supposed
to happen only when triggered, what is the trigger?

[mctavish]

Hi Ted.

I do not want to update variables with every fadvance.

The trigger is a change in membrane potential originally triggered by a spiking event. In the case of backpropagating action potentials, the spike will radiate from the soma to the dendritic segments as a spiking event, similar to a linear network of cells that has a short delay and fires with a sensitive threshold. Inhibitory synapses on the dendrites will also radiate, but in both directions along the dendrite and with a decay of influence. That is, inhibition will be prominent at the location of synapse, but decay along adjacent dendrites as it spreads, and actually peter out within a few segments of the synaptic location. In this way, network activity from inhibitory events will be constrained.

Theoretically, most cells in the network for some small window of time will not be too active and have a resting membrane potential. Still, I will probably want to squelch event generation. I can envision doing this through some membrane quantization, like if its membrane potential does not change much, then it will not generate another event. Or ideally, if a segment receives two events in short order to modify its membrane potential, then before it sends an event in response, instead of ignoring the second event, if it could incorporate that information into the original message that is going to be sent out from the first message, that would be good.

So again, is there any way in NMODL of gaining access to the cell's NetCons to programmatically and dynamically change the NetCon's weight vector and if so, how?

Thanks,
Tom

[hines]

I see that in NET_RECEIVE that the weight vector is passed in by reference, so one can modify input parameters,

Right. And the block can deal with all the incoming netcons with the FOR_NETCONS(w,...) loop.

but I want to modify the weight vector on output. How might this be possible?

The only way that immediately comes to mind is to give the POINT_PROCESS (or ARTIFICIAL_CELL?) instance a List of the NetCons which have this instance as the source (of the net_event(t) call). Then you can iterate over the list before the net_event(t) and use the
nrn_netcon_get_thresh and nrn_netcon_set_thresh or nrn_netcon_info functions (the latter is the most general) declared in nrn/src/nrncvode/netcvode.cpp to decide how to change the values.

[mctavish]

Thanks Michael. I'll see what I can do.

[hines]

I thought some more about a source finding out the NetCon list it sends events to and see that the net_event(t) call gets translated into the c code,

Code: Select all

net_event ( _pnt, t ) ;

where _pnt refers to this POINT_PROCESS or ARTIFICIAL_CELL instance. Looking at the net_event implementation in src/nrncvode/netcvode.cpp I see the list is
pnt_->presyn_->dil_. Unfortunately, presyn_ and dil_ both point to C++ class instances so it would be necessary to devise an 'extern "C" {}' iteration function and put it in netcvode.cpp in order to access the NetCon objects from the dil_ list.