Yannick opened by declaring this meeting was a general roundtable, and that there were no special announcements.

Yannick started the roundtable by reporting that the YAML update was successfully merged, and so far there have been no major issues. Yannick asked if anyone needed help with the YAML update and there were no takers.

Wojciech has a set of PRs under review that lay the foundation for his effort to provide JSON schema based validation of YAML configuration files. The current PRs do refactoring of the Parameters classes in JEDI which is needed to enable the validation. Subsequent PRs will submitted soon that add the validate functions to do the JSON schema based checks. Wojciech said he would provide the ability to select from several JSON schema libraries since there is no clear winner among several library implementations. Yannick asked if the Configuration classes will be needed after these updates. Wojciech pointed out that the validation functionality is in C++ only, so the Configuration classes will still be needed for Fortran access. He also noted that any class that doesn't require a structured YAML (ie, arbitrary format) would be better off staying with the Configuration classes.

Mark O reported that he has been helping NCAR with a CMake configuration for MPAS jedi as well as the MPAS model code. This will enable building the full model and interface in one bundle build. The MPAS CMake configuration will depend on updates to CMake configurations for the core repos: oops, crtm, ufo, ioda, etc., and Mark reported that OOPS and CRTM are completed and IODA is close. Steve H added that he completed the final install directory reorganization in the ioda PR which works with jedi-build. Mark will test this and if it passes, then the IODA PR will be merged.

Mark O added that the GPTL library (runtime profiling) is a dependency of the MPAS repos, and a CMake findGptl script needs to be available to manage this dependency. Mark has created the findGptl script and after some discussion, he submitted the PR to the jedi-toolchains repo. He pointed out that ecbuild was another repo being considered, but it was decided that PRs to ecbuild should be about specific ecbuild issues and since the findGptl script is a generic CMake tool that can be used inside or outside of ecbuild it belonged in the jedi-toolchain repo.

As part of this work, the jedi-toolchain repo will become a general toolkit for providing cmake utilities such as modules and toolchains.  For this reason, it will be renamed.  The current plan is to call it jedi-cmake, and this will be added to all the bundles.  If you have any opinion on the name, please comment on Mark O's active PR in the jedi-toolchains repo.

Steve H reported good progress with the ioda-engines work related to ioda-converters. He and Ryan are working with EMC to develop an AMSU-A BUFR converter and they have a prototype working now. The output ioda file is being built, but it's not ready for assimilating in JEDI yet.

Steve H mentioned that the existing odb files in the S3 ioda test file set are from an experiment involving an alternate layout inside the file which is different from the UKMO and ECMWF layout. Some people have been confused thinking these were in the UKMO/ECMWF layout plus Steve noted that we don't want to move forward with this experimental layout, so he proposed deleting these files to eliminate this confusion. No one responded when Steve asked the group if there is anyone with objections to his removing the odb files from the S3 test file set, so he will delete those files.

Some discussion ensued after Steve's report. There is a lot of interest in the ioda converters, so it was decided that Steve will give a 1/2 hour mini tutorial during the next available special topics meeting (Thu, July 27th). Tom asked about the effort to create a converter using the new interface, and Steve responded that starting from scratch, it should take around 1 to 2 weeks. (This should be much faster with some examples that can be used for guidance.) Tom also asked if the UKMO odb file layout is the same as the ECMWF layout. They are essentially the same format, where the Met Office has supplemented the ECMWF format with some extra variables.

Hailing reported that a workflow for posting RO real-time obs data on S3 is in place. The source of the data is the GDAS datasets from the NOMADS website. The flow starts with BUFR files which get converted to ioda format and then uploaded to S3. Mark O added that jedi-rapids is set up to be able to pull these data from S3 and use them in the near real time system.

Hailing asked how to output zero hour restart files from fv3. Rahul responded that this cannot be done since the model needs to advance at least one time step before it can dump out the restart files.

