Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accessing CV area in mechanisms #2105

Closed
jlubo opened this issue Apr 5, 2023 · 1 comment · Fixed by #2110
Closed

Accessing CV area in mechanisms #2105

jlubo opened this issue Apr 5, 2023 · 1 comment · Fixed by #2110

Comments

@jlubo
Copy link
Collaborator

jlubo commented Apr 5, 2023

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
Copy link
Collaborator Author

jlubo commented Apr 5, 2023

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.

brenthuisman pushed a commit that referenced this issue Jun 7, 2023
Add `area` variable in NMODL, this is used by _concentration models_
where flux over the membrane is proportional
to ionic current, the (lateral) CV area, and Faraday's constant and
_diffusive models_ which have similar formulae.

Also pushes ion state and solver construction into shared state to
isolate fvm_lowered from that duty.
Simplifies the construction of ion state.

Closes #2105
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant