Total precipitation in 6 hour window or accumulated at each time step

[junwang-noaa]

gabrielcassol09@gmail.com noticed a problem with the accumulated precipitation variable in some GraphCast runs:

APCPsfc 0.1.0 0.1.8.1 ** surface Total Precipitation [kg/m^2]

Instead of accumulating rain at each time step, in some rounds this variable "APCPsfc" is showing rain in the 6-hour window. Not all rounds, for example, in rounds 00 and 12 UTC yesterday (June 14th) everything was fine. But in round 00 UTC today, June 15th, it came with this problem. I'm attaching an example of yesterday's and today's round so you can see the difference and better understand what I'm talking about.

APCPsfc GIF referring to round 12 UTC on June 14th (Correct round) https://drive.google.com/file/d/1iGPBX8N7MNGad2Vkf1Cp4A3I8-SPEdX-/view?usp=sharing

APCPsfc GIF referring to the 00 UTC round on June 15th (Faulty round) https://drive.google.com/file/d/1l3SBdXyrkmS3WQ4lcqWriWkSL8fRGqAZ/view?usp=sharing

What I have observed over the course of these days is that this bug does not have a certain logic of occurrence, sometimes it occurs in round 00, sometimes it occurs in round 12. I don't follow rounds 06 and 18 so I couldn't tell you if this problem also occurs in some of them.

[junwang-noaa]

To be consistent with operational GFS forecast, graphcastGFS outputs two APCP variables in the output fields. One is "bucket" total precip in a 6 hourly window. The other is "continuous" total precip accumulated from initial time.

For forecast at 12 UTC on June 14th 6 hourly "bucket" total precip:

15:45425506:vt=2024061500:surface:6-12 hour acc fcst:APCP Total Precipitation [kg/m^2]:
    ndata=1038240:undef=0:mean=0.529249:min=-0.986978:max=31.3817
    grid_template=0:winds(N/S):
        lat-lon grid:(1440 x 721) units 1e-06 input WE:NS output WE:SN res 48
        lat 90.000000 to -90.000000 by 0.250000
        lon 0.000000 to 359.750000 by 0.250000 #points=1038240

"continuous" total precip:

29:90851036:vt=2024061500:surface:0-12 hour acc fcst:APCP Total Precipitation [kg/m^2]:
    ndata=1038240:undef=0:mean=1.08629:min=-1.68495:max=119.469
    grid_template=0:winds(N/S):
        lat-lon grid:(1440 x 721) units 1e-06 input WE:NS output WE:SN res 48
        lat 90.000000 to -90.000000 by 0.250000
        lon 0.000000 to 359.750000 by 0.250000 #points=1038240

We are checking the forecast output to make sure that forecasts from 2024061500 have the correct outputs.

[junwang-noaa]

On forecasts on 00 UTC round on June 15th:

6 hourly "bucket" total precip:

71:227127554:vt=2024061512:surface:6-12 hour acc fcst:APCP Total Precipitation [kg/m^2]:
    ndata=1038240:undef=0:mean=0.551499:min=-0.408967:max=34.1805
    grid_template=0:winds(N/S):
        lat-lon grid:(1440 x 721) units 1e-06 input WE:NS output WE:SN res 48
        lat 90.000000 to -90.000000 by 0.250000
        lon 0.000000 to 359.750000 by 0.250000 #points=1038240

"continuous" total precip:

70:223882851:vt=2024061512:surface:0-12 hour acc fcst:APCP Total Precipitation [kg/m^2]:
    ndata=1038240:undef=0:mean=1.10671:min=-1.80664:max=81.138
    grid_template=0:winds(N/S):
        lat-lon grid:(1440 x 721) units 1e-06 input WE:NS output WE:SN res 48
        lat 90.000000 to -90.000000 by 0.250000
        lon 0.000000 to 359.750000 by 0.250000 #points=1038240

So at the 2024061500 cycle, the two APCP variables are present, but they are in different order. Please use the forecast time "6-12 hour acc fcst" or "0-12 hour acc fcst" to get the desired variable.

[gabrielcassol]

Jung,

There really are two variables within the index file, but the problem is that they have the same name, and when g2ctl is used to generate the control file to read in GrADS, one is replaced by the other, always keeping the last APCP variable as you can see it in the images I attached. As their order is variable, in some rounds I get the total accumulated rain and in other rounds I get the accumulated rain in 6 hours.

Would any of these solutions be possible?

• Keep the position of the total accumulated APCP variable fixed always after the APCP variable 6 hours?
• Give another name for the 6-hour APCP variable so that this conflict does not occur with the total accumulated APCP?

Index file of the example round 12 UTC on June 14th

Index file of the example round 00 UTC on June 15th

[junwang-noaa]

