www.neuron.yale.edu

Thanks for the support, Ted.

I took the revMRGaxon.hoc file and placed it in my directory and made the necessary change to initxstim.hoc, however the problem still persists.

I went back and repeated all of my steps from my last post with a clean copy of the extracellular stimulation code, however I am still getting the same issue as before (extracellular stim off, but plot of v(.5) shows a spike).

Are there any changes that have to be made to axnode.mod for this to work?

Igoy wrote:Are there any changes that have to be made to axnode.mod for this to work?

No.

To advise you further on the problem you are having, I will have to be able to reproduce it for myself. Please zip up the hoc, mod, and ses files you are using (no .c or .o or .dll files, and no i686 or x86_64 subdirectories!) and send that to
ted dot carnevale at yale dot edu

The problem is that your model's resting potential is -80 mV, but you (actually, the RunControl panel that is recreated by rigc.ses) are initializing it to -65 mV, and that triggers the unwanted spike. An easy mistake to make. You can discover the resting potential of the model simply by running a simulation for a "long" time, say 100 ms or whatever it takes for membrane potential to settle down.

The easiest way to fix this is to insert the statement
v_init = -80 // MRGaxon model's resting potential
into your initxstim.hoc file, right after the statement that loads rigc.ses.

Ordinarily I like to keep related bits of code close to each other, because it helps simplify development and debugging. By this logic, one might ask

why not insert the v_init = -80 statement right after load_file("revMRGaxon.hoc"), or better yet, make it the last statement in revMRGaxon.hoc?

The answer, of course, is that when rigc.ses is loaded later, the value of v_init in rigc.ses supercedes any previously assigned value.

"Well, why not revise rigc.ses so it gives v_init the correct value?"

You could do that, but that only buries the cure in a place where it will too easily be forgotten--users generally don't think about peering inside ses files, let alone editing them. Yes, I know you're an exception, but if you share your code with someone else, and they find they "can't" reuse it with a different model cell, well, that's a problem, right?

An alternative is to insert a statement that defines a symbolic constant V_INIT right after the statement that reads the model specification, i.e. do this
load_file("revMRGaxon.hoc")
V_INIT = -80 // resting potential for this model; assign to v_init below
and then change the statement
load_file("rigc.ses")
to
load_file("rigc.ses") // recreates a RunControl panel etc.
v_init = V_INIT // ensure that v_init has correct value regardless of whatever was saved to rigc.ses

The resulting source code reminds the user to make sure that V_INIT has the correct value.
Furthermore, this value is to be assigned right after the statement that reads the model specification, which is where it will be readily seen and, one hopes, will prompt the proper action by anyone who subsequently uses this code with a different model cell.

Reminder to one and all: it is difficult if not impossible to write code that cannot be abused or misused deliberately or accidentally. The best one can do is write understandable code, and include explanatory comments, and hope somebody else reads them.

Thanks, Ted - that did the trick. I've spent some more time creating additional plots and becoming familiar with the IO operations provided by NEURON. That was fun.

Now I'm stuck again...I am following instructions from viewtopic.php?f=8&t=1814&start=15#p8670 post to modify xtra.mod for incorporating a second stimulating electrodes.

When I make the changes stated on that post to xtra.mod, along with changing "GLOBAL is" to "GLOBAL is1, is2", I get the following errors after compiling the *mod files and running "nrngui initxstim.hoc":
Note - the only change I do not make is rename to xtra2.mod or change the mechanism name (my code is versioned). If I undo my changes, these errors go away and the model behaves as it should. I have not modified any other file.

I can't seem to figure out why is_xtra is undefined. The mechanism is still inserted into my model. I assume the syntax error is a result of is_xtra being undefined. Any suggestions?

Nevermind to that - a little digging into the source code helped me figure out that the e_extracellular and i_membrane pointers were dangling. Just had to change all calls to is_xtra to is1_xtra and so on. This is really fun.

Now an alternate question that I am facing. I'd like to include the fsin mechanism previously provided elsewhere. I added the following to my stim.hoc file:
I also read in the xtra.mod header that I need to conver fieldrec to a proc, so I did this:
Since is2_extra is a GLOBAL, and I have included the superposition code to xtra.mod and changed fieldrec to a proc, I was expecting to see a change in the states (I figured out how to create custom plots, yay) and the voltage due to the oscillating input.

However, that is not at all the case. The system solves as it normally would and doesn't provide any output for debugging why the fsin input is not working for my second stimulation electrode. Any suggestions on what I am missing/where to look?

First a comment and a question, just in case it is possible to avoid unnecessary complications.

The comment: if electrode 1 passes current i1(t) and electrode 2 passes current i2(t), and there is some constant k such that
i1(t) + k*i2(t) = 0
then there is no need to modify xtra.mod.
The question: is there such a constant?

Turns out I made a very foolish mistake and didn't initialize the fsin object properly - thanks for pointing me in the right direction, Ted! That worked and both stimuli are generated.

Question - I am setting pointer x from Fsin to is2_xtra. That works, and I see the effects of both stimuli on the voltage plot (either a spike or oscillating potential). However, it appears that the oscillating stimulus is attached to node[0]. What is the syntax for attaching it to a different node, say node[18]?

My current approach involves using a forall loop and checking for the node that is being iterated over. Once I reach node[18], which is done by creating a string called "node[18]" and using "if(issection(nodestring))", I call "setpointer fs.x, is2_xtra" - however this shows the same voltage plot, suggesting the oscillating stimulus is still attached to node[0].

To determine what section the point process was attached to, I used get_loc. I used the following procedure found elsewhere on the forums to determine which section the point process was attached too, and it shows that the point process is attached to node[18].
Any guiding hints/suggestions appreciated!

To determine what section the point process was attached to

First please note that, since NEURON can be expanded by adding user-written code, the only "names" that have fixed meaning are keywords that are intrinsic to NEURON "as it comes out of the box." When you refer to Fsin you know what you mean because you have the code that implements it. However, I cannot assume that it's the same as something I may have written in the past, not least because I may have reused that name to refer to different things at different times. Or maybe you picked up something that Joe Schmegegi wrote while he was a postdoc at the Institute for Irreproducible Results in Lower Slobbovia 20 years ago.

Which means that anything I write here without seeing your code is just a guess.

The Fsin that I wrote about 6 years ago merely adds the function
amp * sin(2*PI*(t-del)*f*(0.001))
to NEURON. It has a POINTER variable called x that can be used, via a setpointer statement or the equivalent Python syntax, to any other variable in NEURON.

It happens to be packaged inside a mod file that defines a POINT_PROCESS because that is a convenient way to add new functions to NEURON; however, it is not a current source (note that the NEURON block of the mod file has no USEION foo WRITE ifoo, or NONSPECIFIC_CURRENT i, statement). It really doesn't matter to which compartment in which section you attach an instance of this point process. All that matters is the fact that it is linked to some other variable, so it can serve as a forcing function that drives that variable to change during a simulation.

Only one setpointer statement is necessary to use Fsin to drive the xtra mechanism's is variable, because the latter is a GLOBAL variable, i.e. has the same value in all segments of all sections into which xtra has been inserted. I do not know anything about what you did to xtra to implement your second stimulus current; if that variable is a GLOBAL and you're driving it with Fsin's x POINTER variable, a single setpointer statement is all that is needed to ensure that all sections see the same value of your second stimulus current.

I think I have the proper edits made for multiple electrodes and assigning the Fsin to the GLOBAL of xtra. May I send you my code, which I have commented extensively, to be sure?

Sure, zip up whatever hoc, mod, and ses files are necessary to reproduce the issue and send it to
ted dot carnevale at yale dot edu