Yannick opened the meeting announcing that we will do a general round table update.
Yannick started by reporting on the new YAML updates. A few of the feature branches related to the new YAML updates accidentally got deleted earlier this week, and these have been restored and believed to be functioning properly. Be aware of this interruption and please report any issues. Yannick then asked for updates from those working on getting model configurations compliant with the YAML changes.
- Chris H requested help with a few YAML fixes (a few cases are not working properly) for the shallow water model. Anna will help.
- Clementine reported that fv3 test failures are appearing in the GNU Singularity container. These seem to be related to the recent CMake PR merges (i.e, not the YAML updates). Fv3 tests are passing in most other environments beside the GNU Singularity container. Mark O will help. (update after the meeting: this was solved by running "ulimit -s unlimited" - the problem arose because the new cmake now properly initialized OpenMP for gnu, a by-product of which is to allocate arrays on the stack);
- Guillaume asked when the merge of the YAML updates will take place. Yannick is targeting next week, but it will have to wait until all model updates are ready.
Hailing reported that the ROPP 2D obs operator, while using FV3, is broken. getValues is returning all zeros. This could be related to the recent getValues refactoring work. All the FV3 ctests are passing. The error shows up when manually running the H(x) application using data outside the JEDI test sets. Mark O will help with this, which will help cover his need to further develop GNSSRO capability in jedi-rapids.
Through the chat, Kristin asked whether there will be a special code sprint for the new YAML updates? Nothing is planned at this time as it seems model developers are making good progress on their own. If a number of issues surface that block model progress, we will organize a sprint to get things resolved. But, this will require a coordinated merge.
Mariusz had three questions to discuss, documented in the following slides.
Please see the slides for details. In summary, the first question is related to a confusing result when comparing c12 and c24 results where the increment was smaller at c24 resolution. There was some discussion which resulted in a caution about making too much, scientifically, out of these low resolution results. The c12 and c24 resolution setups exist primarily for unit testing, which is intended to be a suite of fast running tests exercising as much code as possible (i.e., not for scientifically validating results).
Mariusz’s second question was related to configuration of an FGAT run. Mariusz was wanting to center the assimilation on a particular time (day 15, hour 0), and be able to assimilate observations that are time stamped at an earlier time (day 14, hour 21). After some discussion it was determined that although 3DVar would handle this situation, FGAT is designed to have the analysis at the beginning of the timing window. If your window is day 14, hour 21 to day 15 hour 3, then the analysis should occur at day 14, hour 21. The FGAT scheme in JEDI would have to be modified in order to assimilate obs prior (in time) to the analysis.
Mariusz's third question concerned the obs bias correction function. He noticed that by changing the name of the obs bias data variable in the ioda file, he can get JEDI to use the obs bias data from the file, but he wanted guidance on the proper way to enable bias correction. A discussion ensued which yielded the following points. The data in the file with the "@KnownObsBias" suffix are the values from GSI and are being used for testing purposes (i.e., comparing JEDI with GSI). The obs bias correction code in JEDI is under development (by Xin) and is not fully functional yet. As a workaround for now, Mariusz can shut off obs bias correction in the YAML configuration, change the name of the variable in the file to use the "@ObsBias" suffix and JEDI will pick it up and use that data. For the short term, it was suggested that we add an option to JEDI to use the bias values from a specified variable in the ioda file since we do not want variables in the file with the "@ObsBias" due to this being a reserved name for internal use in JEDI.
Jianjun asked if the cloudy sky obs bias correction scheme currently in GSI will be handled by JEDI. Xin has completed (merged into develop branches) much of the obs bias correction functionality, and is currently working on the preconditioning part. Xin added that Emily has completed a lot of work with moving the GSI filter functionality into JEDI, including filters associated with cloudy sky. Xin and Emily will work together to make sure the GSI cloudy sky bias correction scheme is covered in JEDI.
Marek reported that their code base is now officially compliant with C++14 standards.
Marek also asked about an issue the Met Office ran into with the Atlas interface. There exists a variable in CMake, called ATLASIFIED, where if set to 0 the old (non-Atlas) interpolation interface is used, and if set to 1 the new Atlas interface is used. Currently, there is not a means to control ATLASIFIED on a per-repo basis of which Marek needs. After some discussion, it was determined that the ATLASIFIED variable is a temporary mechanism for developers to use while we are transitioning from the non-Atlas interface to the Atlas interface. ATLASIFIED will be going away once everyone is on the Atlas interface, so in the meantime the workaround is to edit the CMakeLists.txt files to set ATLASIFIED for switching back and forth between the two interfaces.
Chris H reported that he is ready to merge his shallow water PR containing updates to be in compliance with the recently merged CMake PRs. He requested help with a question that was posted in his PR, plus help with understanding how the new CMake structure and methodology works. Mark O will help with these requests.
Ryan reminded everyone to send in their list of accomplishments for the upcoming quarterly review (July 23rd) this week. For the AOP, JEDI is broken down into 5 main tasks (JEDI1-5) which are lead by Mark M, Ryan, Dan, Anna and Yannick (respectively JEDI1 through JEDI5). See these meeting notes for details. You should have received email recently from the leads requesting your list, and please send your lists to the appropriate lead.
Chris S asked if this process was going to be stable from now on. Yannick replied that we will continue with the process, and it was changed in order to track and manage the large scope of JEDI more effectively. In addition to the quarterly review reporting mentioned above, the process also includes bi-weekly meetings to discuss the status of ZenHub issues, prioritizing these issues, and organizing the work to get the issues resolved. Yannick added to keep the list of accomplishments concise and high-level, while the details of the work will be captured in the ZenHub issues.
For the astronomy buffs, Clementine mentioned that a comet is visible in the Northern Hemisphere. For Boulder, the view is in the north east, the brightest showing occurs between 3:30 and 4:30am MDT, is close to the horizon, and will be viewable until Saturday morning. See here for viewing tips
At this point there were no more updates, so Yannick closed the meeting.