[Met_help] [rt.rap.ucar.edu #56988] History for Running point_stat with NCAR ds337 ncdf files

John Halley Gotway via RT met_help at ucar.edu
Wed Jul 11 13:00:22 MDT 2012


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

Hello,

I have recently upgraded to v3.1 of MET and am running point_stat for 
the first time on two separate machines - one locally, with the other 
being NASA Ames' Pleiades. I am trying to use the netcdf PrepBufr obs 
files obtained from NCAR's dss337, however, all attempts to run 
point_stat terminate with this error:

DEBUG 1: Default Config File: 
/u/jmhender/NWP/WRF-MET/METv3.1/data/config/PointStatConfig_default
DEBUG 1: User Config File: 
PointStatConfig_V3.1-SLC-case03.20120614.13.47.57.UTC
DEBUG 1: Forecast File: 
/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib
DEBUG 1: Climatology File: none
DEBUG 1: Observation File: 
/nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090101.nc
DEBUG 1: Observation File: 
/nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090102.nc
DEBUG 2:
DEBUG 2: 
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Reading data for TMP/P200.
DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found range match for 
VarInfo "TMP/P200" in GRIB record 81 of GRIB file 
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found 1 GRIB records 
matching VarInfo "TMP/P200" in GRIB file 
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
DEBUG 4: parse_sid_mask() ->  parsing station ID mask file "(nul)"
DEBUG 4: parse_grid_mask() ->  parsing grid mask "FULL"
DEBUG 2: For TMP/P200 found 1 forecast levels and 0 climatology levels.
DEBUG 2:

...

DEBUG 3: Rotating U and V wind components from grid-relative to 
earth-relative.
DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found 1 GRIB records 
matching VarInfo "32/Z010" in GRIB file 
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
DEBUG 3: MetGrib1DataFile::data_plane_array() -> Reading V-wind records.
DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found range match for 
VarInfo "32/Z010" in GRIB record 294 of GRIB file 
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
DEBUG 3: MetGrib1DataFile::rotate_winds() -> Have V-wind record, reading 
U-wind record.
DEBUG 3: MetGrib1DataFile::data_plane_scalar() -> Found exact match for 
VarInfo "32/Z010" in GRIB record 293 of GRIB file 
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
DEBUG 3: Rotating U and V wind components from grid-relative to 
earth-relative.
DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found 1 GRIB records 
matching VarInfo "32/Z010" in GRIB file 
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
DEBUG 3: Deriving wind speed from U and V wind components.
DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found 1 GRIB records 
matching VarInfo "32/Z010" in GRIB file 
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
DEBUG 2: For 32/Z010 found 1 forecast levels and 0 climatology levels.
DEBUG 2:
DEBUG 2: 
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Searching 2979273 observations from 85274 messages.
ERROR  :
ERROR  : process_obs_file() -> can't read the header array record for 
header number 85274
ERROR  :

I was wondering if this perhaps is something related to my build of 
METv3.1, the way I am calling point_stat, or perhaps a bug in the ncdf 
files. Note that the test script provided with METv3.1 seems to work 
just fine.

Any help would be much appreciated.

Thanks.

John Henderson



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

Subject: Re: [rt.rap.ucar.edu #56988] Running point_stat with NCAR ds337 ncdf files
From: John Halley Gotway
Time: Thu Jun 14 10:36:24 2012

John,

Very good question.  Can you please clarify one thing for me?

Are you retrieving the PrepBufr files themselves from this ds337 link:
    http://rda.ucar.edu/datasets/ds337.0
And then running them through the PB2NC tool to pre-process them?

Or are you using the subset request form at this link:
    http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php
And using that data as input into Point-Stat directly?

I need to figure out which avenue needs debugging.

Thanks,
John

On 06/14/2012 09:59 AM, jhenders at aer.com via RT wrote:
>
> Thu Jun 14 09:59:39 2012: Request 56988 was acted upon.
> Transaction: Ticket created by jhenders at aer.com
>         Queue: met_help
>       Subject: Running point_stat with NCAR ds337 ncdf files
>         Owner: Nobody
>    Requestors: jhenders at aer.com
>        Status: new
>   Ticket<URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988>
>
>
> Hello,
>
> I have recently upgraded to v3.1 of MET and am running point_stat
for
> the first time on two separate machines - one locally, with the
other
> being NASA Ames' Pleiades. I am trying to use the netcdf PrepBufr
obs
> files obtained from NCAR's dss337, however, all attempts to run
> point_stat terminate with this error:
>
> DEBUG 1: Default Config File:
> /u/jmhender/NWP/WRF-MET/METv3.1/data/config/PointStatConfig_default
> DEBUG 1: User Config File:
> PointStatConfig_V3.1-SLC-case03.20120614.13.47.57.UTC
> DEBUG 1: Forecast File:
> /nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib
> DEBUG 1: Climatology File: none
> DEBUG 1: Observation File:
> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090101.nc
> DEBUG 1: Observation File:
> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090102.nc
> DEBUG 2:
> DEBUG 2:
>
--------------------------------------------------------------------------------
> DEBUG 2:
> DEBUG 2: Reading data for TMP/P200.
> DEBUG 3: MetGrib1DataFile::data_plane_array() ->  Found range match
for
> VarInfo "TMP/P200" in GRIB record 81 of GRIB file
>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
> DEBUG 3: MetGrib1DataFile::data_plane_array() ->  Found 1 GRIB
records
> matching VarInfo "TMP/P200" in GRIB file
>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
> DEBUG 4: parse_sid_mask() ->   parsing station ID mask file "(nul)"
> DEBUG 4: parse_grid_mask() ->   parsing grid mask "FULL"
> DEBUG 2: For TMP/P200 found 1 forecast levels and 0 climatology
levels.
> DEBUG 2:
>
> ...
>
> DEBUG 3: Rotating U and V wind components from grid-relative to
> earth-relative.
> DEBUG 3: MetGrib1DataFile::data_plane_array() ->  Found 1 GRIB
records
> matching VarInfo "32/Z010" in GRIB file
>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
> DEBUG 3: MetGrib1DataFile::data_plane_array() ->  Reading V-wind
records.
> DEBUG 3: MetGrib1DataFile::data_plane_array() ->  Found range match
for
> VarInfo "32/Z010" in GRIB record 294 of GRIB file
>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
> DEBUG 3: MetGrib1DataFile::rotate_winds() ->  Have V-wind record,
reading
> U-wind record.
> DEBUG 3: MetGrib1DataFile::data_plane_scalar() ->  Found exact match
for
> VarInfo "32/Z010" in GRIB record 293 of GRIB file
>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
> DEBUG 3: Rotating U and V wind components from grid-relative to
> earth-relative.
> DEBUG 3: MetGrib1DataFile::data_plane_array() ->  Found 1 GRIB
records
> matching VarInfo "32/Z010" in GRIB file
>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
> DEBUG 3: Deriving wind speed from U and V wind components.
> DEBUG 3: MetGrib1DataFile::data_plane_array() ->  Found 1 GRIB
records
> matching VarInfo "32/Z010" in GRIB file
>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
> DEBUG 2: For 32/Z010 found 1 forecast levels and 0 climatology
levels.
> DEBUG 2:
> DEBUG 2:
>
--------------------------------------------------------------------------------
> DEBUG 2:
> DEBUG 2: Searching 2979273 observations from 85274 messages.
> ERROR  :
> ERROR  : process_obs_file() ->  can't read the header array record
for
> header number 85274
> ERROR  :
>
> I was wondering if this perhaps is something related to my build of
> METv3.1, the way I am calling point_stat, or perhaps a bug in the
ncdf
> files. Note that the test script provided with METv3.1 seems to work
> just fine.
>
> Any help would be much appreciated.
>
> Thanks.
>
> John Henderson
>

------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #56988] Running point_stat with NCAR ds337 ncdf files
From: jhenders at aer.com
Time: Thu Jun 14 12:12:22 2012

Hello again John,

Thanks again for your prompt response. The quick answer is that I have
tried both ways.

Originally I retrieved the netcdf files directly from
http://rda.ucar.edu/dsszone/ds337.0/index.html?g=5.

Having this new archive of netcdf files at NCAR was a welcome
discovery,
except that they are global files and point_stat took 3 h on NASA's
Pleiades before failing with the error I provided.

To test further, I then requested netcdf files for a geographical
subregion via
http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php.
That again fails (much faster) with the same error.

I should note that I have only used point_stat with netcdf obs files
from 20090901 and 20090902. The error shows up on both a local linux
cluster as well as on Pleiades.

In the past hour I have retrieved a PrepBufr file from NCAR and run
pb2nc on Pleiades. I then provide that ncdf file to point_stat. I was
able to get past the error, though (for unknown reasons) I am not
finding any successful matches.

This suggests a problem with the ncdf files at NCAR.

Thanks.

John


On 6/14/12 12:36 PM, John Halley Gotway via RT wrote:
> John,
>
> Very good question.  Can you please clarify one thing for me?
>
> Are you retrieving the PrepBufr files themselves from this ds337
link:
>      http://rda.ucar.edu/datasets/ds337.0
> And then running them through the PB2NC tool to pre-process them?
>
> Or are you using the subset request form at this link:
>      http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php
> And using that data as input into Point-Stat directly?
>
> I need to figure out which avenue needs debugging.
>
> Thanks,
> John
>
> On 06/14/2012 09:59 AM, jhenders at aer.com via RT wrote:
>> Thu Jun 14 09:59:39 2012: Request 56988 was acted upon.
>> Transaction: Ticket created by jhenders at aer.com
>>          Queue: met_help
>>        Subject: Running point_stat with NCAR ds337 ncdf files
>>          Owner: Nobody
>>     Requestors: jhenders at aer.com
>>         Status: new
>>    Ticket<URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988>
>>
>>
>> Hello,
>>
>> I have recently upgraded to v3.1 of MET and am running point_stat
for
>> the first time on two separate machines - one locally, with the
other
>> being NASA Ames' Pleiades. I am trying to use the netcdf PrepBufr
obs
>> files obtained from NCAR's dss337, however, all attempts to run
>> point_stat terminate with this error:
>>
>> DEBUG 1: Default Config File:
>> /u/jmhender/NWP/WRF-MET/METv3.1/data/config/PointStatConfig_default
>> DEBUG 1: User Config File:
>> PointStatConfig_V3.1-SLC-case03.20120614.13.47.57.UTC
>> DEBUG 1: Forecast File:
>> /nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib
>> DEBUG 1: Climatology File: none
>> DEBUG 1: Observation File:
>> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090101.nc
>> DEBUG 1: Observation File:
>> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090102.nc
>> DEBUG 2:
>> DEBUG 2:
>>
--------------------------------------------------------------------------------
>> DEBUG 2:
>> DEBUG 2: Reading data for TMP/P200.
>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found range
match for
>> VarInfo "TMP/P200" in GRIB record 81 of GRIB file
>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1 GRIB
records
>> matching VarInfo "TMP/P200" in GRIB file
>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>> DEBUG 4: parse_sid_mask() ->    parsing station ID mask file
"(nul)"
>> DEBUG 4: parse_grid_mask() ->    parsing grid mask "FULL"
>> DEBUG 2: For TMP/P200 found 1 forecast levels and 0 climatology
levels.
>> DEBUG 2:
>>
>> ...
>>
>> DEBUG 3: Rotating U and V wind components from grid-relative to
>> earth-relative.
>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1 GRIB
records
>> matching VarInfo "32/Z010" in GRIB file
>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Reading V-wind
records.
>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found range
match for
>> VarInfo "32/Z010" in GRIB record 294 of GRIB file
>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>> DEBUG 3: MetGrib1DataFile::rotate_winds() ->   Have V-wind record,
reading
>> U-wind record.
>> DEBUG 3: MetGrib1DataFile::data_plane_scalar() ->   Found exact
match for
>> VarInfo "32/Z010" in GRIB record 293 of GRIB file
>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>> DEBUG 3: Rotating U and V wind components from grid-relative to
>> earth-relative.
>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1 GRIB
records
>> matching VarInfo "32/Z010" in GRIB file
>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>> DEBUG 3: Deriving wind speed from U and V wind components.
>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1 GRIB
records
>> matching VarInfo "32/Z010" in GRIB file
>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>> DEBUG 2: For 32/Z010 found 1 forecast levels and 0 climatology
levels.
>> DEBUG 2:
>> DEBUG 2:
>>
--------------------------------------------------------------------------------
>> DEBUG 2:
>> DEBUG 2: Searching 2979273 observations from 85274 messages.
>> ERROR  :
>> ERROR  : process_obs_file() ->   can't read the header array record
for
>> header number 85274
>> ERROR  :
>>
>> I was wondering if this perhaps is something related to my build of
>> METv3.1, the way I am calling point_stat, or perhaps a bug in the
ncdf
>> files. Note that the test script provided with METv3.1 seems to
work
>> just fine.
>>
>> Any help would be much appreciated.
>>
>> Thanks.
>>
>> John Henderson
>>

------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #56988] Running point_stat with NCAR ds337 ncdf files
From: John Halley Gotway
Time: Thu Jun 14 12:47:59 2012

John,

I tried to replicate the error you're seeing but was not immediately
able to do so.  I went to the page you sent:
    http://rda.ucar.edu/dsszone/ds337.0/index.html?g=5

And retrieved some data:
    netcdf.gdas.2009010100.nc
    netcdf.gdas.2009010106.nc

When I run point_stat against it, it runs fine.  I tried using both
the originally released METv3.1 and the version with the latest set of
patches applied.  I'm not able to produce the error using either.

Here are some questions:

- Am I looking at the right dates?  In your message you say 20090901
and 20090902, but in the command you sent it's 20090101 and 20090102.
I tested with January, 2009 data, but should I be looking
September 2009 data instead?

- I'm not sure where exactly you got this file:
/nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090101.nc
On ds337.0, the file names are "netcdf.gdas.YYYYMMDDHH.nc" - but yours
is missing the "HH".  How did you get a single file for the entire
day?

You mentioned getting 0 matched pairs, and not knowing why.  Please
try running Point-Stat with "-v 3", that'll dump out more verbose
output and give you more detailed information for each
verification task.  Something like the following:

DEBUG 2: Processing VGRD/Z10 versus VGRD/Z10, for observation type
ADPSFC, over region DTC165, for interpolation method UW_MEAN(1), using
9998 pairs.
DEBUG 3: Number of matched pairs  = 9998
DEBUG 3: Observations processed   = 2920139
DEBUG 3: Rejected: GRIB code      = 2322261
DEBUG 3: Rejected: valid time     = 0
DEBUG 3: Rejected: bad obs value  = 0
DEBUG 3: Rejected: off the grid   = 486827
DEBUG 3: Rejected: level mismatch = 61549
DEBUG 3: Rejected: message type   = 5863
DEBUG 3: Rejected: masking region = 33641
DEBUG 3: Rejected: bad fcst value = 0

That way you can tell why the observation are not be used in each
verification task.

Lastly, I think a very possible scenario is that those NetCDF files in
ds337.0 were generated using an earlier version of the PB2NC tool, and
the Point-Stat tool is not handling them well.  But if
that really is the case, then I should be able to reproduce the error
here.

If you'd like, you could bundle up a model file, NetCDF point
observation file, and Point-Stat config file that demonstrate the
error and post them to our ftp site.  I could grab them, reproduce the
error here, and then figure out what's going wrong.  Here's
instructions for posting to our ftp site:
    http://www.dtcenter.org/met/users/support/met_help.php#ftp

Thanks,
John


On 06/14/2012 12:12 PM, jhenders at aer.com via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>
> Hello again John,
>
> Thanks again for your prompt response. The quick answer is that I
have
> tried both ways.
>
> Originally I retrieved the netcdf files directly from
> http://rda.ucar.edu/dsszone/ds337.0/index.html?g=5.
>
> Having this new archive of netcdf files at NCAR was a welcome
discovery,
> except that they are global files and point_stat took 3 h on NASA's
> Pleiades before failing with the error I provided.
>
> To test further, I then requested netcdf files for a geographical
> subregion via
http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php.
> That again fails (much faster) with the same error.
>
> I should note that I have only used point_stat with netcdf obs files
> from 20090901 and 20090902. The error shows up on both a local linux
> cluster as well as on Pleiades.
>
> In the past hour I have retrieved a PrepBufr file from NCAR and run
> pb2nc on Pleiades. I then provide that ncdf file to point_stat. I
was
> able to get past the error, though (for unknown reasons) I am not
> finding any successful matches.
>
> This suggests a problem with the ncdf files at NCAR.
>
> Thanks.
>
> John
>
>
> On 6/14/12 12:36 PM, John Halley Gotway via RT wrote:
>> John,
>>
>> Very good question.  Can you please clarify one thing for me?
>>
>> Are you retrieving the PrepBufr files themselves from this ds337
link:
>>       http://rda.ucar.edu/datasets/ds337.0
>> And then running them through the PB2NC tool to pre-process them?
>>
>> Or are you using the subset request form at this link:
>>       http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php
>> And using that data as input into Point-Stat directly?
>>
>> I need to figure out which avenue needs debugging.
>>
>> Thanks,
>> John
>>
>> On 06/14/2012 09:59 AM, jhenders at aer.com via RT wrote:
>>> Thu Jun 14 09:59:39 2012: Request 56988 was acted upon.
>>> Transaction: Ticket created by jhenders at aer.com
>>>           Queue: met_help
>>>         Subject: Running point_stat with NCAR ds337 ncdf files
>>>           Owner: Nobody
>>>      Requestors: jhenders at aer.com
>>>          Status: new
>>>     Ticket<URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988>
>>>
>>>
>>> Hello,
>>>
>>> I have recently upgraded to v3.1 of MET and am running point_stat
for
>>> the first time on two separate machines - one locally, with the
other
>>> being NASA Ames' Pleiades. I am trying to use the netcdf PrepBufr
obs
>>> files obtained from NCAR's dss337, however, all attempts to run
>>> point_stat terminate with this error:
>>>
>>> DEBUG 1: Default Config File:
>>> /u/jmhender/NWP/WRF-
MET/METv3.1/data/config/PointStatConfig_default
>>> DEBUG 1: User Config File:
>>> PointStatConfig_V3.1-SLC-case03.20120614.13.47.57.UTC
>>> DEBUG 1: Forecast File:
>>> /nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib
>>> DEBUG 1: Climatology File: none
>>> DEBUG 1: Observation File:
>>> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090101.nc
>>> DEBUG 1: Observation File:
>>> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090102.nc
>>> DEBUG 2:
>>> DEBUG 2:
>>>
--------------------------------------------------------------------------------
>>> DEBUG 2:
>>> DEBUG 2: Reading data for TMP/P200.
>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found range
match for
>>> VarInfo "TMP/P200" in GRIB record 81 of GRIB file
>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1 GRIB
records
>>> matching VarInfo "TMP/P200" in GRIB file
>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>> DEBUG 4: parse_sid_mask() ->    parsing station ID mask file
"(nul)"
>>> DEBUG 4: parse_grid_mask() ->    parsing grid mask "FULL"
>>> DEBUG 2: For TMP/P200 found 1 forecast levels and 0 climatology
levels.
>>> DEBUG 2:
>>>
>>> ...
>>>
>>> DEBUG 3: Rotating U and V wind components from grid-relative to
>>> earth-relative.
>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1 GRIB
records
>>> matching VarInfo "32/Z010" in GRIB file
>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Reading V-wind
records.
>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found range
match for
>>> VarInfo "32/Z010" in GRIB record 294 of GRIB file
>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>> DEBUG 3: MetGrib1DataFile::rotate_winds() ->   Have V-wind record,
reading
>>> U-wind record.
>>> DEBUG 3: MetGrib1DataFile::data_plane_scalar() ->   Found exact
match for
>>> VarInfo "32/Z010" in GRIB record 293 of GRIB file
>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>> DEBUG 3: Rotating U and V wind components from grid-relative to
>>> earth-relative.
>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1 GRIB
records
>>> matching VarInfo "32/Z010" in GRIB file
>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>> DEBUG 3: Deriving wind speed from U and V wind components.
>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1 GRIB
records
>>> matching VarInfo "32/Z010" in GRIB file
>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>> DEBUG 2: For 32/Z010 found 1 forecast levels and 0 climatology
levels.
>>> DEBUG 2:
>>> DEBUG 2:
>>>
--------------------------------------------------------------------------------
>>> DEBUG 2:
>>> DEBUG 2: Searching 2979273 observations from 85274 messages.
>>> ERROR  :
>>> ERROR  : process_obs_file() ->   can't read the header array
record for
>>> header number 85274
>>> ERROR  :
>>>
>>> I was wondering if this perhaps is something related to my build
of
>>> METv3.1, the way I am calling point_stat, or perhaps a bug in the
ncdf
>>> files. Note that the test script provided with METv3.1 seems to
work
>>> just fine.
>>>
>>> Any help would be much appreciated.
>>>
>>> Thanks.
>>>
>>> John Henderson
>>>


------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #56988] Running point_stat with NCAR ds337 ncdf files
From: jhenders at aer.com
Time: Thu Jun 14 13:17:55 2012

John,

Thank you for trying to reproduce. I now suspect that the problem lies
in my use of an nco tool to join the four six-hourly ncdf files from
NCAR into one daily file (correct date is 20090101 - sorry). That
explains the naming convention you mention below. Perhaps I'm issuing
that incorrectly or otherwise that is not an appropriate tool to use.
I
used the nco tool to limit the number of files that I had to provide
at
the command line.

I will let you know the results of a rerun soon.

Thanks.

John


------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #56988] Running point_stat with NCAR ds337 ncdf files
From: John Halley Gotway
Time: Thu Jun 14 13:42:56 2012

John,

Yes, that does sound like the likely culprit.

John

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>
> John,
>
> Thank you for trying to reproduce. I now suspect that the problem
lies
> in my use of an nco tool to join the four six-hourly ncdf files from
> NCAR into one daily file (correct date is 20090101 - sorry). That
> explains the naming convention you mention below. Perhaps I'm
issuing
> that incorrectly or otherwise that is not an appropriate tool to
use. I
> used the nco tool to limit the number of files that I had to provide
at
> the command line.
>
> I will let you know the results of a rerun soon.
>
> Thanks.
>
> John
>
>



------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #56988] Running point_stat with NCAR ds337 ncdf files
From: jhenders at aer.com
Time: Thu Jun 14 13:46:18 2012

John,

Earlier I believe I had confirmed that the number of obs in the
combined
file equalled the sum of those in the individual files. Something may
still be awry, of course. As I mentioned earlier, I will report on
subsequent tests when they finish.

Thanks again.

Regards,

John

On 6/14/12 3:42 PM, John Halley Gotway via RT wrote:
> John,
>
> Yes, that does sound like the likely culprit.
>
> John
>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988>
>>
>> John,
>>
>> Thank you for trying to reproduce. I now suspect that the problem
lies
>> in my use of an nco tool to join the four six-hourly ncdf files
from
>> NCAR into one daily file (correct date is 20090101 - sorry). That
>> explains the naming convention you mention below. Perhaps I'm
issuing
>> that incorrectly or otherwise that is not an appropriate tool to
use. I
>> used the nco tool to limit the number of files that I had to
provide at
>> the command line.
>>
>> I will let you know the results of a rerun soon.
>>
>> Thanks.
>>
>> John
>>
>>
>
>

------------------------------------------------
Subject: Running point_stat with NCAR ds337 ncdf files
From: jhenders at aer.com
Time: Fri Jun 29 10:52:09 2012

Hello again John,

I am now back on this task and have been able to run METv3.1's
point_stat successfully for obs types other than ADPSFC. I am running
with '-v 4'. For METv2 I had no problems getting 2-m temperature or
10-m
winds working in MET... The obs file I am using was geographically
restricted to G212 by METv3.1's pb2nc.

Any ideas? Attached is my PointStat config file and Point_Stat output.

I also have two points of clarification: 1) I inadvertently omitted
thresholds in fcst_thresh for all the fields, however, the code did
not
complain, and 2) Your notation below of Z10 doesn't agree with the
documentation or code which states ZNNN as the proper level format.
The
code seems to work either way.

Please let me know if the above two points make sense and whether any
action is required.

Thanks.

John




On 6/14/12 2:47 PM, John Halley Gotway via RT wrote:
> You mentioned getting 0 matched pairs, and not knowing why.  Please
try running Point-Stat with "-v 3", that'll dump out more verbose
output and give you more detailed information for each
> verification task.  Something like the following:
>
> DEBUG 2: Processing VGRD/Z10 versus VGRD/Z10, for observation type
ADPSFC, over region DTC165, for interpolation method UW_MEAN(1), using
9998 pairs.
> DEBUG 3: Number of matched pairs  = 9998
> DEBUG 3: Observations processed   = 2920139
> DEBUG 3: Rejected: GRIB code      = 2322261
> DEBUG 3: Rejected: valid time     = 0
> DEBUG 3: Rejected: bad obs value  = 0
> DEBUG 3: Rejected: off the grid   = 486827
> DEBUG 3: Rejected: level mismatch = 61549
> DEBUG 3: Rejected: message type   = 5863
> DEBUG 3: Rejected: masking region = 33641
> DEBUG 3: Rejected: bad fcst value = 0
>
> That way you can tell why the observation are not be used in each
verification task.
>
> Lastly, I think a very possible scenario is that those NetCDF files
in ds337.0 were generated using an earlier version of the PB2NC tool,
and the Point-Stat tool is not handling them well.  But if
> that really is the case, then I should be able to reproduce the
error here.
>
> If you'd like, you could bundle up a model file, NetCDF point
observation file, and Point-Stat config file that demonstrate the
error and post them to our ftp site.  I could grab them, reproduce the
> error here, and then figure out what's going wrong.  Here's
instructions for posting to our ftp site:
>      http://www.dtcenter.org/met/users/support/met_help.php#ftp
>
> Thanks,
> John
>
>
> On 06/14/2012 12:12 PM, jhenders at aer.com via RT wrote:
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>>
>> Hello again John,
>>
>> Thanks again for your prompt response. The quick answer is that I
have
>> tried both ways.
>>
>> Originally I retrieved the netcdf files directly from
>> http://rda.ucar.edu/dsszone/ds337.0/index.html?g=5.
>>
>> Having this new archive of netcdf files at NCAR was a welcome
discovery,
>> except that they are global files and point_stat took 3 h on NASA's
>> Pleiades before failing with the error I provided.
>>
>> To test further, I then requested netcdf files for a geographical
>> subregion via
http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php.
>> That again fails (much faster) with the same error.
>>
>> I should note that I have only used point_stat with netcdf obs
files
>> from 20090901 and 20090902. The error shows up on both a local
linux
>> cluster as well as on Pleiades.
>>
>> In the past hour I have retrieved a PrepBufr file from NCAR and run
>> pb2nc on Pleiades. I then provide that ncdf file to point_stat. I
was
>> able to get past the error, though (for unknown reasons) I am not
>> finding any successful matches.
>>
>> This suggests a problem with the ncdf files at NCAR.
>>
>> Thanks.
>>
>> John
>>
>>
>> On 6/14/12 12:36 PM, John Halley Gotway via RT wrote:
>>> John,
>>>
>>> Very good question.  Can you please clarify one thing for me?
>>>
>>> Are you retrieving the PrepBufr files themselves from this ds337
link:
>>>        http://rda.ucar.edu/datasets/ds337.0
>>> And then running them through the PB2NC tool to pre-process them?
>>>
>>> Or are you using the subset request form at this link:
>>>        http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php
>>> And using that data as input into Point-Stat directly?
>>>
>>> I need to figure out which avenue needs debugging.
>>>
>>> Thanks,
>>> John
>>>
>>> On 06/14/2012 09:59 AM, jhenders at aer.com via RT wrote:
>>>> Thu Jun 14 09:59:39 2012: Request 56988 was acted upon.
>>>> Transaction: Ticket created by jhenders at aer.com
>>>>            Queue: met_help
>>>>          Subject: Running point_stat with NCAR ds337 ncdf files
>>>>            Owner: Nobody
>>>>       Requestors: jhenders at aer.com
>>>>           Status: new
>>>>      Ticket<URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988>
>>>>
>>>>
>>>> Hello,
>>>>
>>>> I have recently upgraded to v3.1 of MET and am running point_stat
for
>>>> the first time on two separate machines - one locally, with the
other
>>>> being NASA Ames' Pleiades. I am trying to use the netcdf PrepBufr
obs
>>>> files obtained from NCAR's dss337, however, all attempts to run
>>>> point_stat terminate with this error:
>>>>
>>>> DEBUG 1: Default Config File:
>>>> /u/jmhender/NWP/WRF-
MET/METv3.1/data/config/PointStatConfig_default
>>>> DEBUG 1: User Config File:
>>>> PointStatConfig_V3.1-SLC-case03.20120614.13.47.57.UTC
>>>> DEBUG 1: Forecast File:
>>>>
/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib
>>>> DEBUG 1: Climatology File: none
>>>> DEBUG 1: Observation File:
>>>> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090101.nc
>>>> DEBUG 1: Observation File:
>>>> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090102.nc
>>>> DEBUG 2:
>>>> DEBUG 2:
>>>>
--------------------------------------------------------------------------------
>>>> DEBUG 2:
>>>> DEBUG 2: Reading data for TMP/P200.
>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found range
match for
>>>> VarInfo "TMP/P200" in GRIB record 81 of GRIB file
>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1 GRIB
records
>>>> matching VarInfo "TMP/P200" in GRIB file
>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>> DEBUG 4: parse_sid_mask() ->    parsing station ID mask file
"(nul)"
>>>> DEBUG 4: parse_grid_mask() ->    parsing grid mask "FULL"
>>>> DEBUG 2: For TMP/P200 found 1 forecast levels and 0 climatology
levels.
>>>> DEBUG 2:
>>>>
>>>> ...
>>>>
>>>> DEBUG 3: Rotating U and V wind components from grid-relative to
>>>> earth-relative.
>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1 GRIB
records
>>>> matching VarInfo "32/Z010" in GRIB file
>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Reading V-wind
records.
>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found range
match for
>>>> VarInfo "32/Z010" in GRIB record 294 of GRIB file
>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>> DEBUG 3: MetGrib1DataFile::rotate_winds() ->   Have V-wind
record, reading
>>>> U-wind record.
>>>> DEBUG 3: MetGrib1DataFile::data_plane_scalar() ->   Found exact
match for
>>>> VarInfo "32/Z010" in GRIB record 293 of GRIB file
>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>> DEBUG 3: Rotating U and V wind components from grid-relative to
>>>> earth-relative.
>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1 GRIB
records
>>>> matching VarInfo "32/Z010" in GRIB file
>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>> DEBUG 3: Deriving wind speed from U and V wind components.
>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1 GRIB
records
>>>> matching VarInfo "32/Z010" in GRIB file
>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>> DEBUG 2: For 32/Z010 found 1 forecast levels and 0 climatology
levels.
>>>> DEBUG 2:
>>>> DEBUG 2:
>>>>
--------------------------------------------------------------------------------
>>>> DEBUG 2:
>>>> DEBUG 2: Searching 2979273 observations from 85274 messages.
>>>> ERROR  :
>>>> ERROR  : process_obs_file() ->   can't read the header array
record for
>>>> header number 85274
>>>> ERROR  :
>>>>
>>>> I was wondering if this perhaps is something related to my build
of
>>>> METv3.1, the way I am calling point_stat, or perhaps a bug in the
ncdf
>>>> files. Note that the test script provided with METv3.1 seems to
work
>>>> just fine.
>>>>
>>>> Any help would be much appreciated.
>>>>
>>>> Thanks.
>>>>
>>>> John Henderson
>>>>
>



------------------------------------------------
Subject: Running point_stat with NCAR ds337 ncdf files
From: jhenders at aer.com
Time: Fri Jun 29 10:52:09 2012

Job 256249.pbspl1.nas.nasa.gov started on Fri Jun 29 08:49:14 PDT 2012
The job requested the following resources:
    ncpus=1
    place=scatter:excl
    walltime=06:00:00

PBS set the following environment variables:
        FORT_BUFFERED = 1
                   TZ = PST8PDT

On r200i3n15:
Warning: no access to tty (Bad file descriptor).
Thus no job control in this shell.
Current directory is /nobackup/jmhender/p1652/test
DEBUG 1: Default Config File: /u/jmhender/NWP/WRF-
MET/METv3.1/data/config/PointStatConfig_default
DEBUG 1: User Config File: PointStatConfig-winds
DEBUG 1: Forecast File:
/nobackupp6/jmhender/p1652/grib/2009090100/d1_2009090100_1200.grib
DEBUG 1: Climatology File: none
DEBUG 1: Observation File: /nobackupp6/jmhender/p1652/obs/obs-nc/obs-
20090901.nc
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Reading data for TMP/Z002.
DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found range match for
VarInfo "TMP/Z002" in GRIB record 289 of GRIB file
"/nobackupp6/jmhender/p1652/grib/2009090100/d1_2009090100_1200.grib".
DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found 1 GRIB records
matching VarInfo "TMP/Z002" in GRIB file
"/nobackupp6/jmhender/p1652/grib/2009090100/d1_2009090100_1200.grib".
DEBUG 4: parse_sid_mask() ->  parsing station ID mask file "(nul)"
DEBUG 4: parse_grid_mask() ->  parsing grid mask "FULL"
DEBUG 2: For TMP/Z002 found 1 forecast levels and 0 climatology
levels.
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Reading data for UGRD/Z010.
DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found range match for
VarInfo "UGRD/Z010" in GRIB record 293 of GRIB file
"/nobackupp6/jmhender/p1652/grib/2009090100/d1_2009090100_1200.grib".
DEBUG 3: MetGrib1DataFile::rotate_winds() -> Have U-wind record,
reading V-wind record.
DEBUG 3: MetGrib1DataFile::data_plane_scalar() -> Found exact match
for VarInfo "UGRD/Z010" in GRIB record 294 of GRIB file
"/nobackupp6/jmhender/p1652/grib/2009090100/d1_2009090100_1200.grib".
DEBUG 3: Rotating U and V wind components from grid-relative to earth-
relative.
DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found 1 GRIB records
matching VarInfo "UGRD/Z010" in GRIB file
"/nobackupp6/jmhender/p1652/grib/2009090100/d1_2009090100_1200.grib".
DEBUG 2: For UGRD/Z010 found 1 forecast levels and 0 climatology
levels.
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Reading data for TMP/P500.
DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found range match for
VarInfo "TMP/P500" in GRIB record 157 of GRIB file
"/nobackupp6/jmhender/p1652/grib/2009090100/d1_2009090100_1200.grib".
DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found 1 GRIB records
matching VarInfo "TMP/P500" in GRIB file
"/nobackupp6/jmhender/p1652/grib/2009090100/d1_2009090100_1200.grib".
DEBUG 2: For TMP/P500 found 1 forecast levels and 0 climatology
levels.
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Searching 397179 observations from 109362 messages.
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Processing TMP/Z002 versus TMP/Z002, for observation type
ADPUPA, over region FULL, for interpolation method UW_MEAN(1), using 0
pairs.
DEBUG 3: Number of matched pairs  = 0
DEBUG 3: Observations processed   = 397179
DEBUG 3: Rejected: GRIB code      = 370508
DEBUG 3: Rejected: valid time     = 17110
DEBUG 3: Rejected: bad obs value  = 0
DEBUG 3: Rejected: off the grid   = 85
DEBUG 3: Rejected: level mismatch = 8208
DEBUG 3: Rejected: message type   = 1268
DEBUG 3: Rejected: masking region = 0
DEBUG 3: Rejected: bad fcst value = 0
DEBUG 2: Processing TMP/Z002 versus TMP/Z002, for observation type
ADPSFC, over region FULL, for interpolation method UW_MEAN(1), using 0
pairs.
DEBUG 3: Number of matched pairs  = 0
DEBUG 3: Observations processed   = 397179
DEBUG 3: Rejected: GRIB code      = 370508
DEBUG 3: Rejected: valid time     = 17110
DEBUG 3: Rejected: bad obs value  = 0
DEBUG 3: Rejected: off the grid   = 85
DEBUG 3: Rejected: level mismatch = 8208
DEBUG 3: Rejected: message type   = 1268
DEBUG 3: Rejected: masking region = 0
DEBUG 3: Rejected: bad fcst value = 0
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Processing UGRD/Z010 versus UGRD/Z010, for observation type
ADPUPA, over region FULL, for interpolation method UW_MEAN(1), using 0
pairs.
DEBUG 3: Number of matched pairs  = 0
DEBUG 3: Observations processed   = 397179
DEBUG 3: Rejected: GRIB code      = 341626
DEBUG 3: Rejected: valid time     = 43272
DEBUG 3: Rejected: bad obs value  = 0
DEBUG 3: Rejected: off the grid   = 103
DEBUG 3: Rejected: level mismatch = 10796
DEBUG 3: Rejected: message type   = 1382
DEBUG 3: Rejected: masking region = 0
DEBUG 3: Rejected: bad fcst value = 0
DEBUG 2: Processing UGRD/Z010 versus UGRD/Z010, for observation type
ADPSFC, over region FULL, for interpolation method UW_MEAN(1), using 0
pairs.
DEBUG 3: Number of matched pairs  = 0
DEBUG 3: Observations processed   = 397179
DEBUG 3: Rejected: GRIB code      = 341626
DEBUG 3: Rejected: valid time     = 43272
DEBUG 3: Rejected: bad obs value  = 0
DEBUG 3: Rejected: off the grid   = 103
DEBUG 3: Rejected: level mismatch = 10796
DEBUG 3: Rejected: message type   = 1382
DEBUG 3: Rejected: masking region = 0
DEBUG 3: Rejected: bad fcst value = 0
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Processing TMP/P500 versus TMP/P500, for observation type
ADPUPA, over region FULL, for interpolation method UW_MEAN(1), using
114 pairs.
DEBUG 3: Number of matched pairs  = 114
DEBUG 3: Observations processed   = 397179
DEBUG 3: Rejected: GRIB code      = 370508
DEBUG 3: Rejected: valid time     = 17110
DEBUG 3: Rejected: bad obs value  = 0
DEBUG 3: Rejected: off the grid   = 85
DEBUG 3: Rejected: level mismatch = 9362
DEBUG 3: Rejected: message type   = 0
DEBUG 3: Rejected: masking region = 0
DEBUG 3: Rejected: bad fcst value = 0
DEBUG 2: Computing Continuous Statistics.
DEBUG 2: Processing TMP/P500 versus TMP/P500, for observation type
ADPSFC, over region FULL, for interpolation method UW_MEAN(1), using 0
pairs.
DEBUG 3: Number of matched pairs  = 0
DEBUG 3: Observations processed   = 397179
DEBUG 3: Rejected: GRIB code      = 370508
DEBUG 3: Rejected: valid time     = 17110
DEBUG 3: Rejected: bad obs value  = 0
DEBUG 3: Rejected: off the grid   = 85
DEBUG 3: Rejected: level mismatch = 9362
DEBUG 3: Rejected: message type   = 114
DEBUG 3: Rejected: masking region = 0
DEBUG 3: Rejected: bad fcst value = 0
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 1: Output file: stats/point_stat_120000L_20090901_120000V.stat
DEBUG 1: Output file:
stats/point_stat_120000L_20090901_120000V_cnt.txt

____________________________________________________________________
Job Resource Usage Summary for 256249.pbspl1.nas.nasa.gov

    CPU Time Used            : 00:10:53
    Real Memory Used         : 19152kb
    Walltime Used            : 00:11:23
    Exit Status              : 0

    Number of CPUs Requested : 1
    Walltime Requested       : 06:00:00

    Execution Queue          : smd1
    Charged To               : s1064

    Job Stopped              : Fri Jun 29 09:00:38 2012
____________________________________________________________________

------------------------------------------------
Subject: Running point_stat with NCAR ds337 ncdf files
From: jhenders at aer.com
Time: Fri Jun 29 10:52:09 2012

////////////////////////////////////////////////////////////////////////////////
//
// Default point_stat configuration file
//
////////////////////////////////////////////////////////////////////////////////

//
// Specify a name to designate the model being verified.  This name
will be
// written to the second column of the ASCII output generated.
//
model = "WRF";

//
// Beginning and ending time offset values in seconds for observations
// to be used.  These time offsets are defined in reference to the
// forecast valid time, v.  Observations with a valid time falling in
the
// window [v+beg_ds, v+end_ds] will be used.
// These selections are overridden by the command line arguments
// -obs_valid_beg and -obs_valid_end.
//
beg_ds = -5400;
end_ds =  5400;

//
// Specify a comma-separated list of fields to be verified.  The
forecast and
// observation fields may be specified separately.  If the obs_field
parameter
// is left blank, it will default to the contents of fcst_field.
//
// Each field is specified as a GRIB code or abbreviation followed by
an
// accumulation or vertical level indicator for GRIB files or as a
variable name
// followed by a list of dimensions for NetCDF files output from
p_interp or MET.
//
// Specifying verification fields for GRIB files:
//    GC/ANNN for accumulation interval NNN
//    GC/ZNNN for vertical level NNN
//    GC/ZNNN-NNN for a range of vertical levels (MSL or AGL)
//    GC/PNNN for pressure level NNN in hPa
//    GC/PNNN-NNN for a range of pressure levels in hPa
//    GC/LNNN for a generic level type
//    GC/RNNN for a specific GRIB record number
//    Where GC is the number of or abbreviation for the grib code
//    to be verified.
// http://www.nco.ncep.noaa.gov/pmb/docs/on388/table2.html
//
// Specifying verification fields for NetCDF files:
//    var_name(i,...,j,*,*) for a single field
//    var_name(i-j,*,*) for a range of fields
//    Where var_name is the name of the NetCDF variable,
//    and i,...,j specifies fixed dimension values,
//    and i-j specifies a range of values for a single dimension,
//    and *,* specifies the two dimensions for the gridded field.
//
//    NOTE: To verify winds as vectors rather than scalars,
//          specify UGRD (or 33) followed by VGRD (or 34) with the
//          same level values.
//
//    NOTE: To process a probability field, add "/PROB", such as
"POP/Z0/PROB".
//
// e.g. fcst_field[] = [ "SPFH/P500", "TMP/P500" ]; for a GRIB input
// e.g. fcst_field[] = [ "QVAPOR(0,5,*,*)", "TT(0,5,*,*)" ]; for
NetCDF input
//
fcst_field[] = [ "TMP/Z002", "UGRD/Z010", "TMP/P500" ];
obs_field[]  = [];

//
// Specify a comma-separated list of groups of thresholds to be
applied to the
// fields listed above.  Thresholds for the forecast and observation
fields
// may be specified separately.  If the obs_thresh parameter is left
blank,
// it will default to the contents of fcst_thresh.
//
// At least one threshold must be provided for each field listed
above.  The
// lengths of the "fcst_field" and "fcst_thresh" arrays must match, as
must
// lengths of the "obs_field" and "obs_thresh" arrays.  To apply
multiple
// thresholds to a field, separate the threshold values with a space.
//
// Each threshold must be preceded by a two letter indicator for the
type of
// thresholding to be performed:
//    'lt' for less than     'le' for less than or equal to
//    'eq' for equal to      'ne' for not equal to
//    'gt' for greater than  'ge' for greater than or equal to
//
// NOTE: Thresholds for probabilities must begin with 0.0, end with
1.0,
//       and be preceeded by "ge".
//
// e.g. fcst_thresh[] = [ "gt80", "gt273" ];
//
fcst_thresh[] = [ "ge0" ];
obs_thresh[]  = [];

//
// Specify a comma-separated list of thresholds to be used when
computing
// VL1L2 and VAL1L2 partial sums for winds.  The thresholds are
applied to the
// wind speed values derived from each U/V pair.  Only those U/V pairs
which meet
// the wind speed threshold criteria are retained.  If the
obs_wind_thresh
// parameter is left blank, it will default to the contents of
fcst_wind_thresh.
//
// To apply multiple wind speed thresholds, separate the threshold
values with a
// space.  Use "NA" to indicate that no wind speed threshold should be
applied.
//
// Each threshold must be preceded by a two letter indicator for the
type of
// thresholding to be performed:
//    'lt' for less than     'le' for less than or equal to
//    'eq' for equal to      'ne' for not equal to
//    'gt' for greater than  'ge' for greater than or equal to
//    'NA' for no threshold
//
// e.g. fcst_wind_thresh[] = [ "NA", "ge1.0" ];
//
fcst_wind_thresh[] = [ "NA" ];
obs_wind_thresh[]  = [];

//
// Specify a comma-separated list of PrepBufr message types with which
// to perform the verification.  Statistics will be computed
separately
// for each message type specified.  At least one PrepBufr message
type
// must be provided.
// List of valid message types:
//    ADPUPA AIRCAR AIRCFT ADPSFC ERS1DA GOESND GPSIPW
//    MSONET PROFLR QKSWND RASSDA SATEMP SATWND SFCBOG
//    SFCSHP SPSSMI SYNDAT VADWND
//    ANYAIR (= AIRCAR, AIRCFT)
//    ANYSFC (= ADPSFC, SFCSHP, ADPUPA, PROFLR)
//    ONLYSF (= ADPSFC, SFCSHP)
//
http://www.emc.ncep.noaa.gov/mmb/data_processing/prepbufr.doc/table_1.htm
//
// e.g. message_type[] = [ "ADPUPA", "AIRCAR" ];
//
message_type[] = [ "ADPUPA", "ADPSFC" ];

//
// Specify a comma-separated list of grids to be used in masking the
data over
// which to perform scoring.  An empty list indicates that no masking
grid
// should be performed.  The standard NCEP grids are named "GNNN"
where NNN
// indicates the three digit grid number.  Enter "FULL" to score over
the
// entire domain.
// http://www.nco.ncep.noaa.gov/pmb/docs/on388/tableb.html
//
// e.g. mask_grid[] = [ "FULL" ];
//
mask_grid[] = [ "FULL" ];

//
// Specify a comma-separated list of masking regions to be applied.
// An empty list indicates that no additional masks should be used.
// The masking regions may be defined in one of 4 ways:
//
// (1) An ASCII file containing a lat/lon polygon.
//     Latitude in degrees north and longitude in degrees east.
//     By default, the first and last polygon points are connected.
//     e.g. "MET_BASE/data/poly/EAST.poly" which consists of n points:
//          "poly_name lat1 lon1 lat2 lon2... latn lonn"
//
// (2) The NetCDF output of the gen_poly_mask tool.
//
// (3) A NetCDF data file, followed by the name of the NetCDF variable
//     to be used, and optionally, a threshold to be applied to the
field.
//     e.g. "sample.nc var_name gt0.00"
//
// (4) A GRIB data file, followed by a description of the field
//     to be used, and optionally, a threshold to be applied to the
field.
//     e.g. "sample.grb APCP/A3 gt0.00"
//
// Any NetCDF or GRIB file used must have the same grid dimensions as
the
// data being verified.
//
// MET_BASE may be used in the path for the files above.
//
// e.g. mask_poly[] = [ "MET_BASE/data/poly/EAST.poly",
//                      "poly_mask.ncf",
//                      "sample.nc APCP",
//                      "sample.grb HGT/Z0 gt100.0" ];
//
mask_poly[] = [ ];

//
// Specify the name of an ASCII file containing a space-separated list
of
// station ID's at which to perform verification.  Each station ID
specified
// is treated as an individual masking region.
//
// An empty list file name indicates that no station ID masks should
be used.
//
// MET_BASE may be used in the path for the station ID mask file name.
//
// e.g. mask_sid = "MET_BASE/data/stations/CONUS.stations";
//
mask_sid = "";

//
// Specify a comma-separated list of values for alpha to be used when
computing
// confidence intervals.  Values of alpha must be between 0 and 1.
//
// e.g. ci_alpha[] = [ 0.05, 0.10 ];
//
ci_alpha[] = [ 0.05 ];

//
// Specify the method to be used for computing bootstrap confidence
intervals.
// The value for this is interpreted as follows:
//    (0) Use the BCa interval method (computationally intensive)
//    (1) Use the percentile interval method
//
boot_interval = 1;

//
// Specify a proportion between 0 and 1 to define the replicate sample
size
// to be used when computing percentile intervals.  The replicate
sample
// size is set to boot_rep_prop * n, where n is the number of raw data
points.
//
// e.g boot_rep_prop = 0.80;
//
boot_rep_prop = 1.0;

//
// Specify the number of times each set of matched pair data should be
// resampled when computing bootstrap confidence intervals.  A value
of
// zero disables the computation of bootstrap condifence intervals.
//
// e.g. n_boot_rep = 1000;
//
n_boot_rep = 0;

//
// Specify the name of the random number generator to be used.  See
the MET
// Users Guide for a list of possible random number generators.
//
boot_rng = "mt19937";

//
// Specify the seed value to be used when computing bootstrap
confidence
// intervals.  If left unspecified, the seed will change for each run
and
// the computed bootstrap confidence intervals will not be
reproducable.
//
boot_seed = "1";

//
// Specify a comma-separated list of interpolation method(s) to be
used
// for comparing the forecast grid to the observation points.  String
values
// are interpreted as follows:
//    MIN     = Minimum in the neighborhood
//    MAX     = Maximum in the neighborhood
//    MEDIAN  = Median in the neighborhood
//    UW_MEAN = Unweighted mean in the neighborhood
//    DW_MEAN = Distance-weighted mean in the neighborhood
//    LS_FIT  = Least-squares fit in the neighborhood
//    BILIN   = Bilinear interpolation using the 4 closest points
//
// In all cases, vertical interpolation is performed in the natural
log
// of pressure of the levels above and below the observation.
//
// e.g. interp_method[] = [ "UW_MEAN", "MEDIAN" ];
//
interp_method[] = [ "DW_MEAN" ];

//
// Specify a comma-separated list of box widths to be used by the
// interpolation techniques listed above.  A value of 1 indicates that
// the nearest neighbor approach should be used.  For a value of n
// greater than 1, the n*n grid points closest to the observation
define
// the neighborhood.
//
// e.g. interp_width = [ 1, 3, 5 ];
//
interp_width[] = [ 1 ];

//
// When interpolating, compute a ratio of the number of valid data
points
// to the total number of points in the neighborhood.  If that ratio
is
// less than this threshold, do not include the observation.  This
// threshold must be between 0 and 1.  Setting this threshold to 1
will
// require that each observation be surrounded by n*n valid forecast
// points.
//
// e.g. interp_thresh = 1.0;
//
interp_thresh = 1.0;

//
// Specify flags to indicate the type of data to be output:
//    (1) STAT and FHO Text Files, Forecast, Hit, Observation Rates:
//           Total (TOTAL),
//           Forecast Rate (F_RATE),
//           Hit Rate (H_RATE),
//           Observation Rate (O_RATE)
//
//    (2) STAT and CTC Text Files, Contingency Table Counts:
//           Total (TOTAL),
//           Forecast Yes and Observation Yes Count (FY_OY),
//           Forecast Yes and Observation No Count (FY_ON),
//           Forecast No and Observation Yes Count (FN_OY),
//           Forecast No and Observation No Count (FN_ON)
//
//    (3) STAT and CTS Text Files, Contingency Table Scores:
//           Total (TOTAL),
//           Base Rate (BASER),
//           Forecast Mean (FMEAN),
//           Accuracy (ACC),
//           Frequency Bias (FBIAS),
//           Probability of Detecting Yes (PODY),
//           Probability of Detecting No (PODN),
//           Probability of False Detection (POFD),
//           False Alarm Ratio (FAR),
//           Critical Success Index (CSI),
//           Gilbert Skill Score (GSS),
//           Hanssen and Kuipers Discriminant (HK),
//           Heidke Skill Score (HSS),
//           Odds Ratio (ODDS),
//           NOTE: All statistics listed above contain parametric
and/or
//                 non-parametric confidence interval limits.
//
//    (4) STAT and MCTC Text Files, NxN Multi-Category Contingency
Table Counts:
//           Total (TOTAL),
//           Number of Categories (N_CAT),
//           Contingency Table Count columns repeated N_CAT*N_CAT
times
//
//    (5) STAT and MCTS Text Files, NxN Multi-Category Contingency
Table Scores:
//           Total (TOTAL),
//           Number of Categories (N_CAT),
//           Accuracy (ACC),
//           Hanssen and Kuipers Discriminant (HK),
//           Heidke Skill Score (HSS),
//           Gerrity Score (GER),
//           NOTE: All statistics listed above contain parametric
and/or
//                 non-parametric confidence interval limits.
//
//    (6) STAT and CNT Text Files, Statistics of Continuous Variables:
//           Total (TOTAL),
//           Forecast Mean (FBAR),
//           Forecast Standard Deviation (FSTDEV),
//           Observation Mean (OBAR),
//           Observation Standard Deviation (OSTDEV),
//           Pearson's Correlation Coefficient (PR_CORR),
//           Spearman's Rank Correlation Coefficient (SP_CORR),
//           Kendall Tau Rank Correlation Coefficient (KT_CORR),
//           Number of ranks compared (RANKS),
//           Number of tied ranks in the forecast field (FRANK_TIES),
//           Number of tied ranks in the observation field
(ORANK_TIES),
//           Mean Error (ME),
//           Standard Deviation of the Error (ESTDEV),
//           Multiplicative Bias (MBIAS = FBAR - OBAR),
//           Mean Absolute Error (MAE),
//           Mean Squared Error (MSE),
//           Bias-Corrected Mean Squared Error (BCMSE),
//           Root Mean Squared Error (RMSE),
//           Percentiles of the Error (E10, E25, E50, E75, E90)
//           NOTE: Most statistics listed above contain parametric
and/or
//                 non-parametric confidence interval limits.
//
//    (7) STAT and SL1L2 Text Files, Scalar Partial Sums:
//           Total (TOTAL),
//           Forecast Mean (FBAR),
//              = mean(f)
//           Observation Mean (OBAR),
//              = mean(o)
//           Forecast*Observation Product Mean (FOBAR),
//              = mean(f*o)
//           Forecast Squared Mean (FFBAR),
//              = mean(f^2)
//           Observation Squared Mean (OOBAR)
//              = mean(o^2)
//
//    (8) STAT and SAL1L2 Text Files, Scalar Anomaly Partial Sums:
//           Total (TOTAL),
//           Forecast Anomaly Mean (FABAR),
//              = mean(f-c)
//           Observation Anomaly Mean (OABAR),
//              = mean(o-c)
//           Product of Forecast and Observation Anomalies Mean
(FOABAR),
//              = mean((f-c)*(o-c))
//           Forecast Anomaly Squared Mean (FFABAR),
//              = mean((f-c)^2)
//           Observation Anomaly Squared Mean (OOABAR)
//              = mean((o-c)^2)
//
//    (9) STAT and VL1L2 Text Files, Vector Partial Sums:
//           Total (TOTAL),
//           U-Forecast Mean (UFBAR),
//              = mean(uf)
//           V-Forecast Mean (VFBAR),
//              = mean(vf)
//           U-Observation Mean (UOBAR),
//              = mean(uo)
//           V-Observation Mean (VOBAR),
//              = mean(vo)
//           U-Product Plus V-Product (UVFOBAR),
//              = mean(uf*uo+vf*vo)
//           U-Forecast Squared Plus V-Forecast Squared (UVFFBAR),
//              = mean(uf^2+vf^2)
//           U-Observation Squared Plus V-Observation Squared
(UVOOBAR)
//              = mean(uo^2+vo^2)
//
//   (10) STAT and VAL1L2 Text Files, Vector Anomaly Partial Sums:
//           U-Forecast Anomaly Mean (UFABAR),
//              = mean(uf-uc)
//           V-Forecast Anomaly Mean (VFABAR),
//              = mean(vf-vc)
//           U-Observation Anomaly Mean (UOABAR),
//              = mean(uo-uc)
//           V-Observation Anomaly Mean (VOABAR),
//              = mean(vo-vc)
//           U-Anomaly Product Plus V-Anomaly Product (UVFOABAR),
//              = mean((uf-uc)*(uo-uc)+(vf-vc)*(vo-vc))
//           U-Forecast Anomaly Squared Plus V-Forecast Anomaly
Squared (UVFFABAR),
//              = mean((uf-uc)^2+(vf-vc)^2)
//           U-Observation Anomaly Squared Plus V-Observation Anomaly
Squared (UVOOABAR)
//              = mean((uo-uc)^2+(vo-vc)^2)
//
//   (11) STAT and PCT Text Files, Nx2 Probability Contingency Table
Counts:
//           Total (TOTAL),
//           Number of Forecast Probability Thresholds (N_THRESH),
//           Probability Threshold Value (THRESH_i),
//           Row Observation Yes Count (OY_i),
//           Row Observation No Count (ON_i),
//           NOTE: Previous 3 columns repeated for each row in the
table.
//           Last Probability Threshold Value (THRESH_n)
//
//   (12) STAT and PSTD Text Files, Nx2 Probability Contingency Table
Scores:
//           Total (TOTAL),
//           Number of Forecast Probability Thresholds (N_THRESH),
//           Base Rate (BASER) with confidence interval limits,
//           Reliability (RELIABILITY),
//           Resolution (RESOLUTION),
//           Uncertainty (UNCERTAINTY),
//           Area Under the ROC Curve (ROC_AUC),
//           Brier Score (BRIER) with confidence interval limits,
//           Probability Threshold Value (THRESH_i)
//           NOTE: Previous column repeated for each probability
threshold.
//
//   (13) STAT and PJC Text Files, Joint/Continuous Statistics of
//                                 Probabilistic Variables:
//           Total (TOTAL),
//           Number of Forecast Probability Thresholds (N_THRESH),
//           Probability Threshold Value (THRESH_i),
//           Observation Yes Count Divided by Total (OY_TP_i),
//           Observation No Count Divided by Total (ON_TP_i),
//           Calibration (CALIBRATION_i),
//           Refinement (REFINEMENT_i),
//           Likelikhood (LIKELIHOOD_i),
//           Base Rate (BASER_i),
//           NOTE: Previous 7 columns repeated for each row in the
table.
//           Last Probability Threshold Value (THRESH_n)
//
//   (14) STAT and PRC Text Files, ROC Curve Points for
//                                 Probabilistic Variables:
//           Total (TOTAL),
//           Number of Forecast Probability Thresholds (N_THRESH),
//           Probability Threshold Value (THRESH_i),
//           Probability of Detecting Yes (PODY_i),
//           Probability of False Detection (POFD_i),
//           NOTE: Previous 3 columns repeated for each row in the
table.
//           Last Probability Threshold Value (THRESH_n)
//
//   (15) STAT and MPR Text Files, Matched Pair Data:
//           Total (TOTAL),
//           Index (INDEX),
//           Observation Station ID (OBS_SID),
//           Observation Latitude (OBS_LAT),
//           Observation Longitude (OBS_LON),
//           Observation Level (OBS_LVL),
//           Observation Elevation (OBS_ELV),
//           Forecast Value (FCST),
//           Observation Value (OBS),
//           Climatological Value (CLIMO)
//
//   In the expressions above, f are forecast values, o are observed
values,
//   and c are climatological values.
//
// Values for these flags are interpreted as follows:
//    (0) Do not generate output of this type
//    (1) Write output to a STAT file
//    (2) Write output to a STAT file and a text file
//
output_flag[] = [ 0, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0 ];

//
// Flag to indicate whether Kendall's Tau and Spearman's Rank
Correlation
// Coefficients should be computed.  Computing them over large
datasets is
// computationally intensive and slows down the runtime execution
significantly.
//    (0) Do not compute these correlation coefficients
//    (1) Compute these correlation coefficients
//
rank_corr_flag = 0;

//
// Specify the GRIB Table 2 parameter table version number to be used
// for interpreting GRIB codes.
// http://www.nco.ncep.noaa.gov/pmb/docs/on388/table2.html
//
grib_ptv = 2;

//
// Directory where temporary files should be written.
//
tmp_dir = "tmp";

//
// Prefix to be used for the output file names.
//
output_prefix = "";

//
// Indicate a version number for the contents of this configuration
file.
// The value should generally not be modified.
//
version = "V3.1";

------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #56988] Running point_stat with NCAR ds337 ncdf files
From: John Halley Gotway
Time: Fri Jun 29 13:05:13 2012

John,

Regarding your questions at the end...

(1) In previous versions of MET, the code required that the number of
thresholds specified must exactly match the number of fields being
verified in all cases.  We modified the code to only enforce
that requirement when the user has requested thresholding be performed
in the "output_flag" parameter of the config file.  It's only enforced
when categorical output line types (like FHO, CTC, CTS,
and so on) are requested.  In your case, your only requesting
continuous stats (CNT line type) - thus no error.

(2) Where it states "ZNNN", the number of digits following 'Z' doesn't
really matter.  So "Z2", "Z02", and "Z002" are all equivalent.

Regarding getting no matched pairs for the ADPSFC message type, I'm
really not sure.  It could due to any number of issues.  Probably the
quickest way to debug it would be to have you send me the data
that produced the "log.txt" file you sent.  So I'd need:
  - Forecast File:
/nobackupp6/jmhender/p1652/grib/2009090100/d1_2009090100_1200.grib
  - Observation File: /nobackupp6/jmhender/p1652/obs/obs-nc/obs-
20090901.nc
  - User Config File: PointStatConfig-winds
  - The command line you're using to run Point-Stat.

I'll run it here, and figure out what's going on.

You can post data to our anonymous ftp site as described here:
    http://www.dtcenter.org/met/users/support/met_help.php

Thanks,
John


On 06/29/2012 10:52 AM, jhenders at aer.com via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>
> Hello again John,
>
> I am now back on this task and have been able to run METv3.1's
> point_stat successfully for obs types other than ADPSFC. I am
running
> with '-v 4'. For METv2 I had no problems getting 2-m temperature or
10-m
> winds working in MET... The obs file I am using was geographically
> restricted to G212 by METv3.1's pb2nc.
>
> Any ideas? Attached is my PointStat config file and Point_Stat
output.
>
> I also have two points of clarification: 1) I inadvertently omitted
> thresholds in fcst_thresh for all the fields, however, the code did
not
> complain, and 2) Your notation below of Z10 doesn't agree with the
> documentation or code which states ZNNN as the proper level format.
The
> code seems to work either way.
>
> Please let me know if the above two points make sense and whether
any
> action is required.
>
> Thanks.
>
> John
>
>
>
>
> On 6/14/12 2:47 PM, John Halley Gotway via RT wrote:
>> You mentioned getting 0 matched pairs, and not knowing why.  Please
try running Point-Stat with "-v 3", that'll dump out more verbose
output and give you more detailed information for each
>> verification task.  Something like the following:
>>
>> DEBUG 2: Processing VGRD/Z10 versus VGRD/Z10, for observation type
ADPSFC, over region DTC165, for interpolation method UW_MEAN(1), using
9998 pairs.
>> DEBUG 3: Number of matched pairs  = 9998
>> DEBUG 3: Observations processed   = 2920139
>> DEBUG 3: Rejected: GRIB code      = 2322261
>> DEBUG 3: Rejected: valid time     = 0
>> DEBUG 3: Rejected: bad obs value  = 0
>> DEBUG 3: Rejected: off the grid   = 486827
>> DEBUG 3: Rejected: level mismatch = 61549
>> DEBUG 3: Rejected: message type   = 5863
>> DEBUG 3: Rejected: masking region = 33641
>> DEBUG 3: Rejected: bad fcst value = 0
>>
>> That way you can tell why the observation are not be used in each
verification task.
>>
>> Lastly, I think a very possible scenario is that those NetCDF files
in ds337.0 were generated using an earlier version of the PB2NC tool,
and the Point-Stat tool is not handling them well.  But if
>> that really is the case, then I should be able to reproduce the
error here.
>>
>> If you'd like, you could bundle up a model file, NetCDF point
observation file, and Point-Stat config file that demonstrate the
error and post them to our ftp site.  I could grab them, reproduce the
>> error here, and then figure out what's going wrong.  Here's
instructions for posting to our ftp site:
>>       http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>
>> Thanks,
>> John
>>
>>
>> On 06/14/2012 12:12 PM, jhenders at aer.com via RT wrote:
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>>>
>>> Hello again John,
>>>
>>> Thanks again for your prompt response. The quick answer is that I
have
>>> tried both ways.
>>>
>>> Originally I retrieved the netcdf files directly from
>>> http://rda.ucar.edu/dsszone/ds337.0/index.html?g=5.
>>>
>>> Having this new archive of netcdf files at NCAR was a welcome
discovery,
>>> except that they are global files and point_stat took 3 h on
NASA's
>>> Pleiades before failing with the error I provided.
>>>
>>> To test further, I then requested netcdf files for a geographical
>>> subregion via
http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php.
>>> That again fails (much faster) with the same error.
>>>
>>> I should note that I have only used point_stat with netcdf obs
files
>>> from 20090901 and 20090902. The error shows up on both a local
linux
>>> cluster as well as on Pleiades.
>>>
>>> In the past hour I have retrieved a PrepBufr file from NCAR and
run
>>> pb2nc on Pleiades. I then provide that ncdf file to point_stat. I
was
>>> able to get past the error, though (for unknown reasons) I am not
>>> finding any successful matches.
>>>
>>> This suggests a problem with the ncdf files at NCAR.
>>>
>>> Thanks.
>>>
>>> John
>>>
>>>
>>> On 6/14/12 12:36 PM, John Halley Gotway via RT wrote:
>>>> John,
>>>>
>>>> Very good question.  Can you please clarify one thing for me?
>>>>
>>>> Are you retrieving the PrepBufr files themselves from this ds337
link:
>>>>         http://rda.ucar.edu/datasets/ds337.0
>>>> And then running them through the PB2NC tool to pre-process them?
>>>>
>>>> Or are you using the subset request form at this link:
>>>>         http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php
>>>> And using that data as input into Point-Stat directly?
>>>>
>>>> I need to figure out which avenue needs debugging.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>> On 06/14/2012 09:59 AM, jhenders at aer.com via RT wrote:
>>>>> Thu Jun 14 09:59:39 2012: Request 56988 was acted upon.
>>>>> Transaction: Ticket created by jhenders at aer.com
>>>>>             Queue: met_help
>>>>>           Subject: Running point_stat with NCAR ds337 ncdf files
>>>>>             Owner: Nobody
>>>>>        Requestors: jhenders at aer.com
>>>>>            Status: new
>>>>>       Ticket<URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988>
>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> I have recently upgraded to v3.1 of MET and am running
point_stat for
>>>>> the first time on two separate machines - one locally, with the
other
>>>>> being NASA Ames' Pleiades. I am trying to use the netcdf
PrepBufr obs
>>>>> files obtained from NCAR's dss337, however, all attempts to run
>>>>> point_stat terminate with this error:
>>>>>
>>>>> DEBUG 1: Default Config File:
>>>>> /u/jmhender/NWP/WRF-
MET/METv3.1/data/config/PointStatConfig_default
>>>>> DEBUG 1: User Config File:
>>>>> PointStatConfig_V3.1-SLC-case03.20120614.13.47.57.UTC
>>>>> DEBUG 1: Forecast File:
>>>>>
/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib
>>>>> DEBUG 1: Climatology File: none
>>>>> DEBUG 1: Observation File:
>>>>> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090101.nc
>>>>> DEBUG 1: Observation File:
>>>>> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090102.nc
>>>>> DEBUG 2:
>>>>> DEBUG 2:
>>>>>
--------------------------------------------------------------------------------
>>>>> DEBUG 2:
>>>>> DEBUG 2: Reading data for TMP/P200.
>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found range
match for
>>>>> VarInfo "TMP/P200" in GRIB record 81 of GRIB file
>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1 GRIB
records
>>>>> matching VarInfo "TMP/P200" in GRIB file
>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>> DEBUG 4: parse_sid_mask() ->    parsing station ID mask file
"(nul)"
>>>>> DEBUG 4: parse_grid_mask() ->    parsing grid mask "FULL"
>>>>> DEBUG 2: For TMP/P200 found 1 forecast levels and 0 climatology
levels.
>>>>> DEBUG 2:
>>>>>
>>>>> ...
>>>>>
>>>>> DEBUG 3: Rotating U and V wind components from grid-relative to
>>>>> earth-relative.
>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1 GRIB
records
>>>>> matching VarInfo "32/Z010" in GRIB file
>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Reading V-
wind records.
>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found range
match for
>>>>> VarInfo "32/Z010" in GRIB record 294 of GRIB file
>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>> DEBUG 3: MetGrib1DataFile::rotate_winds() ->   Have V-wind
record, reading
>>>>> U-wind record.
>>>>> DEBUG 3: MetGrib1DataFile::data_plane_scalar() ->   Found exact
match for
>>>>> VarInfo "32/Z010" in GRIB record 293 of GRIB file
>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>> DEBUG 3: Rotating U and V wind components from grid-relative to
>>>>> earth-relative.
>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1 GRIB
records
>>>>> matching VarInfo "32/Z010" in GRIB file
>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>> DEBUG 3: Deriving wind speed from U and V wind components.
>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1 GRIB
records
>>>>> matching VarInfo "32/Z010" in GRIB file
>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>> DEBUG 2: For 32/Z010 found 1 forecast levels and 0 climatology
levels.
>>>>> DEBUG 2:
>>>>> DEBUG 2:
>>>>>
--------------------------------------------------------------------------------
>>>>> DEBUG 2:
>>>>> DEBUG 2: Searching 2979273 observations from 85274 messages.
>>>>> ERROR  :
>>>>> ERROR  : process_obs_file() ->   can't read the header array
record for
>>>>> header number 85274
>>>>> ERROR  :
>>>>>
>>>>> I was wondering if this perhaps is something related to my build
of
>>>>> METv3.1, the way I am calling point_stat, or perhaps a bug in
the ncdf
>>>>> files. Note that the test script provided with METv3.1 seems to
work
>>>>> just fine.
>>>>>
>>>>> Any help would be much appreciated.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> John Henderson
>>>>>
>>
>
>
>


