Leech Heart (HE) Motor Neuron conductances contributions to NN activity (Lamb & Calabrese 2013)

 Download zip file 
Help downloading and running models
"... To explore the relationship between conductances, and in particular how they influence the activity of motor neurons in the well characterized leech heartbeat system, we developed a new multi-compartmental Hodgkin-Huxley style leech heart motor neuron model. To do so, we evolved a population of model instances, which differed in the density of specific conductances, capable of achieving specific output activity targets given an associated input pattern. ... We found that the strengths of many conductances, including those with differing dynamics, had strong partial correlations and that these relationships appeared to be linked by their influence on heart motor neuron activity. Conductances that had positive correlations opposed one another and had the opposite effects on activity metrics when perturbed whereas conductances that had negative correlations could compensate for one another and had similar effects on activity metrics. "
1 . Lamb DG, Calabrese RL (2013) Correlated conductance parameters in leech heart motor neurons contribute to motor pattern formation. PLoS One 8:e79267 [PubMed]
Citations  Citation Browser
Model Information (Click on a link to find other models with that property)
Model Type: Realistic Network; Neuron or other electrically excitable cell;
Brain Region(s)/Organism: Leech;
Cell Type(s): Leech heart motor neuron (HE);
Channel(s): I Na,p; I A; I K; I K,leak; I K,Ca; I Sodium; I Calcium; I Na, leak;
Gap Junctions: Gap junctions;
Simulation Environment: GENESIS;
Model Concept(s): Action Potential Initiation; Activity Patterns; Bursting; Temporal Pattern Generation; Detailed Neuronal Models; Parameter sensitivity; Conductance distributions;
Implementer(s): Lamb, Damon [Damon.Lamb at neurology.ufl.edu];
Search NeuronDB for information about:  I Na,p; I A; I K; I K,leak; I K,Ca; I Sodium; I Calcium; I Na, leak;
compt_chop.g *
compt_chop.g.bu *
defaults.g *
defaults.g.bu *
hot *
Neurokit.g *
Neurokit.g.bu *
NEURON.g.bu *
synactivator.g *
synactivator.g.bu *
userprefs.g *
userprefs.g.bu *
xall.g *
xall.g.bu *
xcell_funcs.g *
xcell_funcs.g.bu *
xchannel_funcs.g *
xchannel_funcs.g.bu *
xgeom.g *
xgeom.g.bu *
xgraph_funcs.g *
xgraph_funcs.g.bu *
xicons.g *
xicons.g.bu *
xout_funcs.g *
xout_funcs.g.bu *
xrun.g *
xrun.g.bu *
xselect.g *
xselect.g.bu *
xstartup.g *
xstartup.g.bu *
xtitle.g *
xtitle.g.bu *

// synactivator object
// This is an extended object built from scratch to provide
// for synaptic activation equivalent to a single spike of
// a given weight.  The activation is delivered by calling
// an action.  This is something that would be nice to have
// in the various synaptic channel objects.



// a synactivator is a neutral with the following actions and fields:
//	weight	(rw)	: spike weight (alias for z)
//	act	(ro)	: calculated activation to deliver (alias for y)
//	path	(ro)	: channel to deliver to
//	SEND_SPIKE path	: send a spike to the given channel
//	PROCESS		: called from schedule to terminate activation
// The object is defined to be in the device class.  This is important
// as the order in which the synactivator PROCESS action is called from
// the schedule determines when the activation is terminated.  Since
// devices follow the channels in the schedule, we can terminate the
// activation on the next call to PROCESS.

create neutral /synactivator
pushe /synactivator > /dev/null

addfield . weight -indirect . z -description "Spike weight"
addfield . act -indirect . y -description "Calculated activation"
addfield . path -description "Destination channel"

setfieldprot . -readonly path act

addaction . SEND_SPIKE __synactivatorSEND_SPIKE
addaction . PROCESS __synactivatorPROCESS

addclass . device

pope > /dev/null

addobject synactivator /synactivator

// ACTION functions

// SEND_SPIKE action
// calculate the activation for the channel and send an ACTIVATION
// message causing the activation to be added to the channel when
// it is next processed.

function __synactivatorSEND_SPIKE(action, chanpath)

    if ({getfield act} != 0.0)
	echo synactivator: already sending a spike to {getfield path}

    str chantype
    foreach chantype (manualconduct channelC channelC2 channelC3 \
	    channelA channelB synchan synchan2 hebbsynchan hebbsynchan2)
	if ({isa {chantype} {chanpath}})
	    chantype = "Ok"

    if (chantype != "Ok")
	echo synactivator: '{chanpath}' not a synaptic channel

    setfield act { {getfield weight} / {getclock 0} }
    setfield path {chanpath}

    addmsg . {chanpath} ACTIVATION act


// PROCESS action
// Remove the ACTIVATION message if there is one and zero the act
// field which indicates no spike being sent

function __synactivatorPROCESS

    if ({getfield act} != 0.0)
	setfield act 0
	deletemsg {getfield path} 0 -find . ACTIVATION