General topics
1. PRs to be merged that require coordination
- Refactoring of IODA engines, will require changing yamls for all obs
2. Containers: New spack-stack containers for next release. Need to know if packages are missing by Friday Sep 9
Naming convention for model variables
- See slides from Steve Vahl: ADD HERE
- Need model variable naming conventions, two options:
- CCPP standard names
- JEDI obs naming standard
- Proposal to proceed with CCPP standard names
- Discussion:
- Dan Holdaway: Is the proposal to move away from IODA obs naming conventions, or have two conventions?
- Have two - one for model vars, one for obs vars
- The only place where both are present is in obs operator (model var in --> obs var out)
- Tom Auligne: How much overlap between model and obs vars
- Atmosphere: moderate overlap
- Ocean: pretty-much 1:1
- Travis Sluka: Potential temperature? Potential temperature where? Is there a way to distinguish?
- CCPP standard allows to differentiate between those
- Tom A.: Why are there two different standards?
- Greg Thompson: When starting the IODA conventions, netCDF CF conventions where extremely limited for obs; bufr: good coverage and acceptance, and has correspondance with bufr codes
- Please don't change ioda/obs side of things
- No plans to change any of the ioda-obs names, the few places where both need to coexist can use either one
- Dan H.: Impact if using VADER in IODA for variable changes? Using different standards in both?
- Using VADER in UFO may be difficult - VADER is model-agnostic using atlas fields, but will require large code changes on the UFO side
- If model interface is responsible for name translation, then model naming convention stays in model space. Observation space does its name translations - seems like we can keep those pretty separate
- hofx when using identity operator - only need to translate model / obs names
- Tom A.: Definitely value for adopting another model variable naming standard. Are there other standards than CCPP that are suitable?
- Other standards didn't have nearly enough model variable names
- But CCPP also contains many names not needed in the DA world (but do we care if we don't need those)
- Will the adjoint require additional names? Likely not. bmatrix will use vader - will need a few additional names (balanced, unbalanced)
- Dan H.: Will CCPP standard be open to new names?
- CCPP standard is not considered to be complete and open to new names
- Ricardo Todling: How about chemistry?
- NCAR chemistry people were involved in the discussion, it is still to be determined whether the standard is sufficient or not (some think yes, some think no)
- Maryam Abdi-Oskouei: Think it's pretty sufficient for atmospheric composition, especially for the variables currently used in JEDI
- CCPP standard naming system can be extended to solve the problems that new users might have
- Tom A.: How flexible is the process to add new names to CCPP? Probably more flexible than bufr
- Relatively small group, thus pretty flexible and quick to adopt - so far NOAA and NCAR modeling groups
- Sarah King: Navy currently uses two different naming standards for model physics and DA
- Phil Underwood: UK MetOffice also has its own naming conventions for the model variables, need to consider another layer to map model names to JEDI names anyway - therefore it doesn't matter which names JEDI uses for the model
- Joanne Waller: At UK MetOffice also have a mapping for observation variable names
- Yannick Tremolet: Moving to use atlas field sets everywhere in the future - models will only have to use the correct names from the field sets in their metadata
- A summary of the discussion and plan will be provided for everyone to comment on later