Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ConMon -- add NetCDF Support #7

Closed
EdwardSafford-NOAA opened this issue Jun 8, 2020 · 42 comments · Fixed by #99
Closed

ConMon -- add NetCDF Support #7

EdwardSafford-NOAA opened this issue Jun 8, 2020 · 42 comments · Fixed by #99
Assignees

Comments

@EdwardSafford-NOAA
Copy link
Contributor

Modify the Conventional data monitor (ConMon): * change the package level build script to use the cmake utility and the $target specific module files. * utilize the latest version of read_diag.f90 to enable support for NetCDF formatted cnvstat diagnostic files.

This issue began as VLab #63754. Development will continue in repository EdwardSafford-NOAA/GSI in branch esafford_ConMon_63754.

@EdwardSafford-NOAA
Copy link
Contributor Author

Note that the original description of "utilize latest version of read_diag.f90..." is in error. That file in the GSI source code provides NetCDF support only for radiance diagnostic files. This ticket will include writing a conmon_read_diag.F90 module to enable reading conventional diag files. That will be implemented by data type (ps, q, t, uv, gpsro).

@EdwardSafford-NOAA
Copy link
Contributor Author

Complication:

I believe I've found another missing data element in the NetCDF formatted in the uv diag files. I'm using diag files from v16rt2 and when I do

dump -h diag_conv_uv_ges.2020051806.nc4

The variable list does not include Nonlinear_QC_Var_Jb. This variable is found in diag files for ps, t, and q types.

Further in the gsi code in setupw.f90 I find these lines (with line numbers):

  • 372 ijb=25 ! index of non linear qc parameter
  • 462 var_jb=data(ijb,i)
  • 1633 rdiagbuf(10,ii) = var_jb ! non linear qc parameter

Line 1633 is within subroutine contents_binary_diag_ but I don't find a similar assignment in subroutine contents_netcdf_diag_. I suspect setting the Nonlinear_QC_Var_Jb variable was overlooked.

KarinaApodaca-NOAA pushed a commit to KarinaApodaca-NOAA/GSI that referenced this issue Jun 9, 2020
@EdwardSafford-NOAA
Copy link
Contributor Author

Using code from release/gfsda.v16.0.0, added Nonlinear_QC_Var_Jb to the NetCDF diag file in setupw.f90. Used that branch so Russ could test is using v16rt2 parallel. The var is now included in the diagnostic file, and is 0 in all cases. Per Su, that's as it should be. I'll include that code change in this release.

@MichaelLueken MichaelLueken reopened this Jun 11, 2020
EdwardSafford-NOAA added a commit to EdwardSafford-NOAA/GSI that referenced this issue Jun 11, 2020
Saving current work before switching branches.
EdwardSafford-NOAA added a commit to EdwardSafford-NOAA/GSI that referenced this issue Jun 12, 2020
Save changes before updating from upstream.
@EdwardSafford-NOAA
Copy link
Contributor Author

Added support for reading gps diag files to the common module conmon_read_diag.F90. This is working in the first executable, conmon_grads_sfctime.x. Installing it in conmon_grads_sfc.x yielded a seg fault, which I'm investigating. But now it appears I've been hamstrung by a change in libraries or modules (cmake was updated and convoluted this AM) -- the nc references suddenly produce a raft of compiler failures.

EdwardSafford-NOAA added a commit to EdwardSafford-NOAA/GSI that referenced this issue Jun 18, 2020
Merge branch 'master' into esafford_ConMon_63754
@EdwardSafford-NOAA
Copy link
Contributor Author

Update: Compile issue continues to exist. I updated the hera mod file to correctly find the python and cmake modules. That fixed the GSI/ush/build_all_cmake.sh script. At the ConMon level though I'm running into a raft of undefined references to MPI resources. That I don't get; I'm not explicitly utilizing mpi resources in my code. Must be in the nc* libraries somewhere, but what changed that I'm now having problems? Thurs. last this compiled. Diagnosing issues with cmake is part logic and part dart throwing.

@CoryMartin-NOAA
Copy link
Contributor

