www.neuron.yale.edu

Posted: **Thu Sep 25, 2014 11:08 am**

Hi there,

I have problems compiling a .mod. The error message are confusing and interestly, the behaviour changes when my computer returns from hibernation (a Dell Laptop with Ubuntu 12.04).
I'm compiling three .mod, two of them have worked OK in a different problem and the new one (GolfAC5GiSyn.mod) is the problematic one.

First compilation attempt:

Code: Select all

mine$ nrnivmodl GolfAC5GiSyn peaktrainglobal diptrainglobal
/mine
GolfAC5GiSyn peaktrainglobal diptrainglobal
GolfAC5GiSyn peaktrainglobal diptrainglobal
"/home/yo/NEURON/nrn-7.3/x86_64/bin/nocmodl" GolfAC5GiSyn
Translating GolfAC5GiSyn.mod into GolfAC5GiSyn.c
Notice: Use of EXTERNAL is not thread safe.
Notice: Use of EXTERNAL is not thread safe.
PDE10 can't be declared a parameter by default at line 315 in file GolfAC5GiSyn.mod
}
^
make: *** [GolfAC5GiSyn.c] Error 1

Then, I changed PDE1 to PDE1aa in the STATE block which ended at line 315 and tried to compile again.

Code: Select all

mine$ nrnivmodl GolfAC5GiSyn peaktrainglobal diptrainglobal
/mine
GolfAC5GiSyn peaktrainglobal diptrainglobal
GolfAC5GiSyn peaktrainglobal diptrainglobal
"/home/yo/NEURON/nrn-7.3/x86_64/bin/nocmodl" GolfAC5GiSyn
Translating GolfAC5GiSyn.mod into GolfAC5GiSyn.c
Notice: Use of EXTERNAL is not thread safe.
Notice: Use of EXTERNAL is not thread safe.
Line too long:GaiGTP' =  - (kfAC5XGaiGTP*GaiGTP*AC5Ca - krAC5XGaiGTP*AC5CaGaiGTP) - (kGiGTPase*GaiGTP) + (kactGi*M4RAChGi) - (kfAC5XGaiGTP*GaiGTP*AC5 - krAC5XGaiGTP*AC5GaiGTP) - (kfAC5XNCGaiGTP*GaiGTP*AC5GaolfGTP - krAC5XNCGaiGTP*AC5GaolfGTPGaiGTP) - (kfAC5XNCGaiGTP*GaiGTP*AC5CaGaolfGTP - krAC5XNCGaiGTP*AC5CaGaolfGTPGaiGTP) - (kfAC5XGaiGTP*AC5xxATP*GaiGTP - krAC5XGaiGTP*AC5GaiGTPxxATP) - (kfAC5XNCGaiGTP*GaiGTP*AC5GaolfGTPxxATP - krAC5XNCGaiGTP*AC5GaolfGTPGaiGTPxxATP) - (kfAC5XGaiGTP*AC5CaxxATP*GaiGTP - krAC5XGaiGTP*AC5C at line 388 in file GolfAC5GiSyn.mod
GaiGTP' =  - (kfAC5XGaiGTP*GaiGTP*AC5Ca - krAC5XGaiGTP*AC5CaGaiGTP) - (kGiGTPase*GaiGTP) + (kactGi*M4RAChGi) - (kfAC5XGaiGTP*GaiGTP*AC5 - krAC5XGaiGTP*AC5GaiGTP) - (kfAC5XNCGaiGTP*GaiGTP*AC5GaolfGTP - krAC5XNCGaiGTP*AC5GaolfGTPGaiGTP) - (kfAC5XNCGaiGTP*GaiGTP*AC5CaGaolfGTP - krAC5XNCGaiGTP*AC5CaGaolfGTPGaiGTP) - (kfAC5XGaiGTP*AC5xxATP*GaiGTP - krAC5XGaiGTP*AC5GaiGTPxxATP) - (kfAC5XNCGaiGTP*GaiGTP*AC5GaolfGTPxxATP - krAC5XNCGaiGTP*AC5GaolfGTPGaiGTPxxATP) - (kfAC5XGaiGTP*AC5CaxxATP*GaiGTP - krAC5XGaiGTP*AC5C
make: *** [GolfAC5GiSyn.c] Error 1

Then I changed back PDE1aa to PDE1, close the lid of the laptop, opened it again, login and apparently no problem with the compilation:

Code: Select all

mine$ nrnivmodl GolfAC5GiSyn peaktrainglobal diptrainglobal

...

Successfully created x86_64/special

(but the file GolfAC5GiSyn.c in the x86_64 subfolder is empty)

Now, when I try to run the .hoc calling these mechanisms:

Code: Select all

mine$ nrniv peakdipsynergy.hoc -
NEURON -- VERSION 7.3 ansi (1119:b3f8ab0f8203) 2014-07-18
Duke, Yale, and the BlueBrain Project -- Copyright 1984-2014
See http://www.neuron.yale.edu/neuron/credits

loading membrane mechanisms from x86_64/.libs/libnrnmech.so
dlopen failed - 
x86_64/.libs/libnrnmech.so: undefined symbol: _GolfAC5GiSyn_reg
	1 
nrniv: syntax error
 in peakdipsynergy.hoc near line 8
 insert peaktrainglobal
                      ^
oc>

I look forward to hear from you.

Thanks in advance,

Omar

Posted: **Thu Sep 25, 2014 12:40 pm**

Without seeing the problem mod file there's not much that I can say. I've never seen an error message like this

PDE10 can't be declared a parameter by default at line 315 in file GolfAC5GiSyn.mod

and can't imagine how it would be resolved by doing this

Code: Select all

changed PDE1 to PDE1aa in the STATE block

NMODL syntax is obscure, and mknrndll doesn't provide much in the way of useful feedback when it encounters errors. It is strongly advised that users check all NMODL code, from whatever source they get it (and especially if they write it themselves), with modlunit. modlunit is better than mknrndll or nrnivmodl at flagging syntax errors, and easier to work with because it stops as soon as it finds an error. However, it is very fastidious about unit consistency, and really fixing inconsistencies (rather than hiding them by wrapping UNITSOFF...UNITSON around affected code) can be tedious. That said, the only thing worse than buggy code that crashes is buggy code that compiles and runs without complaint; it is much better to detect and fix such errors than to waste a lot of time cranking out numerical results that are grossly incorrect because of some units mismatch.

WRT "Line too long" messages, I usually agree with them. A line long enough to gag software is probably also too long to be maintained or debugged by humans. If shorter variable names won't be sufficiently mnemonic, you might try breaking this monstrosity into multiple fragments by using the line continuation character \ every so often, e.g.

Code: Select all

GaiGTP' =  - (kfAC5XGaiGTP*GaiGTP*AC5Ca - krAC5XGaiGTP*AC5CaGaiGTP) \
  - (kGiGTPase*GaiGTP) + (kactGi*M4RAChGi) \
  - (kfAC5XGaiGTP*GaiGTP*AC5 - krAC5XGaiGTP*AC5GaiGTP) \
etc.

Posted: **Thu Sep 25, 2014 3:49 pm**

Thanks Ted.

Would you take a look at the .mod?

Looking forward,

Omar

Posted: **Thu Sep 25, 2014 5:19 pm**

When I break the lines with \ the following error follows:

Code: Select all

 
mine$ modlunit GolfAC5GiSyn.mod
model   1.1.1.1   1994/10/12 17:22:51
Checking units of GolfAC5GiSyn.mod
syntax error:
 Illegal statement:
 Illegal block at line 389 in file GolfAC5GiSyn.mod
GaiGTP' =  - (kfAC5XGaiGTP*GaiGTP*AC5Ca - krAC5XGaiGTP*AC5CaGaiGTP) \
                                                                    ^

In the source .mod it reads,

Code: Select all

GaiGTP' =  - (kfAC5XGaiGTP*GaiGTP*AC5Ca - krAC5XGaiGTP*AC5CaGaiGTP) \
 - (kGiGTPase*GaiGTP) \
 + (kactGi*M4RAChGi) \
 - (kfAC5XGaiGTP*GaiGTP*AC5 - krAC5XGaiGTP*AC5GaiGTP) \
 - (kfAC5XNCGaiGTP*GaiGTP*AC5GaolfGTP - krAC5XNCGaiGTP*AC5GaolfGTPGaiGTP) \
 - (kfAC5XNCGaiGTP*GaiGTP*AC5CaGaolfGTP - krAC5XNCGaiGTP*AC5CaGaolfGTPGaiGTP) \
 - (kfAC5XGaiGTP*AC5xxATP*GaiGTP - krAC5XGaiGTP*AC5GaiGTPxxATP) \
 - (kfAC5XNCGaiGTP*GaiGTP*AC5GaolfGTPxxATP - krAC5XNCGaiGTP*AC5GaolfGTPGaiGTPxxATP) \
 - (kfAC5XGaiGTP*AC5CaxxATP*GaiGTP - krAC5XGaiGTP*AC5CaGaiGTPxxATP) \
 - (kfAC5XNCGaiGTP*GaiGTP*AC5CaGaolfGTPxxATP - krAC5XNCGaiGTP*AC5CaGaolfGTPGaiGTPxxATP)

The PDE10 appearing in the error described in the first post is the name of a STATE (Phosphodiesterase 10)

I look forward.

Thanks in advance,

Omar

Posted: **Thu Sep 25, 2014 10:09 pm**

My mistake--NMODL's derivative notation does not allow the continuation character. However, the translator that turns derivative statements into C code is smart enough to deal with multiline statements without requiring the continuation character. Here is a purely fictional example: this multiline statement
m' = (minf-m)/mtau
-(hinf-h)/htau
+(ninf-n)/ntau
produces the same code as this single line statement
m' = (minf-m)/mtau - (hinf-h)/htau + (ninf-n)/ntau

Posted: **Fri Sep 26, 2014 6:18 am**

Thanks again Ted.

Now GolfAC5GiSyn.mod goes through modlunit without complains.

However, when compiling I keep having the problem with PDE10. Is ther some possibility that PDE10 is a reserved word or something similar?

Code: Select all

mine$ nrnivmodl peaktrainglobal diptrainglobal GolfAC5GiSyn
/mine
peaktrainglobal diptrainglobal GolfAC5GiSyn
peaktrainglobal diptrainglobal GolfAC5GiSyn
"/home/yo/NEURON/nrn-7.3/x86_64/bin/nocmodl" GolfAC5GiSyn
Translating GolfAC5GiSyn.mod into GolfAC5GiSyn.c
Notice: Use of EXTERNAL is not thread safe.
Notice: Use of EXTERNAL is not thread safe.
PDE10 can't be declared a parameter by default at line 341 in file GolfAC5GiSyn.mod
PDE1 (nM)}
         ^
make: *** [GolfAC5GiSyn.c] Error 1

I look forward.

Thanks in advance,

Omar

Posted: **Fri Sep 26, 2014 6:26 am**

I forgot to mention that if in this position I change PDE1 for PDE1aa or any other trailing character then this compiling error disappears and instead

Code: Select all

mine$ nrnivmodl peaktrainglobal diptrainglobal GolfAC5GiSyn
/mine
peaktrainglobal diptrainglobal GolfAC5GiSyn
peaktrainglobal diptrainglobal GolfAC5GiSyn
"/home/yo/NEURON/nrn-7.3/x86_64/bin/nocmodl" GolfAC5GiSyn
Translating GolfAC5GiSyn.mod into GolfAC5GiSyn.c
Notice: Use of EXTERNAL is not thread safe.
Notice: Use of EXTERNAL is not thread safe.
PDE1 must be declared as a state variable at line 691 in file GolfAC5GiSyn.mod
}
^

which is understandable because there is no PDE1 declared in the STATE block.

Looking forward,

Omar

Posted: **Fri Sep 26, 2014 12:16 pm**

I have changed all parameter and states names to k# and sp# respectively. Now the parameter names are like k105 and the species like sp63.

This new .mod went through nmodlunit smoothly. But when trying to compile, a new error popped up.

Code: Select all

mine$ nrnivmodl peaktrainglobal diptrainglobal GolfAC5GiSynParSp
/mine
peaktrainglobal diptrainglobal GolfAC5GiSynParSp
peaktrainglobal diptrainglobal GolfAC5GiSynParSp
"/home/yo/NEURON/nrn-7.3/x86_64/bin/nocmodl" GolfAC5GiSynParSp
Translating GolfAC5GiSynParSp.mod into GolfAC5GiSynParSp.c
Notice: Use of EXTERNAL is not thread safe.
Notice: Use of EXTERNAL is not thread safe.
Notice: sp10 is promoted from a PARAMETER to a STATE
Notice: sp20 is promoted from a PARAMETER to a STATE
Notice: sp30 is promoted from a PARAMETER to a STATE
Notice: sp40 is promoted from a PARAMETER to a STATE
Notice: sp50 is promoted from a PARAMETER to a STATE
Notice: sp60 is promoted from a PARAMETER to a STATE
nocmodl: nocpout.c:1370: decode_ustr: Assertion `i == 2' failed.
Aborted (core dumped)
make: *** [GolfAC5GiSynParSp.lo] Error 134

Species were never in the PARAMETER block. They just appear in STATE, INITIAL and DERIVATIVE. Furthermore, the Notice in the compiling message refers just to the only species names that end in 0.
Does this give any clue?

I look forward.

Thanks in advance,

Omar

Posted: **Fri Sep 26, 2014 12:49 pm**

If name is declared as a STATE, then name0 is automatically declared as its initial value. So if you have STATE { PDE1 } then PDE10 will be an automatic
PARAMETER. So it becomes an error to also declare PDE10 as a STATE.

Posted: **Fri Sep 26, 2014 7:50 pm**

Thanks Mike. I change those 0s and now it compiles OK.
I need to change the solver, because the fixed step methods doesn't seem to work OK with this problem.

Thanks again,

Omar

www.neuron.yale.edu

Esoteric but wrong compilation

Esoteric but wrong compilation

Re: Esoteric but wrong compilation

Re: Esoteric but wrong compilation

Re: Esoteric but wrong compilation

Re: Esoteric but wrong compilation

Re: Esoteric but wrong compilation

Re: Esoteric but wrong compilation

Re: Esoteric but wrong compilation

Re: Esoteric but wrong compilation

Re: Esoteric but wrong compilation