NCAR / ccpp-framework

Common Community Physics Package (CCPP)
http://www.dtcenter.org/community-code/common-community-physics-package-ccpp/
Other
26 stars 63 forks source link

Add optional metadata fields for constituent implementation #461

Open peverwhee opened 1 year ago

peverwhee commented 1 year ago

Description

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

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:

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 commented 1 year ago
  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 commented 1 year ago

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 commented 1 year ago

One additional proposed metadata field: