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

Add optional metadata fields for constituent implementation #461

Open
peverwhee opened this issue Jan 18, 2023 · 3 comments
Open

Add optional metadata fields for constituent implementation #461

peverwhee opened this issue Jan 18, 2023 · 3 comments

Comments

@peverwhee
Copy link
Collaborator

Description

For the purposes of completing the constituent infrastructure in CAMDEN, @gold2718 and I propose two new optional metadata fields:

  • molar_mass (float)
  • input_names (list): list of aliases found on file for reading input data file

Additionally: a new interface will be generated (akin to ccpp_physics_suite_variables) that will return the input_names list for each variable.

Aside: a related optional metadata field is already in NCAR/ccpp-framework/main:

  • advected (boolean, default false): if true, this is an advected constituent

Alternatives (optional)

During discussion of this at the CCPP Framework meeting, there was some pushback on the input_names field because:

  1. "non-standard" fieldnames like "T" and "state_T" (for example) introduce unwanted ambiguity
  2. Since the framework should have nothing to do with I/O it seems iffy to include these names that are very much tied to I/O

One related suggestion was to change the name of the field from input_names to known_aliases or input_aliases for clarity. Though this does not resolve the ambiguity of the aliases themselves or the I/O ties.

@gold2718
Copy link
Collaborator

  1. "non-standard" fieldnames like "T" and "state_T" (for example) introduce unwanted ambiguity

I've been wondering about this, especially with names such as "state_T" which are from a very specific source not likely to be widely used. Perhaps this needs to be a host-model function.

On the other hand:

Since the framework should have nothing to do with I/O it seems iffy to include these names that are very much tied to I/O

I think there have been calls for the CCPP Framework to provide a way to have a diagnostic name that is different from the standard name. Because many diagnostic fields are widely shared, how do we provide this service without being too I/O about it?

@peverwhee
Copy link
Collaborator Author

I've been thinking about this all day and still don't have a clear idea. I think perhaps we move the input names list (and interface) to the host side and deal with the diagnostic fields in the future.

@peverwhee
Copy link
Collaborator Author

One additional proposed metadata field:

  • default_value (float): what a constituent will default to if not on the initial data file

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

No branches or pull requests

2 participants