Yannick opened the meeting with a 2-slide presentation on the topic of the change variable functionality. Here is a copy of his slides:
The first slide is on the change variable interface, and the second slide presents several use cases. There were a number of questions that came up during the discussion. Following are clarification points that resulted from these questions.
- The change variable functionality is general purpose (e.g., not limited to a particular application such as 4DVar)
- The two methods that allow the client to set input and output variable lists are optional
- For example, the setting of these variable lists could be done in the constructor (of a particular subclass)
- There is a 3DVar flow in JEDI that is currently using this interface
- During minimization, the variables being changed are increments
- During processing of model data, the variables being changed are states
- (in response to a question by Guillaume) - the variable changes for linear and nonlinear instantiations are separated in order to be consistent with the general design of other JEDI components
- Adding change of variables in your particular model/application should not hurt (break) anything but it will require code modifications to take advantage of
- On slide #2, the dashed box on the left marked with 'B' refers to the B-matrix
- BUMP is a piece inside the 'B' box that is associated with the unbalanced variables
- the variable changes depicted in the box are in the B matrix but outside of BUMP
Next, the floor was opened to general updates from everyone.
Steve H announced that the resulting requirements that were collected from the recent IODA Workshop are being process using ZenHub. Several categories (e.g., Security, Flexibility, Reliability) have been defined as Epics in ZenHub. An Epic is a longer term objective as compared to a Milestone that represents a focused, short term objective such as a code sprint. All of the specific requirements will be entered as issues, and each issue gets associated with an Epic. Then as the issues are addressed in code updates, the Epic can be viewed to see the overall progress toward that long term objective. Mark added that this is work in progress, and if anyone wants to add a requirement (as a ZenHub issue) to any of the Epics that have been defined, please feel free to do so.
Steve H is also working on refactoring the ObsSpace with two goals in mind. The first is to provide an interface to the IodaIO class for the software that converts external obs files (NCEP, GSI, GODAS, etc.) into files that IODA can read. This way all conversion scripts and IODA will use the same IO interface. The goal is to finish this work in time for the upcoming marine obs code sprint (roughly a month from now). The second goal is to generalize the memory store so that new complex obs types can be handled. An example is the ocean wave spectrum obs type where each location is represented with a 2D array, whereas the current memory store only handles a scalar at each location.
Steve V has added to UFO a test for the AMV (satwind) obs type. He is currently working on adding the ECMWF ODB2 file format to his scripts that convert Met Office ODB2 files to the IODA file format.
Chris S reported that they are starting work on a surface obs operator for UFO. He will create a discussion on GitHub for the purpose of determining the best way to do a surface obs operator, and he encouraged anyone with ideas to participate.
Chris S also announced that they are starting work on static-B. He asked if he should use the current change variable code that Yannick presented, or should he wait. Yannick advised him to start with the current version (develop branch) and the change variable functionality will evolve as needed. Chris said that they will be focusing on transforms inside the 'B' box (B-matrix) first. Yannick added that the change variable scheme can be used to chain multiple transformations, making it a powerful mechanism.
Mark is working on getting software to build and run on AWS using the Intel compiler. Standalone FV3-GFS works with both OpenMPI and Intel MPI libraries. JEDI compiles with both OpenMPI and Intel MPI libraries, but there are several lorenz95 test failures (slight differences in expected output). Mark is going to try a similar experiment on Cheyenne using the MPT MPI library and see if this can help debug the test failures on AWS. When he gets it working, the MPT build on Cheyenne may also help with the performance issues JJ presented last week. If anyone has already gotten JEDI to build and run on Cheyenne with intel compilers and the MPT MPI library, please let Mark know.
Xin is working on bias correction in JEDI WRF and is expecting to have a preliminary implementation running next week.
Ming reported that the JEDI WRF model interface is working on Cheyenne for the Intel compiler, but not working for the GNU compiler. The hofx function is under development, but he is running into an issue related to location data. Once the hofx is working, he will attempt 3DVar.
Junmei is developing the flow to do GNSSRO obs operators with MPAS. She is currently working on extracting geopotential height from MPAS (geopotential height is not native to MPAS).
Maryam has submitted a pull request that provides examples of BOOST based tests replaced with ECKIT based equivalents. The goal of this work is to eliminate all BOOST based tests. Once this pull request is merged, it will provide examples for others on how to replace their BOOST based tests with ECKIT.
Jim ran into several issues with ufo-bundle this past week using the latest develop branches. A number of tests have failed with error messages suggesting that memory is being mishandled (double free, malloc invalid chunk size, etc.) These faults only show up when building in Debug mode. These do not show up when building in Release mode. Debugging is underway. Jim recommended that when people test their code, to try both Debug and Release mode in order to catch these problems earlier. A particular QG BUMP test reported an array bounds violation in the Debug build mode. Benjamin has a fix for this issue staged in a pull request into OOPS. Chris H pointed out that this is a reason to prefer Debug mode when developing code, i.e, you get much better error reporting.
Travis is new and is booting up on JEDI and the marine flows and obs operators. He will be working on the ocean model and coupled DA.
Clementine is working on block ensemble DA, and is running into an issue where the run diverges after several outer loop iterations. She is currently debugging this issue.
Dan is implementing the 4DVar variable change flow (analysis state to model state) for FV3 and asked for help with passing around variable lists to various stages of his flow. Discussion ensued, a number of options came up, and it settled on Dan will take another look and Yannick will be available to help.
Dan is also working on interfacing FV3-GEOS with JEDI.
Guillaume was in Colorado this past week working with Travis, and he is preparing for the upcoming marine code sprint. The code sprint will take place March 25th through April 6th in Boulder.
Stylianos announced that they are working on new marine obs types from 3 satellites. They are working on the conversion of the corresonding obs files into the IODA format with new Python code. This effort is being coordinated with the development of the shared IodaIO interface.
Andrew is looking at Anna's GSI conversion to IODA flow. He is running into some issues with AMSU-A conversion, and is currently working to resolve these. He announced that EMC will be ramping up effort to implement various radiance obs operators. Andrew will be training new contributors, and is planning two mini code sprints, the first to begin on March 18th.
Hui reported that she and Hailing have completed the GNSSRO 1D and 2D obs operators, plus they have completed the associated QC filtering. Next they will work on GSI TL/AD testing.
Steve S is working on the JEDI LFRic model interface. They have the transform from model fields to colocated fields running, as well as 3DFGAT. They are currently reviewing and verifying these results, looking at states and increments. Steve mentioned that he will let Marek (who was absent) know about Chris S's request for help with surface obs operator design.
Chawn reported that Marek is putting together a program for Yannick's visit to Exeter in a couple weeks. They are starting work on obs processing for several satellites. Chawn has prepared a flow diagram, and a power requirements document for the satellites in preparation for Yannick's visit. He will send these to Yannick soon so Yannick can review them before his visit.
Sarah is working with John Mikolakus (sp?) to refactor NEPTUNE for the purpose of facilitating the implementation of the NEPTUNE JEDI interface.
Chris H has made progress with the shallow water toy model. The Geometry and Model interfaces are done, and the State and Increments interfaces are work in progress. He might refactor the shallow water model to make it easier to finish the interfaces. One benefit of refactoring the model is it should yield insight on how to design new models to be more amenable to integration into JEDI.
Yannick will be absent next week.
We plan to hold this meeting next week, along with the JEDI junction session.