You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
"non-standard" fieldnames like "T" and "state_T" (for example) introduce unwanted ambiguity
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.
The text was updated successfully, but these errors were encountered:
"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.
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.
The text was updated successfully, but these errors were encountered: