Fix zero out accumulated total precip

[junwang-noaa]

Description

This PR is to resolve the issue with #976. The average total precipitation fields (accumulated from cycle starting time) are not correct in GFSv17 retro run.

The following code changes in production/GFS.16 were lost in the current fv3atm ccpp driver code: https://github.com/NOAA-EMC/fv3atm/blob/production/GFS.v16/gfsphysics/GFS_layer/GFS_driver.F90#L643-L649

  if (Model%iau_offset > 0) then
      kdt_iau = nint(Model%iau_offset*con_hr/Model%dtp)
      if (Model%kdt == kdt_iau+1) then
        iauwindow_center = .true.
        do nb = 1,nblks
          call Diag(nb)%rad_zero  (Model)
          call Diag(nb)%phys_zero (Model,iauwindow_center=iauwindow_center)

ccpp_driver.F90 is updated with the code.

Issue(s) addressed

Link the issues to be closed with this PR, whether in this repository or in another repository.
(Remember, issues should always be created before starting work on a PR branch!)

• fixes How is time averaged precipitation calculated? #976
• fixes Prate_ave in atmospheric sfc history files accumulates while cycling GFS#1

Testing

How were these changes tested?
The code has been tested on hera with cpld_control_gfsv17 and cpld_control_gfsv17_iau tests. There is no change in cpld_control_gfsv17 and the changes in sfc, pgrb and restart/phys files are what we expected. The rt log files are under:

/scratch1/NCEPDEV/nems/Jun.Wang/nems/vlab/20250523/totprep/ufs-weather-model/tests/logs/log_hera:
rt_cpld_control_gfsv17_intel.log
rt_cpld_control_gfsv17_iau_intel.log

For cpld_control_gfsv17_iau, the pgrb24 file shows field differences, with no impact on bucket precip related fields:

6874c6874
860:51710820:vt=2021032312:surface:0-1 day acc fcst:APCP Total Precipitation [kg/m^2]:
<     ndata=72960:undef=0:mean=2.20412:min=0:max=85.125
---
>     ndata=72960:undef=0:mean=2.74013:min=0:max=96.1875

< 862:51782808:vt=2021032312:surface:0-1 day acc fcst:ACPCP Convective Precipitation [kg/m^2]:
<     ndata=72960:undef=0:mean=1.19379:min=0:max=44.5625
---
> 862:51784880:vt=2021032312:surface:0-1 day acc fcst:ACPCP Convective Precipitation [kg/m^2]:
>     ndata=72960:undef=0:mean=1.48688:min=0:max=51.75
< 864:51839342:vt=2021032312:surface:0-1 day acc fcst:NCPCP Large-Scale Precipitation (non-convective) [kg/m^2]:
<     ndata=72960:undef=0:mean=1.00914:min=0:max=69.8125
---
> 864:51843137:vt=2021032312:surface:0-1 day acc fcst:NCPCP Large-Scale Precipitation (non-convective) [kg/m^2]:
>     ndata=72960:undef=0:mean=1.25191:min=0:max=87.5625
6913,6914c6913,6914
< 865:51870935:vt=2021032312:surface:0-1 day acc fcst:FROZR Frozen Rain [kg/m^2]:
<     ndata=72960:undef=0:mean=0.00337536:min=0:max=1.4826
---
> 865:51877684:vt=2021032312:surface:0-1 day acc fcst:FROZR Frozen Rain [kg/m^2]:
>     ndata=72960:undef=0:mean=0.00663582:min=0:max=1.95496
6921,6922c6921,6922
< 866:51892809:vt=2021032312:surface:0-1 day acc fcst:FRZR Freezing Rain [kg/m^2]:
<     ndata=72960:undef=0:mean=0.00102056:min=0:max=1.255
---
> 866:51907601:vt=2021032312:surface:0-1 day acc fcst:FRZR Freezing Rain [kg/m^2]:
>     ndata=72960:undef=0:mean=0.00111388:min=0:max=1.255
6929,6930c6929,6930
< 867:51898053:vt=2021032312:surface:0-1 day acc fcst:TSNOWP Total Snow Precipitation [kg/m^2]:
<     ndata=72960:undef=0:mean=0.3984:min=0:max=62.87
---
> 867:51913552:vt=2021032312:surface:0-1 day acc fcst:TSNOWP Total Snow Precipitation [kg/m^2]:
>     ndata=72960:undef=0:mean=0.492066:min=0:max=75.91

Dependencies

If testing this branch requires non-default branches in other repositories, list them.
Those branches should have matching names (ideally)

Do PRs in upstream repositories need to be merged first?
If so add the "waiting for other repos" label and list the upstream PRs

• waiting on noaa-emc/nems/pull/<pr_number>
• waiting on noaa-emc/fv3atm/pull/<pr_number>

[RuiyuSun]

Thanks @junwang-noaa for providing a solution! This is related to the NOAA-EMC/GFS#1. @ClaraDraper-NOAA first found this precipitation accumulation issue. This fix is being tested in a test retro.

[junwang-noaa]

@RuiyuSun The first output time for the IAU will now be the first time step at current cycle time. Please check if the total precip and bucket precip are now consistent. Thanks.

[RuiyuSun]

@RuiyuSun The first output time for the IAU will now be the first time step at current cycle time. Please check if the total precip and bucket precip are now consistent. Thanks.

@junwang-noaa Great! I will test this.

[RuiyuSun]

This PR worked in the most recent retro test. The total accumulated precipitation rate is zeroed out during the first timestep and its value is the same as its corresponding bucket value in the sfcf files up to 6 hours.

The RUNDIR of the test is at /lfs/h2/emc/physics/noscrub/ruiyu.sun/gfsv17_retro.logfiles/fcst.2420737. The gdas_fcst_seg0.log also in the dir.

In the test, output_fh: 0.0417 1 2 3 4 5 6 7 8 9 (hard coded in model_configure). 0.0417=150/3600. This requests the model writes history file after zeroing out the total precipitation and other accumulated fields in the first timestep and ensures the accumulated precipitation rate (and other accumulated fields) and the bucket precipitation rate are the same at the 00Z forecast.

One concern of this test setting is whether the initial value of total precipitation rate before zeroing out is used by any components in DA.

An issue is this setting messed up the filename consistency between the model and workflow. For example, the 00Z files from the model: sfcf000-02-30.nc, atmf000-02-30.nc, GFSPRS.GrbF00 and GFSFLX.GrbF00 are not linked to their workflow names.

atmf0.0.nc -> /lfs/h2/emc/stmp/ruiyu.sun/retro10p/gdas.20241115/06//model/atmos/histo
ry/gdas.t06z.atmf0.0.nc
sfcf0.0.nc -> /lfs/h2/emc/stmp/ruiyu.sun/retro10p/gdas.20241115/06//model/atmos/histo
ry/gdas.t06z.sfcf0.0.nc
GFSFLX.GrbF0.0 -> /lfs/h2/emc/stmp/ruiyu.sun/retro10p/gdas.20241115/06//model/atmos/m
aster/gdas.t06z.sfluxgrbf0.0.grib2
GFSPRS.GrbF0.0 -> /lfs/h2/emc/stmp/ruiyu.sun/retro10p/gdas.20241115/06//model/atmos/m
aster/gdas.t06z.master.grb2f0.0

[RuiyuSun]

The file name changes in the previous comments are due to the changes made to the forecast_postdet.sh.

ruiyu.sun@dlogin04:/lfs/h2/emc/physics/noscrub/ruiyu.sun/git/gfsv17/global_workflow_gfsv17_0603_
phys_zero/ush> diff forecast_postdet.sh.org forecast_postdet.sh
261,262c261,264
< FH3=$(printf %03i "${fhr}")
< FH2=$(printf %02i "${fhr}")
vs

  #rsun FH3=$(printf %03i "${fhr}")
  #rsun FH2=$(printf %02i "${fhr}")
  FH3=$(printf %3.1f "${fhr}")
  FH2=$(printf %2.1f "${fhr}")

[RuiyuSun]

This PR worked in the most recent retro test. The total accumulated precipitation rate is zeroed out during the first timestep and its value is the same as its corresponding bucket value in the sfcf files up to 6 hours.

The RUNDIR of the test is at /lfs/h2/emc/physics/noscrub/ruiyu.sun/gfsv17_retro.logfiles/fcst.2420737. The gdas_fcst_seg0.log also in the dir.

In the test, output_fh: 0.0417 1 2 3 4 5 6 7 8 9 (hard coded in model_configure). 0.0417=150/3600. This requests the model writes history file after zeroing out the total precipitation and other accumulated fields in the first timestep and ensures the accumulated precipitation rate (and other accumulated fields) and the bucket precipitation rate are the same at the 00Z forecast.

One concern of this test setting is whether the initial value of total precipitation rate before zeroing out is used by any components in DA.

An issue is this setting messed up the filename consistency between the model and workflow. For example, the 00Z files from the model: sfcf000-02-30.nc, atmf000-02-30.nc, GFSPRS.GrbF00 and GFSFLX.GrbF00 are not linked to their workflow names.

atmf0.0.nc -> /lfs/h2/emc/stmp/ruiyu.sun/retro10p/gdas.20241115/06//model/atmos/histo ry/gdas.t06z.atmf0.0.nc sfcf0.0.nc -> /lfs/h2/emc/stmp/ruiyu.sun/retro10p/gdas.20241115/06//model/atmos/histo ry/gdas.t06z.sfcf0.0.nc GFSFLX.GrbF0.0 -> /lfs/h2/emc/stmp/ruiyu.sun/retro10p/gdas.20241115/06//model/atmos/m aster/gdas.t06z.sfluxgrbf0.0.grib2 GFSPRS.GrbF0.0 -> /lfs/h2/emc/stmp/ruiyu.sun/retro10p/gdas.20241115/06//model/atmos/m aster/gdas.t06z.master.grb2f0.0

@WenMeng-NOAA @ChristopherHill-NOAA Could you chime in about potential impact of changing the accumulated values in the sfc files from the values exact at f00 hour to those after one-time step to the UPP outputs and downstream products when IAU is used?

[WenMeng-NOAA]

This PR worked in the most recent retro test. The total accumulated precipitation rate is zeroed out during the first timestep and its value is the same as its corresponding bucket value in the sfcf files up to 6 hours.
The RUNDIR of the test is at /lfs/h2/emc/physics/noscrub/ruiyu.sun/gfsv17_retro.logfiles/fcst.2420737. The gdas_fcst_seg0.log also in the dir.
In the test, output_fh: 0.0417 1 2 3 4 5 6 7 8 9 (hard coded in model_configure). 0.0417=150/3600. This requests the model writes history file after zeroing out the total precipitation and other accumulated fields in the first timestep and ensures the accumulated precipitation rate (and other accumulated fields) and the bucket precipitation rate are the same at the 00Z forecast.
One concern of this test setting is whether the initial value of total precipitation rate before zeroing out is used by any components in DA.
An issue is this setting messed up the filename consistency between the model and workflow. For example, the 00Z files from the model: sfcf000-02-30.nc, atmf000-02-30.nc, GFSPRS.GrbF00 and GFSFLX.GrbF00 are not linked to their workflow names.
atmf0.0.nc -> /lfs/h2/emc/stmp/ruiyu.sun/retro10p/gdas.20241115/06//model/atmos/histo ry/gdas.t06z.atmf0.0.nc sfcf0.0.nc -> /lfs/h2/emc/stmp/ruiyu.sun/retro10p/gdas.20241115/06//model/atmos/histo ry/gdas.t06z.sfcf0.0.nc GFSFLX.GrbF0.0 -> /lfs/h2/emc/stmp/ruiyu.sun/retro10p/gdas.20241115/06//model/atmos/m aster/gdas.t06z.sfluxgrbf0.0.grib2 GFSPRS.GrbF0.0 -> /lfs/h2/emc/stmp/ruiyu.sun/retro10p/gdas.20241115/06//model/atmos/m aster/gdas.t06z.master.grb2f0.0

@WenMeng-NOAA @ChristopherHill-NOAA Could you chime in about potential impact of changing the accumulated values in the sfc files from the values exact at f00 hour to those after one-time step to the UPP outputs and downstream products when IAU is used?

@RuiyuSun These time-averaged variables are not outputted from UPP at F000.

[RuiyuSun]

Thanks @WenMeng-NOAA for confirming! @ChristopherHill-NOAA do you have any concern, in terms of product generation, about writing out the accumulated fields at one timestep after FH000 instead of exactly at FH000?

[ChristopherHill-NOAA]

@ChristopherHill-NOAA do you have any concern, in terms of product generation, about writing out the accumulated fields at one timestep after FH000 instead of exactly at FH000?

It is observed that none of the variables APCP, ACPCP, NCPCP, FROZR, FRZR, or TSNOWP appears in the GFSv16 product files gdas.t00z.master.grb2anl, gdas.t00z.master.grb2f000, or gfs.t00z.master.grb2f000. The changes in this PR should, therefore, not affect these files and the other F000 downstream product files.