Built in vs user compiled mechanisms

[bqrosen]

I'm learning to write my own mechanisms and while attempting to isolate a problem in one I found this apparent paradox. When using Exp2syn my test simulation runs as expected, but when using a self-compiled mechanism (testgaba) it doesn't. The self-compiled mechanism is Exp2syn copy and pasted, with just the the name of the mechanism changed (the POINT_PROCESS line of the NEURON block). No error occurs but the simulation runs as if the mechanism is not there. The test simulation also uses another self compiled mechanism (myleak) which works in both cases. I am running Neuron 7.1 on Mac OSX 10.6.2.

I don't understand why one would work and the other wouldn't. Is there some intrinsic difference between built in and user compiled mechanisms?

Thanks in advance.

This is the .hoc code I am using:

create soma
access soma
objref gaba,presyn,input
soma {

soma.nseg = 1
soma.diam = 100 // micrometer
soma.L = 100 // micrometer
soma.Ra = 120 // ohm-cm
soma.cm = .01 // uF/cm2

// toggle between testgaba and Exp2Syn
gaba = new testgaba(0.5)
//gaba = new Exp2Syn(0.5)

gaba.tau1 = 5.6
gaba.tau2 = 0.285
gaba.e = -95



insert myleak
e_myleak = -70
g_myleak = .000001
}

presyn = new NetStim(0.5)
presyn.interval = 10 // ms
presyn.number = 2
presyn.start = 20 // ms
presyn.noise = 0

access soma
input = new NetCon(presyn, gaba)
input.weight = 1000
input.threshold = 1
input.delay = 0


tstop= 300


// graphing code (taken from .ses file after using gui)
objectvar save_window_, rvp_
objectvar scene_vector_[3]
objectvar ocbox_, ocbox_list_, scene_, scene_list_
{ocbox_list_ = new List() scene_list_ = new List()}
{pwman_place(0,0,0)}
{
save_window_ = new Graph(0)
save_window_.size(0,300,-120,40)
scene_vector_[2] = save_window_
{save_window_.view(0, -120, 300, 120, 28, 135, 300, 200)}
graphList[0].append(save_window_)
save_window_.save_name("graphList[0].")
save_window_.addexpr("v(.5)", 1, 1, 0.8, 0.9, 2)
}
objectvar scene_vector_[1]
{doNotify()}


run()

[ted]

Nicely structured code, but phpBB ignores leading whitespace by default, and that tends to degrade readability. You might want to follow the suggestions in
Preserving code and text formatting
viewtopic.php?f=20&t=493

Is there some intrinsic difference between built in and user compiled mechanisms?

Code written by users is more likely to contain errors; at least, that's the case for my own code, which accounts for most of the user-written code that I see.

But you asked about "user compiled" code. Did you in fact compile it, did NEURON load the compiled mechanism(s) when you used NEURON to execute your hoc code, does an instance of your mechanism actually exist in your model after execution of the "model specification" portion of your hoc code, and does the mechanism have the parameters you want it to?

So how do you debug your own code? I bet you'll discover what's wrong, or at least the key symptom, if you do the following:
1. Comment out the "run()" statement. Instead, use the RunControl panel
NEURON Main Menu / Tools / RunControl
It's much more convenient for interactive debugging.
2. Use as small a value for tstop as is practical. 300 ms is way too big. 5 or 10 is OK.
3. Why wait 20 ms for the first synaptic event?
"v needs time to settle from its initial value of -65 mV to its resting level of -70."
So why not change its initial value to -70? Easy to do with the RunControl panel.
"How do I do that in hoc?"
Save the RunControl panel to a ses file, then read the ses file and discover the assignment statement that does this--and the name of the variable that specifies the potential that NEURON's run time system uses for its default initialization.
4. Read the messages that NEURON prints in its xterm when it starts up. Do you see any error messages? Do you see the name of the mod file that defines your new mechanism?
5. This is a small model, so type
soma psection()
at the oc> prompt and see what NEURON tells you about what's in your model. Do you see an instance of your new mechanism?
For larger models with more sections, you'd probably want to use the ModelView tool to verify that the model in the computer matches the conceptual model in your head. But why wait--try it now and see what you can discover. If you're not familiar with ModelView, read about it here http://www.neuron.yale.edu/neuron/docs


A few minor comments about your hoc code.
1. The second "access" statement is superfluous.
2. It's good to see that you used a code block of the form

Code: Select all

sectionname {
  . . . statements . . .
}

This "section stack" method for defining the currently accessed section makes code more readable. A small hint: inside the soma { . . . } block you can save yourself some typing by omitting the "soma." part of names such as soma.nseg
3. Since the spike source "presyn" is an artificial spiking cell, there is no need to specify the NetCon's threshold. An artificial spiking cell generates output events directly, unlike a biophysical model cell (a cell implemented as one or more sections) which has a variable that must be monitored by a NetCon's threshold detector.
4. The code that is built into NEURON uses capitalization for class names. This is a common programming practice that marginally improves readability. You might want to do that with your new synaptic mechanism class, e.g. TestGaba.