What should valid_beg and valid_end be for accums in grid_stat output

[mpm-meto]

I have grid_stat output which has the fcst_valid_beg = fcst_valid_end, which are in turn equal to obs_valid_beg and obs_valid_end. In this instance the fcst_valid_end and obs_valid_end values are what I would expect, and the filename is right (I think) but for a 24h accumulation I am not expecting the fcst_valid_beg and obs_valid_beg to be the same as the valid_end. If they should not be the same what element of the forecast netcdf is incorrectly set (and not extracted correctly)?
regridded_u-cg721_20190830T1200Z_036.nc.gz
files.gz created using tar cvzf. Obs file attached to discussion item #1094
grid_stat_360000L_20190901_000000V_nbrcnt.txt

[JohnHalleyGotway]

@mpm-meto I see how this can be confusing. You are wondering how to make sense of the values of the FCST_VALID_BEG, FCST_VALID_END, OBS_VALID_BEG, and OBS_VALID_END columns in the output created by Grid-Stat.

In the sample grid_stat_360000L_20190901_000000V_nbrcnt.txt file you sent, they are all set to the same value of "20190901_000000". This makes sense to me and is exactly what I'd expect, but I understand how this behavior is confusing for a variable like precipitation, which is accumulated through time.

Let's step back and ask the question, why are there 4 different columns to indicate the valid time? Many of the MET tools write to a common ascii file format which we call the ".stat" file format. These include grid_stat, point_stat, wavelet_stat, ensemble_stat, and stat_analysis. The output of these tools is stored in different line types, but the first 24 header columns (from VERSION to LINE_TYPE) are common to all line types. And the 4 valid time columns are included in those 24 header columns.

When grid_stat is run, it identifies a single valid time for the gridded forecast field and a single valid time for the gridded observation field. USUALLY those are exactly the same date/time, but they don't need to be. If they differ, grid_stat prints are warning message but then proceeds to process the data and write output. But in the grid_stat output, it is ALWAYS the case that FCST_VALID_BEG = FCST_VALID_END and OBS_VALID_BEG = OBS_VALID_END. And it is usually the case that all 4 are the same.

Here are the lines in the source code where the forecast valid times are set and the obs valid times are set to the same values. Even when processing accumulating variables, like precip, a single valid time is chosen... and is defined to be the END of the accumulation window.

So why are there separate columns for begin and end valid times? These are populated by point_stat and ensemble_stat when processing point observations. Let's say you run point_stat and define a matching time window (i.e. obs_window in the point_stat config file) as +/- 30 minutes and compute CNT statistics, in the output you'll see:
FCST_VALID_BEG = FCST_VALID_END = t
OBS_VALID_BEG = t - 30 minutes
OBS_VALID_END = t + 30 minutes

This is also used when aggregating data across multiple runs using the stat_analysis tool. Let's say you run stat_analysis to aggregate SL1L2 partial sums over 1 month of data. In the output you'll see:
FCST_VALID_BEG = minimum of all FCST_VALID_BEG values read
FCST_VALID_END = maximum of all FCST_VALID_END values read
OBS_VALID_BEG = minimum of all OBS_VALID_BEG values read
OBS_VALID_END = maximum of all OBS_VALID_END values read

So this is largely a result of having multiple tools which process different types of data write to the same output file format. One advantage is consistency, and one disadvantage is writing the same date strings multiple times.