Allow for dimensions set to be used in variables in registry.xml

[jimmielin]

Tag name (required for release branches):
Originator(s): @jimmielin
AI tools used (if applicable; please also add the "AI-generated code" label to the PR):
What: claude-opus:4.6[1m]
How: scoped out the work, wrote tests and proposed fix to horizontal_dimensions unassigned in test

Description (include the issue title, and the keyword ['closes', 'fixes', 'resolves'] followed by the issue number):

• Fixes Registry should allow for registered variables to also be dimensions of other variables #390
• Fixes CAM-SIMA cannot read physics snapshot variables with non-standard dimensions #465: Fix self-referential custom dimensions in registry autogen

Background: Variables used in microp_aero like nacon and rndst in registry.xml (to be read from snapshot file) use dust_size_bin_dimension as a third dimension. That dimension is itself defined as a variable ndust (dust_size_bin_dimension) in the same generated module.

Problem: The autogen code (generate_registry_data.py) emits allocate calls using standard names as Fortran identifiers (e.g., allocate(rndst(..., dust_size_bin_dimension))), but only knows how to import dimension variables from external metadata files via use statements. For dimensions defined in the same module, no use statement can be generated (Fortran can't use its own module), so the standard name is undefined at compile time.

This fix generates local integer aliases in the allocate subroutine for any dimension that resolves to a variable in the same module:

  integer :: dust_size_bin_dimension  ! local alias
  dust_size_bin_dimension = ndust     ! set before allocate calls

This only triggers when the dimension is not already provided by an external metadata file (i.e., not in var_module_dict). The existing number_of_ccpp_constituents special case (quoted below) is left untouched:

CAM-SIMA/src/data/generate_registry_data.py

Lines 1400 to 1408 in a9a6263

	#Bring in "num_advected" as well if needed, as the
	#standard name in the cam_constituents.meta file doesn't
	#match the standard name that is actually used to represent
	#all constituents. Please note that once the CCPP-framework
	#supports a separation between total and advected constituents
	#then this section of code will likely need to be modified:
	if ('number_of_ccpp_constituents' in self.__var_dict.known_dimensions):
	outfile.write("use cam_constituents, only: number_of_ccpp_constituents=>num_constituents", 2)
	outfile.blank_line()

• Fix undefined horizontal_dimension variable in tests - Claude pointed out that it was unassigned in the test file. In real builds, horizontal_dimension comes from physics_grid.meta via a use statement, so no alias is generated for it. It should only be fixed in the test sample file.

Describe any changes made to build system:

Describe any changes made to the namelist:

List any changes to the defaults for the input datasets (e.g. boundary datasets):

List all files eliminated and why:

List all files added and what they do:

List all existing files that have been modified, and describe the changes:
(Helpful git command: git diff --name-status development...<your_branch_name>)

M       src/data/generate_registry_data.py
  - now assign self-referencing dimensions from registry

M       test/unit/python/sample_files/physics_types_parameter.F90
M       test/unit/python/sample_files/physics_types_simple.F90
  - bugfix for unassigned horizontal_dimensions in original test sample file

A       test/unit/python/sample_files/physics_types_self_ref_dim.F90
A       test/unit/python/sample_files/physics_types_self_ref_dim.meta
A       test/unit/python/sample_files/reg_good_self_ref_dim.xml
M       test/unit/python/test_registry.py
  - dust third dimension specified in registry.xml + variable using that dimension in registry.xml (self-referencing) test in test_registry test

M       src/data/registry.xml
  - add dust_size_bin_dimension set to 4
  - add nacon, rndst variables which use new ndust=4 dimension

If there are new failures (compared to the test/existing-test-failures.txt file),
have them OK'd by the gatekeeper, note them here, and add them to the file.
If there are baseline differences, include the test and the reason for the
diff. What is the nature of the change? Roundoff?

derecho/intel/aux_sima:

derecho/gnu/aux_sima:

derecho/nvhpc/aux_sima (test is run via Github workflow. Only run the test manually if we need to save new baselines):

If this changes climate describe any run(s) done to evaluate the new
climate in enough detail that it(they) could be reproduced:

CAM-SIMA date used for the baseline comparison tests if different than latest:

[jimmielin]

I am not sure if this fully resolves #465 but I suspect it does.

OK confirmed it does! I can check nacon and rndst dimensioned (ncol, nlev, dst)

 ********** Physics Check Data Results **********

 TIMESTEP:            1
INFLD_REAL8_3D: field = pbuf_NACON, grid = physgrid, timelevel = 1
 Creating new decomp: 486!58!4!!486!58!4!!d6!i1!
 cam_pio_newdecomp: dims =          486          58           4
INFLD_REAL8_3D: field = pbuf_RNDST, grid = physgrid, timelevel = 1

 No differences found (above the threshold) for all variables below:
 Note: If a variable is not in the registry,
       or if a constituent is not registered,
       or the variable was not updated by any scheme,
       it is not checked against the snapshot.
       Verify all expected model state variables are enumerated below:

 Variable Checked                                  # Values   Avg (model)   Avg (snapshot)
 --------                                          --------   ------------   --------------
dust_number_concentration_by_size_bin_for_contact_freezing
                                                     112752    6.00165E+03    6.00165E+03
 dust_radii_by_size_bin                              112752    1.39425E-06    1.39425E-06

[jimmielin]

It appears that I have independently discovered #462