Today's main agenda item was to discuss how do we best handle code changes that affect all the models.  For example, changes to high-level interfaces in the oops::, test:: ioda:: and ufo:: namespaces may require corresponding changes in the model repositories in order to ensure that they are still compatible.  We'd like to minimize these changes but sometimes they are necessary for the project to move forward. 

Yannick said that he did not want to rely on email lists for this because they are difficult to keep up to date.  Instead, we should keep people informed through GitHub teams.

Currently there is a GitHub "Super Team" that includes all members of the JCSDA organization on GitHub.  Yesterday Yannick posted a notification to this team with the heading:

[JCSDA/jedi] Updates that might break tests (#2)

This was posted on GitHub but you should have also received an email with this header. Going around the table, some people remembered receiving this email and others did not.  

If you did not receive this email, please check your GitHub settings to ensure that notifications posted to the GitHub teams will be forwarded to your email.   Mark (miesch@ucar.edu) and Steve (stephenh@ucar.edu) are happy to help with this if you wish. 

In the future, this will be our main mechanism for communicating high-level code changes that effect all repositories (no other suggestions were offered).  So again, if you don't already have email notifications set up on GitHub, please do so.

Then Mark reported a high-level code change that will have implications across all repositories, namely a new interpolation test.  This is now included in the State test, along with the tests of the State constructors.  Since it is not yet fully implemented for all models, it will likely cause your State tests to fail. Over the coming days, Mark will work with you to implement it fully into all the models.

The rationale behind the new interpolation tests follows these steps:

  1. Initialize the JEDI State object based on idealized analytic formulae
  2. Interpolate the State variables onto selected "observation" locations using the .interpolate() method of the State object. The result is placed in a JEDI GeoVaLs object
  3. Compute the correct solution by applying the analytic formulae directly at the observation locations.
  4. Assess the accuracy of the interpolation by comparing the interpolated values from Step 2 with the exact values from Step 3 

So, in order for this to work, an analytic initialization needs to be implemented both in ufo (for GeoVals - step 3) and in each model (Step 1).  Currently the only models that are equipped for this are qg, L95, and FV3.  We will start with the horizontal winds u and v but the test can be set up to test any variables you wish. 

Then Yannick made an another important announcement:

The OOPS repo will be moved from UCAR to JCSDA on Saturday

This is the last step in our migration to the JCSDA organization on GitHub.  After this, there should be nothing left on the UCAR organization that you need.

This has some important action items for you:

  • Please commit and push your changes to OOPS to GitHub before this weekend so all branches can be properly migrated
  • On Monday, please clone again your oops repository from github.com/JCSDA.  

Make sure the CMakeLists.txt file in your bundle points to JCSDA instead of UCAR.  Soon we will rename the UCAR/oops repo so ecbuild will fail if your bundle CMakeLists.txt file is not properly updated

Questions then arose as to the fate of the eckit, fckit, and ecbuild repos on UCAR.  These will not be migrated to JCSDA.  Instead, we will use the main repositories at ECMWF, which are public and continually updated.  If we find the need to make changes in any of these repos we will create forks as needed.  However, this is currently not needed.

The floor was then open for other issues and we received an update on the activation of Git-LFS on Theia.  Guillaume opened a ticket to set up the proper security protocols but Chris mentioned that there was still some uncertainty about which ports needed to be enabled in order for Git-LFS to transfer files. 

Yannick pointed out that Git-LFS is now working on Discover and asked if we could determine the ports from there.  Chris replied that NOAA's security protocols in this respect are more stringent than NASA's, blocking both inbound and outbound transfers without explicit permissions.

Then there was a final question about an oops modification that allows for an extra argument to pass the linearization state to the interpolation in oops.  Yannick said that this is already implemented in the feature/nicas-pptraj branch of oops and encouraged users to test it.


 

  • No labels