Open peverwhee opened 1 year ago
- "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?
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.
One additional proposed metadata field:
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:
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.