------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #56988] Running point_stat with NCAR ds337 ncdf files
From: jhenders at aer.com
Time: Fri Jun 29 13:19:54 2012

Hi John,

Thanks for the answers. I suspected as much. I think the documentation
needs to be tweaked.

I have uploaded my files to henderson_data. Though I downloaded the
prepbufr file from ds337 and used pb2nc, I have not plotted the
lat/lon
and timing of any ADPSFC obs. I did a quick verification attempt for
another randomly-chosen date in 2009 and it also failed to match
pairs.

I noticed that the original v3.0 code had a problem with vertical
level
matching for ADPSFC that was patched and, I suspect, permanently
corrected in v3.1. I noticed that the file structure has changed in
that
point-matching code between v3.1 and v3.0, so I haven't had time to
evaluate further.

Any insight you can provide using my files would be much appreciated.
I
am running remotely on a NASA Ames supercomputer Pleiades, in case you
are wondering about some non-familiar text in any output files.

John

On 6/29/12 3:05 PM, John Halley Gotway via RT wrote:
> John,
>
> Regarding your questions at the end...
>
> (1) In previous versions of MET, the code required that the number
of thresholds specified must exactly match the number of fields being
verified in all cases.  We modified the code to only enforce
> that requirement when the user has requested thresholding be
performed in the "output_flag" parameter of the config file.  It's
only enforced when categorical output line types (like FHO, CTC, CTS,
> and so on) are requested.  In your case, your only requesting
continuous stats (CNT line type) - thus no error.
>
> (2) Where it states "ZNNN", the number of digits following 'Z'
doesn't really matter.  So "Z2", "Z02", and "Z002" are all equivalent.
>
> Regarding getting no matched pairs for the ADPSFC message type, I'm
really not sure.  It could due to any number of issues.  Probably the
quickest way to debug it would be to have you send me the data
> that produced the "log.txt" file you sent.  So I'd need:
>    - Forecast File:
/nobackupp6/jmhender/p1652/grib/2009090100/d1_2009090100_1200.grib
>    - Observation File: /nobackupp6/jmhender/p1652/obs/obs-nc/obs-
20090901.nc
>    - User Config File: PointStatConfig-winds
>    - The command line you're using to run Point-Stat.
>
> I'll run it here, and figure out what's going on.
>
> You can post data to our anonymous ftp site as described here:
>      http://www.dtcenter.org/met/users/support/met_help.php
>
> Thanks,
> John
>
>
> On 06/29/2012 10:52 AM, jhenders at aer.com via RT wrote:
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>>
>> Hello again John,
>>
>> I am now back on this task and have been able to run METv3.1's
>> point_stat successfully for obs types other than ADPSFC. I am
running
>> with '-v 4'. For METv2 I had no problems getting 2-m temperature or
10-m
>> winds working in MET... The obs file I am using was geographically
>> restricted to G212 by METv3.1's pb2nc.
>>
>> Any ideas? Attached is my PointStat config file and Point_Stat
output.
>>
>> I also have two points of clarification: 1) I inadvertently omitted
>> thresholds in fcst_thresh for all the fields, however, the code did
not
>> complain, and 2) Your notation below of Z10 doesn't agree with the
>> documentation or code which states ZNNN as the proper level format.
The
>> code seems to work either way.
>>
>> Please let me know if the above two points make sense and whether
any
>> action is required.
>>
>> Thanks.
>>
>> John
>>
>>
>>
>>
>> On 6/14/12 2:47 PM, John Halley Gotway via RT wrote:
>>> You mentioned getting 0 matched pairs, and not knowing why.
Please try running Point-Stat with "-v 3", that'll dump out more
verbose output and give you more detailed information for each
>>> verification task.  Something like the following:
>>>
>>> DEBUG 2: Processing VGRD/Z10 versus VGRD/Z10, for observation type
ADPSFC, over region DTC165, for interpolation method UW_MEAN(1), using
9998 pairs.
>>> DEBUG 3: Number of matched pairs  = 9998
>>> DEBUG 3: Observations processed   = 2920139
>>> DEBUG 3: Rejected: GRIB code      = 2322261
>>> DEBUG 3: Rejected: valid time     = 0
>>> DEBUG 3: Rejected: bad obs value  = 0
>>> DEBUG 3: Rejected: off the grid   = 486827
>>> DEBUG 3: Rejected: level mismatch = 61549
>>> DEBUG 3: Rejected: message type   = 5863
>>> DEBUG 3: Rejected: masking region = 33641
>>> DEBUG 3: Rejected: bad fcst value = 0
>>>
>>> That way you can tell why the observation are not be used in each
verification task.
>>>
>>> Lastly, I think a very possible scenario is that those NetCDF
files in ds337.0 were generated using an earlier version of the PB2NC
tool, and the Point-Stat tool is not handling them well.  But if
>>> that really is the case, then I should be able to reproduce the
error here.
>>>
>>> If you'd like, you could bundle up a model file, NetCDF point
observation file, and Point-Stat config file that demonstrate the
error and post them to our ftp site.  I could grab them, reproduce the
>>> error here, and then figure out what's going wrong.  Here's
instructions for posting to our ftp site:
>>>        http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>
>>> Thanks,
>>> John
>>>
>>>
>>> On 06/14/2012 12:12 PM, jhenders at aer.com via RT wrote:
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>>>>
>>>> Hello again John,
>>>>
>>>> Thanks again for your prompt response. The quick answer is that I
have
>>>> tried both ways.
>>>>
>>>> Originally I retrieved the netcdf files directly from
>>>> http://rda.ucar.edu/dsszone/ds337.0/index.html?g=5.
>>>>
>>>> Having this new archive of netcdf files at NCAR was a welcome
discovery,
>>>> except that they are global files and point_stat took 3 h on
NASA's
>>>> Pleiades before failing with the error I provided.
>>>>
>>>> To test further, I then requested netcdf files for a geographical
>>>> subregion via
http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php.
>>>> That again fails (much faster) with the same error.
>>>>
>>>> I should note that I have only used point_stat with netcdf obs
files
>>>> from 20090901 and 20090902. The error shows up on both a local
linux
>>>> cluster as well as on Pleiades.
>>>>
>>>> In the past hour I have retrieved a PrepBufr file from NCAR and
run
>>>> pb2nc on Pleiades. I then provide that ncdf file to point_stat. I
was
>>>> able to get past the error, though (for unknown reasons) I am not
>>>> finding any successful matches.
>>>>
>>>> This suggests a problem with the ncdf files at NCAR.
>>>>
>>>> Thanks.
>>>>
>>>> John
>>>>
>>>>
>>>> On 6/14/12 12:36 PM, John Halley Gotway via RT wrote:
>>>>> John,
>>>>>
>>>>> Very good question.  Can you please clarify one thing for me?
>>>>>
>>>>> Are you retrieving the PrepBufr files themselves from this ds337
link:
>>>>>          http://rda.ucar.edu/datasets/ds337.0
>>>>> And then running them through the PB2NC tool to pre-process
them?
>>>>>
>>>>> Or are you using the subset request form at this link:
>>>>>
http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php
>>>>> And using that data as input into Point-Stat directly?
>>>>>
>>>>> I need to figure out which avenue needs debugging.
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>> On 06/14/2012 09:59 AM, jhenders at aer.com via RT wrote:
>>>>>> Thu Jun 14 09:59:39 2012: Request 56988 was acted upon.
>>>>>> Transaction: Ticket created by jhenders at aer.com
>>>>>>              Queue: met_help
>>>>>>            Subject: Running point_stat with NCAR ds337 ncdf
files
>>>>>>              Owner: Nobody
>>>>>>         Requestors: jhenders at aer.com
>>>>>>             Status: new
>>>>>>        Ticket<URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988>
>>>>>>
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I have recently upgraded to v3.1 of MET and am running
point_stat for
>>>>>> the first time on two separate machines - one locally, with the
other
>>>>>> being NASA Ames' Pleiades. I am trying to use the netcdf
PrepBufr obs
>>>>>> files obtained from NCAR's dss337, however, all attempts to run
>>>>>> point_stat terminate with this error:
>>>>>>
>>>>>> DEBUG 1: Default Config File:
>>>>>> /u/jmhender/NWP/WRF-
MET/METv3.1/data/config/PointStatConfig_default
>>>>>> DEBUG 1: User Config File:
>>>>>> PointStatConfig_V3.1-SLC-case03.20120614.13.47.57.UTC
>>>>>> DEBUG 1: Forecast File:
>>>>>>
/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib
>>>>>> DEBUG 1: Climatology File: none
>>>>>> DEBUG 1: Observation File:
>>>>>> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090101.nc
>>>>>> DEBUG 1: Observation File:
>>>>>> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090102.nc
>>>>>> DEBUG 2:
>>>>>> DEBUG 2:
>>>>>>
--------------------------------------------------------------------------------
>>>>>> DEBUG 2:
>>>>>> DEBUG 2: Reading data for TMP/P200.
>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found range
match for
>>>>>> VarInfo "TMP/P200" in GRIB record 81 of GRIB file
>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1 GRIB
records
>>>>>> matching VarInfo "TMP/P200" in GRIB file
>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>> DEBUG 4: parse_sid_mask() ->    parsing station ID mask file
"(nul)"
>>>>>> DEBUG 4: parse_grid_mask() ->    parsing grid mask "FULL"
>>>>>> DEBUG 2: For TMP/P200 found 1 forecast levels and 0 climatology
levels.
>>>>>> DEBUG 2:
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> DEBUG 3: Rotating U and V wind components from grid-relative to
>>>>>> earth-relative.
>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1 GRIB
records
>>>>>> matching VarInfo "32/Z010" in GRIB file
>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Reading V-
wind records.
>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found range
match for
>>>>>> VarInfo "32/Z010" in GRIB record 294 of GRIB file
>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>> DEBUG 3: MetGrib1DataFile::rotate_winds() ->   Have V-wind
record, reading
>>>>>> U-wind record.
>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_scalar() ->   Found exact
match for
>>>>>> VarInfo "32/Z010" in GRIB record 293 of GRIB file
>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>> DEBUG 3: Rotating U and V wind components from grid-relative to
>>>>>> earth-relative.
>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1 GRIB
records
>>>>>> matching VarInfo "32/Z010" in GRIB file
>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>> DEBUG 3: Deriving wind speed from U and V wind components.
>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1 GRIB
records
>>>>>> matching VarInfo "32/Z010" in GRIB file
>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>> DEBUG 2: For 32/Z010 found 1 forecast levels and 0 climatology
levels.
>>>>>> DEBUG 2:
>>>>>> DEBUG 2:
>>>>>>
--------------------------------------------------------------------------------
>>>>>> DEBUG 2:
>>>>>> DEBUG 2: Searching 2979273 observations from 85274 messages.
>>>>>> ERROR  :
>>>>>> ERROR  : process_obs_file() ->   can't read the header array
record for
>>>>>> header number 85274
>>>>>> ERROR  :
>>>>>>
>>>>>> I was wondering if this perhaps is something related to my
build of
>>>>>> METv3.1, the way I am calling point_stat, or perhaps a bug in
the ncdf
>>>>>> files. Note that the test script provided with METv3.1 seems to
work
>>>>>> just fine.
>>>>>>
>>>>>> Any help would be much appreciated.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> John Henderson
>>>>>>
>>
>>
>



------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #56988] Running point_stat with NCAR ds337 ncdf files
From: John Halley Gotway
Time: Wed Jul 04 08:53:15 2012

John,

Sorry for the delay in getting back with you - I've been traveling.

I ran with your data and was able to reproduce the behavior you're
seeing.
 I'm not able to get any matched pairs for TMP/Z2 or UGRD/Z10.  These
fields should be matching against observations of type ADPSFC.  I used
the
"plot_point_obs" tool to plot the locations of these observations in
the
data you sent.  But in doing so, found that no such observations exist
in
your data file:

METv3.1/bin/plot_point_obs \
obs-20090901.nc obs.ps \
-msg_typ ADPSFC \
-gc 11 -gc 33
DEBUG 1: Using default global grid.
DEBUG 1: Opening netCDF file: obs-20090901.nc
DEBUG 1: Processing 397179 observations at 109362 locations.
DEBUG 1: Observation GRIB codes: 34 11
DEBUG 1: Observation message types: ADPSFC
DEBUG 1: Creating postscript file: obs.ps
DEBUG 2: Finished plotting 0 locations.
DEBUG 2: Skipped 0 locations off the grid.

So we need to take a step back and figure out why there are not any
ADPSFC
observations for TMP or UGRD in the output of PB2NC.

I'm a bit limited in what I can do while traveling, but can take a
better
look when I'm back in my office on Monday.

Hope that helps.

John

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>
> Hi John,
>
> Thanks for the answers. I suspected as much. I think the
documentation
> needs to be tweaked.
>
> I have uploaded my files to henderson_data. Though I downloaded the
> prepbufr file from ds337 and used pb2nc, I have not plotted the
lat/lon
> and timing of any ADPSFC obs. I did a quick verification attempt for
> another randomly-chosen date in 2009 and it also failed to match
pairs.
>
> I noticed that the original v3.0 code had a problem with vertical
level
> matching for ADPSFC that was patched and, I suspect, permanently
> corrected in v3.1. I noticed that the file structure has changed in
that
> point-matching code between v3.1 and v3.0, so I haven't had time to
> evaluate further.
>
> Any insight you can provide using my files would be much
appreciated. I
> am running remotely on a NASA Ames supercomputer Pleiades, in case
you
> are wondering about some non-familiar text in any output files.
>
> John
>
> On 6/29/12 3:05 PM, John Halley Gotway via RT wrote:
>> John,
>>
>> Regarding your questions at the end...
>>
>> (1) In previous versions of MET, the code required that the number
of
>> thresholds specified must exactly match the number of fields being
>> verified in all cases.  We modified the code to only enforce
>> that requirement when the user has requested thresholding be
performed
>> in the "output_flag" parameter of the config file.  It's only
enforced
>> when categorical output line types (like FHO, CTC, CTS,
>> and so on) are requested.  In your case, your only requesting
continuous
>> stats (CNT line type) - thus no error.
>>
>> (2) Where it states "ZNNN", the number of digits following 'Z'
doesn't
>> really matter.  So "Z2", "Z02", and "Z002" are all equivalent.
>>
>> Regarding getting no matched pairs for the ADPSFC message type, I'm
>> really not sure.  It could due to any number of issues.  Probably
the
>> quickest way to debug it would be to have you send me the data
>> that produced the "log.txt" file you sent.  So I'd need:
>>    - Forecast File:
>> /nobackupp6/jmhender/p1652/grib/2009090100/d1_2009090100_1200.grib
>>    - Observation File:
>> /nobackupp6/jmhender/p1652/obs/obs-nc/obs-20090901.nc
>>    - User Config File: PointStatConfig-winds
>>    - The command line you're using to run Point-Stat.
>>
>> I'll run it here, and figure out what's going on.
>>
>> You can post data to our anonymous ftp site as described here:
>>      http://www.dtcenter.org/met/users/support/met_help.php
>>
>> Thanks,
>> John
>>
>>
>> On 06/29/2012 10:52 AM, jhenders at aer.com via RT wrote:
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>>>
>>> Hello again John,
>>>
>>> I am now back on this task and have been able to run METv3.1's
>>> point_stat successfully for obs types other than ADPSFC. I am
running
>>> with '-v 4'. For METv2 I had no problems getting 2-m temperature
or
>>> 10-m
>>> winds working in MET... The obs file I am using was geographically
>>> restricted to G212 by METv3.1's pb2nc.
>>>
>>> Any ideas? Attached is my PointStat config file and Point_Stat
output.
>>>
>>> I also have two points of clarification: 1) I inadvertently
omitted
>>> thresholds in fcst_thresh for all the fields, however, the code
did not
>>> complain, and 2) Your notation below of Z10 doesn't agree with the
>>> documentation or code which states ZNNN as the proper level
format. The
>>> code seems to work either way.
>>>
>>> Please let me know if the above two points make sense and whether
any
>>> action is required.
>>>
>>> Thanks.
>>>
>>> John
>>>
>>>
>>>
>>>
>>> On 6/14/12 2:47 PM, John Halley Gotway via RT wrote:
>>>> You mentioned getting 0 matched pairs, and not knowing why.
Please
>>>> try running Point-Stat with "-v 3", that'll dump out more verbose
>>>> output and give you more detailed information for each
>>>> verification task.  Something like the following:
>>>>
>>>> DEBUG 2: Processing VGRD/Z10 versus VGRD/Z10, for observation
type
>>>> ADPSFC, over region DTC165, for interpolation method UW_MEAN(1),
using
>>>> 9998 pairs.
>>>> DEBUG 3: Number of matched pairs  = 9998
>>>> DEBUG 3: Observations processed   = 2920139
>>>> DEBUG 3: Rejected: GRIB code      = 2322261
>>>> DEBUG 3: Rejected: valid time     = 0
>>>> DEBUG 3: Rejected: bad obs value  = 0
>>>> DEBUG 3: Rejected: off the grid   = 486827
>>>> DEBUG 3: Rejected: level mismatch = 61549
>>>> DEBUG 3: Rejected: message type   = 5863
>>>> DEBUG 3: Rejected: masking region = 33641
>>>> DEBUG 3: Rejected: bad fcst value = 0
>>>>
>>>> That way you can tell why the observation are not be used in each
>>>> verification task.
>>>>
>>>> Lastly, I think a very possible scenario is that those NetCDF
files in
>>>> ds337.0 were generated using an earlier version of the PB2NC
tool, and
>>>> the Point-Stat tool is not handling them well.  But if
>>>> that really is the case, then I should be able to reproduce the
error
>>>> here.
>>>>
>>>> If you'd like, you could bundle up a model file, NetCDF point
>>>> observation file, and Point-Stat config file that demonstrate the
>>>> error and post them to our ftp site.  I could grab them,
reproduce the
>>>> error here, and then figure out what's going wrong.  Here's
>>>> instructions for posting to our ftp site:
>>>>        http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>>
>>>> On 06/14/2012 12:12 PM, jhenders at aer.com via RT wrote:
>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>>>>>
>>>>> Hello again John,
>>>>>
>>>>> Thanks again for your prompt response. The quick answer is that
I
>>>>> have
>>>>> tried both ways.
>>>>>
>>>>> Originally I retrieved the netcdf files directly from
>>>>> http://rda.ucar.edu/dsszone/ds337.0/index.html?g=5.
>>>>>
>>>>> Having this new archive of netcdf files at NCAR was a welcome
>>>>> discovery,
>>>>> except that they are global files and point_stat took 3 h on
NASA's
>>>>> Pleiades before failing with the error I provided.
>>>>>
>>>>> To test further, I then requested netcdf files for a
geographical
>>>>> subregion via
>>>>> http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php.
>>>>> That again fails (much faster) with the same error.
>>>>>
>>>>> I should note that I have only used point_stat with netcdf obs
files
>>>>> from 20090901 and 20090902. The error shows up on both a local
linux
>>>>> cluster as well as on Pleiades.
>>>>>
>>>>> In the past hour I have retrieved a PrepBufr file from NCAR and
run
>>>>> pb2nc on Pleiades. I then provide that ncdf file to point_stat.
I was
>>>>> able to get past the error, though (for unknown reasons) I am
not
>>>>> finding any successful matches.
>>>>>
>>>>> This suggests a problem with the ncdf files at NCAR.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>> On 6/14/12 12:36 PM, John Halley Gotway via RT wrote:
>>>>>> John,
>>>>>>
>>>>>> Very good question.  Can you please clarify one thing for me?
>>>>>>
>>>>>> Are you retrieving the PrepBufr files themselves from this
ds337
>>>>>> link:
>>>>>>          http://rda.ucar.edu/datasets/ds337.0
>>>>>> And then running them through the PB2NC tool to pre-process
them?
>>>>>>
>>>>>> Or are you using the subset request form at this link:
>>>>>>
http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php
>>>>>> And using that data as input into Point-Stat directly?
>>>>>>
>>>>>> I need to figure out which avenue needs debugging.
>>>>>>
>>>>>> Thanks,
>>>>>> John
>>>>>>
>>>>>> On 06/14/2012 09:59 AM, jhenders at aer.com via RT wrote:
>>>>>>> Thu Jun 14 09:59:39 2012: Request 56988 was acted upon.
>>>>>>> Transaction: Ticket created by jhenders at aer.com
>>>>>>>              Queue: met_help
>>>>>>>            Subject: Running point_stat with NCAR ds337 ncdf
files
>>>>>>>              Owner: Nobody
>>>>>>>         Requestors: jhenders at aer.com
>>>>>>>             Status: new
>>>>>>>        Ticket<URL:
>>>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988>
>>>>>>>
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I have recently upgraded to v3.1 of MET and am running
point_stat
>>>>>>> for
>>>>>>> the first time on two separate machines - one locally, with
the
>>>>>>> other
>>>>>>> being NASA Ames' Pleiades. I am trying to use the netcdf
PrepBufr
>>>>>>> obs
>>>>>>> files obtained from NCAR's dss337, however, all attempts to
run
>>>>>>> point_stat terminate with this error:
>>>>>>>
>>>>>>> DEBUG 1: Default Config File:
>>>>>>> /u/jmhender/NWP/WRF-
MET/METv3.1/data/config/PointStatConfig_default
>>>>>>> DEBUG 1: User Config File:
>>>>>>> PointStatConfig_V3.1-SLC-case03.20120614.13.47.57.UTC
>>>>>>> DEBUG 1: Forecast File:
>>>>>>>
/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib
>>>>>>> DEBUG 1: Climatology File: none
>>>>>>> DEBUG 1: Observation File:
>>>>>>> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090101.nc
>>>>>>> DEBUG 1: Observation File:
>>>>>>> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090102.nc
>>>>>>> DEBUG 2:
>>>>>>> DEBUG 2:
>>>>>>>
--------------------------------------------------------------------------------
>>>>>>> DEBUG 2:
>>>>>>> DEBUG 2: Reading data for TMP/P200.
>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found range
>>>>>>> match for
>>>>>>> VarInfo "TMP/P200" in GRIB record 81 of GRIB file
>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
>>>>>>> records
>>>>>>> matching VarInfo "TMP/P200" in GRIB file
>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>> DEBUG 4: parse_sid_mask() ->    parsing station ID mask file
>>>>>>> "(nul)"
>>>>>>> DEBUG 4: parse_grid_mask() ->    parsing grid mask "FULL"
>>>>>>> DEBUG 2: For TMP/P200 found 1 forecast levels and 0
climatology
>>>>>>> levels.
>>>>>>> DEBUG 2:
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>> DEBUG 3: Rotating U and V wind components from grid-relative
to
>>>>>>> earth-relative.
>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
>>>>>>> records
>>>>>>> matching VarInfo "32/Z010" in GRIB file
>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Reading V-
wind
>>>>>>> records.
>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found range
>>>>>>> match for
>>>>>>> VarInfo "32/Z010" in GRIB record 294 of GRIB file
>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>> DEBUG 3: MetGrib1DataFile::rotate_winds() ->   Have V-wind
record,
>>>>>>> reading
>>>>>>> U-wind record.
>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_scalar() ->   Found
exact
>>>>>>> match for
>>>>>>> VarInfo "32/Z010" in GRIB record 293 of GRIB file
>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>> DEBUG 3: Rotating U and V wind components from grid-relative
to
>>>>>>> earth-relative.
>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
>>>>>>> records
>>>>>>> matching VarInfo "32/Z010" in GRIB file
>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>> DEBUG 3: Deriving wind speed from U and V wind components.
>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
>>>>>>> records
>>>>>>> matching VarInfo "32/Z010" in GRIB file
>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>> DEBUG 2: For 32/Z010 found 1 forecast levels and 0 climatology
>>>>>>> levels.
>>>>>>> DEBUG 2:
>>>>>>> DEBUG 2:
>>>>>>>
--------------------------------------------------------------------------------
>>>>>>> DEBUG 2:
>>>>>>> DEBUG 2: Searching 2979273 observations from 85274 messages.
>>>>>>> ERROR  :
>>>>>>> ERROR  : process_obs_file() ->   can't read the header array
record
>>>>>>> for
>>>>>>> header number 85274
>>>>>>> ERROR  :
>>>>>>>
>>>>>>> I was wondering if this perhaps is something related to my
build of
>>>>>>> METv3.1, the way I am calling point_stat, or perhaps a bug in
the
>>>>>>> ncdf
>>>>>>> files. Note that the test script provided with METv3.1 seems
to
>>>>>>> work
>>>>>>> just fine.
>>>>>>>
>>>>>>> Any help would be much appreciated.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> John Henderson
>>>>>>>
>>>
>>>
>>
>
>
>



