Yannick opened the meeting announcing that today's topic will be about a design proposal (enhancement), from the Met Office, concerning the UFO QC flag management. David Simonin gave the following slide presentation.
David also supplied the following document which provides more details about the design proposal.
In summary, a need to enhance the QC flag management was recognized to address four identified requirements, two of which come from the DA flow itself and the other two from diagnostic and monitoring purposes. The four requirements are:
- R_1: Accept/Reject - This flag denotes if an observation will be handed over to the DA flow
- R_2: Active/Passive - This flag denotes if an observation handed over to the DA flow will be used during minimization
- R_3: Reason for rejection - Associated with Accept/Reject flag
- R_4: Additional information - Used by monitoring system, independent of Accept/Reject flag, user defined
It was noted the the system already can handle R_1 and R_3, so the design enhancement is focused on R_2 and R_4. The main feature of the enhancement is the introduction of a new flag mechanism (called Diagflags) that hold key/value pairs. The key/value pairs would be user programmable (through YAML) so that each operating center could have their own set. Two implementation options for Diagflags were also offered. The first based on using variables in an ObsSpace, and the second based on a DiagflagsManager similar to the existing QCflagsManager. Please see the slides and document for more details.
During the presentation a suggestion to handle "passive" observations (ones that get handed over to the DA flow, but not used in minimization) by inflating the ObsError for those observations to the maximum float value. This seemed a simple way to have these observations have no impact on the minimization. Several people noted that doing this can sometimes result in a subtle, hard to trace impact and it is cleaner to actually remove the observation from the minimization step. It was generally agreed to not use this error inflation technique on the passive observations and instead make the minimization step "aware" of passive observations.
Discussion of the active/passive flag came up with the primary question being if an obs is marked "passive" can it still be used in the VarBC step? The consensus appeared to be that the active/passive flag needs more levels than just "active" and "passive" so that control can be specified for both the VarBC and minimization steps. Three levels were proposed:
- Active: use in both VarBC and minimization
- Partially passive: use in VarBC, don't use in minimization
- Fully passive: don't use in VarBC, don't use in minimization
Neill B asked if implementation option 2 (DiagflagsManager) would offer more flexibility than option 1 (variables in an ObsSpace), and gave an example of where that might happen (please see chat room notes below). Wojciech responded with an explanation of how Neill's example could be accomplished with option 1.
There was general agreement that implementation option 1 (variables in an ObSpace) was the best one to start with (much less work). There was also general agreement that the original ObsSpace (created by the ioda reader) was the best place to put the flag related variables since this would allow the current output to simply pick up the new flag related variables. One caution with using an ObsSpace is that we want to avoid storing intermediate variables in the ObsSpace. It was agreed that this would not be an issue for this proposal since it would be easy to limit the variables stored in the ObsSpace to those that we want for monitoring and diagnostics.
Here is a snapshot of the chat room comments: