[Met_help] [rt.rap.ucar.edu #80859] History for difficulty specifying field and level in MODE

Tue Jun 20 11:28:39 MDT 2017

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

Working with version 5.2:

I want to verify MRMS rotation tracks against model output updraft helicity
(hourly max in the 2-5 km AGL layer). I know from wgrib2 (the input file
format is GRIB2) that the specific array record is 42, so I can use R42 in
the level specification of the config file. However, I work with sets of
files in which the UH array may not always have that record number, so I
would like to specify the level using some other template. wgrib2 gives the
data as so:

42:48816704:00Z09may2016:MXUPHL Hourly Maximum of Updraft Helicity over
Layer 2km to 5 km AGL [m^2/s^2]:lvl1=(103,5000) lvl2=(103,2000):5000-2000 m
above ground:35-36 hour max fcst:

So I tried Z5000-2000 and Z2000-5000 in the level setting of the control
file, but MODE said

WARNING: MetGrib2DataFile::data_plane() - No matching record found for
'MXUPHL/Z5000-2000'

for both attempts.

What else can I try?

Jeff Duda
-- 
Jeff Duda
Post-doctoral research fellow
University of Oklahoma School of Meteorology

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

Subject: difficulty specifying field and level in MODE
From: John Halley Gotway
Time: Wed Jun 14 11:03:28 2017

Jeff,

Can you please point me to one of the GRIB2 MRMS files you're using?
Either send me a link to the file or just post it on our anonymous ftp
site
(http://www.dtcenter.org/met/users/support/met_help.php#ftp).  We can
run
it through the debugger and figure out what's going on.

Thanks,
John

On Wed, Jun 14, 2017 at 10:49 AM, Jeff Duda via RT <met_help at ucar.edu>
wrote:

>
> Wed Jun 14 10:49:18 2017: Request 80859 was acted upon.
> Transaction: Ticket created by jeffduda319 at gmail.com
>        Queue: met_help
>      Subject: difficulty specifying field and level in MODE
>        Owner: Nobody
>   Requestors: jeffduda319 at gmail.com
>       Status: new
>  Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
>
>
> Working with version 5.2:
>
> I want to verify MRMS rotation tracks against model output updraft
helicity
> (hourly max in the 2-5 km AGL layer). I know from wgrib2 (the input
file
> format is GRIB2) that the specific array record is 42, so I can use
R42 in
> the level specification of the config file. However, I work with
sets of
> files in which the UH array may not always have that record number,
so I
> would like to specify the level using some other template. wgrib2
gives the
> data as so:
>
> 42:48816704:00Z09may2016:MXUPHL Hourly Maximum of Updraft Helicity
over
> Layer 2km to 5 km AGL [m^2/s^2]:lvl1=(103,5000)
lvl2=(103,2000):5000-2000 m
> above ground:35-36 hour max fcst:
>
> So I tried Z5000-2000 and Z2000-5000 in the level setting of the
control
> file, but MODE said
>
> WARNING: MetGrib2DataFile::data_plane() - No matching record found
for
> 'MXUPHL/Z5000-2000'
>
> for both attempts.
>
> What else can I try?
>
> Jeff Duda
> --
> Jeff Duda
> Post-doctoral research fellow
> University of Oklahoma School of Meteorology
>
>

------------------------------------------------
Subject: difficulty specifying field and level in MODE
From: Jeff Duda
Time: Wed Jun 14 11:16:28 2017

John,
I totally waffled on explaining the data source.  While it's true I am
comparing my forecast to MRMS RotationTrack data, I am not having
trouble
with the MRMS file. Instead, the issue is with the forecast file
output
from the UPP. So I uploaded that particular file instead.

Jeff

On Wed, Jun 14, 2017 at 12:03 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:

> Jeff,
>
> Can you please point me to one of the GRIB2 MRMS files you're using?
> Either send me a link to the file or just post it on our anonymous
ftp site
> (http://www.dtcenter.org/met/users/support/met_help.php#ftp).  We
can run
> it through the debugger and figure out what's going on.
>
> Thanks,
> John
>
> On Wed, Jun 14, 2017 at 10:49 AM, Jeff Duda via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > Wed Jun 14 10:49:18 2017: Request 80859 was acted upon.
> > Transaction: Ticket created by jeffduda319 at gmail.com
> >        Queue: met_help
> >      Subject: difficulty specifying field and level in MODE
> >        Owner: Nobody
> >   Requestors: jeffduda319 at gmail.com
> >       Status: new
> >  Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> >
> >
> > Working with version 5.2:
> >
> > I want to verify MRMS rotation tracks against model output updraft
> helicity
> > (hourly max in the 2-5 km AGL layer). I know from wgrib2 (the
input file
> > format is GRIB2) that the specific array record is 42, so I can
use R42
> in
> > the level specification of the config file. However, I work with
sets of
> > files in which the UH array may not always have that record
number, so I
> > would like to specify the level using some other template. wgrib2
gives
> the
> > data as so:
> >
> > 42:48816704:00Z09may2016:MXUPHL Hourly Maximum of Updraft Helicity
over
> > Layer 2km to 5 km AGL [m^2/s^2]:lvl1=(103,5000)
> lvl2=(103,2000):5000-2000 m
> > above ground:35-36 hour max fcst:
> >
> > So I tried Z5000-2000 and Z2000-5000 in the level setting of the
control
> > file, but MODE said
> >
> > WARNING: MetGrib2DataFile::data_plane() - No matching record found
for
> > 'MXUPHL/Z5000-2000'
> >
> > for both attempts.
> >
> > What else can I try?
> >
> > Jeff Duda
> > --
> > Jeff Duda
> > Post-doctoral research fellow
> > University of Oklahoma School of Meteorology
> >
> >
>
>

--
Jeff Duda
Post-doctoral research fellow
University of Oklahoma School of Meteorology

------------------------------------------------
Subject: difficulty specifying field and level in MODE
From: John Halley Gotway
Time: Wed Jun 14 13:40:52 2017

Hi Jeff,

Thanks for sending your sample file.  I grabbed it and was able to get
the
plot_data_plane utility to create the attached plot of record number
42:

met-6.0/bin/plot_data_plane \
   CA_00Z_free_upp_d01_36_NSSL.grib2 plot.ps \
   'name="MXUPHL"; level="L2000-5000";' -v 3 -plot_range 0 70

I used the "-plot_range" option because the actual data values go from
-1000 to about 70.

I used "L2000-5000".  The "L" tells MET to match a generic level
type...
meaning don't worry about whether it's a pressure level or height...
just
make sure the level values match what's in the data.

You should be able to use the same settings in the MODE config file.

Thanks,
John

On Wed, Jun 14, 2017 at 11:16 AM, Jeff Duda via RT <met_help at ucar.edu>
wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
>
> John,
> I totally waffled on explaining the data source.  While it's true I
am
> comparing my forecast to MRMS RotationTrack data, I am not having
trouble
> with the MRMS file. Instead, the issue is with the forecast file
output
> from the UPP. So I uploaded that particular file instead.
>
> Jeff
>
> On Wed, Jun 14, 2017 at 12:03 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Jeff,
> >
> > Can you please point me to one of the GRIB2 MRMS files you're
using?
> > Either send me a link to the file or just post it on our anonymous
ftp
> site
> > (http://www.dtcenter.org/met/users/support/met_help.php#ftp).  We
can
> run
> > it through the debugger and figure out what's going on.
> >
> > Thanks,
> > John
> >
> > On Wed, Jun 14, 2017 at 10:49 AM, Jeff Duda via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > Wed Jun 14 10:49:18 2017: Request 80859 was acted upon.
> > > Transaction: Ticket created by jeffduda319 at gmail.com
> > >        Queue: met_help
> > >      Subject: difficulty specifying field and level in MODE
> > >        Owner: Nobody
> > >   Requestors: jeffduda319 at gmail.com
> > >       Status: new
> > >  Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859
> >
> > >
> > >
> > > Working with version 5.2:
> > >
> > > I want to verify MRMS rotation tracks against model output
updraft
> > helicity
> > > (hourly max in the 2-5 km AGL layer). I know from wgrib2 (the
input
> file
> > > format is GRIB2) that the specific array record is 42, so I can
use R42
> > in
> > > the level specification of the config file. However, I work with
sets
> of
> > > files in which the UH array may not always have that record
number, so
> I
> > > would like to specify the level using some other template.
wgrib2 gives
> > the
> > > data as so:
> > >
> > > 42:48816704:00Z09may2016:MXUPHL Hourly Maximum of Updraft
Helicity
> over
> > > Layer 2km to 5 km AGL [m^2/s^2]:lvl1=(103,5000)
> > lvl2=(103,2000):5000-2000 m
> > > above ground:35-36 hour max fcst:
> > >
> > > So I tried Z5000-2000 and Z2000-5000 in the level setting of the
> control
> > > file, but MODE said
> > >
> > > WARNING: MetGrib2DataFile::data_plane() - No matching record
found for
> > > 'MXUPHL/Z5000-2000'
> > >
> > > for both attempts.
> > >
> > > What else can I try?
> > >
> > > Jeff Duda
> > > --
> > > Jeff Duda
> > > Post-doctoral research fellow
> > > University of Oklahoma School of Meteorology
> > >
> > >
> >
> >
>
>
> --
> Jeff Duda
> Post-doctoral research fellow
> University of Oklahoma School of Meteorology
>
>

------------------------------------------------
Subject: difficulty specifying field and level in MODE
From: Jeff Duda
Time: Wed Jun 14 16:02:11 2017

Thanks, John. Problem solved!

I need to lump in a separate issue now.

The output from MODE describes the problem well enough: ERROR  :
MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
found in bad slot

Here's the entry in the config file:
      name  = "forecast_probability";
      level = "(0,0,*,*)";

And the ncdump -h output from the forecast file:
netcdf fcst_neighborhood_precip_20170501f01 {
dimensions:
        latitude = 1120 ;
        longitude = 1620 ;
        threshold = 5 ;
        spatial_scale = 5 ;
variables:
        float latitude(latitude, longitude) ;
        float longitude(latitude, longitude) ;
        float forecast_probability(spatial_scale, threshold, latitude,
longitude) ;
                forecast_probability:ensemble = "MAP" ;

So the two spatial dimensions are indeed the third and fourth. So why
is
MODE complaining with this level entry in the config file?

Jeff

Auxiliary information:
DEBUG 1: Forecast File:
/condo/map/jdduda/HWT2017/neighborhood_fcsts/precip/
fcst_neighborhood_precip_20170501f01.nc
DEBUG 1: Observation File:
/condo/map/jdduda/HWT2017/neighborhood_obs/precip/
obs_neighborhood_precip_2017050101.nc
obs_neighborhood_precip_2017050101.nc has the exact same
dimensionality as
fcst_neighborhood_precip_20170501f01.nc, except the array in question
is
named observed_probability instead of forecast_probability

On Wed, Jun 14, 2017 at 2:40 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:

> Hi Jeff,
>
> Thanks for sending your sample file.  I grabbed it and was able to
get the
> plot_data_plane utility to create the attached plot of record number
42:
>
> met-6.0/bin/plot_data_plane \
>    CA_00Z_free_upp_d01_36_NSSL.grib2 plot.ps \
>    'name="MXUPHL"; level="L2000-5000";' -v 3 -plot_range 0 70
>
> I used the "-plot_range" option because the actual data values go
from
> -1000 to about 70.
>
> I used "L2000-5000".  The "L" tells MET to match a generic level
type...
> meaning don't worry about whether it's a pressure level or height...
just
> make sure the level values match what's in the data.
>
> You should be able to use the same settings in the MODE config file.
>
> Thanks,
> John
>
>
>
> On Wed, Jun 14, 2017 at 11:16 AM, Jeff Duda via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> >
> > John,
> > I totally waffled on explaining the data source.  While it's true
I am
> > comparing my forecast to MRMS RotationTrack data, I am not having
trouble
> > with the MRMS file. Instead, the issue is with the forecast file
output
> > from the UPP. So I uploaded that particular file instead.
> >
> > Jeff
> >
> > On Wed, Jun 14, 2017 at 12:03 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Jeff,
> > >
> > > Can you please point me to one of the GRIB2 MRMS files you're
using?
> > > Either send me a link to the file or just post it on our
anonymous ftp
> > site
> > > (http://www.dtcenter.org/met/users/support/met_help.php#ftp).
We can
> > run
> > > it through the debugger and figure out what's going on.
> > >
> > > Thanks,
> > > John
> > >
> > > On Wed, Jun 14, 2017 at 10:49 AM, Jeff Duda via RT
<met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > Wed Jun 14 10:49:18 2017: Request 80859 was acted upon.
> > > > Transaction: Ticket created by jeffduda319 at gmail.com
> > > >        Queue: met_help
> > > >      Subject: difficulty specifying field and level in MODE
> > > >        Owner: Nobody
> > > >   Requestors: jeffduda319 at gmail.com
> > > >       Status: new
> > > >  Ticket <URL: https://rt.rap.ucar.edu/rt/
> Ticket/Display.html?id=80859
> > >
> > > >
> > > >
> > > > Working with version 5.2:
> > > >
> > > > I want to verify MRMS rotation tracks against model output
updraft
> > > helicity
> > > > (hourly max in the 2-5 km AGL layer). I know from wgrib2 (the
input
> > file
> > > > format is GRIB2) that the specific array record is 42, so I
can use
> R42
> > > in
> > > > the level specification of the config file. However, I work
with sets
> > of
> > > > files in which the UH array may not always have that record
number,
> so
> > I
> > > > would like to specify the level using some other template.
wgrib2
> gives
> > > the
> > > > data as so:
> > > >
> > > > 42:48816704:00Z09may2016:MXUPHL Hourly Maximum of Updraft
Helicity
> > over
> > > > Layer 2km to 5 km AGL [m^2/s^2]:lvl1=(103,5000)
> > > lvl2=(103,2000):5000-2000 m
> > > > above ground:35-36 hour max fcst:
> > > >
> > > > So I tried Z5000-2000 and Z2000-5000 in the level setting of
the
> > control
> > > > file, but MODE said
> > > >
> > > > WARNING: MetGrib2DataFile::data_plane() - No matching record
found
> for
> > > > 'MXUPHL/Z5000-2000'
> > > >
> > > > for both attempts.
> > > >
> > > > What else can I try?
> > > >
> > > > Jeff Duda
> > > > --
> > > > Jeff Duda
> > > > Post-doctoral research fellow
> > > > University of Oklahoma School of Meteorology
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Jeff Duda
> > Post-doctoral research fellow
> > University of Oklahoma School of Meteorology
> >
> >
>
>

--
Jeff Duda
Post-doctoral research fellow
University of Oklahoma School of Meteorology

------------------------------------------------
Subject: difficulty specifying field and level in MODE
From: John Halley Gotway
Time: Thu Jun 15 10:08:30 2017

Jeff,

I see you're having trouble getting MET to read your NetCDF file.  The
clue
I see in the output you sent is on this line:

MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star found
in bad slot

This is coming from the "MetNcFile" class which is used for reading
the
intermediate NetCDF output from the MET tools (i.e. gen_vx_mask,
pcp_combine, and so on).  MET supports a few flavors of NetCDF, and if
it
can't determine that it's one of the other two, it assumes it's the
internal MET format.  Unfortunately, that format is limited and really
only
supports variables of 2 dimensions.

Instead, let's tell MET to interpret your data as CF-compliant using
the
"file_type" option.  Please try running the following plot_data_plane
command to see if you get any better results:

met-6.0/bin/plot_data_plane \
/condo/map/jdduda/HWT2017/neighborhood_fcsts/precip/
fcst_neighborhood_precip_20170501f01.nc \
plot.ps \
'name="forecast_probability"; level="(0,0,*,*)";
file_type=NETCDF_NCCF;'

I see that you have lat/lon variables defined.  If this is for an
evenly
spaced lat/lon grid, that should work.  But if the data lives on some
other
projection, like lambert conformal, mercator, or polar stereographic,
you'll need to define the projection info in the file.  I do see that
there's no timing information present in your file... so you'll need
to add
that if you want the timestamps to be accurate in the output of MET.

Please let me know how it goes, and feel free to post the problematic
file
to our anonymous ftp site.

Thanks,
John

On Wed, Jun 14, 2017 at 4:02 PM, Jeff Duda via RT <met_help at ucar.edu>
wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
>
> Thanks, John. Problem solved!
>
> I need to lump in a separate issue now.
>
> The output from MODE describes the problem well enough: ERROR  :
> MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
> found in bad slot
>
> Here's the entry in the config file:
>       name  = "forecast_probability";
>       level = "(0,0,*,*)";
>
> And the ncdump -h output from the forecast file:
> netcdf fcst_neighborhood_precip_20170501f01 {
> dimensions:
>         latitude = 1120 ;
>         longitude = 1620 ;
>         threshold = 5 ;
>         spatial_scale = 5 ;
> variables:
>         float latitude(latitude, longitude) ;
>         float longitude(latitude, longitude) ;
>         float forecast_probability(spatial_scale, threshold,
latitude,
> longitude) ;
>                 forecast_probability:ensemble = "MAP" ;
>
>
> So the two spatial dimensions are indeed the third and fourth. So
why is
> MODE complaining with this level entry in the config file?
>
> Jeff
>
> Auxiliary information:
> DEBUG 1: Forecast File: /condo/map/jdduda/HWT2017/
> neighborhood_fcsts/precip/
> fcst_neighborhood_precip_20170501f01.nc
> DEBUG 1: Observation File:
> /condo/map/jdduda/HWT2017/neighborhood_obs/precip/
> obs_neighborhood_precip_2017050101.nc
> obs_neighborhood_precip_2017050101.nc has the exact same
dimensionality as
> fcst_neighborhood_precip_20170501f01.nc, except the array in
question is
> named observed_probability instead of forecast_probability
>
> On Wed, Jun 14, 2017 at 2:40 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Hi Jeff,
> >
> > Thanks for sending your sample file.  I grabbed it and was able to
get
> the
> > plot_data_plane utility to create the attached plot of record
number 42:
> >
> > met-6.0/bin/plot_data_plane \
> >    CA_00Z_free_upp_d01_36_NSSL.grib2 plot.ps \
> >    'name="MXUPHL"; level="L2000-5000";' -v 3 -plot_range 0 70
> >
> > I used the "-plot_range" option because the actual data values go
from
> > -1000 to about 70.
> >
> > I used "L2000-5000".  The "L" tells MET to match a generic level
type...
> > meaning don't worry about whether it's a pressure level or
height... just
> > make sure the level values match what's in the data.
> >
> > You should be able to use the same settings in the MODE config
file.
> >
> > Thanks,
> > John
> >
> >
> >
> > On Wed, Jun 14, 2017 at 11:16 AM, Jeff Duda via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> > >
> > > John,
> > > I totally waffled on explaining the data source.  While it's
true I am
> > > comparing my forecast to MRMS RotationTrack data, I am not
having
> trouble
> > > with the MRMS file. Instead, the issue is with the forecast file
output
> > > from the UPP. So I uploaded that particular file instead.
> > >
> > > Jeff
> > >
> > > On Wed, Jun 14, 2017 at 12:03 PM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > > Jeff,
> > > >
> > > > Can you please point me to one of the GRIB2 MRMS files you're
using?
> > > > Either send me a link to the file or just post it on our
anonymous
> ftp
> > > site
> > > > (http://www.dtcenter.org/met/users/support/met_help.php#ftp).
We
> can
> > > run
> > > > it through the debugger and figure out what's going on.
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > > On Wed, Jun 14, 2017 at 10:49 AM, Jeff Duda via RT <
> met_help at ucar.edu>
> > > > wrote:
> > > >
> > > > >
> > > > > Wed Jun 14 10:49:18 2017: Request 80859 was acted upon.
> > > > > Transaction: Ticket created by jeffduda319 at gmail.com
> > > > >        Queue: met_help
> > > > >      Subject: difficulty specifying field and level in MODE
> > > > >        Owner: Nobody
> > > > >   Requestors: jeffduda319 at gmail.com
> > > > >       Status: new
> > > > >  Ticket <URL: https://rt.rap.ucar.edu/rt/
> > Ticket/Display.html?id=80859
> > > >
> > > > >
> > > > >
> > > > > Working with version 5.2:
> > > > >
> > > > > I want to verify MRMS rotation tracks against model output
updraft
> > > > helicity
> > > > > (hourly max in the 2-5 km AGL layer). I know from wgrib2
(the input
> > > file
> > > > > format is GRIB2) that the specific array record is 42, so I
can use
> > R42
> > > > in
> > > > > the level specification of the config file. However, I work
with
> sets
> > > of
> > > > > files in which the UH array may not always have that record
number,
> > so
> > > I
> > > > > would like to specify the level using some other template.
wgrib2
> > gives
> > > > the
> > > > > data as so:
> > > > >
> > > > > 42:48816704:00Z09may2016:MXUPHL Hourly Maximum of Updraft
Helicity
> > > over
> > > > > Layer 2km to 5 km AGL [m^2/s^2]:lvl1=(103,5000)
> > > > lvl2=(103,2000):5000-2000 m
> > > > > above ground:35-36 hour max fcst:
> > > > >
> > > > > So I tried Z5000-2000 and Z2000-5000 in the level setting of
the
> > > control
> > > > > file, but MODE said
> > > > >
> > > > > WARNING: MetGrib2DataFile::data_plane() - No matching record
found
> > for
> > > > > 'MXUPHL/Z5000-2000'
> > > > >
> > > > > for both attempts.
> > > > >
> > > > > What else can I try?
> > > > >
> > > > > Jeff Duda
> > > > > --
> > > > > Jeff Duda
> > > > > Post-doctoral research fellow
> > > > > University of Oklahoma School of Meteorology
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Jeff Duda
> > > Post-doctoral research fellow
> > > University of Oklahoma School of Meteorology
> > >
> > >
> >
> >
>
>
> --
> Jeff Duda
> Post-doctoral research fellow
> University of Oklahoma School of Meteorology
>
>

------------------------------------------------
Subject: difficulty specifying field and level in MODE
From: Jeff Duda
Time: Thu Jun 15 10:35:14 2017

Yeah...I guess projection information is the problem (indeed the grid
is
projected):

[jdduda at schooner1 MODE]$ /home/jdduda/tool/met/bin/plot_data_plane
/condo/map/jdduda/HWT2017/neighborhood_fcsts/precip/
fcst_neighborhood_precip_20170501f01.nc ....
DEBUG 1: Opening data file:
/condo/map/jdduda/HWT2017/neighborhood_fcsts/precip/
WARNING:
WARNING: NcCfFile::open() -> could not determine the valid time, using
0.
WARNING:
ERROR  :
ERROR  : NcCfFile::read_netcdf_grid() -> Couldn't figure out
projection
from inf
ERROR  :

This is the attributes section of the ncdump -h of that file, which I
uploaded to the ftp site, btw:
// global attributes:
                :Thresholds = 0.254f, 2.54f, 6.35f, 12.7f, 25.4f ;
                :Scales = 10.f, 25.f, 50.f, 80.f, 100.f ;
                :MET_version = "V5.2" ;
                :MET_tool = "pcp_combine" ;
                :Note\ about\ above = "Did not actually use
pcp_combine to
generate this file" ;
                :Projection = "Lambert Conformal" ;
                :scale_lat_1 = "38.5" ;
                :scale_lat_2 = "38.5" ;
                :lat_pin = "20.974351" ;
                :lon_pin = "-120.105241" ;
                :x_pin = "0.0" ;
                :y_pin = "0.0" ;
                :lon_orient = "-97.5" ;
                :d_km = "3.0" ;
                :r_km = "6371.20" ;
                :nx = "1620" ;
                :ny = "1120 grid points" ;

This is what I used for other files that I run using MODE and those
seem to
work, so is the problem simply that I have more than two dimensions in
the
file?

Jeff

On Thu, Jun 15, 2017 at 11:08 AM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:

> Jeff,
>
> I see you're having trouble getting MET to read your NetCDF file.
The clue
> I see in the output you sent is on this line:
>
> MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
> found
> in bad slot
>
> This is coming from the "MetNcFile" class which is used for reading
the
> intermediate NetCDF output from the MET tools (i.e. gen_vx_mask,
> pcp_combine, and so on).  MET supports a few flavors of NetCDF, and
if it
> can't determine that it's one of the other two, it assumes it's the
> internal MET format.  Unfortunately, that format is limited and
really only
> supports variables of 2 dimensions.
>
> Instead, let's tell MET to interpret your data as CF-compliant using
the
> "file_type" option.  Please try running the following
plot_data_plane
> command to see if you get any better results:
>
> met-6.0/bin/plot_data_plane \
> /condo/map/jdduda/HWT2017/neighborhood_fcsts/precip/
> fcst_neighborhood_precip_20170501f01.nc \
> plot.ps \
> 'name="forecast_probability"; level="(0,0,*,*)";
file_type=NETCDF_NCCF;'
>
> I see that you have lat/lon variables defined.  If this is for an
evenly
> spaced lat/lon grid, that should work.  But if the data lives on
some other
> projection, like lambert conformal, mercator, or polar
stereographic,
> you'll need to define the projection info in the file.  I do see
that
> there's no timing information present in your file... so you'll need
to add
> that if you want the timestamps to be accurate in the output of MET.
>
> Please let me know how it goes, and feel free to post the
problematic file
> to our anonymous ftp site.
>
> Thanks,
> John
>
> On Wed, Jun 14, 2017 at 4:02 PM, Jeff Duda via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> >
> > Thanks, John. Problem solved!
> >
> > I need to lump in a separate issue now.
> >
> > The output from MODE describes the problem well enough: ERROR  :
> > MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
> > found in bad slot
> >
> > Here's the entry in the config file:
> >       name  = "forecast_probability";
> >       level = "(0,0,*,*)";
> >
> > And the ncdump -h output from the forecast file:
> > netcdf fcst_neighborhood_precip_20170501f01 {
> > dimensions:
> >         latitude = 1120 ;
> >         longitude = 1620 ;
> >         threshold = 5 ;
> >         spatial_scale = 5 ;
> > variables:
> >         float latitude(latitude, longitude) ;
> >         float longitude(latitude, longitude) ;
> >         float forecast_probability(spatial_scale, threshold,
latitude,
> > longitude) ;
> >                 forecast_probability:ensemble = "MAP" ;
> >
> >
> > So the two spatial dimensions are indeed the third and fourth. So
why is
> > MODE complaining with this level entry in the config file?
> >
> > Jeff
> >
> > Auxiliary information:
> > DEBUG 1: Forecast File: /condo/map/jdduda/HWT2017/
> > neighborhood_fcsts/precip/
> > fcst_neighborhood_precip_20170501f01.nc
> > DEBUG 1: Observation File:
> > /condo/map/jdduda/HWT2017/neighborhood_obs/precip/
> > obs_neighborhood_precip_2017050101.nc
> > obs_neighborhood_precip_2017050101.nc has the exact same
dimensionality
> as
> > fcst_neighborhood_precip_20170501f01.nc, except the array in
question is
> > named observed_probability instead of forecast_probability
> >
> > On Wed, Jun 14, 2017 at 2:40 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Hi Jeff,
> > >
> > > Thanks for sending your sample file.  I grabbed it and was able
to get
> > the
> > > plot_data_plane utility to create the attached plot of record
number
> 42:
> > >
> > > met-6.0/bin/plot_data_plane \
> > >    CA_00Z_free_upp_d01_36_NSSL.grib2 plot.ps \
> > >    'name="MXUPHL"; level="L2000-5000";' -v 3 -plot_range 0 70
> > >
> > > I used the "-plot_range" option because the actual data values
go from
> > > -1000 to about 70.
> > >
> > > I used "L2000-5000".  The "L" tells MET to match a generic level
> type...
> > > meaning don't worry about whether it's a pressure level or
height...
> just
> > > make sure the level values match what's in the data.
> > >
> > > You should be able to use the same settings in the MODE config
file.
> > >
> > > Thanks,
> > > John
> > >
> > >
> > >
> > > On Wed, Jun 14, 2017 at 11:16 AM, Jeff Duda via RT
<met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859
>
> > > >
> > > > John,
> > > > I totally waffled on explaining the data source.  While it's
true I
> am
> > > > comparing my forecast to MRMS RotationTrack data, I am not
having
> > trouble
> > > > with the MRMS file. Instead, the issue is with the forecast
file
> output
> > > > from the UPP. So I uploaded that particular file instead.
> > > >
> > > > Jeff
> > > >
> > > > On Wed, Jun 14, 2017 at 12:03 PM, John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > > Jeff,
> > > > >
> > > > > Can you please point me to one of the GRIB2 MRMS files
you're
> using?
> > > > > Either send me a link to the file or just post it on our
anonymous
> > ftp
> > > > site
> > > > >
(http://www.dtcenter.org/met/users/support/met_help.php#ftp).  We
> > can
> > > > run
> > > > > it through the debugger and figure out what's going on.
> > > > >
> > > > > Thanks,
> > > > > John
> > > > >
> > > > > On Wed, Jun 14, 2017 at 10:49 AM, Jeff Duda via RT <
> > met_help at ucar.edu>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > Wed Jun 14 10:49:18 2017: Request 80859 was acted upon.
> > > > > > Transaction: Ticket created by jeffduda319 at gmail.com
> > > > > >        Queue: met_help
> > > > > >      Subject: difficulty specifying field and level in
MODE
> > > > > >        Owner: Nobody
> > > > > >   Requestors: jeffduda319 at gmail.com
> > > > > >       Status: new
> > > > > >  Ticket <URL: https://rt.rap.ucar.edu/rt/
> > > Ticket/Display.html?id=80859
> > > > >
> > > > > >
> > > > > >
> > > > > > Working with version 5.2:
> > > > > >
> > > > > > I want to verify MRMS rotation tracks against model output
> updraft
> > > > > helicity
> > > > > > (hourly max in the 2-5 km AGL layer). I know from wgrib2
(the
> input
> > > > file
> > > > > > format is GRIB2) that the specific array record is 42, so
I can
> use
> > > R42
> > > > > in
> > > > > > the level specification of the config file. However, I
work with
> > sets
> > > > of
> > > > > > files in which the UH array may not always have that
record
> number,
> > > so
> > > > I
> > > > > > would like to specify the level using some other template.
wgrib2
> > > gives
> > > > > the
> > > > > > data as so:
> > > > > >
> > > > > > 42:48816704:00Z09may2016:MXUPHL Hourly Maximum of Updraft
> Helicity
> > > > over
> > > > > > Layer 2km to 5 km AGL [m^2/s^2]:lvl1=(103,5000)
> > > > > lvl2=(103,2000):5000-2000 m
> > > > > > above ground:35-36 hour max fcst:
> > > > > >
> > > > > > So I tried Z5000-2000 and Z2000-5000 in the level setting
of the
> > > > control
> > > > > > file, but MODE said
> > > > > >
> > > > > > WARNING: MetGrib2DataFile::data_plane() - No matching
record
> found
> > > for
> > > > > > 'MXUPHL/Z5000-2000'
> > > > > >
> > > > > > for both attempts.
> > > > > >
> > > > > > What else can I try?
> > > > > >
> > > > > > Jeff Duda
> > > > > > --
> > > > > > Jeff Duda
> > > > > > Post-doctoral research fellow
> > > > > > University of Oklahoma School of Meteorology
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Jeff Duda
> > > > Post-doctoral research fellow
> > > > University of Oklahoma School of Meteorology
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Jeff Duda
> > Post-doctoral research fellow
> > University of Oklahoma School of Meteorology
> >
> >
>
>

--
Jeff Duda
Post-doctoral research fellow
University of Oklahoma School of Meteorology

------------------------------------------------
Subject: difficulty specifying field and level in MODE
From: John Halley Gotway
Time: Thu Jun 15 10:58:54 2017

Jeff,

I'm not in my office right now.  Please post a sample data file to our
anonymous ftp site.  When I get a chance this afternoon I'll grab it
and
take a look.  Hopefully after looking at the details, I can make a
good
suggestion on how you might proceed.

Thanks
John

On Thu, Jun 15, 2017 at 10:43 AM Jeff Duda via RT <met_help at ucar.edu>
wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
>
> Yeah...I guess projection information is the problem (indeed the
grid is
> projected):
>
> [jdduda at schooner1 MODE]$ /home/jdduda/tool/met/bin/plot_data_plane
> /condo/map/jdduda/HWT2017/neighborhood_fcsts/precip/
> fcst_neighborhood_precip_20170501f01.nc ....
> DEBUG 1: Opening data file:
> /condo/map/jdduda/HWT2017/neighborhood_fcsts/precip/
> WARNING:
> WARNING: NcCfFile::open() -> could not determine the valid time,
using 0.
> WARNING:
> ERROR  :
> ERROR  : NcCfFile::read_netcdf_grid() -> Couldn't figure out
projection
> from inf
> ERROR  :
>
> This is the attributes section of the ncdump -h of that file, which
I
> uploaded to the ftp site, btw:
> // global attributes:
>                 :Thresholds = 0.254f, 2.54f, 6.35f, 12.7f, 25.4f ;
>                 :Scales = 10.f, 25.f, 50.f, 80.f, 100.f ;
>                 :MET_version = "V5.2" ;
>                 :MET_tool = "pcp_combine" ;
>                 :Note\ about\ above = "Did not actually use
pcp_combine to
> generate this file" ;
>                 :Projection = "Lambert Conformal" ;
>                 :scale_lat_1 = "38.5" ;
>                 :scale_lat_2 = "38.5" ;
>                 :lat_pin = "20.974351" ;
>                 :lon_pin = "-120.105241" ;
>                 :x_pin = "0.0" ;
>                 :y_pin = "0.0" ;
>                 :lon_orient = "-97.5" ;
>                 :d_km = "3.0" ;
>                 :r_km = "6371.20" ;
>                 :nx = "1620" ;
>                 :ny = "1120 grid points" ;
>
> This is what I used for other files that I run using MODE and those
seem to
> work, so is the problem simply that I have more than two dimensions
in the
> file?
>
> Jeff
>
> On Thu, Jun 15, 2017 at 11:08 AM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Jeff,
> >
> > I see you're having trouble getting MET to read your NetCDF file.
The
> clue
> > I see in the output you sent is on this line:
> >
> > MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
> > found
> > in bad slot
> >
> > This is coming from the "MetNcFile" class which is used for
reading the
> > intermediate NetCDF output from the MET tools (i.e. gen_vx_mask,
> > pcp_combine, and so on).  MET supports a few flavors of NetCDF,
and if it
> > can't determine that it's one of the other two, it assumes it's
the
> > internal MET format.  Unfortunately, that format is limited and
really
> only
> > supports variables of 2 dimensions.
> >
> > Instead, let's tell MET to interpret your data as CF-compliant
using the
> > "file_type" option.  Please try running the following
plot_data_plane
> > command to see if you get any better results:
> >
> > met-6.0/bin/plot_data_plane \
> > /condo/map/jdduda/HWT2017/neighborhood_fcsts/precip/
> > fcst_neighborhood_precip_20170501f01.nc \
> > plot.ps \
> > 'name="forecast_probability"; level="(0,0,*,*)";
file_type=NETCDF_NCCF;'
> >
> > I see that you have lat/lon variables defined.  If this is for an
evenly
> > spaced lat/lon grid, that should work.  But if the data lives on
some
> other
> > projection, like lambert conformal, mercator, or polar
stereographic,
> > you'll need to define the projection info in the file.  I do see
that
> > there's no timing information present in your file... so you'll
need to
> add
> > that if you want the timestamps to be accurate in the output of
MET.
> >
> > Please let me know how it goes, and feel free to post the
problematic
> file
> > to our anonymous ftp site.
> >
> > Thanks,
> > John
> >
> > On Wed, Jun 14, 2017 at 4:02 PM, Jeff Duda via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> > >
> > > Thanks, John. Problem solved!
> > >
> > > I need to lump in a separate issue now.
> > >
> > > The output from MODE describes the problem well enough: ERROR  :
> > > MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const
->  star
> > > found in bad slot
> > >
> > > Here's the entry in the config file:
> > >       name  = "forecast_probability";
> > >       level = "(0,0,*,*)";
> > >
> > > And the ncdump -h output from the forecast file:
> > > netcdf fcst_neighborhood_precip_20170501f01 {
> > > dimensions:
> > >         latitude = 1120 ;
> > >         longitude = 1620 ;
> > >         threshold = 5 ;
> > >         spatial_scale = 5 ;
> > > variables:
> > >         float latitude(latitude, longitude) ;
> > >         float longitude(latitude, longitude) ;
> > >         float forecast_probability(spatial_scale, threshold,
latitude,
> > > longitude) ;
> > >                 forecast_probability:ensemble = "MAP" ;
> > >
> > >
> > > So the two spatial dimensions are indeed the third and fourth.
So why
> is
> > > MODE complaining with this level entry in the config file?
> > >
> > > Jeff
> > >
> > > Auxiliary information:
> > > DEBUG 1: Forecast File: /condo/map/jdduda/HWT2017/
> > > neighborhood_fcsts/precip/
> > > fcst_neighborhood_precip_20170501f01.nc
> > > DEBUG 1: Observation File:
> > > /condo/map/jdduda/HWT2017/neighborhood_obs/precip/
> > > obs_neighborhood_precip_2017050101.nc
> > > obs_neighborhood_precip_2017050101.nc has the exact same
> dimensionality
> > as
> > > fcst_neighborhood_precip_20170501f01.nc, except the array in
question
> is
> > > named observed_probability instead of forecast_probability
> > >
> > > On Wed, Jun 14, 2017 at 2:40 PM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > > Hi Jeff,
> > > >
> > > > Thanks for sending your sample file.  I grabbed it and was
able to
> get
> > > the
> > > > plot_data_plane utility to create the attached plot of record
number
> > 42:
> > > >
> > > > met-6.0/bin/plot_data_plane \
> > > >    CA_00Z_free_upp_d01_36_NSSL.grib2 plot.ps \
> > > >    'name="MXUPHL"; level="L2000-5000";' -v 3 -plot_range 0 70
> > > >
> > > > I used the "-plot_range" option because the actual data values
go
> from
> > > > -1000 to about 70.
> > > >
> > > > I used "L2000-5000".  The "L" tells MET to match a generic
level
> > type...
> > > > meaning don't worry about whether it's a pressure level or
height...
> > just
> > > > make sure the level values match what's in the data.
> > > >
> > > > You should be able to use the same settings in the MODE config
file.
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > >
> > > >
> > > > On Wed, Jun 14, 2017 at 11:16 AM, Jeff Duda via RT <
> met_help at ucar.edu>
> > > > wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> > > > >
> > > > > John,
> > > > > I totally waffled on explaining the data source.  While it's
true I
> > am
> > > > > comparing my forecast to MRMS RotationTrack data, I am not
having
> > > trouble
> > > > > with the MRMS file. Instead, the issue is with the forecast
file
> > output
> > > > > from the UPP. So I uploaded that particular file instead.
> > > > >
> > > > > Jeff
> > > > >
> > > > > On Wed, Jun 14, 2017 at 12:03 PM, John Halley Gotway via RT
<
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > > > Jeff,
> > > > > >
> > > > > > Can you please point me to one of the GRIB2 MRMS files
you're
> > using?
> > > > > > Either send me a link to the file or just post it on our
> anonymous
> > > ftp
> > > > > site
> > > > > >
(http://www.dtcenter.org/met/users/support/met_help.php#ftp).
> We
> > > can
> > > > > run
> > > > > > it through the debugger and figure out what's going on.
> > > > > >
> > > > > > Thanks,
> > > > > > John
> > > > > >
> > > > > > On Wed, Jun 14, 2017 at 10:49 AM, Jeff Duda via RT <
> > > met_help at ucar.edu>
> > > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > Wed Jun 14 10:49:18 2017: Request 80859 was acted upon.
> > > > > > > Transaction: Ticket created by jeffduda319 at gmail.com
> > > > > > >        Queue: met_help
> > > > > > >      Subject: difficulty specifying field and level in
MODE
> > > > > > >        Owner: Nobody
> > > > > > >   Requestors: jeffduda319 at gmail.com
> > > > > > >       Status: new
> > > > > > >  Ticket <URL: https://rt.rap.ucar.edu/rt/
> > > > Ticket/Display.html?id=80859
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Working with version 5.2:
> > > > > > >
> > > > > > > I want to verify MRMS rotation tracks against model
output
> > updraft
> > > > > > helicity
> > > > > > > (hourly max in the 2-5 km AGL layer). I know from wgrib2
(the
> > input
> > > > > file
> > > > > > > format is GRIB2) that the specific array record is 42,
so I can
> > use
> > > > R42
> > > > > > in
> > > > > > > the level specification of the config file. However, I
work
> with
> > > sets
> > > > > of
> > > > > > > files in which the UH array may not always have that
record
> > number,
> > > > so
> > > > > I
> > > > > > > would like to specify the level using some other
template.
> wgrib2
> > > > gives
> > > > > > the
> > > > > > > data as so:
> > > > > > >
> > > > > > > 42:48816704:00Z09may2016:MXUPHL Hourly Maximum of
Updraft
> > Helicity
> > > > > over
> > > > > > > Layer 2km to 5 km AGL [m^2/s^2]:lvl1=(103,5000)
> > > > > > lvl2=(103,2000):5000-2000 m
> > > > > > > above ground:35-36 hour max fcst:
> > > > > > >
> > > > > > > So I tried Z5000-2000 and Z2000-5000 in the level
setting of
> the
> > > > > control
> > > > > > > file, but MODE said
> > > > > > >
> > > > > > > WARNING: MetGrib2DataFile::data_plane() - No matching
record
> > found
> > > > for
> > > > > > > 'MXUPHL/Z5000-2000'
> > > > > > >
> > > > > > > for both attempts.
> > > > > > >
> > > > > > > What else can I try?
> > > > > > >
> > > > > > > Jeff Duda
> > > > > > > --
> > > > > > > Jeff Duda
> > > > > > > Post-doctoral research fellow
> > > > > > > University of Oklahoma School of Meteorology
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Jeff Duda
> > > > > Post-doctoral research fellow
> > > > > University of Oklahoma School of Meteorology
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Jeff Duda
> > > Post-doctoral research fellow
> > > University of Oklahoma School of Meteorology
> > >
> > >
> >
> >
>
>
> --
> Jeff Duda
> Post-doctoral research fellow
> University of Oklahoma School of Meteorology
>
>

------------------------------------------------
Subject: difficulty specifying field and level in MODE
From: Jeff Duda
Time: Thu Jun 15 11:10:37 2017

John,
The file is already uploaded. I will await your response.

Jeff

On Thu, Jun 15, 2017 at 11:58 AM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:

> Jeff,
>
> I'm not in my office right now.  Please post a sample data file to
our
> anonymous ftp site.  When I get a chance this afternoon I'll grab it
and
> take a look.  Hopefully after looking at the details, I can make a
good
> suggestion on how you might proceed.
>
> Thanks
> John
>
> On Thu, Jun 15, 2017 at 10:43 AM Jeff Duda via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> >
> > Yeah...I guess projection information is the problem (indeed the
grid is
> > projected):
> >
> > [jdduda at schooner1 MODE]$ /home/jdduda/tool/met/bin/plot_data_plane
> > /condo/map/jdduda/HWT2017/neighborhood_fcsts/precip/
> > fcst_neighborhood_precip_20170501f01.nc ....
> > DEBUG 1: Opening data file:
> > /condo/map/jdduda/HWT2017/neighborhood_fcsts/precip/
> > WARNING:
> > WARNING: NcCfFile::open() -> could not determine the valid time,
using 0.
> > WARNING:
> > ERROR  :
> > ERROR  : NcCfFile::read_netcdf_grid() -> Couldn't figure out
projection
> > from inf
> > ERROR  :
> >
> > This is the attributes section of the ncdump -h of that file,
which I
> > uploaded to the ftp site, btw:
> > // global attributes:
> >                 :Thresholds = 0.254f, 2.54f, 6.35f, 12.7f, 25.4f ;
> >                 :Scales = 10.f, 25.f, 50.f, 80.f, 100.f ;
> >                 :MET_version = "V5.2" ;
> >                 :MET_tool = "pcp_combine" ;
> >                 :Note\ about\ above = "Did not actually use
pcp_combine
> to
> > generate this file" ;
> >                 :Projection = "Lambert Conformal" ;
> >                 :scale_lat_1 = "38.5" ;
> >                 :scale_lat_2 = "38.5" ;
> >                 :lat_pin = "20.974351" ;
> >                 :lon_pin = "-120.105241" ;
> >                 :x_pin = "0.0" ;
> >                 :y_pin = "0.0" ;
> >                 :lon_orient = "-97.5" ;
> >                 :d_km = "3.0" ;
> >                 :r_km = "6371.20" ;
> >                 :nx = "1620" ;
> >                 :ny = "1120 grid points" ;
> >
> > This is what I used for other files that I run using MODE and
those seem
> to
> > work, so is the problem simply that I have more than two
dimensions in
> the
> > file?
> >
> > Jeff
> >
> > On Thu, Jun 15, 2017 at 11:08 AM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Jeff,
> > >
> > > I see you're having trouble getting MET to read your NetCDF
file.  The
> > clue
> > > I see in the output you sent is on this line:
> > >
> > > MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const
->  star
> > > found
> > > in bad slot
> > >
> > > This is coming from the "MetNcFile" class which is used for
reading the
> > > intermediate NetCDF output from the MET tools (i.e. gen_vx_mask,
> > > pcp_combine, and so on).  MET supports a few flavors of NetCDF,
and if
> it
> > > can't determine that it's one of the other two, it assumes it's
the
> > > internal MET format.  Unfortunately, that format is limited and
really
> > only
> > > supports variables of 2 dimensions.
> > >
> > > Instead, let's tell MET to interpret your data as CF-compliant
using
> the
> > > "file_type" option.  Please try running the following
plot_data_plane
> > > command to see if you get any better results:
> > >
> > > met-6.0/bin/plot_data_plane \
> > > /condo/map/jdduda/HWT2017/neighborhood_fcsts/precip/
> > > fcst_neighborhood_precip_20170501f01.nc \
> > > plot.ps \
> > > 'name="forecast_probability"; level="(0,0,*,*)";
> file_type=NETCDF_NCCF;'
> > >
> > > I see that you have lat/lon variables defined.  If this is for
an
> evenly
> > > spaced lat/lon grid, that should work.  But if the data lives on
some
> > other
> > > projection, like lambert conformal, mercator, or polar
stereographic,
> > > you'll need to define the projection info in the file.  I do see
that
> > > there's no timing information present in your file... so you'll
need to
> > add
> > > that if you want the timestamps to be accurate in the output of
MET.
> > >
> > > Please let me know how it goes, and feel free to post the
problematic
> > file
> > > to our anonymous ftp site.
> > >
> > > Thanks,
> > > John
> > >
> > > On Wed, Jun 14, 2017 at 4:02 PM, Jeff Duda via RT
<met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859
>
> > > >
> > > > Thanks, John. Problem solved!
> > > >
> > > > I need to lump in a separate issue now.
> > > >
> > > > The output from MODE describes the problem well enough: ERROR
:
> > > > MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const
->
> star
> > > > found in bad slot
> > > >
> > > > Here's the entry in the config file:
> > > >       name  = "forecast_probability";
> > > >       level = "(0,0,*,*)";
> > > >
> > > > And the ncdump -h output from the forecast file:
> > > > netcdf fcst_neighborhood_precip_20170501f01 {
> > > > dimensions:
> > > >         latitude = 1120 ;
> > > >         longitude = 1620 ;
> > > >         threshold = 5 ;
> > > >         spatial_scale = 5 ;
> > > > variables:
> > > >         float latitude(latitude, longitude) ;
> > > >         float longitude(latitude, longitude) ;
> > > >         float forecast_probability(spatial_scale, threshold,
> latitude,
> > > > longitude) ;
> > > >                 forecast_probability:ensemble = "MAP" ;
> > > >
> > > >
> > > > So the two spatial dimensions are indeed the third and fourth.
So why
> > is
> > > > MODE complaining with this level entry in the config file?
> > > >
> > > > Jeff
> > > >
> > > > Auxiliary information:
> > > > DEBUG 1: Forecast File: /condo/map/jdduda/HWT2017/
> > > > neighborhood_fcsts/precip/
> > > > fcst_neighborhood_precip_20170501f01.nc
> > > > DEBUG 1: Observation File:
> > > > /condo/map/jdduda/HWT2017/neighborhood_obs/precip/
> > > > obs_neighborhood_precip_2017050101.nc
> > > > obs_neighborhood_precip_2017050101.nc has the exact same
> > dimensionality
> > > as
> > > > fcst_neighborhood_precip_20170501f01.nc, except the array in
> question
> > is
> > > > named observed_probability instead of forecast_probability
> > > >
> > > > On Wed, Jun 14, 2017 at 2:40 PM, John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > > Hi Jeff,
> > > > >
> > > > > Thanks for sending your sample file.  I grabbed it and was
able to
> > get
> > > > the
> > > > > plot_data_plane utility to create the attached plot of
record
> number
> > > 42:
> > > > >
> > > > > met-6.0/bin/plot_data_plane \
> > > > >    CA_00Z_free_upp_d01_36_NSSL.grib2 plot.ps \
> > > > >    'name="MXUPHL"; level="L2000-5000";' -v 3 -plot_range 0
70
> > > > >
> > > > > I used the "-plot_range" option because the actual data
values go
> > from
> > > > > -1000 to about 70.
> > > > >
> > > > > I used "L2000-5000".  The "L" tells MET to match a generic
level
> > > type...
> > > > > meaning don't worry about whether it's a pressure level or
> height...
> > > just
> > > > > make sure the level values match what's in the data.
> > > > >
> > > > > You should be able to use the same settings in the MODE
config
> file.
> > > > >
> > > > > Thanks,
> > > > > John
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Jun 14, 2017 at 11:16 AM, Jeff Duda via RT <
> > met_help at ucar.edu>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> > > > > >
> > > > > > John,
> > > > > > I totally waffled on explaining the data source.  While
it's
> true I
> > > am
> > > > > > comparing my forecast to MRMS RotationTrack data, I am not
having
> > > > trouble
> > > > > > with the MRMS file. Instead, the issue is with the
forecast file
> > > output
> > > > > > from the UPP. So I uploaded that particular file instead.
> > > > > >
> > > > > > Jeff
> > > > > >
> > > > > > On Wed, Jun 14, 2017 at 12:03 PM, John Halley Gotway via
RT <
> > > > > > met_help at ucar.edu> wrote:
> > > > > >
> > > > > > > Jeff,
> > > > > > >
> > > > > > > Can you please point me to one of the GRIB2 MRMS files
you're
> > > using?
> > > > > > > Either send me a link to the file or just post it on our
> > anonymous
> > > > ftp
> > > > > > site
> > > > > > >
(http://www.dtcenter.org/met/users/support/met_help.php#ftp).
> > We
> > > > can
> > > > > > run
> > > > > > > it through the debugger and figure out what's going on.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > John
> > > > > > >
> > > > > > > On Wed, Jun 14, 2017 at 10:49 AM, Jeff Duda via RT <
> > > > met_help at ucar.edu>
> > > > > > > wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > Wed Jun 14 10:49:18 2017: Request 80859 was acted
upon.
> > > > > > > > Transaction: Ticket created by jeffduda319 at gmail.com
> > > > > > > >        Queue: met_help
> > > > > > > >      Subject: difficulty specifying field and level in
MODE
> > > > > > > >        Owner: Nobody
> > > > > > > >   Requestors: jeffduda319 at gmail.com
> > > > > > > >       Status: new
> > > > > > > >  Ticket <URL: https://rt.rap.ucar.edu/rt/
> > > > > Ticket/Display.html?id=80859
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Working with version 5.2:
> > > > > > > >
> > > > > > > > I want to verify MRMS rotation tracks against model
output
> > > updraft
> > > > > > > helicity
> > > > > > > > (hourly max in the 2-5 km AGL layer). I know from
wgrib2 (the
> > > input
> > > > > > file
> > > > > > > > format is GRIB2) that the specific array record is 42,
so I
> can
> > > use
> > > > > R42
> > > > > > > in
> > > > > > > > the level specification of the config file. However, I
work
> > with
> > > > sets
> > > > > > of
> > > > > > > > files in which the UH array may not always have that
record
> > > number,
> > > > > so
> > > > > > I
> > > > > > > > would like to specify the level using some other
template.
> > wgrib2
> > > > > gives
> > > > > > > the
> > > > > > > > data as so:
> > > > > > > >
> > > > > > > > 42:48816704:00Z09may2016:MXUPHL Hourly Maximum of
Updraft
> > > Helicity
> > > > > > over
> > > > > > > > Layer 2km to 5 km AGL [m^2/s^2]:lvl1=(103,5000)
> > > > > > > lvl2=(103,2000):5000-2000 m
> > > > > > > > above ground:35-36 hour max fcst:
> > > > > > > >
> > > > > > > > So I tried Z5000-2000 and Z2000-5000 in the level
setting of
> > the
> > > > > > control
> > > > > > > > file, but MODE said
> > > > > > > >
> > > > > > > > WARNING: MetGrib2DataFile::data_plane() - No matching
record
> > > found
> > > > > for
> > > > > > > > 'MXUPHL/Z5000-2000'
> > > > > > > >
> > > > > > > > for both attempts.
> > > > > > > >
> > > > > > > > What else can I try?
> > > > > > > >
> > > > > > > > Jeff Duda
> > > > > > > > --
> > > > > > > > Jeff Duda
> > > > > > > > Post-doctoral research fellow
> > > > > > > > University of Oklahoma School of Meteorology
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Jeff Duda
> > > > > > Post-doctoral research fellow
> > > > > > University of Oklahoma School of Meteorology
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Jeff Duda
> > > > Post-doctoral research fellow
> > > > University of Oklahoma School of Meteorology
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Jeff Duda
> > Post-doctoral research fellow
> > University of Oklahoma School of Meteorology
> >
> >
>
>

--
Jeff Duda
Post-doctoral research fellow
University of Oklahoma School of Meteorology

------------------------------------------------
Subject: difficulty specifying field and level in MODE
From: John Halley Gotway
Time: Thu Jun 15 14:30:37 2017

Jeff,

I ran your file through the debugger and think I may have found a
pesky
little bug in MET in the file named "met_file.cc".

In addition, one rather silly requirement is that the latitude and
longitude dimensions be named "lat" and "lon".  I used the ncrename
tool to
rename them:

ncrename -d latitude,lat -d longitude,lon \
   fcst_neighborhood_precip_20170501f01.nc \
   -o fcst_neighborhood_precip_20170501f01_mod.nc

Running plot_data_plane still results in the same error:
ERROR  : MetNcFile::data(NcVar *, const LongArray &, DataPlane &)
const ->
star found in bad slot

But when I change line 168 of
met-6.0/src/libcode/vx_data2d_nc_met/met_file.cc:

OLD:  for (j=0; j<Ndims; ++j)  {
NEW: for (j=0; j<gDimNames.n_elements(); ++j)  {

And then recompile MET.  And then it works:

met-6.0/bin/plot_data_plane \
fcst_neighborhood_precip_20170501f01_mod.nc \
plot.ps \
'name="forecast_probability"; level="(0,0,*,*)";'

Here's what I'd recommend:

(1) Switch from naming dimensions latitude and longitude to "lat" and
"lon".
(2) Try the bugfix I described above and then recompile.
(3) Make sure that plot_data_plane works now.
(4) Looking at this data using ncview, all of the probability values
appear
to be 0.  I'd suggest looking at the generation of this data file to
make
sure it's correct.
(5) Suggest that you add timing information by adding attributes to
your
variable.  I used the timing info from your filename to guess values
for
those attributes:

ncatted -a init_time,forecast_probability,o,c,"20170501_00" \
            -a init_time_ut,forecast_probability,o,c,"1493596800" \
            -a valid_time,forecast_probability,o,c,"20170501_01" \
            -a valid_time_ut,forecast_probability,o,c,"1493600400" \
            -a accum_time,forecast_probability,o,c,"01" \
            -a accum_time_sec,forecast_probability,o,l,3600 \
            fcst_neighborhood_precip_20170501f01_mod.nc

MET actually reads the init_time_ut, valid_time_ut, and accum_time_sec
attributes.  The other strings are there to make it more human-
readable.
Suppose we should enhance it to read either!

Please give this a shot.  Once you confirm that it fixes the behavior
on
your end, I can add it to the list of bugfixes for met-6.0.

Thanks,
John

On Thu, Jun 15, 2017 at 11:10 AM, Jeff Duda via RT <met_help at ucar.edu>
wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
>
> John,
> The file is already uploaded. I will await your response.
>
> Jeff
>
> On Thu, Jun 15, 2017 at 11:58 AM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Jeff,
> >
> > I'm not in my office right now.  Please post a sample data file to
our
> > anonymous ftp site.  When I get a chance this afternoon I'll grab
it and
> > take a look.  Hopefully after looking at the details, I can make a
good
> > suggestion on how you might proceed.
> >
> > Thanks
> > John
> >
> > On Thu, Jun 15, 2017 at 10:43 AM Jeff Duda via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> > >
> > > Yeah...I guess projection information is the problem (indeed the
grid
> is
> > > projected):
> > >
> > > [jdduda at schooner1 MODE]$
/home/jdduda/tool/met/bin/plot_data_plane
> > > /condo/map/jdduda/HWT2017/neighborhood_fcsts/precip/
> > > fcst_neighborhood_precip_20170501f01.nc ....
> > > DEBUG 1: Opening data file:
> > > /condo/map/jdduda/HWT2017/neighborhood_fcsts/precip/
> > > WARNING:
> > > WARNING: NcCfFile::open() -> could not determine the valid time,
using
> 0.
> > > WARNING:
> > > ERROR  :
> > > ERROR  : NcCfFile::read_netcdf_grid() -> Couldn't figure out
projection
> > > from inf
> > > ERROR  :
> > >
> > > This is the attributes section of the ncdump -h of that file,
which I
> > > uploaded to the ftp site, btw:
> > > // global attributes:
> > >                 :Thresholds = 0.254f, 2.54f, 6.35f, 12.7f, 25.4f
;
> > >                 :Scales = 10.f, 25.f, 50.f, 80.f, 100.f ;
> > >                 :MET_version = "V5.2" ;
> > >                 :MET_tool = "pcp_combine" ;
> > >                 :Note\ about\ above = "Did not actually use
pcp_combine
> > to
> > > generate this file" ;
> > >                 :Projection = "Lambert Conformal" ;
> > >                 :scale_lat_1 = "38.5" ;
> > >                 :scale_lat_2 = "38.5" ;
> > >                 :lat_pin = "20.974351" ;
> > >                 :lon_pin = "-120.105241" ;
> > >                 :x_pin = "0.0" ;
> > >                 :y_pin = "0.0" ;
> > >                 :lon_orient = "-97.5" ;
> > >                 :d_km = "3.0" ;
> > >                 :r_km = "6371.20" ;
> > >                 :nx = "1620" ;
> > >                 :ny = "1120 grid points" ;
> > >
> > > This is what I used for other files that I run using MODE and
those
> seem
> > to
> > > work, so is the problem simply that I have more than two
dimensions in
> > the
> > > file?
> > >
> > > Jeff
> > >
> > > On Thu, Jun 15, 2017 at 11:08 AM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > > Jeff,
> > > >
> > > > I see you're having trouble getting MET to read your NetCDF
file.
> The
> > > clue
> > > > I see in the output you sent is on this line:
> > > >
> > > > MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const
->
> star
> > > > found
> > > > in bad slot
> > > >
> > > > This is coming from the "MetNcFile" class which is used for
reading
> the
> > > > intermediate NetCDF output from the MET tools (i.e.
gen_vx_mask,
> > > > pcp_combine, and so on).  MET supports a few flavors of
NetCDF, and
> if
> > it
> > > > can't determine that it's one of the other two, it assumes
it's the
> > > > internal MET format.  Unfortunately, that format is limited
and
> really
> > > only
> > > > supports variables of 2 dimensions.
> > > >
> > > > Instead, let's tell MET to interpret your data as CF-compliant
using
> > the
> > > > "file_type" option.  Please try running the following
plot_data_plane
> > > > command to see if you get any better results:
> > > >
> > > > met-6.0/bin/plot_data_plane \
> > > > /condo/map/jdduda/HWT2017/neighborhood_fcsts/precip/
> > > > fcst_neighborhood_precip_20170501f01.nc \
> > > > plot.ps \
> > > > 'name="forecast_probability"; level="(0,0,*,*)";
> > file_type=NETCDF_NCCF;'
> > > >
> > > > I see that you have lat/lon variables defined.  If this is for
an
> > evenly
> > > > spaced lat/lon grid, that should work.  But if the data lives
on some
> > > other
> > > > projection, like lambert conformal, mercator, or polar
stereographic,
> > > > you'll need to define the projection info in the file.  I do
see that
> > > > there's no timing information present in your file... so
you'll need
> to
> > > add
> > > > that if you want the timestamps to be accurate in the output
of MET.
> > > >
> > > > Please let me know how it goes, and feel free to post the
problematic
> > > file
> > > > to our anonymous ftp site.
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > > On Wed, Jun 14, 2017 at 4:02 PM, Jeff Duda via RT
<met_help at ucar.edu
> >
> > > > wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> > > > >
> > > > > Thanks, John. Problem solved!
> > > > >
> > > > > I need to lump in a separate issue now.
> > > > >
> > > > > The output from MODE describes the problem well enough:
ERROR  :
> > > > > MetNcFile::data(NcVar *, const LongArray &, DataPlane &)
const ->
> > star
> > > > > found in bad slot
> > > > >
> > > > > Here's the entry in the config file:
> > > > >       name  = "forecast_probability";
> > > > >       level = "(0,0,*,*)";
> > > > >
> > > > > And the ncdump -h output from the forecast file:
> > > > > netcdf fcst_neighborhood_precip_20170501f01 {
> > > > > dimensions:
> > > > >         latitude = 1120 ;
> > > > >         longitude = 1620 ;
> > > > >         threshold = 5 ;
> > > > >         spatial_scale = 5 ;
> > > > > variables:
> > > > >         float latitude(latitude, longitude) ;
> > > > >         float longitude(latitude, longitude) ;
> > > > >         float forecast_probability(spatial_scale, threshold,
> > latitude,
> > > > > longitude) ;
> > > > >                 forecast_probability:ensemble = "MAP" ;
> > > > >
> > > > >
> > > > > So the two spatial dimensions are indeed the third and
fourth. So
> why
> > > is
> > > > > MODE complaining with this level entry in the config file?
> > > > >
> > > > > Jeff
> > > > >
> > > > > Auxiliary information:
> > > > > DEBUG 1: Forecast File: /condo/map/jdduda/HWT2017/
> > > > > neighborhood_fcsts/precip/
> > > > > fcst_neighborhood_precip_20170501f01.nc
> > > > > DEBUG 1: Observation File:
> > > > > /condo/map/jdduda/HWT2017/neighborhood_obs/precip/
> > > > > obs_neighborhood_precip_2017050101.nc
> > > > > obs_neighborhood_precip_2017050101.nc has the exact same
> > > dimensionality
> > > > as
> > > > > fcst_neighborhood_precip_20170501f01.nc, except the array in
> > question
> > > is
> > > > > named observed_probability instead of forecast_probability
> > > > >
> > > > > On Wed, Jun 14, 2017 at 2:40 PM, John Halley Gotway via RT <
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > > > Hi Jeff,
> > > > > >
> > > > > > Thanks for sending your sample file.  I grabbed it and was
able
> to
> > > get
> > > > > the
> > > > > > plot_data_plane utility to create the attached plot of
record
> > number
> > > > 42:
> > > > > >
> > > > > > met-6.0/bin/plot_data_plane \
> > > > > >    CA_00Z_free_upp_d01_36_NSSL.grib2 plot.ps \
> > > > > >    'name="MXUPHL"; level="L2000-5000";' -v 3 -plot_range 0
70
> > > > > >
> > > > > > I used the "-plot_range" option because the actual data
values go
> > > from
> > > > > > -1000 to about 70.
> > > > > >
> > > > > > I used "L2000-5000".  The "L" tells MET to match a generic
level
> > > > type...
> > > > > > meaning don't worry about whether it's a pressure level or
> > height...
> > > > just
> > > > > > make sure the level values match what's in the data.
> > > > > >
> > > > > > You should be able to use the same settings in the MODE
config
> > file.
> > > > > >
> > > > > > Thanks,
> > > > > > John
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, Jun 14, 2017 at 11:16 AM, Jeff Duda via RT <
> > > met_help at ucar.edu>
> > > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859
> >
> > > > > > >
> > > > > > > John,
> > > > > > > I totally waffled on explaining the data source.  While
it's
> > true I
> > > > am
> > > > > > > comparing my forecast to MRMS RotationTrack data, I am
not
> having
> > > > > trouble
> > > > > > > with the MRMS file. Instead, the issue is with the
forecast
> file
> > > > output
> > > > > > > from the UPP. So I uploaded that particular file
instead.
> > > > > > >
> > > > > > > Jeff
> > > > > > >
> > > > > > > On Wed, Jun 14, 2017 at 12:03 PM, John Halley Gotway via
RT <
> > > > > > > met_help at ucar.edu> wrote:
> > > > > > >
> > > > > > > > Jeff,
> > > > > > > >
> > > > > > > > Can you please point me to one of the GRIB2 MRMS files
you're
> > > > using?
> > > > > > > > Either send me a link to the file or just post it on
our
> > > anonymous
> > > > > ftp
> > > > > > > site
> > > > > > > >
(http://www.dtcenter.org/met/users/support/met_help.php#ftp
> ).
> > > We
> > > > > can
> > > > > > > run
> > > > > > > > it through the debugger and figure out what's going
on.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > John
> > > > > > > >
> > > > > > > > On Wed, Jun 14, 2017 at 10:49 AM, Jeff Duda via RT <
> > > > > met_help at ucar.edu>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Wed Jun 14 10:49:18 2017: Request 80859 was acted
upon.
> > > > > > > > > Transaction: Ticket created by jeffduda319 at gmail.com
> > > > > > > > >        Queue: met_help
> > > > > > > > >      Subject: difficulty specifying field and level
in MODE
> > > > > > > > >        Owner: Nobody
> > > > > > > > >   Requestors: jeffduda319 at gmail.com
> > > > > > > > >       Status: new
> > > > > > > > >  Ticket <URL: https://rt.rap.ucar.edu/rt/
> > > > > > Ticket/Display.html?id=80859
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Working with version 5.2:
> > > > > > > > >
> > > > > > > > > I want to verify MRMS rotation tracks against model
output
> > > > updraft
> > > > > > > > helicity
> > > > > > > > > (hourly max in the 2-5 km AGL layer). I know from
wgrib2
> (the
> > > > input
> > > > > > > file
> > > > > > > > > format is GRIB2) that the specific array record is
42, so I
> > can
> > > > use
> > > > > > R42
> > > > > > > > in
> > > > > > > > > the level specification of the config file. However,
I work
> > > with
> > > > > sets
> > > > > > > of
> > > > > > > > > files in which the UH array may not always have that
record
> > > > number,
> > > > > > so
> > > > > > > I
> > > > > > > > > would like to specify the level using some other
template.
> > > wgrib2
> > > > > > gives
> > > > > > > > the
> > > > > > > > > data as so:
> > > > > > > > >
> > > > > > > > > 42:48816704:00Z09may2016:MXUPHL Hourly Maximum of
Updraft
> > > > Helicity
> > > > > > > over
> > > > > > > > > Layer 2km to 5 km AGL [m^2/s^2]:lvl1=(103,5000)
> > > > > > > > lvl2=(103,2000):5000-2000 m
> > > > > > > > > above ground:35-36 hour max fcst:
> > > > > > > > >
> > > > > > > > > So I tried Z5000-2000 and Z2000-5000 in the level
setting
> of
> > > the
> > > > > > > control
> > > > > > > > > file, but MODE said
> > > > > > > > >
> > > > > > > > > WARNING: MetGrib2DataFile::data_plane() - No
matching
> record
> > > > found
> > > > > > for
> > > > > > > > > 'MXUPHL/Z5000-2000'
> > > > > > > > >
> > > > > > > > > for both attempts.
> > > > > > > > >
> > > > > > > > > What else can I try?
> > > > > > > > >
> > > > > > > > > Jeff Duda
> > > > > > > > > --
> > > > > > > > > Jeff Duda
> > > > > > > > > Post-doctoral research fellow
> > > > > > > > > University of Oklahoma School of Meteorology
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Jeff Duda
> > > > > > > Post-doctoral research fellow
> > > > > > > University of Oklahoma School of Meteorology
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Jeff Duda
> > > > > Post-doctoral research fellow
> > > > > University of Oklahoma School of Meteorology
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Jeff Duda
> > > Post-doctoral research fellow
> > > University of Oklahoma School of Meteorology
> > >
> > >
> >
> >
>
>
> --
> Jeff Duda
> Post-doctoral research fellow
> University of Oklahoma School of Meteorology
>
>

------------------------------------------------
Subject: difficulty specifying field and level in MODE
From: Jeff Duda
Time: Fri Jun 16 13:07:03 2017

John,
Thanks for the advice.

Since I do not have access to the source code (I had to have the
sysadmin
team at my organization build it for me because I can't figure it out
on my
own), I have to rely on the sysadmins to handle that for me. They said
they
won't get to it until next week, so I will let you know of the effects
of
the change then.

Jeff

On Thu, Jun 15, 2017 at 3:30 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:

> Jeff,
>
> I ran your file through the debugger and think I may have found a
pesky
> little bug in MET in the file named "met_file.cc".
>
> In addition, one rather silly requirement is that the latitude and
> longitude dimensions be named "lat" and "lon".  I used the ncrename
tool to
> rename them:
>
> ncrename -d latitude,lat -d longitude,lon \
>    fcst_neighborhood_precip_20170501f01.nc \
>    -o fcst_neighborhood_precip_20170501f01_mod.nc
>
> Running plot_data_plane still results in the same error:
> ERROR  : MetNcFile::data(NcVar *, const LongArray &, DataPlane &)
const ->
> star found in bad slot
>
> But when I change line 168 of
> met-6.0/src/libcode/vx_data2d_nc_met/met_file.cc:
>
> OLD:  for (j=0; j<Ndims; ++j)  {
> NEW: for (j=0; j<gDimNames.n_elements(); ++j)  {
>
> And then recompile MET.  And then it works:
>
> met-6.0/bin/plot_data_plane \
> fcst_neighborhood_precip_20170501f01_mod.nc \
> plot.ps \
> 'name="forecast_probability"; level="(0,0,*,*)";'
>
> Here's what I'd recommend:
>
> (1) Switch from naming dimensions latitude and longitude to "lat"
and
> "lon".
> (2) Try the bugfix I described above and then recompile.
> (3) Make sure that plot_data_plane works now.
> (4) Looking at this data using ncview, all of the probability values
appear
> to be 0.  I'd suggest looking at the generation of this data file to
make
> sure it's correct.
> (5) Suggest that you add timing information by adding attributes to
your
> variable.  I used the timing info from your filename to guess values
for
> those attributes:
>
> ncatted -a init_time,forecast_probability,o,c,"20170501_00" \
>             -a init_time_ut,forecast_probability,o,c,"1493596800" \
>             -a valid_time,forecast_probability,o,c,"20170501_01" \
>             -a valid_time_ut,forecast_probability,o,c,"1493600400" \
>             -a accum_time,forecast_probability,o,c,"01" \
>             -a accum_time_sec,forecast_probability,o,l,3600 \
>             fcst_neighborhood_precip_20170501f01_mod.nc
>
> MET actually reads the init_time_ut, valid_time_ut, and
accum_time_sec
> attributes.  The other strings are there to make it more human-
readable.
> Suppose we should enhance it to read either!
>
> Please give this a shot.  Once you confirm that it fixes the
behavior on
> your end, I can add it to the list of bugfixes for met-6.0.
>
> Thanks,
> John
>
>
> On Thu, Jun 15, 2017 at 11:10 AM, Jeff Duda via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> >
> > John,
> > The file is already uploaded. I will await your response.
> >
> > Jeff
> >
> > On Thu, Jun 15, 2017 at 11:58 AM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Jeff,
> > >
> > > I'm not in my office right now.  Please post a sample data file
to our
> > > anonymous ftp site.  When I get a chance this afternoon I'll
grab it
> and
> > > take a look.  Hopefully after looking at the details, I can make
a good
> > > suggestion on how you might proceed.
> > >
> > > Thanks
> > > John
> > >
> > > On Thu, Jun 15, 2017 at 10:43 AM Jeff Duda via RT
<met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859
>
> > > >
> > > > Yeah...I guess projection information is the problem (indeed
the grid
> > is
> > > > projected):
> > > >
> > > > [jdduda at schooner1 MODE]$
/home/jdduda/tool/met/bin/plot_data_plane
> > > > /condo/map/jdduda/HWT2017/neighborhood_fcsts/precip/
> > > > fcst_neighborhood_precip_20170501f01.nc ....
> > > > DEBUG 1: Opening data file:
> > > > /condo/map/jdduda/HWT2017/neighborhood_fcsts/precip/
> > > > WARNING:
> > > > WARNING: NcCfFile::open() -> could not determine the valid
time,
> using
> > 0.
> > > > WARNING:
> > > > ERROR  :
> > > > ERROR  : NcCfFile::read_netcdf_grid() -> Couldn't figure out
> projection
> > > > from inf
> > > > ERROR  :
> > > >
> > > > This is the attributes section of the ncdump -h of that file,
which I
> > > > uploaded to the ftp site, btw:
> > > > // global attributes:
> > > >                 :Thresholds = 0.254f, 2.54f, 6.35f, 12.7f,
25.4f ;
> > > >                 :Scales = 10.f, 25.f, 50.f, 80.f, 100.f ;
> > > >                 :MET_version = "V5.2" ;
> > > >                 :MET_tool = "pcp_combine" ;
> > > >                 :Note\ about\ above = "Did not actually use
> pcp_combine
> > > to
> > > > generate this file" ;
> > > >                 :Projection = "Lambert Conformal" ;
> > > >                 :scale_lat_1 = "38.5" ;
> > > >                 :scale_lat_2 = "38.5" ;
> > > >                 :lat_pin = "20.974351" ;
> > > >                 :lon_pin = "-120.105241" ;
> > > >                 :x_pin = "0.0" ;
> > > >                 :y_pin = "0.0" ;
> > > >                 :lon_orient = "-97.5" ;
> > > >                 :d_km = "3.0" ;
> > > >                 :r_km = "6371.20" ;
> > > >                 :nx = "1620" ;
> > > >                 :ny = "1120 grid points" ;
> > > >
> > > > This is what I used for other files that I run using MODE and
those
> > seem
> > > to
> > > > work, so is the problem simply that I have more than two
dimensions
> in
> > > the
> > > > file?
> > > >
> > > > Jeff
> > > >
> > > > On Thu, Jun 15, 2017 at 11:08 AM, John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > > Jeff,
> > > > >
> > > > > I see you're having trouble getting MET to read your NetCDF
file.
> > The
> > > > clue
> > > > > I see in the output you sent is on this line:
> > > > >
> > > > > MetNcFile::data(NcVar *, const LongArray &, DataPlane &)
const ->
> > star
> > > > > found
> > > > > in bad slot
> > > > >
> > > > > This is coming from the "MetNcFile" class which is used for
reading
> > the
> > > > > intermediate NetCDF output from the MET tools (i.e.
gen_vx_mask,
> > > > > pcp_combine, and so on).  MET supports a few flavors of
NetCDF, and
> > if
> > > it
> > > > > can't determine that it's one of the other two, it assumes
it's the
> > > > > internal MET format.  Unfortunately, that format is limited
and
> > really
> > > > only
> > > > > supports variables of 2 dimensions.
> > > > >
> > > > > Instead, let's tell MET to interpret your data as CF-
compliant
> using
> > > the
> > > > > "file_type" option.  Please try running the following
> plot_data_plane
> > > > > command to see if you get any better results:
> > > > >
> > > > > met-6.0/bin/plot_data_plane \
> > > > > /condo/map/jdduda/HWT2017/neighborhood_fcsts/precip/
> > > > > fcst_neighborhood_precip_20170501f01.nc \
> > > > > plot.ps \
> > > > > 'name="forecast_probability"; level="(0,0,*,*)";
> > > file_type=NETCDF_NCCF;'
> > > > >
> > > > > I see that you have lat/lon variables defined.  If this is
for an
> > > evenly
> > > > > spaced lat/lon grid, that should work.  But if the data
lives on
> some
> > > > other
> > > > > projection, like lambert conformal, mercator, or polar
> stereographic,
> > > > > you'll need to define the projection info in the file.  I do
see
> that
> > > > > there's no timing information present in your file... so
you'll
> need
> > to
> > > > add
> > > > > that if you want the timestamps to be accurate in the output
of
> MET.
> > > > >
> > > > > Please let me know how it goes, and feel free to post the
> problematic
> > > > file
> > > > > to our anonymous ftp site.
> > > > >
> > > > > Thanks,
> > > > > John
> > > > >
> > > > > On Wed, Jun 14, 2017 at 4:02 PM, Jeff Duda via RT <
> met_help at ucar.edu
> > >
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> > > > > >
> > > > > > Thanks, John. Problem solved!
> > > > > >
> > > > > > I need to lump in a separate issue now.
> > > > > >
> > > > > > The output from MODE describes the problem well enough:
ERROR  :
> > > > > > MetNcFile::data(NcVar *, const LongArray &, DataPlane &)
const ->
> > > star
> > > > > > found in bad slot
> > > > > >
> > > > > > Here's the entry in the config file:
> > > > > >       name  = "forecast_probability";
> > > > > >       level = "(0,0,*,*)";
> > > > > >
> > > > > > And the ncdump -h output from the forecast file:
> > > > > > netcdf fcst_neighborhood_precip_20170501f01 {
> > > > > > dimensions:
> > > > > >         latitude = 1120 ;
> > > > > >         longitude = 1620 ;
> > > > > >         threshold = 5 ;
> > > > > >         spatial_scale = 5 ;
> > > > > > variables:
> > > > > >         float latitude(latitude, longitude) ;
> > > > > >         float longitude(latitude, longitude) ;
> > > > > >         float forecast_probability(spatial_scale,
threshold,
> > > latitude,
> > > > > > longitude) ;
> > > > > >                 forecast_probability:ensemble = "MAP" ;
> > > > > >
> > > > > >
> > > > > > So the two spatial dimensions are indeed the third and
fourth. So
> > why
> > > > is
> > > > > > MODE complaining with this level entry in the config file?
> > > > > >
> > > > > > Jeff
> > > > > >
> > > > > > Auxiliary information:
> > > > > > DEBUG 1: Forecast File: /condo/map/jdduda/HWT2017/
> > > > > > neighborhood_fcsts/precip/
> > > > > > fcst_neighborhood_precip_20170501f01.nc
> > > > > > DEBUG 1: Observation File:
> > > > > > /condo/map/jdduda/HWT2017/neighborhood_obs/precip/
> > > > > > obs_neighborhood_precip_2017050101.nc
> > > > > > obs_neighborhood_precip_2017050101.nc has the exact same
> > > > dimensionality
> > > > > as
> > > > > > fcst_neighborhood_precip_20170501f01.nc, except the array
in
> > > question
> > > > is
> > > > > > named observed_probability instead of forecast_probability
> > > > > >
> > > > > > On Wed, Jun 14, 2017 at 2:40 PM, John Halley Gotway via RT
<
> > > > > > met_help at ucar.edu> wrote:
> > > > > >
> > > > > > > Hi Jeff,
> > > > > > >
> > > > > > > Thanks for sending your sample file.  I grabbed it and
was able
> > to
> > > > get
> > > > > > the
> > > > > > > plot_data_plane utility to create the attached plot of
record
> > > number
> > > > > 42:
> > > > > > >
> > > > > > > met-6.0/bin/plot_data_plane \
> > > > > > >    CA_00Z_free_upp_d01_36_NSSL.grib2 plot.ps \
> > > > > > >    'name="MXUPHL"; level="L2000-5000";' -v 3 -plot_range
0 70
> > > > > > >
> > > > > > > I used the "-plot_range" option because the actual data
values
> go
> > > > from
> > > > > > > -1000 to about 70.
> > > > > > >
> > > > > > > I used "L2000-5000".  The "L" tells MET to match a
generic
> level
> > > > > type...
> > > > > > > meaning don't worry about whether it's a pressure level
or
> > > height...
> > > > > just
> > > > > > > make sure the level values match what's in the data.
> > > > > > >
> > > > > > > You should be able to use the same settings in the MODE
config
> > > file.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > John
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Jun 14, 2017 at 11:16 AM, Jeff Duda via RT <
> > > > met_help at ucar.edu>
> > > > > > > wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > <URL: https://rt.rap.ucar.edu/rt/
> Ticket/Display.html?id=80859
> > >
> > > > > > > >
> > > > > > > > John,
> > > > > > > > I totally waffled on explaining the data source.
While it's
> > > true I
> > > > > am
> > > > > > > > comparing my forecast to MRMS RotationTrack data, I am
not
> > having
> > > > > > trouble
> > > > > > > > with the MRMS file. Instead, the issue is with the
forecast
> > file
> > > > > output
> > > > > > > > from the UPP. So I uploaded that particular file
instead.
> > > > > > > >
> > > > > > > > Jeff
> > > > > > > >
> > > > > > > > On Wed, Jun 14, 2017 at 12:03 PM, John Halley Gotway
via RT <
> > > > > > > > met_help at ucar.edu> wrote:
> > > > > > > >
> > > > > > > > > Jeff,
> > > > > > > > >
> > > > > > > > > Can you please point me to one of the GRIB2 MRMS
files
> you're
> > > > > using?
> > > > > > > > > Either send me a link to the file or just post it on
our
> > > > anonymous
> > > > > > ftp
> > > > > > > > site
> > > > > > > > > (http://www.dtcenter.org/met/
> users/support/met_help.php#ftp
> > ).
> > > > We
> > > > > > can
> > > > > > > > run
> > > > > > > > > it through the debugger and figure out what's going
on.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > John
> > > > > > > > >
> > > > > > > > > On Wed, Jun 14, 2017 at 10:49 AM, Jeff Duda via RT <
> > > > > > met_help at ucar.edu>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Wed Jun 14 10:49:18 2017: Request 80859 was acted
upon.
> > > > > > > > > > Transaction: Ticket created by
jeffduda319 at gmail.com
> > > > > > > > > >        Queue: met_help
> > > > > > > > > >      Subject: difficulty specifying field and
level in
> MODE
> > > > > > > > > >        Owner: Nobody
> > > > > > > > > >   Requestors: jeffduda319 at gmail.com
> > > > > > > > > >       Status: new
> > > > > > > > > >  Ticket <URL: https://rt.rap.ucar.edu/rt/
> > > > > > > Ticket/Display.html?id=80859
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Working with version 5.2:
> > > > > > > > > >
> > > > > > > > > > I want to verify MRMS rotation tracks against
model
> output
> > > > > updraft
> > > > > > > > > helicity
> > > > > > > > > > (hourly max in the 2-5 km AGL layer). I know from
wgrib2
> > (the
> > > > > input
> > > > > > > > file
> > > > > > > > > > format is GRIB2) that the specific array record is
42,
> so I
> > > can
> > > > > use
> > > > > > > R42
> > > > > > > > > in
> > > > > > > > > > the level specification of the config file.
However, I
> work
> > > > with
> > > > > > sets
> > > > > > > > of
> > > > > > > > > > files in which the UH array may not always have
that
> record
> > > > > number,
> > > > > > > so
> > > > > > > > I
> > > > > > > > > > would like to specify the level using some other
> template.
> > > > wgrib2
> > > > > > > gives
> > > > > > > > > the
> > > > > > > > > > data as so:
> > > > > > > > > >
> > > > > > > > > > 42:48816704:00Z09may2016:MXUPHL Hourly Maximum of
> Updraft
> > > > > Helicity
> > > > > > > > over
> > > > > > > > > > Layer 2km to 5 km AGL [m^2/s^2]:lvl1=(103,5000)
> > > > > > > > > lvl2=(103,2000):5000-2000 m
> > > > > > > > > > above ground:35-36 hour max fcst:
> > > > > > > > > >
> > > > > > > > > > So I tried Z5000-2000 and Z2000-5000 in the level
setting
> > of
> > > > the
> > > > > > > > control
> > > > > > > > > > file, but MODE said
> > > > > > > > > >
> > > > > > > > > > WARNING: MetGrib2DataFile::data_plane() - No
matching
> > record
> > > > > found
> > > > > > > for
> > > > > > > > > > 'MXUPHL/Z5000-2000'
> > > > > > > > > >
> > > > > > > > > > for both attempts.
> > > > > > > > > >
> > > > > > > > > > What else can I try?
> > > > > > > > > >
> > > > > > > > > > Jeff Duda
> > > > > > > > > > --
> > > > > > > > > > Jeff Duda
> > > > > > > > > > Post-doctoral research fellow
> > > > > > > > > > University of Oklahoma School of Meteorology
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Jeff Duda
> > > > > > > > Post-doctoral research fellow
> > > > > > > > University of Oklahoma School of Meteorology
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Jeff Duda
> > > > > > Post-doctoral research fellow
> > > > > > University of Oklahoma School of Meteorology
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Jeff Duda
> > > > Post-doctoral research fellow
> > > > University of Oklahoma School of Meteorology
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Jeff Duda
> > Post-doctoral research fellow
> > University of Oklahoma School of Meteorology
> >
> >
>
>

--
Jeff Duda
Post-doctoral research fellow
University of Oklahoma School of Meteorology

------------------------------------------------
Subject: difficulty specifying field and level in MODE
From: John Halley Gotway
Time: Fri Jun 16 14:12:07 2017

Jeff,

OK, thanks for letting me know.  I went ahead and posted it as a
bugfix.  I
was a pretty obvious oversight in the code:
   http://www.dtcenter.org/met/users/support/known_issues/METv6.0/index.php

Thanks,
John

On Fri, Jun 16, 2017 at 1:07 PM, Jeff Duda via RT <met_help at ucar.edu>
wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
>
> John,
> Thanks for the advice.
>
> Since I do not have access to the source code (I had to have the
sysadmin
> team at my organization build it for me because I can't figure it
out on my
> own), I have to rely on the sysadmins to handle that for me. They
said they
> won't get to it until next week, so I will let you know of the
effects of
> the change then.
>
> Jeff
>
> On Thu, Jun 15, 2017 at 3:30 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Jeff,
> >
> > I ran your file through the debugger and think I may have found a
pesky
> > little bug in MET in the file named "met_file.cc".
> >
> > In addition, one rather silly requirement is that the latitude and
> > longitude dimensions be named "lat" and "lon".  I used the
ncrename tool
> to
> > rename them:
> >
> > ncrename -d latitude,lat -d longitude,lon \
> >    fcst_neighborhood_precip_20170501f01.nc \
> >    -o fcst_neighborhood_precip_20170501f01_mod.nc
> >
> > Running plot_data_plane still results in the same error:
> > ERROR  : MetNcFile::data(NcVar *, const LongArray &, DataPlane &)
const
> ->
> > star found in bad slot
> >
> > But when I change line 168 of
> > met-6.0/src/libcode/vx_data2d_nc_met/met_file.cc:
> >
> > OLD:  for (j=0; j<Ndims; ++j)  {
> > NEW: for (j=0; j<gDimNames.n_elements(); ++j)  {
> >
> > And then recompile MET.  And then it works:
> >
> > met-6.0/bin/plot_data_plane \
> > fcst_neighborhood_precip_20170501f01_mod.nc \
> > plot.ps \
> > 'name="forecast_probability"; level="(0,0,*,*)";'
> >
> > Here's what I'd recommend:
> >
> > (1) Switch from naming dimensions latitude and longitude to "lat"
and
> > "lon".
> > (2) Try the bugfix I described above and then recompile.
> > (3) Make sure that plot_data_plane works now.
> > (4) Looking at this data using ncview, all of the probability
values
> appear
> > to be 0.  I'd suggest looking at the generation of this data file
to make
> > sure it's correct.
> > (5) Suggest that you add timing information by adding attributes
to your
> > variable.  I used the timing info from your filename to guess
values for
> > those attributes:
> >
> > ncatted -a init_time,forecast_probability,o,c,"20170501_00" \
> >             -a init_time_ut,forecast_probability,o,c,"1493596800"
\
> >             -a valid_time,forecast_probability,o,c,"20170501_01" \
> >             -a valid_time_ut,forecast_probability,o,c,"1493600400"
\
> >             -a accum_time,forecast_probability,o,c,"01" \
> >             -a accum_time_sec,forecast_probability,o,l,3600 \
> >             fcst_neighborhood_precip_20170501f01_mod.nc
> >
> > MET actually reads the init_time_ut, valid_time_ut, and
accum_time_sec
> > attributes.  The other strings are there to make it more human-
readable.
> > Suppose we should enhance it to read either!
> >
> > Please give this a shot.  Once you confirm that it fixes the
behavior on
> > your end, I can add it to the list of bugfixes for met-6.0.
> >
> > Thanks,
> > John
> >
> >
> > On Thu, Jun 15, 2017 at 11:10 AM, Jeff Duda via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> > >
> > > John,
> > > The file is already uploaded. I will await your response.
> > >
> > > Jeff
> > >
> > > On Thu, Jun 15, 2017 at 11:58 AM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > > Jeff,
> > > >
> > > > I'm not in my office right now.  Please post a sample data
file to
> our
> > > > anonymous ftp site.  When I get a chance this afternoon I'll
grab it
> > and
> > > > take a look.  Hopefully after looking at the details, I can
make a
> good
> > > > suggestion on how you might proceed.
> > > >
> > > > Thanks
> > > > John
> > > >
> > > > On Thu, Jun 15, 2017 at 10:43 AM Jeff Duda via RT
<met_help at ucar.edu
> >
> > > > wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> > > > >
> > > > > Yeah...I guess projection information is the problem (indeed
the
> grid
> > > is
> > > > > projected):
> > > > >
> > > > > [jdduda at schooner1 MODE]$
/home/jdduda/tool/met/bin/plot_data_plane
> > > > > /condo/map/jdduda/HWT2017/neighborhood_fcsts/precip/
> > > > > fcst_neighborhood_precip_20170501f01.nc ....
> > > > > DEBUG 1: Opening data file:
> > > > > /condo/map/jdduda/HWT2017/neighborhood_fcsts/precip/
> > > > > WARNING:
> > > > > WARNING: NcCfFile::open() -> could not determine the valid
time,
> > using
> > > 0.
> > > > > WARNING:
> > > > > ERROR  :
> > > > > ERROR  : NcCfFile::read_netcdf_grid() -> Couldn't figure out
> > projection
> > > > > from inf
> > > > > ERROR  :
> > > > >
> > > > > This is the attributes section of the ncdump -h of that
file,
> which I
> > > > > uploaded to the ftp site, btw:
> > > > > // global attributes:
> > > > >                 :Thresholds = 0.254f, 2.54f, 6.35f, 12.7f,
25.4f ;
> > > > >                 :Scales = 10.f, 25.f, 50.f, 80.f, 100.f ;
> > > > >                 :MET_version = "V5.2" ;
> > > > >                 :MET_tool = "pcp_combine" ;
> > > > >                 :Note\ about\ above = "Did not actually use
> > pcp_combine
> > > > to
> > > > > generate this file" ;
> > > > >                 :Projection = "Lambert Conformal" ;
> > > > >                 :scale_lat_1 = "38.5" ;
> > > > >                 :scale_lat_2 = "38.5" ;
> > > > >                 :lat_pin = "20.974351" ;
> > > > >                 :lon_pin = "-120.105241" ;
> > > > >                 :x_pin = "0.0" ;
> > > > >                 :y_pin = "0.0" ;
> > > > >                 :lon_orient = "-97.5" ;
> > > > >                 :d_km = "3.0" ;
> > > > >                 :r_km = "6371.20" ;
> > > > >                 :nx = "1620" ;
> > > > >                 :ny = "1120 grid points" ;
> > > > >
> > > > > This is what I used for other files that I run using MODE
and those
> > > seem
> > > > to
> > > > > work, so is the problem simply that I have more than two
dimensions
> > in
> > > > the
> > > > > file?
> > > > >
> > > > > Jeff
> > > > >
> > > > > On Thu, Jun 15, 2017 at 11:08 AM, John Halley Gotway via RT
<
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > > > Jeff,
> > > > > >
> > > > > > I see you're having trouble getting MET to read your
NetCDF file.
> > > The
> > > > > clue
> > > > > > I see in the output you sent is on this line:
> > > > > >
> > > > > > MetNcFile::data(NcVar *, const LongArray &, DataPlane &)
const ->
> > > star
> > > > > > found
> > > > > > in bad slot
> > > > > >
> > > > > > This is coming from the "MetNcFile" class which is used
for
> reading
> > > the
> > > > > > intermediate NetCDF output from the MET tools (i.e.
gen_vx_mask,
> > > > > > pcp_combine, and so on).  MET supports a few flavors of
NetCDF,
> and
> > > if
> > > > it
> > > > > > can't determine that it's one of the other two, it assumes
it's
> the
> > > > > > internal MET format.  Unfortunately, that format is
limited and
> > > really
> > > > > only
> > > > > > supports variables of 2 dimensions.
> > > > > >
> > > > > > Instead, let's tell MET to interpret your data as CF-
compliant
> > using
> > > > the
> > > > > > "file_type" option.  Please try running the following
> > plot_data_plane
> > > > > > command to see if you get any better results:
> > > > > >
> > > > > > met-6.0/bin/plot_data_plane \
> > > > > > /condo/map/jdduda/HWT2017/neighborhood_fcsts/precip/
> > > > > > fcst_neighborhood_precip_20170501f01.nc \
> > > > > > plot.ps \
> > > > > > 'name="forecast_probability"; level="(0,0,*,*)";
> > > > file_type=NETCDF_NCCF;'
> > > > > >
> > > > > > I see that you have lat/lon variables defined.  If this is
for an
> > > > evenly
> > > > > > spaced lat/lon grid, that should work.  But if the data
lives on
> > some
> > > > > other
> > > > > > projection, like lambert conformal, mercator, or polar
> > stereographic,
> > > > > > you'll need to define the projection info in the file.  I
do see
> > that
> > > > > > there's no timing information present in your file... so
you'll
> > need
> > > to
> > > > > add
> > > > > > that if you want the timestamps to be accurate in the
output of
> > MET.
> > > > > >
> > > > > > Please let me know how it goes, and feel free to post the
> > problematic
> > > > > file
> > > > > > to our anonymous ftp site.
> > > > > >
> > > > > > Thanks,
> > > > > > John
> > > > > >
> > > > > > On Wed, Jun 14, 2017 at 4:02 PM, Jeff Duda via RT <
> > met_help at ucar.edu
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859
> >
> > > > > > >
> > > > > > > Thanks, John. Problem solved!
> > > > > > >
> > > > > > > I need to lump in a separate issue now.
> > > > > > >
> > > > > > > The output from MODE describes the problem well enough:
ERROR
> :
> > > > > > > MetNcFile::data(NcVar *, const LongArray &, DataPlane &)
const
> ->
> > > > star
> > > > > > > found in bad slot
> > > > > > >
> > > > > > > Here's the entry in the config file:
> > > > > > >       name  = "forecast_probability";
> > > > > > >       level = "(0,0,*,*)";
> > > > > > >
> > > > > > > And the ncdump -h output from the forecast file:
> > > > > > > netcdf fcst_neighborhood_precip_20170501f01 {
> > > > > > > dimensions:
> > > > > > >         latitude = 1120 ;
> > > > > > >         longitude = 1620 ;
> > > > > > >         threshold = 5 ;
> > > > > > >         spatial_scale = 5 ;
> > > > > > > variables:
> > > > > > >         float latitude(latitude, longitude) ;
> > > > > > >         float longitude(latitude, longitude) ;
> > > > > > >         float forecast_probability(spatial_scale,
threshold,
> > > > latitude,
> > > > > > > longitude) ;
> > > > > > >                 forecast_probability:ensemble = "MAP" ;
> > > > > > >
> > > > > > >
> > > > > > > So the two spatial dimensions are indeed the third and
fourth.
> So
> > > why
> > > > > is
> > > > > > > MODE complaining with this level entry in the config
file?
> > > > > > >
> > > > > > > Jeff
> > > > > > >
> > > > > > > Auxiliary information:
> > > > > > > DEBUG 1: Forecast File: /condo/map/jdduda/HWT2017/
> > > > > > > neighborhood_fcsts/precip/
> > > > > > > fcst_neighborhood_precip_20170501f01.nc
> > > > > > > DEBUG 1: Observation File:
> > > > > > > /condo/map/jdduda/HWT2017/neighborhood_obs/precip/
> > > > > > > obs_neighborhood_precip_2017050101.nc
> > > > > > > obs_neighborhood_precip_2017050101.nc has the exact same
> > > > > dimensionality
> > > > > > as
> > > > > > > fcst_neighborhood_precip_20170501f01.nc, except the
array in
> > > > question
> > > > > is
> > > > > > > named observed_probability instead of
forecast_probability
> > > > > > >
> > > > > > > On Wed, Jun 14, 2017 at 2:40 PM, John Halley Gotway via
RT <
> > > > > > > met_help at ucar.edu> wrote:
> > > > > > >
> > > > > > > > Hi Jeff,
> > > > > > > >
> > > > > > > > Thanks for sending your sample file.  I grabbed it and
was
> able
> > > to
> > > > > get
> > > > > > > the
> > > > > > > > plot_data_plane utility to create the attached plot of
record
> > > > number
> > > > > > 42:
> > > > > > > >
> > > > > > > > met-6.0/bin/plot_data_plane \
> > > > > > > >    CA_00Z_free_upp_d01_36_NSSL.grib2 plot.ps \
> > > > > > > >    'name="MXUPHL"; level="L2000-5000";' -v 3
-plot_range 0 70
> > > > > > > >
> > > > > > > > I used the "-plot_range" option because the actual
data
> values
> > go
> > > > > from
> > > > > > > > -1000 to about 70.
> > > > > > > >
> > > > > > > > I used "L2000-5000".  The "L" tells MET to match a
generic
> > level
> > > > > > type...
> > > > > > > > meaning don't worry about whether it's a pressure
level or
> > > > height...
> > > > > > just
> > > > > > > > make sure the level values match what's in the data.
> > > > > > > >
> > > > > > > > You should be able to use the same settings in the
MODE
> config
> > > > file.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > John
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Jun 14, 2017 at 11:16 AM, Jeff Duda via RT <
> > > > > met_help at ucar.edu>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > <URL: https://rt.rap.ucar.edu/rt/
> > Ticket/Display.html?id=80859
> > > >
> > > > > > > > >
> > > > > > > > > John,
> > > > > > > > > I totally waffled on explaining the data source.
While
> it's
> > > > true I
> > > > > > am
> > > > > > > > > comparing my forecast to MRMS RotationTrack data, I
am not
> > > having
> > > > > > > trouble
> > > > > > > > > with the MRMS file. Instead, the issue is with the
forecast
> > > file
> > > > > > output
> > > > > > > > > from the UPP. So I uploaded that particular file
instead.
> > > > > > > > >
> > > > > > > > > Jeff
> > > > > > > > >
> > > > > > > > > On Wed, Jun 14, 2017 at 12:03 PM, John Halley Gotway
via
> RT <
> > > > > > > > > met_help at ucar.edu> wrote:
> > > > > > > > >
> > > > > > > > > > Jeff,
> > > > > > > > > >
> > > > > > > > > > Can you please point me to one of the GRIB2 MRMS
files
> > you're
> > > > > > using?
> > > > > > > > > > Either send me a link to the file or just post it
on our
> > > > > anonymous
> > > > > > > ftp
> > > > > > > > > site
> > > > > > > > > > (http://www.dtcenter.org/met/
> > users/support/met_help.php#ftp
> > > ).
> > > > > We
> > > > > > > can
> > > > > > > > > run
> > > > > > > > > > it through the debugger and figure out what's
going on.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > John
> > > > > > > > > >
> > > > > > > > > > On Wed, Jun 14, 2017 at 10:49 AM, Jeff Duda via RT
<
> > > > > > > met_help at ucar.edu>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Wed Jun 14 10:49:18 2017: Request 80859 was
acted upon.
> > > > > > > > > > > Transaction: Ticket created by
jeffduda319 at gmail.com
> > > > > > > > > > >        Queue: met_help
> > > > > > > > > > >      Subject: difficulty specifying field and
level in
> > MODE
> > > > > > > > > > >        Owner: Nobody
> > > > > > > > > > >   Requestors: jeffduda319 at gmail.com
> > > > > > > > > > >       Status: new
> > > > > > > > > > >  Ticket <URL: https://rt.rap.ucar.edu/rt/
> > > > > > > > Ticket/Display.html?id=80859
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Working with version 5.2:
> > > > > > > > > > >
> > > > > > > > > > > I want to verify MRMS rotation tracks against
model
> > output
> > > > > > updraft
> > > > > > > > > > helicity
> > > > > > > > > > > (hourly max in the 2-5 km AGL layer). I know
from
> wgrib2
> > > (the
> > > > > > input
> > > > > > > > > file
> > > > > > > > > > > format is GRIB2) that the specific array record
is 42,
> > so I
> > > > can
> > > > > > use
> > > > > > > > R42
> > > > > > > > > > in
> > > > > > > > > > > the level specification of the config file.
However, I
> > work
> > > > > with
> > > > > > > sets
> > > > > > > > > of
> > > > > > > > > > > files in which the UH array may not always have
that
> > record
> > > > > > number,
> > > > > > > > so
> > > > > > > > > I
> > > > > > > > > > > would like to specify the level using some other
> > template.
> > > > > wgrib2
> > > > > > > > gives
> > > > > > > > > > the
> > > > > > > > > > > data as so:
> > > > > > > > > > >
> > > > > > > > > > > 42:48816704:00Z09may2016:MXUPHL Hourly Maximum
of
> > Updraft
> > > > > > Helicity
> > > > > > > > > over
> > > > > > > > > > > Layer 2km to 5 km AGL [m^2/s^2]:lvl1=(103,5000)
> > > > > > > > > > lvl2=(103,2000):5000-2000 m
> > > > > > > > > > > above ground:35-36 hour max fcst:
> > > > > > > > > > >
> > > > > > > > > > > So I tried Z5000-2000 and Z2000-5000 in the
level
> setting
> > > of
> > > > > the
> > > > > > > > > control
> > > > > > > > > > > file, but MODE said
> > > > > > > > > > >
> > > > > > > > > > > WARNING: MetGrib2DataFile::data_plane() - No
matching
> > > record
> > > > > > found
> > > > > > > > for
> > > > > > > > > > > 'MXUPHL/Z5000-2000'
> > > > > > > > > > >
> > > > > > > > > > > for both attempts.
> > > > > > > > > > >
> > > > > > > > > > > What else can I try?
> > > > > > > > > > >
> > > > > > > > > > > Jeff Duda
> > > > > > > > > > > --
> > > > > > > > > > > Jeff Duda
> > > > > > > > > > > Post-doctoral research fellow
> > > > > > > > > > > University of Oklahoma School of Meteorology
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Jeff Duda
> > > > > > > > > Post-doctoral research fellow
> > > > > > > > > University of Oklahoma School of Meteorology
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Jeff Duda
> > > > > > > Post-doctoral research fellow
> > > > > > > University of Oklahoma School of Meteorology
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Jeff Duda
> > > > > Post-doctoral research fellow
> > > > > University of Oklahoma School of Meteorology
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Jeff Duda
> > > Post-doctoral research fellow
> > > University of Oklahoma School of Meteorology
> > >
> > >
> >
> >
>
>
> --
> Jeff Duda
> Post-doctoral research fellow
> University of Oklahoma School of Meteorology
>
>

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