I had added the xtra mechanism to the hoc file of the cell. any way now when i did what you said
Actually you did what I _should_ have said (I should have said to insert not just xtra, but also extracellular). Very good.
I see the cause of the problem. This is a tricky one, because the error message
Code: Select all
nrniv: syntax error
in setpointers.hoc near line 9
setpointer im_xtra(x), i_membrane(x)
^
is misleading. The problem isn't in setpointers.hoc, it's in interpxyz.hoc which has a proc grindaway() that tries to iterate over all pt3d data (i.e. anatomical measurements of the form (x,y,z,diam)). The model cell specified by ctty238a.asc does use the pt3d style to define the geometry of the sections that it creates--so far so good--but Sheasby et al. wanted their models to have axons, and the anatomical data they were using didn't include axons. So ctty238a.hoc goes on to make a "synthetic axon" by creating three sections called initseg, narrowr, and axon, whose geometry is specified in terms of L and diam, i.e. the "stylized" method for specifying geometry. Consequently those three sections do NOT have pt3d data associated with them, and that's what trips up grindaway().
The fix is to execute define_shape() before loading setpointers.hoc. The first few lines of initxstim.hoc then become
Code: Select all
load_file("nrngui.hoc")
// load_file("cell.ses")
load_file("ctt3219f.asc")
load_file("ctt3219f.hoc")
forall {
insert extracellular
insert xtra
}
define_shape() // create pt3d data for the stylized sections
load_file("anatscale.hoc") // show xyz scale bars
load_file("interpxyz.hoc") // only interpolates sections that have extracellular
load_file("setpointers.hoc") // automatically calls grindaway() in interpxyz.hoc
. . .
Stylized and pt3d specification of geometry are discussed here
http://www.neuron.yale.edu/neuron/stati ... l#Geometry
and define_shape() is discussed here
http://www.neuron.yale.edu/neuron/stati ... fine_shape
Two more problems remain. One is that rigc.ses and rigxc.ses set up range variable plots over paths that don't exist in the new model cell--they refer to sections with the base name dend, but the new model cell has sections whose base name is dend2 (even if the base names were identical, the shape of the new cell is completely different so the paths that are good for it would probably be quite uninteresting in the new cell). The symptom is that, when the hoc parser reaches a statement that refers to a nonexistent section, NEURON emits an error message about a nonexistent section (finally a helpful error message!) and halts. The quickest fix is to edit these two ses files, identifying the code blocks that set up the windows whose graphs refer to nonexistent sections, comment them out, execute initxstim.hoc again, use the NEURON Main Menu toolbar to bring up a new shape plot, use that shape plot to set up the range variable plots that are of interest, and save new session files. This is a little tricky because it involves using the Print & File Window Manager to select which elements of the GUI should be saved to rigc.ses and which should be saved to rigxc.ses.
Anyway, I have now taken care of that and will email you three new files
xinitxstim.hoc
xrigc.ses
xrigxc.ses
xrigc.ses is an updated version of rigc.ses--it uses the latest version of the RunControl panel, and creates one more tool for launching simulations--the "Movie Run" tool, which ensures that space plots are updated on each fadvance() and thus makes them evolve more smoothly in time.
I gave the new ses files new names so I wouldn't confuse them with the originals; ditto for the new hoc file (also made corresponding changes to the hoc files's load_file() statements). Now double clicking on xinitxstim.hoc, or executing
nrngui xinitxstim.hoc
should bring up the model, and clicking on the Init & Run button should launch a simulation.
Finally, the second problem mentioned above: this particular cell model has a few "issues" of its own. The first is that it does not initialize to steady state. That may be partly because of how its mod files are initialized, but I suspect it has more to do with the fact that the model includes calcium accumulation. Ion accumulation mechanisms often have very slow dynamics, and for some reason or other people tend to be careless about initializing them. If you are serious about using these models in your work, you may want to fix this problem. It would be best to discuss this new question in the
Adding new mechanisms and functions to NEURON
viewforum.php?f=16
area of the forum.