Yannick opened the meeting, with no special announcements, and we proceeded to collect updates from the group.
Yannick started by announcing that he has a PR in oops that revises the YAML structure. This PR needs to go in before the upcoming JEDI release. The restructuring on YAML should not have any impact on results. Companion PRs (examples) for fv3, ioda and ufo will be provided. Note that the oops PR (feature/newyaml branch) is all that is necessary to start updating the model YAML files. We need to have everyone share the work of updating the remaining YAML files, which will hopefully limit the work for any individual to just a few files. We may start a JEDI team discussion in GitHub to coordinate the work.
David S asked for clarification about linking ZenHub issues and PRs to AOP Epics. The idea is to link all ZenHub issues and all PRs to an AOP Epic. We want to be able to track all of the work for management purposes and to facilitate generating periodic progress reports for funding agencies.
David S then asked for advice on how best to implement a super-ob process in JEDI. Super-ob is a process of judiciously reducing the number of obs (to help shorten runtime) by replacing a set of observations with a single representative. This is often done at locations where the density of observations exceeds the grid resolution. A lively and detailed discussion ensued among numerous parters (UKMO, NRL, NCAR) who are all interested in this topic. A guiding principle emerged which is to preserve the original obs values for traceability. Concerns raised included: how to track the reduction in the number of observations and changes in their location, how to keep original and super-ob sets distinct (so these can be used selectively in different parts of the flow), is it better to super-ob or to not super-ob, and whether to use standard names for super-ob (and other corrected obs) values. It was agreed that creating a new ObsSpace to hold the super-ob set was the best approach, analogous to variable changes. This naturally allows for the change in number of location of obs, leaves the original set intact, and keeps the original and super-ob set distinct. Yannick and Steve H added that the new IODA interface should be well suited for this approach and a PR should be showing up in July giving access to the new interface. David S asked if they should wait for the PR before implementing this. Yannick said the coding can wait, but you can start planning now how you might want to implement corrections to observations like this.
Mark M and Yannick reported on a new approach we will be taking to manage the AOP projects. There are five primary areas of work for JEDI (see table below) and we will be conducting bi-weekly meetings to track tasks and issues in ZenHub. The idea is to meet every other week, walk through the ZenHub boards and discuss status, roadblocks and plans for moving forward. This should facilitate the AOP work getting completed in a timely fashion, and facilitate generating progress reports. The bi-weekly meetings will have both JEDI core team and parter in-kinds attending. Here are the primary JEDI areas of work and the people who will be managing them.
| AOP Category | Description | Team Lead |
|---|---|---|
| JEDI1 | Infrastructure | Mark Miesch |
| JEDI2 | Observations | Ryan Honeyager |
| JEDI3 | Models | Dan Holdaway |
| JEDI4 | DA methods | Anna Shlyaeva |
| JEDI5 | Training and Support | Yanncik Tremolet |
Yannick noted that the OBS project is using the same methodology, and he asked that everyone fill in your availability in this spreadsheet on Google Drive. Questions came up, and here are points from the subsequent discussion.
- Tasks (ZenHub issues, PRs) should have the appropriate AOP Epic attached to them
- If it's not clear which Epic belongs to a task, you can contact the team lead or the JEDI core team for help. Or, you can wait for the team meetings and discuss it then.
- Only add people to the AOP meetings if they will be contributing to the work. It is ok if they are not explicitly identified in the AOP for the task in question, as long as they are actively contributing.
- The JEDI Weekly meetings will remain as they are, which are for a much wider audience than the AOP meetings
- We will try to start the AOP meetings in the week after next week (ie, June 22-26)
- Gives everyone a chance to fill out the spreadsheet before starting
- If you don't have access to the spreadsheet, contact the JEDI core team for help
Nancy asked if the team leads could be posted, perhaps on the JCSDA project page. Mark M suggested that we could define GItHub teams as a way to keep track of each of the five working groups.
Yannick closed the meeting at this point with a reminder to all to send in their ideas for the Special Topics meetings.