Single, myelinated axon with several nodes and internodes

[hallockk]

Is there a good example of a myelinated axon model that's available for me to work through?

Thanks,

Kevin

[ted]

There are, and some are in ModelDB, but whether they are "good" depends on how you define "good." To me, "good" means not only high quality code but also that the code does not involve a lot of other stuff that is irrelevant to what I want to use the model for--that is, how closely my intent matches the intent of the original implementer of the model. Some models go into great detail regarding anatomical specializations in the vicinity of nodes of Ranvier, and some address extracellular stimulation.

[hallockk]

Thanks.

Right now, I'm looking for something extremely simple for me to compare my basic models with. I'd like a to find a single axon with passive internodes and HH nodes that fire if the voltage change is high enough. I'd like to tackle additional biological complexity later, but for now, simple is better. I've tried building it, with an Ipulse1 point process at one end, but it doesn't look like the nodes are firing. The current passes through the nodes just like it does the passive cables.

Kevin

[ted]

Search ModelDB for models by Moore. That should get you going.

[hallockk]

Thanks.

I tried to load the models in brill77 and received the following error:

nrniv: hoc_sf_ not declared at the top level
in pointman.hoc near line 30
external hoc_sf_
^
xopen("pointman.hoc" )
execute1("{xopen("pointman.hoc")}" )
load_file("pointman.hoc" )
nrniv: syntax error
in pointman.hoc near line 122
if (hoc_sf_.is_artificial(pp) == 0) {

Am I missing a file?

Kevin

[ted]

I tried to load the models in brill77

Don't count on the name of the zip file having any special meaning--some have unique names, many don't. The reliably unambiguous identifier is the model entry's accession number. I'm guessing that you mean the model whose accession number is 9848.

I don't understand "tried to load." Exactly what did you do?

NEURON models in ModelDB are generally packaged in such a way that there is a file called
mosinit.hoc
which is the "administrative master file" i.e. the one you should double click on, or execute by typing
nrngui mosinit.hoc
at the command line prompt. Such is the case with ModelDB entry 9848.

[hallockk]

Thanks! You solved my problem.

[hallockk]

I'm still working on this model. I currently have the following topology:

lead-node1-axon1-axon1[1]-axon1[2]-axon1[3]-axon1[4]-axon1[5]-axon1[6]-axon1[7]-axon1[8]-axon1[9]-node2-axon2.

node1 and node2 are HH nodes that are 10 micrometers in length with everything else being passive. Each axon1 section is 100 microns in length. All sections are 1 micron in diameter. "lead" connects the ipulse1 pulse to the first node and when the pulse has high enough amplitude, node1 fires as expected. After node1, node2 fires as well.

My goal with this model is to adjust the passive parameters in one axon1 section to determine the impact a local demylenation event might have on the pulse, but changing the parameters in axon1[9] also changes node1 such that eventually node1 won't fire. I'm confused as to why this would be the case.

Thanks,

Kevin

[ted]

changing the parameters in axon1[9] also changes node1 such that eventually node1 won't fire.

Your clue will be in the hoc statement that changes the params of axon1[9].

[hallockk]

Your clue will be in the hoc statement that changes the params of axon1[9].

Below is what I think is the relevant code, but I don't see the problem:

tobj = new CellBuildSection("axon1",9, 0, tobj, 1) slist.append(tobj)
tobj.parent=slist.object(10)

{
tobj = new MechanismStandard("pas")
tobj.set("g_pas", 1e-05, 0)
tobj.set("e_pas", -70, 0)
tobj = new MStanWrap(tobj, 1)
bild.topol.slist.object(10).ml.append(tobj)
}

[ted]

Are you following an example obtained from ModelDB, or somewhere else, or is there some other reason for using MechanismStandard?

[hallockk]

Are you following an example obtained from ModelDB, or somewhere else, or is there some other reason for using MechanismStandard?

I used the GUI interface to build my model so I assumed it's the default; why might that be a problem?

[ted]

MechanismStandard was designed as a tool to use for building other tools--specifically, for constructing graphical user interfaces such as the Cell Builder. As such, it has certain properties that are particularly useful in that context (i.e. machine-generated code that is written to ses files), but which may be impediments or have undesired side-effects in other contexts, such as user-written code. You just ran into such a case. I bet you a dollars to donuts you won't find a single example of MechanismStandard being used in a human-written file in ModelDB. And if you export hoc from a CellBuilder, you'll get machine generated hoc statements that don't contain the MechanismStandard keyword.

I use the CellBuilder a lot, but when I need to use my own hoc code to modify a parameter in a CellBuilder-managed model, I first make sure that the CellBuilder's Continuous Create button is NOT checked*--this ensures that the CellBuilder will not overwrite anything I do with hoc. And I make the parameter change by executing garden-variety hoc statements like
dend[3] gbar_kd(0.3) = 0.008
(assuming that gbar is a range variable). That way I have explicit control over which instance of the kd mechanism is affected.

*--This is doable from hoc. Consider this example: an init.hoc file that starts with the following statements:

Code: Select all

load_file("nrngui.hoc")
load_file("mycell.ses") // recreates a CellBuilder that contains my model cell specification
// the CellBuilder comes up with "Continuous create" ON, so it creates the sections,
// attaches them to each other, assigns geometry and biophys properties etc.
// next thing I should do is turn Continuous create OFF
CellBuild[0].continuous = 0 // this turns Continuous create OFF
// now I can write code that changes the parameters in any sections that I like
// without concern that the CellBuilder might undo these customizations

[hallockk]

MechanismStandard was designed as a tool to use for building other tools--specifically, for constructing graphical user interfaces such as the Cell Builder. As such, it has certain properties that are particularly useful in that context (i.e. machine-generated code that is written to ses files), but which may be impediments or have undesired side-effects in other contexts, such as user-written code. You just ran into such a case. I bet you a dollars to donuts you won't find a single example of MechanismStandard being used in a human-written file in ModelDB. And if you export hoc from a CellBuilder, you'll get machine generated hoc statements that don't contain the MechanismStandard keyword.

Do you have something you would recommend instead of MechanismStandard? For the near future, my model will remain as simple as what I posted above.

And if you export hoc from a CellBuilder, you'll get machine generated hoc statements that don't contain the MechanismStandard keyword.

I exported hoc from CellBuilder, but the file won't open; instead, I get the following error.

nrniv: lambda_f undefined function
in C:/nrn71/Hallock/LoneLead12.hoc near line 205
celldef()
^
lambda_f(100 )
geom_nseg( )
celldef( )

*--This is doable from hoc.

Thanks for the code.

The GUI is nice for demonstration purposes because it provides a familiar interface. Is there a way change parameters using the GUI without it overwriting the code? Or will I have to change parameters manually?

Thanks for your help.

Kevin

[ted]

I exported hoc from CellBuilder, but the file won't open; instead, I get the following error.

nrniv: lambda_f undefined function
. . .
C:/nrn71/Hallock/LoneLead12.hoc

I see what's happening. You're using MSWin. When you double click on a hoc file, nrniv starts, and loads the hoc file that you clicked on. nrniv is the bare NEURON executable. It's smart enough to discover and load a nrnmech.dll file, if one is present in the folder where your hoc file sits. So far, so good.

But nrniv is baffled if it runs into a procedure or function that it doesn't know about. Many of NEURON's special capabilities come from code that is not compiled into it, but rather written in a "library" of hoc files (see
Secrets of NEURON: the hoc library
in the Hot tips area of the NEURON Forum). The lambda_f function is just one tiny part of this library. If you are writing your own hoc code, you'll want to insert
load_file("nrngui.hoc")
as the first statement in your "main" program file. That will make things much easier for you.

UNIX/Linux or OS X user's can get away without this load_file statement because they can make NEURON start, load its hoc library, and then read their own hoc file, by typing
nrngui myprogram.hoc
but if they're interested in writing code that will work across platforms--and they should, since most NEURON users work under MSWin!--they'll include
load_file("nrngui.hoc")
in their code.

A minor point: some GUI tools automatically print a
load_file("nrngui.hoc")
statement at the beginning of their ses files just to make sure that the hoc library's functions will be available to them. But don't count on this--it never* hurts to put load_file("nrngui.hoc") at the start of a program.

*--well, I haven't ever seen it cause problems.