------------------------------------------------
Subject: Running point_stat with NCAR ds337 ncdf files
From: jhenders at aer.com
Time: Wed Jul 04 21:49:50 2012

Hello John,

No problems about the delay. I, too, am on the road this week and have
limited capabilities. When I get a chance, I will double check my
pb2nc call.

John

On 07/04/12, John Halley Gotway via RT <met_help at ucar.edu> wrote:

>
> John,
>
> Sorry for the delay in getting back with you - I've been traveling.
>
> I ran with your data and was able to reproduce the behavior you're
seeing.
>  I'm not able to get any matched pairs for TMP/Z2 or UGRD/Z10.
These
> fields should be matching against observations of type ADPSFC.  I
used the
> "plot_point_obs" tool to plot the locations of these observations in
the
> data you sent.  But in doing so, found that no such observations
exist in
> your data file:
>
> METv3.1/bin/plot_point_obs \
> obs-20090901.nc obs.ps \
> -msg_typ ADPSFC \
> -gc 11 -gc 33
> DEBUG 1: Using default global grid.
> DEBUG 1: Opening netCDF file: obs-20090901.nc
> DEBUG 1: Processing 397179 observations at 109362 locations.
> DEBUG 1: Observation GRIB codes: 34 11
> DEBUG 1: Observation message types: ADPSFC
> DEBUG 1: Creating postscript file: obs.ps
> DEBUG 2: Finished plotting 0 locations.
> DEBUG 2: Skipped 0 locations off the grid.
>
> So we need to take a step back and figure out why there are not any
ADPSFC
> observations for TMP or UGRD in the output of PB2NC.
>
> I'm a bit limited in what I can do while traveling, but can take a
better
> look when I'm back in my office on Monday.
>
> Hope that helps.
>
> John
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
> >
> > Hi John,
> >
> > Thanks for the answers. I suspected as much. I think the
documentation
> > needs to be tweaked.
> >
> > I have uploaded my files to henderson_data. Though I downloaded
the
> > prepbufr file from ds337 and used pb2nc, I have not plotted the
lat/lon
> > and timing of any ADPSFC obs. I did a quick verification attempt
for
> > another randomly-chosen date in 2009 and it also failed to match
pairs.
> >
> > I noticed that the original v3.0 code had a problem with vertical
level
> > matching for ADPSFC that was patched and, I suspect, permanently
> > corrected in v3.1. I noticed that the file structure has changed
in that
> > point-matching code between v3.1 and v3.0, so I haven't had time
to
> > evaluate further.
> >
> > Any insight you can provide using my files would be much
appreciated. I
> > am running remotely on a NASA Ames supercomputer Pleiades, in case
you
> > are wondering about some non-familiar text in any output files.
> >
> > John
> >
> > On 6/29/12 3:05 PM, John Halley Gotway via RT wrote:
> >> John,
> >>
> >> Regarding your questions at the end...
> >>
> >> (1) In previous versions of MET, the code required that the
number of
> >> thresholds specified must exactly match the number of fields
being
> >> verified in all cases.  We modified the code to only enforce
> >> that requirement when the user has requested thresholding be
performed
> >> in the "output_flag" parameter of the config file.  It's only
enforced
> >> when categorical output line types (like FHO, CTC, CTS,
> >> and so on) are requested.  In your case, your only requesting
continuous
> >> stats (CNT line type) - thus no error.
> >>
> >> (2) Where it states "ZNNN", the number of digits following 'Z'
doesn't
> >> really matter.  So "Z2", "Z02", and "Z002" are all equivalent.
> >>
> >> Regarding getting no matched pairs for the ADPSFC message type,
I'm
> >> really not sure.  It could due to any number of issues.  Probably
the
> >> quickest way to debug it would be to have you send me the data
> >> that produced the "log.txt" file you sent.  So I'd need:
> >>    - Forecast File:
> >>
/nobackupp6/jmhender/p1652/grib/2009090100/d1_2009090100_1200.grib
> >>    - Observation File:
> >> /nobackupp6/jmhender/p1652/obs/obs-nc/obs-20090901.nc
> >>    - User Config File: PointStatConfig-winds
> >>    - The command line you're using to run Point-Stat.
> >>
> >> I'll run it here, and figure out what's going on.
> >>
> >> You can post data to our anonymous ftp site as described here:
> >>      http://www.dtcenter.org/met/users/support/met_help.php
> >>
> >> Thanks,
> >> John
> >>
> >>
> >> On 06/29/2012 10:52 AM, jhenders at aer.com via RT wrote:
> >>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
> >>>
> >>> Hello again John,
> >>>
> >>> I am now back on this task and have been able to run METv3.1's
> >>> point_stat successfully for obs types other than ADPSFC. I am
running
> >>> with '-v 4'. For METv2 I had no problems getting 2-m temperature
or
> >>> 10-m
> >>> winds working in MET... The obs file I am using was
geographically
> >>> restricted to G212 by METv3.1's pb2nc.
> >>>
> >>> Any ideas? Attached is my PointStat config file and Point_Stat
output.
> >>>
> >>> I also have two points of clarification: 1) I inadvertently
omitted
> >>> thresholds in fcst_thresh for all the fields, however, the code
did not
> >>> complain, and 2) Your notation below of Z10 doesn't agree with
the
> >>> documentation or code which states ZNNN as the proper level
format. The
> >>> code seems to work either way.
> >>>
> >>> Please let me know if the above two points make sense and
whether any
> >>> action is required.
> >>>
> >>> Thanks.
> >>>
> >>> John
> >>>
> >>>
> >>>
> >>>
> >>> On 6/14/12 2:47 PM, John Halley Gotway via RT wrote:
> >>>> You mentioned getting 0 matched pairs, and not knowing why.
Please
> >>>> try running Point-Stat with "-v 3", that'll dump out more
verbose
> >>>> output and give you more detailed information for each
> >>>> verification task.  Something like the following:
> >>>>
> >>>> DEBUG 2: Processing VGRD/Z10 versus VGRD/Z10, for observation
type
> >>>> ADPSFC, over region DTC165, for interpolation method
UW_MEAN(1), using
> >>>> 9998 pairs.
> >>>> DEBUG 3: Number of matched pairs  = 9998
> >>>> DEBUG 3: Observations processed   = 2920139
> >>>> DEBUG 3: Rejected: GRIB code      = 2322261
> >>>> DEBUG 3: Rejected: valid time     = 0
> >>>> DEBUG 3: Rejected: bad obs value  = 0
> >>>> DEBUG 3: Rejected: off the grid   = 486827
> >>>> DEBUG 3: Rejected: level mismatch = 61549
> >>>> DEBUG 3: Rejected: message type   = 5863
> >>>> DEBUG 3: Rejected: masking region = 33641
> >>>> DEBUG 3: Rejected: bad fcst value = 0
> >>>>
> >>>> That way you can tell why the observation are not be used in
each
> >>>> verification task.
> >>>>
> >>>> Lastly, I think a very possible scenario is that those NetCDF
files in
> >>>> ds337.0 were generated using an earlier version of the PB2NC
tool, and
> >>>> the Point-Stat tool is not handling them well.  But if
> >>>> that really is the case, then I should be able to reproduce the
error
> >>>> here.
> >>>>
> >>>> If you'd like, you could bundle up a model file, NetCDF point
> >>>> observation file, and Point-Stat config file that demonstrate
the
> >>>> error and post them to our ftp site.  I could grab them,
reproduce the
> >>>> error here, and then figure out what's going wrong.  Here's
> >>>> instructions for posting to our ftp site:
> >>>>
http://www.dtcenter.org/met/users/support/met_help.php#ftp
> >>>>
> >>>> Thanks,
> >>>> John
> >>>>
> >>>>
> >>>> On 06/14/2012 12:12 PM, jhenders at aer.com via RT wrote:
> >>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988
>
> >>>>>
> >>>>> Hello again John,
> >>>>>
> >>>>> Thanks again for your prompt response. The quick answer is
that I
> >>>>> have
> >>>>> tried both ways.
> >>>>>
> >>>>> Originally I retrieved the netcdf files directly from
> >>>>> http://rda.ucar.edu/dsszone/ds337.0/index.html?g=5.
> >>>>>
> >>>>> Having this new archive of netcdf files at NCAR was a welcome
> >>>>> discovery,
> >>>>> except that they are global files and point_stat took 3 h on
NASA's
> >>>>> Pleiades before failing with the error I provided.
> >>>>>
> >>>>> To test further, I then requested netcdf files for a
geographical
> >>>>> subregion via
> >>>>> http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php.
> >>>>> That again fails (much faster) with the same error.
> >>>>>
> >>>>> I should note that I have only used point_stat with netcdf obs
files
> >>>>> from 20090901 and 20090902. The error shows up on both a local
linux
> >>>>> cluster as well as on Pleiades.
> >>>>>
> >>>>> In the past hour I have retrieved a PrepBufr file from NCAR
and run
> >>>>> pb2nc on Pleiades. I then provide that ncdf file to
point_stat. I was
> >>>>> able to get past the error, though (for unknown reasons) I am
not
> >>>>> finding any successful matches.
> >>>>>
> >>>>> This suggests a problem with the ncdf files at NCAR.
> >>>>>
> >>>>> Thanks.
> >>>>>
> >>>>> John
> >>>>>
> >>>>>
> >>>>> On 6/14/12 12:36 PM, John Halley Gotway via RT wrote:
> >>>>>> John,
> >>>>>>
> >>>>>> Very good question.  Can you please clarify one thing for me?
> >>>>>>
> >>>>>> Are you retrieving the PrepBufr files themselves from this
ds337
> >>>>>> link:
> >>>>>>          http://rda.ucar.edu/datasets/ds337.0
> >>>>>> And then running them through the PB2NC tool to pre-process
them?
> >>>>>>
> >>>>>> Or are you using the subset request form at this link:
> >>>>>>
http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php
> >>>>>> And using that data as input into Point-Stat directly?
> >>>>>>
> >>>>>> I need to figure out which avenue needs debugging.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> John
> >>>>>>
> >>>>>> On 06/14/2012 09:59 AM, jhenders at aer.com via RT wrote:
> >>>>>>> Thu Jun 14 09:59:39 2012: Request 56988 was acted upon.
> >>>>>>> Transaction: Ticket created by jhenders at aer.com
> >>>>>>>              Queue: met_help
> >>>>>>>            Subject: Running point_stat with NCAR ds337 ncdf
files
> >>>>>>>              Owner: Nobody
> >>>>>>>         Requestors: jhenders at aer.com
> >>>>>>>             Status: new
> >>>>>>>        Ticket<URL:
> >>>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988>
> >>>>>>>
> >>>>>>>
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> I have recently upgraded to v3.1 of MET and am running
point_stat
> >>>>>>> for
> >>>>>>> the first time on two separate machines - one locally, with
the
> >>>>>>> other
> >>>>>>> being NASA Ames' Pleiades. I am trying to use the netcdf
PrepBufr
> >>>>>>> obs
> >>>>>>> files obtained from NCAR's dss337, however, all attempts to
run
> >>>>>>> point_stat terminate with this error:
> >>>>>>>
> >>>>>>> DEBUG 1: Default Config File:
> >>>>>>> /u/jmhender/NWP/WRF-
MET/METv3.1/data/config/PointStatConfig_default
> >>>>>>> DEBUG 1: User Config File:
> >>>>>>> PointStatConfig_V3.1-SLC-case03.20120614.13.47.57.UTC
> >>>>>>> DEBUG 1: Forecast File:
> >>>>>>>
/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib
> >>>>>>> DEBUG 1: Climatology File: none
> >>>>>>> DEBUG 1: Observation File:
> >>>>>>> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090101.nc
> >>>>>>> DEBUG 1: Observation File:
> >>>>>>> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090102.nc
> >>>>>>> DEBUG 2:
> >>>>>>> DEBUG 2:
> >>>>>>>
--------------------------------------------------------------------------------
> >>>>>>> DEBUG 2:
> >>>>>>> DEBUG 2: Reading data for TMP/P200.
> >>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found
range
> >>>>>>> match for
> >>>>>>> VarInfo "TMP/P200" in GRIB record 81 of GRIB file
> >>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
> >>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
> >>>>>>> records
> >>>>>>> matching VarInfo "TMP/P200" in GRIB file
> >>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
> >>>>>>> DEBUG 4: parse_sid_mask() ->    parsing station ID mask file
> >>>>>>> "(nul)"
> >>>>>>> DEBUG 4: parse_grid_mask() ->    parsing grid mask "FULL"
> >>>>>>> DEBUG 2: For TMP/P200 found 1 forecast levels and 0
climatology
> >>>>>>> levels.
> >>>>>>> DEBUG 2:
> >>>>>>>
> >>>>>>> ...
> >>>>>>>
> >>>>>>> DEBUG 3: Rotating U and V wind components from grid-relative
to
> >>>>>>> earth-relative.
> >>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
> >>>>>>> records
> >>>>>>> matching VarInfo "32/Z010" in GRIB file
> >>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
> >>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Reading
V-wind
> >>>>>>> records.
> >>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found
range
> >>>>>>> match for
> >>>>>>> VarInfo "32/Z010" in GRIB record 294 of GRIB file
> >>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
> >>>>>>> DEBUG 3: MetGrib1DataFile::rotate_winds() ->   Have V-wind
record,
> >>>>>>> reading
> >>>>>>> U-wind record.
> >>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_scalar() ->   Found
exact
> >>>>>>> match for
> >>>>>>> VarInfo "32/Z010" in GRIB record 293 of GRIB file
> >>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
> >>>>>>> DEBUG 3: Rotating U and V wind components from grid-relative
to
> >>>>>>> earth-relative.
> >>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
> >>>>>>> records
> >>>>>>> matching VarInfo "32/Z010" in GRIB file
> >>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
> >>>>>>> DEBUG 3: Deriving wind speed from U and V wind components.
> >>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
> >>>>>>> records
> >>>>>>> matching VarInfo "32/Z010" in GRIB file
> >>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
> >>>>>>> DEBUG 2: For 32/Z010 found 1 forecast levels and 0
climatology
> >>>>>>> levels.
> >>>>>>> DEBUG 2:
> >>>>>>> DEBUG 2:
> >>>>>>>
--------------------------------------------------------------------------------
> >>>>>>> DEBUG 2:
> >>>>>>> DEBUG 2: Searching 2979273 observations from 85274 messages.
> >>>>>>> ERROR  :
> >>>>>>> ERROR  : process_obs_file() ->   can't read the header array
record
> >>>>>>> for
> >>>>>>> header number 85274
> >>>>>>> ERROR  :
> >>>>>>>
> >>>>>>> I was wondering if this perhaps is something related to my
build of
> >>>>>>> METv3.1, the way I am calling point_stat, or perhaps a bug
in the
> >>>>>>> ncdf
> >>>>>>> files. Note that the test script provided with METv3.1 seems
to
> >>>>>>> work
> >>>>>>> just fine.
> >>>>>>>
> >>>>>>> Any help would be much appreciated.
> >>>>>>>
> >>>>>>> Thanks.
> >>>>>>>
> >>>>>>> John Henderson
> >>>>>>>
> >>>
> >>>
> >>
> >
> >
> >
>
>
>
>
>



------------------------------------------------
Subject: Running point_stat with NCAR ds337 ncdf files
From: jhenders at aer.com
Time: Tue Jul 10 13:33:58 2012

Hello again John,

I have attached the pb2nc config file that I have been using. Please
let
me know if there is anything obviously incorrect with it.

Thanks.

John

On 7/4/12 10:53 AM, John Halley Gotway via RT wrote:
> John,
>
> Sorry for the delay in getting back with you - I've been traveling.
>
> I ran with your data and was able to reproduce the behavior you're
seeing.
>   I'm not able to get any matched pairs for TMP/Z2 or UGRD/Z10.
These
> fields should be matching against observations of type ADPSFC.  I
used the
> "plot_point_obs" tool to plot the locations of these observations in
the
> data you sent.  But in doing so, found that no such observations
exist in
> your data file:
>
> METv3.1/bin/plot_point_obs \
> obs-20090901.nc obs.ps \
> -msg_typ ADPSFC \
> -gc 11 -gc 33
> DEBUG 1: Using default global grid.
> DEBUG 1: Opening netCDF file: obs-20090901.nc
> DEBUG 1: Processing 397179 observations at 109362 locations.
> DEBUG 1: Observation GRIB codes: 34 11
> DEBUG 1: Observation message types: ADPSFC
> DEBUG 1: Creating postscript file: obs.ps
> DEBUG 2: Finished plotting 0 locations.
> DEBUG 2: Skipped 0 locations off the grid.
>
> So we need to take a step back and figure out why there are not any
ADPSFC
> observations for TMP or UGRD in the output of PB2NC.
>
> I'm a bit limited in what I can do while traveling, but can take a
better
> look when I'm back in my office on Monday.
>
> Hope that helps.
>
> John
>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>>
>> Hi John,
>>
>> Thanks for the answers. I suspected as much. I think the
documentation
>> needs to be tweaked.
>>
>> I have uploaded my files to henderson_data. Though I downloaded the
>> prepbufr file from ds337 and used pb2nc, I have not plotted the
lat/lon
>> and timing of any ADPSFC obs. I did a quick verification attempt
for
>> another randomly-chosen date in 2009 and it also failed to match
pairs.
>>
>> I noticed that the original v3.0 code had a problem with vertical
level
>> matching for ADPSFC that was patched and, I suspect, permanently
>> corrected in v3.1. I noticed that the file structure has changed in
that
>> point-matching code between v3.1 and v3.0, so I haven't had time to
>> evaluate further.
>>
>> Any insight you can provide using my files would be much
appreciated. I
>> am running remotely on a NASA Ames supercomputer Pleiades, in case
you
>> are wondering about some non-familiar text in any output files.
>>
>> John
>>
>> On 6/29/12 3:05 PM, John Halley Gotway via RT wrote:
>>> John,
>>>
>>> Regarding your questions at the end...
>>>
>>> (1) In previous versions of MET, the code required that the number
of
>>> thresholds specified must exactly match the number of fields being
>>> verified in all cases.  We modified the code to only enforce
>>> that requirement when the user has requested thresholding be
performed
>>> in the "output_flag" parameter of the config file.  It's only
enforced
>>> when categorical output line types (like FHO, CTC, CTS,
>>> and so on) are requested.  In your case, your only requesting
continuous
>>> stats (CNT line type) - thus no error.
>>>
>>> (2) Where it states "ZNNN", the number of digits following 'Z'
doesn't
>>> really matter.  So "Z2", "Z02", and "Z002" are all equivalent.
>>>
>>> Regarding getting no matched pairs for the ADPSFC message type,
I'm
>>> really not sure.  It could due to any number of issues.  Probably
the
>>> quickest way to debug it would be to have you send me the data
>>> that produced the "log.txt" file you sent.  So I'd need:
>>>     - Forecast File:
>>> /nobackupp6/jmhender/p1652/grib/2009090100/d1_2009090100_1200.grib
>>>     - Observation File:
>>> /nobackupp6/jmhender/p1652/obs/obs-nc/obs-20090901.nc
>>>     - User Config File: PointStatConfig-winds
>>>     - The command line you're using to run Point-Stat.
>>>
>>> I'll run it here, and figure out what's going on.
>>>
>>> You can post data to our anonymous ftp site as described here:
>>>       http://www.dtcenter.org/met/users/support/met_help.php
>>>
>>> Thanks,
>>> John
>>>
>>>
>>> On 06/29/2012 10:52 AM, jhenders at aer.com via RT wrote:
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>>>>
>>>> Hello again John,
>>>>
>>>> I am now back on this task and have been able to run METv3.1's
>>>> point_stat successfully for obs types other than ADPSFC. I am
running
>>>> with '-v 4'. For METv2 I had no problems getting 2-m temperature
or
>>>> 10-m
>>>> winds working in MET... The obs file I am using was
geographically
>>>> restricted to G212 by METv3.1's pb2nc.
>>>>
>>>> Any ideas? Attached is my PointStat config file and Point_Stat
output.
>>>>
>>>> I also have two points of clarification: 1) I inadvertently
omitted
>>>> thresholds in fcst_thresh for all the fields, however, the code
did not
>>>> complain, and 2) Your notation below of Z10 doesn't agree with
the
>>>> documentation or code which states ZNNN as the proper level
format. The
>>>> code seems to work either way.
>>>>
>>>> Please let me know if the above two points make sense and whether
any
>>>> action is required.
>>>>
>>>> Thanks.
>>>>
>>>> John
>>>>
>>>>
>>>>
>>>>
>>>> On 6/14/12 2:47 PM, John Halley Gotway via RT wrote:
>>>>> You mentioned getting 0 matched pairs, and not knowing why.
Please
>>>>> try running Point-Stat with "-v 3", that'll dump out more
verbose
>>>>> output and give you more detailed information for each
>>>>> verification task.  Something like the following:
>>>>>
>>>>> DEBUG 2: Processing VGRD/Z10 versus VGRD/Z10, for observation
type
>>>>> ADPSFC, over region DTC165, for interpolation method UW_MEAN(1),
using
>>>>> 9998 pairs.
>>>>> DEBUG 3: Number of matched pairs  = 9998
>>>>> DEBUG 3: Observations processed   = 2920139
>>>>> DEBUG 3: Rejected: GRIB code      = 2322261
>>>>> DEBUG 3: Rejected: valid time     = 0
>>>>> DEBUG 3: Rejected: bad obs value  = 0
>>>>> DEBUG 3: Rejected: off the grid   = 486827
>>>>> DEBUG 3: Rejected: level mismatch = 61549
>>>>> DEBUG 3: Rejected: message type   = 5863
>>>>> DEBUG 3: Rejected: masking region = 33641
>>>>> DEBUG 3: Rejected: bad fcst value = 0
>>>>>
>>>>> That way you can tell why the observation are not be used in
each
>>>>> verification task.
>>>>>
>>>>> Lastly, I think a very possible scenario is that those NetCDF
files in
>>>>> ds337.0 were generated using an earlier version of the PB2NC
tool, and
>>>>> the Point-Stat tool is not handling them well.  But if
>>>>> that really is the case, then I should be able to reproduce the
error
>>>>> here.
>>>>>
>>>>> If you'd like, you could bundle up a model file, NetCDF point
>>>>> observation file, and Point-Stat config file that demonstrate
the
>>>>> error and post them to our ftp site.  I could grab them,
reproduce the
>>>>> error here, and then figure out what's going wrong.  Here's
>>>>> instructions for posting to our ftp site:
>>>>>
http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>>
>>>>> On 06/14/2012 12:12 PM, jhenders at aer.com via RT wrote:
>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>>>>>>
>>>>>> Hello again John,
>>>>>>
>>>>>> Thanks again for your prompt response. The quick answer is that
I
>>>>>> have
>>>>>> tried both ways.
>>>>>>
>>>>>> Originally I retrieved the netcdf files directly from
>>>>>> http://rda.ucar.edu/dsszone/ds337.0/index.html?g=5.
>>>>>>
>>>>>> Having this new archive of netcdf files at NCAR was a welcome
>>>>>> discovery,
>>>>>> except that they are global files and point_stat took 3 h on
NASA's
>>>>>> Pleiades before failing with the error I provided.
>>>>>>
>>>>>> To test further, I then requested netcdf files for a
geographical
>>>>>> subregion via
>>>>>> http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php.
>>>>>> That again fails (much faster) with the same error.
>>>>>>
>>>>>> I should note that I have only used point_stat with netcdf obs
files
>>>>>> from 20090901 and 20090902. The error shows up on both a local
linux
>>>>>> cluster as well as on Pleiades.
>>>>>>
>>>>>> In the past hour I have retrieved a PrepBufr file from NCAR and
run
>>>>>> pb2nc on Pleiades. I then provide that ncdf file to point_stat.
I was
>>>>>> able to get past the error, though (for unknown reasons) I am
not
>>>>>> finding any successful matches.
>>>>>>
>>>>>> This suggests a problem with the ncdf files at NCAR.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> John
>>>>>>
>>>>>>
>>>>>> On 6/14/12 12:36 PM, John Halley Gotway via RT wrote:
>>>>>>> John,
>>>>>>>
>>>>>>> Very good question.  Can you please clarify one thing for me?
>>>>>>>
>>>>>>> Are you retrieving the PrepBufr files themselves from this
ds337
>>>>>>> link:
>>>>>>>           http://rda.ucar.edu/datasets/ds337.0
>>>>>>> And then running them through the PB2NC tool to pre-process
them?
>>>>>>>
>>>>>>> Or are you using the subset request form at this link:
>>>>>>>
http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php
>>>>>>> And using that data as input into Point-Stat directly?
>>>>>>>
>>>>>>> I need to figure out which avenue needs debugging.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> John
>>>>>>>
>>>>>>> On 06/14/2012 09:59 AM, jhenders at aer.com via RT wrote:
>>>>>>>> Thu Jun 14 09:59:39 2012: Request 56988 was acted upon.
>>>>>>>> Transaction: Ticket created by jhenders at aer.com
>>>>>>>>               Queue: met_help
>>>>>>>>             Subject: Running point_stat with NCAR ds337 ncdf
files
>>>>>>>>               Owner: Nobody
>>>>>>>>          Requestors: jhenders at aer.com
>>>>>>>>              Status: new
>>>>>>>>         Ticket<URL:
>>>>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I have recently upgraded to v3.1 of MET and am running
point_stat
>>>>>>>> for
>>>>>>>> the first time on two separate machines - one locally, with
the
>>>>>>>> other
>>>>>>>> being NASA Ames' Pleiades. I am trying to use the netcdf
PrepBufr
>>>>>>>> obs
>>>>>>>> files obtained from NCAR's dss337, however, all attempts to
run
>>>>>>>> point_stat terminate with this error:
>>>>>>>>
>>>>>>>> DEBUG 1: Default Config File:
>>>>>>>> /u/jmhender/NWP/WRF-
MET/METv3.1/data/config/PointStatConfig_default
>>>>>>>> DEBUG 1: User Config File:
>>>>>>>> PointStatConfig_V3.1-SLC-case03.20120614.13.47.57.UTC
>>>>>>>> DEBUG 1: Forecast File:
>>>>>>>>
/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib
>>>>>>>> DEBUG 1: Climatology File: none
>>>>>>>> DEBUG 1: Observation File:
>>>>>>>> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090101.nc
>>>>>>>> DEBUG 1: Observation File:
>>>>>>>> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090102.nc
>>>>>>>> DEBUG 2:
>>>>>>>> DEBUG 2:
>>>>>>>>
--------------------------------------------------------------------------------
>>>>>>>> DEBUG 2:
>>>>>>>> DEBUG 2: Reading data for TMP/P200.
>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found
range
>>>>>>>> match for
>>>>>>>> VarInfo "TMP/P200" in GRIB record 81 of GRIB file
>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
>>>>>>>> records
>>>>>>>> matching VarInfo "TMP/P200" in GRIB file
>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>> DEBUG 4: parse_sid_mask() ->    parsing station ID mask file
>>>>>>>> "(nul)"
>>>>>>>> DEBUG 4: parse_grid_mask() ->    parsing grid mask "FULL"
>>>>>>>> DEBUG 2: For TMP/P200 found 1 forecast levels and 0
climatology
>>>>>>>> levels.
>>>>>>>> DEBUG 2:
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>> DEBUG 3: Rotating U and V wind components from grid-relative
to
>>>>>>>> earth-relative.
>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
>>>>>>>> records
>>>>>>>> matching VarInfo "32/Z010" in GRIB file
>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Reading V-
wind
>>>>>>>> records.
>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found
range
>>>>>>>> match for
>>>>>>>> VarInfo "32/Z010" in GRIB record 294 of GRIB file
>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>> DEBUG 3: MetGrib1DataFile::rotate_winds() ->   Have V-wind
record,
>>>>>>>> reading
>>>>>>>> U-wind record.
>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_scalar() ->   Found
exact
>>>>>>>> match for
>>>>>>>> VarInfo "32/Z010" in GRIB record 293 of GRIB file
>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>> DEBUG 3: Rotating U and V wind components from grid-relative
to
>>>>>>>> earth-relative.
>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
>>>>>>>> records
>>>>>>>> matching VarInfo "32/Z010" in GRIB file
>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>> DEBUG 3: Deriving wind speed from U and V wind components.
>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
>>>>>>>> records
>>>>>>>> matching VarInfo "32/Z010" in GRIB file
>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>> DEBUG 2: For 32/Z010 found 1 forecast levels and 0
climatology
>>>>>>>> levels.
>>>>>>>> DEBUG 2:
>>>>>>>> DEBUG 2:
>>>>>>>>
--------------------------------------------------------------------------------
>>>>>>>> DEBUG 2:
>>>>>>>> DEBUG 2: Searching 2979273 observations from 85274 messages.
>>>>>>>> ERROR  :
>>>>>>>> ERROR  : process_obs_file() ->   can't read the header array
record
>>>>>>>> for
>>>>>>>> header number 85274
>>>>>>>> ERROR  :
>>>>>>>>
>>>>>>>> I was wondering if this perhaps is something related to my
build of
>>>>>>>> METv3.1, the way I am calling point_stat, or perhaps a bug in
the
>>>>>>>> ncdf
>>>>>>>> files. Note that the test script provided with METv3.1 seems
to
>>>>>>>> work
>>>>>>>> just fine.
>>>>>>>>
>>>>>>>> Any help would be much appreciated.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> John Henderson
>>>>>>>>
>>>>
>>
>>
>
>



------------------------------------------------
Subject: Running point_stat with NCAR ds337 ncdf files
From: jhenders at aer.com
Time: Tue Jul 10 13:33:58 2012

////////////////////////////////////////////////////////////////////////////////
//
// Default pb2nc configuration file
//
////////////////////////////////////////////////////////////////////////////////

//
// Stratify the observation data in the PrepBufr files in the
following
// ways:
//  (1) by message type: supply a list of PrepBufr message types
//      to retain (i.e. AIRCFT)
//  (2) by station id: supply a list of observation stations to retain
//  (3) by valid time: supply starting and ending times in form
//      YYYY-MM-DD HH:MM:SS UTC
//  (4) by location: supply either an NCEP masking grid, a masking
//      lat/lon polygon or a file to a mask lat/lon polygon
//  (5) by elevation: supply min/max elevation values
//  (6) by report type (typ): supply a list of report types to retain
//  (7) by instrument type (itp): supply a list of instrument type to
//      retain
//  (8) by vertical level: supply min/max vertical levels
//  (9) by variable type: supply a list of variable types to retain
//      P, Q, T, Z, U, V
// (11) by quality mark: supply a quality mark threshold
// (12) Flag to retain values for all quality marks, or just the first
//      quality mark (highest)
// (13) by data level category: supply a list of category types to
//      retain.
//
//      0 - Surface level (mass reports only)
//      1 - Mandatory level (upper-air profile reports)
//      2 - Significant temperature level (upper-air profile reports)
//      2 - Significant temperature and winds-by-pressure level
//          (future combined mass and wind upper-air reports)
//      3 - Winds-by-pressure level (upper-air profile reports)
//      4 - Winds-by-height level (upper-air profile reports)
//      5 - Tropopause level (upper-air profile reports)
//      6 - Reports on a single level
//          (e.g., aircraft, satellite-wind, surface wind,
//           precipitable water retrievals, etc.)
//      7 - Auxiliary levels generated via interpolation from spanning
levels
//          (upper-air profile reports)
//

//
// Specify a comma-separated list of PrepBufr message type strings to
retain.
// An empty list indicates that all should be retained.
// List of valid message types:
//    ADPUPA AIRCAR AIRCFT ADPSFC ERS1DA GOESND GPSIPW
//    MSONET PROFLR QKSWND RASSDA SATEMP SATWND SFCBOG
//    SFCSHP SPSSMI SYNDAT VADWND
//    ANYAIR (= AIRCAR, AIRCFT)
//    ANYSFC (= ADPSFC, SFCSHP, ADPUPA, PROFLR)
//    ONLYSF (= ADPSFC, SFCSHP)
//
http://www.emc.ncep.noaa.gov/mmb/data_processing/prepbufr.doc/table_1.htm
//
// e.g. message_type[] = [ "ADPUPA", "AIRCAR" ];
//
message_type[] = [ "ADPUPA",  "AIRCAR", "AIRCFT", "ADPSFC", "MSONET",
"PROFLR", "RASSDA", "SFCSHP", "SYNDAT" ];

//
// Specify a comma-separated list of station ID strings to retain.
// An empty list indicates that all should be retained.
//
// e.g. station_id[] = [ "KDEN" ];
//
station_id[] = [];

//
// Beginning and ending time offset values in seconds for observations
// to retain.  The valid time window for retaining observations is
// defined in reference to the observation time.  So observations with
// a valid time falling in the window [obs_time+beg_ds,
obs_time+end_ds]
// will be retained.
//
beg_ds = -10800;
end_ds =  10800;

//
// Specify the name of a single grid to be used in masking the data.
// An empty string indicates that no grid should be used.  The
standard
// NCEP grids are named "GNNN" where NNN indicates the three digit
grid number.
//
// http://www.nco.ncep.noaa.gov/pmb/docs/on388/tableb.html
//
// e.g. mask_grid = "G212";
//
mask_grid = "G212";

//
// Specify a single ASCII file containing a lat/lon polygon.
// Latitude in degrees north and longitude in degrees east.
// By default, the first and last polygon points are connected.
//
// The lat/lon polygon file should contain a name for the polygon
// followed by a space-separated list of lat/lon points:
//    "name lat1 lon1 lat2 lon2... latn lonn"
//
// MET_BASE may be used in the path for the lat/lon polygon file.
//
// e.g. mask_poly = "MET_BASE/data/poly/EAST.poly";
//
mask_poly = "";

//
// Beginning and ending elevation values in meters for observations
// to retain.
//
beg_elev = -1000;
end_elev = 100000;

//
// Specify a comma-separated list of PrepBufr report type values to
retain.
// An empty list indicates that all should be retained.
//
//
http://www.emc.ncep.noaa.gov/mmb/data_processing/prepbufr.doc/table_4.htm
//
// e.g. pb_report_type[] = [ 120, 133 ];
//
pb_report_type[] = [];

//
// Specify a comma-separated list of input report type values to
retain.
// An empty list indicates that all should be retained.
//
//
http://www.emc.ncep.noaa.gov/mmb/data_processing/prepbufr.doc/table_6.htm
//
// e.g. in_report_type[] = [ 11, 22, 23 ];
//
in_report_type[] = [];

//
// Specify a comma-separated list of instrument type values to retain.
// An empty list indicates that all should be retained.
//
// e.g. instrument_type[] = [ 52, 87 ];
//
instrument_type[] = [];

//
// Beginning and ending vertical levels to retain.
//
beg_level = 1;
end_level = 255;

//
// Specify a comma-separated list of strings containing grib codes or
// corresponding grib code abbreviations to retain or be derived from
// the available observations.
//
// Grib Codes to be RETAINED:
//    SPFH or 51 for Specific Humidity in kg/kg
//    TMP  or 11 for Temperature in K
//    HGT  or 7  for Height in meters
//    UGRD or 33 for the East-West component of the wind in m/s
//    VGRD or 34 for the North-South component of the wind in m/s
//
// Grib Codes to be DERIVED:
//    DPT   or 17 for Dewpoint Temperature in K
//    WIND  or 32 for Wind Speed in m/s
//    RH    or 52 for Relative Humidity in %
//    MIXR  or 53 for Humidity Mixing Ratio in kg/kg
//    PRMSL or  2 for Pressure Reduced to Mean Sea Level in Pa
//
// http://www.nco.ncep.noaa.gov/pmb/docs/on388/table2.html
//
// e.g. obs_grib_code[] = [ "TMP", "UGRD", "VGRD", "WIND" ];
//
obs_grib_code[] = [ "SPFH", "TMP",  "HGT",  "UGRD", "VGRD",
                    "DPT",  "WIND", "RH",   "MIXR", "PRMSL" ];

//
// Quality mark threshold to indicate which observations to retain.
// Observations with a quality mark equal to or LESS THAN this
threshold
// will be retained, while observations with a quality mark GREATER
THAN
// this threshold will be discarded.
//
http://www.emc.ncep.noaa.gov/mmb/data_processing/prepbufr.doc/table_7.htm
//
quality_mark_thresh = 2;

//
// Flag to indicate whether observations should be drawn from the top
// of the event stack (most quality controlled) or the bottom of the
// event stack (most raw).  A value of 1 indicates that the top of the
// event stack should be used while a value of zero indicates that the
// bottom should be used.
//
event_stack_flag = 1;

//
// Space comma-separated list of data level categorie values to
retain,
// where a value of:
//    0 = Surface level (mass reports only)
//    1 = Mandatory level (upper-air profile reports)
//    2 = Significant temperature level (upper-air profile reports)
//    2 = Significant temperature and winds-by-pressure level
//        (future combined mass and wind upper-air reports)
//    3 = Winds-by-pressure level (upper-air profile reports)
//    4 = Winds-by-height level (upper-air profile reports)
//    5 = Tropopause level (upper-air profile reports)
//    6 = Reports on a single level
//        (e.g., aircraft, satellite-wind, surface wind,
//         precipitable water retrievals, etc.)
//    7 = Auxiliary levels generated via interpolation from spanning
levels
//        (upper-air profile reports)
// An empty list indicates that all should be retained.
//
//
http://www.emc.ncep.noaa.gov/mmb/data_processing/prepbufr.doc/table_1.htm
//
// e.g. level_category[] = [ 0, 1 ];
//
level_category[] = [];

//
// Directory where temp files should be written by the PB2NC tool
//
tmp_dir = "tmp";

//
// Indicate a version number for the contents of this configuration
file.
// The value should generally not be modified.
//
version = "V3.1";

------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #56988] Running point_stat with NCAR ds337 ncdf files
From: John Halley Gotway
Time: Wed Jul 11 08:06:08 2012

John,

OK, here's what going on - you're using the PB2NC tool to process GDAS
PrepBufr observations.  And in the configuration file you sent me, the
quality mark threshold is set to 2, meaning that only
observations with a QM of 2 or less are retained.  However, NCEP
processes these observations in their data assimilation system in a
rather unfortunate way.  They discovered that when they assimilate
ground-based observations (ADPSFC message type), the model output gets
worse.  So in order to prevent those ADPSFC observations from being
assimilated, they just set the quality markers to 9.

It's unfortunate because we can't distinguish whether the observation
value really has problems or if NCEP just wanted to disable it's
assimilation for GDAS.

Try modifying the PB2NC config file to use:
    quality_mark_thresh = 9;

That should result in those ADPSFC message types being retained.

We actually were in the same situation as this for a recent DTC
project.  Our solution was to switch over to using the NDAS PrepBufr
observations (over North America), which do not have this quality
marker issue.  However, to my knowledge, only recent NDAS data is
publicly available.  I'm not aware of a publicly available historical
archive of it.  We retrieved the NDAS dataset for the DTC
project by pulling it directly from the NCEP machines.

Hope that helps clarify.

Thanks,
John


