Sometimes, a physics scheme will need input data that is specific to the scheme. The host model needs to perform the input of this data but should not have to know about the field or its source. We propose adding metadata to a variable to facilitate this functionality.
Solution
The players:
<field_data>: The standard name of a field of data (i.e., the standard_name entry in a variable's metadata)
filename_for_<field_data>: The standard name of the file where <field_data> can be located.
fieldname_for_<field_data>: An ordered, comma-separated list of possible NetCDF variable names under which <field_data> is stored in filename_for_<field_data>.
The action:
The semantics would be that filename_for_<field_data> and fieldname_for_<field_data> could be added to the metadata entry for <field_data>. This would allow the host model to read this data.
Of course, this begs the question of where filename_for_<field_data> comes from since the host model also does not know about that. This field needs to be a runtime value. While the CCPP Framework committee has not been able to define any standard for runtime values, CESM does need a solution. If desired, I can outline our current thinking in a future meeting or issue.
Alternatives (optional)
One alternative is for fieldname_for_<field_data> to be a runtime value instead of a hard coded list of (NetCDF) field names. Making it runtime variable name would add flexibility by allowing the namelist to tie a particular file to the variable name on that file. However, that variable does not have to show up anywhere in a scheme's list of dummy arguments so it would be a different use of names in metadata.
Description
Sometimes, a physics scheme will need input data that is specific to the scheme. The host model needs to perform the input of this data but should not have to know about the field or its source. We propose adding metadata to a variable to facilitate this functionality.
Solution
The players:
<field_data>
: The standard name of a field of data (i.e., thestandard_name
entry in a variable's metadata)filename_for_<field_data>
: The standard name of the file where<field_data>
can be located.fieldname_for_<field_data>
: An ordered, comma-separated list of possible NetCDF variable names under which<field_data>
is stored infilename_for_<field_data>
.The action:
filename_for_<field_data>
andfieldname_for_<field_data>
could be added to the metadata entry for<field_data>
. This would allow the host model to read this data.filename_for_<field_data>
comes from since the host model also does not know about that. This field needs to be a runtime value. While the CCPP Framework committee has not been able to define any standard for runtime values, CESM does need a solution. If desired, I can outline our current thinking in a future meeting or issue.Alternatives (optional)
fieldname_for_<field_data>
to be a runtime value instead of a hard coded list of (NetCDF) field names. Making it runtime variable name would add flexibility by allowing the namelist to tie a particular file to the variable name on that file. However, that variable does not have to show up anywhere in a scheme's list of dummy arguments so it would be a different use of names in metadata.