inconsistent dzdt treatment in chgres_cube

[sentientc]

Hi, I found dzdt in guassian_netcdf and gaussian_nemsio were treated differently. Is there a reason for this? Also, by leaving it dzdt m/s and not converting to w Pa/s will cause problem when running the model.

https://github.com/ufs-community/UFS_UTILS/blob/develop/sorc/chgres_cube.fd/input_data.F90 subroutine read_input_atm_gaussian_netcdf_file set dzdt to 0 at line 2049 However, sHi,ubroutine read_input_atm_gaussian_nemsio_file read in dzdt as is at line 1403. Regards,

[GeorgeGayno-NOAA]

@sentientc The forecast model has initialization steps that convert the vertical velocity record (among other conversions). And those conversion steps are run or not run based on the source data used to create the initial conditions.

We have an issue open (#539) to move these initialization steps from the model to chgres. But we have not made much progress so far.

[sentientc]

@GeorgeGayno-NOAA I may missed some of the run or not run according to the IC type. It appears that setting w to 0 in the chgres_cube processed gfs_data*nc solved a lot of the problem for me. I am wondering if it is a valid approach as I have no access to the planning document mentioned in #539 (https://docs.google.com/document/d/1fA_laqSZIdUCT7g2P9wWEY4MhBB3iRxJao3KsUAVJz8/edit).

[GeorgeGayno-NOAA]

Here is the model routine that converts the vertical velocity: https://github.com/NOAA-GFDL/GFDL_atmos_cubed_sphere/blob/main/tools/external_ic.F90#L3016

What input data was used that required you to set w to 0? The GFSv16 gaussian netcdf?

[sentientc]

@GeorgeGayno-NOAA external_ic line 3016 did set gp=omga, however, omga is 0 when it is gaussian_netcdf in chgres_cube. See https://github.com/ufs-community/UFS_UTILS/blob/develop/sorc/chgres_cube.fd/input_data.F90#L2049 "! dzdt set to zero for now." gaussian_nemsio on the other hand read dzdt as omga. At around Oct, 2019, nemsio file changed to include dzdt and this dzdt will cause problem like log of negative value as it is in m/s instead of Pa/s.

[sentientc]

@GeorgeGayno-NOAA nemsio IC downloaded for 2019100418. gaussian netcdf have set dzdt to 0 so omga is 0 but nemsio around Oct, 2019 have non-zero dzdt. Which is the intended way?

https://github.com/ufs-community/UFS_UTILS/blob/develop/sorc/chgres_cube.fd/input_data.F90#L2049 gaussian netcdf set dzdt to 0 gaussian nemsio read dzdt
sgio have no dzdt so set dzdt to 0 grib2 read dzdt or vvel

[GeorgeGayno-NOAA]

@GeorgeGayno-NOAA external_ic line 3016 did set gp=omga, however, omga is 0 when it is gaussian_netcdf in chgres_cube. See https://github.com/ufs-community/UFS_UTILS/blob/develop/sorc/chgres_cube.fd/input_data.F90#L2049 "! dzdt set to zero for now." gaussian_nemsio on the other hand read dzdt as omga. At around Oct, 2019, nemsio file changed to include dzdt and this dzdt will cause problem like log of negative value as it is in m/s instead of Pa/s.

The change from omega (GFS v14) to dzdt (GFS v15) occurred in June 2019. chgres places a global attribute in the coldstart file to document which input data source was used. See here - https://github.com/ufs-community/UFS_UTILS/blob/develop/sorc/chgres_cube.fd/write_data.F90#L526

For v14 data, the attribute is 'SPECTRAL GFS GAUSSIAN NEMSIO FILE', and for v15 data, the attribute is 'FV3GFS GAUSSIAN NEMSIO FILE'. The model code reads that attribute here - https://github.com/NOAA-GFDL/GFDL_atmos_cubed_sphere/blob/main/model/fv_regional_bc.F90#L6768 and sets the 'source_fv3gfs' logical. When false, omega is converted to dzdt.

[sentientc]

fv_regional_bc.F90 does solve the unit difference but omga or w in gfs_data.tile*.nc is still 0 for gaussian_netcdf or 'FV3GFS GAUSSIAN NETCDF FILE'. My question is whether to change https://github.com/ufs-community/UFS_UTILS/blob/develop/sorc/chgres_cube.fd/input_data.F90#L2049 to read in dzdt as w for netcdf v16 data(?).