@EdwardSafford-NOAA GSI and GFS now use netCDF compiled with MPI parallel IO. Take a look at https://github.com/NOAA-EMC/GSI/blob/master/util/netcdf_io/calc_analysis.fd/CMakeLists.txt, you probably just need to add MPI Fortran include/libs flags at compiling.

@EdwardSafford-NOAA
Copy link
Contributor Author

Update: Compile issue continues to exist. I updated the hera mod file to correctly find the python and cmake modules. That fixed the GSI/ush/build_all_cmake.sh script. At the ConMon level though I'm running into a raft of undefined references to MPI resources. I've added the MPI Fortran include/libs flags but my link errors continue. I'm at a loss.

@RussTreadon-NOAA
Copy link
Contributor

Use CMakeLists.txt in Radiance_Monitor to guide edits to CMakeLists.txt in Conventional_Monitor. After incremental updates Conventional_Monitor executables built on Hera using ush/build_all_cmake.sh. rsync working copy to Venus. ush/build_all_cmake.sh works on Venus. Provide details to Ed via a separate email.

@EdwardSafford-NOAA
Copy link
Contributor Author

ConMon build_all script is now working. Issues all involved the order of the NetCDF, HDF5, and MPI resource loads.

@EdwardSafford-NOAA
Copy link
Contributor Author

Have all of the conmon_grads_*.x executables working now. In reviewing the conmon_read_diag.F90 module I discovered that I missed adding a read function for sst (sea surface temp) files. SST isn't used by the ConMon but I should include that and gps (which is mostly there now) in the module. Comparing the contents of my sst diag files I find some mismatches with what I see in the GSI source file setupsst.f90, which writes both the binary and netcdf diag files. The issues are:

  • ncdump -h reports a variable of Pressure. This is loaded in setsst.f90 with this line:
    call nc_diag_metadata("Pressure", missing)
    while setssst.f90 loads the binary file this way:
    rdiagbuf(9,ii) = data(ipct,i) ! open water percentage (0 to 1)
    Note that other data types use pressure which is in the same file position as 'open water percentage' in the binary file, so this looks like a cut & paste and then not sure what to do situation. I think 'Pressure' should instead be 'Open_Water_Percentage' in the NetCDF file.

  • The binary file load in setsst.f90 includes this:
    rdiagbuf(6,ii) = data(itemp,i) ! background open water temperature (K)
    I don't see a similar variable in the NetCDF file load, unless that is "FoundationTempBG". If it is then we're still missing a field because "FoundationTempBG" is in the same position as this field in the binary load:
    rdiagbuf(maxinfo+1,ii) = data(itref,i) ! Tr

Not sure what "Tr" means here. But if "FoundationTempBG" == background open water temp then the NetCDF file has no equivalent variable for the "Tr" data.

  • The binary file load in setsst.f90 includes this:
    rdiagbuf(7,ii) = data(izob,i) ! observation depth (meters)
    I see no equivalent variable to 'observation depth' in the NetCDF file load.

  • The binary file load in setsst.f90 includes this:
    rdiagbuf(20,ii) = data(iotype,i) ! type of measurement
    I see no equivalent variable to 'type of measurement' in the NetCDF file load.

EdwardSafford-NOAA added a commit to EdwardSafford-NOAA/GSI that referenced this issue Jun 26, 2020
Add changes to the conmon_grads* executables.
@EdwardSafford-NOAA
Copy link
Contributor Author

Cleaned up the conmon_read_diag.F90 module. Latest version is now in all the conmon_grads_* executables and compiles at the ConMon level build. The GSI/ush/build_all_cmake.sh still doesn't work with the ConMon executables. Have yet to find the issue, which must be in the GSI/CMakefile.txt, but I will.

@EdwardSafford-NOAA
Copy link
Contributor Author

Figured out the top level build problem. What was missing was an include directory for each executable where compiled mods apparently are placed. Without this the gsi files that included kinds.F90 couldn't find it. Not sure I understand how the build is working but these two lines are what fixed the issues with ConMon builds (at the GSI level):

  • set(Util_MODULE_DIR ${PROJECT_BINARY_DIR}/include/conmon_grads_sfctime )
  • set_target_properties( conmon_grads_sfctime.x PROPERTIES Fortran_MODULE_DIRECTORY ${Util_MODULE_DIR} )

EdwardSafford-NOAA added a commit to EdwardSafford-NOAA/GSI that referenced this issue Jul 6, 2020
Update data_mod.f90 to add enumerated index numbers
for every data type for access to the rdiag array.
EdwardSafford-NOAA added a commit to EdwardSafford-NOAA/GSI that referenced this issue Jul 6, 2020
Save off work for tomorrow's hera outage.
EdwardSafford-NOAA added a commit to EdwardSafford-NOAA/GSI that referenced this issue Jul 19, 2020
Add recent changes to conmon_read_diag module, time_vert
processing.
@EdwardSafford-NOAA
Copy link
Contributor Author

All horiz_hist executables are working. Now adapting the time_vert executable to use the conmon_read_diag.f90 module. Running into run-time issues with the t data. The ps data ran slowly but not prohibitively so, but I'll have to do some engineering on the ps and uv data.

EdwardSafford-NOAA added a commit to EdwardSafford-NOAA/GSI that referenced this issue Jul 21, 2020
Complete work on conmon_read_diag mod to enable reading entire
contents of a conventional diag file.  This capability is
required by the time_vert executable.
@EdwardSafford-NOAA
Copy link
Contributor Author

Have begun testing on wcoss_d with live v16rt2 data. As anticipated, memory use for submitted jobs is many times larger than it is for binary formatted diag files, though it's still under 900MB. The time is longer, but only about 2x binary files. This is a single node, downstream process so that shouldn't be an issue.

EdwardSafford-NOAA added a commit to EdwardSafford-NOAA/GSI that referenced this issue Jul 27, 2020
Update hera test driver script.
@EdwardSafford-NOAA
Copy link
Contributor Author

EdwardSafford-NOAA commented Jul 27, 2020

Horizontal plots seem to be working. Working on hist plots, found an issue with missing and 0 sized scater data files. Traced that back to errors in the diag2grads* scripts which resulted in the scater files not getting transferred to the $TANKDIR. Fixed that, so hist plots have a greater chance of working now.

EdwardSafford-NOAA added a commit to EdwardSafford-NOAA/GSI that referenced this issue Jul 27, 2020
Add changes for wcoss_d.
EdwardSafford-NOAA added a commit to EdwardSafford-NOAA/GSI that referenced this issue Jul 27, 2020
Merge branch 'esafford_ConMon_63754' of
https://github.com/EdwardSafford-NOAA/GSI
into esafford_ConMon_63754
@daviddowellNOAA daviddowellNOAA mentioned this issue Aug 22, 2023
9 tasks
@wx20jjung wx20jjung mentioned this issue Sep 4, 2023
6 tasks
ShunLiu-NOAA pushed a commit that referenced this issue Sep 29, 2023
… (see issue #601) (#614)

Adding code to analyze the siginificant wave heigh in GSI 3D Analysis,
esp. for FV3-LAM model based DA, eg. RRFS-DA, RRFS-3DRTMA. (Also see the
issue in EMC GSI github repository: #601
 Adding I/O for Analysis of Significant Wave Height for 3DRTMA)

<!-- PLEASE READ -->
<!--
Before opening a PR, please note these guidelines:

- Each PR should only address ONE topic and have an associated issue
- No hardcoded or paths to personal directories should be present
- No temporary or backup files should be committed
- Any code that was disabled by being commented out should be removed
-->

**Description**

<!-- Please include relevant motivation and context. -->
Significant Wave Height (hereafter as SWH) is one of the standard
products provided by the operational (2D)RTMA. To continuously provide
the same products in 3DRTMA, the next-generation RTMA, some efforts in
GSI code need to be made in order to analyze the SWH in 3D analysis of
GSI.
<!-- Please include a summary of the change and which issue is fixed.
-->
The kernel subroutines to assimilate SWH in GSI (such as stphowv.f90,
setuphowv.f90, inthowv.f90, gsi_howvOper.f90 and m_howvNode.f90) already
had been added for (2D)RTMA years ago by Manuel Pondeca, so for this
issue, the code work mainly focus on adding the I/O of SWH in background
and analysis fields for 3DRTMA (esp. RRFS-based 3DRTMA), and some
necessary modifications in background error, options, variables related
to analysis of SWH, etc.
Modified code in GSI:
1. rapidrefresh_cldsurf_mod.f90: adding a few variables related to the
analysis of howv in 3D analysis
2. gsimod.F90: adding namelist options used for analysis of howv in 3D
analysis
3. m_berror_stats_reg.f90: added some code for the special treatment to
the static background error (BE) of howv
4. read_prepbufr.f90: adding code to decode the observation of howv in
prepbufr file when howv is available in firstguess
5. setuphowv.f90: adding code to use obs of howv when howv is available
in firstguess
6. gsi_rfv3io_mod.f90: adding I/O code to read in howv from firstguess
and write out howv into analysis.


<!-- List any dependencies that are required for this change. -->
No dependencies are required for this change.
<!-- Please provide reference to the issue this pull request is
addressing. -->
This PR is addressing the issue
[#601](#601): Adding code to
analyze the siginificant wave heigh in GSI 3D Analysis".
<!-- For e.g. Fixes #IssueNumber -->
Fixes #601

**Type of change**

Please delete options that are not relevant.


- [*] New feature (non-breaking change which adds functionality)



**How Has This Been Tested?**

<!-- Please describe the tests that you ran to verify your changes and
on the platforms these tests were conducted. -->
- Brief results from ctest (regression test) with the modified code (on
WCOSS2 - Cactus):

 [gang.zhao@clogin07:build] (feature/3drtma_howv)$ ctest -N
Test project /lfs/h2/emc/da/save/gang.zhao/WorkDir/WaveHgt/develop/build
  Test #1: global_3dvar
  Test #2: global_4dvar
  Test #3: global_4denvar
  Test #4: hwrf_nmm_d2
  Test #5: hwrf_nmm_d3
  Test #6: rtma
  Test #7: rrfs_3denvar_glbens
  Test #8: netcdf_fv3_regional
  Test #9: global_enkf

Total Tests: 9
  Test #1: global_3dvar
[gang.zhao@clogin04:build] (feature/3drtma_howv)$ ctest -R global_3dvar
Test project /lfs/h2/emc/da/save/gang.zhao/WorkDir/WaveHgt/develop/build
    Start 1: global_3dvar
1/1 Test #1: global_3dvar .....................   Passed  1631.12 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) = 1631.14 sec

  Test #2: global_4dvar
[gang.zhao@clogin09:build] (feature/3drtma_howv)$ ctest -R global_4dvar
Test project /lfs/h2/emc/da/save/gang.zhao/WorkDir/WaveHgt/develop/build
    Start 2: global_4dvar
1/1 Test #2: global_4dvar .....................   Passed  2462.19 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) = 2462.23 sec

  Test #3: global_4denvar
[gang.zhao@clogin04:build] (feature/3drtma_howv)$ ctest -R
global_4denvar
Test project /lfs/h2/emc/da/save/gang.zhao/WorkDir/WaveHgt/develop/build
    Start 3: global_4denvar
1/1 Test #3: global_4denvar ...................   Passed  1922.43 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) = 1922.46 sec

  Test #4: hwrf_nmm_d2
[gang.zhao@clogin09:build] (feature/3drtma_howv)$ ctest -R hwrf_nmm_d2
Test project /lfs/h2/emc/da/save/gang.zhao/WorkDir/WaveHgt/develop/build
    Start 4: hwrf_nmm_d2
1/1 Test #4: hwrf_nmm_d2 ......................   Passed  1214.10 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) = 1214.20 sec

  Test #5: hwrf_nmm_d3
[gang.zhao@clogin09:build] (feature/3drtma_howv)$ ctest -R hwrf_nmm_d3
Test project /lfs/h2/emc/da/save/gang.zhao/WorkDir/WaveHgt/develop/build
    Start 5: hwrf_nmm_d3
1/1 Test #5: hwrf_nmm_d3 ......................   Passed  736.38 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) = 736.50 sec

  Test #6: rtma
[gang.zhao@clogin05:build] (feature/3drtma_howv)$ ctest -R rtma
Test project /lfs/h2/emc/da/save/gang.zhao/WorkDir/WaveHgt/develop/build
    Start 6: rtma
1/1 Test #6: rtma .............................   Passed  1027.01 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) = 1027.01 sec

  Test #7: rrfs_3denvar_glbens
[gang.zhao@clogin06:build] (feature/3drtma_howv)$ ctest -R
rrfs_3denvar_glbens
Test project /lfs/h2/emc/da/save/gang.zhao/WorkDir/WaveHgt/develop/build
    Start 7: rrfs_3denvar_glbens
1/1 Test #7: rrfs_3denvar_glbens ..............   Passed  484.69 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) = 484.70 sec

  Test #8: netcdf_fv3_regional
[gang.zhao@clogin03:build] (feature/3drtma_howv)$ ctest -R
netcdf_fv3_regional
Test project /lfs/h2/emc/da/save/gang.zhao/WorkDir/WaveHgt/develop/build
    Start 8: netcdf_fv3_regional
1/1 Test #8: netcdf_fv3_regional ..............   Passed  483.08 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) = 483.11 sec

  Test #9: global_enkf
[gang.zhao@clogin03:build] (feature/3drtma_howv)$ ctest -R global_enkf
Test project /lfs/h2/emc/da/save/gang.zhao/WorkDir/WaveHgt/develop/build
    Start 9: global_enkf
1/1 Test #9: global_enkf ......................   Passed  488.50 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) = 488.57 sec

- The modified GSI code passed the regression tests (all 9 tasks) on
Hera and WCOSS2 (Cactus).

- adding the analysis of howv only has very trial influences on the
analyses of other variables. Here is the statistics of the differences
of other variables (u/v/t/ps/q/t2m/q2m) from the runs of GSI without
howv vs. with howv (from a testing case 2023-07-12_14:00:00 UTC in 3km
North-American domain):

comparing two netcdf files:
fcst_fv3lam_hyb_betas/INPUT/fv_core.res.tile1.nc
fcst_fv3lam_nodata_noinfo/INPUT/fv_core.res.tile1.nc ...
Variable Group Count Sum AbsSum Min Max Range Mean StdDev
u / 602135550 3926.84 25760.8 -0.1026 0.485788 0.588388 6.52152e-06
0.00115817
v / 620166777 -4891.34 32582.5 -0.835774 0.268402 1.10418 -7.88714e-06
0.00197793
T / 155987083 178.048 6497.51 -0.0246582 0.0384064 0.0630646 1.14143e-06
0.000218737
delp / 19559676 -281.532 3008.29 -0.00292969 0.00219727 0.00512695
-1.43935e-05 0.000183727

comparing two netcdf files:
fcst_fv3lam_hyb_betas/INPUT/fv_tracer.res.tile1.nc
fcst_fv3lam_nodata_noinfo/INPUT/fv_tracer.res.tile1.nc ...
Variable Group Count Sum AbsSum Min Max Range Mean StdDev
sphum / 430707614 0.594287 2.77816 -2.6139e-05 3.1759e-05 5.7898e-05
1.37979e-09 8.03072e-08

comparing two netcdf files: fcst_fv3lam_hyb_betas/INPUT/sfc_data.nc
fcst_fv3lam_nodata_noinfo/INPUT/sfc_data.nc ...
Variable Group Count Sum AbsSum Min Max Range Mean StdDev
t2m / 10665000 43.3899 135.095 -0.00152825 0.00686629 0.00839454
4.06844e-06 5.02866e-05
q2m / 10665000 0.0192553 0.124707 -3.1476e-06 1.77554e-05 2.0903e-05
1.80547e-09 5.89657e-08

It could be seen that the differences are trivial and ignorable.

<!-- Provide instructions so we can reproduce. -->
The regression tests were done by following the instructions of "[GSI
Ctests (regression
tests)](https://github.com/NOAA-EMC/GSI/wiki/GSI-Ctests-(regression-tests))"
in [GSI Wiki](https://github.com/NOAA-EMC/GSI/wiki)
<!-- Please also list any relevant details for your test configuration
-->
The modified code had also been tested with a testing case
2023-07-12_14:00:00 UTC for 3km North-American domain
Here is a brief summary of the test results:
1. Here is the analysis increment of Significant Wave Height (aka howv
hereafter): pure 3dvar, static background error of howv is 0.42 meters,
and the de-correlation length scale is 170km.

![HOWV_var_inc_maprll_datll_reg_ncf](https://github.com/NOAA-EMC/GSI/assets/53267411/4fdeeb82-7258-4344-be69-cce747474312)
2. The following figure shows the distribution of howv in the analysis
(used obs is in green, rejected in red). Obviously the location of used
obs of howv match the area of non-zero analysis increments of howv.

![var_obs_2023071214_howv_maprll_datll_reg_ncf](https://github.com/NOAA-EMC/GSI/assets/53267411/d4ed6013-cfc8-486e-8f47-db07ec0e4e53)
3. The following figure is the analysis increment of howv with hybrid
envar analysis (using gdas ensemble 80 members and the ensemble weight
is 84%), and the static BE of howv is tuned/inflated. The analysis
increments are very similar to the results from pure 3dvar run (see the
first figure)

![HOWV_hyb_betas016_inc_maprll_datll_reg_ncf](https://github.com/NOAA-EMC/GSI/assets/53267411/e6e696e8-932b-42ab-9001-3472e970b21c)
4. The last figure shows the analysis increments of howv with hybrid
envar analysis (using gdas ensemble 80 members and the ensemble weight
is 84%), but the static BE of howv is NOT tuned. It can be observed that
the analysis increments is less than the results from the hybrid run
with tuning the static BE of howv. That is because the weight of static
BE (16%) reduced the background error of howv (ensemble of howv is not
available yet), so the impact of obs is decreased.

![HOWV_hyb_betas016_noTune_inc_maprll_datll_reg_ncf](https://github.com/NOAA-EMC/GSI/assets/53267411/ca25d068-fc86-4d47-a9d2-46e02ac22dac)

  
**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

**DUE DATE for this PR is 10/5/2023.** If this PR is not merged into
`develop` by this date, the PR will be closed and returned to the
developer.
@ShunLiu-NOAA ShunLiu-NOAA mentioned this issue Oct 4, 2023
9 tasks
@wx20jjung wx20jjung mentioned this issue Feb 26, 2024
1 task
ShunLiu-NOAA pushed a commit that referenced this issue Mar 27, 2024
**DUE DATE for merger of this PR into `develop` is 2/19/2024 (six weeks
after PR creation).**
**DUE DATE for this PR is extended to 3/19/2024 because @XuLu-NOAA is on
leave.**
**Description**

Xu Lu ([email protected]) and Biju Thomas ([email protected]) fixed bugs
regarding HAFS GSI debug build and run issues. This is in corresponding
to issue #661

Fixes #661

1. In read_radar.f90, uninitialized toff is making all the ground-based
radar observations be placed at -3h instead of 0h, which creates wrong
increments for FGAT and 4DEnVar.
2. In read_radar.f90, uninitialized zsges will crash the debug mode.
3. In read_radar.f90, t4dvo should be used instead of t4dv in the
read_radar_l2rw_novadqc subroutine.
4. In radinfo.90, maxscan should be increased to at least 252 to allow
more scans, or it will crash the debug mode.
5. In read_fl_hdob.f90, dlnpsob is replaced with 1000. since the SFMR
does not sample surface pressure, and the uninitialized dlnpsob creates
issues later in setupspd.f90 in the debug mode.
6. In mod_fv3_lola.f90, (i,j+1) should be used instead of (i+1,j) in
searching for V edges.
7. In stpcalc.f90, when tried to find the best stepsize from outpen
around L838-864, the minimum outstp(i) is stored in stp(ii), but the
istp_use is asigned with i instead of ii. Create inconsistency when
assigning stp(istp_use) to stpinout at L872. Should use istp_use=ii
instead.

**Type of change**
- [Yes] Bug fix (non-breaking change which fixes an issue)

**How Has This Been Tested?**
Regression test on Orion:
```
Test project /work/noaa/hwrf/save/xulu/mergeversions/GSI/build
CMake Warning (dev) at CTestTestfile.cmake:9 (subdirs):  Syntax Warning in cmake code at /work/noaa/hwrf/save/xulu/mergeversions/GSI/build/regression/CTestTestfile.cmake:7:10
1/7 Test #4: [=[netcdf_fv3_regional]=] ........   Passed  365.11 sec
2/7 Test #7: [=[global_enkf]=] ................   Passed  430.29 sec
3/7 Test #3: [=[rrfs_3denvar_glbens]=] ........   Passed  605.35 sec
4/7 Test #2: [=[rtma]=] .......................   Passed  969.78 sec
5/7 Test #6: [=[hafs_3denvar_hybens]=] ........***Failed  1455.47 sec
6/7 Test #1: [=[global_4denvar]=] .............   Passed  1682.40 sec
7/7 Test #5: [=[hafs_4denvar_glbens]=] ........***Failed  1758.90 sec
```

The failed hafs_3denvar and 4denvar are within expectation due to the
fix for toff. As demonstrated in the single observation tests in the
following figure, the uninitialized toff can result in increment
degradations due to wrongly assigned observation times:

![image](https://github.com/NOAA-EMC/GSI/assets/26603014/0de870e1-f8c8-4b6d-8039-57f417b76367)
ShunLiu-NOAA pushed a commit that referenced this issue Apr 5, 2024
…ed 3DRTMA (#730)

<!-- PLEASE READ -->
<!--
Before opening a PR, please note these guidelines:

- Each PR should only address ONE topic and have an associated issue
- No hardcoded or paths to personal directories should be present
- No temporary or backup files should be committed
- Any code that was disabled by being commented out should be removed
-->

**Description**

<!-- Please include relevant motivation and context. -->
<!-- Please include a summary of the change and which issue is fixed.
-->
<!-- List any dependencies that are required for this change. -->
To improve the analysis of the near-surface wind gust in 3DRTMA, the
observations of near-surface wind gust would be analyzed directly in GSI
(3DVar and Hybrid 3DEnVar), instead of being a derived product from the
near-surface wind analysis.

Since the core subroutines for direct variational assimilation of wind
gust (e.g., setupgust.f90, intgust.f90, stpgust.f90, etc.) had already
been implemented in GSI for 2DRTMA, so in the work the development in
GSI mainly focus on adding I/O of 2-D wind gust firstguess and analysis
fields for RRFS-based 3DRTMA, and some minor modifications in
observation and background error for wind gust, options to control the
analysis of wind gust, etc.
<!-- Please provide reference to the issue this pull request is
addressing. -->
<!-- For e.g. Fixes #IssueNumber -->
This PR is to address the issue #726 : Adding I/O for direct analysis of
near-surface wind gust for RRFS-based 3DRTMA
Fixes #726
**Type of change**

Please delete options that are not relevant.

- [x] New feature (non-breaking change which adds functionality)

**How Has This Been Tested?**

<!-- Please describe the tests that you ran to verify your changes and
on the platforms these tests were conducted. -->
<!-- Provide instructions so we can reproduce. -->
<!-- Please also list any relevant details for your test configuration
-->
  
**Checklist**

- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [x] New and existing tests pass with my changes
      tested with a real case - 2024-02-20_12:00Z, 
1. dry-run (using my updated GSI code with wind gust analysis, but
actually no wind gust obs is analyzed, so-called dryrun) is compared to
control-run (original GSI code running without wind gust obs): the
results are identical. This indicates that if without analyzing
wind-gust obs, then the updated code generates the analysis identical to
the analysis of original/control code. Or say, the added code does not
have influence on the other part of code.
2. real case run with updated GSI code to analyze the obs of wind gust:
The following figure shows the used observations of near-surface wind
gust:

![var_obs_2024022012_gust_used_maprll_datll_reg_ncf](https://github.com/NOAA-EMC/GSI/assets/53267411/ecbe479a-03c6-490f-a179-9e0027291468)
the following figure shows the analysis increments:

![GUST_hyb_hwllp90_corptuned_inc_incrintrp_maprll_datrll_reg_grb2](https://github.com/NOAA-EMC/GSI/assets/53267411/a01fca0d-dc1f-438b-b8eb-e624de35a631)
- [x] Any dependent changes have been merged and published
- [x] Regression tests on WCOSS2 (Cactus) and Hera (Rocky-8) : my
updated GSI commit
[#f91f247d](GangZhao-NOAA@f91f247))
vs control/original GSI code (commit
[#6d9ebbb7](6d9ebbb))
Here is the reports of the regression tests on WCOSS2 (Cactus):
~~~
[gang.zhao@clogin02:build] (feature/windgust_in_3dvar_for_3drtma)$ ctest
-j 7
Test project
/lfs/h2/emc/da/save/gang.zhao/WorkDir/ProdGSI_Dev/gsi_dev/build
    Start 1: global_4denvar
    Start 2: rtma
    Start 3: rrfs_3denvar_glbens
    Start 4: netcdf_fv3_regional
    Start 5: hafs_4denvar_glbens
    Start 6: hafs_3denvar_hybens
    Start 7: global_enkf
1/7 Test #4: netcdf_fv3_regional ..............   Passed  483.15 sec
2/7 Test #3: rrfs_3denvar_glbens ..............   Passed  486.74 sec
3/7 Test #7: global_enkf ......................   Passed  850.98 sec
4/7 Test #2: rtma .............................   Passed  970.28 sec
5/7 Test #6: hafs_3denvar_hybens ..............   Passed  1152.82 sec
6/7 Test #5: hafs_4denvar_glbens ..............   Passed  1213.93 sec
7/7 Test #1: global_4denvar ...................   Passed  1683.16 sec

100% tests passed, 0 tests failed out of 7

Total Test time (real) = 1683.19 sec
~~~
Here is the reports of the regression tests on Hera (Rocky8):
~~~
(base) [Gang.Zhao@hfe11:build] (feature/windgust_in_3dvar_for_3drtma)$
ctest -j 7
Test project /scratch1/NCEPDEV/da/Gang.Zhao/ProdGSI_dev/gsi_dev/build
    Start 1: global_4denvar
    Start 2: rtma
    Start 3: rrfs_3denvar_glbens
    Start 4: netcdf_fv3_regional
    Start 5: hafs_4denvar_glbens
    Start 6: hafs_3denvar_hybens
    Start 7: global_enkf
1/7 Test #4: netcdf_fv3_regional ..............   Passed  491.53 sec
2/7 Test #3: rrfs_3denvar_glbens ..............***Failed  495.27 sec
3/7 Test #2: rtma .............................   Passed  982.45 sec
4/7 Test #6: hafs_3denvar_hybens ..............   Passed  1168.99 sec
5/7 Test #7: global_enkf ......................   Passed  1239.77 sec
6/7 Test #5: hafs_4denvar_glbens ..............***Failed  1347.87 sec
7/7 Test #1: global_4denvar ...................   Passed  1974.45 sec

71% tests passed, 2 tests failed out of 7

Total Test time (real) = 1974.91 sec

The following tests FAILED:
          3 - rrfs_3denvar_glbens (Failed)
          5 - hafs_4denvar_glbens (Failed)
Errors while running CTest
Output from these tests are in:
/scratch1/NCEPDEV/da/Gang.Zhao/ProdGSI_dev/gsi_dev/build/Testing/Temporary/LastTest.log
Use "--rerun-failed --output-on-failure" to re-run the failed cases
verbosely.
(base) [Gang.Zhao@hfe11:build] (feature/windgust_in_3dvar_for_3drtma)$
ctest -R rrfs_3denvar_glbens
Test project /scratch1/NCEPDEV/da/Gang.Zhao/ProdGSI_dev/gsi_dev/build
    Start 3: rrfs_3denvar_glbens
1/1 Test #3: rrfs_3denvar_glbens ..............   Passed  430.52 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) = 430.55 sec
(base) [Gang.Zhao@hfe11:build] (feature/windgust_in_3dvar_for_3drtma)$
ctest -R hafs_4denvar_glbens
Test project /scratch1/NCEPDEV/da/Gang.Zhao/ProdGSI_dev/gsi_dev/build
    Start 5: hafs_4denvar_glbens
1/1 Test #5: hafs_4denvar_glbens ..............   Passed  1225.37 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) = 1225.39 sec
~~~
**Note**: 
_When I was running the regression tests, GSI code was just updated to
the latest commit
[#b53740a7](GangZhao-NOAA@f91f247).
Considering the frequent update in EMC GSI code recently and saving the
time, after this PR has been reviewed and approved by peer-reviewers, I
will update the code to latest EMC GSI commit, then re-run the
regression tests for final approval.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants