When constructing run directories, fv3config takes into account the resolution when copying in orography files from a root directory. This way we only need to provide a single root path for all configs, regardless of resolution (e.g. here).
We have not needed this for forcing data up to this point. However, more modern configurations of FV3GFS use some forcing data on the cubed sphere grid. This data is is already on the grid at the specified resolution rather than interpolated from a regular latitude-longitude grid online. It is also the data that is used when generating initial conditions using the chgres_cube tool. See the files for example here.
It would be nice if fv3config could handle this in an elegant way (the current workaround is to copy all the forcing files, both grid-specific and grid-agnostic, into a new reference directory, resulting in many redundant files). Perhaps we could create a new top-level field in an fv3config YAML file, e.g. surface_climatology_files, for the root path to these files at different resolutions, similar to the orography data? The forcing data field would still be specified and would always correspond to the grid-agnostic reference files. There would be some redundancy in the files copied into the run directory, since old grid-agnostic versions of this surface climatology data exist as GRIB files, but the files used at runtime would be disambiguated by which files were specified in the namsfc namelist.
When constructing run directories, fv3config takes into account the resolution when copying in orography files from a root directory. This way we only need to provide a single root path for all configs, regardless of resolution (e.g. here).
We have not needed this for forcing data up to this point. However, more modern configurations of FV3GFS use some forcing data on the cubed sphere grid. This data is is already on the grid at the specified resolution rather than interpolated from a regular latitude-longitude grid online. It is also the data that is used when generating initial conditions using the
chgres_cubetool. See the files for example here.It would be nice if fv3config could handle this in an elegant way (the current workaround is to copy all the forcing files, both grid-specific and grid-agnostic, into a new reference directory, resulting in many redundant files). Perhaps we could create a new top-level field in an fv3config YAML file, e.g.
surface_climatology_files, for the root path to these files at different resolutions, similar to the orography data? Theforcingdata field would still be specified and would always correspond to the grid-agnostic reference files. There would be some redundancy in the files copied into the run directory, since old grid-agnostic versions of this surface climatology data exist as GRIB files, but the files used at runtime would be disambiguated by which files were specified in thenamsfcnamelist.