Neuron 7.0 alpha, segmentation fault

[wvangeit]

I have compiled and installed Neuron 7.0.1072 (obtained from subversion archive) on Mac OS X 10.5.5.

It generates a segmentation fault when I try to run an adapted version of the Akemann & Knopfel PC model (http://senselab.med.yale.edu/SiteNet/ea ... 19&o=80769).
(I added also THREADSAFE to all the mod files)

I've attached a debugger to nrniv and I get :

Code: Select all

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x009a1078
0x009c2ee4 in nrn_init (_nt=0xa0b5a0, _ml=0x1ace980, _type=35) at Na.c:1109
1109	  ena = _ion_ena;

Could it have something to do with the following notice I get when running nrnivmodl ?:

Code: Select all

"/usr/local/share/nrn/libtool"  --mode=compile gcc -DHAVE_CONFIG_H  -I. -I.. -I"/usr/local/include/nrn" -I"/usr/local/i686/lib"    -g -O2 -c -o NaP.lo NaP.c
 gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include/nrn -I/usr/local/i686/lib -g -O2 -c NaP.c  -fno-common -DPIC -o .libs/NaP.o
"/usr/local/i686/bin/nocmodl" Narsg
Translating Narsg.mod into Narsg.c
NEURON's CVode method ignores conservation
Notice: LINEAR is not thread safe.

Is this in any way easily solvable ?

Thx,

Werner Van Geit
Computational Neuroscience Unit
Okinawa Institute of Science and Technology

[ted]

Try this:
comment out the LINEAR blocks, e.g. for Na.mod

Code: Select all

COMMENT
LINEAR seqinitial { : sets initial equilibrium
 . . .
}
ENDCOMMENT

and in the INITIAL block, comment out the existing SOLVE statement, then copy the SOLVE statement from the BREAKPOINT block and replace the METHOD keyword with STEADYSTATE, e.g.

Code: Select all

INITIAL {
        qt = q10^((celsius-22 (degC))/10 (degC))
        rates(v)
:       SOLVE seqinitial
 SOLVE activation STEADYSTATE sparse
}

Let me know if that helps.

[hines]

Return to the original Akemann files and do NOT add THREADSAFE to any mod files.
This works on my mac osx 10.4 machine. Does it work on yours?

[wvangeit]

Return to the original Akemann files and do NOT add THREADSAFE to any mod files.
This works on my mac osx 10.4 machine. Does it work on yours?

I have tried this, and the original runs indeed without problems.

I have also tried your suggestion about commenting out the LINEAR block (and making the other suggested changes), but this also generated the same segmentation fault (same backtrace when running in gdb).

In the mean time however I have found which hoc-line is creating the segmentation fault in my adapted version of the Akemann-Knopfel model:

Code: Select all

{cvode.cache_efficient(1)}

If I run the adapted model without this line, it works perfectly.

Thx for the help.

[wvangeit]

I still have a question about this THREADSAFE statement.

Does this cause Neuron to generate threadsafe code (like I supposed it did), or does it only allow the user to declare that a certain mod file 'is' threadsafe ?

In the former case, I suppose I want to use threadsafe in the mod files I'm using. Since I get warnings when using nrnivmodl:

Code: Select all

Notice: Assignment to the GLOBAL variable, "ninf", is not thread safe
Notice: Assignment to the GLOBAL variable, "taun", is not thread safe

In the latter case, is there a way to make the code threadsafe from the user's perspective ?

Thx,

Werner Van Geit

[wvangeit]

Do I have to enable the multithreading in some way, or is this automatically activated ?
When I run the original Akemann-Knopfel without GUI, Neuron uses only 1 core of my Core 2 Duo processor in my Mac. Or is Neuron not able to parallelize this model ?
(When I activate the GUI, then 66% of my processor power is used (33% per core))

Thx

[ted]

I still have a question about this THREADSAFE statement.

Does this cause Neuron to generate threadsafe code (like I supposed it did), or does it only allow the user to declare that a certain mod file 'is' threadsafe ?

Assigning a value to a GLOBAL variable is not threadsafe because multiple threads executing the same code can try to assign values to the same location. By inserting THREADSAFE in the NEURON block, you are telling mknrndll to interpret the GLOBAL directive in the following way: in the resulting code, each thread will have its own, indepentent copy of any variable(s) that had been declared GLOBAL.

It has been a common idiom to declare "intermediate value" variables, such as steady state values and time constants in HH-style mechanisms, as GLOBAL in order to save space. THREADSAFE will fix that.

I suppose I want to use threadsafe in the mod files I'm using. Since I get warnings when using nrnivmodl:

Code: Select all

Notice: Assignment to the GLOBAL variable, "ninf", is not thread safe
Notice: Assignment to the GLOBAL variable, "taun", is not thread safe

Exactly.

But THREADSAFE but it does not correct all problems that may affect NMODL code. That's why I suggested replacing the LINEAR block in each Na*mod file with a SOLVE . . . STEADYSTATE statement in the INITIAL block.

[ted]

These files declare GLOBALs, but have no other problems, so just insert THREADSAFE into their NEURON blocks:
Ca*.mod
Ih.mod
K*.mod

That will make their GLOBAL variables be on a "per thread" basis.

[ted]

Do I have to enable the multithreading in some way, or is this automatically activated?

Easiest way is with the ParallelComputeTool
NEURON Main Menu / Tools / Parallel Computing
Lets you specify the number of threads, and select various options for how to execute the simulation. Discovering whether multithreaded execution benefits or not is somewhat an empirical process, especially with regard to the number of threads. Complex models tend to show more improvement from multithreaded execution than simple ones do. First try increasing the number of threads; this will improve load balance, and may benefit execution speed up to a point. Then try Cache Efficient. Multisplit is for models that involve cells with complex architectures.

[wvangeit]

Okay, I have added the following to my code:

Code: Select all

load_file("parcom.hoc")

objref pc
pc = new ParallelComputeTool()
pc.multisplit(1)
pc.nthread(2)

And now it runs on 2 cores (it uses 160% of the processing power of 1 core) without using a GUI.