Yannick opened the meeting by announcing that this is the first day of our 2021 AOP. The JCSDA Annual Operations Plan follows a cycle of April 1 through March 31 so today is the first day of the new cycle. This means that there are new JEDI tasks and new Zenhub epics to reflect the plans for the coming year. Tom gave an update of the status of the AOP document itself, which was sent this week for final review and approval by the MOB. Tom said the comments from the MOB and ET have been very supportive. After approval (soon), we plan to make the AOP document public so you will soon be able to see the details and your designated role.
The last AOP had 5 principle JEDI teams, or projects. Now there are 4:
JEDI 1: Software Infrastructure (Lead: Mark M)
JEDI 2: Model Interfaces (Lead: Dan)
JEDI 3: Algorithms (Lead: Anna)
JEDI 4: Infrastructure for JEDI experiments (Lead: Yannick)
There may be a slight reorganization of who appears in which team meetings. After the AOP is made public, you can review the objectives of each team and determine which of the team meetings you wish to participate in.
The labels in ZenHub have already been modified to reflect this new organization. The main reason for the reduction in JEDI projects from 5 to 4 is that the "Use of Observations in JEDI" (previously JEDI 2) has been moved to the OBS project (OBS3), where Ryan will continue as lead.
Though the AOP document is not public yet, the new ZenHub epics are already in place, in the AOP21 Github repository. This repository has already been added to the JEDI ZenHub workspace. If you work in a different ZenHub workspace, make sure that AOP21 is included so you can assign issues to the AOP21 Epics.
Yannick then announced the main topics of this focused topic meeting:
- Transition to IODA 2.0
- Transition to latest ecmwf releases of ecbuild, eckit, fckit, and atlas
Both of these are related to our next planned public release of JEDI (FV3), version 1.1.0, which will hopefully occur by the end of this month.
Both of these items will likely require changes to your repos
Steve presented the following slides that highlight the new features of IODA 2.0 and what models and other repos need to do to adapt.
One of the main take-aways is that any ioda files you work with will have to be converted to the new ioda v2 format, which expresses radiances and other fields as multi-dimensional variables. Eventually ufo geovals files will also use this multi-dimensional, ioda-engines format as well but not until after the release. So you can leave your geovals files as is for now.
The ioda v2 code has not yet been merged into develop. It currently sits in feature/ioda-v2 branches of ioda and ufo. Building this branch of ioda will produce a new executable called ioda-upgrade.x that can be used to convert ioda v1 files to ioda v2. See slides for details.
In association with the move to ioda v2 we will also be introducing new test data repositories, ioda-data and ufo-data. These have already been updated to ioda v2 format. So, if you'd like to see how the files have changes you can compare the files in these repos to the current data files. But the data in these repos have been rearranged somewhat so that they are independent. So, ufo ctests will no longer require test data from the ioda-data repo; all test data needed by ufo ctests should go in ufo-data and similarly for ioda.
After these branches have been merged, there will be a new procedure for updating the test data files. If you have a feature or a bugfix branch in ufo that requires a modification of the data files, then you should create a branch of the same name in ufo-data that has the modified files. Similarly for ioda. For now it is just these two repos that are organized this way. In the future we may take a similar strategy for saber, fv3-jedi, and other repos (if this works well) but not for this release.
After Steve completed his presentation, Yannick asked if we are ready for a possible mini code sprint where Steve, Ryan, and others can help model developers make the necessary changes to their repos. Steve confirmed that we are essentially ready now. So, we tentatively made plans to schedule such a sprint next week. If you are interested in participating, email Steve by Friday afternoon.
Chris S then asked about processing output from JEDI. Since this will now be in ioda v2 format, will we need to change our diagnostic tools? The answer is yes. Output files that contain radiances, for example, will now contain 2D arrays. It was then suggested that it might make sense to have two different efforts, possibly two different 1/2-day or 1-day mini-sprints, focusing on:
- processing ioda input files (applications)
- processing ioda output files (diagnostics)
Let Steve know by the end of the day on Friday which of these you might like to participate in, if any, and we will plan accordingly.
Sergey also brought up the issue of obs ensembles, which will have to be converted separately. But, he said this could wait until after the code sprint.
Mark M then gave a brief overview of what is required to move to updated versions of ecbuild, eckit, fckit, and atlas. The principle reason for this is that we would like for the public release to access the ecmwf releases of these packages instead of our internal forks.
The principle challenge of this migration is ecbuild itself. Version 3.5 contains modifications that will not work with many current JCSDA repositories (after the meeting Mark M realized that ecbuild 3.6.1 has been released so we will now target this version).
For further information the best place to start is PR #72 in jedi-stack. This in turn has links to two other PRs in ufo (merged) and fv3-bundle (pending) where you can find further information and examples of the changes that have been made.
Some of the essential changes include:
- project() commands now require version numbers
- ecbuild_use_package no longer exists in ecbuild. Switch to find_package.
- ecbuild_add_cxx11_flags no longer exists in ecbuild.
- Package names are lowercased
- many include directories are not properly propagated to dependencies, requiring explicit target_include_directories() commands.
the develop branch of ufo-bundle already builds with the new ecmwf release versions. fv3-bundle requires the feature/ecbuild35 branch. Most of the associated fv3-bundle PRs are backward compatible and will likely be merged soon (with the exception of fv3-jedi itself, which is currently failing CI - we're looking into it).
Then there was some discussion of a possible mini-sprint to implement the ecbuild/eckit/fckit/atlas upgrade, including questions like: are we ready? Should it be combined with the ioda v2 sprint(s)? Does this require coordinated merges with ioda v2? It was agreed that the ioda v2 sprints should occur first and those branches should be merged first. This will expedite the move to ioda-engines and address the current inefficiency in updating the test data.
Furthermore, in order to implement the ecbuild/eckit/fckit/atlas migration, first the HPC modules (all platforms) and containers need to be updated to include these latest releases. Furthermore, since we now plan to use tagged versions of fckit and atlas, then these should be included in the HPC modules and containers (by default) rather than being built with the bundles as they were before. So, it will be approximately another week before we will be ready for an ecbuild/eckit/fckit/atlas mini-sprint. If people are interested, we can tentatively plan for some time in the week of April 12-16. Email Mark M if you are interested in participating in a ecbuild/eckit/fckit/atlas mini-sprint (probably 1/2 day).
Travis said it would be useful to have a docker container that has the new ecbuild/eckit/fckit/atlas. Mark agreed this should be a priority and will generate such a container for testing.
It was also suggested that we should update odc. This was agreed, though this is typically no longer included in the JEDI modules and containers (let us know if you want this changed).
After the main topic discussion there were a few more points made. Yannick brought up the recent change to the Hofx application in oops, which greatly improved performance. He plans to make similar changes to the other applications. He will try to minimize the downstream changes but there will likely be some changes needed. Your reward for making these changes will be much faster run times. Stay tuned for further details and pull request beginning next week.
Mark M and Yannick also announced that we will no longer be using Milestones in ZenHub/Github. Instead, we will be using a new feature of ZenHub called sprints. These have benefits over milestones for facilitating project management and agile workflows. Each sprint will be two weeks in length and, at any given time, only three sprints will exist (covering the next 5-6 weeks). Longer-term planning can be handled by prioritizing issues in the backlog column. Further information will be provided in the biweekly team meetings.
The meeting was then adjourned.