Required string for processing of input fields from chgres_cube

[JeffBeck-NOAA]

The value of the SOURCE metadata string in the chgres_cube gfs_data.nc output file apparently determines how FV3 treats input fields. For example, unless the string is set explicitly to "FV3GFS GAUSSIAN NEMSIO FILE," hydrometeor and potentially other fields are ignored and initialized as zeros. Certain field modifications/adjustments also take place unless this string is specifically set to the value of "FV3GFS GAUSSIAN NEMSIO FILE."

When using data from HRRR, RAP, or NAM, sourced from grib2 files, we need to be able to modify this string to something like "GRIB2 FILE" without having FV3 ignore necessary fields.

Is there documentation somewhere that specifies what FV3 does based on this string, which fields it ignores/ingests and what field adjustments takes place? These options would be much better suited as run-time FV3 namelist flags.

Related Issues

https://github.com/NOAA-EMC/UFS_UTILS/issues/539

[junwang-noaa]

Jeff,

This sounds a chgres issue, would you please open an issue at:

https://github.com/NOAA-EMC/UFS_UTILS

Thanks

[JeffBeck-NOAA]

Hi Jun,

This is actually a problem in the FV3 code. FV3 uses the value of this string in gfs_data.nc to decide how to initialize certain fields, instead of reading in the fields directly as they were produced by chgres_cube. If the string isn't specifically defined as "FV3GFS GAUSSIAN NEMSIO FILE", the FV3 code will modify various input variables without the user ever knowing. For example, since not all files are "FV3GFS GAUSSIAN NEMSIO", when we set this string to "GRIB2 FILE", one result is that FV3 does not initialize hydrometeors from Thompson MP included in the gfs_data.nc file correctly, it zeroes them out instead.

I would argue that the value of this string shouldn't determine modifications to initialized fields and that all options to handle and modify ICs should be done within chgres_cube, not the model code itself. Would you agree? Hopefully this make sense? Thanks!

• Jeff

Tagging @LarissaReames-NOAA @gsketefian @jwolff-ncar @JacobCarley-NOAA

[junwang-noaa]

I see. Maybe I missed something, I thought that code adjusts the hydrometeors, I did not see the code sets the hydrometeors zerors. I am wondering if you have "GRIB2 FILE", does the file actually have all the hydrometeors for Thompson MP? I am not sure how chgre_cube creates the hydrometeors from GRIB2 file, I thought most of the hydrometeors were zeros in those files.

On Wed, Jun 10, 2020 at 4:21 PM JeffBeck-NOAA notifications@github.com wrote:

Hi Jun,

This is actually a problem in the FV3 code. FV3 uses the value of this string in gfs_data.nc to decide how to initialize certain fields, instead of reading in the fields directly as they were produced by chgres_cube. If the string isn't specifically defined as "FV3GFS GAUSSIAN NEMSIO FILE", the FV3 code will modify various input variables without the user ever knowing. For example, since not all files are "FV3GFS GAUSSIAN NEMSIO", when we set this string to "GRIB2 FILE", one result is that FV3 does not initialize hydrometeors from Thompson MP included in the gfs_data.nc file correctly, it zeroes them out instead. The value of this string should not determine modifications to initialized fields. I would argue that all options to handle and modify ICs should be done within chgres_cube, not the model code itself. Hopefully this make sense? Thanks!

• Jeff

Tagging @LarissaReames-NOAA https://github.com/LarissaReames-NOAA @gsketefian https://github.com/gsketefian @jwolff-ncar https://github.com/jwolff-ncar

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ufs-community/ufs-weather-model/issues/97#issuecomment-642236117, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI7D6TN3AOU66J2SASEY5UTRV7TKJANCNFSM4L3B4XHQ .

[JeffBeck-NOAA]

Hi Jun,

Yes, the "source" string is something that is assigned in chgres_cube, but our IC/BCs come from RAPX or HRRRX data and they have all hydrometeors included. Depending on what that string is defined as, FV3 modifies lots of initialization data. These routines are defined here:

FV3/atmos_cubed_sphere/tools/external_ic.F90 FV3/atmos_cubed_sphere/model/fv_regional_bc.F90

For example, see here in external_ic.F90:

if (trim(source) /= 'FV3GFS GAUSSIAN NEMSIO FILE') then if ( Atm%flagstruct%nwat .eq. 6 ) then do k=1,npz do i=is,ie qn1(i,k) = Atm%q(i,j,k,liq_wat) Atm%q(i,j,k,rainwat) = 0. Atm%q(i,j,k,snowwat) = 0. Atm%q(i,j,k,graupel) = 0.

If the string is NOT defined as specifically "FV3GFS GAUSSIAN NEMSIO FILE", then rain, snow, and graupel are zeroed out.

There are many other examples of these routines that are based on this string value, such as "computing true temperature using hydrostatic balance", "separating cloud water and cloud ice", and "mapping omega".

• Jeff

On Wed, Jun 10, 2020 at 3:02 PM Jun Wang notifications@github.com wrote:

I see. Maybe I missed something, I thought that code adjusts the hydrometeors, I did not see the code sets the hydrometeors zerors. I am wondering if you have "GRIB2 FILE", does the file actually have all the hydrometeors for Thompson MP? I am not sure how chgre_cube creates the hydrometeors from GRIB2 file, I thought most of the hydrometeors were zeros in those files.

On Wed, Jun 10, 2020 at 4:21 PM JeffBeck-NOAA notifications@github.com wrote:

Hi Jun,

This is actually a problem in the FV3 code. FV3 uses the value of this string in gfs_data.nc to decide how to initialize certain fields, instead of reading in the fields directly as they were produced by chgres_cube. If the string isn't specifically defined as "FV3GFS GAUSSIAN NEMSIO FILE", the FV3 code will modify various input variables without the user ever knowing. For example, since not all files are "FV3GFS GAUSSIAN NEMSIO", when we set this string to "GRIB2 FILE", one result is that FV3 does not initialize hydrometeors from Thompson MP included in the gfs_data.nc file correctly, it zeroes them out instead. The value of this string should not determine modifications to initialized fields. I would argue that all options to handle and modify ICs should be done within chgres_cube, not the model code itself. Hopefully this make sense? Thanks!

• Jeff

Tagging @LarissaReames-NOAA https://github.com/LarissaReames-NOAA @gsketefian https://github.com/gsketefian @jwolff-ncar https://github.com/jwolff-ncar

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/ufs-community/ufs-weather-model/issues/97#issuecomment-642236117 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AI7D6TN3AOU66J2SASEY5UTRV7TKJANCNFSM4L3B4XHQ

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ufs-community/ufs-weather-model/issues/97#issuecomment-642258537, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANFE563USLALRKIA56TA36DRV7YG5ANCNFSM4L3B4XHQ .

[yangfanglin]

Jeff,

The external_ic.F90 was originally written for “cold” start the model with hydrostatic spectral gfs initial conditions, which only had total cloud water as the prognostic cloud hydrometer. The string was added to allow for the model to start from FV3GFS era nemsio files from cycled experiments. Because the required hydrometers are presented and orography is the same, therefore many of the adjustments are not needed. If you were to start from initial conditions different from those of ifs, gfs.v14 and gfs.v15, this program needs to be revisited and probably updated to deal with different “cold” start scenarios correctly. For instance, to using RAP ICS, you may still need topography adjustment but without zeroing out the hydrometers.

My two cents Fanglin

On Wed, Jun 10, 2020 at 6:01 PM JeffBeck-NOAA notifications@github.com wrote:

Hi Jun,

Yes, the "source" string is something that is assigned in chgres_cube, but our IC/BCs come from RAPX or HRRRX data and they have all hydrometeors included. Depending on what that string is defined as, the process lots of initialization data. These routines are defined here:

FV3/atmos_cubed_sphere/tools/external_ic.F90 FV3/atmos_cubed_sphere/model/fv_regional_bc.F90

For example, see here in external_ic.F90:

if (trim(source) /= 'FV3GFS GAUSSIAN NEMSIO FILE') then if ( Atm%flagstruct%nwat .eq. 6 ) then do k=1,npz do i=is,ie qn1(i,k) = Atm%q(i,j,k,liq_wat) Atm%q(i,j,k,rainwat) = 0. Atm%q(i,j,k,snowwat) = 0. Atm%q(i,j,k,graupel) = 0.

If the string is NOT defined as specifically "FV3GFS GAUSSIAN NEMSIO FILE",then rain , snow, and graupel are zeroed out.

There are many other examples of these routines that are based on this string value, such as "computing true temperature using hydrostatic balance", "separating cloud water and cloud ice", and "mapping omega".

