EXTERNAL can't refer to NEURON internals. #3165
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The way NMODL generates code, we're unable to find a way to have
EXTERNAL gbl_foo
refer to global variables in other mod files and global variables insidenrn
. The issue is thatgbl
in the mechanismfoo
isn't implemented as a global double. Instead they're all collected in an struct containing all the global variables (ease of GPU programming).What makes this difficult is that we can't know if
EXTERNAL gbl_foo
should be split as{var_name}_{mech_name}
. Therefore, we can't deduce which (if any) mechanismgbl
belongs. With more help from the DSL we could implement it, e.g.:The handful of cases I could find on ModelDB never used EXTERNAL to refer to global variables inside
nrn
, only global variables in other MOD files (under their control).Therefore, I'd like to propose to remove this part of EXTERNAL. The feature would likely continue to work for NOCMODL, but wouldn't work for NMODL. The tests that check that it's possible to gain access to internal variables would be removed. A similar change was made in the past. When a global variable became a thread-variable, this test was changed to reflect the fact that thread variables can't be the target of an EXTERNAL. This particular example feels like, if it were essential to know the
clamp_resist
value, it could be handled via the mechanism used for other "NEURON globals" likecelsius
.