[Met_help] [rt.rap.ucar.edu #89010] History for stat_analysis: use of fcst_valid_beg, fcst_valid_end, fcst_valid_end

[John Halley Gotway via RT]

----------------------------------------------------------------
  Initial Request
----------------------------------------------------------------

Hello,

I'm using stat_analysis to do some filtering and looking at the Users'
Guide it looks like fcst_valid_beg and fcst_valid_end can be set as
YYYYMMDD with _HHMMSS as optional, so I have set in my config file
fcst_valid_beg = "20180601";
fcst_valid_end = "20180601";
fcst_valid_hour = [ "180000" ];
When I run stat_analysis, I see

DEBUG 2: Processing Job 1: -job filter -fcst_valid_beg 20180601_000000
-fcst_valid_end 20180601_000000 -fcst_valid_hour 180000

and get no stat lines retained. It looks like due to some hour minute
second information being appended to the date I provided (though I didn't
set it in this format in my config).

Now if I set my config to
fcst_valid_beg = "20180601_180000";
fcst_valid_end = "20180601_180000";
fcst_valid_hour = [ "180000" ];

and run I see
DEBUG 2: Processing Job 1: -job filter -model gfs -fcst_valid_beg
20180601_180000 -fcst_valid_end 20180601_180000 -fcst_valid_hour 180000

and I get stat lines retained.

So my question is are these config options not meant to be used in this way
together? It seems if it is okay to define fcst_valid_beg and
fcst_valid_end in YYYYMMDD that defining the hour information in
fcst_valid_hour would be okay (though I know it can be defined in
fcst_valid_beg(end)). I guess I am wondering if fcst_valid_hour is not
meant to be used if fcst_valid_beg and fcst_valid_end are defined.

Thanks!

Mallory


----------------------------------------------------------------
  Complete Ticket History
----------------------------------------------------------------

Subject: stat_analysis: use of fcst_valid_beg, fcst_valid_end, fcst_valid_end
From: John Halley Gotway
Time: Tue Feb 19 15:23:59 2019

Mallory,

Yes, the fcst_valid_beg/fcst_valid_end and fcst_valid_hour filtering
settings are *not* meant to be combined.  They are applied totally
independently.

fcst_valid_beg = DATE/TIME means... only keep lines whose valid time
is >=
this
fcst_valid_end = DATE/TIME means... only keep lines whose valid time
is <=
this
fcst_valid_hour = list of TIMES means... take the forecast valid time
and
throw away the date.  Only keep lines whose time falls in this list of
times.

Here's how you might use them together:
-fcst_valid_beg 20190101 -fcst_valid_end 20190131_235959
-fcst_valid_hour 00

The above settings specify that we only want data for the month of
January
and only data valid at 00Z during that month.

Make sense?

Thanks,
John

On Tue, Feb 19, 2019 at 1:37 PM Mallory Row - NOAA Affiliate via RT <
met_help at ucar.edu> wrote:

>
> Tue Feb 19 13:30:41 2019: Request 89010 was acted upon.
> Transaction: Ticket created by mallory.row at noaa.gov
>        Queue: met_help
>      Subject: stat_analysis: use of fcst_valid_beg, fcst_valid_end,
> fcst_valid_end
>        Owner: Nobody
>   Requestors: mallory.row at noaa.gov
>       Status: new
>  Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=89010 >
>
>
> Hello,
>
> I'm using stat_analysis to do some filtering and looking at the
Users'
> Guide it looks like fcst_valid_beg and fcst_valid_end can be set as
> YYYYMMDD with _HHMMSS as optional, so I have set in my config file
> fcst_valid_beg = "20180601";
> fcst_valid_end = "20180601";
> fcst_valid_hour = [ "180000" ];
> When I run stat_analysis, I see
>
> DEBUG 2: Processing Job 1: -job filter -fcst_valid_beg
20180601_000000
> -fcst_valid_end 20180601_000000 -fcst_valid_hour 180000
>
> and get no stat lines retained. It looks like due to some hour
minute
> second information being appended to the date I provided (though I
didn't
> set it in this format in my config).
>
> Now if I set my config to
> fcst_valid_beg = "20180601_180000";
> fcst_valid_end = "20180601_180000";
> fcst_valid_hour = [ "180000" ];
>
> and run I see
> DEBUG 2: Processing Job 1: -job filter -model gfs -fcst_valid_beg
> 20180601_180000 -fcst_valid_end 20180601_180000 -fcst_valid_hour
180000
>
> and I get stat lines retained.
>
> So my question is are these config options not meant to be used in
this way
> together? It seems if it is okay to define fcst_valid_beg and
> fcst_valid_end in YYYYMMDD that defining the hour information in
> fcst_valid_hour would be okay (though I know it can be defined in
> fcst_valid_beg(end)). I guess I am wondering if fcst_valid_hour is
not
> meant to be used if fcst_valid_beg and fcst_valid_end are defined.
>
> Thanks!
>
> Mallory
>
>

------------------------------------------------
Subject: stat_analysis: use of fcst_valid_beg, fcst_valid_end, fcst_valid_end
From: Mallory Row - NOAA Affiliate
Time: Wed Feb 20 06:17:20 2019

Makes sense, thank you!

Mallory

On Tue, Feb 19, 2019 at 5:24 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:

> Mallory,
>
> Yes, the fcst_valid_beg/fcst_valid_end and fcst_valid_hour filtering
> settings are *not* meant to be combined.  They are applied totally
> independently.
>
> fcst_valid_beg = DATE/TIME means... only keep lines whose valid time
is >=
> this
> fcst_valid_end = DATE/TIME means... only keep lines whose valid time
is <=
> this
> fcst_valid_hour = list of TIMES means... take the forecast valid
time and
> throw away the date.  Only keep lines whose time falls in this list
of
> times.
>
> Here's how you might use them together:
> -fcst_valid_beg 20190101 -fcst_valid_end 20190131_235959
-fcst_valid_hour
> 00
>
> The above settings specify that we only want data for the month of
January
> and only data valid at 00Z during that month.
>
> Make sense?
>
> Thanks,
> John
>
> On Tue, Feb 19, 2019 at 1:37 PM Mallory Row - NOAA Affiliate via RT
<
> met_help at ucar.edu> wrote:
>
> >
> > Tue Feb 19 13:30:41 2019: Request 89010 was acted upon.
> > Transaction: Ticket created by mallory.row at noaa.gov
> >        Queue: met_help
> >      Subject: stat_analysis: use of fcst_valid_beg,
fcst_valid_end,
> > fcst_valid_end
> >        Owner: Nobody
> >   Requestors: mallory.row at noaa.gov
> >       Status: new
> >  Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=89010 >
> >
> >
> > Hello,
> >
> > I'm using stat_analysis to do some filtering and looking at the
Users'
> > Guide it looks like fcst_valid_beg and fcst_valid_end can be set
as
> > YYYYMMDD with _HHMMSS as optional, so I have set in my config file
> > fcst_valid_beg = "20180601";
> > fcst_valid_end = "20180601";
> > fcst_valid_hour = [ "180000" ];
> > When I run stat_analysis, I see
> >
> > DEBUG 2: Processing Job 1: -job filter -fcst_valid_beg
20180601_000000
> > -fcst_valid_end 20180601_000000 -fcst_valid_hour 180000
> >
> > and get no stat lines retained. It looks like due to some hour
minute
> > second information being appended to the date I provided (though I
didn't
> > set it in this format in my config).
> >
> > Now if I set my config to
> > fcst_valid_beg = "20180601_180000";
> > fcst_valid_end = "20180601_180000";
> > fcst_valid_hour = [ "180000" ];
> >
> > and run I see
> > DEBUG 2: Processing Job 1: -job filter -model gfs -fcst_valid_beg
> > 20180601_180000 -fcst_valid_end 20180601_180000 -fcst_valid_hour
180000
> >
> > and I get stat lines retained.
> >
> > So my question is are these config options not meant to be used in
this
> way
> > together? It seems if it is okay to define fcst_valid_beg and
> > fcst_valid_end in YYYYMMDD that defining the hour information in
> > fcst_valid_hour would be okay (though I know it can be defined in
> > fcst_valid_beg(end)). I guess I am wondering if fcst_valid_hour is
not
> > meant to be used if fcst_valid_beg and fcst_valid_end are defined.
> >
> > Thanks!
> >
> > Mallory
> >
> >
>
>

------------------------------------------------