Single, myelinated axon with several nodes and internodes

[ted]

One last point: it looks like you are developing models inside NEURON's installation tree. This is not a good idea. If and when you install a new version of NEURON, you're going to use NEURON's own uninstaller to get rid of the old version, and one of the things it is going to try to do is delete the old installation tree. And there goes all your work. Avoid future pain--make a special directory somewhere else, and put your development stuff in subdirectories of that. What's wrong with making a new directory in the "home" directory that MSWin sets up for you?

[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.

Is there a way to change this from the GUI? Given the simplicity of my model, I would be surprised if it required custom coding. I only have two HH nodes, one 10-section axon, and one 1-section axon. I'm trying to use the GUI as much as possible since I work with a number of people who don't do simulations. GUIs are great for interdisciplinary research.

*--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

I don't know if you can edit your post,
<< I can indeed--and I can edit yours too -- NTC >>
but just in case somebody wants to use this code in the future, "continuous" was missing a "u" in the original posting (which I added above). With the "u" added, the code worked great.
<< As the saying goes, trust but verify. Thanks, I fixed it. -- NTC >>

[hallockk]

One last point: it looks like you are developing models inside NEURON's installation tree. This is not a good idea. If and when you install a new version of NEURON, you're going to use NEURON's own uninstaller to get rid of the old version, and one of the things it is going to try to do is delete the old installation tree. And there goes all your work. Avoid future pain--make a special directory somewhere else, and put your development stuff in subdirectories of that. What's wrong with making a new directory in the "home" directory that MSWin sets up for you?

Thanks for pointing that out! I think I put that folder there because it made saving files faster. I've moved it.

[ted]

Under MSWin, I put a shortcut to the root directory of my "NEURON deveopment tree" on the desktop so it's always easy to find. Also on the Desktop I put copies of the most frequently-used items from the NEURON Program Group (nrngui, neurondemo, the neuron with python thing (whatever it's called), modlunit, mknrndll, rxvt.sh, and Documentation). Or, if I'm dealing with a laptop that has a small display, I make a NEURON folder on the desktop and put them in there.

[ted]

Is there a way to change this from the GUI? Given the simplicity of my model, I would be surprised if it required custom coding. I only have two HH nodes, one 10-section axon, and one 1-section axon. I'm trying to use the GUI as much as possible since I work with a number of people who don't do simulations.

If you only want to modify certain parameters in one particular section, with just a bit of code you could create a small "window" (an "xpanel" in NEURONspeak) that offers controls that affect just those parameters in that section. But you might find it more convenient to use the "distributed mechanism viewer." To find a brief discussion of this on the Forum, use the Forum's Search field to look for
distributed mechanism viewer
One of the hits will be a post by me from 2005.

Make sure that the CellBuilder's "Continuous create" is OFF _before_ you bring up a distributed mechanism viewer. Otherwise there could be a conflict between the params specified by the CellBuilder and the params specified by the "distributed mechanism viewer". Such conflicts destroy the conceptual clarity that is essential in computational modeling--it'll be much harder for you to be sure that there is a close match between the computational model in the computer, and the conceptual model that is in your head.

This is why I like to combine hoc and the GUI. Here's how I proceed:

1. Use the CellBuilder to create the specification of the model cell.
Save this to a ses file by itself, with "Continuous create" ON, called cell.ses
NEURON Main Menu / File / save session
I can now use this ses file as an inexhaustible culture of cloned neurons.

2. Use the GUI to construct a custom user interface: RunControl; graphs of voltage, current, conductance, concentration, gating states, whatever; signal sources like IClamps, SEClamps, AlphaSynapses, etc.
Save just these tools to a separate ses file called rig.ses (from "experimental rig").
Note that rig.ses does NOT include the CellBuilder.
That allows me to use the same rig with different model cells (as long as none of the graphs or signal sources refers to a section that doesn't exist).

3. Write a hoc file called init.hoc that contains these statements:

Code: Select all

load_file("nrngui.hoc")
load_file("cell.ses")
// uncomment the next statement if it will be necessary to change the model's params
// from those specified by the CellBuilder
// CellBuild[0].continuous = 0
load_file("rig.ses")

Double clicking on init.hoc brings up the CellBuilder and the virtual experimental rig.

4. If I need to make "posttranslational changes" to the model cell (change the model's parameters from the specification contained in the CellBuilder), I do one of the following things:
--write a hoc file that does what I need
or
--bring up a "distributed mechanism viewer" and select the section that I want to tweak. After I get the parameter panel for that section, close the "distributed mechanism viewer". Finally, save the parameter panel BY ITSELF to a new ses file called something mnemonic (maybe "dend28params.ses" if the section name was dend28). If you don't know how to do this, read about the Print & File Window Manager in the WWW site's FAQ list
http://www.neuron.yale.edu/neuron/faq/general-questions
The particular document you need is in answer to the question
"How do I print a hard copy of a NEURON window?"

5. Revise init.hoc by appending the statement
load_file("customparams.hoc")
or
load_file("dend28params.ses")
to the end of the file. That way, when NEURON processes init.hoc, the last thing it does is to execute the hoc statements that make your custom parameter changes, or that recreate the parameter panel for your section of particular interest. And since this happens long after Continuous create is turned off, there won't be any conflict between your customizations and the CellBuilder.


Here's a small hint that may make GUI management of your model easier: control the shape of your model cell so that it's easier to select sections of interest with other GUI tools. A lot of people lay out the sections of their axon models in a straight line. It's better to use a zigzag layout. Go to the Topology page of the CellBuilder and click on the Reposition button. Then click near the junction of two sections and drag it up or down (or to the side if your axon is laid out vertically). Repeat at each connection point, alternating the displacement so you end up with something like
/\/\/\/
Also, just because nodes are short, that doesn't mean you have to draw them with short line segments in the CellBuilder. Make every section just as long as necessary for clarity and convenience. The actual anatomical lengths are controlled by what you put on the Geometry page, not by the appearance in the CellBuilder. However, the appearance in the CellBuilder can make it easier or more difficult for you to use other tools like the PointProcessManager, or the distributed mechanism viewer.

GUIs are great for interdisciplinary research.

Also good for exploratory simulation, and--done properly--has the big advantage of helping to ensure a close match between what's in the computer and what's in the user's head.

[hallockk]

Thanks for the advice!

I was reading through one of the examples from ModelDB (I think) and it expressed a concern about "end and stimulation" effects that occur in shorter neurons so the authors used at least twelve nodes and internodes in their simulation. How serious is this problem? Would my simulation be better if I flanked my multiple-compartment axon section with 6+ node-internode pairs on either side of it?

Out of curiosity, I put together

Lead-node1-internode1-node2-internode2-node3-internode3-node4-internode4-node5-internode5-node6-internode6-node7-internode7

to see what the results were and they don't make any sense. The first node appears to fire just fine, but later ones don't refresh the voltage. It decreases as it goes done the line until it ends. I may have made a mistake in the model, which I'll go back and hunt for, but it made me wonder what the best computational controls are for NEURON models. Is there a method you recommend for doing a baseline test of a model to make certain each of its parts are functioning correctly before the computational question is investigated?

Thanks again!

Kevin

[ted]

I was reading through one of the examples from ModelDB (I think) and it expressed a concern about "end and stimulation" effects that occur in shorter neurons

Experimentalists and theoreticians have long known the importance of boundary conditions. Consider this gedankenexperiment: imagine a very long cylindrical axon with an intracellular stimulating electrode near the midpoint of its length. Measure the input resistance of the axon at that point and call it R1. Next, tie off the axon just to the left of the stimulating electrode, so that no injected current can spread into the left half of the axon. Measure the input resistance again and call it R2. Result: R2 will be close to twice as large as R1 (input resistance is higher near a sealed end than in the middle of the axon). Why?

Repeat the experiment, but this time instead of measuring the input resistance, determine the amplitude of a brief (<1ms) current pulse that is just big enough to elicit a spike before (A1) and after (A2) tying off the left half of the axon. Result: A1 will be close to twice as large as A2 (it takes more current to elicit a spike when the stimulus is applied at the midpoint of the axon, than when it is applied at or near a sealed end). Why?

Final gedankenexperiment: Given a long axon with both ends sealed, stimulate the long axon at one end with a brief current pulse (make the current pulse 2 times larger than threshold, so you don't fry the axon). Observe the amplitude of the spike as it propagates toward the other end. Result: as the spike approaches the sealed end, its amplitude increases. Why?

Would my simulation be better

Do you really mean "simulation" or do you mean "model", and if you mean "model", do you mean "conceptual model" or "computational model"? And what do you mean by "better"?

If you really mean "simulation" then the criterion for "goodness of result" is how small you can make the numerical error that results from approximating a continuous physical system with a set of equations that really describe a system that is discretized in time and space, and then grinding out finite precison (hence approximate) solutions to those equations.

If you mean "would my computational model be better", then the question is whether it is a close match to your conceptual model. If your conceptual model has a particular set of anatomical and biophysical properties, and you have a particular pathophysiological mechanism in mind (i.e. a particular perturbation of anatomical and/or biophysical properties), then the criterion of "goodness" is the degree to which your computational model implements the same anatomical and biophysical properties in the "normal" and "diseased" (or "control" and "treated") states.

If you mean "what would make my conceptual model better" then the first question is "what is the purpose of your conceptual model" and the second is "what confounds might interfere with this purpose, and how do you eliminate or reduce them".

It's best to start a modeling project by focussing on the conceptual model, because the conceptual model is the thing that is closest to your hypothesis, and testing your hypothesis should be what drives your efforts.

So you want to test the effects of some focal "lesion" (perturbation of anatomy or biophysics of a node or internode) on spike propagation along a myelinated axon. The axon should be long enough that the lesion is located at a point where boundary conditions at either end won't influence the effect of the lesion on spike propagation. You don't want it to be too long, because simulations will be slowed and you'll waste time. It mustn't be too short either. You'll need to discover the necessary length by assuming a particular set of properties for nodes and internodes, making a long axon model, with "normal" properties, that is stimulated at one end with a brief current that is 2*threshold (standard practice by experimentalists) and seeing how far the spike has to propagate before the conduction velocity and peak spike amplitude settle down to within some percentage of being constant. Then you'll be able to decide just how many nodes & internodes are needed, and proceed to investigate the effects of "lesions".

A separate issue is what values to use for nseg, the spatial discretization parameter.

Do you need to study more than one particular set of anatomical parameters (node and internode lengths and diameters)?

Lead-node1-internode1-node2-internode2-node3-internode3-node4-internode4-node5-internode5-node6-internode6-node7-internode7

to see what the results were and they don't make any sense. The first node appears to fire just fine, but later ones don't refresh the voltage. It decreases as it goes done the line until it ends. I may have made a mistake in the model, which I'll go back and hunt for, but it made me wonder what the best computational controls are for NEURON models. Is there a method you recommend for doing a baseline test of a model to make certain each of its parts are functioning correctly before the computational question is investigated?

The first question is always whether there is a close match between conceptual model and computational implementation. When in doubt, use the Model View tool to verify that biophysical and anatomical properties are as you expected--see
http://www.neuron.yale.edu/neuron/stati ... p2004.html

When a model contains a great deal of stereotypy, as axon models often do, hoc code can be much more practical than using the CellBuilder. Keep in mind the fact that, if only a few parameters are to be varied, it is easy to build a custom GUI interface that allows people who have no knowledge of programming to change params and run simulations.

[hallockk]

Thanks for all your help!

I have a model that is behaving as I'd expect in terms of action potential propagation. When I open the GUI to append certain sections to my Voltage Axis plot (using the Plot What? menu choice), it doesn't show me all of the sections that are present. For example, I'm allowed to choose node[0], node[1], node[2], node[3], node[4], node[5], node[6], and node[12], but not node[7], node[8], node[9], node[10] or node[11].

This limitation is in place for all of the different sections; the pattern seems to be that [0]-[6] and the last section are included on the list.

Thanks,

Kevin

[ted]

They exist, they just aren't displayed in the list. Use the GUI to construct a name that contains the "basename" that you need (e.g. node[0]), then click in the edit field and change the numeric value of the "index" to whatever you like.

[hallockk]

They exist, they just aren't displayed in the list. Use the GUI to construct a name that contains the "basename" that you need (e.g. node[0]), then click in the edit field and change the numeric value of the "index" to whatever you like.

Thanks.

Is there a good place to read up on the different types of tobj's? The GUI sometimes uses MechanismStandard while it uses FakeMechStan some other times. I'd like to learn if any additional options exist as well.

Kevin

[ted]

Is there a good place to read up on the different types of tobj's?

The question as posed means nothing because tobj is not a hoc keyword, so there are no "different types of tobj" in hoc. However, the context of the question suggests the following logical inferences. If the string "tobj" appears in computer generated hoc code, it does so because the procedure responsible for generating that code was written by a human programmer. That programmer probably used "tobj" as the name of an objref that points (but only temporarily) to an instance of some object class.

The GUI sometimes uses MechanismStandard while it uses FakeMechStan some other times. I'd like to learn if any additional options exist as well.

Good question--I don't know. You might try looking at the Programmer's Reference documentation of these two keywords and browsing neighboring entries or following any links to other entries that you discover. A word of caution, though: stay away from these unless you need to do sophisticated development of new GUI tools in hoc. Indeed, since the advent of Python as an alternative interpreter for NEURON it is probably best to use Python for nontrivial new GUI tool development--it's a more powerful programming language than hoc, and the associated libraries of tools for GUI development are more extensive and powerful than hoc's InterViews. Furthermore, they're also under active development, unlike InterViews which is "mature" (read "maintenance, and maybe some refinements here or there, but no big new advances likely").

[hallockk]

Indeed, since the advent of Python as an alternative interpreter for NEURON it is probably best to use Python

I built a model in Python. It is a single axon with a soma-node-internode-node-internode-etc. pattern. There are twenty-three nodes and twenty-four internodes assembled using the CellBuilder GUI. Everything is 1 micron in diamater, with the soma and nodes 1 micron in length and the internodes fifty microns in length. For Biophysics, soma and nodes each have Ra, cm, and hh at default values and the internodes have Ra, cm, and pas at default values. (The defaults are being used to try to show the model will behave well before I apply experimentally determined values.)

I attached an IClamp to one end and no matter how I vary the input current, I cannot get my model to repeatedly spike; any suggestions about what I'm doing wrong?

Thanks.

[ted]

any suggestions about what I'm doing wrong?

Well, for starters, you're quoting me out of context. My original statement was
"Indeed, since the advent of Python as an alternative interpreter for NEURON it is probably best to use Python for nontrivial new GUI tool development"

For development of new models, I'd suggest using whatever you're most comfortable with. If you know Python, by all means use it.

WRT your question--
Unexpected outcomes are the rule rather than the exception in computational modeling--unless one sticks with "safe" models, i.e. so simple that it's easy to guess what they will do (in which case, why bother?). Unexpected outcomes are certainly more likely to produce new insights than expected ones.

In modeling there are three null hypotheses that one must disprove, in the following order:

1. The computational implementation deviates from the conceptual model. Have you verified that your implementation has the anatomical and biophysical properties that you intended?

2. The simulation parameters that control spatial and temporal discretization are insufficient for good accuracy. Have you verified that nseg and dt are appropriate?

3. Having proven that null hypotheses 1 and 2 are false (i.e. having proven that the implementation is a close match to the conceptual model, and that spatial and temporal discretization are sufficient) the remaining hypothesis is that one's intuition was incorrect (in this case, the intuition that a particular stimulus applied to a particular model would elicit repetitive spiking). The question then is why, and it is an empirical question--to be decided by carrying out computational experiments.

So have you addressed hypotheses 1 and 2?

[hallockk]

WRT your question--
Unexpected outcomes are the rule rather than the exception in computational modeling--unless one sticks with "safe" models, i.e. so simple that it's easy to guess what they will do (in which case, why bother?). Unexpected outcomes are certainly more likely to produce new insights than expected ones.

I agree it would be more interesting, but I have to trust the program and model are well-behaved before I can conclude I've discovered something.

1. The computational implementation deviates from the conceptual model. Have you verified that your implementation has the anatomical and biophysical properties that you intended?

Yes. I've also varied them some to try to get a handle on my lack of action potential generation and propogation; no success yet.

2. The simulation parameters that control spatial and temporal discretization are insufficient for good accuracy. Have you verified that nseg and dt are appropriate?

What's the best way to test this? I increased nseg throughout the model and decreased dt by an order of magnitude and neither changed my lack of propagation.

3. Having proven that null hypotheses 1 and 2 are false (i.e. having proven that the implementation is a close match to the conceptual model, and that spatial and temporal discretization are sufficient) the remaining hypothesis is that one's intuition was incorrect (in this case, the intuition that a particular stimulus applied to a particular model would elicit repetitive spiking). The question then is why, and it is an empirical question--to be decided by carrying out computational experiments.

Is there reason to suspect such a system wouldn't propogate an action potential? Experimentally similar systems behave as I expect they would so although I haven't found an error with #1 and #2, I still suspect one or both of them are contributing to my findings.

Thanks.

[ted]

I have to trust the program and model are well-behaved before I can conclude I've discovered something.

Well put. And even then, most "discoveries" turn out to be "private" i.e. improvements of personal intuition but not worthy of publicatioon.

Have you verified that your implementation has the anatomical and biophysical properties that you intended?

Yes.

Good.

Have you verified that nseg and dt are appropriate?

What's the best way to test this?

Empirically, just as you have done, although you could have used the d_lambda rule.

3. Having proven that null hypotheses 1 and 2 are false (i.e. having proven that the implementation is a close match to the conceptual model, and that spatial and temporal discretization are sufficient) the remaining hypothesis is that one's intuition was incorrect (in this case, the intuition that a particular stimulus applied to a particular model would elicit repetitive spiking). The question then is why, and it is an empirical question--to be decided by carrying out computational experiments.

Is there reason to suspect such a system wouldn't propogate an action potential?

Do you know whether the model parameters are such as to support propagation? Time for some computational experiments.

You already know that an unmyelinated axon with default hh properties and the same diameter as your model will support propagation.

1. Consider an unmyelinated axon in which there are inexcitable zones (internodes) of length Li, alternating with excitable zones (nodes) of length 1 um. Presume initially that the internodal and nodal membranes have identical resting potentials. Intuition suggests that there is a value of Li at which propagation fails. What is this value for an axon with diameter 1 um? This is an empirical question--use a computational model to discover the answer. Verify that the internodal and nodal membrane have identical resting potentials, and if they don't, correct this by setting e_pas equal to the resting potential of a model with uniform hh properties (which is what?). Be sure to use a brief stimulus current, and adjust its amplitude as necessary so that the spike at the stimulated end peaks within ~2-3 ms of the stimulus pulse (so that it isn't spreading down the length of the axon to affect other nodes). You may have to make further adjustments of stimulus amplitude as you adjust Li.

2. Implement myelination of the internodes (how?) and repeat 1, making sure again that the internodal and nodal membrane have identical resting potentials.

3. What if internodal and nodal membrane have different resting potentials? Allow the internodal e_pas to be 1 mV more negative than the resting potential of hh membrane. How does the resulting nonuniformity of membrane resting potential affect spike intiation and propagation along the myelinated axon? Does it increase or decrease the Li at which propagation fails? Make sure that the model has reached its steady state before applying any stimulus to the first node. Try again with internodal e_pas 2 mV more negative than hh membrane resting potential. Finally, what happens if internodal e_pas is 5 mV more negative than the resting potential of hh membrane?

Suggested strategy for choosing nseg: use the d_lambda rule as built into the CellBuilder (for each section set nseg to an odd value such that L/nseg < 0.1*AC length constant at 100 Hz).