Recover the capability of handling model fields from operation gfs.v16.3

[emilyhcliu]

Description
Make sure GSI can read the background fields from the operational gfs.v16.3
Please see details in issue #782
Resolves #782

I fixed the indentations. GitHub messes up (confuses) the code indentation change.
So, to clarify, my code changes are:

• fix indentation (no code change, just space change)
• add a if...end condition to an existing code block

So, the real code change is just two lines (see the following link). The rest of the changes are related to indentation fixes.
3404ddf?diff=split&w=1

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

The branch was tested on ORION using two sets of ICs on 2024021900:

• background fields from v17 (/work2/noaa/da/eliu/ICs/UFO_eval/data/para/output_ufo_eval_feb2024/)
• background fields from operational gfs.v16.3 (/work2/noaa/da/eliu/ICs/GDAS_ops/)

The updated code can handle background fields from both gfs.v16.3 and v17.
The updated code does not change the results of regression tests.

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• New and existing tests pass with my changes
• Any dependent changes have been merged and published

[emilyhcliu]

Working on regression tests. Will post results here soon.

[emilyhcliu]

Results of Regression Test on WCOSS-2:

    Start 1: global_4denvar

1/6 Test #1: global_4denvar ...................   Passed  1685.96 sec
    Start 2: rtma
2/6 Test #2: rtma .............................   Passed  970.86 sec
    Start 3: rrfs_3denvar_rdasens
3/6 Test #3: rrfs_3denvar_rdasens .............   Passed  729.70 sec
    Start 4: hafs_4denvar_glbens
4/6 Test #4: hafs_4denvar_glbens ..............   Passed  1334.85 sec
    Start 5: hafs_3denvar_hybens
5/6 Test #5: hafs_3denvar_hybens ..............   Passed  1335.36 sec
    Start 6: global_enkf
6/6 Test #6: global_enkf ......................   Passed  853.77 sec

[emilyhcliu]

@RussTreadon-NOAA Please add @ADCollard and @xincjin-NOAA to review this PR. Thank you.

[emilyhcliu]

@RussTreadon-NOAA Please add @ADCollard and @xincjin-NOAA to review this PR. Thank you.

@RussTreadon-NOAA Never mind. I just found out that I can assign reviewers myself. I will do that.

[XuanliLi-NOAA]

Changes look good to me.
BTW, imp_physics=8 is for Thompson scheme, what value is it for the current GFDL microphysics?

[emilyhcliu]

Changes look good to me. BTW, imp_physics=8 is for Thompson scheme, what value is it for the current GFDL microphysics?

The current imp_physics is 11 for GFDL
Thanks for reviewing this PR.

[xincjin-NOAA]

looks good to me.

[RussTreadon-NOAA]

Looks good. Confirm ctest results on Cactus. Also run stand-alone GSI script using operational backgrounds and imp_physics=11. gsi.x ran to completion. Repeat test with imp_physics=8. gsi.x hangs with

rank of data array != variable ndims (or ndims-1)

Something to consider: It is preferable for gsi.x to

• print an informative error message explaining why the code is hung (e.g., background inconsistent with imp_physics)
• abort execution

instead of hanging when imp_physics does not match what is in the background atmfXXX.nc file.

As things currently stand, it is not clear from the printout

nid001009.cactus.wcoss2.ncep.noaa.gov 14:  rank of data array != variable ndims (or ndims-1)
nid001009.cactus.wcoss2.ncep.noaa.gov 14: 99
nid001098.cactus.wcoss2.ncep.noaa.gov 44:  rank of data array != variable ndims (or ndims-1)
nid001109.cactus.wcoss2.ncep.noaa.gov 74:  rank of data array != variable ndims (or ndims-1)

why the code is hung.

Not sure if NCO's IT testing will catch this or not.

[emilyhcliu]

Looks good. Confirm ctest results on Cactus. Also run stand-alone GSI script using operational backgrounds and imp_physics=11. gsi.x ran to completion. Repeat test with imp_physics=8. gsi.x hangs with

rank of data array != variable ndims (or ndims-1)

Something to consider: It is preferable for gsi.x to

• print an informative error message explaining why the code is hung (e.g., background inconsistent with imp_physics)
• abort execution

instead of hanging when imp_physics does not match what is in the background atmfXXX.nc file.

As things currently stand, it is not clear from the printout

nid001009.cactus.wcoss2.ncep.noaa.gov 14:  rank of data array != variable ndims (or ndims-1)
nid001009.cactus.wcoss2.ncep.noaa.gov 14: 99
nid001098.cactus.wcoss2.ncep.noaa.gov 44:  rank of data array != variable ndims (or ndims-1)
nid001109.cactus.wcoss2.ncep.noaa.gov 74:  rank of data array != variable ndims (or ndims-1)

why the code is hung.

Not sure if NCO's IT testing will catch this or not.

This is a good suggestion. I will improve the error handling. Thanks for looking into this.

[RussTreadon-NOAA]

@emilyhcliu , it may be easier said than done when it comes to adding code to cleanly abort when imp_physics does not align with the background atmfXXX.nc files. The rank of data array != variable ndims (or ndims-1) error message comes from ncio. The read_vardata calls for nccice and nconrd occur inside subcommunicator blocks. Not all tasks will see the error message. Thus, mpi_abort for mpi_comm_world will hang.

If you see an easy way to obtain the desire behavior, fine ... add it. If not, let's move on.

[emilyhcliu]

@emilyhcliu , it may be easier said than done when it comes to adding code to cleanly abort when imp_physics does not align with the background atmfXXX.nc files. The rank of data array != variable ndims (or ndims-1) error message comes from ncio. The read_vardata calls for nccice and nconrd occur inside subcommunicator blocks. Not all tasks will see the error message. Thus, mpi_abort for mpi_comm_world will hang.

If you see an easy way to obtain the desire behavior, fine ... add it. If not, let's move on.

I see. @RussTreadon-NOAA Thanks for the heads up. I will try and let you know.

[RussTreadon-NOAA]

Looks good to me.

Approve.