Skip to content

Fix local name collisions between group cap dummy arguments and locals#771

Open
jimmielin wants to merge 1 commit into
NCAR:developfrom
jimmielin:fix/group-local-name-collision
Open

Fix local name collisions between group cap dummy arguments and locals#771
jimmielin wants to merge 1 commit into
NCAR:developfrom
jimmielin:fix/group-local-name-collision

Conversation

@jimmielin

@jimmielin jimmielin commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

[ 50 character, one line summary ]
Fix local name collisions in generated group caps

[ Description of the changes in this commit. It should be enough
information for someone not following this development to understand.
Lines should be wrapped at about 72 characters. ]
Two schemes in the same suite group may use the same local name for
different quantities (i.e., different standard names).

capgen declared both in the group subroutine scope,
e.g. a constituent dummy argument (which keeps the local name of the first
requesting scheme)
alongside a group local for a scheme-supplied interstitial, or
a host variable dummy alongside such a local.

The call list and group dictionary each enforce internal uniqueness
(#631) but were never checked against each other, so capgen silently
generated uncompilable code (duplicate declarations).

After group analysis, Group.ensure_unique_local_names() now renames
any group-local variable whose name matches a dummy argument or suite
module variable. Renaming locals is safe: generated code resolves
variables by standard name at write time, and group locals are not
visible outside the group subroutine.

User interface changes?: No - bug fix only

Fixes: Issue #772 . Reproducer in PR. See cld_ice_array and ncols which now has two meanings.

Testing:
test removed: n/a
unit tests: all PASS.
system tests: all PASS. see improved advection_test
manual testing: in CAM-SIMA

AI disclosure: claude-fable:5

Two schemes in the same suite group using the same Fortran local name
for different standard names generated an uncompilable group cap:
a constituent dummy argument keeps the local name of the scheme that
first requested it, while a scheme-supplied interstitial declares a
group local with its own scheme local name. The Group call list and the
Group dictionary each enforced local name uniqueness internally (NCAR#631)
but never against each other, so the group subroutine declared the same
name twice. The same collision occurred between a host variable dummy
argument and an interstitial local.

Fixes:
- After a Group's analysis, rename any group-local variable whose local
  name matches a dummy argument (call list) or suite module variable
  (Group.ensure_unique_local_names). Renaming group locals is safe
  because generated code resolves variables by standard name at write
  time and locals are invisible outside the group subroutine.
- VarDictionary.new_internal_variable_name accepts a reserved
  collection of additional names to avoid and compares candidate
  names case insensitively (local name use is case insensitive).
- Add VarDictionary.known_local_names accessor.
- Fix a latent KeyError in Group.write when a duplicate local name was
  first registered as a scalar or optional variable rather than an
  allocatable.

Test: the advection test gains cld_shadow, a scheme reusing the cloud
ice constituent local name (cld_ice_array) and the host horizontal
dimension local name (ncols) for its own interstitials; the generated
group cap must rename its locals for the test to compile and run.

Seen in CAM-SIMA cam7: nucleate_ice_ccpp's constituent 'ni' collided
with the gravity wave drag schemes' interstitial 'ni' (worked around in
atmospheric_physics by renaming the scheme argument).

Assisted-by: claude-fable:5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant