Dynamic number of extracellular layers

[cccohen]

Currently, the number of extracellular layers is a default compilation option in nrn/src/nrnoc/options.h, changeable only by recompilation. The number of extracellular layers should be a dynamically loading option definable by the user at insertion, i.e.

insert extracellular nlayer = [user defined] xraxial[nlayer-1] = [user defined] xg[nlayer-1] = [user defined] xc[nlayer-1] = [user defined] e_extracellular = [user defined]

etc.

[nrnhines]

@alexsavulescu, I'd like to work on this sooner rather than later and it will mean a drastic change to one of the structures in nrn/src/nrnoc/section.h (typedef struct Extnode {) and a lot of code changes in nrn/src/nrnoc/extcelln.c and a few other files. I'd be happy to do this as a subbranch of your cpp branch if it will save you extra effort.

[alexsavulescu]

@nrnhines you can work on those directly, I can always ask for your help afterwards if needed.

[pramodk]

@nrnhines : Are we targeting this for 8.0 release? (not 8.0a)

[nrnhines]

Anyone seeking the best performance for a specific model using the extracellular mechanism will be able to dynamically choose the value for nlayer. However the immediate rationale for this, which I believe has a good deal of force, is the case where the software is built by someone other than the user. I.e. the experience of @cccohen where he mentions:

have to ask each time, either for the first time or with newer versions of NEURON, that supercomputer administrators recompile to one layer. In addition, my experience thus far with recompilation for supercomputers has been spotty, causing problems and delays each time.

[pramodk]

Ok. I am asking to determine where this implementation should go. e.g.

• if we tag 8.0a then there this needs to be implemented in 8.0 branch (because of below)
• once 8.0a is tagged, we will start merging cpp PR of Alex. I assume cherry-picking from master to 8.0a (or 8.0 branch) will require some manual work (?)

But if this feature requires just few days of work and if you are planning this for 8.0a then you can start from master? Otherwise after cpp merge?

[nrnhines]

I have added it to the Release 8.0 milestone. I'm going to start working on it as a branch of the current master. Anticipate a half day to implement. It does not involve any conceptual changes. The main programming issue will be allocation and freeing of array memory from an interpreter specified value for nlayer_extracellular (default 2) instead of current fixed arrays of size NLAYER. I don't want it to delay the 8.0a release.

[cccohen]

@nrnhines Thank you for specifying the use-case and rationale, which I should have included above.

The same rationale of substantial performance increase can also be applied to dynamically removing extracellular after insertion. I thought I should make this suggestion here, in case the modification could also be done as part of the above.

[nrnhines]

I no longer remember the reason why uninsert extracellular (on a per section basis) was not implemented. I will look into it. Because all the dependencies of extracellular need to be updated with nlayer changes, I am thinking of controlling the value from the interpreter via a function nlayer = nlayer_extracellular([nlayer]). Perhaps it can be made to happen that nlayer_extracellular(0) makes sense.

[nrnhines]

The current state of the pull request #926 minimally answers this issue. i.e h.nlayer_extracellular(1) will change from the default of two layers to one layer. The only constraint is that when that function is executed, that there be no sections with extracellular inserted. I.e. it would normally be called prior to the creation of the model.

If sufficiently desirable, it would be possible to eliminate that constraint and allow the function to be called at any time, even when extracellular mechanism instances are present with a different nlayer. I doubt there is a practical use case for this and even if so, it is a simple matter to use a workflow with different launches for different nlayer. However, I suppose the implementation could be such that an increase in nlayer would preserve the values of lesser layers and fill the greater layers with their normal default values (ie. xc=0, xg very large, and vext=0). And a decrease in nlayer would preserve the parameter and vext values in the remaining layers. The greatest difficulty would be to update any pointers to the old vext (eg in graphs) and pointer issues that could arise could delay the merge for several weeks. I have not yet looked into the possibility of uninsert for extracellular but that can await a future pull request. So, @cccohen , if you are satisified with the functionality of PR #926 as is, it can be merged to the master and be part of the approaching 8.0a distribution. I've tested with the Bokil model (https://senselab.med.yale.edu/ModelDB/ShowModel?model=3676#tabs-1) and a few IDA variable time step tests.

[cccohen]

@nrnhines In response to:

If sufficiently desirable, it would be possible to eliminate that constraint and allow the function to be called at any time, even when extracellular mechanism instances are present with a different nlayer.

The use-case for dynamic relayering are computer experiments in which myelinated sections (nlayer_extracellular(1)) are directly compared to non-myelinated ones (nlayer_extracellular(0)), with the substantial performance increase that comes with removing extracellular. Further, as noted,

a decrease in nlayer would preserve the parameter and vext values in the remaining layers.

Of course I am sensitive to such issues as delays due to pointer preservations or updates, and the ability to dynamically change extracellular layers at insertion with respect to the default number, without recompilation, is already a big step forward. I would be happy with closing this pull request here and opening another for dynamic relayering (including 0 layers).