[Met_help] [rt.rap.ucar.edu #77291] History for Valid Hour vs. Init Hour - Possible Issue
John Halley Gotway via RT
met_help at ucar.edu
Fri Aug 12 11:45:52 MDT 2016
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi,
I am using MET Viewer to look into bias (ME) and BCRMSE for the HRRR and
HRRRx, as a function of valid hour, to investigate the effects of the
diurnal cycle.
I could be wrong but I think MET is plotting initialization hour as valid
hour and valid hour as initialization hour. Compare the two surface dew
point plots, one using initialization hour as the independent variable and
the other using valid hour, with slide 29 of Geoff Manikin's MEG
presentation (attached).
The plots for initialization hour seem to match quite closely to the valid
hour plots on slide 29 (provided by GSD), especially for the operational
HRRR, whereas the plots for valid hour are phase shifted by 12 hours. I'm
definitely plotting over the correct region (East US) and I'm using all
12-hr forecasts (lead time is fixed at 12 hours) over the same time period
as GSD.
Thank you!
Ben Blake (EMC)
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Valid Hour vs. Init Hour - Possible Issue
From: John Halley Gotway
Time: Mon Jul 25 10:35:18 2016
Ben,
I see that you have a question about how METViewer is
computing/plotting
the init_hour and valid_hour variables. Thanks for sending the
images. I
understand and see the discrepancy you're describing.
I ran some tests on a small subset of data but am not able to
reproduce the
behavior you're describing. I've attached a plot and xml to show you
what
I'm seeing.
You could try the following:
(1) Save the attached xml to your local machine.
(2) Go to... http://www.dtcenter.org/met/metviewer/metviewer1.jsp
(3) Click "Load XML" in the top-right corner, navigate to attached xml
file, and click "OK".
(4) Click "Generate Plot" to make the image.
(5) Once the plot is finished, click on the "R Data" tab in the plot
window.
(6) Inspect the columns of data and note that the contents of
valid_hour
(i.e. the column just before DPT) really are consistent with the valid
times, not the init times.
So I don't see an obvious problem in METViewer at this point.
The next thing I'd check it how Geoff created the images you're
comparing
against. It's certainly possible that he either inadvertently or
intentionally plotted against init_hour instead of valid_hour.
FYI, Tatiana is in the process of updating the version of METViewer
running
at EMC. This typically only takes about 10 minutes, but for the large
databases there it's taking much longer.
Please let me know if there's anything else I can do to help you debug
this
issue.
Thanks,
John Halley Gotway
On Fri, Jul 22, 2016 at 10:48 AM, Benjamin Blake - NOAA Affiliate via
RT <
met_help at ucar.edu> wrote:
>
> Fri Jul 22 10:48:03 2016: Request 77291 was acted upon.
> Transaction: Ticket created by benjamin.blake at noaa.gov
> Queue: met_help
> Subject: Valid Hour vs. Init Hour - Possible Issue
> Owner: Nobody
> Requestors: benjamin.blake at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
>
>
> Hi,
>
> I am using MET Viewer to look into bias (ME) and BCRMSE for the HRRR
and
> HRRRx, as a function of valid hour, to investigate the effects of
the
> diurnal cycle.
>
> I could be wrong but I think MET is plotting initialization hour as
valid
> hour and valid hour as initialization hour. Compare the two surface
dew
> point plots, one using initialization hour as the independent
variable and
> the other using valid hour, with slide 29 of Geoff Manikin's MEG
> presentation (attached).
>
> The plots for initialization hour seem to match quite closely to the
valid
> hour plots on slide 29 (provided by GSD), especially for the
operational
> HRRR, whereas the plots for valid hour are phase shifted by 12
hours. I'm
> definitely plotting over the correct region (East US) and I'm using
all
> 12-hr forecasts (lead time is fixed at 12 hours) over the same time
period
> as GSD.
>
> Thank you!
> Ben Blake (EMC)
>
>
------------------------------------------------
Subject: Valid Hour vs. Init Hour - Possible Issue
From: Benjamin Blake - NOAA Affiliate
Time: Mon Jul 25 11:05:35 2016
Hi John,
I loaded the xml file you sent and I see that the valid_hour contents
are
indeed consistent with the valid times and not the init times. Thank
you
for sending that.
Once I am able to load my xml file into the EMC version of METViewer I
will
look at the R data tab and make sure it is plotting valid hour. It is
taking a while to load at the moment, which I'm guessing is likely
because
you said that Tatiana is currently updating it.
If it is correctly plotting valid hour then I will talk to Geoff and
see if
we can understand what is going on.
Thank you for your help and I'll let you know if I am unable to
resolve the
discrepancy.
Ben
On Mon, Jul 25, 2016 at 12:35 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Ben,
>
> I see that you have a question about how METViewer is
computing/plotting
> the init_hour and valid_hour variables. Thanks for sending the
images. I
> understand and see the discrepancy you're describing.
>
> I ran some tests on a small subset of data but am not able to
reproduce the
> behavior you're describing. I've attached a plot and xml to show
you what
> I'm seeing.
>
> You could try the following:
> (1) Save the attached xml to your local machine.
> (2) Go to... http://www.dtcenter.org/met/metviewer/metviewer1.jsp
> (3) Click "Load XML" in the top-right corner, navigate to attached
xml
> file, and click "OK".
> (4) Click "Generate Plot" to make the image.
> (5) Once the plot is finished, click on the "R Data" tab in the plot
> window.
> (6) Inspect the columns of data and note that the contents of
valid_hour
> (i.e. the column just before DPT) really are consistent with the
valid
> times, not the init times.
>
> So I don't see an obvious problem in METViewer at this point.
>
> The next thing I'd check it how Geoff created the images you're
comparing
> against. It's certainly possible that he either inadvertently or
> intentionally plotted against init_hour instead of valid_hour.
>
> FYI, Tatiana is in the process of updating the version of METViewer
running
> at EMC. This typically only takes about 10 minutes, but for the
large
> databases there it's taking much longer.
>
> Please let me know if there's anything else I can do to help you
debug this
> issue.
>
> Thanks,
> John Halley Gotway
>
>
> On Fri, Jul 22, 2016 at 10:48 AM, Benjamin Blake - NOAA Affiliate
via RT <
> met_help at ucar.edu> wrote:
>
> >
> > Fri Jul 22 10:48:03 2016: Request 77291 was acted upon.
> > Transaction: Ticket created by benjamin.blake at noaa.gov
> > Queue: met_help
> > Subject: Valid Hour vs. Init Hour - Possible Issue
> > Owner: Nobody
> > Requestors: benjamin.blake at noaa.gov
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
> >
> >
> > Hi,
> >
> > I am using MET Viewer to look into bias (ME) and BCRMSE for the
HRRR and
> > HRRRx, as a function of valid hour, to investigate the effects of
the
> > diurnal cycle.
> >
> > I could be wrong but I think MET is plotting initialization hour
as valid
> > hour and valid hour as initialization hour. Compare the two
surface dew
> > point plots, one using initialization hour as the independent
variable
> and
> > the other using valid hour, with slide 29 of Geoff Manikin's MEG
> > presentation (attached).
> >
> > The plots for initialization hour seem to match quite closely to
the
> valid
> > hour plots on slide 29 (provided by GSD), especially for the
operational
> > HRRR, whereas the plots for valid hour are phase shifted by 12
hours.
> I'm
> > definitely plotting over the correct region (East US) and I'm
using all
> > 12-hr forecasts (lead time is fixed at 12 hours) over the same
time
> period
> > as GSD.
> >
> > Thank you!
> > Ben Blake (EMC)
> >
> >
>
>
------------------------------------------------
Subject: Valid Hour vs. Init Hour - Possible Issue
From: Benjamin Blake - NOAA Affiliate
Time: Tue Jul 26 09:40:37 2016
Hi John,
I am still trying to figure out what the issue could be. I verified
with
the NCEP instance of METViewer that it is indeed plotting valid hour.
Geoff asked Curtis Alexander (who made the original bias plots) about
the
values on the x-axis and Curtis confirmed that they were plotting
valid
hour also. The plots I made using MET Viewer still seem to be phase
shifted by 12 hours. The largest ME should be in the late
afternoon/early
evening, so around 0z, and not in the early morning (12-15z).
Could the issue have something to do with the way MET is reading in
the
database files?
I've attached a xml file that looks at the HRRR vs. HRRRx surface
temperature ME (as a function of valid hour) for all 12-hr forecasts
for
all cycles on 7/20/16 over the eastern US. Perhaps you could load it
into
the NCEP version of METViewer and let me know if you have any idea
what
could be happening?
Thanks again for your help on this!
Ben
On Mon, Jul 25, 2016 at 1:05 PM, Benjamin Blake - NOAA Affiliate <
benjamin.blake at noaa.gov> wrote:
> Hi John,
>
> I loaded the xml file you sent and I see that the valid_hour
contents are
> indeed consistent with the valid times and not the init times.
Thank you
> for sending that.
>
> Once I am able to load my xml file into the EMC version of METViewer
I
> will look at the R data tab and make sure it is plotting valid hour.
It is
> taking a while to load at the moment, which I'm guessing is likely
because
> you said that Tatiana is currently updating it.
>
> If it is correctly plotting valid hour then I will talk to Geoff and
see
> if we can understand what is going on.
>
> Thank you for your help and I'll let you know if I am unable to
resolve
> the discrepancy.
> Ben
>
> On Mon, Jul 25, 2016 at 12:35 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Ben,
>>
>> I see that you have a question about how METViewer is
computing/plotting
>> the init_hour and valid_hour variables. Thanks for sending the
images. I
>> understand and see the discrepancy you're describing.
>>
>> I ran some tests on a small subset of data but am not able to
reproduce
>> the
>> behavior you're describing. I've attached a plot and xml to show
you what
>> I'm seeing.
>>
>> You could try the following:
>> (1) Save the attached xml to your local machine.
>> (2) Go to... http://www.dtcenter.org/met/metviewer/metviewer1.jsp
>> (3) Click "Load XML" in the top-right corner, navigate to attached
xml
>> file, and click "OK".
>> (4) Click "Generate Plot" to make the image.
>> (5) Once the plot is finished, click on the "R Data" tab in the
plot
>> window.
>> (6) Inspect the columns of data and note that the contents of
valid_hour
>> (i.e. the column just before DPT) really are consistent with the
valid
>> times, not the init times.
>>
>> So I don't see an obvious problem in METViewer at this point.
>>
>> The next thing I'd check it how Geoff created the images you're
comparing
>> against. It's certainly possible that he either inadvertently or
>> intentionally plotted against init_hour instead of valid_hour.
>>
>> FYI, Tatiana is in the process of updating the version of METViewer
>> running
>> at EMC. This typically only takes about 10 minutes, but for the
large
>> databases there it's taking much longer.
>>
>> Please let me know if there's anything else I can do to help you
debug
>> this
>> issue.
>>
>> Thanks,
>> John Halley Gotway
>>
>>
>> On Fri, Jul 22, 2016 at 10:48 AM, Benjamin Blake - NOAA Affiliate
via RT <
>> met_help at ucar.edu> wrote:
>>
>> >
>> > Fri Jul 22 10:48:03 2016: Request 77291 was acted upon.
>> > Transaction: Ticket created by benjamin.blake at noaa.gov
>> > Queue: met_help
>> > Subject: Valid Hour vs. Init Hour - Possible Issue
>> > Owner: Nobody
>> > Requestors: benjamin.blake at noaa.gov
>> > Status: new
>> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
>> >
>> >
>> > Hi,
>> >
>> > I am using MET Viewer to look into bias (ME) and BCRMSE for the
HRRR and
>> > HRRRx, as a function of valid hour, to investigate the effects of
the
>> > diurnal cycle.
>> >
>> > I could be wrong but I think MET is plotting initialization hour
as
>> valid
>> > hour and valid hour as initialization hour. Compare the two
surface dew
>> > point plots, one using initialization hour as the independent
variable
>> and
>> > the other using valid hour, with slide 29 of Geoff Manikin's MEG
>> > presentation (attached).
>> >
>> > The plots for initialization hour seem to match quite closely to
the
>> valid
>> > hour plots on slide 29 (provided by GSD), especially for the
operational
>> > HRRR, whereas the plots for valid hour are phase shifted by 12
hours.
>> I'm
>> > definitely plotting over the correct region (East US) and I'm
using all
>> > 12-hr forecasts (lead time is fixed at 12 hours) over the same
time
>> period
>> > as GSD.
>> >
>> > Thank you!
>> > Ben Blake (EMC)
>> >
>> >
>>
>>
>
------------------------------------------------
Subject: Valid Hour vs. Init Hour - Possible Issue
From: John Halley Gotway
Time: Tue Jul 26 10:39:00 2016
Ben,
My access to NCEP VPN isn't working, so I'm not able to test out that
XML
directly. However, another possibility occurred to me. METViewer can
be
loaded with data directly from MET or with VSDB files generated with
the
NCEP Vx package. Both of those pathways read data from flat files and
store them in the database.
The testing I did only covered the "MET" pathway, not the "VSDB" one.
It's
possible that when reading VSDB data, METViewer is storing init times
as
valid times or vice versa.
Do you know how the HRRR data you're plotting via METViewer was
created?
Were they VSDB files or MET output files.
Thanks,
John
On Tue, Jul 26, 2016 at 9:40 AM, Benjamin Blake - NOAA Affiliate via
RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
>
> Hi John,
>
> I am still trying to figure out what the issue could be. I verified
with
> the NCEP instance of METViewer that it is indeed plotting valid
hour.
> Geoff asked Curtis Alexander (who made the original bias plots)
about the
> values on the x-axis and Curtis confirmed that they were plotting
valid
> hour also. The plots I made using MET Viewer still seem to be phase
> shifted by 12 hours. The largest ME should be in the late
afternoon/early
> evening, so around 0z, and not in the early morning (12-15z).
>
> Could the issue have something to do with the way MET is reading in
the
> database files?
> I've attached a xml file that looks at the HRRR vs. HRRRx surface
> temperature ME (as a function of valid hour) for all 12-hr forecasts
for
> all cycles on 7/20/16 over the eastern US. Perhaps you could load
it into
> the NCEP version of METViewer and let me know if you have any idea
what
> could be happening?
>
> Thanks again for your help on this!
>
> Ben
>
>
>
> On Mon, Jul 25, 2016 at 1:05 PM, Benjamin Blake - NOAA Affiliate <
> benjamin.blake at noaa.gov> wrote:
>
> > Hi John,
> >
> > I loaded the xml file you sent and I see that the valid_hour
contents are
> > indeed consistent with the valid times and not the init times.
Thank you
> > for sending that.
> >
> > Once I am able to load my xml file into the EMC version of
METViewer I
> > will look at the R data tab and make sure it is plotting valid
hour. It
> is
> > taking a while to load at the moment, which I'm guessing is likely
> because
> > you said that Tatiana is currently updating it.
> >
> > If it is correctly plotting valid hour then I will talk to Geoff
and see
> > if we can understand what is going on.
> >
> > Thank you for your help and I'll let you know if I am unable to
resolve
> > the discrepancy.
> > Ben
> >
> > On Mon, Jul 25, 2016 at 12:35 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> >> Ben,
> >>
> >> I see that you have a question about how METViewer is
computing/plotting
> >> the init_hour and valid_hour variables. Thanks for sending the
> images. I
> >> understand and see the discrepancy you're describing.
> >>
> >> I ran some tests on a small subset of data but am not able to
reproduce
> >> the
> >> behavior you're describing. I've attached a plot and xml to show
you
> what
> >> I'm seeing.
> >>
> >> You could try the following:
> >> (1) Save the attached xml to your local machine.
> >> (2) Go to... http://www.dtcenter.org/met/metviewer/metviewer1.jsp
> >> (3) Click "Load XML" in the top-right corner, navigate to
attached xml
> >> file, and click "OK".
> >> (4) Click "Generate Plot" to make the image.
> >> (5) Once the plot is finished, click on the "R Data" tab in the
plot
> >> window.
> >> (6) Inspect the columns of data and note that the contents of
valid_hour
> >> (i.e. the column just before DPT) really are consistent with the
valid
> >> times, not the init times.
> >>
> >> So I don't see an obvious problem in METViewer at this point.
> >>
> >> The next thing I'd check it how Geoff created the images you're
> comparing
> >> against. It's certainly possible that he either inadvertently or
> >> intentionally plotted against init_hour instead of valid_hour.
> >>
> >> FYI, Tatiana is in the process of updating the version of
METViewer
> >> running
> >> at EMC. This typically only takes about 10 minutes, but for the
large
> >> databases there it's taking much longer.
> >>
> >> Please let me know if there's anything else I can do to help you
debug
> >> this
> >> issue.
> >>
> >> Thanks,
> >> John Halley Gotway
> >>
> >>
> >> On Fri, Jul 22, 2016 at 10:48 AM, Benjamin Blake - NOAA Affiliate
via
> RT <
> >> met_help at ucar.edu> wrote:
> >>
> >> >
> >> > Fri Jul 22 10:48:03 2016: Request 77291 was acted upon.
> >> > Transaction: Ticket created by benjamin.blake at noaa.gov
> >> > Queue: met_help
> >> > Subject: Valid Hour vs. Init Hour - Possible Issue
> >> > Owner: Nobody
> >> > Requestors: benjamin.blake at noaa.gov
> >> > Status: new
> >> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291
> >
> >> >
> >> >
> >> > Hi,
> >> >
> >> > I am using MET Viewer to look into bias (ME) and BCRMSE for the
HRRR
> and
> >> > HRRRx, as a function of valid hour, to investigate the effects
of the
> >> > diurnal cycle.
> >> >
> >> > I could be wrong but I think MET is plotting initialization
hour as
> >> valid
> >> > hour and valid hour as initialization hour. Compare the two
surface
> dew
> >> > point plots, one using initialization hour as the independent
variable
> >> and
> >> > the other using valid hour, with slide 29 of Geoff Manikin's
MEG
> >> > presentation (attached).
> >> >
> >> > The plots for initialization hour seem to match quite closely
to the
> >> valid
> >> > hour plots on slide 29 (provided by GSD), especially for the
> operational
> >> > HRRR, whereas the plots for valid hour are phase shifted by 12
hours.
> >> I'm
> >> > definitely plotting over the correct region (East US) and I'm
using
> all
> >> > 12-hr forecasts (lead time is fixed at 12 hours) over the same
time
> >> period
> >> > as GSD.
> >> >
> >> > Thank you!
> >> > Ben Blake (EMC)
> >> >
> >> >
> >>
> >>
> >
>
>
------------------------------------------------
Subject: Valid Hour vs. Init Hour - Possible Issue
From: John Halley Gotway
Time: Tue Jul 26 11:05:54 2016
Ben,
Well, I did a visual inspection of the METViewer VSDB loading logic.
I've
attached a sample VSDB file, and I think it all comes down to the
interpretation of column 4.
Column 3 obviously contains the lead time in hours. Column 4 is in
YYYYMMDDHH format and METViewer interprets this as the forecast
initialization time. If columns 4 actually contains the valid time
instead, that would explain the behavior you're describing.
However Tatiana and I checked the documentation we received about the
VSDB
file format as the 4th column is listed as "init date/time".
I do have some doubts about all this tough based on previous
conversations
with Perry Shafran. The VSDB processing logic uses to the "newest"
observations to verify (for example) the current 0-hour forecast, the
6-hour forecast from 6 hours ago, the 12-hour from 12 hours ago... and
so
on. In this logic, the valid time remains constant while the lead
time
changes. Looking in the attached VSDB file, I see that column 4
remains
fixed while the lead times in column 3 change quickly.
So really this could go either way. The documentation suggests that
column
4 is the init time, but the processing logic suggests that it would be
the
valid time.
You could ask Perry to verify the interpretation of column 4.
John
On Tue, Jul 26, 2016 at 10:38 AM, John Halley Gotway <johnhg at ucar.edu>
wrote:
> Ben,
>
> My access to NCEP VPN isn't working, so I'm not able to test out
that XML
> directly. However, another possibility occurred to me. METViewer
can be
> loaded with data directly from MET or with VSDB files generated with
the
> NCEP Vx package. Both of those pathways read data from flat files
and
> store them in the database.
>
> The testing I did only covered the "MET" pathway, not the "VSDB"
one.
> It's possible that when reading VSDB data, METViewer is storing init
times
> as valid times or vice versa.
>
> Do you know how the HRRR data you're plotting via METViewer was
created?
> Were they VSDB files or MET output files.
>
> Thanks,
> John
>
> On Tue, Jul 26, 2016 at 9:40 AM, Benjamin Blake - NOAA Affiliate via
RT <
> met_help at ucar.edu> wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
>>
>> Hi John,
>>
>> I am still trying to figure out what the issue could be. I
verified with
>> the NCEP instance of METViewer that it is indeed plotting valid
hour.
>> Geoff asked Curtis Alexander (who made the original bias plots)
about the
>> values on the x-axis and Curtis confirmed that they were plotting
valid
>> hour also. The plots I made using MET Viewer still seem to be
phase
>> shifted by 12 hours. The largest ME should be in the late
afternoon/early
>> evening, so around 0z, and not in the early morning (12-15z).
>>
>> Could the issue have something to do with the way MET is reading in
the
>> database files?
>> I've attached a xml file that looks at the HRRR vs. HRRRx surface
>> temperature ME (as a function of valid hour) for all 12-hr
forecasts for
>> all cycles on 7/20/16 over the eastern US. Perhaps you could load
it into
>> the NCEP version of METViewer and let me know if you have any idea
what
>> could be happening?
>>
>> Thanks again for your help on this!
>>
>> Ben
>>
>>
>>
>> On Mon, Jul 25, 2016 at 1:05 PM, Benjamin Blake - NOAA Affiliate <
>> benjamin.blake at noaa.gov> wrote:
>>
>> > Hi John,
>> >
>> > I loaded the xml file you sent and I see that the valid_hour
contents
>> are
>> > indeed consistent with the valid times and not the init times.
Thank
>> you
>> > for sending that.
>> >
>> > Once I am able to load my xml file into the EMC version of
METViewer I
>> > will look at the R data tab and make sure it is plotting valid
hour. It
>> is
>> > taking a while to load at the moment, which I'm guessing is
likely
>> because
>> > you said that Tatiana is currently updating it.
>> >
>> > If it is correctly plotting valid hour then I will talk to Geoff
and see
>> > if we can understand what is going on.
>> >
>> > Thank you for your help and I'll let you know if I am unable to
resolve
>> > the discrepancy.
>> > Ben
>> >
>> > On Mon, Jul 25, 2016 at 12:35 PM, John Halley Gotway via RT <
>> > met_help at ucar.edu> wrote:
>> >
>> >> Ben,
>> >>
>> >> I see that you have a question about how METViewer is
>> computing/plotting
>> >> the init_hour and valid_hour variables. Thanks for sending the
>> images. I
>> >> understand and see the discrepancy you're describing.
>> >>
>> >> I ran some tests on a small subset of data but am not able to
reproduce
>> >> the
>> >> behavior you're describing. I've attached a plot and xml to
show you
>> what
>> >> I'm seeing.
>> >>
>> >> You could try the following:
>> >> (1) Save the attached xml to your local machine.
>> >> (2) Go to...
http://www.dtcenter.org/met/metviewer/metviewer1.jsp
>> >> (3) Click "Load XML" in the top-right corner, navigate to
attached xml
>> >> file, and click "OK".
>> >> (4) Click "Generate Plot" to make the image.
>> >> (5) Once the plot is finished, click on the "R Data" tab in the
plot
>> >> window.
>> >> (6) Inspect the columns of data and note that the contents of
>> valid_hour
>> >> (i.e. the column just before DPT) really are consistent with the
valid
>> >> times, not the init times.
>> >>
>> >> So I don't see an obvious problem in METViewer at this point.
>> >>
>> >> The next thing I'd check it how Geoff created the images you're
>> comparing
>> >> against. It's certainly possible that he either inadvertently
or
>> >> intentionally plotted against init_hour instead of valid_hour.
>> >>
>> >> FYI, Tatiana is in the process of updating the version of
METViewer
>> >> running
>> >> at EMC. This typically only takes about 10 minutes, but for the
large
>> >> databases there it's taking much longer.
>> >>
>> >> Please let me know if there's anything else I can do to help you
debug
>> >> this
>> >> issue.
>> >>
>> >> Thanks,
>> >> John Halley Gotway
>> >>
>> >>
>> >> On Fri, Jul 22, 2016 at 10:48 AM, Benjamin Blake - NOAA
Affiliate via
>> RT <
>> >> met_help at ucar.edu> wrote:
>> >>
>> >> >
>> >> > Fri Jul 22 10:48:03 2016: Request 77291 was acted upon.
>> >> > Transaction: Ticket created by benjamin.blake at noaa.gov
>> >> > Queue: met_help
>> >> > Subject: Valid Hour vs. Init Hour - Possible Issue
>> >> > Owner: Nobody
>> >> > Requestors: benjamin.blake at noaa.gov
>> >> > Status: new
>> >> > Ticket <URL:
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
>> >> >
>> >> >
>> >> > Hi,
>> >> >
>> >> > I am using MET Viewer to look into bias (ME) and BCRMSE for
the HRRR
>> and
>> >> > HRRRx, as a function of valid hour, to investigate the effects
of the
>> >> > diurnal cycle.
>> >> >
>> >> > I could be wrong but I think MET is plotting initialization
hour as
>> >> valid
>> >> > hour and valid hour as initialization hour. Compare the two
surface
>> dew
>> >> > point plots, one using initialization hour as the independent
>> variable
>> >> and
>> >> > the other using valid hour, with slide 29 of Geoff Manikin's
MEG
>> >> > presentation (attached).
>> >> >
>> >> > The plots for initialization hour seem to match quite closely
to the
>> >> valid
>> >> > hour plots on slide 29 (provided by GSD), especially for the
>> operational
>> >> > HRRR, whereas the plots for valid hour are phase shifted by 12
hours.
>> >> I'm
>> >> > definitely plotting over the correct region (East US) and I'm
using
>> all
>> >> > 12-hr forecasts (lead time is fixed at 12 hours) over the same
time
>> >> period
>> >> > as GSD.
>> >> >
>> >> > Thank you!
>> >> > Ben Blake (EMC)
>> >> >
>> >> >
>> >>
>> >>
>> >
>>
>>
>
------------------------------------------------
Subject: Valid Hour vs. Init Hour - Possible Issue
From: Jacob Carley - NOAA Affiliate
Time: Tue Jul 26 11:30:14 2016
Hi John,
I just took a look at our (EMC's) most recent vsdb files and saw a
date of
2016072500 in column 4. Furthermore, it also showed verification out
to
forecast hours 40+. Given that today is 07/26, this makes me almost
certain that column 4 is the valid time - not the initialization time.
As
you mentioned, this would explain the odd behavior Ben is seeing in
his MET
Viewer output.
I've cc'd Perry to confirm.
How quickly might we be able get this addressed? This will certainly
impact our verification stats generated from MET Viewer with our vsdb
files.
Thanks!
Jacob
On Tue, Jul 26, 2016 at 1:05 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Ben,
>
> Well, I did a visual inspection of the METViewer VSDB loading logic.
I've
> attached a sample VSDB file, and I think it all comes down to the
> interpretation of column 4.
>
> Column 3 obviously contains the lead time in hours. Column 4 is in
> YYYYMMDDHH format and METViewer interprets this as the forecast
> initialization time. If columns 4 actually contains the valid time
> instead, that would explain the behavior you're describing.
>
> However Tatiana and I checked the documentation we received about
the VSDB
> file format as the 4th column is listed as "init date/time".
>
> I do have some doubts about all this tough based on previous
conversations
> with Perry Shafran. The VSDB processing logic uses to the "newest"
> observations to verify (for example) the current 0-hour forecast,
the
> 6-hour forecast from 6 hours ago, the 12-hour from 12 hours ago...
and so
> on. In this logic, the valid time remains constant while the lead
time
> changes. Looking in the attached VSDB file, I see that column 4
remains
> fixed while the lead times in column 3 change quickly.
>
> So really this could go either way. The documentation suggests that
column
> 4 is the init time, but the processing logic suggests that it would
be the
> valid time.
>
> You could ask Perry to verify the interpretation of column 4.
>
> John
>
>
> On Tue, Jul 26, 2016 at 10:38 AM, John Halley Gotway
<johnhg at ucar.edu>
> wrote:
>
> > Ben,
> >
> > My access to NCEP VPN isn't working, so I'm not able to test out
that XML
> > directly. However, another possibility occurred to me. METViewer
can be
> > loaded with data directly from MET or with VSDB files generated
with the
> > NCEP Vx package. Both of those pathways read data from flat files
and
> > store them in the database.
> >
> > The testing I did only covered the "MET" pathway, not the "VSDB"
one.
> > It's possible that when reading VSDB data, METViewer is storing
init
> times
> > as valid times or vice versa.
> >
> > Do you know how the HRRR data you're plotting via METViewer was
created?
> > Were they VSDB files or MET output files.
> >
> > Thanks,
> > John
> >
> > On Tue, Jul 26, 2016 at 9:40 AM, Benjamin Blake - NOAA Affiliate
via RT <
> > met_help at ucar.edu> wrote:
> >
> >>
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
> >>
> >> Hi John,
> >>
> >> I am still trying to figure out what the issue could be. I
verified
> with
> >> the NCEP instance of METViewer that it is indeed plotting valid
hour.
> >> Geoff asked Curtis Alexander (who made the original bias plots)
about
> the
> >> values on the x-axis and Curtis confirmed that they were plotting
valid
> >> hour also. The plots I made using MET Viewer still seem to be
phase
> >> shifted by 12 hours. The largest ME should be in the late
> afternoon/early
> >> evening, so around 0z, and not in the early morning (12-15z).
> >>
> >> Could the issue have something to do with the way MET is reading
in the
> >> database files?
> >> I've attached a xml file that looks at the HRRR vs. HRRRx surface
> >> temperature ME (as a function of valid hour) for all 12-hr
forecasts for
> >> all cycles on 7/20/16 over the eastern US. Perhaps you could
load it
> into
> >> the NCEP version of METViewer and let me know if you have any
idea what
> >> could be happening?
> >>
> >> Thanks again for your help on this!
> >>
> >> Ben
> >>
> >>
> >>
> >> On Mon, Jul 25, 2016 at 1:05 PM, Benjamin Blake - NOAA Affiliate
<
> >> benjamin.blake at noaa.gov> wrote:
> >>
> >> > Hi John,
> >> >
> >> > I loaded the xml file you sent and I see that the valid_hour
contents
> >> are
> >> > indeed consistent with the valid times and not the init times.
Thank
> >> you
> >> > for sending that.
> >> >
> >> > Once I am able to load my xml file into the EMC version of
METViewer I
> >> > will look at the R data tab and make sure it is plotting valid
hour.
> It
> >> is
> >> > taking a while to load at the moment, which I'm guessing is
likely
> >> because
> >> > you said that Tatiana is currently updating it.
> >> >
> >> > If it is correctly plotting valid hour then I will talk to
Geoff and
> see
> >> > if we can understand what is going on.
> >> >
> >> > Thank you for your help and I'll let you know if I am unable to
> resolve
> >> > the discrepancy.
> >> > Ben
> >> >
> >> > On Mon, Jul 25, 2016 at 12:35 PM, John Halley Gotway via RT <
> >> > met_help at ucar.edu> wrote:
> >> >
> >> >> Ben,
> >> >>
> >> >> I see that you have a question about how METViewer is
> >> computing/plotting
> >> >> the init_hour and valid_hour variables. Thanks for sending
the
> >> images. I
> >> >> understand and see the discrepancy you're describing.
> >> >>
> >> >> I ran some tests on a small subset of data but am not able to
> reproduce
> >> >> the
> >> >> behavior you're describing. I've attached a plot and xml to
show you
> >> what
> >> >> I'm seeing.
> >> >>
> >> >> You could try the following:
> >> >> (1) Save the attached xml to your local machine.
> >> >> (2) Go to...
http://www.dtcenter.org/met/metviewer/metviewer1.jsp
> >> >> (3) Click "Load XML" in the top-right corner, navigate to
attached
> xml
> >> >> file, and click "OK".
> >> >> (4) Click "Generate Plot" to make the image.
> >> >> (5) Once the plot is finished, click on the "R Data" tab in
the plot
> >> >> window.
> >> >> (6) Inspect the columns of data and note that the contents of
> >> valid_hour
> >> >> (i.e. the column just before DPT) really are consistent with
the
> valid
> >> >> times, not the init times.
> >> >>
> >> >> So I don't see an obvious problem in METViewer at this point.
> >> >>
> >> >> The next thing I'd check it how Geoff created the images
you're
> >> comparing
> >> >> against. It's certainly possible that he either inadvertently
or
> >> >> intentionally plotted against init_hour instead of valid_hour.
> >> >>
> >> >> FYI, Tatiana is in the process of updating the version of
METViewer
> >> >> running
> >> >> at EMC. This typically only takes about 10 minutes, but for
the
> large
> >> >> databases there it's taking much longer.
> >> >>
> >> >> Please let me know if there's anything else I can do to help
you
> debug
> >> >> this
> >> >> issue.
> >> >>
> >> >> Thanks,
> >> >> John Halley Gotway
> >> >>
> >> >>
> >> >> On Fri, Jul 22, 2016 at 10:48 AM, Benjamin Blake - NOAA
Affiliate via
> >> RT <
> >> >> met_help at ucar.edu> wrote:
> >> >>
> >> >> >
> >> >> > Fri Jul 22 10:48:03 2016: Request 77291 was acted upon.
> >> >> > Transaction: Ticket created by benjamin.blake at noaa.gov
> >> >> > Queue: met_help
> >> >> > Subject: Valid Hour vs. Init Hour - Possible Issue
> >> >> > Owner: Nobody
> >> >> > Requestors: benjamin.blake at noaa.gov
> >> >> > Status: new
> >> >> > Ticket <URL:
> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
> >> >> >
> >> >> >
> >> >> > Hi,
> >> >> >
> >> >> > I am using MET Viewer to look into bias (ME) and BCRMSE for
the
> HRRR
> >> and
> >> >> > HRRRx, as a function of valid hour, to investigate the
effects of
> the
> >> >> > diurnal cycle.
> >> >> >
> >> >> > I could be wrong but I think MET is plotting initialization
hour as
> >> >> valid
> >> >> > hour and valid hour as initialization hour. Compare the two
> surface
> >> dew
> >> >> > point plots, one using initialization hour as the
independent
> >> variable
> >> >> and
> >> >> > the other using valid hour, with slide 29 of Geoff Manikin's
MEG
> >> >> > presentation (attached).
> >> >> >
> >> >> > The plots for initialization hour seem to match quite
closely to
> the
> >> >> valid
> >> >> > hour plots on slide 29 (provided by GSD), especially for the
> >> operational
> >> >> > HRRR, whereas the plots for valid hour are phase shifted by
12
> hours.
> >> >> I'm
> >> >> > definitely plotting over the correct region (East US) and
I'm using
> >> all
> >> >> > 12-hr forecasts (lead time is fixed at 12 hours) over the
same time
> >> >> period
> >> >> > as GSD.
> >> >> >
> >> >> > Thank you!
> >> >> > Ben Blake (EMC)
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >
> >>
> >>
> >
>
>
------------------------------------------------
Subject: Valid Hour vs. Init Hour - Possible Issue
From: perry.shafran at noaa.gov
Time: Tue Jul 26 11:38:22 2016
Hi, all,
Column 4 is the VALID time. I suppose it was possible that confusion
by me
led to this being interpreted as the initial time, but indeed column 4
is
the valid time.
Perry
On Tue, Jul 26, 2016 at 1:30 PM, Jacob Carley - NOAA Affiliate <
jacob.carley at noaa.gov> wrote:
> Hi John,
>
> I just took a look at our (EMC's) most recent vsdb files and saw a
date of
> 2016072500 in column 4. Furthermore, it also showed verification
out to
> forecast hours 40+. Given that today is 07/26, this makes me almost
> certain that column 4 is the valid time - not the initialization
time. As
> you mentioned, this would explain the odd behavior Ben is seeing in
his MET
> Viewer output.
>
> I've cc'd Perry to confirm.
>
> How quickly might we be able get this addressed? This will
certainly
> impact our verification stats generated from MET Viewer with our
vsdb files.
>
> Thanks!
> Jacob
>
> On Tue, Jul 26, 2016 at 1:05 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Ben,
>>
>> Well, I did a visual inspection of the METViewer VSDB loading
logic. I've
>> attached a sample VSDB file, and I think it all comes down to the
>> interpretation of column 4.
>>
>> Column 3 obviously contains the lead time in hours. Column 4 is in
>> YYYYMMDDHH format and METViewer interprets this as the forecast
>> initialization time. If columns 4 actually contains the valid time
>> instead, that would explain the behavior you're describing.
>>
>> However Tatiana and I checked the documentation we received about
the VSDB
>> file format as the 4th column is listed as "init date/time".
>>
>> I do have some doubts about all this tough based on previous
conversations
>> with Perry Shafran. The VSDB processing logic uses to the "newest"
>> observations to verify (for example) the current 0-hour forecast,
the
>> 6-hour forecast from 6 hours ago, the 12-hour from 12 hours ago...
and so
>> on. In this logic, the valid time remains constant while the lead
time
>> changes. Looking in the attached VSDB file, I see that column 4
remains
>> fixed while the lead times in column 3 change quickly.
>>
>> So really this could go either way. The documentation suggests
that
>> column
>> 4 is the init time, but the processing logic suggests that it would
be the
>> valid time.
>>
>> You could ask Perry to verify the interpretation of column 4.
>>
>> John
>>
>>
>> On Tue, Jul 26, 2016 at 10:38 AM, John Halley Gotway
<johnhg at ucar.edu>
>> wrote:
>>
>> > Ben,
>> >
>> > My access to NCEP VPN isn't working, so I'm not able to test out
that
>> XML
>> > directly. However, another possibility occurred to me.
METViewer can
>> be
>> > loaded with data directly from MET or with VSDB files generated
with the
>> > NCEP Vx package. Both of those pathways read data from flat
files and
>> > store them in the database.
>> >
>> > The testing I did only covered the "MET" pathway, not the "VSDB"
one.
>> > It's possible that when reading VSDB data, METViewer is storing
init
>> times
>> > as valid times or vice versa.
>> >
>> > Do you know how the HRRR data you're plotting via METViewer was
created?
>> > Were they VSDB files or MET output files.
>> >
>> > Thanks,
>> > John
>> >
>> > On Tue, Jul 26, 2016 at 9:40 AM, Benjamin Blake - NOAA Affiliate
via RT
>> <
>> > met_help at ucar.edu> wrote:
>> >
>> >>
>> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
>> >>
>> >> Hi John,
>> >>
>> >> I am still trying to figure out what the issue could be. I
verified
>> with
>> >> the NCEP instance of METViewer that it is indeed plotting valid
hour.
>> >> Geoff asked Curtis Alexander (who made the original bias plots)
about
>> the
>> >> values on the x-axis and Curtis confirmed that they were
plotting valid
>> >> hour also. The plots I made using MET Viewer still seem to be
phase
>> >> shifted by 12 hours. The largest ME should be in the late
>> afternoon/early
>> >> evening, so around 0z, and not in the early morning (12-15z).
>> >>
>> >> Could the issue have something to do with the way MET is reading
in the
>> >> database files?
>> >> I've attached a xml file that looks at the HRRR vs. HRRRx
surface
>> >> temperature ME (as a function of valid hour) for all 12-hr
forecasts
>> for
>> >> all cycles on 7/20/16 over the eastern US. Perhaps you could
load it
>> into
>> >> the NCEP version of METViewer and let me know if you have any
idea what
>> >> could be happening?
>> >>
>> >> Thanks again for your help on this!
>> >>
>> >> Ben
>> >>
>> >>
>> >>
>> >> On Mon, Jul 25, 2016 at 1:05 PM, Benjamin Blake - NOAA Affiliate
<
>> >> benjamin.blake at noaa.gov> wrote:
>> >>
>> >> > Hi John,
>> >> >
>> >> > I loaded the xml file you sent and I see that the valid_hour
contents
>> >> are
>> >> > indeed consistent with the valid times and not the init times.
Thank
>> >> you
>> >> > for sending that.
>> >> >
>> >> > Once I am able to load my xml file into the EMC version of
METViewer
>> I
>> >> > will look at the R data tab and make sure it is plotting valid
hour.
>> It
>> >> is
>> >> > taking a while to load at the moment, which I'm guessing is
likely
>> >> because
>> >> > you said that Tatiana is currently updating it.
>> >> >
>> >> > If it is correctly plotting valid hour then I will talk to
Geoff and
>> see
>> >> > if we can understand what is going on.
>> >> >
>> >> > Thank you for your help and I'll let you know if I am unable
to
>> resolve
>> >> > the discrepancy.
>> >> > Ben
>> >> >
>> >> > On Mon, Jul 25, 2016 at 12:35 PM, John Halley Gotway via RT <
>> >> > met_help at ucar.edu> wrote:
>> >> >
>> >> >> Ben,
>> >> >>
>> >> >> I see that you have a question about how METViewer is
>> >> computing/plotting
>> >> >> the init_hour and valid_hour variables. Thanks for sending
the
>> >> images. I
>> >> >> understand and see the discrepancy you're describing.
>> >> >>
>> >> >> I ran some tests on a small subset of data but am not able to
>> reproduce
>> >> >> the
>> >> >> behavior you're describing. I've attached a plot and xml to
show
>> you
>> >> what
>> >> >> I'm seeing.
>> >> >>
>> >> >> You could try the following:
>> >> >> (1) Save the attached xml to your local machine.
>> >> >> (2) Go to...
http://www.dtcenter.org/met/metviewer/metviewer1.jsp
>> >> >> (3) Click "Load XML" in the top-right corner, navigate to
attached
>> xml
>> >> >> file, and click "OK".
>> >> >> (4) Click "Generate Plot" to make the image.
>> >> >> (5) Once the plot is finished, click on the "R Data" tab in
the plot
>> >> >> window.
>> >> >> (6) Inspect the columns of data and note that the contents of
>> >> valid_hour
>> >> >> (i.e. the column just before DPT) really are consistent with
the
>> valid
>> >> >> times, not the init times.
>> >> >>
>> >> >> So I don't see an obvious problem in METViewer at this point.
>> >> >>
>> >> >> The next thing I'd check it how Geoff created the images
you're
>> >> comparing
>> >> >> against. It's certainly possible that he either
inadvertently or
>> >> >> intentionally plotted against init_hour instead of
valid_hour.
>> >> >>
>> >> >> FYI, Tatiana is in the process of updating the version of
METViewer
>> >> >> running
>> >> >> at EMC. This typically only takes about 10 minutes, but for
the
>> large
>> >> >> databases there it's taking much longer.
>> >> >>
>> >> >> Please let me know if there's anything else I can do to help
you
>> debug
>> >> >> this
>> >> >> issue.
>> >> >>
>> >> >> Thanks,
>> >> >> John Halley Gotway
>> >> >>
>> >> >>
>> >> >> On Fri, Jul 22, 2016 at 10:48 AM, Benjamin Blake - NOAA
Affiliate
>> via
>> >> RT <
>> >> >> met_help at ucar.edu> wrote:
>> >> >>
>> >> >> >
>> >> >> > Fri Jul 22 10:48:03 2016: Request 77291 was acted upon.
>> >> >> > Transaction: Ticket created by benjamin.blake at noaa.gov
>> >> >> > Queue: met_help
>> >> >> > Subject: Valid Hour vs. Init Hour - Possible Issue
>> >> >> > Owner: Nobody
>> >> >> > Requestors: benjamin.blake at noaa.gov
>> >> >> > Status: new
>> >> >> > Ticket <URL:
>> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
>> >> >> >
>> >> >> >
>> >> >> > Hi,
>> >> >> >
>> >> >> > I am using MET Viewer to look into bias (ME) and BCRMSE for
the
>> HRRR
>> >> and
>> >> >> > HRRRx, as a function of valid hour, to investigate the
effects of
>> the
>> >> >> > diurnal cycle.
>> >> >> >
>> >> >> > I could be wrong but I think MET is plotting initialization
hour
>> as
>> >> >> valid
>> >> >> > hour and valid hour as initialization hour. Compare the
two
>> surface
>> >> dew
>> >> >> > point plots, one using initialization hour as the
independent
>> >> variable
>> >> >> and
>> >> >> > the other using valid hour, with slide 29 of Geoff
Manikin's MEG
>> >> >> > presentation (attached).
>> >> >> >
>> >> >> > The plots for initialization hour seem to match quite
closely to
>> the
>> >> >> valid
>> >> >> > hour plots on slide 29 (provided by GSD), especially for
the
>> >> operational
>> >> >> > HRRR, whereas the plots for valid hour are phase shifted by
12
>> hours.
>> >> >> I'm
>> >> >> > definitely plotting over the correct region (East US) and
I'm
>> using
>> >> all
>> >> >> > 12-hr forecasts (lead time is fixed at 12 hours) over the
same
>> time
>> >> >> period
>> >> >> > as GSD.
>> >> >> >
>> >> >> > Thank you!
>> >> >> > Ben Blake (EMC)
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >
>>
>>
>
------------------------------------------------
Subject: Valid Hour vs. Init Hour - Possible Issue
From: John Halley Gotway
Time: Tue Jul 26 13:09:58 2016
Hi all,
Looks like the documentation is something we generated ourselves.
Looking
back through email, I see that Binbin sent us VSDB header info back in
October 2014 which listed that column as "run time". We made the
mistake
of interpreting it as the initialization time.
Sorry for all of this confusion, but thanks Ben for tracking it down!
The good news is that the fix is pretty straightforward...
(1) Patch the METViewer VSDB loading logic to correctly interpret
column 4
as the valid time. Deploy the updated logic in a new version of
METViewer.
(2) Update the existing databases by subtracting the lead time from
the
initialization and valid times.
Here's the old (incorrect) logic:
Init = column 4
Lead = column 3
Valid = column 4 + column 3
The correct logic should be:
Init = column 4 - column 3
Lead = column 3
Valid = column 4
Subtracting the lead time (i.e. column 3) from both the the init and
valid
times should correct the existing databases.
But I'll leave it to Tatiana to estimate how long these patches will
take.
Thanks,
John
On Tue, Jul 26, 2016 at 11:38 AM, perry.shafran at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
>
> Hi, all,
>
> Column 4 is the VALID time. I suppose it was possible that
confusion by me
> led to this being interpreted as the initial time, but indeed column
4 is
> the valid time.
>
> Perry
>
> On Tue, Jul 26, 2016 at 1:30 PM, Jacob Carley - NOAA Affiliate <
> jacob.carley at noaa.gov> wrote:
>
> > Hi John,
> >
> > I just took a look at our (EMC's) most recent vsdb files and saw a
date
> of
> > 2016072500 in column 4. Furthermore, it also showed verification
out to
> > forecast hours 40+. Given that today is 07/26, this makes me
almost
> > certain that column 4 is the valid time - not the initialization
time.
> As
> > you mentioned, this would explain the odd behavior Ben is seeing
in his
> MET
> > Viewer output.
> >
> > I've cc'd Perry to confirm.
> >
> > How quickly might we be able get this addressed? This will
certainly
> > impact our verification stats generated from MET Viewer with our
vsdb
> files.
> >
> > Thanks!
> > Jacob
> >
> > On Tue, Jul 26, 2016 at 1:05 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> >> Ben,
> >>
> >> Well, I did a visual inspection of the METViewer VSDB loading
logic.
> I've
> >> attached a sample VSDB file, and I think it all comes down to the
> >> interpretation of column 4.
> >>
> >> Column 3 obviously contains the lead time in hours. Column 4 is
in
> >> YYYYMMDDHH format and METViewer interprets this as the forecast
> >> initialization time. If columns 4 actually contains the valid
time
> >> instead, that would explain the behavior you're describing.
> >>
> >> However Tatiana and I checked the documentation we received about
the
> VSDB
> >> file format as the 4th column is listed as "init date/time".
> >>
> >> I do have some doubts about all this tough based on previous
> conversations
> >> with Perry Shafran. The VSDB processing logic uses to the
"newest"
> >> observations to verify (for example) the current 0-hour forecast,
the
> >> 6-hour forecast from 6 hours ago, the 12-hour from 12 hours
ago... and
> so
> >> on. In this logic, the valid time remains constant while the
lead time
> >> changes. Looking in the attached VSDB file, I see that column 4
remains
> >> fixed while the lead times in column 3 change quickly.
> >>
> >> So really this could go either way. The documentation suggests
that
> >> column
> >> 4 is the init time, but the processing logic suggests that it
would be
> the
> >> valid time.
> >>
> >> You could ask Perry to verify the interpretation of column 4.
> >>
> >> John
> >>
> >>
> >> On Tue, Jul 26, 2016 at 10:38 AM, John Halley Gotway
<johnhg at ucar.edu>
> >> wrote:
> >>
> >> > Ben,
> >> >
> >> > My access to NCEP VPN isn't working, so I'm not able to test
out that
> >> XML
> >> > directly. However, another possibility occurred to me.
METViewer can
> >> be
> >> > loaded with data directly from MET or with VSDB files generated
with
> the
> >> > NCEP Vx package. Both of those pathways read data from flat
files and
> >> > store them in the database.
> >> >
> >> > The testing I did only covered the "MET" pathway, not the
"VSDB" one.
> >> > It's possible that when reading VSDB data, METViewer is storing
init
> >> times
> >> > as valid times or vice versa.
> >> >
> >> > Do you know how the HRRR data you're plotting via METViewer was
> created?
> >> > Were they VSDB files or MET output files.
> >> >
> >> > Thanks,
> >> > John
> >> >
> >> > On Tue, Jul 26, 2016 at 9:40 AM, Benjamin Blake - NOAA
Affiliate via
> RT
> >> <
> >> > met_help at ucar.edu> wrote:
> >> >
> >> >>
> >> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291
>
> >> >>
> >> >> Hi John,
> >> >>
> >> >> I am still trying to figure out what the issue could be. I
verified
> >> with
> >> >> the NCEP instance of METViewer that it is indeed plotting
valid hour.
> >> >> Geoff asked Curtis Alexander (who made the original bias
plots) about
> >> the
> >> >> values on the x-axis and Curtis confirmed that they were
plotting
> valid
> >> >> hour also. The plots I made using MET Viewer still seem to be
phase
> >> >> shifted by 12 hours. The largest ME should be in the late
> >> afternoon/early
> >> >> evening, so around 0z, and not in the early morning (12-15z).
> >> >>
> >> >> Could the issue have something to do with the way MET is
reading in
> the
> >> >> database files?
> >> >> I've attached a xml file that looks at the HRRR vs. HRRRx
surface
> >> >> temperature ME (as a function of valid hour) for all 12-hr
forecasts
> >> for
> >> >> all cycles on 7/20/16 over the eastern US. Perhaps you could
load it
> >> into
> >> >> the NCEP version of METViewer and let me know if you have any
idea
> what
> >> >> could be happening?
> >> >>
> >> >> Thanks again for your help on this!
> >> >>
> >> >> Ben
> >> >>
> >> >>
> >> >>
> >> >> On Mon, Jul 25, 2016 at 1:05 PM, Benjamin Blake - NOAA
Affiliate <
> >> >> benjamin.blake at noaa.gov> wrote:
> >> >>
> >> >> > Hi John,
> >> >> >
> >> >> > I loaded the xml file you sent and I see that the valid_hour
> contents
> >> >> are
> >> >> > indeed consistent with the valid times and not the init
times.
> Thank
> >> >> you
> >> >> > for sending that.
> >> >> >
> >> >> > Once I am able to load my xml file into the EMC version of
> METViewer
> >> I
> >> >> > will look at the R data tab and make sure it is plotting
valid
> hour.
> >> It
> >> >> is
> >> >> > taking a while to load at the moment, which I'm guessing is
likely
> >> >> because
> >> >> > you said that Tatiana is currently updating it.
> >> >> >
> >> >> > If it is correctly plotting valid hour then I will talk to
Geoff
> and
> >> see
> >> >> > if we can understand what is going on.
> >> >> >
> >> >> > Thank you for your help and I'll let you know if I am unable
to
> >> resolve
> >> >> > the discrepancy.
> >> >> > Ben
> >> >> >
> >> >> > On Mon, Jul 25, 2016 at 12:35 PM, John Halley Gotway via RT
<
> >> >> > met_help at ucar.edu> wrote:
> >> >> >
> >> >> >> Ben,
> >> >> >>
> >> >> >> I see that you have a question about how METViewer is
> >> >> computing/plotting
> >> >> >> the init_hour and valid_hour variables. Thanks for sending
the
> >> >> images. I
> >> >> >> understand and see the discrepancy you're describing.
> >> >> >>
> >> >> >> I ran some tests on a small subset of data but am not able
to
> >> reproduce
> >> >> >> the
> >> >> >> behavior you're describing. I've attached a plot and xml
to show
> >> you
> >> >> what
> >> >> >> I'm seeing.
> >> >> >>
> >> >> >> You could try the following:
> >> >> >> (1) Save the attached xml to your local machine.
> >> >> >> (2) Go to...
http://www.dtcenter.org/met/metviewer/metviewer1.jsp
> >> >> >> (3) Click "Load XML" in the top-right corner, navigate to
attached
> >> xml
> >> >> >> file, and click "OK".
> >> >> >> (4) Click "Generate Plot" to make the image.
> >> >> >> (5) Once the plot is finished, click on the "R Data" tab in
the
> plot
> >> >> >> window.
> >> >> >> (6) Inspect the columns of data and note that the contents
of
> >> >> valid_hour
> >> >> >> (i.e. the column just before DPT) really are consistent
with the
> >> valid
> >> >> >> times, not the init times.
> >> >> >>
> >> >> >> So I don't see an obvious problem in METViewer at this
point.
> >> >> >>
> >> >> >> The next thing I'd check it how Geoff created the images
you're
> >> >> comparing
> >> >> >> against. It's certainly possible that he either
inadvertently or
> >> >> >> intentionally plotted against init_hour instead of
valid_hour.
> >> >> >>
> >> >> >> FYI, Tatiana is in the process of updating the version of
> METViewer
> >> >> >> running
> >> >> >> at EMC. This typically only takes about 10 minutes, but
for the
> >> large
> >> >> >> databases there it's taking much longer.
> >> >> >>
> >> >> >> Please let me know if there's anything else I can do to
help you
> >> debug
> >> >> >> this
> >> >> >> issue.
> >> >> >>
> >> >> >> Thanks,
> >> >> >> John Halley Gotway
> >> >> >>
> >> >> >>
> >> >> >> On Fri, Jul 22, 2016 at 10:48 AM, Benjamin Blake - NOAA
Affiliate
> >> via
> >> >> RT <
> >> >> >> met_help at ucar.edu> wrote:
> >> >> >>
> >> >> >> >
> >> >> >> > Fri Jul 22 10:48:03 2016: Request 77291 was acted upon.
> >> >> >> > Transaction: Ticket created by benjamin.blake at noaa.gov
> >> >> >> > Queue: met_help
> >> >> >> > Subject: Valid Hour vs. Init Hour - Possible Issue
> >> >> >> > Owner: Nobody
> >> >> >> > Requestors: benjamin.blake at noaa.gov
> >> >> >> > Status: new
> >> >> >> > Ticket <URL:
> >> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
> >> >> >> >
> >> >> >> >
> >> >> >> > Hi,
> >> >> >> >
> >> >> >> > I am using MET Viewer to look into bias (ME) and BCRMSE
for the
> >> HRRR
> >> >> and
> >> >> >> > HRRRx, as a function of valid hour, to investigate the
effects
> of
> >> the
> >> >> >> > diurnal cycle.
> >> >> >> >
> >> >> >> > I could be wrong but I think MET is plotting
initialization hour
> >> as
> >> >> >> valid
> >> >> >> > hour and valid hour as initialization hour. Compare the
two
> >> surface
> >> >> dew
> >> >> >> > point plots, one using initialization hour as the
independent
> >> >> variable
> >> >> >> and
> >> >> >> > the other using valid hour, with slide 29 of Geoff
Manikin's MEG
> >> >> >> > presentation (attached).
> >> >> >> >
> >> >> >> > The plots for initialization hour seem to match quite
closely to
> >> the
> >> >> >> valid
> >> >> >> > hour plots on slide 29 (provided by GSD), especially for
the
> >> >> operational
> >> >> >> > HRRR, whereas the plots for valid hour are phase shifted
by 12
> >> hours.
> >> >> >> I'm
> >> >> >> > definitely plotting over the correct region (East US) and
I'm
> >> using
> >> >> all
> >> >> >> > 12-hr forecasts (lead time is fixed at 12 hours) over the
same
> >> time
> >> >> >> period
> >> >> >> > as GSD.
> >> >> >> >
> >> >> >> > Thank you!
> >> >> >> > Ben Blake (EMC)
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >
> >>
> >>
> >
>
>
------------------------------------------------
Subject: Valid Hour vs. Init Hour - Possible Issue
From: Benjamin Blake - NOAA Affiliate
Time: Tue Jul 26 13:52:41 2016
Hi John,
Sounds great! Thanks again for looking into this.
And thanks Jacob and Perry for confirming.
Ben
On Tue, Jul 26, 2016 at 3:09 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Hi all,
>
> Looks like the documentation is something we generated ourselves.
Looking
> back through email, I see that Binbin sent us VSDB header info back
in
> October 2014 which listed that column as "run time". We made the
mistake
> of interpreting it as the initialization time.
>
> Sorry for all of this confusion, but thanks Ben for tracking it
down!
>
> The good news is that the fix is pretty straightforward...
>
> (1) Patch the METViewer VSDB loading logic to correctly interpret
column 4
> as the valid time. Deploy the updated logic in a new version of
METViewer.
>
> (2) Update the existing databases by subtracting the lead time from
the
> initialization and valid times.
>
> Here's the old (incorrect) logic:
> Init = column 4
> Lead = column 3
> Valid = column 4 + column 3
>
> The correct logic should be:
> Init = column 4 - column 3
> Lead = column 3
> Valid = column 4
>
> Subtracting the lead time (i.e. column 3) from both the the init and
valid
> times should correct the existing databases.
>
> But I'll leave it to Tatiana to estimate how long these patches will
take.
>
> Thanks,
> John
>
> On Tue, Jul 26, 2016 at 11:38 AM, perry.shafran at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
> >
> > Hi, all,
> >
> > Column 4 is the VALID time. I suppose it was possible that
confusion by
> me
> > led to this being interpreted as the initial time, but indeed
column 4 is
> > the valid time.
> >
> > Perry
> >
> > On Tue, Jul 26, 2016 at 1:30 PM, Jacob Carley - NOAA Affiliate <
> > jacob.carley at noaa.gov> wrote:
> >
> > > Hi John,
> > >
> > > I just took a look at our (EMC's) most recent vsdb files and saw
a date
> > of
> > > 2016072500 in column 4. Furthermore, it also showed
verification out
> to
> > > forecast hours 40+. Given that today is 07/26, this makes me
almost
> > > certain that column 4 is the valid time - not the initialization
time.
> > As
> > > you mentioned, this would explain the odd behavior Ben is seeing
in his
> > MET
> > > Viewer output.
> > >
> > > I've cc'd Perry to confirm.
> > >
> > > How quickly might we be able get this addressed? This will
certainly
> > > impact our verification stats generated from MET Viewer with our
vsdb
> > files.
> > >
> > > Thanks!
> > > Jacob
> > >
> > > On Tue, Jul 26, 2016 at 1:05 PM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > >> Ben,
> > >>
> > >> Well, I did a visual inspection of the METViewer VSDB loading
logic.
> > I've
> > >> attached a sample VSDB file, and I think it all comes down to
the
> > >> interpretation of column 4.
> > >>
> > >> Column 3 obviously contains the lead time in hours. Column 4
is in
> > >> YYYYMMDDHH format and METViewer interprets this as the forecast
> > >> initialization time. If columns 4 actually contains the valid
time
> > >> instead, that would explain the behavior you're describing.
> > >>
> > >> However Tatiana and I checked the documentation we received
about the
> > VSDB
> > >> file format as the 4th column is listed as "init date/time".
> > >>
> > >> I do have some doubts about all this tough based on previous
> > conversations
> > >> with Perry Shafran. The VSDB processing logic uses to the
"newest"
> > >> observations to verify (for example) the current 0-hour
forecast, the
> > >> 6-hour forecast from 6 hours ago, the 12-hour from 12 hours
ago... and
> > so
> > >> on. In this logic, the valid time remains constant while the
lead
> time
> > >> changes. Looking in the attached VSDB file, I see that column
4
> remains
> > >> fixed while the lead times in column 3 change quickly.
> > >>
> > >> So really this could go either way. The documentation suggests
that
> > >> column
> > >> 4 is the init time, but the processing logic suggests that it
would be
> > the
> > >> valid time.
> > >>
> > >> You could ask Perry to verify the interpretation of column 4.
> > >>
> > >> John
> > >>
> > >>
> > >> On Tue, Jul 26, 2016 at 10:38 AM, John Halley Gotway
<johnhg at ucar.edu
> >
> > >> wrote:
> > >>
> > >> > Ben,
> > >> >
> > >> > My access to NCEP VPN isn't working, so I'm not able to test
out
> that
> > >> XML
> > >> > directly. However, another possibility occurred to me.
METViewer
> can
> > >> be
> > >> > loaded with data directly from MET or with VSDB files
generated with
> > the
> > >> > NCEP Vx package. Both of those pathways read data from flat
files
> and
> > >> > store them in the database.
> > >> >
> > >> > The testing I did only covered the "MET" pathway, not the
"VSDB"
> one.
> > >> > It's possible that when reading VSDB data, METViewer is
storing init
> > >> times
> > >> > as valid times or vice versa.
> > >> >
> > >> > Do you know how the HRRR data you're plotting via METViewer
was
> > created?
> > >> > Were they VSDB files or MET output files.
> > >> >
> > >> > Thanks,
> > >> > John
> > >> >
> > >> > On Tue, Jul 26, 2016 at 9:40 AM, Benjamin Blake - NOAA
Affiliate via
> > RT
> > >> <
> > >> > met_help at ucar.edu> wrote:
> > >> >
> > >> >>
> > >> >> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
> > >> >>
> > >> >> Hi John,
> > >> >>
> > >> >> I am still trying to figure out what the issue could be. I
> verified
> > >> with
> > >> >> the NCEP instance of METViewer that it is indeed plotting
valid
> hour.
> > >> >> Geoff asked Curtis Alexander (who made the original bias
plots)
> about
> > >> the
> > >> >> values on the x-axis and Curtis confirmed that they were
plotting
> > valid
> > >> >> hour also. The plots I made using MET Viewer still seem to
be
> phase
> > >> >> shifted by 12 hours. The largest ME should be in the late
> > >> afternoon/early
> > >> >> evening, so around 0z, and not in the early morning (12-
15z).
> > >> >>
> > >> >> Could the issue have something to do with the way MET is
reading in
> > the
> > >> >> database files?
> > >> >> I've attached a xml file that looks at the HRRR vs. HRRRx
surface
> > >> >> temperature ME (as a function of valid hour) for all 12-hr
> forecasts
> > >> for
> > >> >> all cycles on 7/20/16 over the eastern US. Perhaps you
could load
> it
> > >> into
> > >> >> the NCEP version of METViewer and let me know if you have
any idea
> > what
> > >> >> could be happening?
> > >> >>
> > >> >> Thanks again for your help on this!
> > >> >>
> > >> >> Ben
> > >> >>
> > >> >>
> > >> >>
> > >> >> On Mon, Jul 25, 2016 at 1:05 PM, Benjamin Blake - NOAA
Affiliate <
> > >> >> benjamin.blake at noaa.gov> wrote:
> > >> >>
> > >> >> > Hi John,
> > >> >> >
> > >> >> > I loaded the xml file you sent and I see that the
valid_hour
> > contents
> > >> >> are
> > >> >> > indeed consistent with the valid times and not the init
times.
> > Thank
> > >> >> you
> > >> >> > for sending that.
> > >> >> >
> > >> >> > Once I am able to load my xml file into the EMC version of
> > METViewer
> > >> I
> > >> >> > will look at the R data tab and make sure it is plotting
valid
> > hour.
> > >> It
> > >> >> is
> > >> >> > taking a while to load at the moment, which I'm guessing
is
> likely
> > >> >> because
> > >> >> > you said that Tatiana is currently updating it.
> > >> >> >
> > >> >> > If it is correctly plotting valid hour then I will talk to
Geoff
> > and
> > >> see
> > >> >> > if we can understand what is going on.
> > >> >> >
> > >> >> > Thank you for your help and I'll let you know if I am
unable to
> > >> resolve
> > >> >> > the discrepancy.
> > >> >> > Ben
> > >> >> >
> > >> >> > On Mon, Jul 25, 2016 at 12:35 PM, John Halley Gotway via
RT <
> > >> >> > met_help at ucar.edu> wrote:
> > >> >> >
> > >> >> >> Ben,
> > >> >> >>
> > >> >> >> I see that you have a question about how METViewer is
> > >> >> computing/plotting
> > >> >> >> the init_hour and valid_hour variables. Thanks for
sending the
> > >> >> images. I
> > >> >> >> understand and see the discrepancy you're describing.
> > >> >> >>
> > >> >> >> I ran some tests on a small subset of data but am not
able to
> > >> reproduce
> > >> >> >> the
> > >> >> >> behavior you're describing. I've attached a plot and xml
to
> show
> > >> you
> > >> >> what
> > >> >> >> I'm seeing.
> > >> >> >>
> > >> >> >> You could try the following:
> > >> >> >> (1) Save the attached xml to your local machine.
> > >> >> >> (2) Go to...
> http://www.dtcenter.org/met/metviewer/metviewer1.jsp
> > >> >> >> (3) Click "Load XML" in the top-right corner, navigate to
> attached
> > >> xml
> > >> >> >> file, and click "OK".
> > >> >> >> (4) Click "Generate Plot" to make the image.
> > >> >> >> (5) Once the plot is finished, click on the "R Data" tab
in the
> > plot
> > >> >> >> window.
> > >> >> >> (6) Inspect the columns of data and note that the
contents of
> > >> >> valid_hour
> > >> >> >> (i.e. the column just before DPT) really are consistent
with the
> > >> valid
> > >> >> >> times, not the init times.
> > >> >> >>
> > >> >> >> So I don't see an obvious problem in METViewer at this
point.
> > >> >> >>
> > >> >> >> The next thing I'd check it how Geoff created the images
you're
> > >> >> comparing
> > >> >> >> against. It's certainly possible that he either
inadvertently
> or
> > >> >> >> intentionally plotted against init_hour instead of
valid_hour.
> > >> >> >>
> > >> >> >> FYI, Tatiana is in the process of updating the version of
> > METViewer
> > >> >> >> running
> > >> >> >> at EMC. This typically only takes about 10 minutes, but
for the
> > >> large
> > >> >> >> databases there it's taking much longer.
> > >> >> >>
> > >> >> >> Please let me know if there's anything else I can do to
help you
> > >> debug
> > >> >> >> this
> > >> >> >> issue.
> > >> >> >>
> > >> >> >> Thanks,
> > >> >> >> John Halley Gotway
> > >> >> >>
> > >> >> >>
> > >> >> >> On Fri, Jul 22, 2016 at 10:48 AM, Benjamin Blake - NOAA
> Affiliate
> > >> via
> > >> >> RT <
> > >> >> >> met_help at ucar.edu> wrote:
> > >> >> >>
> > >> >> >> >
> > >> >> >> > Fri Jul 22 10:48:03 2016: Request 77291 was acted upon.
> > >> >> >> > Transaction: Ticket created by benjamin.blake at noaa.gov
> > >> >> >> > Queue: met_help
> > >> >> >> > Subject: Valid Hour vs. Init Hour - Possible Issue
> > >> >> >> > Owner: Nobody
> > >> >> >> > Requestors: benjamin.blake at noaa.gov
> > >> >> >> > Status: new
> > >> >> >> > Ticket <URL:
> > >> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
> > >> >> >> >
> > >> >> >> >
> > >> >> >> > Hi,
> > >> >> >> >
> > >> >> >> > I am using MET Viewer to look into bias (ME) and BCRMSE
for
> the
> > >> HRRR
> > >> >> and
> > >> >> >> > HRRRx, as a function of valid hour, to investigate the
effects
> > of
> > >> the
> > >> >> >> > diurnal cycle.
> > >> >> >> >
> > >> >> >> > I could be wrong but I think MET is plotting
initialization
> hour
> > >> as
> > >> >> >> valid
> > >> >> >> > hour and valid hour as initialization hour. Compare
the two
> > >> surface
> > >> >> dew
> > >> >> >> > point plots, one using initialization hour as the
independent
> > >> >> variable
> > >> >> >> and
> > >> >> >> > the other using valid hour, with slide 29 of Geoff
Manikin's
> MEG
> > >> >> >> > presentation (attached).
> > >> >> >> >
> > >> >> >> > The plots for initialization hour seem to match quite
closely
> to
> > >> the
> > >> >> >> valid
> > >> >> >> > hour plots on slide 29 (provided by GSD), especially
for the
> > >> >> operational
> > >> >> >> > HRRR, whereas the plots for valid hour are phase
shifted by 12
> > >> hours.
> > >> >> >> I'm
> > >> >> >> > definitely plotting over the correct region (East US)
and I'm
> > >> using
> > >> >> all
> > >> >> >> > 12-hr forecasts (lead time is fixed at 12 hours) over
the same
> > >> time
> > >> >> >> period
> > >> >> >> > as GSD.
> > >> >> >> >
> > >> >> >> > Thank you!
> > >> >> >> > Ben Blake (EMC)
> > >> >> >> >
> > >> >> >> >
> > >> >> >>
> > >> >> >>
> > >> >> >
> > >> >>
> > >> >>
> > >> >
> > >>
> > >>
> > >
> >
> >
>
>
------------------------------------------------
Subject: Valid Hour vs. Init Hour - Possible Issue
From: Tatiana Burek
Time: Wed Jul 27 15:29:17 2016
Hi all,
I have a script that would fix existing databases and a patch for the
loading module ready.
When is the best time to update the software?
Tatiana
On Tue Jul 26 13:52:41 2016, benjamin.blake at noaa.gov wrote:
> Hi John,
>
> Sounds great! Thanks again for looking into this.
> And thanks Jacob and Perry for confirming.
>
> Ben
>
> On Tue, Jul 26, 2016 at 3:09 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Hi all,
> >
> > Looks like the documentation is something we generated ourselves.
> > Looking
> > back through email, I see that Binbin sent us VSDB header info
back
> > in
> > October 2014 which listed that column as "run time". We made the
> > mistake
> > of interpreting it as the initialization time.
> >
> > Sorry for all of this confusion, but thanks Ben for tracking it
down!
> >
> > The good news is that the fix is pretty straightforward...
> >
> > (1) Patch the METViewer VSDB loading logic to correctly interpret
> > column 4
> > as the valid time. Deploy the updated logic in a new version of
> > METViewer.
> >
> > (2) Update the existing databases by subtracting the lead time
from
> > the
> > initialization and valid times.
> >
> > Here's the old (incorrect) logic:
> > Init = column 4
> > Lead = column 3
> > Valid = column 4 + column 3
> >
> > The correct logic should be:
> > Init = column 4 - column 3
> > Lead = column 3
> > Valid = column 4
> >
> > Subtracting the lead time (i.e. column 3) from both the the init
and
> > valid
> > times should correct the existing databases.
> >
> > But I'll leave it to Tatiana to estimate how long these patches
will
> > take.
> >
> > Thanks,
> > John
> >
> > On Tue, Jul 26, 2016 at 11:38 AM, perry.shafran at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
> > >
> > > Hi, all,
> > >
> > > Column 4 is the VALID time. I suppose it was possible that
> > > confusion by
> > me
> > > led to this being interpreted as the initial time, but indeed
> > > column 4 is
> > > the valid time.
> > >
> > > Perry
> > >
> > > On Tue, Jul 26, 2016 at 1:30 PM, Jacob Carley - NOAA Affiliate <
> > > jacob.carley at noaa.gov> wrote:
> > >
> > > > Hi John,
> > > >
> > > > I just took a look at our (EMC's) most recent vsdb files and
saw
> > > > a date
> > > of
> > > > 2016072500 in column 4. Furthermore, it also showed
verification
> > > > out
> > to
> > > > forecast hours 40+. Given that today is 07/26, this makes me
> > > > almost
> > > > certain that column 4 is the valid time - not the
initialization
> > > > time.
> > > As
> > > > you mentioned, this would explain the odd behavior Ben is
seeing
> > > > in his
> > > MET
> > > > Viewer output.
> > > >
> > > > I've cc'd Perry to confirm.
> > > >
> > > > How quickly might we be able get this addressed? This will
> > > > certainly
> > > > impact our verification stats generated from MET Viewer with
our
> > > > vsdb
> > > files.
> > > >
> > > > Thanks!
> > > > Jacob
> > > >
> > > > On Tue, Jul 26, 2016 at 1:05 PM, John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > >> Ben,
> > > >>
> > > >> Well, I did a visual inspection of the METViewer VSDB loading
> > > >> logic.
> > > I've
> > > >> attached a sample VSDB file, and I think it all comes down to
> > > >> the
> > > >> interpretation of column 4.
> > > >>
> > > >> Column 3 obviously contains the lead time in hours. Column 4
is
> > > >> in
> > > >> YYYYMMDDHH format and METViewer interprets this as the
forecast
> > > >> initialization time. If columns 4 actually contains the
valid
> > > >> time
> > > >> instead, that would explain the behavior you're describing.
> > > >>
> > > >> However Tatiana and I checked the documentation we received
> > > >> about the
> > > VSDB
> > > >> file format as the 4th column is listed as "init date/time".
> > > >>
> > > >> I do have some doubts about all this tough based on previous
> > > conversations
> > > >> with Perry Shafran. The VSDB processing logic uses to the
> > > >> "newest"
> > > >> observations to verify (for example) the current 0-hour
> > > >> forecast, the
> > > >> 6-hour forecast from 6 hours ago, the 12-hour from 12 hours
> > > >> ago... and
> > > so
> > > >> on. In this logic, the valid time remains constant while the
> > > >> lead
> > time
> > > >> changes. Looking in the attached VSDB file, I see that
column 4
> > remains
> > > >> fixed while the lead times in column 3 change quickly.
> > > >>
> > > >> So really this could go either way. The documentation
suggests
> > > >> that
> > > >> column
> > > >> 4 is the init time, but the processing logic suggests that it
> > > >> would be
> > > the
> > > >> valid time.
> > > >>
> > > >> You could ask Perry to verify the interpretation of column 4.
> > > >>
> > > >> John
> > > >>
> > > >>
> > > >> On Tue, Jul 26, 2016 at 10:38 AM, John Halley Gotway
> > > >> <johnhg at ucar.edu
> > >
> > > >> wrote:
> > > >>
> > > >> > Ben,
> > > >> >
> > > >> > My access to NCEP VPN isn't working, so I'm not able to
test
> > > >> > out
> > that
> > > >> XML
> > > >> > directly. However, another possibility occurred to me.
> > > >> > METViewer
> > can
> > > >> be
> > > >> > loaded with data directly from MET or with VSDB files
> > > >> > generated with
> > > the
> > > >> > NCEP Vx package. Both of those pathways read data from
flat
> > > >> > files
> > and
> > > >> > store them in the database.
> > > >> >
> > > >> > The testing I did only covered the "MET" pathway, not the
> > > >> > "VSDB"
> > one.
> > > >> > It's possible that when reading VSDB data, METViewer is
> > > >> > storing init
> > > >> times
> > > >> > as valid times or vice versa.
> > > >> >
> > > >> > Do you know how the HRRR data you're plotting via METViewer
> > > >> > was
> > > created?
> > > >> > Were they VSDB files or MET output files.
> > > >> >
> > > >> > Thanks,
> > > >> > John
> > > >> >
> > > >> > On Tue, Jul 26, 2016 at 9:40 AM, Benjamin Blake - NOAA
> > > >> > Affiliate via
> > > RT
> > > >> <
> > > >> > met_help at ucar.edu> wrote:
> > > >> >
> > > >> >>
> > > >> >> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291
> > > >> >> >
> > > >> >>
> > > >> >> Hi John,
> > > >> >>
> > > >> >> I am still trying to figure out what the issue could be.
I
> > verified
> > > >> with
> > > >> >> the NCEP instance of METViewer that it is indeed plotting
> > > >> >> valid
> > hour.
> > > >> >> Geoff asked Curtis Alexander (who made the original bias
> > > >> >> plots)
> > about
> > > >> the
> > > >> >> values on the x-axis and Curtis confirmed that they were
> > > >> >> plotting
> > > valid
> > > >> >> hour also. The plots I made using MET Viewer still seem
to
> > > >> >> be
> > phase
> > > >> >> shifted by 12 hours. The largest ME should be in the late
> > > >> afternoon/early
> > > >> >> evening, so around 0z, and not in the early morning (12-
15z).
> > > >> >>
> > > >> >> Could the issue have something to do with the way MET is
> > > >> >> reading in
> > > the
> > > >> >> database files?
> > > >> >> I've attached a xml file that looks at the HRRR vs. HRRRx
> > > >> >> surface
> > > >> >> temperature ME (as a function of valid hour) for all 12-hr
> > forecasts
> > > >> for
> > > >> >> all cycles on 7/20/16 over the eastern US. Perhaps you
could
> > > >> >> load
> > it
> > > >> into
> > > >> >> the NCEP version of METViewer and let me know if you have
any
> > > >> >> idea
> > > what
> > > >> >> could be happening?
> > > >> >>
> > > >> >> Thanks again for your help on this!
> > > >> >>
> > > >> >> Ben
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> On Mon, Jul 25, 2016 at 1:05 PM, Benjamin Blake - NOAA
> > > >> >> Affiliate <
> > > >> >> benjamin.blake at noaa.gov> wrote:
> > > >> >>
> > > >> >> > Hi John,
> > > >> >> >
> > > >> >> > I loaded the xml file you sent and I see that the
> > > >> >> > valid_hour
> > > contents
> > > >> >> are
> > > >> >> > indeed consistent with the valid times and not the init
> > > >> >> > times.
> > > Thank
> > > >> >> you
> > > >> >> > for sending that.
> > > >> >> >
> > > >> >> > Once I am able to load my xml file into the EMC version
of
> > > METViewer
> > > >> I
> > > >> >> > will look at the R data tab and make sure it is plotting
> > > >> >> > valid
> > > hour.
> > > >> It
> > > >> >> is
> > > >> >> > taking a while to load at the moment, which I'm guessing
is
> > likely
> > > >> >> because
> > > >> >> > you said that Tatiana is currently updating it.
> > > >> >> >
> > > >> >> > If it is correctly plotting valid hour then I will talk
to
> > > >> >> > Geoff
> > > and
> > > >> see
> > > >> >> > if we can understand what is going on.
> > > >> >> >
> > > >> >> > Thank you for your help and I'll let you know if I am
> > > >> >> > unable to
> > > >> resolve
> > > >> >> > the discrepancy.
> > > >> >> > Ben
> > > >> >> >
> > > >> >> > On Mon, Jul 25, 2016 at 12:35 PM, John Halley Gotway via
RT
> > > >> >> > <
> > > >> >> > met_help at ucar.edu> wrote:
> > > >> >> >
> > > >> >> >> Ben,
> > > >> >> >>
> > > >> >> >> I see that you have a question about how METViewer is
> > > >> >> computing/plotting
> > > >> >> >> the init_hour and valid_hour variables. Thanks for
> > > >> >> >> sending the
> > > >> >> images. I
> > > >> >> >> understand and see the discrepancy you're describing.
> > > >> >> >>
> > > >> >> >> I ran some tests on a small subset of data but am not
able
> > > >> >> >> to
> > > >> reproduce
> > > >> >> >> the
> > > >> >> >> behavior you're describing. I've attached a plot and
xml
> > > >> >> >> to
> > show
> > > >> you
> > > >> >> what
> > > >> >> >> I'm seeing.
> > > >> >> >>
> > > >> >> >> You could try the following:
> > > >> >> >> (1) Save the attached xml to your local machine.
> > > >> >> >> (2) Go to...
> > http://www.dtcenter.org/met/metviewer/metviewer1.jsp
> > > >> >> >> (3) Click "Load XML" in the top-right corner, navigate
to
> > attached
> > > >> xml
> > > >> >> >> file, and click "OK".
> > > >> >> >> (4) Click "Generate Plot" to make the image.
> > > >> >> >> (5) Once the plot is finished, click on the "R Data"
tab
> > > >> >> >> in the
> > > plot
> > > >> >> >> window.
> > > >> >> >> (6) Inspect the columns of data and note that the
contents
> > > >> >> >> of
> > > >> >> valid_hour
> > > >> >> >> (i.e. the column just before DPT) really are consistent
> > > >> >> >> with the
> > > >> valid
> > > >> >> >> times, not the init times.
> > > >> >> >>
> > > >> >> >> So I don't see an obvious problem in METViewer at this
> > > >> >> >> point.
> > > >> >> >>
> > > >> >> >> The next thing I'd check it how Geoff created the
images
> > > >> >> >> you're
> > > >> >> comparing
> > > >> >> >> against. It's certainly possible that he either
> > > >> >> >> inadvertently
> > or
> > > >> >> >> intentionally plotted against init_hour instead of
> > > >> >> >> valid_hour.
> > > >> >> >>
> > > >> >> >> FYI, Tatiana is in the process of updating the version
of
> > > METViewer
> > > >> >> >> running
> > > >> >> >> at EMC. This typically only takes about 10 minutes,
but
> > > >> >> >> for the
> > > >> large
> > > >> >> >> databases there it's taking much longer.
> > > >> >> >>
> > > >> >> >> Please let me know if there's anything else I can do to
> > > >> >> >> help you
> > > >> debug
> > > >> >> >> this
> > > >> >> >> issue.
> > > >> >> >>
> > > >> >> >> Thanks,
> > > >> >> >> John Halley Gotway
> > > >> >> >>
> > > >> >> >>
> > > >> >> >> On Fri, Jul 22, 2016 at 10:48 AM, Benjamin Blake - NOAA
> > Affiliate
> > > >> via
> > > >> >> RT <
> > > >> >> >> met_help at ucar.edu> wrote:
> > > >> >> >>
> > > >> >> >> >
> > > >> >> >> > Fri Jul 22 10:48:03 2016: Request 77291 was acted
upon.
> > > >> >> >> > Transaction: Ticket created by
benjamin.blake at noaa.gov
> > > >> >> >> > Queue: met_help
> > > >> >> >> > Subject: Valid Hour vs. Init Hour - Possible
Issue
> > > >> >> >> > Owner: Nobody
> > > >> >> >> > Requestors: benjamin.blake at noaa.gov
> > > >> >> >> > Status: new
> > > >> >> >> > Ticket <URL:
> > > >> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
> > > >> >> >> >
> > > >> >> >> >
> > > >> >> >> > Hi,
> > > >> >> >> >
> > > >> >> >> > I am using MET Viewer to look into bias (ME) and
BCRMSE
> > > >> >> >> > for
> > the
> > > >> HRRR
> > > >> >> and
> > > >> >> >> > HRRRx, as a function of valid hour, to investigate
the
> > > >> >> >> > effects
> > > of
> > > >> the
> > > >> >> >> > diurnal cycle.
> > > >> >> >> >
> > > >> >> >> > I could be wrong but I think MET is plotting
> > > >> >> >> > initialization
> > hour
> > > >> as
> > > >> >> >> valid
> > > >> >> >> > hour and valid hour as initialization hour. Compare
the
> > > >> >> >> > two
> > > >> surface
> > > >> >> dew
> > > >> >> >> > point plots, one using initialization hour as the
> > > >> >> >> > independent
> > > >> >> variable
> > > >> >> >> and
> > > >> >> >> > the other using valid hour, with slide 29 of Geoff
> > > >> >> >> > Manikin's
> > MEG
> > > >> >> >> > presentation (attached).
> > > >> >> >> >
> > > >> >> >> > The plots for initialization hour seem to match quite
> > > >> >> >> > closely
> > to
> > > >> the
> > > >> >> >> valid
> > > >> >> >> > hour plots on slide 29 (provided by GSD), especially
for
> > > >> >> >> > the
> > > >> >> operational
> > > >> >> >> > HRRR, whereas the plots for valid hour are phase
shifted
> > > >> >> >> > by 12
> > > >> hours.
> > > >> >> >> I'm
> > > >> >> >> > definitely plotting over the correct region (East US)
> > > >> >> >> > and I'm
> > > >> using
> > > >> >> all
> > > >> >> >> > 12-hr forecasts (lead time is fixed at 12 hours) over
> > > >> >> >> > the same
> > > >> time
> > > >> >> >> period
> > > >> >> >> > as GSD.
> > > >> >> >> >
> > > >> >> >> > Thank you!
> > > >> >> >> > Ben Blake (EMC)
> > > >> >> >> >
> > > >> >> >> >
> > > >> >> >>
> > > >> >> >>
> > > >> >> >
> > > >> >>
> > > >> >>
> > > >> >
> > > >>
> > > >>
> > > >
> > >
> > >
> >
> >
------------------------------------------------
Subject: Valid Hour vs. Init Hour - Possible Issue
From: Jacob Carley - NOAA Affiliate
Time: Wed Jul 27 17:36:12 2016
Hi Tatiana,
Great!
It might be best to ask Perry (cc'd)
Perry: When is the best time for Tatiana to fix the database and patch
the
MET Viewer software?
Thanks!
Jacob
On Wed, Jul 27, 2016 at 5:29 PM, Tatiana Burek via RT
<met_help at ucar.edu>
wrote:
> Hi all,
>
> I have a script that would fix existing databases and a patch for
the
> loading module ready.
> When is the best time to update the software?
>
> Tatiana
>
> On Tue Jul 26 13:52:41 2016, benjamin.blake at noaa.gov wrote:
> > Hi John,
> >
> > Sounds great! Thanks again for looking into this.
> > And thanks Jacob and Perry for confirming.
> >
> > Ben
> >
> > On Tue, Jul 26, 2016 at 3:09 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Hi all,
> > >
> > > Looks like the documentation is something we generated
ourselves.
> > > Looking
> > > back through email, I see that Binbin sent us VSDB header info
back
> > > in
> > > October 2014 which listed that column as "run time". We made
the
> > > mistake
> > > of interpreting it as the initialization time.
> > >
> > > Sorry for all of this confusion, but thanks Ben for tracking it
down!
> > >
> > > The good news is that the fix is pretty straightforward...
> > >
> > > (1) Patch the METViewer VSDB loading logic to correctly
interpret
> > > column 4
> > > as the valid time. Deploy the updated logic in a new version of
> > > METViewer.
> > >
> > > (2) Update the existing databases by subtracting the lead time
from
> > > the
> > > initialization and valid times.
> > >
> > > Here's the old (incorrect) logic:
> > > Init = column 4
> > > Lead = column 3
> > > Valid = column 4 + column 3
> > >
> > > The correct logic should be:
> > > Init = column 4 - column 3
> > > Lead = column 3
> > > Valid = column 4
> > >
> > > Subtracting the lead time (i.e. column 3) from both the the init
and
> > > valid
> > > times should correct the existing databases.
> > >
> > > But I'll leave it to Tatiana to estimate how long these patches
will
> > > take.
> > >
> > > Thanks,
> > > John
> > >
> > > On Tue, Jul 26, 2016 at 11:38 AM, perry.shafran at noaa.gov via RT
<
> > > met_help at ucar.edu> wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291
>
> > > >
> > > > Hi, all,
> > > >
> > > > Column 4 is the VALID time. I suppose it was possible that
> > > > confusion by
> > > me
> > > > led to this being interpreted as the initial time, but indeed
> > > > column 4 is
> > > > the valid time.
> > > >
> > > > Perry
> > > >
> > > > On Tue, Jul 26, 2016 at 1:30 PM, Jacob Carley - NOAA Affiliate
<
> > > > jacob.carley at noaa.gov> wrote:
> > > >
> > > > > Hi John,
> > > > >
> > > > > I just took a look at our (EMC's) most recent vsdb files and
saw
> > > > > a date
> > > > of
> > > > > 2016072500 in column 4. Furthermore, it also showed
verification
> > > > > out
> > > to
> > > > > forecast hours 40+. Given that today is 07/26, this makes
me
> > > > > almost
> > > > > certain that column 4 is the valid time - not the
initialization
> > > > > time.
> > > > As
> > > > > you mentioned, this would explain the odd behavior Ben is
seeing
> > > > > in his
> > > > MET
> > > > > Viewer output.
> > > > >
> > > > > I've cc'd Perry to confirm.
> > > > >
> > > > > How quickly might we be able get this addressed? This will
> > > > > certainly
> > > > > impact our verification stats generated from MET Viewer with
our
> > > > > vsdb
> > > > files.
> > > > >
> > > > > Thanks!
> > > > > Jacob
> > > > >
> > > > > On Tue, Jul 26, 2016 at 1:05 PM, John Halley Gotway via RT <
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > >> Ben,
> > > > >>
> > > > >> Well, I did a visual inspection of the METViewer VSDB
loading
> > > > >> logic.
> > > > I've
> > > > >> attached a sample VSDB file, and I think it all comes down
to
> > > > >> the
> > > > >> interpretation of column 4.
> > > > >>
> > > > >> Column 3 obviously contains the lead time in hours. Column
4 is
> > > > >> in
> > > > >> YYYYMMDDHH format and METViewer interprets this as the
forecast
> > > > >> initialization time. If columns 4 actually contains the
valid
> > > > >> time
> > > > >> instead, that would explain the behavior you're describing.
> > > > >>
> > > > >> However Tatiana and I checked the documentation we received
> > > > >> about the
> > > > VSDB
> > > > >> file format as the 4th column is listed as "init
date/time".
> > > > >>
> > > > >> I do have some doubts about all this tough based on
previous
> > > > conversations
> > > > >> with Perry Shafran. The VSDB processing logic uses to the
> > > > >> "newest"
> > > > >> observations to verify (for example) the current 0-hour
> > > > >> forecast, the
> > > > >> 6-hour forecast from 6 hours ago, the 12-hour from 12 hours
> > > > >> ago... and
> > > > so
> > > > >> on. In this logic, the valid time remains constant while
the
> > > > >> lead
> > > time
> > > > >> changes. Looking in the attached VSDB file, I see that
column 4
> > > remains
> > > > >> fixed while the lead times in column 3 change quickly.
> > > > >>
> > > > >> So really this could go either way. The documentation
suggests
> > > > >> that
> > > > >> column
> > > > >> 4 is the init time, but the processing logic suggests that
it
> > > > >> would be
> > > > the
> > > > >> valid time.
> > > > >>
> > > > >> You could ask Perry to verify the interpretation of column
4.
> > > > >>
> > > > >> John
> > > > >>
> > > > >>
> > > > >> On Tue, Jul 26, 2016 at 10:38 AM, John Halley Gotway
> > > > >> <johnhg at ucar.edu
> > > >
> > > > >> wrote:
> > > > >>
> > > > >> > Ben,
> > > > >> >
> > > > >> > My access to NCEP VPN isn't working, so I'm not able to
test
> > > > >> > out
> > > that
> > > > >> XML
> > > > >> > directly. However, another possibility occurred to me.
> > > > >> > METViewer
> > > can
> > > > >> be
> > > > >> > loaded with data directly from MET or with VSDB files
> > > > >> > generated with
> > > > the
> > > > >> > NCEP Vx package. Both of those pathways read data from
flat
> > > > >> > files
> > > and
> > > > >> > store them in the database.
> > > > >> >
> > > > >> > The testing I did only covered the "MET" pathway, not the
> > > > >> > "VSDB"
> > > one.
> > > > >> > It's possible that when reading VSDB data, METViewer is
> > > > >> > storing init
> > > > >> times
> > > > >> > as valid times or vice versa.
> > > > >> >
> > > > >> > Do you know how the HRRR data you're plotting via
METViewer
> > > > >> > was
> > > > created?
> > > > >> > Were they VSDB files or MET output files.
> > > > >> >
> > > > >> > Thanks,
> > > > >> > John
> > > > >> >
> > > > >> > On Tue, Jul 26, 2016 at 9:40 AM, Benjamin Blake - NOAA
> > > > >> > Affiliate via
> > > > RT
> > > > >> <
> > > > >> > met_help at ucar.edu> wrote:
> > > > >> >
> > > > >> >>
> > > > >> >> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291
> > > > >> >> >
> > > > >> >>
> > > > >> >> Hi John,
> > > > >> >>
> > > > >> >> I am still trying to figure out what the issue could be.
I
> > > verified
> > > > >> with
> > > > >> >> the NCEP instance of METViewer that it is indeed
plotting
> > > > >> >> valid
> > > hour.
> > > > >> >> Geoff asked Curtis Alexander (who made the original bias
> > > > >> >> plots)
> > > about
> > > > >> the
> > > > >> >> values on the x-axis and Curtis confirmed that they were
> > > > >> >> plotting
> > > > valid
> > > > >> >> hour also. The plots I made using MET Viewer still seem
to
> > > > >> >> be
> > > phase
> > > > >> >> shifted by 12 hours. The largest ME should be in the
late
> > > > >> afternoon/early
> > > > >> >> evening, so around 0z, and not in the early morning (12-
15z).
> > > > >> >>
> > > > >> >> Could the issue have something to do with the way MET is
> > > > >> >> reading in
> > > > the
> > > > >> >> database files?
> > > > >> >> I've attached a xml file that looks at the HRRR vs.
HRRRx
> > > > >> >> surface
> > > > >> >> temperature ME (as a function of valid hour) for all 12-
hr
> > > forecasts
> > > > >> for
> > > > >> >> all cycles on 7/20/16 over the eastern US. Perhaps you
could
> > > > >> >> load
> > > it
> > > > >> into
> > > > >> >> the NCEP version of METViewer and let me know if you
have any
> > > > >> >> idea
> > > > what
> > > > >> >> could be happening?
> > > > >> >>
> > > > >> >> Thanks again for your help on this!
> > > > >> >>
> > > > >> >> Ben
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >> On Mon, Jul 25, 2016 at 1:05 PM, Benjamin Blake - NOAA
> > > > >> >> Affiliate <
> > > > >> >> benjamin.blake at noaa.gov> wrote:
> > > > >> >>
> > > > >> >> > Hi John,
> > > > >> >> >
> > > > >> >> > I loaded the xml file you sent and I see that the
> > > > >> >> > valid_hour
> > > > contents
> > > > >> >> are
> > > > >> >> > indeed consistent with the valid times and not the
init
> > > > >> >> > times.
> > > > Thank
> > > > >> >> you
> > > > >> >> > for sending that.
> > > > >> >> >
> > > > >> >> > Once I am able to load my xml file into the EMC
version of
> > > > METViewer
> > > > >> I
> > > > >> >> > will look at the R data tab and make sure it is
plotting
> > > > >> >> > valid
> > > > hour.
> > > > >> It
> > > > >> >> is
> > > > >> >> > taking a while to load at the moment, which I'm
guessing is
> > > likely
> > > > >> >> because
> > > > >> >> > you said that Tatiana is currently updating it.
> > > > >> >> >
> > > > >> >> > If it is correctly plotting valid hour then I will
talk to
> > > > >> >> > Geoff
> > > > and
> > > > >> see
> > > > >> >> > if we can understand what is going on.
> > > > >> >> >
> > > > >> >> > Thank you for your help and I'll let you know if I am
> > > > >> >> > unable to
> > > > >> resolve
> > > > >> >> > the discrepancy.
> > > > >> >> > Ben
> > > > >> >> >
> > > > >> >> > On Mon, Jul 25, 2016 at 12:35 PM, John Halley Gotway
via RT
> > > > >> >> > <
> > > > >> >> > met_help at ucar.edu> wrote:
> > > > >> >> >
> > > > >> >> >> Ben,
> > > > >> >> >>
> > > > >> >> >> I see that you have a question about how METViewer is
> > > > >> >> computing/plotting
> > > > >> >> >> the init_hour and valid_hour variables. Thanks for
> > > > >> >> >> sending the
> > > > >> >> images. I
> > > > >> >> >> understand and see the discrepancy you're describing.
> > > > >> >> >>
> > > > >> >> >> I ran some tests on a small subset of data but am not
able
> > > > >> >> >> to
> > > > >> reproduce
> > > > >> >> >> the
> > > > >> >> >> behavior you're describing. I've attached a plot and
xml
> > > > >> >> >> to
> > > show
> > > > >> you
> > > > >> >> what
> > > > >> >> >> I'm seeing.
> > > > >> >> >>
> > > > >> >> >> You could try the following:
> > > > >> >> >> (1) Save the attached xml to your local machine.
> > > > >> >> >> (2) Go to...
> > > http://www.dtcenter.org/met/metviewer/metviewer1.jsp
> > > > >> >> >> (3) Click "Load XML" in the top-right corner,
navigate to
> > > attached
> > > > >> xml
> > > > >> >> >> file, and click "OK".
> > > > >> >> >> (4) Click "Generate Plot" to make the image.
> > > > >> >> >> (5) Once the plot is finished, click on the "R Data"
tab
> > > > >> >> >> in the
> > > > plot
> > > > >> >> >> window.
> > > > >> >> >> (6) Inspect the columns of data and note that the
contents
> > > > >> >> >> of
> > > > >> >> valid_hour
> > > > >> >> >> (i.e. the column just before DPT) really are
consistent
> > > > >> >> >> with the
> > > > >> valid
> > > > >> >> >> times, not the init times.
> > > > >> >> >>
> > > > >> >> >> So I don't see an obvious problem in METViewer at
this
> > > > >> >> >> point.
> > > > >> >> >>
> > > > >> >> >> The next thing I'd check it how Geoff created the
images
> > > > >> >> >> you're
> > > > >> >> comparing
> > > > >> >> >> against. It's certainly possible that he either
> > > > >> >> >> inadvertently
> > > or
> > > > >> >> >> intentionally plotted against init_hour instead of
> > > > >> >> >> valid_hour.
> > > > >> >> >>
> > > > >> >> >> FYI, Tatiana is in the process of updating the
version of
> > > > METViewer
> > > > >> >> >> running
> > > > >> >> >> at EMC. This typically only takes about 10 minutes,
but
> > > > >> >> >> for the
> > > > >> large
> > > > >> >> >> databases there it's taking much longer.
> > > > >> >> >>
> > > > >> >> >> Please let me know if there's anything else I can do
to
> > > > >> >> >> help you
> > > > >> debug
> > > > >> >> >> this
> > > > >> >> >> issue.
> > > > >> >> >>
> > > > >> >> >> Thanks,
> > > > >> >> >> John Halley Gotway
> > > > >> >> >>
> > > > >> >> >>
> > > > >> >> >> On Fri, Jul 22, 2016 at 10:48 AM, Benjamin Blake -
NOAA
> > > Affiliate
> > > > >> via
> > > > >> >> RT <
> > > > >> >> >> met_help at ucar.edu> wrote:
> > > > >> >> >>
> > > > >> >> >> >
> > > > >> >> >> > Fri Jul 22 10:48:03 2016: Request 77291 was acted
upon.
> > > > >> >> >> > Transaction: Ticket created by
benjamin.blake at noaa.gov
> > > > >> >> >> > Queue: met_help
> > > > >> >> >> > Subject: Valid Hour vs. Init Hour - Possible
Issue
> > > > >> >> >> > Owner: Nobody
> > > > >> >> >> > Requestors: benjamin.blake at noaa.gov
> > > > >> >> >> > Status: new
> > > > >> >> >> > Ticket <URL:
> > > > >> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291
>
> > > > >> >> >> >
> > > > >> >> >> >
> > > > >> >> >> > Hi,
> > > > >> >> >> >
> > > > >> >> >> > I am using MET Viewer to look into bias (ME) and
BCRMSE
> > > > >> >> >> > for
> > > the
> > > > >> HRRR
> > > > >> >> and
> > > > >> >> >> > HRRRx, as a function of valid hour, to investigate
the
> > > > >> >> >> > effects
> > > > of
> > > > >> the
> > > > >> >> >> > diurnal cycle.
> > > > >> >> >> >
> > > > >> >> >> > I could be wrong but I think MET is plotting
> > > > >> >> >> > initialization
> > > hour
> > > > >> as
> > > > >> >> >> valid
> > > > >> >> >> > hour and valid hour as initialization hour.
Compare the
> > > > >> >> >> > two
> > > > >> surface
> > > > >> >> dew
> > > > >> >> >> > point plots, one using initialization hour as the
> > > > >> >> >> > independent
> > > > >> >> variable
> > > > >> >> >> and
> > > > >> >> >> > the other using valid hour, with slide 29 of Geoff
> > > > >> >> >> > Manikin's
> > > MEG
> > > > >> >> >> > presentation (attached).
> > > > >> >> >> >
> > > > >> >> >> > The plots for initialization hour seem to match
quite
> > > > >> >> >> > closely
> > > to
> > > > >> the
> > > > >> >> >> valid
> > > > >> >> >> > hour plots on slide 29 (provided by GSD),
especially for
> > > > >> >> >> > the
> > > > >> >> operational
> > > > >> >> >> > HRRR, whereas the plots for valid hour are phase
shifted
> > > > >> >> >> > by 12
> > > > >> hours.
> > > > >> >> >> I'm
> > > > >> >> >> > definitely plotting over the correct region (East
US)
> > > > >> >> >> > and I'm
> > > > >> using
> > > > >> >> all
> > > > >> >> >> > 12-hr forecasts (lead time is fixed at 12 hours)
over
> > > > >> >> >> > the same
> > > > >> time
> > > > >> >> >> period
> > > > >> >> >> > as GSD.
> > > > >> >> >> >
> > > > >> >> >> > Thank you!
> > > > >> >> >> > Ben Blake (EMC)
> > > > >> >> >> >
> > > > >> >> >> >
> > > > >> >> >>
> > > > >> >> >>
> > > > >> >> >
> > > > >> >>
> > > > >> >>
> > > > >> >
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > >
> > >
>
>
>
>
------------------------------------------------
Subject: Valid Hour vs. Init Hour - Possible Issue
From: perry.shafran at noaa.gov
Time: Thu Jul 28 06:31:59 2016
Hi, Tatiana,
I'm not sure when the best time is to update the software. How long
would
this process take? I think the sooner the better.
Perry
On Wed, Jul 27, 2016 at 7:36 PM, Jacob Carley - NOAA Affiliate <
jacob.carley at noaa.gov> wrote:
> Hi Tatiana,
>
> Great!
>
> It might be best to ask Perry (cc'd)
>
> Perry: When is the best time for Tatiana to fix the database and
patch the
> MET Viewer software?
>
> Thanks!
> Jacob
>
> On Wed, Jul 27, 2016 at 5:29 PM, Tatiana Burek via RT
<met_help at ucar.edu>
> wrote:
>
>> Hi all,
>>
>> I have a script that would fix existing databases and a patch for
the
>> loading module ready.
>> When is the best time to update the software?
>>
>> Tatiana
>>
>> On Tue Jul 26 13:52:41 2016, benjamin.blake at noaa.gov wrote:
>> > Hi John,
>> >
>> > Sounds great! Thanks again for looking into this.
>> > And thanks Jacob and Perry for confirming.
>> >
>> > Ben
>> >
>> > On Tue, Jul 26, 2016 at 3:09 PM, John Halley Gotway via RT <
>> > met_help at ucar.edu> wrote:
>> >
>> > > Hi all,
>> > >
>> > > Looks like the documentation is something we generated
ourselves.
>> > > Looking
>> > > back through email, I see that Binbin sent us VSDB header info
back
>> > > in
>> > > October 2014 which listed that column as "run time". We made
the
>> > > mistake
>> > > of interpreting it as the initialization time.
>> > >
>> > > Sorry for all of this confusion, but thanks Ben for tracking it
down!
>> > >
>> > > The good news is that the fix is pretty straightforward...
>> > >
>> > > (1) Patch the METViewer VSDB loading logic to correctly
interpret
>> > > column 4
>> > > as the valid time. Deploy the updated logic in a new version
of
>> > > METViewer.
>> > >
>> > > (2) Update the existing databases by subtracting the lead time
from
>> > > the
>> > > initialization and valid times.
>> > >
>> > > Here's the old (incorrect) logic:
>> > > Init = column 4
>> > > Lead = column 3
>> > > Valid = column 4 + column 3
>> > >
>> > > The correct logic should be:
>> > > Init = column 4 - column 3
>> > > Lead = column 3
>> > > Valid = column 4
>> > >
>> > > Subtracting the lead time (i.e. column 3) from both the the
init and
>> > > valid
>> > > times should correct the existing databases.
>> > >
>> > > But I'll leave it to Tatiana to estimate how long these patches
will
>> > > take.
>> > >
>> > > Thanks,
>> > > John
>> > >
>> > > On Tue, Jul 26, 2016 at 11:38 AM, perry.shafran at noaa.gov via RT
<
>>
>> > > met_help at ucar.edu> wrote:
>> > >
>> > > >
>> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291
>
>> > > >
>> > > > Hi, all,
>> > > >
>> > > > Column 4 is the VALID time. I suppose it was possible that
>> > > > confusion by
>> > > me
>> > > > led to this being interpreted as the initial time, but indeed
>> > > > column 4 is
>> > > > the valid time.
>> > > >
>> > > > Perry
>> > > >
>> > > > On Tue, Jul 26, 2016 at 1:30 PM, Jacob Carley - NOAA
Affiliate <
>> > > > jacob.carley at noaa.gov> wrote:
>> > > >
>> > > > > Hi John,
>> > > > >
>> > > > > I just took a look at our (EMC's) most recent vsdb files
and saw
>> > > > > a date
>> > > > of
>> > > > > 2016072500 in column 4. Furthermore, it also showed
verification
>> > > > > out
>> > > to
>> > > > > forecast hours 40+. Given that today is 07/26, this makes
me
>> > > > > almost
>> > > > > certain that column 4 is the valid time - not the
initialization
>> > > > > time.
>> > > > As
>> > > > > you mentioned, this would explain the odd behavior Ben is
seeing
>> > > > > in his
>> > > > MET
>> > > > > Viewer output.
>> > > > >
>> > > > > I've cc'd Perry to confirm.
>> > > > >
>> > > > > How quickly might we be able get this addressed? This will
>> > > > > certainly
>> > > > > impact our verification stats generated from MET Viewer
with our
>> > > > > vsdb
>> > > > files.
>> > > > >
>> > > > > Thanks!
>> > > > > Jacob
>> > > > >
>> > > > > On Tue, Jul 26, 2016 at 1:05 PM, John Halley Gotway via RT
<
>> > > > > met_help at ucar.edu> wrote:
>> > > > >
>> > > > >> Ben,
>> > > > >>
>> > > > >> Well, I did a visual inspection of the METViewer VSDB
loading
>> > > > >> logic.
>> > > > I've
>> > > > >> attached a sample VSDB file, and I think it all comes down
to
>> > > > >> the
>> > > > >> interpretation of column 4.
>> > > > >>
>> > > > >> Column 3 obviously contains the lead time in hours.
Column 4 is
>> > > > >> in
>> > > > >> YYYYMMDDHH format and METViewer interprets this as the
forecast
>> > > > >> initialization time. If columns 4 actually contains the
valid
>> > > > >> time
>> > > > >> instead, that would explain the behavior you're
describing.
>> > > > >>
>> > > > >> However Tatiana and I checked the documentation we
received
>> > > > >> about the
>> > > > VSDB
>> > > > >> file format as the 4th column is listed as "init
date/time".
>> > > > >>
>> > > > >> I do have some doubts about all this tough based on
previous
>> > > > conversations
>> > > > >> with Perry Shafran. The VSDB processing logic uses to the
>> > > > >> "newest"
>> > > > >> observations to verify (for example) the current 0-hour
>> > > > >> forecast, the
>> > > > >> 6-hour forecast from 6 hours ago, the 12-hour from 12
hours
>> > > > >> ago... and
>> > > > so
>> > > > >> on. In this logic, the valid time remains constant while
the
>> > > > >> lead
>> > > time
>> > > > >> changes. Looking in the attached VSDB file, I see that
column 4
>> > > remains
>> > > > >> fixed while the lead times in column 3 change quickly.
>> > > > >>
>> > > > >> So really this could go either way. The documentation
suggests
>> > > > >> that
>> > > > >> column
>> > > > >> 4 is the init time, but the processing logic suggests that
it
>> > > > >> would be
>> > > > the
>> > > > >> valid time.
>> > > > >>
>> > > > >> You could ask Perry to verify the interpretation of column
4.
>> > > > >>
>> > > > >> John
>> > > > >>
>> > > > >>
>> > > > >> On Tue, Jul 26, 2016 at 10:38 AM, John Halley Gotway
>> > > > >> <johnhg at ucar.edu
>> > > >
>> > > > >> wrote:
>> > > > >>
>> > > > >> > Ben,
>> > > > >> >
>> > > > >> > My access to NCEP VPN isn't working, so I'm not able to
test
>> > > > >> > out
>> > > that
>> > > > >> XML
>> > > > >> > directly. However, another possibility occurred to me.
>> > > > >> > METViewer
>> > > can
>> > > > >> be
>> > > > >> > loaded with data directly from MET or with VSDB files
>> > > > >> > generated with
>> > > > the
>> > > > >> > NCEP Vx package. Both of those pathways read data from
flat
>> > > > >> > files
>> > > and
>> > > > >> > store them in the database.
>> > > > >> >
>> > > > >> > The testing I did only covered the "MET" pathway, not
the
>> > > > >> > "VSDB"
>> > > one.
>> > > > >> > It's possible that when reading VSDB data, METViewer is
>> > > > >> > storing init
>> > > > >> times
>> > > > >> > as valid times or vice versa.
>> > > > >> >
>> > > > >> > Do you know how the HRRR data you're plotting via
METViewer
>> > > > >> > was
>> > > > created?
>> > > > >> > Were they VSDB files or MET output files.
>> > > > >> >
>> > > > >> > Thanks,
>> > > > >> > John
>> > > > >> >
>> > > > >> > On Tue, Jul 26, 2016 at 9:40 AM, Benjamin Blake - NOAA
>> > > > >> > Affiliate via
>> > > > RT
>> > > > >> <
>> > > > >> > met_help at ucar.edu> wrote:
>> > > > >> >
>> > > > >> >>
>> > > > >> >> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291
>> > > > >> >> >
>> > > > >> >>
>> > > > >> >> Hi John,
>> > > > >> >>
>> > > > >> >> I am still trying to figure out what the issue could
be. I
>> > > verified
>> > > > >> with
>> > > > >> >> the NCEP instance of METViewer that it is indeed
plotting
>> > > > >> >> valid
>> > > hour.
>> > > > >> >> Geoff asked Curtis Alexander (who made the original
bias
>> > > > >> >> plots)
>> > > about
>> > > > >> the
>> > > > >> >> values on the x-axis and Curtis confirmed that they
were
>> > > > >> >> plotting
>> > > > valid
>> > > > >> >> hour also. The plots I made using MET Viewer still
seem to
>> > > > >> >> be
>> > > phase
>> > > > >> >> shifted by 12 hours. The largest ME should be in the
late
>> > > > >> afternoon/early
>> > > > >> >> evening, so around 0z, and not in the early morning
(12-15z).
>> > > > >> >>
>> > > > >> >> Could the issue have something to do with the way MET
is
>> > > > >> >> reading in
>> > > > the
>> > > > >> >> database files?
>> > > > >> >> I've attached a xml file that looks at the HRRR vs.
HRRRx
>> > > > >> >> surface
>> > > > >> >> temperature ME (as a function of valid hour) for all
12-hr
>> > > forecasts
>> > > > >> for
>> > > > >> >> all cycles on 7/20/16 over the eastern US. Perhaps you
could
>> > > > >> >> load
>> > > it
>> > > > >> into
>> > > > >> >> the NCEP version of METViewer and let me know if you
have any
>> > > > >> >> idea
>> > > > what
>> > > > >> >> could be happening?
>> > > > >> >>
>> > > > >> >> Thanks again for your help on this!
>> > > > >> >>
>> > > > >> >> Ben
>> > > > >> >>
>> > > > >> >>
>> > > > >> >>
>> > > > >> >> On Mon, Jul 25, 2016 at 1:05 PM, Benjamin Blake - NOAA
>> > > > >> >> Affiliate <
>> > > > >> >> benjamin.blake at noaa.gov> wrote:
>> > > > >> >>
>> > > > >> >> > Hi John,
>> > > > >> >> >
>> > > > >> >> > I loaded the xml file you sent and I see that the
>> > > > >> >> > valid_hour
>> > > > contents
>> > > > >> >> are
>> > > > >> >> > indeed consistent with the valid times and not the
init
>> > > > >> >> > times.
>> > > > Thank
>> > > > >> >> you
>> > > > >> >> > for sending that.
>> > > > >> >> >
>> > > > >> >> > Once I am able to load my xml file into the EMC
version of
>> > > > METViewer
>> > > > >> I
>> > > > >> >> > will look at the R data tab and make sure it is
plotting
>> > > > >> >> > valid
>> > > > hour.
>> > > > >> It
>> > > > >> >> is
>> > > > >> >> > taking a while to load at the moment, which I'm
guessing is
>> > > likely
>> > > > >> >> because
>> > > > >> >> > you said that Tatiana is currently updating it.
>> > > > >> >> >
>> > > > >> >> > If it is correctly plotting valid hour then I will
talk to
>> > > > >> >> > Geoff
>> > > > and
>> > > > >> see
>> > > > >> >> > if we can understand what is going on.
>> > > > >> >> >
>> > > > >> >> > Thank you for your help and I'll let you know if I am
>> > > > >> >> > unable to
>> > > > >> resolve
>> > > > >> >> > the discrepancy.
>> > > > >> >> > Ben
>> > > > >> >> >
>> > > > >> >> > On Mon, Jul 25, 2016 at 12:35 PM, John Halley Gotway
via RT
>> > > > >> >> > <
>> > > > >> >> > met_help at ucar.edu> wrote:
>> > > > >> >> >
>> > > > >> >> >> Ben,
>> > > > >> >> >>
>> > > > >> >> >> I see that you have a question about how METViewer
is
>> > > > >> >> computing/plotting
>> > > > >> >> >> the init_hour and valid_hour variables. Thanks for
>> > > > >> >> >> sending the
>> > > > >> >> images. I
>> > > > >> >> >> understand and see the discrepancy you're
describing.
>> > > > >> >> >>
>> > > > >> >> >> I ran some tests on a small subset of data but am
not able
>> > > > >> >> >> to
>> > > > >> reproduce
>> > > > >> >> >> the
>> > > > >> >> >> behavior you're describing. I've attached a plot
and xml
>> > > > >> >> >> to
>> > > show
>> > > > >> you
>> > > > >> >> what
>> > > > >> >> >> I'm seeing.
>> > > > >> >> >>
>> > > > >> >> >> You could try the following:
>> > > > >> >> >> (1) Save the attached xml to your local machine.
>> > > > >> >> >> (2) Go to...
>> > > http://www.dtcenter.org/met/metviewer/metviewer1.jsp
>> > > > >> >> >> (3) Click "Load XML" in the top-right corner,
navigate to
>> > > attached
>> > > > >> xml
>> > > > >> >> >> file, and click "OK".
>> > > > >> >> >> (4) Click "Generate Plot" to make the image.
>> > > > >> >> >> (5) Once the plot is finished, click on the "R Data"
tab
>> > > > >> >> >> in the
>> > > > plot
>> > > > >> >> >> window.
>> > > > >> >> >> (6) Inspect the columns of data and note that the
contents
>> > > > >> >> >> of
>> > > > >> >> valid_hour
>> > > > >> >> >> (i.e. the column just before DPT) really are
consistent
>> > > > >> >> >> with the
>> > > > >> valid
>> > > > >> >> >> times, not the init times.
>> > > > >> >> >>
>> > > > >> >> >> So I don't see an obvious problem in METViewer at
this
>> > > > >> >> >> point.
>> > > > >> >> >>
>> > > > >> >> >> The next thing I'd check it how Geoff created the
images
>> > > > >> >> >> you're
>> > > > >> >> comparing
>> > > > >> >> >> against. It's certainly possible that he either
>> > > > >> >> >> inadvertently
>> > > or
>> > > > >> >> >> intentionally plotted against init_hour instead of
>> > > > >> >> >> valid_hour.
>> > > > >> >> >>
>> > > > >> >> >> FYI, Tatiana is in the process of updating the
version of
>> > > > METViewer
>> > > > >> >> >> running
>> > > > >> >> >> at EMC. This typically only takes about 10 minutes,
but
>> > > > >> >> >> for the
>> > > > >> large
>> > > > >> >> >> databases there it's taking much longer.
>> > > > >> >> >>
>> > > > >> >> >> Please let me know if there's anything else I can do
to
>> > > > >> >> >> help you
>> > > > >> debug
>> > > > >> >> >> this
>> > > > >> >> >> issue.
>> > > > >> >> >>
>> > > > >> >> >> Thanks,
>> > > > >> >> >> John Halley Gotway
>> > > > >> >> >>
>> > > > >> >> >>
>> > > > >> >> >> On Fri, Jul 22, 2016 at 10:48 AM, Benjamin Blake -
NOAA
>> > > Affiliate
>> > > > >> via
>> > > > >> >> RT <
>> > > > >> >> >> met_help at ucar.edu> wrote:
>> > > > >> >> >>
>> > > > >> >> >> >
>> > > > >> >> >> > Fri Jul 22 10:48:03 2016: Request 77291 was acted
upon.
>> > > > >> >> >> > Transaction: Ticket created by
benjamin.blake at noaa.gov
>> > > > >> >> >> > Queue: met_help
>> > > > >> >> >> > Subject: Valid Hour vs. Init Hour - Possible
Issue
>> > > > >> >> >> > Owner: Nobody
>> > > > >> >> >> > Requestors: benjamin.blake at noaa.gov
>> > > > >> >> >> > Status: new
>> > > > >> >> >> > Ticket <URL:
>> > > > >> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291
>
>> > > > >> >> >> >
>> > > > >> >> >> >
>> > > > >> >> >> > Hi,
>> > > > >> >> >> >
>> > > > >> >> >> > I am using MET Viewer to look into bias (ME) and
BCRMSE
>> > > > >> >> >> > for
>> > > the
>> > > > >> HRRR
>> > > > >> >> and
>> > > > >> >> >> > HRRRx, as a function of valid hour, to investigate
the
>> > > > >> >> >> > effects
>> > > > of
>> > > > >> the
>> > > > >> >> >> > diurnal cycle.
>> > > > >> >> >> >
>> > > > >> >> >> > I could be wrong but I think MET is plotting
>> > > > >> >> >> > initialization
>> > > hour
>> > > > >> as
>> > > > >> >> >> valid
>> > > > >> >> >> > hour and valid hour as initialization hour.
Compare the
>> > > > >> >> >> > two
>> > > > >> surface
>> > > > >> >> dew
>> > > > >> >> >> > point plots, one using initialization hour as the
>> > > > >> >> >> > independent
>> > > > >> >> variable
>> > > > >> >> >> and
>> > > > >> >> >> > the other using valid hour, with slide 29 of Geoff
>> > > > >> >> >> > Manikin's
>> > > MEG
>> > > > >> >> >> > presentation (attached).
>> > > > >> >> >> >
>> > > > >> >> >> > The plots for initialization hour seem to match
quite
>> > > > >> >> >> > closely
>> > > to
>> > > > >> the
>> > > > >> >> >> valid
>> > > > >> >> >> > hour plots on slide 29 (provided by GSD),
especially for
>> > > > >> >> >> > the
>> > > > >> >> operational
>> > > > >> >> >> > HRRR, whereas the plots for valid hour are phase
shifted
>> > > > >> >> >> > by 12
>> > > > >> hours.
>> > > > >> >> >> I'm
>> > > > >> >> >> > definitely plotting over the correct region (East
US)
>> > > > >> >> >> > and I'm
>> > > > >> using
>> > > > >> >> all
>> > > > >> >> >> > 12-hr forecasts (lead time is fixed at 12 hours)
over
>> > > > >> >> >> > the same
>> > > > >> time
>> > > > >> >> >> period
>> > > > >> >> >> > as GSD.
>> > > > >> >> >> >
>> > > > >> >> >> > Thank you!
>> > > > >> >> >> > Ben Blake (EMC)
>> > > > >> >> >> >
>> > > > >> >> >> >
>> > > > >> >> >>
>> > > > >> >> >>
>> > > > >> >> >
>> > > > >> >>
>> > > > >> >>
>> > > > >> >
>> > > > >>
>> > > > >>
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>>
>>
>>
>>
>
------------------------------------------------
Subject: Valid Hour vs. Init Hour - Possible Issue
From: Tatiana Burek
Time: Thu Jul 28 08:09:37 2016
Perry,
Updating the loading module would take me 5-10 min.
But the database update would take much longer. I was testing the
script
using 15GB database. It took ~45 min to finish.
Giving the total size of databases on vm-lnx-metviewdev-process1 I
would
estimate a few hours.
Tatiana
On Thu, Jul 28, 2016 at 6:32 AM, perry.shafran at noaa.gov via RT <
met_help at ucar.edu> wrote:
> Hi, Tatiana,
>
> I'm not sure when the best time is to update the software. How long
would
> this process take? I think the sooner the better.
>
> Perry
>
> On Wed, Jul 27, 2016 at 7:36 PM, Jacob Carley - NOAA Affiliate <
> jacob.carley at noaa.gov> wrote:
>
> > Hi Tatiana,
> >
> > Great!
> >
> > It might be best to ask Perry (cc'd)
> >
> > Perry: When is the best time for Tatiana to fix the database and
patch
> the
> > MET Viewer software?
> >
> > Thanks!
> > Jacob
> >
> > On Wed, Jul 27, 2016 at 5:29 PM, Tatiana Burek via RT
<met_help at ucar.edu
> >
> > wrote:
> >
> >> Hi all,
> >>
> >> I have a script that would fix existing databases and a patch for
the
> >> loading module ready.
> >> When is the best time to update the software?
> >>
> >> Tatiana
> >>
> >> On Tue Jul 26 13:52:41 2016, benjamin.blake at noaa.gov wrote:
> >> > Hi John,
> >> >
> >> > Sounds great! Thanks again for looking into this.
> >> > And thanks Jacob and Perry for confirming.
> >> >
> >> > Ben
> >> >
> >> > On Tue, Jul 26, 2016 at 3:09 PM, John Halley Gotway via RT <
> >> > met_help at ucar.edu> wrote:
> >> >
> >> > > Hi all,
> >> > >
> >> > > Looks like the documentation is something we generated
ourselves.
> >> > > Looking
> >> > > back through email, I see that Binbin sent us VSDB header
info back
> >> > > in
> >> > > October 2014 which listed that column as "run time". We made
the
> >> > > mistake
> >> > > of interpreting it as the initialization time.
> >> > >
> >> > > Sorry for all of this confusion, but thanks Ben for tracking
it
> down!
> >> > >
> >> > > The good news is that the fix is pretty straightforward...
> >> > >
> >> > > (1) Patch the METViewer VSDB loading logic to correctly
interpret
> >> > > column 4
> >> > > as the valid time. Deploy the updated logic in a new version
of
> >> > > METViewer.
> >> > >
> >> > > (2) Update the existing databases by subtracting the lead
time from
> >> > > the
> >> > > initialization and valid times.
> >> > >
> >> > > Here's the old (incorrect) logic:
> >> > > Init = column 4
> >> > > Lead = column 3
> >> > > Valid = column 4 + column 3
> >> > >
> >> > > The correct logic should be:
> >> > > Init = column 4 - column 3
> >> > > Lead = column 3
> >> > > Valid = column 4
> >> > >
> >> > > Subtracting the lead time (i.e. column 3) from both the the
init and
> >> > > valid
> >> > > times should correct the existing databases.
> >> > >
> >> > > But I'll leave it to Tatiana to estimate how long these
patches will
> >> > > take.
> >> > >
> >> > > Thanks,
> >> > > John
> >> > >
> >> > > On Tue, Jul 26, 2016 at 11:38 AM, perry.shafran at noaa.gov via
RT <
> >>
> >> > > met_help at ucar.edu> wrote:
> >> > >
> >> > > >
> >> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
> >> > > >
> >> > > > Hi, all,
> >> > > >
> >> > > > Column 4 is the VALID time. I suppose it was possible that
> >> > > > confusion by
> >> > > me
> >> > > > led to this being interpreted as the initial time, but
indeed
> >> > > > column 4 is
> >> > > > the valid time.
> >> > > >
> >> > > > Perry
> >> > > >
> >> > > > On Tue, Jul 26, 2016 at 1:30 PM, Jacob Carley - NOAA
Affiliate <
> >> > > > jacob.carley at noaa.gov> wrote:
> >> > > >
> >> > > > > Hi John,
> >> > > > >
> >> > > > > I just took a look at our (EMC's) most recent vsdb files
and saw
> >> > > > > a date
> >> > > > of
> >> > > > > 2016072500 in column 4. Furthermore, it also showed
> verification
> >> > > > > out
> >> > > to
> >> > > > > forecast hours 40+. Given that today is 07/26, this
makes me
> >> > > > > almost
> >> > > > > certain that column 4 is the valid time - not the
initialization
> >> > > > > time.
> >> > > > As
> >> > > > > you mentioned, this would explain the odd behavior Ben is
seeing
> >> > > > > in his
> >> > > > MET
> >> > > > > Viewer output.
> >> > > > >
> >> > > > > I've cc'd Perry to confirm.
> >> > > > >
> >> > > > > How quickly might we be able get this addressed? This
will
> >> > > > > certainly
> >> > > > > impact our verification stats generated from MET Viewer
with our
> >> > > > > vsdb
> >> > > > files.
> >> > > > >
> >> > > > > Thanks!
> >> > > > > Jacob
> >> > > > >
> >> > > > > On Tue, Jul 26, 2016 at 1:05 PM, John Halley Gotway via
RT <
> >> > > > > met_help at ucar.edu> wrote:
> >> > > > >
> >> > > > >> Ben,
> >> > > > >>
> >> > > > >> Well, I did a visual inspection of the METViewer VSDB
loading
> >> > > > >> logic.
> >> > > > I've
> >> > > > >> attached a sample VSDB file, and I think it all comes
down to
> >> > > > >> the
> >> > > > >> interpretation of column 4.
> >> > > > >>
> >> > > > >> Column 3 obviously contains the lead time in hours.
Column 4
> is
> >> > > > >> in
> >> > > > >> YYYYMMDDHH format and METViewer interprets this as the
forecast
> >> > > > >> initialization time. If columns 4 actually contains the
valid
> >> > > > >> time
> >> > > > >> instead, that would explain the behavior you're
describing.
> >> > > > >>
> >> > > > >> However Tatiana and I checked the documentation we
received
> >> > > > >> about the
> >> > > > VSDB
> >> > > > >> file format as the 4th column is listed as "init
date/time".
> >> > > > >>
> >> > > > >> I do have some doubts about all this tough based on
previous
> >> > > > conversations
> >> > > > >> with Perry Shafran. The VSDB processing logic uses to
the
> >> > > > >> "newest"
> >> > > > >> observations to verify (for example) the current 0-hour
> >> > > > >> forecast, the
> >> > > > >> 6-hour forecast from 6 hours ago, the 12-hour from 12
hours
> >> > > > >> ago... and
> >> > > > so
> >> > > > >> on. In this logic, the valid time remains constant
while the
> >> > > > >> lead
> >> > > time
> >> > > > >> changes. Looking in the attached VSDB file, I see that
column
> 4
> >> > > remains
> >> > > > >> fixed while the lead times in column 3 change quickly.
> >> > > > >>
> >> > > > >> So really this could go either way. The documentation
suggests
> >> > > > >> that
> >> > > > >> column
> >> > > > >> 4 is the init time, but the processing logic suggests
that it
> >> > > > >> would be
> >> > > > the
> >> > > > >> valid time.
> >> > > > >>
> >> > > > >> You could ask Perry to verify the interpretation of
column 4.
> >> > > > >>
> >> > > > >> John
> >> > > > >>
> >> > > > >>
> >> > > > >> On Tue, Jul 26, 2016 at 10:38 AM, John Halley Gotway
> >> > > > >> <johnhg at ucar.edu
> >> > > >
> >> > > > >> wrote:
> >> > > > >>
> >> > > > >> > Ben,
> >> > > > >> >
> >> > > > >> > My access to NCEP VPN isn't working, so I'm not able
to test
> >> > > > >> > out
> >> > > that
> >> > > > >> XML
> >> > > > >> > directly. However, another possibility occurred to
me.
> >> > > > >> > METViewer
> >> > > can
> >> > > > >> be
> >> > > > >> > loaded with data directly from MET or with VSDB files
> >> > > > >> > generated with
> >> > > > the
> >> > > > >> > NCEP Vx package. Both of those pathways read data
from flat
> >> > > > >> > files
> >> > > and
> >> > > > >> > store them in the database.
> >> > > > >> >
> >> > > > >> > The testing I did only covered the "MET" pathway, not
the
> >> > > > >> > "VSDB"
> >> > > one.
> >> > > > >> > It's possible that when reading VSDB data, METViewer
is
> >> > > > >> > storing init
> >> > > > >> times
> >> > > > >> > as valid times or vice versa.
> >> > > > >> >
> >> > > > >> > Do you know how the HRRR data you're plotting via
METViewer
> >> > > > >> > was
> >> > > > created?
> >> > > > >> > Were they VSDB files or MET output files.
> >> > > > >> >
> >> > > > >> > Thanks,
> >> > > > >> > John
> >> > > > >> >
> >> > > > >> > On Tue, Jul 26, 2016 at 9:40 AM, Benjamin Blake - NOAA
> >> > > > >> > Affiliate via
> >> > > > RT
> >> > > > >> <
> >> > > > >> > met_help at ucar.edu> wrote:
> >> > > > >> >
> >> > > > >> >>
> >> > > > >> >> <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291
> >> > > > >> >> >
> >> > > > >> >>
> >> > > > >> >> Hi John,
> >> > > > >> >>
> >> > > > >> >> I am still trying to figure out what the issue could
be. I
> >> > > verified
> >> > > > >> with
> >> > > > >> >> the NCEP instance of METViewer that it is indeed
plotting
> >> > > > >> >> valid
> >> > > hour.
> >> > > > >> >> Geoff asked Curtis Alexander (who made the original
bias
> >> > > > >> >> plots)
> >> > > about
> >> > > > >> the
> >> > > > >> >> values on the x-axis and Curtis confirmed that they
were
> >> > > > >> >> plotting
> >> > > > valid
> >> > > > >> >> hour also. The plots I made using MET Viewer still
seem to
> >> > > > >> >> be
> >> > > phase
> >> > > > >> >> shifted by 12 hours. The largest ME should be in the
late
> >> > > > >> afternoon/early
> >> > > > >> >> evening, so around 0z, and not in the early morning
> (12-15z).
> >> > > > >> >>
> >> > > > >> >> Could the issue have something to do with the way MET
is
> >> > > > >> >> reading in
> >> > > > the
> >> > > > >> >> database files?
> >> > > > >> >> I've attached a xml file that looks at the HRRR vs.
HRRRx
> >> > > > >> >> surface
> >> > > > >> >> temperature ME (as a function of valid hour) for all
12-hr
> >> > > forecasts
> >> > > > >> for
> >> > > > >> >> all cycles on 7/20/16 over the eastern US. Perhaps
you
> could
> >> > > > >> >> load
> >> > > it
> >> > > > >> into
> >> > > > >> >> the NCEP version of METViewer and let me know if you
have
> any
> >> > > > >> >> idea
> >> > > > what
> >> > > > >> >> could be happening?
> >> > > > >> >>
> >> > > > >> >> Thanks again for your help on this!
> >> > > > >> >>
> >> > > > >> >> Ben
> >> > > > >> >>
> >> > > > >> >>
> >> > > > >> >>
> >> > > > >> >> On Mon, Jul 25, 2016 at 1:05 PM, Benjamin Blake -
NOAA
> >> > > > >> >> Affiliate <
> >> > > > >> >> benjamin.blake at noaa.gov> wrote:
> >> > > > >> >>
> >> > > > >> >> > Hi John,
> >> > > > >> >> >
> >> > > > >> >> > I loaded the xml file you sent and I see that the
> >> > > > >> >> > valid_hour
> >> > > > contents
> >> > > > >> >> are
> >> > > > >> >> > indeed consistent with the valid times and not the
init
> >> > > > >> >> > times.
> >> > > > Thank
> >> > > > >> >> you
> >> > > > >> >> > for sending that.
> >> > > > >> >> >
> >> > > > >> >> > Once I am able to load my xml file into the EMC
version of
> >> > > > METViewer
> >> > > > >> I
> >> > > > >> >> > will look at the R data tab and make sure it is
plotting
> >> > > > >> >> > valid
> >> > > > hour.
> >> > > > >> It
> >> > > > >> >> is
> >> > > > >> >> > taking a while to load at the moment, which I'm
guessing
> is
> >> > > likely
> >> > > > >> >> because
> >> > > > >> >> > you said that Tatiana is currently updating it.
> >> > > > >> >> >
> >> > > > >> >> > If it is correctly plotting valid hour then I will
talk to
> >> > > > >> >> > Geoff
> >> > > > and
> >> > > > >> see
> >> > > > >> >> > if we can understand what is going on.
> >> > > > >> >> >
> >> > > > >> >> > Thank you for your help and I'll let you know if I
am
> >> > > > >> >> > unable to
> >> > > > >> resolve
> >> > > > >> >> > the discrepancy.
> >> > > > >> >> > Ben
> >> > > > >> >> >
> >> > > > >> >> > On Mon, Jul 25, 2016 at 12:35 PM, John Halley
Gotway via
> RT
> >> > > > >> >> > <
> >> > > > >> >> > met_help at ucar.edu> wrote:
> >> > > > >> >> >
> >> > > > >> >> >> Ben,
> >> > > > >> >> >>
> >> > > > >> >> >> I see that you have a question about how METViewer
is
> >> > > > >> >> computing/plotting
> >> > > > >> >> >> the init_hour and valid_hour variables. Thanks
for
> >> > > > >> >> >> sending the
> >> > > > >> >> images. I
> >> > > > >> >> >> understand and see the discrepancy you're
describing.
> >> > > > >> >> >>
> >> > > > >> >> >> I ran some tests on a small subset of data but am
not
> able
> >> > > > >> >> >> to
> >> > > > >> reproduce
> >> > > > >> >> >> the
> >> > > > >> >> >> behavior you're describing. I've attached a plot
and xml
> >> > > > >> >> >> to
> >> > > show
> >> > > > >> you
> >> > > > >> >> what
> >> > > > >> >> >> I'm seeing.
> >> > > > >> >> >>
> >> > > > >> >> >> You could try the following:
> >> > > > >> >> >> (1) Save the attached xml to your local machine.
> >> > > > >> >> >> (2) Go to...
> >> > > http://www.dtcenter.org/met/metviewer/metviewer1.jsp
> >> > > > >> >> >> (3) Click "Load XML" in the top-right corner,
navigate to
> >> > > attached
> >> > > > >> xml
> >> > > > >> >> >> file, and click "OK".
> >> > > > >> >> >> (4) Click "Generate Plot" to make the image.
> >> > > > >> >> >> (5) Once the plot is finished, click on the "R
Data" tab
> >> > > > >> >> >> in the
> >> > > > plot
> >> > > > >> >> >> window.
> >> > > > >> >> >> (6) Inspect the columns of data and note that the
> contents
> >> > > > >> >> >> of
> >> > > > >> >> valid_hour
> >> > > > >> >> >> (i.e. the column just before DPT) really are
consistent
> >> > > > >> >> >> with the
> >> > > > >> valid
> >> > > > >> >> >> times, not the init times.
> >> > > > >> >> >>
> >> > > > >> >> >> So I don't see an obvious problem in METViewer at
this
> >> > > > >> >> >> point.
> >> > > > >> >> >>
> >> > > > >> >> >> The next thing I'd check it how Geoff created the
images
> >> > > > >> >> >> you're
> >> > > > >> >> comparing
> >> > > > >> >> >> against. It's certainly possible that he either
> >> > > > >> >> >> inadvertently
> >> > > or
> >> > > > >> >> >> intentionally plotted against init_hour instead of
> >> > > > >> >> >> valid_hour.
> >> > > > >> >> >>
> >> > > > >> >> >> FYI, Tatiana is in the process of updating the
version of
> >> > > > METViewer
> >> > > > >> >> >> running
> >> > > > >> >> >> at EMC. This typically only takes about 10
minutes, but
> >> > > > >> >> >> for the
> >> > > > >> large
> >> > > > >> >> >> databases there it's taking much longer.
> >> > > > >> >> >>
> >> > > > >> >> >> Please let me know if there's anything else I can
do to
> >> > > > >> >> >> help you
> >> > > > >> debug
> >> > > > >> >> >> this
> >> > > > >> >> >> issue.
> >> > > > >> >> >>
> >> > > > >> >> >> Thanks,
> >> > > > >> >> >> John Halley Gotway
> >> > > > >> >> >>
> >> > > > >> >> >>
> >> > > > >> >> >> On Fri, Jul 22, 2016 at 10:48 AM, Benjamin Blake -
NOAA
> >> > > Affiliate
> >> > > > >> via
> >> > > > >> >> RT <
> >> > > > >> >> >> met_help at ucar.edu> wrote:
> >> > > > >> >> >>
> >> > > > >> >> >> >
> >> > > > >> >> >> > Fri Jul 22 10:48:03 2016: Request 77291 was
acted upon.
> >> > > > >> >> >> > Transaction: Ticket created by
benjamin.blake at noaa.gov
> >> > > > >> >> >> > Queue: met_help
> >> > > > >> >> >> > Subject: Valid Hour vs. Init Hour -
Possible Issue
> >> > > > >> >> >> > Owner: Nobody
> >> > > > >> >> >> > Requestors: benjamin.blake at noaa.gov
> >> > > > >> >> >> > Status: new
> >> > > > >> >> >> > Ticket <URL:
> >> > > > >> >>
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
> >> > > > >> >> >> >
> >> > > > >> >> >> >
> >> > > > >> >> >> > Hi,
> >> > > > >> >> >> >
> >> > > > >> >> >> > I am using MET Viewer to look into bias (ME) and
BCRMSE
> >> > > > >> >> >> > for
> >> > > the
> >> > > > >> HRRR
> >> > > > >> >> and
> >> > > > >> >> >> > HRRRx, as a function of valid hour, to
investigate the
> >> > > > >> >> >> > effects
> >> > > > of
> >> > > > >> the
> >> > > > >> >> >> > diurnal cycle.
> >> > > > >> >> >> >
> >> > > > >> >> >> > I could be wrong but I think MET is plotting
> >> > > > >> >> >> > initialization
> >> > > hour
> >> > > > >> as
> >> > > > >> >> >> valid
> >> > > > >> >> >> > hour and valid hour as initialization hour.
Compare
> the
> >> > > > >> >> >> > two
> >> > > > >> surface
> >> > > > >> >> dew
> >> > > > >> >> >> > point plots, one using initialization hour as
the
> >> > > > >> >> >> > independent
> >> > > > >> >> variable
> >> > > > >> >> >> and
> >> > > > >> >> >> > the other using valid hour, with slide 29 of
Geoff
> >> > > > >> >> >> > Manikin's
> >> > > MEG
> >> > > > >> >> >> > presentation (attached).
> >> > > > >> >> >> >
> >> > > > >> >> >> > The plots for initialization hour seem to match
quite
> >> > > > >> >> >> > closely
> >> > > to
> >> > > > >> the
> >> > > > >> >> >> valid
> >> > > > >> >> >> > hour plots on slide 29 (provided by GSD),
especially
> for
> >> > > > >> >> >> > the
> >> > > > >> >> operational
> >> > > > >> >> >> > HRRR, whereas the plots for valid hour are phase
> shifted
> >> > > > >> >> >> > by 12
> >> > > > >> hours.
> >> > > > >> >> >> I'm
> >> > > > >> >> >> > definitely plotting over the correct region
(East US)
> >> > > > >> >> >> > and I'm
> >> > > > >> using
> >> > > > >> >> all
> >> > > > >> >> >> > 12-hr forecasts (lead time is fixed at 12 hours)
over
> >> > > > >> >> >> > the same
> >> > > > >> time
> >> > > > >> >> >> period
> >> > > > >> >> >> > as GSD.
> >> > > > >> >> >> >
> >> > > > >> >> >> > Thank you!
> >> > > > >> >> >> > Ben Blake (EMC)
> >> > > > >> >> >> >
> >> > > > >> >> >> >
> >> > > > >> >> >>
> >> > > > >> >> >>
> >> > > > >> >> >
> >> > > > >> >>
> >> > > > >> >>
> >> > > > >> >
> >> > > > >>
> >> > > > >>
> >> > > > >
> >> > > >
> >> > > >
> >> > >
> >> > >
> >>
> >>
> >>
> >>
> >
>
>
------------------------------------------------
Subject: Valid Hour vs. Init Hour - Possible Issue
From: Jacob Carley - NOAA Affiliate
Time: Thu Jul 28 10:21:16 2016
Noticed Perry was missing from the thread - adding him back in the
loop.
-Jacob
On Thu, Jul 28, 2016 at 10:09 AM, Tatiana Burek <tatiana at ucar.edu>
wrote:
> Perry,
> Updating the loading module would take me 5-10 min.
> But the database update would take much longer. I was testing the
script
> using 15GB database. It took ~45 min to finish.
> Giving the total size of databases on vm-lnx-metviewdev-process1 I
would
> estimate a few hours.
>
> Tatiana
>
> On Thu, Jul 28, 2016 at 6:32 AM, perry.shafran at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
>> Hi, Tatiana,
>>
>> I'm not sure when the best time is to update the software. How
long would
>> this process take? I think the sooner the better.
>>
>> Perry
>>
>> On Wed, Jul 27, 2016 at 7:36 PM, Jacob Carley - NOAA Affiliate <
>> jacob.carley at noaa.gov> wrote:
>>
>> > Hi Tatiana,
>> >
>> > Great!
>> >
>> > It might be best to ask Perry (cc'd)
>> >
>> > Perry: When is the best time for Tatiana to fix the database and
patch
>> the
>> > MET Viewer software?
>> >
>> > Thanks!
>> > Jacob
>> >
>> > On Wed, Jul 27, 2016 at 5:29 PM, Tatiana Burek via RT <
>> met_help at ucar.edu>
>> > wrote:
>> >
>> >> Hi all,
>> >>
>> >> I have a script that would fix existing databases and a patch
for the
>> >> loading module ready.
>> >> When is the best time to update the software?
>> >>
>> >> Tatiana
>> >>
>> >> On Tue Jul 26 13:52:41 2016, benjamin.blake at noaa.gov wrote:
>> >> > Hi John,
>> >> >
>> >> > Sounds great! Thanks again for looking into this.
>> >> > And thanks Jacob and Perry for confirming.
>> >> >
>> >> > Ben
>> >> >
>> >> > On Tue, Jul 26, 2016 at 3:09 PM, John Halley Gotway via RT <
>> >> > met_help at ucar.edu> wrote:
>> >> >
>> >> > > Hi all,
>> >> > >
>> >> > > Looks like the documentation is something we generated
ourselves.
>> >> > > Looking
>> >> > > back through email, I see that Binbin sent us VSDB header
info back
>> >> > > in
>> >> > > October 2014 which listed that column as "run time". We
made the
>> >> > > mistake
>> >> > > of interpreting it as the initialization time.
>> >> > >
>> >> > > Sorry for all of this confusion, but thanks Ben for tracking
it
>> down!
>> >> > >
>> >> > > The good news is that the fix is pretty straightforward...
>> >> > >
>> >> > > (1) Patch the METViewer VSDB loading logic to correctly
interpret
>> >> > > column 4
>> >> > > as the valid time. Deploy the updated logic in a new
version of
>> >> > > METViewer.
>> >> > >
>> >> > > (2) Update the existing databases by subtracting the lead
time from
>> >> > > the
>> >> > > initialization and valid times.
>> >> > >
>> >> > > Here's the old (incorrect) logic:
>> >> > > Init = column 4
>> >> > > Lead = column 3
>> >> > > Valid = column 4 + column 3
>> >> > >
>> >> > > The correct logic should be:
>> >> > > Init = column 4 - column 3
>> >> > > Lead = column 3
>> >> > > Valid = column 4
>> >> > >
>> >> > > Subtracting the lead time (i.e. column 3) from both the the
init
>> and
>> >> > > valid
>> >> > > times should correct the existing databases.
>> >> > >
>> >> > > But I'll leave it to Tatiana to estimate how long these
patches
>> will
>> >> > > take.
>> >> > >
>> >> > > Thanks,
>> >> > > John
>> >> > >
>> >> > > On Tue, Jul 26, 2016 at 11:38 AM, perry.shafran at noaa.gov via
RT <
>> >>
>> >> > > met_help at ucar.edu> wrote:
>> >> > >
>> >> > > >
>> >> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
>> >> > > >
>> >> > > > Hi, all,
>> >> > > >
>> >> > > > Column 4 is the VALID time. I suppose it was possible
that
>> >> > > > confusion by
>> >> > > me
>> >> > > > led to this being interpreted as the initial time, but
indeed
>> >> > > > column 4 is
>> >> > > > the valid time.
>> >> > > >
>> >> > > > Perry
>> >> > > >
>> >> > > > On Tue, Jul 26, 2016 at 1:30 PM, Jacob Carley - NOAA
Affiliate <
>> >> > > > jacob.carley at noaa.gov> wrote:
>> >> > > >
>> >> > > > > Hi John,
>> >> > > > >
>> >> > > > > I just took a look at our (EMC's) most recent vsdb files
and
>> saw
>> >> > > > > a date
>> >> > > > of
>> >> > > > > 2016072500 in column 4. Furthermore, it also showed
>> verification
>> >> > > > > out
>> >> > > to
>> >> > > > > forecast hours 40+. Given that today is 07/26, this
makes me
>> >> > > > > almost
>> >> > > > > certain that column 4 is the valid time - not the
>> initialization
>> >> > > > > time.
>> >> > > > As
>> >> > > > > you mentioned, this would explain the odd behavior Ben
is
>> seeing
>> >> > > > > in his
>> >> > > > MET
>> >> > > > > Viewer output.
>> >> > > > >
>> >> > > > > I've cc'd Perry to confirm.
>> >> > > > >
>> >> > > > > How quickly might we be able get this addressed? This
will
>> >> > > > > certainly
>> >> > > > > impact our verification stats generated from MET Viewer
with
>> our
>> >> > > > > vsdb
>> >> > > > files.
>> >> > > > >
>> >> > > > > Thanks!
>> >> > > > > Jacob
>> >> > > > >
>> >> > > > > On Tue, Jul 26, 2016 at 1:05 PM, John Halley Gotway via
RT <
>> >> > > > > met_help at ucar.edu> wrote:
>> >> > > > >
>> >> > > > >> Ben,
>> >> > > > >>
>> >> > > > >> Well, I did a visual inspection of the METViewer VSDB
loading
>> >> > > > >> logic.
>> >> > > > I've
>> >> > > > >> attached a sample VSDB file, and I think it all comes
down to
>> >> > > > >> the
>> >> > > > >> interpretation of column 4.
>> >> > > > >>
>> >> > > > >> Column 3 obviously contains the lead time in hours.
Column 4
>> is
>> >> > > > >> in
>> >> > > > >> YYYYMMDDHH format and METViewer interprets this as the
>> forecast
>> >> > > > >> initialization time. If columns 4 actually contains
the valid
>> >> > > > >> time
>> >> > > > >> instead, that would explain the behavior you're
describing.
>> >> > > > >>
>> >> > > > >> However Tatiana and I checked the documentation we
received
>> >> > > > >> about the
>> >> > > > VSDB
>> >> > > > >> file format as the 4th column is listed as "init
date/time".
>> >> > > > >>
>> >> > > > >> I do have some doubts about all this tough based on
previous
>> >> > > > conversations
>> >> > > > >> with Perry Shafran. The VSDB processing logic uses to
the
>> >> > > > >> "newest"
>> >> > > > >> observations to verify (for example) the current 0-hour
>> >> > > > >> forecast, the
>> >> > > > >> 6-hour forecast from 6 hours ago, the 12-hour from 12
hours
>> >> > > > >> ago... and
>> >> > > > so
>> >> > > > >> on. In this logic, the valid time remains constant
while the
>> >> > > > >> lead
>> >> > > time
>> >> > > > >> changes. Looking in the attached VSDB file, I see that
>> column 4
>> >> > > remains
>> >> > > > >> fixed while the lead times in column 3 change quickly.
>> >> > > > >>
>> >> > > > >> So really this could go either way. The documentation
>> suggests
>> >> > > > >> that
>> >> > > > >> column
>> >> > > > >> 4 is the init time, but the processing logic suggests
that it
>> >> > > > >> would be
>> >> > > > the
>> >> > > > >> valid time.
>> >> > > > >>
>> >> > > > >> You could ask Perry to verify the interpretation of
column 4.
>> >> > > > >>
>> >> > > > >> John
>> >> > > > >>
>> >> > > > >>
>> >> > > > >> On Tue, Jul 26, 2016 at 10:38 AM, John Halley Gotway
>> >> > > > >> <johnhg at ucar.edu
>> >> > > >
>> >> > > > >> wrote:
>> >> > > > >>
>> >> > > > >> > Ben,
>> >> > > > >> >
>> >> > > > >> > My access to NCEP VPN isn't working, so I'm not able
to test
>> >> > > > >> > out
>> >> > > that
>> >> > > > >> XML
>> >> > > > >> > directly. However, another possibility occurred to
me.
>> >> > > > >> > METViewer
>> >> > > can
>> >> > > > >> be
>> >> > > > >> > loaded with data directly from MET or with VSDB files
>> >> > > > >> > generated with
>> >> > > > the
>> >> > > > >> > NCEP Vx package. Both of those pathways read data
from flat
>> >> > > > >> > files
>> >> > > and
>> >> > > > >> > store them in the database.
>> >> > > > >> >
>> >> > > > >> > The testing I did only covered the "MET" pathway, not
the
>> >> > > > >> > "VSDB"
>> >> > > one.
>> >> > > > >> > It's possible that when reading VSDB data, METViewer
is
>> >> > > > >> > storing init
>> >> > > > >> times
>> >> > > > >> > as valid times or vice versa.
>> >> > > > >> >
>> >> > > > >> > Do you know how the HRRR data you're plotting via
METViewer
>> >> > > > >> > was
>> >> > > > created?
>> >> > > > >> > Were they VSDB files or MET output files.
>> >> > > > >> >
>> >> > > > >> > Thanks,
>> >> > > > >> > John
>> >> > > > >> >
>> >> > > > >> > On Tue, Jul 26, 2016 at 9:40 AM, Benjamin Blake -
NOAA
>> >> > > > >> > Affiliate via
>> >> > > > RT
>> >> > > > >> <
>> >> > > > >> > met_help at ucar.edu> wrote:
>> >> > > > >> >
>> >> > > > >> >>
>> >> > > > >> >> <URL:
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291
>> >> > > > >> >> >
>> >> > > > >> >>
>> >> > > > >> >> Hi John,
>> >> > > > >> >>
>> >> > > > >> >> I am still trying to figure out what the issue could
be. I
>> >> > > verified
>> >> > > > >> with
>> >> > > > >> >> the NCEP instance of METViewer that it is indeed
plotting
>> >> > > > >> >> valid
>> >> > > hour.
>> >> > > > >> >> Geoff asked Curtis Alexander (who made the original
bias
>> >> > > > >> >> plots)
>> >> > > about
>> >> > > > >> the
>> >> > > > >> >> values on the x-axis and Curtis confirmed that they
were
>> >> > > > >> >> plotting
>> >> > > > valid
>> >> > > > >> >> hour also. The plots I made using MET Viewer still
seem to
>> >> > > > >> >> be
>> >> > > phase
>> >> > > > >> >> shifted by 12 hours. The largest ME should be in
the late
>> >> > > > >> afternoon/early
>> >> > > > >> >> evening, so around 0z, and not in the early morning
>> (12-15z).
>> >> > > > >> >>
>> >> > > > >> >> Could the issue have something to do with the way
MET is
>> >> > > > >> >> reading in
>> >> > > > the
>> >> > > > >> >> database files?
>> >> > > > >> >> I've attached a xml file that looks at the HRRR vs.
HRRRx
>> >> > > > >> >> surface
>> >> > > > >> >> temperature ME (as a function of valid hour) for all
12-hr
>> >> > > forecasts
>> >> > > > >> for
>> >> > > > >> >> all cycles on 7/20/16 over the eastern US. Perhaps
you
>> could
>> >> > > > >> >> load
>> >> > > it
>> >> > > > >> into
>> >> > > > >> >> the NCEP version of METViewer and let me know if you
have
>> any
>> >> > > > >> >> idea
>> >> > > > what
>> >> > > > >> >> could be happening?
>> >> > > > >> >>
>> >> > > > >> >> Thanks again for your help on this!
>> >> > > > >> >>
>> >> > > > >> >> Ben
>> >> > > > >> >>
>> >> > > > >> >>
>> >> > > > >> >>
>> >> > > > >> >> On Mon, Jul 25, 2016 at 1:05 PM, Benjamin Blake -
NOAA
>> >> > > > >> >> Affiliate <
>> >> > > > >> >> benjamin.blake at noaa.gov> wrote:
>> >> > > > >> >>
>> >> > > > >> >> > Hi John,
>> >> > > > >> >> >
>> >> > > > >> >> > I loaded the xml file you sent and I see that the
>> >> > > > >> >> > valid_hour
>> >> > > > contents
>> >> > > > >> >> are
>> >> > > > >> >> > indeed consistent with the valid times and not the
init
>> >> > > > >> >> > times.
>> >> > > > Thank
>> >> > > > >> >> you
>> >> > > > >> >> > for sending that.
>> >> > > > >> >> >
>> >> > > > >> >> > Once I am able to load my xml file into the EMC
version
>> of
>> >> > > > METViewer
>> >> > > > >> I
>> >> > > > >> >> > will look at the R data tab and make sure it is
plotting
>> >> > > > >> >> > valid
>> >> > > > hour.
>> >> > > > >> It
>> >> > > > >> >> is
>> >> > > > >> >> > taking a while to load at the moment, which I'm
guessing
>> is
>> >> > > likely
>> >> > > > >> >> because
>> >> > > > >> >> > you said that Tatiana is currently updating it.
>> >> > > > >> >> >
>> >> > > > >> >> > If it is correctly plotting valid hour then I will
talk
>> to
>> >> > > > >> >> > Geoff
>> >> > > > and
>> >> > > > >> see
>> >> > > > >> >> > if we can understand what is going on.
>> >> > > > >> >> >
>> >> > > > >> >> > Thank you for your help and I'll let you know if I
am
>> >> > > > >> >> > unable to
>> >> > > > >> resolve
>> >> > > > >> >> > the discrepancy.
>> >> > > > >> >> > Ben
>> >> > > > >> >> >
>> >> > > > >> >> > On Mon, Jul 25, 2016 at 12:35 PM, John Halley
Gotway via
>> RT
>> >> > > > >> >> > <
>> >> > > > >> >> > met_help at ucar.edu> wrote:
>> >> > > > >> >> >
>> >> > > > >> >> >> Ben,
>> >> > > > >> >> >>
>> >> > > > >> >> >> I see that you have a question about how
METViewer is
>> >> > > > >> >> computing/plotting
>> >> > > > >> >> >> the init_hour and valid_hour variables. Thanks
for
>> >> > > > >> >> >> sending the
>> >> > > > >> >> images. I
>> >> > > > >> >> >> understand and see the discrepancy you're
describing.
>> >> > > > >> >> >>
>> >> > > > >> >> >> I ran some tests on a small subset of data but am
not
>> able
>> >> > > > >> >> >> to
>> >> > > > >> reproduce
>> >> > > > >> >> >> the
>> >> > > > >> >> >> behavior you're describing. I've attached a plot
and
>> xml
>> >> > > > >> >> >> to
>> >> > > show
>> >> > > > >> you
>> >> > > > >> >> what
>> >> > > > >> >> >> I'm seeing.
>> >> > > > >> >> >>
>> >> > > > >> >> >> You could try the following:
>> >> > > > >> >> >> (1) Save the attached xml to your local machine.
>> >> > > > >> >> >> (2) Go to...
>> >> > > http://www.dtcenter.org/met/metviewer/metviewer1.jsp
>> >> > > > >> >> >> (3) Click "Load XML" in the top-right corner,
navigate
>> to
>> >> > > attached
>> >> > > > >> xml
>> >> > > > >> >> >> file, and click "OK".
>> >> > > > >> >> >> (4) Click "Generate Plot" to make the image.
>> >> > > > >> >> >> (5) Once the plot is finished, click on the "R
Data" tab
>> >> > > > >> >> >> in the
>> >> > > > plot
>> >> > > > >> >> >> window.
>> >> > > > >> >> >> (6) Inspect the columns of data and note that the
>> contents
>> >> > > > >> >> >> of
>> >> > > > >> >> valid_hour
>> >> > > > >> >> >> (i.e. the column just before DPT) really are
consistent
>> >> > > > >> >> >> with the
>> >> > > > >> valid
>> >> > > > >> >> >> times, not the init times.
>> >> > > > >> >> >>
>> >> > > > >> >> >> So I don't see an obvious problem in METViewer at
this
>> >> > > > >> >> >> point.
>> >> > > > >> >> >>
>> >> > > > >> >> >> The next thing I'd check it how Geoff created the
images
>> >> > > > >> >> >> you're
>> >> > > > >> >> comparing
>> >> > > > >> >> >> against. It's certainly possible that he either
>> >> > > > >> >> >> inadvertently
>> >> > > or
>> >> > > > >> >> >> intentionally plotted against init_hour instead
of
>> >> > > > >> >> >> valid_hour.
>> >> > > > >> >> >>
>> >> > > > >> >> >> FYI, Tatiana is in the process of updating the
version
>> of
>> >> > > > METViewer
>> >> > > > >> >> >> running
>> >> > > > >> >> >> at EMC. This typically only takes about 10
minutes, but
>> >> > > > >> >> >> for the
>> >> > > > >> large
>> >> > > > >> >> >> databases there it's taking much longer.
>> >> > > > >> >> >>
>> >> > > > >> >> >> Please let me know if there's anything else I can
do to
>> >> > > > >> >> >> help you
>> >> > > > >> debug
>> >> > > > >> >> >> this
>> >> > > > >> >> >> issue.
>> >> > > > >> >> >>
>> >> > > > >> >> >> Thanks,
>> >> > > > >> >> >> John Halley Gotway
>> >> > > > >> >> >>
>> >> > > > >> >> >>
>> >> > > > >> >> >> On Fri, Jul 22, 2016 at 10:48 AM, Benjamin Blake
- NOAA
>> >> > > Affiliate
>> >> > > > >> via
>> >> > > > >> >> RT <
>> >> > > > >> >> >> met_help at ucar.edu> wrote:
>> >> > > > >> >> >>
>> >> > > > >> >> >> >
>> >> > > > >> >> >> > Fri Jul 22 10:48:03 2016: Request 77291 was
acted
>> upon.
>> >> > > > >> >> >> > Transaction: Ticket created by
>> benjamin.blake at noaa.gov
>> >> > > > >> >> >> > Queue: met_help
>> >> > > > >> >> >> > Subject: Valid Hour vs. Init Hour -
Possible
>> Issue
>> >> > > > >> >> >> > Owner: Nobody
>> >> > > > >> >> >> > Requestors: benjamin.blake at noaa.gov
>> >> > > > >> >> >> > Status: new
>> >> > > > >> >> >> > Ticket <URL:
>> >> > > > >> >>
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
>> >> > > > >> >> >> >
>> >> > > > >> >> >> >
>> >> > > > >> >> >> > Hi,
>> >> > > > >> >> >> >
>> >> > > > >> >> >> > I am using MET Viewer to look into bias (ME)
and
>> BCRMSE
>> >> > > > >> >> >> > for
>> >> > > the
>> >> > > > >> HRRR
>> >> > > > >> >> and
>> >> > > > >> >> >> > HRRRx, as a function of valid hour, to
investigate the
>> >> > > > >> >> >> > effects
>> >> > > > of
>> >> > > > >> the
>> >> > > > >> >> >> > diurnal cycle.
>> >> > > > >> >> >> >
>> >> > > > >> >> >> > I could be wrong but I think MET is plotting
>> >> > > > >> >> >> > initialization
>> >> > > hour
>> >> > > > >> as
>> >> > > > >> >> >> valid
>> >> > > > >> >> >> > hour and valid hour as initialization hour.
Compare
>> the
>> >> > > > >> >> >> > two
>> >> > > > >> surface
>> >> > > > >> >> dew
>> >> > > > >> >> >> > point plots, one using initialization hour as
the
>> >> > > > >> >> >> > independent
>> >> > > > >> >> variable
>> >> > > > >> >> >> and
>> >> > > > >> >> >> > the other using valid hour, with slide 29 of
Geoff
>> >> > > > >> >> >> > Manikin's
>> >> > > MEG
>> >> > > > >> >> >> > presentation (attached).
>> >> > > > >> >> >> >
>> >> > > > >> >> >> > The plots for initialization hour seem to match
quite
>> >> > > > >> >> >> > closely
>> >> > > to
>> >> > > > >> the
>> >> > > > >> >> >> valid
>> >> > > > >> >> >> > hour plots on slide 29 (provided by GSD),
especially
>> for
>> >> > > > >> >> >> > the
>> >> > > > >> >> operational
>> >> > > > >> >> >> > HRRR, whereas the plots for valid hour are
phase
>> shifted
>> >> > > > >> >> >> > by 12
>> >> > > > >> hours.
>> >> > > > >> >> >> I'm
>> >> > > > >> >> >> > definitely plotting over the correct region
(East US)
>> >> > > > >> >> >> > and I'm
>> >> > > > >> using
>> >> > > > >> >> all
>> >> > > > >> >> >> > 12-hr forecasts (lead time is fixed at 12
hours) over
>> >> > > > >> >> >> > the same
>> >> > > > >> time
>> >> > > > >> >> >> period
>> >> > > > >> >> >> > as GSD.
>> >> > > > >> >> >> >
>> >> > > > >> >> >> > Thank you!
>> >> > > > >> >> >> > Ben Blake (EMC)
>> >> > > > >> >> >> >
>> >> > > > >> >> >> >
>> >> > > > >> >> >>
>> >> > > > >> >> >>
>> >> > > > >> >> >
>> >> > > > >> >>
>> >> > > > >> >>
>> >> > > > >> >
>> >> > > > >>
>> >> > > > >>
>> >> > > > >
>> >> > > >
>> >> > > >
>> >> > >
>> >> > >
>> >>
>> >>
>> >>
>> >>
>> >
>>
>>
>
------------------------------------------------
Subject: Valid Hour vs. Init Hour - Possible Issue
From: perry.shafran at noaa.gov
Time: Thu Jul 28 11:27:08 2016
I think you should just go ahead and to the updates when you are
ready.
I'm sure folks here can wait until it is finished to plot again.
Please go ahead and do the updates and shoot us an email to let us
know
when it is finished.
Thanks!
Perry
On Thu, Jul 28, 2016 at 11:27 AM, Jacob Carley - NOAA Affiliate <
jacob.carley at noaa.gov> wrote:
> Noticed Perry was missing from the thread - adding him back in the
loop.
> -Jacob
>
> On Thu, Jul 28, 2016 at 10:09 AM, Tatiana Burek <tatiana at ucar.edu>
wrote:
>
>> Perry,
>> Updating the loading module would take me 5-10 min.
>> But the database update would take much longer. I was testing the
script
>> using 15GB database. It took ~45 min to finish.
>> Giving the total size of databases on vm-lnx-metviewdev-process1 I
would
>> estimate a few hours.
>>
>> Tatiana
>>
>> On Thu, Jul 28, 2016 at 6:32 AM, perry.shafran at noaa.gov via RT <
>> met_help at ucar.edu> wrote:
>>
>>> Hi, Tatiana,
>>>
>>> I'm not sure when the best time is to update the software. How
long
>>> would
>>> this process take? I think the sooner the better.
>>>
>>> Perry
>>>
>>> On Wed, Jul 27, 2016 at 7:36 PM, Jacob Carley - NOAA Affiliate <
>>> jacob.carley at noaa.gov> wrote:
>>>
>>> > Hi Tatiana,
>>> >
>>> > Great!
>>> >
>>> > It might be best to ask Perry (cc'd)
>>> >
>>> > Perry: When is the best time for Tatiana to fix the database and
patch
>>> the
>>> > MET Viewer software?
>>> >
>>> > Thanks!
>>> > Jacob
>>> >
>>> > On Wed, Jul 27, 2016 at 5:29 PM, Tatiana Burek via RT <
>>> met_help at ucar.edu>
>>> > wrote:
>>> >
>>> >> Hi all,
>>> >>
>>> >> I have a script that would fix existing databases and a patch
for the
>>> >> loading module ready.
>>> >> When is the best time to update the software?
>>> >>
>>> >> Tatiana
>>> >>
>>> >> On Tue Jul 26 13:52:41 2016, benjamin.blake at noaa.gov wrote:
>>> >> > Hi John,
>>> >> >
>>> >> > Sounds great! Thanks again for looking into this.
>>> >> > And thanks Jacob and Perry for confirming.
>>> >> >
>>> >> > Ben
>>> >> >
>>> >> > On Tue, Jul 26, 2016 at 3:09 PM, John Halley Gotway via RT <
>>> >> > met_help at ucar.edu> wrote:
>>> >> >
>>> >> > > Hi all,
>>> >> > >
>>> >> > > Looks like the documentation is something we generated
ourselves.
>>> >> > > Looking
>>> >> > > back through email, I see that Binbin sent us VSDB header
info
>>> back
>>> >> > > in
>>> >> > > October 2014 which listed that column as "run time". We
made the
>>> >> > > mistake
>>> >> > > of interpreting it as the initialization time.
>>> >> > >
>>> >> > > Sorry for all of this confusion, but thanks Ben for
tracking it
>>> down!
>>> >> > >
>>> >> > > The good news is that the fix is pretty straightforward...
>>> >> > >
>>> >> > > (1) Patch the METViewer VSDB loading logic to correctly
interpret
>>> >> > > column 4
>>> >> > > as the valid time. Deploy the updated logic in a new
version of
>>> >> > > METViewer.
>>> >> > >
>>> >> > > (2) Update the existing databases by subtracting the lead
time
>>> from
>>> >> > > the
>>> >> > > initialization and valid times.
>>> >> > >
>>> >> > > Here's the old (incorrect) logic:
>>> >> > > Init = column 4
>>> >> > > Lead = column 3
>>> >> > > Valid = column 4 + column 3
>>> >> > >
>>> >> > > The correct logic should be:
>>> >> > > Init = column 4 - column 3
>>> >> > > Lead = column 3
>>> >> > > Valid = column 4
>>> >> > >
>>> >> > > Subtracting the lead time (i.e. column 3) from both the the
init
>>> and
>>> >> > > valid
>>> >> > > times should correct the existing databases.
>>> >> > >
>>> >> > > But I'll leave it to Tatiana to estimate how long these
patches
>>> will
>>> >> > > take.
>>> >> > >
>>> >> > > Thanks,
>>> >> > > John
>>> >> > >
>>> >> > > On Tue, Jul 26, 2016 at 11:38 AM, perry.shafran at noaa.gov
via RT <
>>> >>
>>> >> > > met_help at ucar.edu> wrote:
>>> >> > >
>>> >> > > >
>>> >> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
>>> >> > > >
>>> >> > > > Hi, all,
>>> >> > > >
>>> >> > > > Column 4 is the VALID time. I suppose it was possible
that
>>> >> > > > confusion by
>>> >> > > me
>>> >> > > > led to this being interpreted as the initial time, but
indeed
>>> >> > > > column 4 is
>>> >> > > > the valid time.
>>> >> > > >
>>> >> > > > Perry
>>> >> > > >
>>> >> > > > On Tue, Jul 26, 2016 at 1:30 PM, Jacob Carley - NOAA
Affiliate <
>>> >> > > > jacob.carley at noaa.gov> wrote:
>>> >> > > >
>>> >> > > > > Hi John,
>>> >> > > > >
>>> >> > > > > I just took a look at our (EMC's) most recent vsdb
files and
>>> saw
>>> >> > > > > a date
>>> >> > > > of
>>> >> > > > > 2016072500 in column 4. Furthermore, it also showed
>>> verification
>>> >> > > > > out
>>> >> > > to
>>> >> > > > > forecast hours 40+. Given that today is 07/26, this
makes me
>>> >> > > > > almost
>>> >> > > > > certain that column 4 is the valid time - not the
>>> initialization
>>> >> > > > > time.
>>> >> > > > As
>>> >> > > > > you mentioned, this would explain the odd behavior Ben
is
>>> seeing
>>> >> > > > > in his
>>> >> > > > MET
>>> >> > > > > Viewer output.
>>> >> > > > >
>>> >> > > > > I've cc'd Perry to confirm.
>>> >> > > > >
>>> >> > > > > How quickly might we be able get this addressed? This
will
>>> >> > > > > certainly
>>> >> > > > > impact our verification stats generated from MET Viewer
with
>>> our
>>> >> > > > > vsdb
>>> >> > > > files.
>>> >> > > > >
>>> >> > > > > Thanks!
>>> >> > > > > Jacob
>>> >> > > > >
>>> >> > > > > On Tue, Jul 26, 2016 at 1:05 PM, John Halley Gotway via
RT <
>>> >> > > > > met_help at ucar.edu> wrote:
>>> >> > > > >
>>> >> > > > >> Ben,
>>> >> > > > >>
>>> >> > > > >> Well, I did a visual inspection of the METViewer VSDB
loading
>>> >> > > > >> logic.
>>> >> > > > I've
>>> >> > > > >> attached a sample VSDB file, and I think it all comes
down to
>>> >> > > > >> the
>>> >> > > > >> interpretation of column 4.
>>> >> > > > >>
>>> >> > > > >> Column 3 obviously contains the lead time in hours.
Column
>>> 4 is
>>> >> > > > >> in
>>> >> > > > >> YYYYMMDDHH format and METViewer interprets this as the
>>> forecast
>>> >> > > > >> initialization time. If columns 4 actually contains
the
>>> valid
>>> >> > > > >> time
>>> >> > > > >> instead, that would explain the behavior you're
describing.
>>> >> > > > >>
>>> >> > > > >> However Tatiana and I checked the documentation we
received
>>> >> > > > >> about the
>>> >> > > > VSDB
>>> >> > > > >> file format as the 4th column is listed as "init
date/time".
>>> >> > > > >>
>>> >> > > > >> I do have some doubts about all this tough based on
previous
>>> >> > > > conversations
>>> >> > > > >> with Perry Shafran. The VSDB processing logic uses to
the
>>> >> > > > >> "newest"
>>> >> > > > >> observations to verify (for example) the current 0-
hour
>>> >> > > > >> forecast, the
>>> >> > > > >> 6-hour forecast from 6 hours ago, the 12-hour from 12
hours
>>> >> > > > >> ago... and
>>> >> > > > so
>>> >> > > > >> on. In this logic, the valid time remains constant
while the
>>> >> > > > >> lead
>>> >> > > time
>>> >> > > > >> changes. Looking in the attached VSDB file, I see
that
>>> column 4
>>> >> > > remains
>>> >> > > > >> fixed while the lead times in column 3 change quickly.
>>> >> > > > >>
>>> >> > > > >> So really this could go either way. The documentation
>>> suggests
>>> >> > > > >> that
>>> >> > > > >> column
>>> >> > > > >> 4 is the init time, but the processing logic suggests
that it
>>> >> > > > >> would be
>>> >> > > > the
>>> >> > > > >> valid time.
>>> >> > > > >>
>>> >> > > > >> You could ask Perry to verify the interpretation of
column 4.
>>> >> > > > >>
>>> >> > > > >> John
>>> >> > > > >>
>>> >> > > > >>
>>> >> > > > >> On Tue, Jul 26, 2016 at 10:38 AM, John Halley Gotway
>>> >> > > > >> <johnhg at ucar.edu
>>> >> > > >
>>> >> > > > >> wrote:
>>> >> > > > >>
>>> >> > > > >> > Ben,
>>> >> > > > >> >
>>> >> > > > >> > My access to NCEP VPN isn't working, so I'm not able
to
>>> test
>>> >> > > > >> > out
>>> >> > > that
>>> >> > > > >> XML
>>> >> > > > >> > directly. However, another possibility occurred to
me.
>>> >> > > > >> > METViewer
>>> >> > > can
>>> >> > > > >> be
>>> >> > > > >> > loaded with data directly from MET or with VSDB
files
>>> >> > > > >> > generated with
>>> >> > > > the
>>> >> > > > >> > NCEP Vx package. Both of those pathways read data
from
>>> flat
>>> >> > > > >> > files
>>> >> > > and
>>> >> > > > >> > store them in the database.
>>> >> > > > >> >
>>> >> > > > >> > The testing I did only covered the "MET" pathway,
not the
>>> >> > > > >> > "VSDB"
>>> >> > > one.
>>> >> > > > >> > It's possible that when reading VSDB data, METViewer
is
>>> >> > > > >> > storing init
>>> >> > > > >> times
>>> >> > > > >> > as valid times or vice versa.
>>> >> > > > >> >
>>> >> > > > >> > Do you know how the HRRR data you're plotting via
METViewer
>>> >> > > > >> > was
>>> >> > > > created?
>>> >> > > > >> > Were they VSDB files or MET output files.
>>> >> > > > >> >
>>> >> > > > >> > Thanks,
>>> >> > > > >> > John
>>> >> > > > >> >
>>> >> > > > >> > On Tue, Jul 26, 2016 at 9:40 AM, Benjamin Blake -
NOAA
>>> >> > > > >> > Affiliate via
>>> >> > > > RT
>>> >> > > > >> <
>>> >> > > > >> > met_help at ucar.edu> wrote:
>>> >> > > > >> >
>>> >> > > > >> >>
>>> >> > > > >> >> <URL:
>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291
>>> >> > > > >> >> >
>>> >> > > > >> >>
>>> >> > > > >> >> Hi John,
>>> >> > > > >> >>
>>> >> > > > >> >> I am still trying to figure out what the issue
could be.
>>> I
>>> >> > > verified
>>> >> > > > >> with
>>> >> > > > >> >> the NCEP instance of METViewer that it is indeed
plotting
>>> >> > > > >> >> valid
>>> >> > > hour.
>>> >> > > > >> >> Geoff asked Curtis Alexander (who made the original
bias
>>> >> > > > >> >> plots)
>>> >> > > about
>>> >> > > > >> the
>>> >> > > > >> >> values on the x-axis and Curtis confirmed that they
were
>>> >> > > > >> >> plotting
>>> >> > > > valid
>>> >> > > > >> >> hour also. The plots I made using MET Viewer still
seem
>>> to
>>> >> > > > >> >> be
>>> >> > > phase
>>> >> > > > >> >> shifted by 12 hours. The largest ME should be in
the late
>>> >> > > > >> afternoon/early
>>> >> > > > >> >> evening, so around 0z, and not in the early morning
>>> (12-15z).
>>> >> > > > >> >>
>>> >> > > > >> >> Could the issue have something to do with the way
MET is
>>> >> > > > >> >> reading in
>>> >> > > > the
>>> >> > > > >> >> database files?
>>> >> > > > >> >> I've attached a xml file that looks at the HRRR vs.
HRRRx
>>> >> > > > >> >> surface
>>> >> > > > >> >> temperature ME (as a function of valid hour) for
all 12-hr
>>> >> > > forecasts
>>> >> > > > >> for
>>> >> > > > >> >> all cycles on 7/20/16 over the eastern US. Perhaps
you
>>> could
>>> >> > > > >> >> load
>>> >> > > it
>>> >> > > > >> into
>>> >> > > > >> >> the NCEP version of METViewer and let me know if
you have
>>> any
>>> >> > > > >> >> idea
>>> >> > > > what
>>> >> > > > >> >> could be happening?
>>> >> > > > >> >>
>>> >> > > > >> >> Thanks again for your help on this!
>>> >> > > > >> >>
>>> >> > > > >> >> Ben
>>> >> > > > >> >>
>>> >> > > > >> >>
>>> >> > > > >> >>
>>> >> > > > >> >> On Mon, Jul 25, 2016 at 1:05 PM, Benjamin Blake -
NOAA
>>> >> > > > >> >> Affiliate <
>>> >> > > > >> >> benjamin.blake at noaa.gov> wrote:
>>> >> > > > >> >>
>>> >> > > > >> >> > Hi John,
>>> >> > > > >> >> >
>>> >> > > > >> >> > I loaded the xml file you sent and I see that the
>>> >> > > > >> >> > valid_hour
>>> >> > > > contents
>>> >> > > > >> >> are
>>> >> > > > >> >> > indeed consistent with the valid times and not
the init
>>> >> > > > >> >> > times.
>>> >> > > > Thank
>>> >> > > > >> >> you
>>> >> > > > >> >> > for sending that.
>>> >> > > > >> >> >
>>> >> > > > >> >> > Once I am able to load my xml file into the EMC
version
>>> of
>>> >> > > > METViewer
>>> >> > > > >> I
>>> >> > > > >> >> > will look at the R data tab and make sure it is
plotting
>>> >> > > > >> >> > valid
>>> >> > > > hour.
>>> >> > > > >> It
>>> >> > > > >> >> is
>>> >> > > > >> >> > taking a while to load at the moment, which I'm
>>> guessing is
>>> >> > > likely
>>> >> > > > >> >> because
>>> >> > > > >> >> > you said that Tatiana is currently updating it.
>>> >> > > > >> >> >
>>> >> > > > >> >> > If it is correctly plotting valid hour then I
will talk
>>> to
>>> >> > > > >> >> > Geoff
>>> >> > > > and
>>> >> > > > >> see
>>> >> > > > >> >> > if we can understand what is going on.
>>> >> > > > >> >> >
>>> >> > > > >> >> > Thank you for your help and I'll let you know if
I am
>>> >> > > > >> >> > unable to
>>> >> > > > >> resolve
>>> >> > > > >> >> > the discrepancy.
>>> >> > > > >> >> > Ben
>>> >> > > > >> >> >
>>> >> > > > >> >> > On Mon, Jul 25, 2016 at 12:35 PM, John Halley
Gotway
>>> via RT
>>> >> > > > >> >> > <
>>> >> > > > >> >> > met_help at ucar.edu> wrote:
>>> >> > > > >> >> >
>>> >> > > > >> >> >> Ben,
>>> >> > > > >> >> >>
>>> >> > > > >> >> >> I see that you have a question about how
METViewer is
>>> >> > > > >> >> computing/plotting
>>> >> > > > >> >> >> the init_hour and valid_hour variables. Thanks
for
>>> >> > > > >> >> >> sending the
>>> >> > > > >> >> images. I
>>> >> > > > >> >> >> understand and see the discrepancy you're
describing.
>>> >> > > > >> >> >>
>>> >> > > > >> >> >> I ran some tests on a small subset of data but
am not
>>> able
>>> >> > > > >> >> >> to
>>> >> > > > >> reproduce
>>> >> > > > >> >> >> the
>>> >> > > > >> >> >> behavior you're describing. I've attached a
plot and
>>> xml
>>> >> > > > >> >> >> to
>>> >> > > show
>>> >> > > > >> you
>>> >> > > > >> >> what
>>> >> > > > >> >> >> I'm seeing.
>>> >> > > > >> >> >>
>>> >> > > > >> >> >> You could try the following:
>>> >> > > > >> >> >> (1) Save the attached xml to your local machine.
>>> >> > > > >> >> >> (2) Go to...
>>> >> > > http://www.dtcenter.org/met/metviewer/metviewer1.jsp
>>> >> > > > >> >> >> (3) Click "Load XML" in the top-right corner,
navigate
>>> to
>>> >> > > attached
>>> >> > > > >> xml
>>> >> > > > >> >> >> file, and click "OK".
>>> >> > > > >> >> >> (4) Click "Generate Plot" to make the image.
>>> >> > > > >> >> >> (5) Once the plot is finished, click on the "R
Data"
>>> tab
>>> >> > > > >> >> >> in the
>>> >> > > > plot
>>> >> > > > >> >> >> window.
>>> >> > > > >> >> >> (6) Inspect the columns of data and note that
the
>>> contents
>>> >> > > > >> >> >> of
>>> >> > > > >> >> valid_hour
>>> >> > > > >> >> >> (i.e. the column just before DPT) really are
consistent
>>> >> > > > >> >> >> with the
>>> >> > > > >> valid
>>> >> > > > >> >> >> times, not the init times.
>>> >> > > > >> >> >>
>>> >> > > > >> >> >> So I don't see an obvious problem in METViewer
at this
>>> >> > > > >> >> >> point.
>>> >> > > > >> >> >>
>>> >> > > > >> >> >> The next thing I'd check it how Geoff created
the
>>> images
>>> >> > > > >> >> >> you're
>>> >> > > > >> >> comparing
>>> >> > > > >> >> >> against. It's certainly possible that he either
>>> >> > > > >> >> >> inadvertently
>>> >> > > or
>>> >> > > > >> >> >> intentionally plotted against init_hour instead
of
>>> >> > > > >> >> >> valid_hour.
>>> >> > > > >> >> >>
>>> >> > > > >> >> >> FYI, Tatiana is in the process of updating the
version
>>> of
>>> >> > > > METViewer
>>> >> > > > >> >> >> running
>>> >> > > > >> >> >> at EMC. This typically only takes about 10
minutes,
>>> but
>>> >> > > > >> >> >> for the
>>> >> > > > >> large
>>> >> > > > >> >> >> databases there it's taking much longer.
>>> >> > > > >> >> >>
>>> >> > > > >> >> >> Please let me know if there's anything else I
can do to
>>> >> > > > >> >> >> help you
>>> >> > > > >> debug
>>> >> > > > >> >> >> this
>>> >> > > > >> >> >> issue.
>>> >> > > > >> >> >>
>>> >> > > > >> >> >> Thanks,
>>> >> > > > >> >> >> John Halley Gotway
>>> >> > > > >> >> >>
>>> >> > > > >> >> >>
>>> >> > > > >> >> >> On Fri, Jul 22, 2016 at 10:48 AM, Benjamin Blake
- NOAA
>>> >> > > Affiliate
>>> >> > > > >> via
>>> >> > > > >> >> RT <
>>> >> > > > >> >> >> met_help at ucar.edu> wrote:
>>> >> > > > >> >> >>
>>> >> > > > >> >> >> >
>>> >> > > > >> >> >> > Fri Jul 22 10:48:03 2016: Request 77291 was
acted
>>> upon.
>>> >> > > > >> >> >> > Transaction: Ticket created by
>>> benjamin.blake at noaa.gov
>>> >> > > > >> >> >> > Queue: met_help
>>> >> > > > >> >> >> > Subject: Valid Hour vs. Init Hour -
Possible
>>> Issue
>>> >> > > > >> >> >> > Owner: Nobody
>>> >> > > > >> >> >> > Requestors: benjamin.blake at noaa.gov
>>> >> > > > >> >> >> > Status: new
>>> >> > > > >> >> >> > Ticket <URL:
>>> >> > > > >> >>
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=77291 >
>>> >> > > > >> >> >> >
>>> >> > > > >> >> >> >
>>> >> > > > >> >> >> > Hi,
>>> >> > > > >> >> >> >
>>> >> > > > >> >> >> > I am using MET Viewer to look into bias (ME)
and
>>> BCRMSE
>>> >> > > > >> >> >> > for
>>> >> > > the
>>> >> > > > >> HRRR
>>> >> > > > >> >> and
>>> >> > > > >> >> >> > HRRRx, as a function of valid hour, to
investigate
>>> the
>>> >> > > > >> >> >> > effects
>>> >> > > > of
>>> >> > > > >> the
>>> >> > > > >> >> >> > diurnal cycle.
>>> >> > > > >> >> >> >
>>> >> > > > >> >> >> > I could be wrong but I think MET is plotting
>>> >> > > > >> >> >> > initialization
>>> >> > > hour
>>> >> > > > >> as
>>> >> > > > >> >> >> valid
>>> >> > > > >> >> >> > hour and valid hour as initialization hour.
Compare
>>> the
>>> >> > > > >> >> >> > two
>>> >> > > > >> surface
>>> >> > > > >> >> dew
>>> >> > > > >> >> >> > point plots, one using initialization hour as
the
>>> >> > > > >> >> >> > independent
>>> >> > > > >> >> variable
>>> >> > > > >> >> >> and
>>> >> > > > >> >> >> > the other using valid hour, with slide 29 of
Geoff
>>> >> > > > >> >> >> > Manikin's
>>> >> > > MEG
>>> >> > > > >> >> >> > presentation (attached).
>>> >> > > > >> >> >> >
>>> >> > > > >> >> >> > The plots for initialization hour seem to
match quite
>>> >> > > > >> >> >> > closely
>>> >> > > to
>>> >> > > > >> the
>>> >> > > > >> >> >> valid
>>> >> > > > >> >> >> > hour plots on slide 29 (provided by GSD),
especially
>>> for
>>> >> > > > >> >> >> > the
>>> >> > > > >> >> operational
>>> >> > > > >> >> >> > HRRR, whereas the plots for valid hour are
phase
>>> shifted
>>> >> > > > >> >> >> > by 12
>>> >> > > > >> hours.
>>> >> > > > >> >> >> I'm
>>> >> > > > >> >> >> > definitely plotting over the correct region
(East US)
>>> >> > > > >> >> >> > and I'm
>>> >> > > > >> using
>>> >> > > > >> >> all
>>> >> > > > >> >> >> > 12-hr forecasts (lead time is fixed at 12
hours) over
>>> >> > > > >> >> >> > the same
>>> >> > > > >> time
>>> >> > > > >> >> >> period
>>> >> > > > >> >> >> > as GSD.
>>> >> > > > >> >> >> >
>>> >> > > > >> >> >> > Thank you!
>>> >> > > > >> >> >> > Ben Blake (EMC)
>>> >> > > > >> >> >> >
>>> >> > > > >> >> >> >
>>> >> > > > >> >> >>
>>> >> > > > >> >> >>
>>> >> > > > >> >> >
>>> >> > > > >> >>
>>> >> > > > >> >>
>>> >> > > > >> >
>>> >> > > > >>
>>> >> > > > >>
>>> >> > > > >
>>> >> > > >
>>> >> > > >
>>> >> > >
>>> >> > >
>>> >>
>>> >>
>>> >>
>>> >>
>>> >
>>>
>>>
>>
>
------------------------------------------------
More information about the Met_help
mailing list