Neill Bowler: code sprint next week; flipping of geovals order to be top to bottom
- If UFO is presented with obs bottom to top, should it flip them or fail with an error message?
- Yannick: It should abort so that we capture these issues and don't need to carry along these hacks
- Question came up because the utility to flip it will be retired
Joanne Waller:
- #1778 (Decouple filter variables and simulated variables)
- Example pressure: observed
- sea level pressure
- pressure at station height
- standard pressure
but only derived pressure (from the above three variables) is assimilated and needs an H(x)
- Q&A:
- Yannick T.: Using a list of monitored variables is explicit and easier to understand
- David S.: Both approaches (monitored variables vs qc-out) leads to the same result
- Greg T.: It's unlikely that one variable is monitored entirely, depends on the type/instrument (e.g. qualifiers associated with the variable)
- Ben R.: The original issue (assimilated variables) should be addressed first, let's not have the monitoring question get in the way
- Steve H.: These are UFO controls. Does it make sense to have all controls under the obsspace section?
- Ryan H.: UFO is driving all of this, but it touches many IODA classes, can see yaml based instructions in both places
- David S.: Should be a UFO control
- Anna S.: Simulated/assimilated variables are used to create ObsVectors (for obs values and hofx) at oops level
- Ryan H.: Need to know what we want to write out from IODA (metadata) before we start processing?
- Yannick T.: IODA shouldn't know anything about the UFO controls; IODA should be a base for data handling, transforms (science) should be in UFO
- David S. Doing variable transform in UFO gives greater flexibility than doing it in IODA
- Lee H.-S.: We have observation processing steps, transformations and derivations etc. which require model information
- Greg T.: Do we really need three different categories? Have just two lines: assimilated and observed (only assimilated needs H(x)), no need for "derived variables"?
- Joanne W.: Having a derived variables list makes it explicit what has been calculated versus what is processed input data
- Please add your comments to the issue, MetOffice would like to start working on the original issue (derived variables). Slides will be added to the issue
- #1777 (Use mapping file to associate IODA variable names with GeoVal names)
- Yannick: Should this be a model specific decision?
- getvalues has to respond to the names that come from the IODA convention, and the model interface can do this variable mapping in the way it wants
- David S.: In the long term, everyone should adopt the GeoVal naming convenetion, the mapping file would smoothen the transition
Chris Thomas:
- #1675 (Filter ordering): WYSIWYG filter orderning
- Current way to construct yamls for obs filtering is confusing, in particular the "defer to post" option
- Proposing WYSIWYG filter orderning, have three sections: obs pre filters, obs prior filters, obs post filters
- Code needs to throw an exception of a variable is in a phase where the required data isn't available
- Q&A:
- Steve H.: When specifying a list of filters in one section, will they be processed in the order listed?
- Chris T.: Yes. (This is already the case)
Capture of Google Meet chat:
Anna Shlyaeva 9:27 AM
Good point. I think "assimilated variables" could be outside of obs space (at the same level)?
Anna Shlyaeva 9:29 AM
simulated/assimilated variables are used to create ObsVectors (for obs values and hofx) at oops level.
Lee Hawkness-Smith 9:35 AM
We have observation processing steps, transformations and derivations etc. which require model information
Dom Heinzeller 9:46 AM
Could the mapping file be optional, and if omitted assume identity?
JJ Guerrette 9:50 AM
FV3 and MPAS both have mappings between model state variables and GeoVaLs. YAMLs are involved
Steven Vahl 9:50 AM
This issue is going to arise again when VADER is implemented, which will also need its own set of variable names.