ConMon -- add NetCDF Support

[EdwardSafford-NOAA]

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]

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]

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.

[EdwardSafford-NOAA]

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.

[EdwardSafford-NOAA]

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]

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]

@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]

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]

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.