Yannick announced that he has received requests to get updates from each of the JEDI AOP tasks. Yannick then said moving forward, the people managing the various AOP tasks give brief summaries during this bi-weekly meeting. Tom suggested that brief minutes could be taken at each meeting to help with the updates in this bi-weekly meeting.

JEDI1 (Infrastructure)

Mark M reported:

  • Mark O has made progress with CMake for MPAS, and jedi-rapids version 0.3
  • Maryam is developing running our CI build/test flow using the AWS code pipeline technology
    • This will be used initially for the periodic all model testing
  • Rick is working on modules for Orion, S4 and Discover and on setting up the NRT workflow on Orion
  • Sergey is using Cylc to run ensemble cycling using UFS
    • Includes testing inside Singularity container
  • Mark M reported that a new configuration is available for AWS (see active PRs in jedi-tools and jedi-docs for usage instructions)
    • Both single node and cluster modes
    • Inside and outside containers (Singularity and Charliecloud)
    • Provides a good development testbed
  • Xin and Ryan have been investigating Spack as an alternative to jedi-stack
  • NRL is transitioning to NEPTUNE2
    • Mark M has access now to the NRL machines

Tom asked what are the advantages of Spack over jedi-stack. Mark M and Ryan responded

  • Advantages
    • Platform independent
    • Ease of use
    • Supports lua and tcl script construction for setting environments
      • We have to do tcl script construction manually now
    • Fully reproducible build on any machine
    • Manages dependencies
    • Good for consistency
  • Disadvantages
    • Configuration (build recipes) are hard to modify (less control over config options)
    • requires internet connection

Chris H noted that Spack needs internet access which is not available on some HPC systems. Rahul mentioned that Spack is being disallowed on NOAA operational systems. Sarah added that NRL is using all tcl scripts for environment setting (also UKMO).

JEDI2 (Observations)

Ryan reported:

  • Wojciech is upgrading the Parameter classes to be able to validate based on JSON schemas
  • Ryan and Steve are developing ioda-engines (new ioda interface)
  • Various people are contributing improvements to filtering
    • DateTime checks
    • Bitset support
  • Meeting agendas are already being published

JEDI3 (Models)

Dan reported:

  • Discussed plans for August and metrics for July
  • fv3-jedi
    • Static B
      • Operational ensemble from Jeff W
      • Started training and comparing results with GSI
    • GEOS interface is near to enabling forecasting
  • NCEP
    • Cory is working on chemistry modeling
    • Mark Potts is working on UFS integration
  • Met Office
    • UM-jedi (Marek)
    • LFRic-jedi - adding in 4D applications
  • MPAS
    • Interpolation
    • Run assimilation with different resolutions for background and increment
    • Variable changes
    • B-Matrix
  • WRF
    • Holding pattern, lots of updates on interface
  • SOCA
    • Travis is performing scientific validation
  • Shallow Water
    • Chris H is doing maintenance, and adding in the utilization of the new Atlas interpolation interface

JEDI4 (DA methodology) and JEDI5 (Training and support)

Anna (JEDI4) is on PTO this week, so Yannick reported on both JEDI4 and JEDI5:

  • Public release of JEDI this October
    • Lots of cleanup PRs
    • Add in lots more tests and documentation
      • Ideally would do sprints together, but given COVID-19 will figure out a way to do these remotely
      • This effort is targeted for early September
  • Upcoming PR to clean up 3DVar YAML specs
    • 3DVar does not need the TL/AD model related configuration ("model object" section)
    • Only need the background
    • Will remove the model object specs from YAML for 3D applications

Tom emphasized that it is highly important to have good tests and documentation for the initial release. Doing this will decrease our support load later on. So please help with this effort when the time comes in early September, and/or before then if the JEDI team asks. Thanks!

Yannick closed the meeting at this point, and announced that next Thursday (special topic) Mark M will present on containers and cloud.

  • No labels