Yannick opened the meeting reporting that the problems with the Singularity container have been fixed so please be sure to pull the latest image file if you plan to work in the container.
Then Yannick announced that he merged a number of branches into the develop branch of oops yesterday (including develop-next).
There were also may recent changes to ioda and ufo that have been merged.
Warning: The new develop branches of oops, ioda, and ufo have several changes that may require changes in your models.
One change to oops that will require changes in models is the Model header has been removed from the Traits file. Model objects are now registered by means of a ModelFactory in oops/src/oops/base/ModelBase.h. A consequence of this is the need to specify the model name in the configuration file.
This has been implemented in qg and fv3-jedi so please refer there for examples of how to implement this change. It may also be beneficial to look at the changes made when the recent Feature/modelfactory pull request was merged into oops develop.
Then Marek and Dan brought up two changes in ioda that have been causing problems for some users. Both have to do with the April 15 radiosonde data files.
The first has to do with the naming of the temperature variable. Marek and Dan were under the impression that there was a change in variable name from Air Temperature to virtual Temperature. Steve (H) mentioned that Air Temperature should still be used in the obs data files but virtual temperature is used for the GeoVaLs.
The second problem is that the obserror field appears to be missing from the April 15 radiosonde data files, which can cause an error upon reading them. Possible fixes include adding the obserror back in to the files or adding an option that allows the user to set the R matrix equal to the identity matrix if the obs error is missing.
Steve and Dan made plans to sort out both issues later today.
Dan mentioned that, until recently, fv3 tests did not really test the reading of the obs files very comprehensively. So, it was easy for the obs error problem to go unnoticed. Several tests have now been added to fv3 to test the reading of the obs data files more thoroughly.
The target timeline for moving completely to the new version of oops develop is the end of next week (Sept 21). After that date, all other develop-* branches will be deleted, provided that no other problems arise with the new develop branch. So, please test the new develop branch and please let us know if there are any other problems.
Then Guillaume brought up a possible memory leak in bump. When run on one processor, he was finding that the bump initialization ran out of memory. Marek may be seeing a similar issue. Yannick recommended that they ask Benjamin M about it.
Steve S then mentioned that he was having problems with the develop-bump branch of oops that had previously worked. Yannick mentioned that he has not worked with that branch in a while. It will become obsolete by next week.
Then Marek mentioned that he was seeing new warning messages regarding base classes such as util:Printable and boost::noncopyable. Rahul mentioned that these base classes have now been incorporated into a higher-level ModelBase class. The warning messages likely arise because the lower-level classes cannot redefine the higher-level base classes. Again, look to qg and fv3-jedi for examples on how to handle the new structure.
This was followed by a discussion of where we stand with building and running JEDI using intel compilers - specifically Intel versions 17 or 18.
Many users have reported that JEDI (specifically ufo-bundle) builds and runs with Intel 17 but does not work with Intel version 18. Specifically, Dan mentioned that JEDI does not build and run successfully with Intel version 18.0.0.163 
on Discover.
Chris H mentioned that there are two versions of Intel 18 on Theia and recommended that users try moving back one version from the latest.
Yannick then noted that Xin is working on redesigning the test framework so that we no longer have to rely on boost. In the future, we will make use of the boost headers but not the compiled binaries. So, in the future, we will merely have to download the source code and copy the header files to an appropriate location, with no compilation necessary.
Guillaume then mentioned some ufo test failures in the container. Others have found ufo tests to pass in the container. So, make sure you have the latest container image and the latest develop branches. If you're sure that you are using the latest versions of everything, please document problems and let us know.