Allow calc_analysis.x to switch between JEDI and GSI-formatted increments in calc_analysis.nml#35
Conversation
| work3d_bg(:,j,1) = work3d_bg(:,j,1) + work3d_inc(:,jj) | ||
| end do | ||
| ! JEDI-derived increments have a time dimension, so read to appropriate array | ||
| if ( jedi ) then |
There was a problem hiding this comment.
This is great. I suspect when we move from the AuxGrid in FV3-JEDI to the generic Gaussian interpolation/write in OOPS, this boolean will be even more important.
|
@DavidNew-NOAA can you (or have you already) run a low resolution 3DVar test using develop of g-w with this hash of gsi_utils just to confirm that it will cycle with GSI still? It should be fine but I would feel better testing it to be sure. |
|
@CoryMartin-NOAA I just ran this branch in GSI with GW feature/jediinc2fv3 (will be merged into develop soon, but test should work in develop already), and it got through a full cycle. It's moving through the next cycle now without problem, including gdasanalcalc of that cycle. |
|
Thanks @DavidNew-NOAA works for me! |
2 participants
Because the JEDI increments will soon be produced in the Global Workflow with a time dimension, calc_analysis.x will fail, since it expects a GSI-style increment with no time dimensions. The PR adds a "jedi" parameter in calc_analysis.nml that is default set to false. When it is false, it expects no time dimension when reading and adding the increment to the background, and when it is true, it does expect a time dimension.
I have tested this in the Global Workflow by adding and removing the time dimension for the atmospheric increment, and running calc_analysis.x in the "gdasanalcalc" job with jedi set to .true. and not set at all (defaults to false) respectively. The resulting analyses are zero diff.