@gabrielcassol So the issue is in g2ctl. We will look into the code to have continuous APCP come after the bucket APCP. Meanwhile, you can extract continuous APCP from the grib2 file and use g2ctl to make the plot.

[gabrielcassol]

@junwang-noaa how can I do what you said about extracting the continuous APCP from grib2 so that it appears in the control file when using g2ctl?

[junwang-noaa]

Below is the reply from Wesley.Ebisuzaki, the author of g2ctl:

$ alt_g2ctl -0t gfs.t00z.pgrb2.0p25.f258 >$ptmp/junk.ctl
$ alt_gmp $ptmp/junk.ctl

https://www.cpc.ncep.noaa.gov/products/wesley/alt_g2ctl_gmp.html

Note the ctl file produced by alt_g2ctl  is not compatible with 
gribmap.  You need alt_gmp.  Both alt_g2ctl and alt_gmp
are perl scripts that require  the same version of wgrib2 to be installed.

When using alt_g2ctl, I got the following in the grads ctl file, both APCP fields (APCP012houraccfcstsfc and APCP612houraccfcstsfc) are shown up. I think this is a cleaner solution.

dset ^graphcastgfs.t00z.pgrb2.0p25.f012
index ^graphcastgfs.t00z.pgrb2.0p25.f012.idx
undef 9.999E+20
title graphcastgfs.t00z.pgrb2.0p25.f012
* produced by alt_g2ctl v1.0.8, use alt_gmp to make idx file
* command line options: -0t graphcastgfs.t00z.pgrb2.0p25.f012
* alt_gmp options: update=0
* alt_gmp options: nthreads=4
* alt_gmp options: big=0
* alt_gmp options: match=
* wgrib2 inventory flags: -npts -set_ext_name 1 -T -ext_name -ftime -lev
* wgrib2 inv suffix: .invd02
* griddef=1:0:(1440 x 721):grid_template=0:winds(N/S): lat-lon grid:(1440 x 721) units 1e-06 input WE:NS output WE:SN res 48 lat 90.000000 to -90.000000 by 0.250000 lon 0.000000 to 359.750000 by 0.250000 #points=1038240:winds(N/S)

dtype grib2
ydef 721 linear -90.000000 0.25
xdef 1440 linear 0.000000 0.250000
tdef 1 linear 00Z15jun2024 1mo
zdef 13 levels 1000 925 850 700 600 500 400 300 250 200 150 100 50
vars 12
APCP012houraccfcstsfc 0 0 "APCP:0-12 hour acc fcst:surface" * APCP:0-12 hour acc fcst:surface
APCP612houraccfcstsfc 0 0 "APCP:6-12 hour acc fcst:surface" * APCP:6-12 hour acc fcst:surface
HGT12hourfcstprs 13 0 "HGT:12 hour fcst:%s mb" * profile HGT:12 hour fcst:%s mb
PRMSL12hourfcstmsl 0 0 "PRMSL:12 hour fcst:mean sea level" * PRMSL:12 hour fcst:mean sea level
SPFH12hourfcstprs 13 0 "SPFH:12 hour fcst:%s mb" * profile SPFH:12 hour fcst:%s mb
TMP12hourfcst2m 0 0 "TMP:12 hour fcst:2 m above ground" * TMP:12 hour fcst:2 m above ground
TMP12hourfcstprs 13 0 "TMP:12 hour fcst:%s mb" * profile TMP:12 hour fcst:%s mb
UGRD12hourfcst10m 0 0 "UGRD:12 hour fcst:10 m above ground" * UGRD:12 hour fcst:10 m above ground
UGRD12hourfcstprs 13 0 "UGRD:12 hour fcst:%s mb" * profile UGRD:12 hour fcst:%s mb
VGRD12hourfcst10m 0 0 "VGRD:12 hour fcst:10 m above ground" * VGRD:12 hour fcst:10 m above ground
VGRD12hourfcstprs 13 0 "VGRD:12 hour fcst:%s mb" * profile VGRD:12 hour fcst:%s mb
VVEL12hourfcstprs 13 0 "VVEL:12 hour fcst:%s mb" * profile VVEL:12 hour fcst:%s mb
endvars

[junwang-noaa]

@junwang-noaa how can I do what you said about extracting the continuous APCP from grib2 so that it appears in the control file when using g2ctl?

@gabrielcassol you can use wgrib2 to extract the continuous APCP from grib2:

 wgrib2 graphcastgfs.t12z.pgrb2.0p25.f012  -match APCP -not ":surface:[1-9]" -grib Your_Continuous_APCP_grib2file_name

[junwang-noaa]

@gabrielcassol Please see the suggestion above. Also back to your suggestion: "Give another name for the 6-hour APCP variable so that this conflict does not occur with the total accumulated APCP", as we are producing data consistent from the operational GFS, we have to use standard meteorological field names defined by WMO, it is not appropriate for us to use non-standard names in those products .