Skip to content

Sync RDASApp submodule with upstream repositories

Jump to bottom
Samuel Degelia edited this page Nov 7, 2024 · 54 revisions

This document provides guidance of syncing RDASApp submodules under sorc directory with upstream repositories. Team who takes on this task includes: Junjun, Haidao, Hongli, Janet, Donnie, Sam, Guoqing, Shun, Ming.

1. Upstream repositories

Check the CMakeLists.txt of the following bundles for tracing upstream repositories. A list of all upstream repositories can also be found in .gitmodules.

RDASApp upstream repositories:

Note: the repositories in JSCDA-intenal and JCSDA space are synced. We mostly follow repositories in JCSDA space. If certain functions we need only in JSCDA-intenal repositories, we will follow JSCDA-intenal.

Basic JEDI repositories
  1. oops
  2. vader
  3. saber
  4. ioda
  5. ufo
  6. iodaconv
  7. crtm
  8. jedicmake
  9. gsibec
MPAS interface
  1. mpas
  2. mpas-jedi
FV3 interface
  1. fv3-jedi
  2. fv3
  3. femps
  4. fv3-jedi-lm

2. Steps to sync and test the RDASApp submodules

2a. Checkout the RDASApp

git clone --recurse-submodules https://github.com/NOAA-EMC/RDASApp.git

2b. Update submodules from upstream repositories

Instructions for updating individual submodules can be found on the Wiki page: working with RDASApp submodules

The submodules in RDASApp can also be bulk updated with a single command. First, edit .gitmodules and comment out any submodules that you do not want to update (such as the tagged versions of MPAS, gsibec, or CRTM). Then, you can run the following command from the base directory in RDASApp:

cd RDASApp
git submodule update --init --remote

Each subdirectory that is updated should then be committed following the wiki article linked above. Note: if using the git submodule update option, then please do not commit any changes made to .gitmodules.

2c. Build RDASApp

./build.sh

2d. Run ctests on Hera, Jet, Orion

After updating the RDASApp submodules, we should run ctests for the major submodules to ensure that everything works as expected. At the moment, it is sufficient to run ctests for rrfs-test, ufo, mpas-jedi, and fv3-jedi. The ctests are located under the build directory. Before running a ctest, the following two steps should be done,

source ush/load_rdas.sh
export SLURM_ACCOUNT=$account

where $account is your valid slurm resource account (e.g., fv3-cam, da-cpu, wrfruc, rtrr, nrtrr, etc.).

rrfs-test

cd build/rrfs-test
ctest -j8

We should get "100% tests passed, 0 tests failed". If a test fails due to a ReferenceMismatchError, then the test reference data for the ctests might need to be udpated. Please navigate to build/rrfs-test/rundir-${TESTNAME} and locate a file called rrfs-${DYCORE}-${TESTTYPE}.out. You can replace the corresponding .ref file in rrfs-test/testoutput with this file and rerun the ctests. Please commit the new .ref file with your PR.

mpas-jedi

cd build/mpas-jedi
ctest

Note: Be sure to use ctest instead of ctest -jN as the mpas-jedi testing dependencies may not be set up.

The five tests might fail due to the CRTM version:

37 - test_mpasjedi_3denvar_amsua_allsky (Failed)
38 - test_mpasjedi_3denvar_amsua_bc (Failed)
43 - test_mpasjedi_4denvar_VarBC (Failed)
44 - test_mpasjedi_4denvar_VarBC_nonpar (Failed)
54 - test_mpasjedi_lgetkf_height_vloc (Failed)

The following two tests might might also fail due to RDASApp rejecting one more radiosonde wind observation than the clean mpas-bundle.

40 - test_mpasjedi_3dfgat (Failed)
47 - test_mpasjedi_4dfgat (Failed)

fv3-jedi

cd build/fv3-jedi
ctest -j8

The following tests might fail:

70 - fv3jedi_test_tier1_hofx_nomodel_abi_radii (Failed)
88 - fv3jedi_test_tier1_hyb-3dvar (Failed)
91 - fv3jedi_test_tier1_3dvar_lam_cmaq (Failed)
96 - fv3jedi_test_tier1_hyb-fgat_fv3lm (Failed)
98 - fv3jedi_test_tier1_4denvar (Failed)
99 - fv3jedi_test_tier1_4denvar_seq (Failed)
109 - fv3jedi_test_tier1_diffstates_gfs (Failed)
111 - fv3jedi_test_tier1_diffstates_lam_cmaq (Failed)
112 - fv3jedi_test_tier1_addincrement_gfs (Failed)
125 - fv3jedi_test_tier1_eda_3dvar_control_pert (Failed)

ufo

cd build/ufo
ctest

The following tests might fail:

146 - ufo_test_tier1_test_ufo_qc_variableassignment (Failed)
166 - ufo_test_tier1_test_ufo_tropics_qc_filters (Failed)
494 - ufo_test_tier1_test_ufo_variabletransforms_rhumidity (Failed)
497 - ufo_test_tier1_test_ufo_variabletransforms_shumidity (Failed)

All JEDI tests

Note that it is typically not necessary to run all ctests included in RDASApp (there are ~2000 total tests). But if you would like to verify, then you can follow the below steps:

cd build
ctest -j8

2e. Update the staged data for submodules (if necessary)

If you notice many failures of ufo, fv3-jedi, or mpas-jedi ctests, then this might indicate that their respective data directories need to be updated. Please note that these repositories are only accessible under the JCSDA-internal group on GitHub. If you do not have access to these repositories, then please contact another member of the syncing team.

Repository list:

https://github.com/JCSDA-internal/ufo-data
https://github.com/JCSDA-internal/ioda-data
https://github.com/JCSDA-internal/mpas-jedi-data
https://github.com/JCSDA-internal/fv3-jedi-data

These data are currently staged on each of the supported RDASApp machines. If you need to update them, please contact a member of the fix management team to stage the updated directories on $RDAS_DATA. You will also need to update the links to the new data in your PR. These links are contained under fix/jcsda.

2f. Create PR to update submodules

Once the above steps are done, please create a PR documenting the updated hashes for each submodule and the status of the ctests. See examples in #194 or #217.

3. History of sync

Clone this wiki locally