[Met_help] [rt.rap.ucar.edu #82818] History for 1 Jan 1970 files written when model fields missing

Tue Nov 7 14:28:02 MST 2017

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

Dear MET help,

I'm running MET v6.0 and noticed something odd when doing upper-level verification on my nested WRF domain d02.
First, let me note that I de-activated outputting upper-level fields for my nested grid so I'm only writing upper-level fields to d01.

Given that, when I tried running point_stat on the upper-level fields for d02, instead of ending in an error, point_stat proceeded to write null/0 size output files with a date/time stamp of 1 Jan 1970.  It gave a warning about not finding the fields in the model data.

Is there a way I can ensure that MET will quit with an error instead of writing out all these files when encountering a model field that is not present in the GRIB2 WRF files?

Thanks much,
Jon

*****************************************************
Jonathan Case (Jon)
ENSCO, Inc./NASA SPoRT Center
National Space Science and Technology Center
320 Sparkman Drive, Room 3000B
Huntsville, AL 35805
Jonathan.Case-1 at nasa.gov<mailto:Jonathan.Case-1 at nasa.gov> (alt: case.jonathan at ensco.com<mailto:case.jonathan at ensco.com>)
*****************************************************

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

Subject: 1 Jan 1970 files written when model fields missing
From: John Halley Gotway
Time: Thu Nov 02 15:56:03 2017

Jon,

Thanks for letting us know about this behavior.

The desired functionality is that it would try to process all the
requested
fields.  If no data is found a for a field, it prints a warning
message and
continues on to the next one.

I suspect we're missing the logic that if none of the input fields are
present at all, it should error out.

I'll replicate the behavior here and make sure we add that in for
version
6.1.

For now, you do have one option.  There's a config file option named
"exit_on_warning" that is set to false by default.  If you reset it to
true
then any warning messages encountered will result in the tool exiting
with
bad status:

// Warning message results in tool exiting.
exit_on_warning = FALSE;

That'd do the job... but maybe too well?  You'd need to see if any of
you
successful runs actually contain any warning messages.

Thanks,
John Halley Gotway

On Wed, Nov 1, 2017 at 2:45 PM, Case, Jonathan[ENSCO INC] via RT <
met_help at ucar.edu> wrote:

>
> Wed Nov 01 14:45:31 2017: Request 82818 was acted upon.
> Transaction: Ticket created by jonathan.case-1 at nasa.gov
>        Queue: met_help
>      Subject: 1 Jan 1970 files written when model fields missing
>        Owner: Nobody
>   Requestors: jonathan.case-1 at nasa.gov
>       Status: new
>  Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=82818 >
>
>
> Dear MET help,
>
> I'm running MET v6.0 and noticed something odd when doing upper-
level
> verification on my nested WRF domain d02.
> First, let me note that I de-activated outputting upper-level fields
for
> my nested grid so I'm only writing upper-level fields to d01.
>
> Given that, when I tried running point_stat on the upper-level
fields for
> d02, instead of ending in an error, point_stat proceeded to write
null/0
> size output files with a date/time stamp of 1 Jan 1970.  It gave a
warning
> about not finding the fields in the model data.
>
> Is there a way I can ensure that MET will quit with an error instead
of
> writing out all these files when encountering a model field that is
not
> present in the GRIB2 WRF files?
>
> Thanks much,
> Jon
>
> *****************************************************
> Jonathan Case (Jon)
> ENSCO, Inc./NASA SPoRT Center
> National Space Science and Technology Center
> 320 Sparkman Drive, Room 3000B
> Huntsville, AL 35805
> Jonathan.Case-1 at nasa.gov<mailto:Jonathan.Case-1 at nasa.gov> (alt:
> case.jonathan at ensco.com<mailto:case.jonathan at ensco.com>)
> *****************************************************
>
>
>

------------------------------------------------
Subject: 1 Jan 1970 files written when model fields missing
From: John Halley Gotway
Time: Fri Nov 03 17:38:27 2017

Jon,

I added checks to point_stat and grid_stat to error out with bad
status
when this occurs.  Very easy check to add to the development trunk for
the
next release.  If it'd be helpful, I could post a bugfix with these
checks
for met-6.0.  Just let me know.

Thanks,
John

On Thu, Nov 2, 2017 at 3:56 PM, The RT System itself via RT <
met_help at ucar.edu> wrote:

>
> Thu Nov 02 15:56:03 2017: Request 82818 was acted upon.
> Transaction: Given to johnhg (John Halley Gotway) by RT_System
>        Queue: met_help
>      Subject: 1 Jan 1970 files written when model fields missing
>        Owner: johnhg
>   Requestors: jonathan.case-1 at nasa.gov
>       Status: new
>  Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=82818 >
>
>
> This transaction appears to have no content
>

------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #82818] 1 Jan 1970 files written when model fields missing
From: Case, Jonathan[ENSCO INC]
Time: Tue Nov 07 13:35:36 2017

John H-G,

Thanks for the recommendation.  That might be a little "too good" of
an option.  For now, I'll try to remember not to process upper-level
verification when no model fields exist.

-JonC

-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Thursday, November 2, 2017 4:56 PM
To: Case, Jonathan (MSFC-ST11)[ENSCO INC] <jonathan.case-1 at nasa.gov>
Subject: Re: [rt.rap.ucar.edu #82818] 1 Jan 1970 files written when
model fields missing

Jon,

Thanks for letting us know about this behavior.

The desired functionality is that it would try to process all the
requested fields.  If no data is found a for a field, it prints a
warning message and continues on to the next one.

I suspect we're missing the logic that if none of the input fields are
present at all, it should error out.

I'll replicate the behavior here and make sure we add that in for
version 6.1.

For now, you do have one option.  There's a config file option named
"exit_on_warning" that is set to false by default.  If you reset it to
true then any warning messages encountered will result in the tool
exiting with bad status:

// Warning message results in tool exiting.
exit_on_warning = FALSE;

That'd do the job... but maybe too well?  You'd need to see if any of
you successful runs actually contain any warning messages.

Thanks,
John Halley Gotway

On Wed, Nov 1, 2017 at 2:45 PM, Case, Jonathan[ENSCO INC] via RT <
met_help at ucar.edu> wrote:

>
> Wed Nov 01 14:45:31 2017: Request 82818 was acted upon.
> Transaction: Ticket created by jonathan.case-1 at nasa.gov
>        Queue: met_help
>      Subject: 1 Jan 1970 files written when model fields missing
>        Owner: Nobody
>   Requestors: jonathan.case-1 at nasa.gov
>       Status: new
>  Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=82818
> >
>
>
> Dear MET help,
>
> I'm running MET v6.0 and noticed something odd when doing upper-
level
> verification on my nested WRF domain d02.
> First, let me note that I de-activated outputting upper-level fields
> for my nested grid so I'm only writing upper-level fields to d01.
>
> Given that, when I tried running point_stat on the upper-level
fields
> for d02, instead of ending in an error, point_stat proceeded to
write
> null/0 size output files with a date/time stamp of 1 Jan 1970.  It
> gave a warning about not finding the fields in the model data.
>
> Is there a way I can ensure that MET will quit with an error instead
> of writing out all these files when encountering a model field that
is
> not present in the GRIB2 WRF files?
>
> Thanks much,
> Jon
>
> *****************************************************
> Jonathan Case (Jon)
> ENSCO, Inc./NASA SPoRT Center
> National Space Science and Technology Center
> 320 Sparkman Drive, Room 3000B
> Huntsville, AL 35805
> Jonathan.Case-1 at nasa.gov<mailto:Jonathan.Case-1 at nasa.gov> (alt:
> case.jonathan at ensco.com<mailto:case.jonathan at ensco.com>)
> *****************************************************
>
>
>

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