Is your feature request related to a problem? Please describe.
When working with native grid output, auxiliary coordinate variables are essential for analysis. For CMIP publishing, these auxillary coordinate variables are required and routinely available.
For regular postprocessed output, FRE has a cultural tradition of a "static postprocessed file" for each postprocess component that contains static diagnostics, coordinate variables, and auxillary coordinate variables.
In legacy FRE, the static component pp file is generated from all statics probably associated with the component. Coordinate variables and auxillary coordinate variables that are in the history files will be in the timeseries and climatologies, but there is no mechanism for including other variables.
In modern FRE, the static component pp file is explicitly generated from a list of history files, and optionally a list of "offline source" files. e.g.
postprocess:
components:
- type: atmos
# temporal sources
sources:
- history_file: "atmos_month"
- history_file: "atmos_4xdaily"
# static sources from history files
static:
# all variables included if variables not specified
- source: "atmos_static"
# explicit list
- source: "land_static"
variables: ["land_mask", "sftlf"]
# static sources from offline files
# all variables included if variables not specified
- offline_source: "/path/to/my-static.nc"
# explicit list
- offline_source: "/path/to/a-second-static.nc"
variables: ["geolon", "geolat", "geolon_c", "geolat_c"]
A user reported that it would be useful to add/overwrite certain auxilllary coordinate variables to temporal output (timeseries, climatologies). The use case is native ocean and seaice output made available to collaborators who expect the auxillary coordinate variables to be in the temporal file, not in a separate static file.
A capability to add certain variables from an offline files to temporal output is requested. It could look like:
postprocess:
components:
- type: ocean
sources:
- history_file: "ocean_month"
- history_file: "ocean_annual"
add_custom_temporal_variables:
- offline_source: "/path/to/a-second-static.nc"
variables: ["geolon", "geolat", "geolon_c", "geolat_c"]
Describe the solution you'd like
Support adding custom variables to temporal (timeseries and climatology) output.
This feature is of general use and likely to be used by others.
Describe alternatives you've considered
Refinediag and analysis scripts are overkill and harder to maintain.
This
Additional context
Add any other context or screenshots about the feature request here.
Is your feature request related to a problem? Please describe.
When working with native grid output, auxiliary coordinate variables are essential for analysis. For CMIP publishing, these auxillary coordinate variables are required and routinely available.
For regular postprocessed output, FRE has a cultural tradition of a "static postprocessed file" for each postprocess component that contains static diagnostics, coordinate variables, and auxillary coordinate variables.
In legacy FRE, the static component pp file is generated from all statics probably associated with the component. Coordinate variables and auxillary coordinate variables that are in the history files will be in the timeseries and climatologies, but there is no mechanism for including other variables.
In modern FRE, the static component pp file is explicitly generated from a list of history files, and optionally a list of "offline source" files. e.g.
A user reported that it would be useful to add/overwrite certain auxilllary coordinate variables to temporal output (timeseries, climatologies). The use case is native ocean and seaice output made available to collaborators who expect the auxillary coordinate variables to be in the temporal file, not in a separate static file.
A capability to add certain variables from an offline files to temporal output is requested. It could look like:
Describe the solution you'd like
Support adding custom variables to temporal (timeseries and climatology) output.
This feature is of general use and likely to be used by others.
Describe alternatives you've considered
Refinediag and analysis scripts are overkill and harder to maintain.
This
Additional context
Add any other context or screenshots about the feature request here.