Reduce indirection when MOD files use diam and area

[iomaganaris]

Overview of the feature

MOD files can access the section diameter using the special diam variable name. Examples of this include share/examples/nrniv/nmodl/nadifl.mod and ModelDB entry 184054. This is handled explicitly in the codebase, and the underlying storage for diam values is managed via a special pseudomechanism called MORPHOLOGY. When diam is used in the generated code, the values are indirectly looked up using data_handle during the simulation, which is rather slow and indirect. There are (at least?) two possibilities for how the situation can be improved:

Adopt the same caching technique that is used for ion variables, i.e. don’t change the data layout but do reduce the indirection down to loading a pointer and dereferencing it. To pursue this, look at neuron::cache::indices_to_cache and modify the code generation to use the cached pointer.
Revisit whether the MORPHOLOGY pseudomechanism is still needed, or whether the diameter could be stored directly as a Node data field? See #2312 for more information.
Similarly, usage of area in generated code may be able to be simplified. Most likely, the best approach is to uniformly handle area and diam in the same way as Node voltages, both in terms of the underlying data structure and how they are accessed in the generated code.

Source: https://nrn.readthedocs.io/en/latest/dev/data-structures.html#reduce-indirection-when-mod-files-use-diam

[nrnhines]

Data for area (and ri) is already similar to Node voltage. I believe diam should also be handled in that way as well. However
we need to consider whether exposure of diam at the interpreter should remain identical for legacy reasons. One exposure
is

oc>psection()
soma { nseg=1  L=3.1831  Ra=35.4
	/*location 0 attached to cell 0*/
	/* First segment only */
	insert morphology { diam=10}
        ...

However morphology is automatically inserted in every section upon section creation and cannot be uninserted.
The name convention for morphology diam is that it not have the typical suffix (we do not say diam_morphology). This is similar
to what happens with capacitance, ions, and extracellular.
Note that at present, morphology does not exist at 0 area nodes but a request for diam at those locations returns the
diam of the nearest segment in the currently accessed section. i.e.

oc>create soma, dend
oc>soma connect dend(0), 1
oc>soma.diam = 10
oc>dend.diam = 1
oc>topology()

|-|       soma(0-1)
   `|       dend(0-1)

	1 
oc>dend.diam(0)
	1 
oc>soma.diam(1)
	10 

though soma(0) and dend(0) are the same internal Node.

[olupton]

I don't have any great insight or comment here.

If I understand correctly, psection() is already returning something questionable (an explicit insert for something that's implicitly inserted), and keeping the same output formatting would be fine.

For the second issue, it would seem cleaner to me to just store + return a zero diameter for nodes with zero area. It seems to me that the example given above of getting 1 or 10 depending on how you ask, when the "correct" answer is zero, shows that code relying on this is broken code..?

[nrnhines]

0 area nodes have 0 length. The non-zero diameter is mostly a convenience for display. Also 0 diameter makes the idea of axial resistance between nodes on either side of that diameter point somewhat confusing.