On 07/10/2012 01:33 PM, jhenders at aer.com via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>
> Hello again John,
>
> I have attached the pb2nc config file that I have been using. Please
let
> me know if there is anything obviously incorrect with it.
>
> Thanks.
>
> John
>
> On 7/4/12 10:53 AM, John Halley Gotway via RT wrote:
>> John,
>>
>> Sorry for the delay in getting back with you - I've been traveling.
>>
>> I ran with your data and was able to reproduce the behavior you're
seeing.
>>    I'm not able to get any matched pairs for TMP/Z2 or UGRD/Z10.
These
>> fields should be matching against observations of type ADPSFC.  I
used the
>> "plot_point_obs" tool to plot the locations of these observations
in the
>> data you sent.  But in doing so, found that no such observations
exist in
>> your data file:
>>
>> METv3.1/bin/plot_point_obs \
>> obs-20090901.nc obs.ps \
>> -msg_typ ADPSFC \
>> -gc 11 -gc 33
>> DEBUG 1: Using default global grid.
>> DEBUG 1: Opening netCDF file: obs-20090901.nc
>> DEBUG 1: Processing 397179 observations at 109362 locations.
>> DEBUG 1: Observation GRIB codes: 34 11
>> DEBUG 1: Observation message types: ADPSFC
>> DEBUG 1: Creating postscript file: obs.ps
>> DEBUG 2: Finished plotting 0 locations.
>> DEBUG 2: Skipped 0 locations off the grid.
>>
>> So we need to take a step back and figure out why there are not any
ADPSFC
>> observations for TMP or UGRD in the output of PB2NC.
>>
>> I'm a bit limited in what I can do while traveling, but can take a
better
>> look when I'm back in my office on Monday.
>>
>> Hope that helps.
>>
>> John
>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>>>
>>> Hi John,
>>>
>>> Thanks for the answers. I suspected as much. I think the
documentation
>>> needs to be tweaked.
>>>
>>> I have uploaded my files to henderson_data. Though I downloaded
the
>>> prepbufr file from ds337 and used pb2nc, I have not plotted the
lat/lon
>>> and timing of any ADPSFC obs. I did a quick verification attempt
for
>>> another randomly-chosen date in 2009 and it also failed to match
pairs.
>>>
>>> I noticed that the original v3.0 code had a problem with vertical
level
>>> matching for ADPSFC that was patched and, I suspect, permanently
>>> corrected in v3.1. I noticed that the file structure has changed
in that
>>> point-matching code between v3.1 and v3.0, so I haven't had time
to
>>> evaluate further.
>>>
>>> Any insight you can provide using my files would be much
appreciated. I
>>> am running remotely on a NASA Ames supercomputer Pleiades, in case
you
>>> are wondering about some non-familiar text in any output files.
>>>
>>> John
>>>
>>> On 6/29/12 3:05 PM, John Halley Gotway via RT wrote:
>>>> John,
>>>>
>>>> Regarding your questions at the end...
>>>>
>>>> (1) In previous versions of MET, the code required that the
number of
>>>> thresholds specified must exactly match the number of fields
being
>>>> verified in all cases.  We modified the code to only enforce
>>>> that requirement when the user has requested thresholding be
performed
>>>> in the "output_flag" parameter of the config file.  It's only
enforced
>>>> when categorical output line types (like FHO, CTC, CTS,
>>>> and so on) are requested.  In your case, your only requesting
continuous
>>>> stats (CNT line type) - thus no error.
>>>>
>>>> (2) Where it states "ZNNN", the number of digits following 'Z'
doesn't
>>>> really matter.  So "Z2", "Z02", and "Z002" are all equivalent.
>>>>
>>>> Regarding getting no matched pairs for the ADPSFC message type,
I'm
>>>> really not sure.  It could due to any number of issues.  Probably
the
>>>> quickest way to debug it would be to have you send me the data
>>>> that produced the "log.txt" file you sent.  So I'd need:
>>>>      - Forecast File:
>>>>
/nobackupp6/jmhender/p1652/grib/2009090100/d1_2009090100_1200.grib
>>>>      - Observation File:
>>>> /nobackupp6/jmhender/p1652/obs/obs-nc/obs-20090901.nc
>>>>      - User Config File: PointStatConfig-winds
>>>>      - The command line you're using to run Point-Stat.
>>>>
>>>> I'll run it here, and figure out what's going on.
>>>>
>>>> You can post data to our anonymous ftp site as described here:
>>>>        http://www.dtcenter.org/met/users/support/met_help.php
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>>
>>>> On 06/29/2012 10:52 AM, jhenders at aer.com via RT wrote:
>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>>>>>
>>>>> Hello again John,
>>>>>
>>>>> I am now back on this task and have been able to run METv3.1's
>>>>> point_stat successfully for obs types other than ADPSFC. I am
running
>>>>> with '-v 4'. For METv2 I had no problems getting 2-m temperature
or
>>>>> 10-m
>>>>> winds working in MET... The obs file I am using was
geographically
>>>>> restricted to G212 by METv3.1's pb2nc.
>>>>>
>>>>> Any ideas? Attached is my PointStat config file and Point_Stat
output.
>>>>>
>>>>> I also have two points of clarification: 1) I inadvertently
omitted
>>>>> thresholds in fcst_thresh for all the fields, however, the code
did not
>>>>> complain, and 2) Your notation below of Z10 doesn't agree with
the
>>>>> documentation or code which states ZNNN as the proper level
format. The
>>>>> code seems to work either way.
>>>>>
>>>>> Please let me know if the above two points make sense and
whether any
>>>>> action is required.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 6/14/12 2:47 PM, John Halley Gotway via RT wrote:
>>>>>> You mentioned getting 0 matched pairs, and not knowing why.
Please
>>>>>> try running Point-Stat with "-v 3", that'll dump out more
verbose
>>>>>> output and give you more detailed information for each
>>>>>> verification task.  Something like the following:
>>>>>>
>>>>>> DEBUG 2: Processing VGRD/Z10 versus VGRD/Z10, for observation
type
>>>>>> ADPSFC, over region DTC165, for interpolation method
UW_MEAN(1), using
>>>>>> 9998 pairs.
>>>>>> DEBUG 3: Number of matched pairs  = 9998
>>>>>> DEBUG 3: Observations processed   = 2920139
>>>>>> DEBUG 3: Rejected: GRIB code      = 2322261
>>>>>> DEBUG 3: Rejected: valid time     = 0
>>>>>> DEBUG 3: Rejected: bad obs value  = 0
>>>>>> DEBUG 3: Rejected: off the grid   = 486827
>>>>>> DEBUG 3: Rejected: level mismatch = 61549
>>>>>> DEBUG 3: Rejected: message type   = 5863
>>>>>> DEBUG 3: Rejected: masking region = 33641
>>>>>> DEBUG 3: Rejected: bad fcst value = 0
>>>>>>
>>>>>> That way you can tell why the observation are not be used in
each
>>>>>> verification task.
>>>>>>
>>>>>> Lastly, I think a very possible scenario is that those NetCDF
files in
>>>>>> ds337.0 were generated using an earlier version of the PB2NC
tool, and
>>>>>> the Point-Stat tool is not handling them well.  But if
>>>>>> that really is the case, then I should be able to reproduce the
error
>>>>>> here.
>>>>>>
>>>>>> If you'd like, you could bundle up a model file, NetCDF point
>>>>>> observation file, and Point-Stat config file that demonstrate
the
>>>>>> error and post them to our ftp site.  I could grab them,
reproduce the
>>>>>> error here, and then figure out what's going wrong.  Here's
>>>>>> instructions for posting to our ftp site:
>>>>>>
http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>>>>
>>>>>> Thanks,
>>>>>> John
>>>>>>
>>>>>>
>>>>>> On 06/14/2012 12:12 PM, jhenders at aer.com via RT wrote:
>>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988
>
>>>>>>>
>>>>>>> Hello again John,
>>>>>>>
>>>>>>> Thanks again for your prompt response. The quick answer is
that I
>>>>>>> have
>>>>>>> tried both ways.
>>>>>>>
>>>>>>> Originally I retrieved the netcdf files directly from
>>>>>>> http://rda.ucar.edu/dsszone/ds337.0/index.html?g=5.
>>>>>>>
>>>>>>> Having this new archive of netcdf files at NCAR was a welcome
>>>>>>> discovery,
>>>>>>> except that they are global files and point_stat took 3 h on
NASA's
>>>>>>> Pleiades before failing with the error I provided.
>>>>>>>
>>>>>>> To test further, I then requested netcdf files for a
geographical
>>>>>>> subregion via
>>>>>>> http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php.
>>>>>>> That again fails (much faster) with the same error.
>>>>>>>
>>>>>>> I should note that I have only used point_stat with netcdf obs
files
>>>>>>> from 20090901 and 20090902. The error shows up on both a local
linux
>>>>>>> cluster as well as on Pleiades.
>>>>>>>
>>>>>>> In the past hour I have retrieved a PrepBufr file from NCAR
and run
>>>>>>> pb2nc on Pleiades. I then provide that ncdf file to
point_stat. I was
>>>>>>> able to get past the error, though (for unknown reasons) I am
not
>>>>>>> finding any successful matches.
>>>>>>>
>>>>>>> This suggests a problem with the ncdf files at NCAR.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>> On 6/14/12 12:36 PM, John Halley Gotway via RT wrote:
>>>>>>>> John,
>>>>>>>>
>>>>>>>> Very good question.  Can you please clarify one thing for me?
>>>>>>>>
>>>>>>>> Are you retrieving the PrepBufr files themselves from this
ds337
>>>>>>>> link:
>>>>>>>>            http://rda.ucar.edu/datasets/ds337.0
>>>>>>>> And then running them through the PB2NC tool to pre-process
them?
>>>>>>>>
>>>>>>>> Or are you using the subset request form at this link:
>>>>>>>>
http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php
>>>>>>>> And using that data as input into Point-Stat directly?
>>>>>>>>
>>>>>>>> I need to figure out which avenue needs debugging.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> John
>>>>>>>>
>>>>>>>> On 06/14/2012 09:59 AM, jhenders at aer.com via RT wrote:
>>>>>>>>> Thu Jun 14 09:59:39 2012: Request 56988 was acted upon.
>>>>>>>>> Transaction: Ticket created by jhenders at aer.com
>>>>>>>>>                Queue: met_help
>>>>>>>>>              Subject: Running point_stat with NCAR ds337
ncdf files
>>>>>>>>>                Owner: Nobody
>>>>>>>>>           Requestors: jhenders at aer.com
>>>>>>>>>               Status: new
>>>>>>>>>          Ticket<URL:
>>>>>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I have recently upgraded to v3.1 of MET and am running
point_stat
>>>>>>>>> for
>>>>>>>>> the first time on two separate machines - one locally, with
the
>>>>>>>>> other
>>>>>>>>> being NASA Ames' Pleiades. I am trying to use the netcdf
PrepBufr
>>>>>>>>> obs
>>>>>>>>> files obtained from NCAR's dss337, however, all attempts to
run
>>>>>>>>> point_stat terminate with this error:
>>>>>>>>>
>>>>>>>>> DEBUG 1: Default Config File:
>>>>>>>>> /u/jmhender/NWP/WRF-
MET/METv3.1/data/config/PointStatConfig_default
>>>>>>>>> DEBUG 1: User Config File:
>>>>>>>>> PointStatConfig_V3.1-SLC-case03.20120614.13.47.57.UTC
>>>>>>>>> DEBUG 1: Forecast File:
>>>>>>>>>
/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib
>>>>>>>>> DEBUG 1: Climatology File: none
>>>>>>>>> DEBUG 1: Observation File:
>>>>>>>>> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090101.nc
>>>>>>>>> DEBUG 1: Observation File:
>>>>>>>>> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090102.nc
>>>>>>>>> DEBUG 2:
>>>>>>>>> DEBUG 2:
>>>>>>>>>
--------------------------------------------------------------------------------
>>>>>>>>> DEBUG 2:
>>>>>>>>> DEBUG 2: Reading data for TMP/P200.
>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found
range
>>>>>>>>> match for
>>>>>>>>> VarInfo "TMP/P200" in GRIB record 81 of GRIB file
>>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
>>>>>>>>> records
>>>>>>>>> matching VarInfo "TMP/P200" in GRIB file
>>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>>> DEBUG 4: parse_sid_mask() ->    parsing station ID mask file
>>>>>>>>> "(nul)"
>>>>>>>>> DEBUG 4: parse_grid_mask() ->    parsing grid mask "FULL"
>>>>>>>>> DEBUG 2: For TMP/P200 found 1 forecast levels and 0
climatology
>>>>>>>>> levels.
>>>>>>>>> DEBUG 2:
>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> DEBUG 3: Rotating U and V wind components from grid-relative
to
>>>>>>>>> earth-relative.
>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
>>>>>>>>> records
>>>>>>>>> matching VarInfo "32/Z010" in GRIB file
>>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Reading
V-wind
>>>>>>>>> records.
>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found
range
>>>>>>>>> match for
>>>>>>>>> VarInfo "32/Z010" in GRIB record 294 of GRIB file
>>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>>> DEBUG 3: MetGrib1DataFile::rotate_winds() ->   Have V-wind
record,
>>>>>>>>> reading
>>>>>>>>> U-wind record.
>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_scalar() ->   Found
exact
>>>>>>>>> match for
>>>>>>>>> VarInfo "32/Z010" in GRIB record 293 of GRIB file
>>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>>> DEBUG 3: Rotating U and V wind components from grid-relative
to
>>>>>>>>> earth-relative.
>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
>>>>>>>>> records
>>>>>>>>> matching VarInfo "32/Z010" in GRIB file
>>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>>> DEBUG 3: Deriving wind speed from U and V wind components.
>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
>>>>>>>>> records
>>>>>>>>> matching VarInfo "32/Z010" in GRIB file
>>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>>> DEBUG 2: For 32/Z010 found 1 forecast levels and 0
climatology
>>>>>>>>> levels.
>>>>>>>>> DEBUG 2:
>>>>>>>>> DEBUG 2:
>>>>>>>>>
--------------------------------------------------------------------------------
>>>>>>>>> DEBUG 2:
>>>>>>>>> DEBUG 2: Searching 2979273 observations from 85274 messages.
>>>>>>>>> ERROR  :
>>>>>>>>> ERROR  : process_obs_file() ->   can't read the header array
record
>>>>>>>>> for
>>>>>>>>> header number 85274
>>>>>>>>> ERROR  :
>>>>>>>>>
>>>>>>>>> I was wondering if this perhaps is something related to my
build of
>>>>>>>>> METv3.1, the way I am calling point_stat, or perhaps a bug
in the
>>>>>>>>> ncdf
>>>>>>>>> files. Note that the test script provided with METv3.1 seems
to
>>>>>>>>> work
>>>>>>>>> just fine.
>>>>>>>>>
>>>>>>>>> Any help would be much appreciated.
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> John Henderson
>>>>>>>>>
>>>>>
>>>
>>>
>>
>>
>
>
>


------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #56988] Running point_stat with NCAR ds337 ncdf files
From: jhenders at aer.com
Time: Wed Jul 11 11:58:53 2012

Hello John,

Thanks so much for delving into this. I'm glad your experience with a
DTC project brought this to light. I do see that the NDAS obs are
essentially available only for the most recent day or two.

I will try rerunning with a much lower quality mark. I believe the
value
of 2 that I used was the default value, but I will change that to 9.

John

On 7/11/12 10:06 AM, John Halley Gotway via RT wrote:
> John,
>
> OK, here's what going on - you're using the PB2NC tool to process
GDAS PrepBufr observations.  And in the configuration file you sent
me, the quality mark threshold is set to 2, meaning that only
> observations with a QM of 2 or less are retained.  However, NCEP
processes these observations in their data assimilation system in a
rather unfortunate way.  They discovered that when they assimilate
> ground-based observations (ADPSFC message type), the model output
gets worse.  So in order to prevent those ADPSFC observations from
being assimilated, they just set the quality markers to 9.
>
> It's unfortunate because we can't distinguish whether the
observation value really has problems or if NCEP just wanted to
disable it's assimilation for GDAS.
>
> Try modifying the PB2NC config file to use:
>      quality_mark_thresh = 9;
>
> That should result in those ADPSFC message types being retained.
>
> We actually were in the same situation as this for a recent DTC
project.  Our solution was to switch over to using the NDAS PrepBufr
observations (over North America), which do not have this quality
> marker issue.  However, to my knowledge, only recent NDAS data is
publicly available.  I'm not aware of a publicly available historical
archive of it.  We retrieved the NDAS dataset for the DTC
> project by pulling it directly from the NCEP machines.
>
> Hope that helps clarify.
>
> Thanks,
> John
>
>
> On 07/10/2012 01:33 PM, jhenders at aer.com via RT wrote:
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>>
>> Hello again John,
>>
>> I have attached the pb2nc config file that I have been using.
Please let
>> me know if there is anything obviously incorrect with it.
>>
>> Thanks.
>>
>> John
>>
>> On 7/4/12 10:53 AM, John Halley Gotway via RT wrote:
>>> John,
>>>
>>> Sorry for the delay in getting back with you - I've been
traveling.
>>>
>>> I ran with your data and was able to reproduce the behavior you're
seeing.
>>>     I'm not able to get any matched pairs for TMP/Z2 or UGRD/Z10.
These
>>> fields should be matching against observations of type ADPSFC.  I
used the
>>> "plot_point_obs" tool to plot the locations of these observations
in the
>>> data you sent.  But in doing so, found that no such observations
exist in
>>> your data file:
>>>
>>> METv3.1/bin/plot_point_obs \
>>> obs-20090901.nc obs.ps \
>>> -msg_typ ADPSFC \
>>> -gc 11 -gc 33
>>> DEBUG 1: Using default global grid.
>>> DEBUG 1: Opening netCDF file: obs-20090901.nc
>>> DEBUG 1: Processing 397179 observations at 109362 locations.
>>> DEBUG 1: Observation GRIB codes: 34 11
>>> DEBUG 1: Observation message types: ADPSFC
>>> DEBUG 1: Creating postscript file: obs.ps
>>> DEBUG 2: Finished plotting 0 locations.
>>> DEBUG 2: Skipped 0 locations off the grid.
>>>
>>> So we need to take a step back and figure out why there are not
any ADPSFC
>>> observations for TMP or UGRD in the output of PB2NC.
>>>
>>> I'm a bit limited in what I can do while traveling, but can take a
better
>>> look when I'm back in my office on Monday.
>>>
>>> Hope that helps.
>>>
>>> John
>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>>>>
>>>> Hi John,
>>>>
>>>> Thanks for the answers. I suspected as much. I think the
documentation
>>>> needs to be tweaked.
>>>>
>>>> I have uploaded my files to henderson_data. Though I downloaded
the
>>>> prepbufr file from ds337 and used pb2nc, I have not plotted the
lat/lon
>>>> and timing of any ADPSFC obs. I did a quick verification attempt
for
>>>> another randomly-chosen date in 2009 and it also failed to match
pairs.
>>>>
>>>> I noticed that the original v3.0 code had a problem with vertical
level
>>>> matching for ADPSFC that was patched and, I suspect, permanently
>>>> corrected in v3.1. I noticed that the file structure has changed
in that
>>>> point-matching code between v3.1 and v3.0, so I haven't had time
to
>>>> evaluate further.
>>>>
>>>> Any insight you can provide using my files would be much
appreciated. I
>>>> am running remotely on a NASA Ames supercomputer Pleiades, in
case you
>>>> are wondering about some non-familiar text in any output files.
>>>>
>>>> John
>>>>
>>>> On 6/29/12 3:05 PM, John Halley Gotway via RT wrote:
>>>>> John,
>>>>>
>>>>> Regarding your questions at the end...
>>>>>
>>>>> (1) In previous versions of MET, the code required that the
number of
>>>>> thresholds specified must exactly match the number of fields
being
>>>>> verified in all cases.  We modified the code to only enforce
>>>>> that requirement when the user has requested thresholding be
performed
>>>>> in the "output_flag" parameter of the config file.  It's only
enforced
>>>>> when categorical output line types (like FHO, CTC, CTS,
>>>>> and so on) are requested.  In your case, your only requesting
continuous
>>>>> stats (CNT line type) - thus no error.
>>>>>
>>>>> (2) Where it states "ZNNN", the number of digits following 'Z'
doesn't
>>>>> really matter.  So "Z2", "Z02", and "Z002" are all equivalent.
>>>>>
>>>>> Regarding getting no matched pairs for the ADPSFC message type,
I'm
>>>>> really not sure.  It could due to any number of issues.
Probably the
>>>>> quickest way to debug it would be to have you send me the data
>>>>> that produced the "log.txt" file you sent.  So I'd need:
>>>>>       - Forecast File:
>>>>>
/nobackupp6/jmhender/p1652/grib/2009090100/d1_2009090100_1200.grib
>>>>>       - Observation File:
>>>>> /nobackupp6/jmhender/p1652/obs/obs-nc/obs-20090901.nc
>>>>>       - User Config File: PointStatConfig-winds
>>>>>       - The command line you're using to run Point-Stat.
>>>>>
>>>>> I'll run it here, and figure out what's going on.
>>>>>
>>>>> You can post data to our anonymous ftp site as described here:
>>>>>         http://www.dtcenter.org/met/users/support/met_help.php
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>>
>>>>> On 06/29/2012 10:52 AM, jhenders at aer.com via RT wrote:
>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>>>>>>
>>>>>> Hello again John,
>>>>>>
>>>>>> I am now back on this task and have been able to run METv3.1's
>>>>>> point_stat successfully for obs types other than ADPSFC. I am
running
>>>>>> with '-v 4'. For METv2 I had no problems getting 2-m
temperature or
>>>>>> 10-m
>>>>>> winds working in MET... The obs file I am using was
geographically
>>>>>> restricted to G212 by METv3.1's pb2nc.
>>>>>>
>>>>>> Any ideas? Attached is my PointStat config file and Point_Stat
output.
>>>>>>
>>>>>> I also have two points of clarification: 1) I inadvertently
omitted
>>>>>> thresholds in fcst_thresh for all the fields, however, the code
did not
>>>>>> complain, and 2) Your notation below of Z10 doesn't agree with
the
>>>>>> documentation or code which states ZNNN as the proper level
format. The
>>>>>> code seems to work either way.
>>>>>>
>>>>>> Please let me know if the above two points make sense and
whether any
>>>>>> action is required.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> John
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 6/14/12 2:47 PM, John Halley Gotway via RT wrote:
>>>>>>> You mentioned getting 0 matched pairs, and not knowing why.
Please
>>>>>>> try running Point-Stat with "-v 3", that'll dump out more
verbose
>>>>>>> output and give you more detailed information for each
>>>>>>> verification task.  Something like the following:
>>>>>>>
>>>>>>> DEBUG 2: Processing VGRD/Z10 versus VGRD/Z10, for observation
type
>>>>>>> ADPSFC, over region DTC165, for interpolation method
UW_MEAN(1), using
>>>>>>> 9998 pairs.
>>>>>>> DEBUG 3: Number of matched pairs  = 9998
>>>>>>> DEBUG 3: Observations processed   = 2920139
>>>>>>> DEBUG 3: Rejected: GRIB code      = 2322261
>>>>>>> DEBUG 3: Rejected: valid time     = 0
>>>>>>> DEBUG 3: Rejected: bad obs value  = 0
>>>>>>> DEBUG 3: Rejected: off the grid   = 486827
>>>>>>> DEBUG 3: Rejected: level mismatch = 61549
>>>>>>> DEBUG 3: Rejected: message type   = 5863
>>>>>>> DEBUG 3: Rejected: masking region = 33641
>>>>>>> DEBUG 3: Rejected: bad fcst value = 0
>>>>>>>
>>>>>>> That way you can tell why the observation are not be used in
each
>>>>>>> verification task.
>>>>>>>
>>>>>>> Lastly, I think a very possible scenario is that those NetCDF
files in
>>>>>>> ds337.0 were generated using an earlier version of the PB2NC
tool, and
>>>>>>> the Point-Stat tool is not handling them well.  But if
>>>>>>> that really is the case, then I should be able to reproduce
the error
>>>>>>> here.
>>>>>>>
>>>>>>> If you'd like, you could bundle up a model file, NetCDF point
>>>>>>> observation file, and Point-Stat config file that demonstrate
the
>>>>>>> error and post them to our ftp site.  I could grab them,
reproduce the
>>>>>>> error here, and then figure out what's going wrong.  Here's
>>>>>>> instructions for posting to our ftp site:
>>>>>>>
http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>>>>>
>>>>>>> Thanks,
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>> On 06/14/2012 12:12 PM, jhenders at aer.com via RT wrote:
>>>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988
>
>>>>>>>>
>>>>>>>> Hello again John,
>>>>>>>>
>>>>>>>> Thanks again for your prompt response. The quick answer is
that I
>>>>>>>> have
>>>>>>>> tried both ways.
>>>>>>>>
>>>>>>>> Originally I retrieved the netcdf files directly from
>>>>>>>> http://rda.ucar.edu/dsszone/ds337.0/index.html?g=5.
>>>>>>>>
>>>>>>>> Having this new archive of netcdf files at NCAR was a welcome
>>>>>>>> discovery,
>>>>>>>> except that they are global files and point_stat took 3 h on
NASA's
>>>>>>>> Pleiades before failing with the error I provided.
>>>>>>>>
>>>>>>>> To test further, I then requested netcdf files for a
geographical
>>>>>>>> subregion via
>>>>>>>> http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php.
>>>>>>>> That again fails (much faster) with the same error.
>>>>>>>>
>>>>>>>> I should note that I have only used point_stat with netcdf
obs files
>>>>>>>> from 20090901 and 20090902. The error shows up on both a
local linux
>>>>>>>> cluster as well as on Pleiades.
>>>>>>>>
>>>>>>>> In the past hour I have retrieved a PrepBufr file from NCAR
and run
>>>>>>>> pb2nc on Pleiades. I then provide that ncdf file to
point_stat. I was
>>>>>>>> able to get past the error, though (for unknown reasons) I am
not
>>>>>>>> finding any successful matches.
>>>>>>>>
>>>>>>>> This suggests a problem with the ncdf files at NCAR.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> John
>>>>>>>>
>>>>>>>>
>>>>>>>> On 6/14/12 12:36 PM, John Halley Gotway via RT wrote:
>>>>>>>>> John,
>>>>>>>>>
>>>>>>>>> Very good question.  Can you please clarify one thing for
me?
>>>>>>>>>
>>>>>>>>> Are you retrieving the PrepBufr files themselves from this
ds337
>>>>>>>>> link:
>>>>>>>>>             http://rda.ucar.edu/datasets/ds337.0
>>>>>>>>> And then running them through the PB2NC tool to pre-process
them?
>>>>>>>>>
>>>>>>>>> Or are you using the subset request form at this link:
>>>>>>>>>
http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php
>>>>>>>>> And using that data as input into Point-Stat directly?
>>>>>>>>>
>>>>>>>>> I need to figure out which avenue needs debugging.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>> On 06/14/2012 09:59 AM, jhenders at aer.com via RT wrote:
>>>>>>>>>> Thu Jun 14 09:59:39 2012: Request 56988 was acted upon.
>>>>>>>>>> Transaction: Ticket created by jhenders at aer.com
>>>>>>>>>>                 Queue: met_help
>>>>>>>>>>               Subject: Running point_stat with NCAR ds337
ncdf files
>>>>>>>>>>                 Owner: Nobody
>>>>>>>>>>            Requestors: jhenders at aer.com
>>>>>>>>>>                Status: new
>>>>>>>>>>           Ticket<URL:
>>>>>>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> I have recently upgraded to v3.1 of MET and am running
point_stat
>>>>>>>>>> for
>>>>>>>>>> the first time on two separate machines - one locally, with
the
>>>>>>>>>> other
>>>>>>>>>> being NASA Ames' Pleiades. I am trying to use the netcdf
PrepBufr
>>>>>>>>>> obs
>>>>>>>>>> files obtained from NCAR's dss337, however, all attempts to
run
>>>>>>>>>> point_stat terminate with this error:
>>>>>>>>>>
>>>>>>>>>> DEBUG 1: Default Config File:
>>>>>>>>>> /u/jmhender/NWP/WRF-
MET/METv3.1/data/config/PointStatConfig_default
>>>>>>>>>> DEBUG 1: User Config File:
>>>>>>>>>> PointStatConfig_V3.1-SLC-case03.20120614.13.47.57.UTC
>>>>>>>>>> DEBUG 1: Forecast File:
>>>>>>>>>>
/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib
>>>>>>>>>> DEBUG 1: Climatology File: none
>>>>>>>>>> DEBUG 1: Observation File:
>>>>>>>>>> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090101.nc
>>>>>>>>>> DEBUG 1: Observation File:
>>>>>>>>>> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090102.nc
>>>>>>>>>> DEBUG 2:
>>>>>>>>>> DEBUG 2:
>>>>>>>>>>
--------------------------------------------------------------------------------
>>>>>>>>>> DEBUG 2:
>>>>>>>>>> DEBUG 2: Reading data for TMP/P200.
>>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found
range
>>>>>>>>>> match for
>>>>>>>>>> VarInfo "TMP/P200" in GRIB record 81 of GRIB file
>>>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
>>>>>>>>>> records
>>>>>>>>>> matching VarInfo "TMP/P200" in GRIB file
>>>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>>>> DEBUG 4: parse_sid_mask() ->    parsing station ID mask
file
>>>>>>>>>> "(nul)"
>>>>>>>>>> DEBUG 4: parse_grid_mask() ->    parsing grid mask "FULL"
>>>>>>>>>> DEBUG 2: For TMP/P200 found 1 forecast levels and 0
climatology
>>>>>>>>>> levels.
>>>>>>>>>> DEBUG 2:
>>>>>>>>>>
>>>>>>>>>> ...
>>>>>>>>>>
>>>>>>>>>> DEBUG 3: Rotating U and V wind components from grid-
relative to
>>>>>>>>>> earth-relative.
>>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
>>>>>>>>>> records
>>>>>>>>>> matching VarInfo "32/Z010" in GRIB file
>>>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Reading
V-wind
>>>>>>>>>> records.
>>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found
range
>>>>>>>>>> match for
>>>>>>>>>> VarInfo "32/Z010" in GRIB record 294 of GRIB file
>>>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>>>> DEBUG 3: MetGrib1DataFile::rotate_winds() ->   Have V-wind
record,
>>>>>>>>>> reading
>>>>>>>>>> U-wind record.
>>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_scalar() ->   Found
exact
>>>>>>>>>> match for
>>>>>>>>>> VarInfo "32/Z010" in GRIB record 293 of GRIB file
>>>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>>>> DEBUG 3: Rotating U and V wind components from grid-
relative to
>>>>>>>>>> earth-relative.
>>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
>>>>>>>>>> records
>>>>>>>>>> matching VarInfo "32/Z010" in GRIB file
>>>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>>>> DEBUG 3: Deriving wind speed from U and V wind components.
>>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
>>>>>>>>>> records
>>>>>>>>>> matching VarInfo "32/Z010" in GRIB file
>>>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>>>> DEBUG 2: For 32/Z010 found 1 forecast levels and 0
climatology
>>>>>>>>>> levels.
>>>>>>>>>> DEBUG 2:
>>>>>>>>>> DEBUG 2:
>>>>>>>>>>
--------------------------------------------------------------------------------
>>>>>>>>>> DEBUG 2:
>>>>>>>>>> DEBUG 2: Searching 2979273 observations from 85274
messages.
>>>>>>>>>> ERROR  :
>>>>>>>>>> ERROR  : process_obs_file() ->   can't read the header
array record
>>>>>>>>>> for
>>>>>>>>>> header number 85274
>>>>>>>>>> ERROR  :
>>>>>>>>>>
>>>>>>>>>> I was wondering if this perhaps is something related to my
build of
>>>>>>>>>> METv3.1, the way I am calling point_stat, or perhaps a bug
in the
>>>>>>>>>> ncdf
>>>>>>>>>> files. Note that the test script provided with METv3.1
seems to
>>>>>>>>>> work
>>>>>>>>>> just fine.
>>>>>>>>>>
>>>>>>>>>> Any help would be much appreciated.
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> John Henderson
>>>>>>>>>>
>>>>
>>>
>>
>>
>



