hh.mod incompatibility with coreneuron about nrn HOT 7 CLOSED

My work around strategy has been to clone into a nrncore repository, modify manually, and then pull
as the github repository changes. (git stash ; git pull ; git stash pop)
For a longer term solution, I'm thinking in terms of mod2c_core handling the issue analogous to what is
currently done with the THREADSAFE keyword for pthreads. ie. when a GLOBAL is assigned a value in
the mod file, and it is to be simulated on a gpu, then the GLOBAL is promoted to a (hidden) RANGE
variable. In the case of TABLE, the intention is to eventually support that on the GPU..

from nrn.

Thank you for your reply!
I'll be waiting for the long term solution, in the meantime I'll use the suggested workaround.
Thanks

from nrn.

ie. when a GLOBAL is assigned a value in the mod file, and it is to be simulated on a gpu, then the GLOBAL is promoted to a (hidden) RANGE variable

@nrnhines : when we load the bbcore_write data into coreneuron, we check vector count etc. If mod2c convert GLOBAL to RANGE at coreneuron side then it will confuse about count etc. May be we have to handle it in more detail...also when we want to have NEURON and CoreNEURON in same memory space (as a single executable).

I was thinking about having some flag for nrnivmodl itself that will tell nocmdol to do these changes from NEURON side as well and then build special. But there will be also more details here.... (for example , for pre-comliping models like hh.mod)

from nrn.

from nrn.

This will be solved by BlueBrain/CoreNeuron#54

from nrn.

@sharkovsky : that BlueBrain/CoreNeuron#54 will only work if the channel is not used i.e. "ignore unused channels if they have different sizes. ". For hh.mod here, we are considering channels that are actually being used and they have different sizes. We can revisit this after mod2c changes.

from nrn.

CMake build system now automatically updates hh.mod if CoreNEURON is enabled. So this is good to close.

from nrn.