Use SoA for "dparam".

[1uc]

This issue is to track and discuss about using the soa datastructure for "dparams".

[nrnhines]

This is a useful project as it extends, simplifies, and makes uniform the soa concept to all data needed by membrane mechanisms (the Prop structure). The separate implementation for pool memory management of dparams can be discarded. The permutation benefits and data handle stability for dparam data will be the same as for param data. It seems to me that another beneficial consequence is that the concept of a Prop instance becomes entirely abstract and possiblly eliminable from the code. At least a Prop instance reduces to a pointer or reference to a mechanism row. Note that in CoreNEURON, there is no explicit mention of structure Prop.

Presently, dparam items have various types and usages.

name   value   type
area    -1    double*
iontype    -2    int
cvodeieq    -3    int
netsend    -4    void*
pointer    -5    double* (or void* depending on mod file usage)
pntproc    -6    Point_process*
bbcorepointer    -7    void*
watch    -8    void*
diam    -9    double*
fornetcon    -10    void*
random    -11    nrnran123_State*
xx_ion    mechtype of the ion    double*
#xx_ion    1000 + mechtype of the ion    double*

param items are categorized as PARAMETER, ASSIGNED, or STATE variables and are all type double Consider the type field unreliable. They are as I recall from before SoA.

[1uc]

Thank you, very helpful. I'll do area first.

[1uc]

I think I understand a bit better. Here's a sketch of what I think is currently happening. Essentially all dparams get stored in a pool allocated area; and the Prop seems to "control" it's lifetime. The SoA caches filter all dparams / Datum objects pointed to by the Prop that are semantically double *.

dpara-cache-soa.pdf

Here's the proposal, and maybe this is what @nrnhines has been trying to tell me all along. We move the Datum into the SoA container. That would eliminate the need of having the pool-allocated Datums. The current system for caching double* could remain in place, it would simply be populated from the SoA rather than the shadow std::vector<std::vector<Datum*>> object inside cache::Mechanism. The sketch of that is here:

dpara-cache-soa-soln1.pdf