from neuron import coreneuron specifies CoreNEURON run properties

[nrnhines]

coreneuron.nrncore_arg(tstop) returns str that can be used with
pc.nrncore_run(str) based on coreneuron properties and current
NEURON settings. User specifiable properties are enable, gpu,
cell_permute, warp_balance, verbose, and prcellstate. Args derived
from current NEURON settings are --mpi, --binqueue, --spkcompress,
--multisend, --ms_subinterval, and --ms_phases.

Closes #639

[pramodk]

looks ok to me. but we can tune / update once psolve changes are in.

[pramodk]

if user set int then it is also treated as float?

[nrnhines]

what do you think about

tstop = float(tstop) # error if can't be a float
enable = bool(enable)       
gpu = bool(gpu)
cell_permute = int(cell_permute)

I suppose the last two would never raise an error.

[pramodk]

I think this is fine. If we will need more elaborate option validation, we can extend it later.

[pramodk]

@nrnhines : is this ready for basic testing? If so, what are steps we need to do? e.g.

• nrnivmodl & nrnivmodl-core
• modify python script to import neuron and enable it

I wonder about cache_efficient(1). Should we set this if coreneuron is enabled?

[nrnhines]

It is ready for basic testing. Please examine the output of this test.

temp.py.txt

I wonder about cache_efficient(1)

It is tempting to check and set in neuron.coreneuron.nrncore_arg(tstop) but after setting it requires a stdinit(). That may be too far. (although it would almost be safe to set in enable if that was a function.)

[pramodk]

It is tempting to check and set in neuron.coreneuron.nrncore_arg(tstop) but after setting it requires a stdinit().

Just thinking loud : stdinit / finitialize can check if coreneuron is enabled and then set it cache_efficient(1) as first thing?

[nrnhines]

I experimented and see that if I have changed cache_efficient(...) after stdinit and before a normal pc.psolve I get segmentation violation, but if it is between a stdinit and an enable=True pc.psolve then I get

NEURON: NEURON model internal structures for CoreNEURON are out of date. Make sure call to finitialize(...) is after cvode.cache_efficient(1))

So your idea would work unless they set enable after finitialize()

[nrnhines]

I might be able to fix both the normal psolve segmentation violation and the nrncore_run complaint of Model internal structures out of date by factoring out the first part of nrn_finitialize() to do the internal structure update (no data value changes but pointers get updated as well) One consequece would be that neuron.coreneuron.nrncore_arg(tstop) could safely call
h.cache_efficient(1)

[nrnhines]

Another possibility to avoid the h.cache_efficient(1) issue is to make it unnecessary for transferring data to CoreNEURON. It really was mostly a convenience requirement to allow reasonably fast determination of what mechanism instance data a pointer is referencing. At any rate, for the purposes of this pull request, I think we can require that the user call h.cache_efficient(1) (if using CoreNEURON) prior to finitialize(). And finitialize() must be prior in all cases to the first call to pc.psolve(tstop). Or else suffer a meaningful error message to be implemented in the next changeset to this pull request.

[pramodk]

At any rate, for the purposes of this pull request, I think we can require that the user call h.cache_efficient(1) (if using CoreNEURON) prior to finitialize().

Agree. We can make this mandatory and can re-evaluate other possibilities later.

[nrnhines]

Need any more for now? Looks like we are supporting

cvode.cache_efficient(1)
stdinit()
pc.psolve(tstop)

And deferring subsequent pc.psolve(tstop) to when we have data transfer back and forth between NEURON and CoreNEURON so that NEURON can change parameters between successive pc.psolve calls

[pramodk]

Some minor comments. Once these are answered/clarified, good to merge. (already approving)