Closed jiaruidong2017 closed 6 days ago
The updated JEDI:
/scratch2/NCEPDEV/land/data/jedi/fv3-bundle-20221103/build/
Modules used in GDASApp:
/scratch2/NCEPDEV/land/data/jedi/GDASApp_modulefiles/
README file:
/scratch2/NCEPDEV/land/data/jedi/readme_fv3_jiarui
Thanks @jiaruidong2017. A few things:
1a) I thought Cory was now working with a specific release of JEDI, and not the latest develop? @CoryMartin-NOAA? In which case, that's the version that we want here (and the readme should also be updated to include the details for cloning that release).
Do we need to copy the module files locally? I asked you to provide instructions on how to load the new module files, not necessarily to copy them.
The next step is to update the yamls in the offline system, and then check that the test passes. Also, please make sure that any yamls not included in the test are also update so that they'll run with the updated JEDI.
@ClaraDraper-NOAA right now we are using a fixed set of commit hashes in GDASApp. However, soon we will have three options:
I think we should go with number 3 as the default for land DA.
@jiaruidong2017 if you can run JEDI with the version you just compiled on the land directory and the namelist that you generated from the GDASApp, then we can just use that for now. Otherwise, please switch to the same set of commit hashes that GDASApp is using.
@ClaraDraper-NOAA agreed. The idea was that 1 would be for dev of things like UFO or FV3-JEDI, 2 would be to make sure there is something recent that will work and 3 is for science/general users
@ClaraDraper-NOAA As we talked in today's meeting, I don't have permission to update the readme file. I created a new readme file with the necessary changes, and you can merge the changes into your readme file.
There are some differences in the ecbuild command, and I added the steps how to get and load the the GDASApp modules in the readme file.
As we agreed in our today's meeting, we don't have to update the yamls in the offline system for the new JEDI version, because the original yaml files in the offline workflow is working well in the new JEDI version.
I think we should go with number 3 as the default for land DA.
@jiaruidong2017 if you can run JEDI with the version you just compiled on the land directory and the namelist that you generated from the GDASApp, then we can just use that for now. Otherwise, please switch to the same set of commit hashes that GDASApp is using.
I have tested, and it worked with the JEDI version in the land directory and the yaml file generated from GDASApp. Please let me know if you want me to switch to the same set of commit hashes that GDASApp is using.
Yesterday you said that the test case in the offline workflow passes with the new JEDI version, but when I ran it it crashed because my workflow doesn't load the same modules as you used to compile JEDI. I hadn't realised that the modules used in GDASApp are not hosted externally somewhere, which complicates my plan to switch the offline workflow across to using the same modules. I don't have time to go into this this week. If @CoryMartin-NOAA can join our meeting next week, I suggest we just wait until that meeting, and then we can re-think how we're going about merging the land DA code.
@ClaraDraper-NOAA I talked with @barlage this morning. I will plan to attend every other week to your tag ups (whenever possible) so that we can coordinate better.
@ClaraDraper-NOAA I conducted my test runs in the work directory created from the offline land DA workflow using both the new JEDI version and the GDASApp modules. I think one simple way could use the GDASApp modules to replace the modules used by the offline land DA workflow for a test.
Update the JEDI version compiled using the same modules as the GDASApp in the land directory for offline land DA workflow, create readme with instructions for how to compile, and copy across module files.