• Jeff

On Wed, Jun 10, 2020 at 3:02 PM Jun Wang notifications@github.com wrote:

I see. Maybe I missed something, I thought that code adjusts the hydrometeors, I did not see the code sets the hydrometeors zerors. I am wondering if you have "GRIB2 FILE", does the file actually have all the hydrometeors for Thompson MP? I am not sure how chgre_cube creates the hydrometeors from GRIB2 file, I thought most of the hydrometeors were zeros in those files.

On Wed, Jun 10, 2020 at 4:21 PM JeffBeck-NOAA notifications@github.com wrote:

Hi Jun,

This is actually a problem in the FV3 code. FV3 uses the value of this string in gfs_data.nc to decide how to initialize certain fields, instead of reading in the fields directly as they were produced by chgres_cube. If the string isn't specifically defined as "FV3GFS GAUSSIAN NEMSIO FILE", the FV3 code will modify various input variables without the user ever knowing. For example, since not all files are "FV3GFS GAUSSIAN NEMSIO", when we set this string to "GRIB2 FILE", one result is that FV3 does not initialize hydrometeors from Thompson MP included in the gfs_data.nc file correctly, it zeroes them out instead. The value of this string should not determine modifications to initialized fields. I would argue that all options to handle and modify ICs should be done within chgres_cube, not the model code itself. Hopefully this make sense? Thanks!

• Jeff

Tagging @LarissaReames-NOAA https://github.com/LarissaReames-NOAA @gsketefian https://github.com/gsketefian @jwolff-ncar https://github.com/jwolff-ncar

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/ufs-community/ufs-weather-model/issues/97#issuecomment-642236117

, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AI7D6TN3AOU66J2SASEY5UTRV7TKJANCNFSM4L3B4XHQ

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/ufs-community/ufs-weather-model/issues/97#issuecomment-642258537 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/ANFE563USLALRKIA56TA36DRV7YG5ANCNFSM4L3B4XHQ

.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ufs-community/ufs-weather-model/issues/97#issuecomment-642290366, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKY5N2NH4LLN2ISGODN4I2LRV77DFANCNFSM4L3B4XHQ .

-- Fanglin Yang, Ph.D. Physical Scientist Environmental Modeling Center National Centers for Environmental Prediction 301-6833722; fanglin.yang@noaa.gov http://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/ http://www.emc.ncep.noaa.gov/gmb/STATS_vsdb/

[JeffBeck-NOAA]

Hi Fanglin,

Thanks for the information. I believe a lot of these adjustments were implemented at a time when chgres_cube was not being used, correct? Now that we've implemented that pre-processing utility, and we have many different external model data sets that are being used to initialize ICs, it would seem that these checks/adjustments should be migrated from the FV3 code, into chgres_cube, if necessary.

Could you describe and point me to the topography adjustment portion of the code? I wasn't aware that was occurring.

Thanks!

• Jeff

[junwang-noaa]

@JeffBeck-NOAA May I ask if this is still an issue?

[JeffBeck-NOAA]

Hi Jun,

Yes, this is still a problem. If the chgres_cube output netcdf file does not include the metadata label "FV3GFS GAUSSIAN NEMSIO FILE", hydrometeor fields are zeroed out at initialization time in FV3.

At one point, Larissa and I had to make the following change to write_data.F90 in chgres_cube to avoid this problem:

elseif (trim(input_type) == "grib2") then error = nf90_put_att(ncid, nf90_global, 'source', 'FV3GFS GAUSSIAN NEMSIO FILE')

However, I now see that it was reset to:

elseif (trim(input_type) == "grib2") then error = nf90_put_att(ncid, nf90_global, 'source', 'FV3GFS GRIB2 FILE

George, this will work for global grib2 data, but for regional grib2 data, this causes the inherited hydrometeor tracers from the external model to be zeroed out. Please see my attached screen captures of reflectivity at the "zero" hour (5 minutes into the run), and at 1-, and 2-hr forecasts. The hydrometeors are not retained, and the model is forced to spin up the precipitation.

The only way to avoid this problem until the model code is changed is to assign chgres_cube netcdf output with the incorrect metadata string when source data come from grib2 files.

• Jeff

On Thu, Oct 22, 2020 at 9:08 AM Jun Wang notifications@github.com wrote:

@JeffBeck-NOAA https://github.com/JeffBeck-NOAA May I ask if this is still an issue?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ufs-community/ufs-weather-model/issues/97#issuecomment-714560025, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANFE563FJD3YNCW74IA4SZ3SMBDFFANCNFSM4L3B4XHQ .

[GeorgeGayno-NOAA]

If I understand correctly, those fields will also be zeroed out if GFS v16 netcdf files (or any tiled history or warm restart files) are used. Can't the model check the coldstart files for the existence of the icewat, rainwat, snowat and graupel records. And if they exist, use them? If they don't exist, then initialize them with zeroes.

[JeffBeck-NOAA]

Can't the model check the coldstart files for the existence of the icewat, rainwat, snowat and graupel records. And if they exist, use them? If they don't exist, then initialize them with zeroes.

@GeorgeGayno-NOAA, that would be ideal!  @junwang-noaa, is it possible to make this change?

• Jeff

[JeffBeck-NOAA]

For the SRW App release, unless this model change can be implemented quickly, we will unfortunately need to have a fix in chgres_cube (such as setting the wrong metadata string) to get things to work correctly.

[GeorgeGayno-NOAA]

For the SRW App release, unless this model change can be implemented quickly, we will unfortunately need to have a fix in chgres_cube (such as setting the wrong metadata string) to get things to work correctly.

If you need to set the set the chgres_cube string incorrectly, I would do it in the release branch only and not develop.

[JeffBeck-NOAA]

@GeorgeGayno-NOAA, yes, that would work.

[junwang-noaa]

@JeffBeck-NOAA Is the issue resolved?

[JeffBeck-NOAA]

@junwang-noaa, unfortunately, no. We had to hard-wire the chgres_cube release branch for the SRW App to use "FV3GFS GAUSSIAN NEMSIO FILE" for all file types so that FV3 would read in all tracers specified in the chgres_cube output. It will currently ignore tracers if that's not the case. Therefore, the model code still requires changes to fix this problem. @JacobCarley-NOAA, @JamesAbeles-NOAA @LarissaReames-NOAA, @GeorgeGayno-NOAA, @jwolff-ncar, @gsketefian

[junwang-noaa]

Thank you for the clarification. Do you have code changes that can fix the issue?

On Fri, Mar 12, 2021 at 3:19 PM JeffBeck-NOAA @.***> wrote:

@junwang-noaa https://github.com/junwang-noaa, unfortunately, no. We had to hard-wire the chgres_cube release branch to use "FV3GFS GAUSSIAN NEMSIO FILE" for all file types so that FV3 would read in all tracers specified in the chgres_cube output. It will currently ignore tracers if that's not the case. Therefore, the model code still requires changes to fix this problem. @JacobCarley-NOAA https://github.com/JacobCarley-NOAA, @JamesAbeles-NOAA https://github.com/JamesAbeles-NOAA @LarissaReames-NOAA https://github.com/LarissaReames-NOAA, @jwolff-ncar https://github.com/jwolff-ncar, @gsketefian https://github.com/gsketefian

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ufs-community/ufs-weather-model/issues/97#issuecomment-797732162, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI7D6TJJT5WTL3GEOVMESQTTDJSNJANCNFSM4L3B4XHQ .

[junwang-noaa]

@JeffBeck-NOAA Please see the dycore PR#96, would that resolve the issue here? Thanks

[arunchawla-NOAA]

@JeffBeck-NOAA circling back to what @junwang-noaa asked above on Apr 15. Is this issue solved with the dycore PR?

[JeffBeck-NOAA]

@junwang-noaa and @arunchawla-NOAA, this fixes the issue for now. However, note issue #539 in UFS_UTILS, created in response to the goal of migrating all modifications based on this source string to UFS_UTILS. Ideally, all assumptions (and related modifications) about how initial conditions should be applied to FV3 should be handled by chgres_cube.

[JeffBeck-NOAA]

@junwang-noaa and @arunchawla-NOAA, as @LarissaReames-NOAA mentioned in issue #539, work to migrate these modifications to UFS_UTILS will require coordination on changes to the ufs-weather-model source code.

[junwang-noaa]

@JeffBeck-NOAA Since the dycore PR#96 fixed the issue for now. Can we close this issue and open and a new one when the modifications to UFS_UTILS are ready? Thanks.

[JeffBeck-NOAA]

@junwang-noaa, Yes! Thanks. Here is the related issue in UFS_UTILS. Closing this one.