record current during VClamp family

[thats_karlo]

Dear Firends,

I write a *.hoc code for my compartmental model. that works well!

From "Neuron main menu"-->"Tools"-->"point proccesses"-->"manager" i chose "Electrode". Then from I/V clamp Electrode, i enter my numbers in condition, test and return level. then in "VClamp falimy" i click on "vary Test level".

During "vary test level", that i see different membrane potential for my section, i put electrode in soma, i. like to recorde a current for every level of membrane potential.
I can do that from "Graph"-->current axis, with keep line option, and save all trace. but i'm sure that's not a efficient way!

Could you give me a suggestion? is it possible to write some code and add to *.hoc file, that in result every trace automaticaly save in separate data file?

await for your reply!

Yours,
Karlo

[thats_karlo]

Hi,

Is my question clear or not?

[Raj]

You might want to read up on the vector record method.

After recording the vector you can save it to file with the vector class' fprint method.

A good place to add these might be in a personalized version of the init procedure, see example below. I think it is in chapter 8 of the NEURON book that you can find more information on how to do this.

Code: Select all

proc init() {
// start recording here, but first try a print statement to verify 
// that every run brings you here.
finitialize(v_init) //This is absolutely needed do not delete
// print vector to file here
}

[thats_karlo]

Hi,
I try the following code, to record maximum and minimum of a current. i want to change some parametrs from sh windows, oc> , and run my code. The code is

Code: Select all

load_file("nrngui.hoc")
create soma
access soma
  //define geometry
  insert hh
  gnabar_hh=0.1
 // define a  IClamp

objref recI
recI= new Vector()

proc initialize(){
      finitialize(-70)
      fcurrent()
      recI.record(&soma.ina(0.5))
      printf("max amplitude %g  and min amplitude %g \n",recI.max(),recI.min())
 }

proc integrate(){
        while(t<tstop){
               fadvance()
               }
 }

proc go(){
initialize()
integrate()
}

when i run this program , in sh windows i type oc> go() result for max , and min always is zero,

unfortunatly, i con not find my mistake. i will be appriciate if you help me to find out!

Regards,
karlo

[ted]

A good place to add these might be in a personalized version of the init procedure

Probably not. Vector recording falls into the category that one might call "instrumentation
code," but initialization belongs to the category of "simulation control code." Development
and debugging are easiest if these categories are kept separate from each other. Also,
unlike initialization, which might be done several times in a single session if one is
engaged in interactive model exploration or just running off a whole familiy of simulations,
there is no reason to assert
vectorname.record(&varname)
at every initialization. Vector record statements only need to be executed once. This can
be at top level (outside any object or proc or func) or it can be done by code that lies
within some object, proc or func. The sole constraint is that the variable that is to be
recorded must already exist.

The standard run system takes care of re-initializing Vector recording when stdinit() is
called (or when run() is called, or when the RunControl panel's Init or Init & Run button
is clicked on).

The init() procedure should be reserved for code that is necessary to ensure that
model state variables are properly initialized. Details of how NEURON's standard run
system deals with initialization are provided in chapter 8 of The NEURON Book, as well
as several examples of custom initializations and how they can be implemented by
writing one's own custom proc init().

[ted]

I try the following code, to record maximum and minimum of a current.
. . .
when i run this program , in sh windows i type oc> go() result for max , and min always is zero,

Hint: after you execute go(), type
recI.size()
at the oc> prompt. What answer do you get?

[thats_karlo]

Hi ted,

thanks for fast reply! answer to your last question is

oc>go()

max amplitude 0 min amplitude 0

oc>recI.size()
2002

[ted]

2002? I don't think so. tstop is only 5 and dt is 0.025, so a simulation run will generate only
200 values of soma.ina. However, the code you posted won't capture any of them--
recI.size() will report a value of 0 because nothing will be recorded to recI. Vector record()
must be asserted before finitialize() is called. But even your code did record soma.ina,
look at where it checks for recI's max and min--before the simulation happens. So recI is
empty when it is tested for max and min.

Here's an example of how to do it properly:

Code: Select all

load_file("nrngui.hoc")
create soma
access soma
  //define geometry
  insert hh
  gnabar_hh=0.1
 // define a  IClamp

objref recI
recI= new Vector()
recI.record(&soma.ina(0.5))

proc go(){
run()
printf("max amplitude %g  and min amplitude %g \n",recI.max(),recI.min())
}

Notice where the Vector record statement is located--at the top level, outside of any
proc or func or object. Also notice that there is no need to mess around with your own
proc initialize() or to cobble up your own proc integrat(). Just use the stuff that is built
into NEURON's standard run system.
load_file("nrngui.hoc")
makes NEURON load the standard run system, so why not use it? proc run(), which is
part of the standard run system, takes care of initialization and simulation execution for
you.

[Raj]

A good place to add these might be in a personalized version of the init procedure

Probably not. Vector recording falls into the category that one might call "instrumentation
code," but initialization belongs to the category of "simulation control code."

Agreed, but if you want to use an automatic scan from the GUI for printing data to external output, I see only two options: hooking into the standard run system at an (in)appropriate level or deriving your own GUI component from the already existing one. For code that is ment to be used for longer period, that is basically all code except code entered from the command line I would prefer the latter, provided the GUI component is not so complex that analyzing its internals takes more time then writing your own code. For command line exploration overwriting the run function might be a better option.

[ted]

The chief problem with altering the standard run system is loss of interoperability.
It's much too easy to end up with code that is hard to understand and difficult to use--
doesn't work properly with tools such as Variable Step Control, Model View,
Multiple Run Fitter, etc..

if you want to use an automatic scan from the GUI for printing data to external output, I see only two options: hooking into the standard run system at an (in)appropriate level or deriving your own GUI component from the already existing one.

A Vector record statement is equivalent to your first option, i.e. hooking into into the
standard run system. It ensures that the specified variable will be recorded to the
specified Vector during simulation execution.

For code that is ment to be used for longer period, that is basically all code except code entered from the command line I would prefer the latter, provided the GUI component is not so complex that analyzing its internals takes more time then writing your own code. For command line exploration overwriting the run function might be a better option.

proc go() provides a command line way to launch a simulation and report results (print
to a file, etc.) without overwriting proc run(). One can also exploit go() via a GUI tool.
This

Code: Select all

xpanel("Go")
xbutton("Go", "go()")
xpanel(200, 200)

creates a panel that contains a button labeled "Go"; clicking on that button executes
proc go(). If the panel is in an inconvenient location, just drag it to a preferred spot and
then use the PFWM to save it to a session file. The session file will contain an xpanel
statement with the "correct coordinates." Here is an example of such a session file:

Code: Select all

objectvar save_window_, rvp_
objectvar scene_vector_[2]
objectvar ocbox_, ocbox_list_, scene_, scene_list_
{ocbox_list_ = new List()  scene_list_ = new List()}
{
xpanel("Custom run control", 0)
xbutton("Init & Run","run()")
xpanel(10,382)
}
objectvar scene_vector_[1]
{doNotify()}

The second xpanel statement contains the desired coordinates; these can be manually
inserted into one's own hoc code.

[Raj]

The original question referred to using the "VClamp family" GUI for producing output to file. My comment is entirely aimed at such a situation: You have a GUI-component that varies the parameters you are interested in and prints the result to screen. You are satisfied with the result and you want to save the results to file. It seems undesirable to write a large amount of new (GUI) code just because you want to export a visible and easily reproducible result to file. For this specific purpose it would therefore be ideal if the standard run system would provide a post processing/output procedure that can be savely overwritten by the user.

I agree that there are risks to using the standard run system in the way I proposed in previous postings, but during model exploration it might still be a good option provided the standard run system modification is not included in the main code ment for reuse later on in the project. You might, however, still want to keep it in a simulation specific session based hoc-file so it will be available for inspection later on in the project. Admittedly these type of solutions do not fit in the "Getting Started" character of this section of the forum.

[ted]

As this discussion shows, there are many different possible strategies for accomplishing
a particular task. For this task

You have a GUI-component that varies the parameters you are interested in and prints the result to screen. You are satisfied with the result and you want to save the results to file. It seems undesirable to write a large amount of new (GUI) code just because you want to export a visible and easily reproducible result to file.

it is certainly possible to modify simulation flow control so that every "run" includes
user-specified postprocessing. The standard run system's proc run() is

Code: Select all

proc run() {
  stdinit()
  continuerun(tstop)
}

So one could just make a file called postproc.hoc that contains this code

Code: Select all

proc postprocess() {
  // statements that accomplish whatever postprocessing is desired
}

proc run() {
  stdinit()
  continuerun(tstop)
  postprocess()
}

and load it _after_ the load_file("nrngui.hoc") (or after the load_file("noload.hoc"), if
you're avoiding the GUI). Every run() (or click on the Init & Run button) will launch a
simulation that is followed immediately by whatever proc postprocess() does.

However, in my opinion it's safer--and doesn't involve much GUI programming--to leave
run() unmodified and do this instead:

Code: Select all

proc postprocess() {
  // statements that accomplish whatever postprocessing is desired
}

proc go() {
  run()
  postprocess()
}

xpanel("Go")
xbutton("Go", "go()")
xpanel(200, 200)

Or even this

Code: Select all

proc postprocess() {
  // statements that accomplish whatever postprocessing is desired
}

xpanel("Run & Postprocess")
xbutton("Run & Postprocess", "run() postprocess()")
xpanel(200, 200)

(although this latter approach doesn't give one the option of typing go() at the oc>
prompt).

I agree that there are risks to using the standard run system in the way I proposed in previous postings

Here's the chief reason for my aversion to messing with the run time system for any
purpose other than custom initialization: all too often, the result is a complex, idiosyncratic
intermingling of model specification, data analysis, and user interface code with
simulation control code. Such programs are hard to maintain and debug, tend to be
unusable by anyone other than the original developer, often can't be properly examined
or exercised by NEURON's own graphical tools, and are an endless source of confusion
for those who encounter such code in ModelDB or elsewhere.