Skip to content

CAM-SIMA cannot read physics snapshot variables with non-standard dimensions #465

@nusbaume

Description

@nusbaume

What happened?

Certain physics schemes (e.g. PUMAS) require variables from snapshot files that contain a dimension that is not a member of the standard set of horziontal_dimension, vertical_layer_dimension, vertical_interface_dimension, or number_of_ccpp_constituents. This causes the file read step to fail with an error like so:

Cannot read nacon_in from file, nacon_in has unsupported dimension, dust_size_bins_dimension.

Given that there will be needed variables from a snapshot with non-standard dimensions, this bug needs to be fixed.

What are the steps to reproduce the bug?

You can replicate this error by doing the following on Derecho:

git clone https://github.com/nusbaume/CAM-SIMA.git
cd CAM-SIMA
git checkout pumas_round3
bin/git-fleximod update

Then create a new FPHYStest (snapshot) case with the pumas test suite, and then build and run the case with the cam_ne3pg3_fhistc_ltso_pumas_snapshot_derecho_gnu_* snapshots found here:

/glade/campaign/cesm/community/amwg/sima_baselines/cam_sima_test_snapshots

along with the number of vertical levels set to 58.

The model should then fail with the following error:

Cannot read nacon_in from file, nacon_in has unsupported dimension, dust_size_bins_dimension.

What CAM-SIMA hash were you using?

2af61da (on pumas_round3 branch)

What machine were you running CAM-SIMA on?

CISL machine (e.g. cheyenne)

What compiler were you using?

GNU

Path to a case directory, if applicable

/glade/derecho/scratch/nusbaume/model_runs/SIMA_pumas_test

Will you be addressing this bug yourself?

Yes

Extra info

This can (theoretically) be fixed by creating a more generic data-reading interface that doesn't check what dimensions are present, but instead just ensures that the dimension sizes and rank matches the provided buffer variable.

Then the auto-generated initialization code can check if a variable has a non-standard dimension, and if so then use the generic interface instead of the default standard interface. This should not only fix the bug, but also protect the more precise error messages for all the other variables that do not have an extra dimension.

In the long-term, this generic interface could sit below the more specific interfaces, which would reduce the total amount of code. However, this is just a "nice-to-have", and not required for fixing this particular bug.

Also pinging @cacraigucar @peverwhee as they helped discover this bug and come up with the potential solution.

Metadata

Metadata

Assignees

Labels

bugSomething isn't working correctly

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions