Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Mark M has been working on an Intel compiler issue related to "hidden symbols". See this JEDI team GitHub discussion and this ECMWF GitHub issue for details.  If you use the JEDI containers or environment modules then you do not need to worry about this - the issue is taken care of.  If you have your own installation of JEDI dependencies, then Mark pointed out that the JEDI team discussion includes 3 options for working around this issue. Please select and implement only one of the options.  

Mark M has a new environment module on Discover for Intel 17. Mark's module supplements those that Rahul has provided. Mark will help users get started for those interested.

Mark M has also been debugging an issue with MPT working with intel 19 environment modules on Cheyenne using Intel 19.0.5 compiler where parallel HDF5 (netcdf) fails during FV3-GEOS tests in fv3-bundle. The Intel MPI library (IMPI) does not experience this issue. .  The MPT stack installation failed because of build issues with HDF5 and intel.  But, there is a working intel19-impi stack.  ufo-bundle tests pass but the geos tests in fv3-bundle fail, apparently due to parallel io with netcdf4. Mark noted a curious symptom in that SABER tests using parallel HDF5 pass at the same time that FV3-GEOS tests fail.

Mark M reminded the group that a new Fortran OOPS variables module is available, deprecating the current Fortran module, and the model developers need to switch over to the new module soon. Mark noted that this has already been done for fv3-jedi and mpas.  Marek reported that this has also been done for LFRic, and Travis reported that this has not been done yet for SOCA. See this JEDI models GitHub discussion for details and instructions.


Xin has a PR under review for variational bias correction, and another PR is coming soon. He is currently validating the automatic generation of bias predictors in the correction scheme.  

Junmei has a PR under review which provides a workflow for running cycling experiments with MPAS using CYLC.


Guilluame noted that the templates for GitHub issues (reported earlier by Travis) came from NOAA. He also mentioned that they are working on reading the resulting H(x) values from FV3 into a SOCA DA run (question)(question).

Hamideh is working on identifying the causes of differences between GSI and JEDI for H(x) calculations. She has submitted ZenHub issues related to this work.

Hamideh reported that there exist some empty links on the website. Mark M has a tool to update links on the website. He will go run that tool after the meeting to get the empty links repaired.


Sarah announced that the Neptune grid has duplicate lat/lon values and they have been working to take this into account in the JEDI interface.  They also reported back about our python discussion from last week.  They confirmed that the visualization packages they use now are ready for python 3.6 and their cycl workflow implementation will soon be moving to python 3.6.  So, as discussed last week, if we adopt python 3.6 as a required minimum version for JEDI tools and applications, then NRL will be ready for that.


At this point the updates were complete and Yannick opened the floor to questions.

Travis reported that the GitHub issue templates don't show up in ZenHub, but he suggested that the templates should work in ZenHub. Mark M will look into whether ZenHub supports the GitHub issue template feature. If this looks compelling, we will try it out in the other JCSDA repositories. (Update: Mark M and Phil confirmed that the templates are integrated with ZenHub and can be used when you open new issues in ZenHub; we will consider whether or not we wish to use such templates in the future but, in any case, it is good to know about them).

Mark M announced that we are linking ZenHub issues into an AOP board through the ZenHub Epic mechanism. This is being done to improve our ability to report our progress to our stake holders. Mark reminded the group that when a new issue is created, to please fill out the Estimate and Epic (ie, link to an AOP Epic) fields need to be filled in. If the AOP Epics are not visible on your ZenHub board, you likely need to add AOP to the ZenHub workspace you are using. Please note that several workspaces (eg., DA, JEDI Observations) already exist that include AOP so it might be a matter of simply selecting one of those workspaces. Another tip is to add an AOP column to your ZenHub board which will help navigating through the collection of Epics and issues.  Note - this primarily applies to JCSDA team members; in-kind and collaborative contributors need not worry about attaching issues to epics that concern the JCSDA Annual Operating Plan (AOP).  In the future we may create new epics for in-kind and collaborative contributions and if and when we do so, we will let you know.

Marek asked for guidance with the ZenHub Estimate values. A non-linear scale, in units of "story points", is presented that you have to select from. One rule of thumb is to say that one story point is roughly a 1/2 day of work. Another tip is to think of the story point values as relative effort. For example the addition of a single ASSERT to flag something that was badly formed is a task that would be expected to take less effort than something like adding a new QC filter. In that case the ASSERT work should get a smaller story point value than the new QC filter. Regardless of how the story points are viewed, we are just starting out on this methodology and we will get better at estimating effort as we go along, and the key point is to get started now with the practice of providing estimates.