Static Variable / File Conventions

[jkrasting]

Static fields continue to be an issue for modeling components with non-uniform grids. As I am exploring the integration of OM4Labs into the MDTF Framework, I have encountered an inherent limitation (inconsistency?) between how the MDTF Framework data manager and GFDL's file constructs.

The MDTF assumes 1 variable per file, consistent with CF conventions. Two-dimensional coordinates, if they are included with the variable are currently supported. This is almost always the case with CMIP and NCAR-formatted data.

GFDL, however, breaks out these coordinate variables into separate, time-invariant static files. In the case of the ocean model, the coordinate variables and grid metrics are duplicated across different grid point types: i.e. cell centers, u & v velocity points, and corner points. The static file often ends up with several dozen fields. Attached is the output of ncdump for one of the ocean_monthly.static.nc files.

The question is then: How best should we handle the definitions of static fields from the MDTF Framework when it comes to interfacing with OM4labs?

OM4Labs accepts the ocean.static.nc file as a run time argument. In the case of running with GFDL data, we need to find a way to pass-through this file to OM4Labs. When running with CMIP, or NCAR formatted data, we then need a way to aggregate the coordinate variables and grid metrics and into a static.nc-like file to pass onto OM4Labs at runtime. I think changing the OM4Labs interface to declare every individual grid variable is too cumbersome.

Any thoughts on implementation strategies for these ocean static fields @wrongkindofdoctor, @raphaeldussin, @aradhakrishnanGFDL, @Wen-hao-Dong ?

[wrongkindofdoctor]

@jkrasting Expanding on the description of the current behavior, the framework will read files with multiple variables/coordinates (and assumes that the file name contains the target variable using the default LocalFile data_manager setting). It ignores file variables/coordinates that do not correspond to the target variable. The Model Data Sources documentation provides more details.

[jkrasting]

See PR #363.