Sync submodules with upstream repositories (Feb. 2026) by SamuelDegelia-NOAA · Pull Request #536 · NOAA-EMC/RDASApp

SamuelDegelia-NOAA · 2026-02-11T21:59:18Z

Overview

This PR updates the RDASApp submodules to align with the latest changes in their respective upstream repositories. Each submodule has been synchronized to the head of their develop branches.

As part of this PR, a few of the gsibec workaround codes can now be removed since their upstream PR was merged. Other workaround files have been synced with changes from the upstream repository. @Masanori-NOAA and @TingLei-NOAA would you please review the changes to your respective workarounds from this PR? Let me know if you have any specific questions.

One change needed with this sync is that a recent update to JCB (NOAA-EMC/jcb#32) modified how the EnKF localization and distribution info are passed into the observation-space yamls. Those variables are now defined in the main JCB config file which allows us to remove these sections from the obs space yamls. This also means that #535 is no longer needed.

Note that after adding our parallel I/O codes, 83 of the fv3-jedi ctests are now failing. Most failures show error messages related to not enough ranks being available for the I/O. This is good information to have and suggests that our new parallel I/O code could either be enhanced or added as an toggleable option when opening the eventual PR to fv3-jedi. Because of the large number of failures, I will not include the fv3-jedi ctest results as a comment to this PR (mpas-jedi and UFO will still be posted).

Summary of Changes

1. Submodule Updates (required)

sorc/fv3-jedi:         689dbd8 -> fc4f48c
sorc/gsibec:           c70049c -> a754e95
sorc/ioda:             df1e3c9 -> fead60c
sorc/iodaconv:         e220318 -> 84c73b0
sorc/oops:             711f5c8 -> 4cb58e1
sorc/saber:            db5d624 -> 3fee34d
sorc/ufo:              612a1ec -> 6379f4e
sorc/vader:            5c5970d -> b6dab37
sorc/mpas-jedi:        b278424 -> 5d6d005
sorc/bufr-query:       6935d70 -> f850b03
sorc/wxflow:           afbbf2d -> e952a8a
parm/jcb-algorithms:   b01c18d -> 7d51ab6
sorc/jcb:              ebd10ea -> 72ccf27

2. Staged `ctest-data` Updates

The staged ctest data were updated for ioda-data and ufo-data.

3. Test Reference Updates

All ctests pass after the submodule update so the test references do not need to be updated.

4. Ctest Results

100% tests passed, 0 tests failed out of 18

Label Time Summary:
mpi            = 5613.44 sec*proc (18 tests)
rdas-bundle    = 5613.44 sec*proc (18 tests)
script         = 5613.44 sec*proc (18 tests)

Total Test time (real) = 858.78 sec
+ exit 0

5. Notable Exclusions

CRTM and MPAS are excluded from this update.

6. Checklist

Submodules updated to latest develop branches.
Staged ctest-data synchronized to all machines (if needed).
Test references (rrfs-test) updated (if needed).
Verified no unintended updates to locked submodules (e.g., CRTM, MPAS, gsibec).
Validation and testing completed on all machines.

SamuelDegelia-NOAA · 2026-02-11T22:00:20Z

MPAS-JEDI ctest results:

87% tests passed, 8 tests failed out of 61

Label Time Summary:
executable    =  76.78 sec*proc (12 tests)
mpasjedi      = 1145.01 sec*proc (61 tests)
mpi           = 1143.60 sec*proc (60 tests)
script        = 1068.23 sec*proc (49 tests)

Total Test time (real) = 1145.15 sec

The following tests FAILED:
         15 - test_mpasjedi_hofx3d (Failed)
         33 - test_mpasjedi_3dvar (Failed)
         36 - test_mpasjedi_3dfgat_cda (Failed)
         40 - test_mpasjedi_3denvar_amsua_allsky (Failed)
         43 - test_mpasjedi_3dfgat (Failed)
         50 - test_mpasjedi_4dfgat (Failed)
         56 - test_mpasjedi_lgetkf_4pe (Failed)
         60 - test_mpasjedi_3dvar_2pe (Failed)

These are the same failures reported in our last update in #500.

SamuelDegelia-NOAA · 2026-02-11T22:00:40Z

UFO ctest results:

98% tests passed, 18 tests failed out of 946

Label Time Summary:
CI_exclude_hang_gnssro_ukmo_intel_O1    = 3529.63 sec*proc (11 tests)
GEOS                                    =  11.39 sec*proc (3 tests)
HofX                                    =  24.28 sec*proc (7 tests)
QC                                      =  49.62 sec*proc (13 tests)
UV                                      =   8.77 sec*proc (2 tests)
actions                                 =  11.89 sec*proc (4 tests)
aircraft                                =  16.09 sec*proc (3 tests)
compo                                   =   8.70 sec*proc (2 tests)
crtm                                    = 326.99 sec*proc (59 tests)
errors                                  =  42.25 sec*proc (8 tests)
executable                              = 145.43 sec*proc (49 tests)
filters                                 = 1755.15 sec*proc (212 tests)
fov                                     =  11.96 sec*proc (3 tests)
gnssro                                  =   3.48 sec*proc (1 test)
instrument                              =  82.60 sec*proc (22 tests)
metoffice                               =  12.83 sec*proc (2 tests)
mpi                                     = 5545.69 sec*proc (509 tests)
obsfunctions                            = 311.82 sec*proc (95 tests)
operators                               = 3221.27 sec*proc (163 tests)
ozone                                   =   0.41 sec*proc (2 tests)
pibal                                   =   5.26 sec*proc (1 test)
predictors                              = 130.15 sec*proc (30 tests)
profile                                 = 160.28 sec*proc (43 tests)
radarVAD                                =   8.40 sec*proc (2 tests)
rass                                    =   7.94 sec*proc (2 tests)
rttov                                   =   2.02 sec*proc (1 test)
satwinds                                =  11.17 sec*proc (3 tests)
scatwinds                               =   3.32 sec*proc (1 test)
script                                  = 5519.50 sec*proc (897 tests)
sfcLand                                 =   3.67 sec*proc (1 test)
sfcMarine                               =   2.62 sec*proc (1 test)
sonde                                   =  11.55 sec*proc (3 tests)
ufo                                     = 5664.93 sec*proc (946 tests)
ufo_data_validate                       =  73.27 sec*proc (401 tests)
unit_tests                              = 430.32 sec*proc (103 tests)
utils                                   =   5.24 sec*proc (2 tests)
variablenamemap                         =   2.04 sec*proc (1 test)
variabletransforms                      = 127.93 sec*proc (27 tests)

Total Test time (real) = 5669.24 sec

The following tests FAILED:
        474 - ufo_test_tier1_test_ufo_gnssrobendmetoffice_qc (Failed)
        476 - ufo_test_tier1_test_ufo_gnssrobendmetoffice_obserror (Failed)
        482 - ufo_test_tier1_test_ufo_gnssro_super_refraction_check (Failed)
        510 - ufo_test_tier1_test_ufo_qc_gauss_thinning_mean_error (Failed)
        562 - ufo_test_tier1_test_ufo_amsua_allsky_gfs_gsi_qc (Failed)
        566 - ufo_test_tier1_test_ufo_amsua_qc_filters_geos (Failed)
        569 - ufo_test_tier1_test_ufo_atms_n20_qc_filters_geos (Failed)
        573 - ufo_test_tier1_test_ufo_tropics_qc_filters (Failed)
        708 - ufo_test_tier1_test_ufo_opr_gnssrobendmetoffice (Failed)
        709 - ufo_test_tier1_test_ufo_linopr_gnssrobendmetoffice (Failed)
        710 - ufo_test_tier1_test_ufo_opr_gnssrobendmetoffice_nopseudo (Failed)
        713 - ufo_test_tier1_test_ufo_opr_gnssrobendmetoffice_nosupercheck (Failed)
        714 - ufo_test_tier1_test_ufo_linopr_gnssrobendmetoffice_nosupercheck (Failed)
        715 - ufo_test_tier1_test_ufo_opr_gnssrobendmetoffice_refractivity_changes (Failed)
        716 - ufo_test_tier1_test_ufo_linopr_gnssrobendmetoffice_refractivity_changes (Failed)
        845 - ufo_test_tier1_test_ufo_amsua_crtm_bc_channelnobc_geos (Failed)
        846 - ufo_test_tier1_test_ufo_amsua_crtm_bc_geos (Failed)
        922 - ufo_test_tier1_test_ufo_variabletransforms_icefreeboardtothickness (Failed)

These are the same failures reported in our last update in #500.

rrfsbot · 2026-02-11T22:34:16Z

PASSED on hera

started build_and_test on hera at UTC time: Wed Feb 11 22:04:57 UTC 2026
finished at UTC time: Wed Feb 11 22:34:15 UTC 2026

Test project /scratch3/NCEPDEV/fv3-cam/rrfsbot/PRs_RDASApp/536/build/rrfs-test
      Start  6: rrfs_fv3jedi_2024052700_getkf_observer
      Start 15: rrfs_mpasjedi_2024052700_getkf_observer
      Start  1: rrfs_fv3jedi_2024052700_3dvar
      Start  2: rrfs_fv3jedi_2024052700_3denvar
      Start  3: rrfs_fv3jedi_2024052700_3denvar_mgbf
      Start  4: rrfs_fv3jedi_2024052700_hybrid3denvar
      Start  5: rrfs_fv3jedi_2024052700_hybrid3denvar_mgbf
      Start  8: rrfs_fv3jedi_2024052700_3dvar_conv_surface
 1/18 Test  #1: rrfs_fv3jedi_2024052700_3dvar .................   Passed   29.01 sec
      Start  9: rrfs_fv3jedi_2024052700_3dvar_conv_upperair
 2/18 Test  #6: rrfs_fv3jedi_2024052700_getkf_observer ........   Passed   70.97 sec
      Start  7: rrfs_fv3jedi_2024052700_getkf_solver
 3/18 Test  #8: rrfs_fv3jedi_2024052700_3dvar_conv_surface ....   Passed  118.49 sec
      Start 10: rrfs_fv3jedi_2024052700_3dvar_remote
 4/18 Test  #9: rrfs_fv3jedi_2024052700_3dvar_conv_upperair ...   Passed   89.62 sec
      Start 11: rrfs_fv3jedi_2024052700_3dvar_satrad
 5/18 Test  #7: rrfs_fv3jedi_2024052700_getkf_solver ..........   Passed   62.22 sec
      Start 12: rrfs_fv3jedi_2024052700_3denvar_refl
 6/18 Test #10: rrfs_fv3jedi_2024052700_3dvar_remote ..........   Passed   33.71 sec
      Start 13: rrfs_mpasjedi_2024052700_bumploc
 7/18 Test  #5: rrfs_fv3jedi_2024052700_hybrid3denvar_mgbf ....   Passed  171.78 sec
      Start 14: rrfs_mpasjedi_2024052700_3denvar
 8/18 Test #11: rrfs_fv3jedi_2024052700_3dvar_satrad ..........   Passed   61.30 sec
      Start 17: rrfs_mpasjedi_2024052700_3dvar
 9/18 Test  #2: rrfs_fv3jedi_2024052700_3denvar ...............   Passed  196.27 sec
      Start 18: rrfs_bufr2ioda_msonet
10/18 Test  #4: rrfs_fv3jedi_2024052700_hybrid3denvar .........   Passed  213.00 sec
11/18 Test #18: rrfs_bufr2ioda_msonet .........................   Passed   25.50 sec
12/18 Test #17: rrfs_mpasjedi_2024052700_3dvar ................   Passed   48.69 sec
13/18 Test #15: rrfs_mpasjedi_2024052700_getkf_observer .......   Passed  232.63 sec
      Start 16: rrfs_mpasjedi_2024052700_getkf_solver
14/18 Test  #3: rrfs_fv3jedi_2024052700_3denvar_mgbf ..........   Passed  240.57 sec
15/18 Test #16: rrfs_mpasjedi_2024052700_getkf_solver .........   Passed  179.39 sec
16/18 Test #14: rrfs_mpasjedi_2024052700_3denvar ..............   Passed  285.29 sec
17/18 Test #12: rrfs_fv3jedi_2024052700_3denvar_refl ..........   Passed  365.28 sec
18/18 Test #13: rrfs_mpasjedi_2024052700_bumploc ..............   Passed  346.94 sec

100% tests passed, 0 tests failed out of 18

Label Time Summary:
mpi            = 2770.67 sec*proc (18 tests)
rdas-bundle    = 2770.67 sec*proc (18 tests)
script         = 2770.67 sec*proc (18 tests)

Total Test time (real) = 499.18 sec

workdir: /scratch3/NCEPDEV/fv3-cam/rrfsbot/PRs_RDASApp/536

SamuelDegelia-NOAA · 2026-02-11T23:01:30Z

PASSED on wcoss2

started build_and_test on wcoss2 at UTC time: Wed Feb 11 22:02:49 UTC 2026
finished at UTC time: Wed Feb 11 23:01:29 UTC 2026

Test project /lfs/h2/emc/da/noscrub/samuel.degelia/rrfsbot/PRs_RDASApp/536/build/rrfs-test
      Start  6: rrfs_fv3jedi_2024052700_getkf_observer
      Start 15: rrfs_mpasjedi_2024052700_getkf_observer
      Start  1: rrfs_fv3jedi_2024052700_3dvar
      Start  2: rrfs_fv3jedi_2024052700_3denvar
      Start  3: rrfs_fv3jedi_2024052700_3denvar_mgbf
      Start  4: rrfs_fv3jedi_2024052700_hybrid3denvar
      Start  5: rrfs_fv3jedi_2024052700_hybrid3denvar_mgbf
      Start  8: rrfs_fv3jedi_2024052700_3dvar_conv_surface
      Start  9: rrfs_fv3jedi_2024052700_3dvar_conv_upperair
      Start 10: rrfs_fv3jedi_2024052700_3dvar_remote
 1/18 Test #10: rrfs_fv3jedi_2024052700_3dvar_remote ..........   Passed  115.64 sec
      Start 11: rrfs_fv3jedi_2024052700_3dvar_satrad
 2/18 Test  #9: rrfs_fv3jedi_2024052700_3dvar_conv_upperair ...   Passed  140.63 sec
      Start 12: rrfs_fv3jedi_2024052700_3denvar_refl
 3/18 Test  #8: rrfs_fv3jedi_2024052700_3dvar_conv_surface ....   Passed  145.63 sec
      Start 13: rrfs_mpasjedi_2024052700_bumploc
 4/18 Test  #1: rrfs_fv3jedi_2024052700_3dvar .................   Passed  158.75 sec
      Start 14: rrfs_mpasjedi_2024052700_3denvar
 5/18 Test  #6: rrfs_fv3jedi_2024052700_getkf_observer ........   Passed  169.70 sec
      Start  7: rrfs_fv3jedi_2024052700_getkf_solver
 6/18 Test #11: rrfs_fv3jedi_2024052700_3dvar_satrad ..........   Passed  133.93 sec
      Start 17: rrfs_mpasjedi_2024052700_3dvar
 7/18 Test  #2: rrfs_fv3jedi_2024052700_3denvar ...............   Passed  275.64 sec
      Start 18: rrfs_bufr2ioda_msonet
 8/18 Test  #4: rrfs_fv3jedi_2024052700_hybrid3denvar .........   Passed  294.63 sec
 9/18 Test #18: rrfs_bufr2ioda_msonet .........................   Passed   34.59 sec
10/18 Test  #7: rrfs_fv3jedi_2024052700_getkf_solver ..........   Passed  161.09 sec
11/18 Test  #3: rrfs_fv3jedi_2024052700_3denvar_mgbf ..........   Passed  359.65 sec
12/18 Test #17: rrfs_mpasjedi_2024052700_3dvar ................   Passed  116.98 sec
13/18 Test  #5: rrfs_fv3jedi_2024052700_hybrid3denvar_mgbf ....   Passed  372.65 sec
14/18 Test #13: rrfs_mpasjedi_2024052700_bumploc ..............   Passed  350.01 sec
15/18 Test #15: rrfs_mpasjedi_2024052700_getkf_observer .......   Passed  506.72 sec
      Start 16: rrfs_mpasjedi_2024052700_getkf_solver
16/18 Test #14: rrfs_mpasjedi_2024052700_3denvar ..............   Passed  485.89 sec
17/18 Test #12: rrfs_fv3jedi_2024052700_3denvar_refl ..........   Passed  668.02 sec
18/18 Test #16: rrfs_mpasjedi_2024052700_getkf_solver .........   Passed  328.90 sec

100% tests passed, 0 tests failed out of 18

Label Time Summary:
rdas-bundle    = 4819.04 sec*proc (18 tests)
script         = 4819.04 sec*proc (18 tests)

Total Test time (real) = 835.70 sec

workdir: /lfs/h2/emc/da/noscrub/samuel.degelia/rrfsbot/PRs_RDASApp/536

guoqing-noaa · 2026-02-12T03:33:34Z

@SamuelDegelia-NOAA Sorry I did not follow on this. Could you help me understand how obs space.distribution and obs localizations are defined now? JCB will write out them directly? Or JEDI has changes so that we don't need them in YAML files? Thanks!

guoqing-noaa · 2026-02-12T03:36:50Z

@SamuelDegelia-NOAA Currently, sorc/ufo: 612a1ec -> 6379f4e

Could you update ufo further to the hash 6b5e3e4 (which was merged 1 hr ago)? Thanks!

guoqing-noaa · 2026-02-12T05:08:28Z

@delippi Good point! Thanks for reminding us of this. [0,360] will be preferred.

I think @HuiLiu-NOAA previously dealt with the [-180, 180] vs [0,360] issue when working on ZTD. The PR is #352. I think we also had more discussions on it. @HuiLiu-NOAA Have you created an issue for this?

With that said, I will check with Sam T. to see whether he can make the polygon filter more robust to handle both situations.

HuiLiu-NOAA · 2026-02-12T05:20:19Z

@delippi Good point! Thanks for reminding us of this. [0,360] will be preferred.

I think @HuiLiu-NOAA previously dealt with the [-180, 180] vs [0,360] issue when working on ZTD. The PR is #352. I think we also had more discussions on it. @HuiLiu-NOAA Have you created an issue for this?

With that said, I will check with Sam T. to see whether he can make the polygon filter more robust to handle both situations.

I think it would be more generic if the bufr2ioda codes in RDASApp can handle both [0, 360] and [-180, 180] format since the two are still being used in some observation types. Just need to add one more line for this purpose, I think.

SamuelDegelia-NOAA · 2026-02-12T14:51:30Z

Converting to draft to update UFO to its latest commit.

SamuelDegelia-NOAA · 2026-02-12T14:55:41Z

@SamuelDegelia-NOAA Sorry I did not follow on this. Could you help me understand how obs space.distribution and obs localizations are defined now? JCB will write out them directly? Or JEDI has changes so that we don't need them in YAML files? Thanks!

Yes, JCB will now write those sections directly into the individual obs spaces using the obs_distribution_localization settings defined in the high-level config file. So we no longer need those sections and variables in the individual obs space j2 templates. But this is only related to JCB. Those sections are still needed in the yamls, its just that now JCB can write them out now. If not using JCB, we still need to include them.

guoqing-noaa · 2026-02-12T15:46:50Z

@SamuelDegelia-NOAA Thanks for the information and updating UFO further!

guoqing-noaa · 2026-02-12T15:55:23Z

@delippi Good point! Thanks for reminding us of this. [0,360] will be preferred.
I think @HuiLiu-NOAA previously dealt with the [-180, 180] vs [0,360] issue when working on ZTD. The PR is #352. I think we also had more discussions on it. @HuiLiu-NOAA Have you created an issue for this?
With that said, I will check with Sam T. to see whether he can make the polygon filter more robust to handle both situations.

I think it would be more generic if the bufr2ioda codes in RDASApp can handle both [0, 360] and [-180, 180] format since the two are still being used in some observation types. Just need to add one more line for this purpose, I think.

@HuiLiu-NOAA I agree.
So we would like to add one line after

RDASApp/rrfs-test/IODA/python/bufr2ioda_satwnd_amv_goes.py

Lines 187 to 188 in c362127

    
           lat = r.get('latitude') 
        
           lon = r.get('longitude')

similar to what we did in

RDASApp/rrfs-test/IODA/python/bufr2ioda_ztd.py

Lines 118 to 120 in c362127

    
           lat = r.get('latitude') 
        
           lon = r.get('longitude') 
        
           lon[lon < 0] += 360  # Convert to [0, 360]

delippi

Looks good to me. Thank you for your efforts on keeping all the submodules up to date.

SamuelDegelia-NOAA · 2026-02-12T16:06:06Z

UFO has been updated to the latest commit and the ctests are still passing.

HuiLiu-NOAA · 2026-02-12T16:11:00Z

@delippi Good point! Thanks for reminding us of this. [0,360] will be preferred.
I think @HuiLiu-NOAA previously dealt with the [-180, 180] vs [0,360] issue when working on ZTD. The PR is #352. I think we also had more discussions on it. @HuiLiu-NOAA Have you created an issue for this?
With that said, I will check with Sam T. to see whether he can make the polygon filter more robust to handle both situations.

I think it would be more generic if the bufr2ioda codes in RDASApp can handle both [0, 360] and [-180, 180] format since the two are still being used in some observation types. Just need to add one more line for this purpose, I think.

@HuiLiu-NOAA I agree. So we would like to add one line after

RDASApp/rrfs-test/IODA/python/bufr2ioda_satwnd_amv_goes.py

Lines 187 to 188 in c362127

lat = r.get('latitude')

lon = r.get('longitude')

similar to what we did in

RDASApp/rrfs-test/IODA/python/bufr2ioda_ztd.py

Lines 118 to 120 in c362127

lat = r.get('latitude')

lon = r.get('longitude')

lon[lon < 0] += 360 # Convert to [0, 360]

I thought Sam already made such change sometime before??

delippi · 2026-02-12T16:11:10Z

@guoqing-noaa I think that one-liner change seems correct to me.

I assume you're already on it, but just in case, I wanted to make sure that we apply this change for each ob type and make sure everything is consistent. I think the obs that use the "incorrect" format [-180, 180] are the obs using the python based converters. I haven't found any incorrect format from the yaml based converters.

SamuelDegelia-NOAA · 2026-02-12T16:14:21Z

I thought Sam already made such change sometime before??

I made a change to do this in the offline domain checks in #222. But we need to do it at the bufr2ioda level if we want them to work with the new online domain check in UFO.

HuiLiu-NOAA · 2026-02-12T16:16:50Z

I thought Sam already made such change sometime before??

I made a change to do this in the offline domain checks in #222. But we need to do it at the bufr2ioda level if we want them to work with the new online domain check in UFO.

That seems a good reason for this to go.

guoqing-noaa · 2026-02-12T17:16:16Z

Good news! Sam T. confirmed that Boost can handle [0, 360] or [-180, 180] automatically. So the polygon prefilter works no matter what longitude values are used in the ioda files.
Sam just updated the documentation to make this explicit:
https://github.com/JCSDA-internal/jedi-docs/pull/974/changes

guoqing-noaa

LGTM. Thanks a lot for updating RDASApp to the latest JEDI.

delippi · 2026-02-12T19:38:15Z

Good news! Sam T. confirmed that Boost can handle [0, 360] or [-180, 180] automatically. So the polygon prefilter works no matter what longitude values are used in the ioda files. Sam just updated the documentation to make this explicit: https://github.com/JCSDA-internal/jedi-docs/pull/974/changes

@guoqing-noaa based on what I'm reading, you would need to know what the format is per obs type and then use the corresponding longitude format to define the verticies of the polygon. So based on my understanding you can't apply the same set of verticies as below for obs that use [0, 360] format and vice versa.

      vertex longitudes: [ -110, -100, -80, -90, -95, -110 ]
      vertex latitudes: [ 30, 45, 40, 25, 35, 30 ]

I think the best thing to do is make sure all the ioda values use the same longitude format [0, 360] seems to be the current choice. This is just good hygiene. Next, is add a similar line like below to the polygon tool.

lon[lon < 0] += 360  # Convert to [0, 360]

Technically if we have good longitude hygiene we wouldn't need to do this but it would make the tool more robust. This way we can define the polygon vertices exactly the same across all obs spaces.

TingLei-NOAA · 2026-02-12T20:42:25Z

@SamuelDegelia-NOAA , For the treatment of missing values in the background fields in gsibec and for the missing atlas halo points, a clean draft PR to show the changes is https://github.com/JCSDA-internal/saber/pull/1189.
With those changes, some monitoring of the background values in gsibec are not needed.

guoqing-noaa · 2026-02-12T20:53:44Z

Good news! Sam T. confirmed that Boost can handle [0, 360] or [-180, 180] automatically. So the polygon prefilter works no matter what longitude values are used in the ioda files. Sam just updated the documentation to make this explicit: https://github.com/JCSDA-internal/jedi-docs/pull/974/changes

@guoqing-noaa based on what I'm reading, you would need to know what the format is per obs type and then use the corresponding longitude format to define the verticies of the polygon. So based on my understanding you can't apply the same set of verticies as below for obs that use [0, 360] format and vice versa.
      vertex longitudes: [ -110, -100, -80, -90, -95, -110 ]
      vertex latitudes: [ 30, 45, 40, 25, 35, 30 ]
I think the best thing to do is make sure all the ioda values use the same longitude format [0, 360] seems to be the current choice. This is just good hygiene. Next, is add a similar line like below to the polygon tool.
lon[lon < 0] += 360  # Convert to [0, 360]
Technically if we have good longitude hygiene we wouldn't need to do this but it would make the tool more robust. This way we can define the polygon vertices exactly the same across all obs spaces.

I agree to use [0, 360] in all ioda files to be consistent.

Per Sam T., for the polygon filter itself, it can handle the mixed use of [-180,180] and [0,360] correctly.
For example, both of the following lines work:

      vertex longitudes: [ -110, -100, -80, -90, -95, -110 ]
      vertex longitudes: [ 250, 260, 280, 270, 265, 250 ]

Thanks!

delippi · 2026-02-12T21:11:26Z

Good news! Sam T. confirmed that Boost can handle [0, 360] or [-180, 180] automatically. So the polygon prefilter works no matter what longitude values are used in the ioda files. Sam just updated the documentation to make this explicit: https://github.com/JCSDA-internal/jedi-docs/pull/974/changes

@guoqing-noaa based on what I'm reading, you would need to know what the format is per obs type and then use the corresponding longitude format to define the verticies of the polygon. So based on my understanding you can't apply the same set of verticies as below for obs that use [0, 360] format and vice versa.
      vertex longitudes: [ -110, -100, -80, -90, -95, -110 ]
      vertex latitudes: [ 30, 45, 40, 25, 35, 30 ]
I think the best thing to do is make sure all the ioda values use the same longitude format [0, 360] seems to be the current choice. This is just good hygiene. Next, is add a similar line like below to the polygon tool.
lon[lon < 0] += 360  # Convert to [0, 360]
Technically if we have good longitude hygiene we wouldn't need to do this but it would make the tool more robust. This way we can define the polygon vertices exactly the same across all obs spaces.
I agree to use [0, 360] in all ioda files to be consistent.

Per Sam T., for the polygon filter itself, it can handle the mixed use of [-180,180] and [0,360] correctly. For example, both of the following lines work:
      vertex longitudes: [ -110, -100, -80, -90, -95, -110 ]
      vertex longitudes: [ 250, 260, 280, 270, 265, 250 ]
Thanks!

Are you saying for data of format [-180, 180], for example, you can use either to achieve the same result?

vertex longitudes: [ -110, -100, -80, -90, -95, -110 ]
vertex longitudes: [ 250, 260, 280, 270, 265, 250 ]

We might be talking past each other. I think I just need to test it myself to test my concerns.

SamuelDegelia-NOAA · 2026-02-12T21:20:41Z

@SamuelDegelia-NOAA , For the treatment of missing values in the background fields in gsibec and for the missing atlas halo points, a clean draft PR to show the changes is JCSDA-internal/saber#1189. With those changes, some monitoring of the background values in gsibec are not needed.

That is great @TingLei-NOAA, thank you for sharing. Should we get these changes into RDASApp now or are we okay with waiting until the next submodule update?

guoqing-noaa · 2026-02-12T21:47:36Z

Are you saying for data of format [-180, 180], for example, you can use either to achieve the same result?
vertex longitudes: [ -110, -100, -80, -90, -95, -110 ]
vertex longitudes: [ 250, 260, 280, 270, 265, 250 ]
We might be talking past each other. I think I just need to test it myself to test my concerns.

@delippi I assume so but I did not test it by myself. It is great if you can test to confirm whether it is the case. Thanks!

TingLei-NOAA · 2026-02-12T22:27:38Z

@SamuelDegelia-NOAA The interpolation.cc in my draft PR should be ok to be used in the work-around directory. but the gsi_covariance_mod.f90 could have differences from its current version in the work-around directory. If you already had @Masanori-NOAA 's changes to make NaN values disappear, we can wait to see how to proceed.

Samuel Degelia and others added 8 commits February 10, 2026 16:13

update all submodules except for mpas and crtm

79dbe8c

cleanup jcb section of build script

41a4cf7

sync workaround codes

ff437ad

restructure how getkf localization is handled in jcb

3fcc909

missed removing a few localization settings

a0feb4c

add override localization for dbz example

68e906e

update jcsda test data

8ca9eaa

remove some workarounds that have been merged

21b57e0

SamuelDegelia-NOAA requested review from Masanori-NOAA, ShunLiu-NOAA, TingLei-NOAA and delippi February 11, 2026 21:59

SamuelDegelia-NOAA added test_hera test_wcoss2 labels Feb 11, 2026

SamuelDegelia-NOAA requested a review from guoqing-noaa February 11, 2026 21:59

rrfsbot added running_hera and removed test_hera labels Feb 11, 2026

SamuelDegelia-NOAA added running_wcoss2 and removed test_wcoss2 labels Feb 11, 2026

rrfsbot added Passed_hera and removed running_hera labels Feb 11, 2026

SamuelDegelia-NOAA added Passed_wcoss2 and removed running_wcoss2 labels Feb 11, 2026

SamuelDegelia-NOAA marked this pull request as ready for review February 11, 2026 23:08

SamuelDegelia-NOAA marked this pull request as draft February 12, 2026 14:51

delippi previously approved these changes Feb 12, 2026

View reviewed changes

update ufo

159fc6e

SamuelDegelia-NOAA dismissed delippi’s stale review via 159fc6e February 12, 2026 16:05

SamuelDegelia-NOAA marked this pull request as ready for review February 12, 2026 16:06

guoqing-noaa approved these changes Feb 12, 2026

View reviewed changes

delippi approved these changes Feb 12, 2026

View reviewed changes

ShunLiu-NOAA approved these changes Feb 12, 2026

View reviewed changes

ShunLiu-NOAA merged commit 280fd84 into NOAA-EMC:develop Feb 12, 2026
1 check passed

SamuelDegelia-NOAA deleted the feature/submodule_update_feb2026 branch February 12, 2026 19:49

Junjun-NOAA mentioned this pull request Feb 17, 2026

update RDASApp and UPP to the latest version NOAA-EMC/rrfs-workflow#1326

Merged

Conversation

SamuelDegelia-NOAA commented Feb 11, 2026

Overview

Summary of Changes

1. Submodule Updates (required)

2. Staged ctest-data Updates

3. Test Reference Updates

4. Ctest Results

5. Notable Exclusions

6. Checklist

Uh oh!

SamuelDegelia-NOAA commented Feb 11, 2026

Uh oh!

SamuelDegelia-NOAA commented Feb 11, 2026

Uh oh!

rrfsbot commented Feb 11, 2026

Uh oh!

SamuelDegelia-NOAA commented Feb 11, 2026

Uh oh!

guoqing-noaa commented Feb 12, 2026

Uh oh!

guoqing-noaa commented Feb 12, 2026

Uh oh!

guoqing-noaa commented Feb 12, 2026

Uh oh!

HuiLiu-NOAA commented Feb 12, 2026

Uh oh!

SamuelDegelia-NOAA commented Feb 12, 2026

Uh oh!

SamuelDegelia-NOAA commented Feb 12, 2026

Uh oh!

guoqing-noaa commented Feb 12, 2026

Uh oh!

guoqing-noaa commented Feb 12, 2026

Uh oh!

delippi left a comment

Choose a reason for hiding this comment

Uh oh!

SamuelDegelia-NOAA commented Feb 12, 2026

Uh oh!

HuiLiu-NOAA commented Feb 12, 2026

Uh oh!

delippi commented Feb 12, 2026

Uh oh!

SamuelDegelia-NOAA commented Feb 12, 2026

Uh oh!

HuiLiu-NOAA commented Feb 12, 2026

Uh oh!

guoqing-noaa commented Feb 12, 2026

Uh oh!

guoqing-noaa left a comment

Choose a reason for hiding this comment

Uh oh!

delippi commented Feb 12, 2026

Uh oh!

Uh oh!

TingLei-NOAA commented Feb 12, 2026

Uh oh!

guoqing-noaa commented Feb 12, 2026

Uh oh!

delippi commented Feb 12, 2026

Uh oh!

SamuelDegelia-NOAA commented Feb 12, 2026

Uh oh!

guoqing-noaa commented Feb 12, 2026

Uh oh!

TingLei-NOAA commented Feb 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

2. Staged `ctest-data` Updates