------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #56988] Running point_stat with NCAR ds337 ncdf files
From: John Halley Gotway
Time: Wed Jul 11 13:00:06 2012

Great.  Glad I could help.

Thanks,
John

On 07/11/2012 11:58 AM, jhenders at aer.com via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>
> Hello John,
>
> Thanks so much for delving into this. I'm glad your experience with
a
> DTC project brought this to light. I do see that the NDAS obs are
> essentially available only for the most recent day or two.
>
> I will try rerunning with a much lower quality mark. I believe the
value
> of 2 that I used was the default value, but I will change that to 9.
>
> John
>
> On 7/11/12 10:06 AM, John Halley Gotway via RT wrote:
>> John,
>>
>> OK, here's what going on - you're using the PB2NC tool to process
GDAS PrepBufr observations.  And in the configuration file you sent
me, the quality mark threshold is set to 2, meaning that only
>> observations with a QM of 2 or less are retained.  However, NCEP
processes these observations in their data assimilation system in a
rather unfortunate way.  They discovered that when they assimilate
>> ground-based observations (ADPSFC message type), the model output
gets worse.  So in order to prevent those ADPSFC observations from
being assimilated, they just set the quality markers to 9.
>>
>> It's unfortunate because we can't distinguish whether the
observation value really has problems or if NCEP just wanted to
disable it's assimilation for GDAS.
>>
>> Try modifying the PB2NC config file to use:
>>       quality_mark_thresh = 9;
>>
>> That should result in those ADPSFC message types being retained.
>>
>> We actually were in the same situation as this for a recent DTC
project.  Our solution was to switch over to using the NDAS PrepBufr
observations (over North America), which do not have this quality
>> marker issue.  However, to my knowledge, only recent NDAS data is
publicly available.  I'm not aware of a publicly available historical
archive of it.  We retrieved the NDAS dataset for the DTC
>> project by pulling it directly from the NCEP machines.
>>
>> Hope that helps clarify.
>>
>> Thanks,
>> John
>>
>>
>> On 07/10/2012 01:33 PM, jhenders at aer.com via RT wrote:
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>>>
>>> Hello again John,
>>>
>>> I have attached the pb2nc config file that I have been using.
Please let
>>> me know if there is anything obviously incorrect with it.
>>>
>>> Thanks.
>>>
>>> John
>>>
>>> On 7/4/12 10:53 AM, John Halley Gotway via RT wrote:
>>>> John,
>>>>
>>>> Sorry for the delay in getting back with you - I've been
traveling.
>>>>
>>>> I ran with your data and was able to reproduce the behavior
you're seeing.
>>>>      I'm not able to get any matched pairs for TMP/Z2 or
UGRD/Z10.  These
>>>> fields should be matching against observations of type ADPSFC.  I
used the
>>>> "plot_point_obs" tool to plot the locations of these observations
in the
>>>> data you sent.  But in doing so, found that no such observations
exist in
>>>> your data file:
>>>>
>>>> METv3.1/bin/plot_point_obs \
>>>> obs-20090901.nc obs.ps \
>>>> -msg_typ ADPSFC \
>>>> -gc 11 -gc 33
>>>> DEBUG 1: Using default global grid.
>>>> DEBUG 1: Opening netCDF file: obs-20090901.nc
>>>> DEBUG 1: Processing 397179 observations at 109362 locations.
>>>> DEBUG 1: Observation GRIB codes: 34 11
>>>> DEBUG 1: Observation message types: ADPSFC
>>>> DEBUG 1: Creating postscript file: obs.ps
>>>> DEBUG 2: Finished plotting 0 locations.
>>>> DEBUG 2: Skipped 0 locations off the grid.
>>>>
>>>> So we need to take a step back and figure out why there are not
any ADPSFC
>>>> observations for TMP or UGRD in the output of PB2NC.
>>>>
>>>> I'm a bit limited in what I can do while traveling, but can take
a better
>>>> look when I'm back in my office on Monday.
>>>>
>>>> Hope that helps.
>>>>
>>>> John
>>>>
>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>>>>>
>>>>> Hi John,
>>>>>
>>>>> Thanks for the answers. I suspected as much. I think the
documentation
>>>>> needs to be tweaked.
>>>>>
>>>>> I have uploaded my files to henderson_data. Though I downloaded
the
>>>>> prepbufr file from ds337 and used pb2nc, I have not plotted the
lat/lon
>>>>> and timing of any ADPSFC obs. I did a quick verification attempt
for
>>>>> another randomly-chosen date in 2009 and it also failed to match
pairs.
>>>>>
>>>>> I noticed that the original v3.0 code had a problem with
vertical level
>>>>> matching for ADPSFC that was patched and, I suspect, permanently
>>>>> corrected in v3.1. I noticed that the file structure has changed
in that
>>>>> point-matching code between v3.1 and v3.0, so I haven't had time
to
>>>>> evaluate further.
>>>>>
>>>>> Any insight you can provide using my files would be much
appreciated. I
>>>>> am running remotely on a NASA Ames supercomputer Pleiades, in
case you
>>>>> are wondering about some non-familiar text in any output files.
>>>>>
>>>>> John
>>>>>
>>>>> On 6/29/12 3:05 PM, John Halley Gotway via RT wrote:
>>>>>> John,
>>>>>>
>>>>>> Regarding your questions at the end...
>>>>>>
>>>>>> (1) In previous versions of MET, the code required that the
number of
>>>>>> thresholds specified must exactly match the number of fields
being
>>>>>> verified in all cases.  We modified the code to only enforce
>>>>>> that requirement when the user has requested thresholding be
performed
>>>>>> in the "output_flag" parameter of the config file.  It's only
enforced
>>>>>> when categorical output line types (like FHO, CTC, CTS,
>>>>>> and so on) are requested.  In your case, your only requesting
continuous
>>>>>> stats (CNT line type) - thus no error.
>>>>>>
>>>>>> (2) Where it states "ZNNN", the number of digits following 'Z'
doesn't
>>>>>> really matter.  So "Z2", "Z02", and "Z002" are all equivalent.
>>>>>>
>>>>>> Regarding getting no matched pairs for the ADPSFC message type,
I'm
>>>>>> really not sure.  It could due to any number of issues.
Probably the
>>>>>> quickest way to debug it would be to have you send me the data
>>>>>> that produced the "log.txt" file you sent.  So I'd need:
>>>>>>        - Forecast File:
>>>>>>
/nobackupp6/jmhender/p1652/grib/2009090100/d1_2009090100_1200.grib
>>>>>>        - Observation File:
>>>>>> /nobackupp6/jmhender/p1652/obs/obs-nc/obs-20090901.nc
>>>>>>        - User Config File: PointStatConfig-winds
>>>>>>        - The command line you're using to run Point-Stat.
>>>>>>
>>>>>> I'll run it here, and figure out what's going on.
>>>>>>
>>>>>> You can post data to our anonymous ftp site as described here:
>>>>>>          http://www.dtcenter.org/met/users/support/met_help.php
>>>>>>
>>>>>> Thanks,
>>>>>> John
>>>>>>
>>>>>>
>>>>>> On 06/29/2012 10:52 AM, jhenders at aer.com via RT wrote:
>>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988
>
>>>>>>>
>>>>>>> Hello again John,
>>>>>>>
>>>>>>> I am now back on this task and have been able to run METv3.1's
>>>>>>> point_stat successfully for obs types other than ADPSFC. I am
running
>>>>>>> with '-v 4'. For METv2 I had no problems getting 2-m
temperature or
>>>>>>> 10-m
>>>>>>> winds working in MET... The obs file I am using was
geographically
>>>>>>> restricted to G212 by METv3.1's pb2nc.
>>>>>>>
>>>>>>> Any ideas? Attached is my PointStat config file and Point_Stat
output.
>>>>>>>
>>>>>>> I also have two points of clarification: 1) I inadvertently
omitted
>>>>>>> thresholds in fcst_thresh for all the fields, however, the
code did not
>>>>>>> complain, and 2) Your notation below of Z10 doesn't agree with
the
>>>>>>> documentation or code which states ZNNN as the proper level
format. The
>>>>>>> code seems to work either way.
>>>>>>>
>>>>>>> Please let me know if the above two points make sense and
whether any
>>>>>>> action is required.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 6/14/12 2:47 PM, John Halley Gotway via RT wrote:
>>>>>>>> You mentioned getting 0 matched pairs, and not knowing why.
Please
>>>>>>>> try running Point-Stat with "-v 3", that'll dump out more
verbose
>>>>>>>> output and give you more detailed information for each
>>>>>>>> verification task.  Something like the following:
>>>>>>>>
>>>>>>>> DEBUG 2: Processing VGRD/Z10 versus VGRD/Z10, for observation
type
>>>>>>>> ADPSFC, over region DTC165, for interpolation method
UW_MEAN(1), using
>>>>>>>> 9998 pairs.
>>>>>>>> DEBUG 3: Number of matched pairs  = 9998
>>>>>>>> DEBUG 3: Observations processed   = 2920139
>>>>>>>> DEBUG 3: Rejected: GRIB code      = 2322261
>>>>>>>> DEBUG 3: Rejected: valid time     = 0
>>>>>>>> DEBUG 3: Rejected: bad obs value  = 0
>>>>>>>> DEBUG 3: Rejected: off the grid   = 486827
>>>>>>>> DEBUG 3: Rejected: level mismatch = 61549
>>>>>>>> DEBUG 3: Rejected: message type   = 5863
>>>>>>>> DEBUG 3: Rejected: masking region = 33641
>>>>>>>> DEBUG 3: Rejected: bad fcst value = 0
>>>>>>>>
>>>>>>>> That way you can tell why the observation are not be used in
each
>>>>>>>> verification task.
>>>>>>>>
>>>>>>>> Lastly, I think a very possible scenario is that those NetCDF
files in
>>>>>>>> ds337.0 were generated using an earlier version of the PB2NC
tool, and
>>>>>>>> the Point-Stat tool is not handling them well.  But if
>>>>>>>> that really is the case, then I should be able to reproduce
the error
>>>>>>>> here.
>>>>>>>>
>>>>>>>> If you'd like, you could bundle up a model file, NetCDF point
>>>>>>>> observation file, and Point-Stat config file that demonstrate
the
>>>>>>>> error and post them to our ftp site.  I could grab them,
reproduce the
>>>>>>>> error here, and then figure out what's going wrong.  Here's
>>>>>>>> instructions for posting to our ftp site:
>>>>>>>>
http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> John
>>>>>>>>
>>>>>>>>
>>>>>>>> On 06/14/2012 12:12 PM, jhenders at aer.com via RT wrote:
>>>>>>>>> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988 >
>>>>>>>>>
>>>>>>>>> Hello again John,
>>>>>>>>>
>>>>>>>>> Thanks again for your prompt response. The quick answer is
that I
>>>>>>>>> have
>>>>>>>>> tried both ways.
>>>>>>>>>
>>>>>>>>> Originally I retrieved the netcdf files directly from
>>>>>>>>> http://rda.ucar.edu/dsszone/ds337.0/index.html?g=5.
>>>>>>>>>
>>>>>>>>> Having this new archive of netcdf files at NCAR was a
welcome
>>>>>>>>> discovery,
>>>>>>>>> except that they are global files and point_stat took 3 h on
NASA's
>>>>>>>>> Pleiades before failing with the error I provided.
>>>>>>>>>
>>>>>>>>> To test further, I then requested netcdf files for a
geographical
>>>>>>>>> subregion via
>>>>>>>>> http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php.
>>>>>>>>> That again fails (much faster) with the same error.
>>>>>>>>>
>>>>>>>>> I should note that I have only used point_stat with netcdf
obs files
>>>>>>>>> from 20090901 and 20090902. The error shows up on both a
local linux
>>>>>>>>> cluster as well as on Pleiades.
>>>>>>>>>
>>>>>>>>> In the past hour I have retrieved a PrepBufr file from NCAR
and run
>>>>>>>>> pb2nc on Pleiades. I then provide that ncdf file to
point_stat. I was
>>>>>>>>> able to get past the error, though (for unknown reasons) I
am not
>>>>>>>>> finding any successful matches.
>>>>>>>>>
>>>>>>>>> This suggests a problem with the ncdf files at NCAR.
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 6/14/12 12:36 PM, John Halley Gotway via RT wrote:
>>>>>>>>>> John,
>>>>>>>>>>
>>>>>>>>>> Very good question.  Can you please clarify one thing for
me?
>>>>>>>>>>
>>>>>>>>>> Are you retrieving the PrepBufr files themselves from this
ds337
>>>>>>>>>> link:
>>>>>>>>>>              http://rda.ucar.edu/datasets/ds337.0
>>>>>>>>>> And then running them through the PB2NC tool to pre-process
them?
>>>>>>>>>>
>>>>>>>>>> Or are you using the subset request form at this link:
>>>>>>>>>>
http://rda.ucar.edu/datasets/ds337.0/forms/337_subset.php
>>>>>>>>>> And using that data as input into Point-Stat directly?
>>>>>>>>>>
>>>>>>>>>> I need to figure out which avenue needs debugging.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> John
>>>>>>>>>>
>>>>>>>>>> On 06/14/2012 09:59 AM, jhenders at aer.com via RT wrote:
>>>>>>>>>>> Thu Jun 14 09:59:39 2012: Request 56988 was acted upon.
>>>>>>>>>>> Transaction: Ticket created by jhenders at aer.com
>>>>>>>>>>>                  Queue: met_help
>>>>>>>>>>>                Subject: Running point_stat with NCAR ds337
ncdf files
>>>>>>>>>>>                  Owner: Nobody
>>>>>>>>>>>             Requestors: jhenders at aer.com
>>>>>>>>>>>                 Status: new
>>>>>>>>>>>            Ticket<URL:
>>>>>>>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=56988>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> I have recently upgraded to v3.1 of MET and am running
point_stat
>>>>>>>>>>> for
>>>>>>>>>>> the first time on two separate machines - one locally,
with the
>>>>>>>>>>> other
>>>>>>>>>>> being NASA Ames' Pleiades. I am trying to use the netcdf
PrepBufr
>>>>>>>>>>> obs
>>>>>>>>>>> files obtained from NCAR's dss337, however, all attempts
to run
>>>>>>>>>>> point_stat terminate with this error:
>>>>>>>>>>>
>>>>>>>>>>> DEBUG 1: Default Config File:
>>>>>>>>>>> /u/jmhender/NWP/WRF-
MET/METv3.1/data/config/PointStatConfig_default
>>>>>>>>>>> DEBUG 1: User Config File:
>>>>>>>>>>> PointStatConfig_V3.1-SLC-case03.20120614.13.47.57.UTC
>>>>>>>>>>> DEBUG 1: Forecast File:
>>>>>>>>>>>
/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib
>>>>>>>>>>> DEBUG 1: Climatology File: none
>>>>>>>>>>> DEBUG 1: Observation File:
>>>>>>>>>>> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090101.nc
>>>>>>>>>>> DEBUG 1: Observation File:
>>>>>>>>>>> /nobackupp6/jmhender/p1652/obs/netcdf.gdas.20090102.nc
>>>>>>>>>>> DEBUG 2:
>>>>>>>>>>> DEBUG 2:
>>>>>>>>>>>
--------------------------------------------------------------------------------
>>>>>>>>>>> DEBUG 2:
>>>>>>>>>>> DEBUG 2: Reading data for TMP/P200.
>>>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found
range
>>>>>>>>>>> match for
>>>>>>>>>>> VarInfo "TMP/P200" in GRIB record 81 of GRIB file
>>>>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
>>>>>>>>>>> records
>>>>>>>>>>> matching VarInfo "TMP/P200" in GRIB file
>>>>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>>>>> DEBUG 4: parse_sid_mask() ->    parsing station ID mask
file
>>>>>>>>>>> "(nul)"
>>>>>>>>>>> DEBUG 4: parse_grid_mask() ->    parsing grid mask "FULL"
>>>>>>>>>>> DEBUG 2: For TMP/P200 found 1 forecast levels and 0
climatology
>>>>>>>>>>> levels.
>>>>>>>>>>> DEBUG 2:
>>>>>>>>>>>
>>>>>>>>>>> ...
>>>>>>>>>>>
>>>>>>>>>>> DEBUG 3: Rotating U and V wind components from grid-
relative to
>>>>>>>>>>> earth-relative.
>>>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
>>>>>>>>>>> records
>>>>>>>>>>> matching VarInfo "32/Z010" in GRIB file
>>>>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Reading
V-wind
>>>>>>>>>>> records.
>>>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found
range
>>>>>>>>>>> match for
>>>>>>>>>>> VarInfo "32/Z010" in GRIB record 294 of GRIB file
>>>>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>>>>> DEBUG 3: MetGrib1DataFile::rotate_winds() ->   Have V-wind
record,
>>>>>>>>>>> reading
>>>>>>>>>>> U-wind record.
>>>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_scalar() ->   Found
exact
>>>>>>>>>>> match for
>>>>>>>>>>> VarInfo "32/Z010" in GRIB record 293 of GRIB file
>>>>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>>>>> DEBUG 3: Rotating U and V wind components from grid-
relative to
>>>>>>>>>>> earth-relative.
>>>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
>>>>>>>>>>> records
>>>>>>>>>>> matching VarInfo "32/Z010" in GRIB file
>>>>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>>>>> DEBUG 3: Deriving wind speed from U and V wind components.
>>>>>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->   Found 1
GRIB
>>>>>>>>>>> records
>>>>>>>>>>> matching VarInfo "32/Z010" in GRIB file
>>>>>>>>>>>
"/nobackupp6/jmhender/p1652/grib/2009010100/d2_2009010100_3000.grib".
>>>>>>>>>>> DEBUG 2: For 32/Z010 found 1 forecast levels and 0
climatology
>>>>>>>>>>> levels.
>>>>>>>>>>> DEBUG 2:
>>>>>>>>>>> DEBUG 2:
>>>>>>>>>>>
--------------------------------------------------------------------------------
>>>>>>>>>>> DEBUG 2:
>>>>>>>>>>> DEBUG 2: Searching 2979273 observations from 85274
messages.
>>>>>>>>>>> ERROR  :
>>>>>>>>>>> ERROR  : process_obs_file() ->   can't read the header
array record
>>>>>>>>>>> for
>>>>>>>>>>> header number 85274
>>>>>>>>>>> ERROR  :
>>>>>>>>>>>
>>>>>>>>>>> I was wondering if this perhaps is something related to my
build of
>>>>>>>>>>> METv3.1, the way I am calling point_stat, or perhaps a bug
in the
>>>>>>>>>>> ncdf
>>>>>>>>>>> files. Note that the test script provided with METv3.1
seems to
>>>>>>>>>>> work
>>>>>>>>>>> just fine.
>>>>>>>>>>>
>>>>>>>>>>> Any help would be much appreciated.
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> John Henderson
>>>>>>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


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


More information about the Met_help mailing list