arbor-sim/arbor

Accessing CV area in mechanisms

Closed this issue · 1 comments

jlubo commented

Regarding issue #2084, @schmitts, @thorstenhater and I have had offline discussions that led to the following conclusion.

The area of the spatial discretization unit (the CV area) should be made available in point and density mechanisms. Along with the already available variable diam, users will then be able to derive the CV volume as well.

Having access to the area and volume of the CV, it becomes possible to normalize input currents, the amount of diffusive particles, etc. directly in the mechanisms. Thereby, users can ensure that calculations are done with the physically correct units and #2084 may be solved without workaround.

jlubo commented

See below the outcome of the mentioned discussions (copied from here)

Proposal.

TH: Currently, a POINT_PROCESS writing to the current iX will NOT be independent of the CV size. Thus, I'd suggest we change the diffusion feature to have parity with that. Principle of least surprise. Also, writing Xd += 5 now means exactly that. In both density and pointy things. If you're desparate, we can grant access to the area (SS: and volume?) of a CV which was frowned upon by the elders on grounds of purity.

SS: Rephrased: no scaling "magic" for point processes at all (but density mechs continue to scale their effect with area), but the user can scale herself with the volume and area made available in the mechanisms. Correct?

TH: Yes. No (more) magic. It was a bad idea.

JL: that would be nice, to have volume & area in available in the mechanisms.

TH: One begets the other. area is the cylindrical mantel, so together with the alreay exposed diam, you can synthesize volume. Reason for not adding it directly is that it'd mean another array in the internal storage. But. We can hand out a function volume_of(area, diam).

SS: fine, the user can calc. the volume if needed. The function would be very nice.

TH: Agreed, you can write it.

TH: I prefer this approach since area is helpful in other contexts as well, ie concentration mechs. The alternative would be to define a meta(-function) flux(...) that converts/represents/defines an ionic flux (!) across the membrane, which essentially is the same as normalize-by-area-and-possibly-charge.