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

Wed Aug 9 10:12:31 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
>
>

------------------------------------------------
Subject: difficulty specifying field and level in MODE
From: Jeff Duda
Time: Thu Jun 22 15:20:15 2017

John,
My local IT sysadmin sent me this email about the issue:

The change you specified:

The file is src/libcode/vx_data2d_nc_met/met_file.cc. The code to fix
(look
around line 168) is

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

is not compiling because there is no definition of gDimNames.

The exact error is:

met_file.cc(173): error: identifier "gDimNames" is undefined

  for (j=0; j<gDimNames.n_elements(); ++j)  {

Can you suggest a solution? This is MET v 5.2.

Jeff

On Fri, Jun 16, 2017 at 3:12 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:

> 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
> >
> >
>
>

--
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 23 11:47:58 2017

Jeff,

I should have asked the version you were using in the beginning!  I
posted
a bugfix for 6.0, not 5.2.

In fact, going back and testing with 5.2, it works fine!  The bug was
introduced in version 6.0 (and patched by the bugfix I posted).

Here's the 5.2 plot_data_plane command I ran after changing the
dimension
names to lat and lon:

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

Since your 5.2 build is now in a broken state, I'd suggest asking your
sys
admin to download MET 5.2 from scratch and then apply the latest set
of 5.2
patches.

Or you could take this opportunity to switch to 6.0.  But
unfortunately the
compilation environment has changed a lot with the switch from NetCDF3
to
NetCDF4.

Sorry for all the confusion.

John

On Thu, Jun 22, 2017 at 3:20 PM, Jeff Duda via RT <met_help at ucar.edu>
wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
>
> John,
> My local IT sysadmin sent me this email about the issue:
>
> The change you specified:
>
> The file is src/libcode/vx_data2d_nc_met/met_file.cc. The code to
fix
> (look
> around line 168) is
>
> OLD:  for (j=0; j<Ndims; ++j)  {
> NEW: for (j=0; j<gDimNames.n_elements(); ++j) {
>
>
>
> is not compiling because there is no definition of gDimNames.
>
>
>
> The exact error is:
>
> met_file.cc(173): error: identifier "gDimNames" is undefined
>
>   for (j=0; j<gDimNames.n_elements(); ++j)  {
>
>
> Can you suggest a solution? This is MET v 5.2.
>
>
> Jeff
>
>
> On Fri, Jun 16, 2017 at 3:12 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > 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
> > >
> > >
> >
> >
>
>
> --
> 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 23 12:36:14 2017

Okay, all you changed there was the index values. In my original email
the
indices were (0,0,*,*), and that didn't work. Now using (0,1,*,*) it
does
work. Why does the latter work but the former doesn't?

Jeff

On Fri, Jun 23, 2017 at 12:47 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:

> Jeff,
>
> I should have asked the version you were using in the beginning!  I
posted
> a bugfix for 6.0, not 5.2.
>
> In fact, going back and testing with 5.2, it works fine!  The bug
was
> introduced in version 6.0 (and patched by the bugfix I posted).
>
> Here's the 5.2 plot_data_plane command I ran after changing the
dimension
> names to lat and lon:
>
> met-5.2/bin/plot_data_plane \
> fcst_neighborhood_precip_20170501f01_mod.nc plot.ps \
> 'name="forecast_probability"; level="(0,1,*,*)";'
>
> Since your 5.2 build is now in a broken state, I'd suggest asking
your sys
> admin to download MET 5.2 from scratch and then apply the latest set
of 5.2
> patches.
>
> Or you could take this opportunity to switch to 6.0.  But
unfortunately the
> compilation environment has changed a lot with the switch from
NetCDF3 to
> NetCDF4.
>
> Sorry for all the confusion.
>
> John
>
> On Thu, Jun 22, 2017 at 3:20 PM, Jeff Duda via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> >
> > John,
> > My local IT sysadmin sent me this email about the issue:
> >
> > The change you specified:
> >
> > The file is src/libcode/vx_data2d_nc_met/met_file.cc. The code to
fix
> > (look
> > around line 168) is
> >
> > OLD:  for (j=0; j<Ndims; ++j)  {
> > NEW: for (j=0; j<gDimNames.n_elements(); ++j) {
> >
> >
> >
> > is not compiling because there is no definition of gDimNames.
> >
> >
> >
> > The exact error is:
> >
> > met_file.cc(173): error: identifier "gDimNames" is undefined
> >
> >   for (j=0; j<gDimNames.n_elements(); ++j)  {
> >
> >
> > Can you suggest a solution? This is MET v 5.2.
> >
> >
> > Jeff
> >
> >
> > On Fri, Jun 16, 2017 at 3:12 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > 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
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > 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 23 12:46:08 2017

Using the original indices works too:

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

All I did was switch the name of the dimensions from "latitude" and
"longitude" to "lat" and "lon".

This is the error that shows up when using the "latitude" and
"longitude"
dimensions:
ERROR  : MetNcFile::data(NcVar *, const LongArray &, DataPlane &)
const ->
star found in bad slot

John

On Fri, Jun 23, 2017 at 12:36 PM, Jeff Duda via RT <met_help at ucar.edu>
wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
>
> Okay, all you changed there was the index values. In my original
email the
> indices were (0,0,*,*), and that didn't work. Now using (0,1,*,*) it
does
> work. Why does the latter work but the former doesn't?
>
> Jeff
>
> On Fri, Jun 23, 2017 at 12:47 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Jeff,
> >
> > I should have asked the version you were using in the beginning!
I
> posted
> > a bugfix for 6.0, not 5.2.
> >
> > In fact, going back and testing with 5.2, it works fine!  The bug
was
> > introduced in version 6.0 (and patched by the bugfix I posted).
> >
> > Here's the 5.2 plot_data_plane command I ran after changing the
dimension
> > names to lat and lon:
> >
> > met-5.2/bin/plot_data_plane \
> > fcst_neighborhood_precip_20170501f01_mod.nc plot.ps \
> > 'name="forecast_probability"; level="(0,1,*,*)";'
> >
> > Since your 5.2 build is now in a broken state, I'd suggest asking
your
> sys
> > admin to download MET 5.2 from scratch and then apply the latest
set of
> 5.2
> > patches.
> >
> > Or you could take this opportunity to switch to 6.0.  But
unfortunately
> the
> > compilation environment has changed a lot with the switch from
NetCDF3 to
> > NetCDF4.
> >
> > Sorry for all the confusion.
> >
> > John
> >
> > On Thu, Jun 22, 2017 at 3:20 PM, Jeff Duda via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> > >
> > > John,
> > > My local IT sysadmin sent me this email about the issue:
> > >
> > > The change you specified:
> > >
> > > The file is src/libcode/vx_data2d_nc_met/met_file.cc. The code
to fix
> > > (look
> > > around line 168) is
> > >
> > > OLD:  for (j=0; j<Ndims; ++j)  {
> > > NEW: for (j=0; j<gDimNames.n_elements(); ++j) {
> > >
> > >
> > >
> > > is not compiling because there is no definition of gDimNames.
> > >
> > >
> > >
> > > The exact error is:
> > >
> > > met_file.cc(173): error: identifier "gDimNames" is undefined
> > >
> > >   for (j=0; j<gDimNames.n_elements(); ++j)  {
> > >
> > >
> > > Can you suggest a solution? This is MET v 5.2.
> > >
> > >
> > > Jeff
> > >
> > >
> > > On Fri, Jun 16, 2017 at 3:12 PM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > > 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
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > 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 23 13:41:48 2017

ohhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

I thought the problem was with the index settings I was using...

So the real limitation here was that I was using the wrong dimension
names
then? That's it????

Jeff

On Fri, Jun 23, 2017 at 1:46 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:

> Using the original indices works too:
>
> met-5.2/bin/plot_data_plane \
> fcst_neighborhood_precip_20170501f01_mod.nc plot.ps \
> 'name="forecast_probability"; level="(0,0,*,*)";'
>
> All I did was switch the name of the dimensions from "latitude" and
> "longitude" to "lat" and "lon".
>
> This is the error that shows up when using the "latitude" and
"longitude"
> dimensions:
> ERROR  : MetNcFile::data(NcVar *, const LongArray &, DataPlane &)
const ->
> star found in bad slot
>
> John
>
> On Fri, Jun 23, 2017 at 12:36 PM, Jeff Duda via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> >
> > Okay, all you changed there was the index values. In my original
email
> the
> > indices were (0,0,*,*), and that didn't work. Now using (0,1,*,*)
it does
> > work. Why does the latter work but the former doesn't?
> >
> > Jeff
> >
> > On Fri, Jun 23, 2017 at 12:47 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Jeff,
> > >
> > > I should have asked the version you were using in the beginning!
I
> > posted
> > > a bugfix for 6.0, not 5.2.
> > >
> > > In fact, going back and testing with 5.2, it works fine!  The
bug was
> > > introduced in version 6.0 (and patched by the bugfix I posted).
> > >
> > > Here's the 5.2 plot_data_plane command I ran after changing the
> dimension
> > > names to lat and lon:
> > >
> > > met-5.2/bin/plot_data_plane \
> > > fcst_neighborhood_precip_20170501f01_mod.nc plot.ps \
> > > 'name="forecast_probability"; level="(0,1,*,*)";'
> > >
> > > Since your 5.2 build is now in a broken state, I'd suggest
asking your
> > sys
> > > admin to download MET 5.2 from scratch and then apply the latest
set of
> > 5.2
> > > patches.
> > >
> > > Or you could take this opportunity to switch to 6.0.  But
unfortunately
> > the
> > > compilation environment has changed a lot with the switch from
NetCDF3
> to
> > > NetCDF4.
> > >
> > > Sorry for all the confusion.
> > >
> > > John
> > >
> > > On Thu, Jun 22, 2017 at 3:20 PM, Jeff Duda via RT
<met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859
>
> > > >
> > > > John,
> > > > My local IT sysadmin sent me this email about the issue:
> > > >
> > > > The change you specified:
> > > >
> > > > The file is src/libcode/vx_data2d_nc_met/met_file.cc. The code
to
> fix
> > > > (look
> > > > around line 168) is
> > > >
> > > > OLD:  for (j=0; j<Ndims; ++j)  {
> > > > NEW: for (j=0; j<gDimNames.n_elements(); ++j) {
> > > >
> > > >
> > > >
> > > > is not compiling because there is no definition of gDimNames.
> > > >
> > > >
> > > >
> > > > The exact error is:
> > > >
> > > > met_file.cc(173): error: identifier "gDimNames" is undefined
> > > >
> > > >   for (j=0; j<gDimNames.n_elements(); ++j)  {
> > > >
> > > >
> > > > Can you suggest a solution? This is MET v 5.2.
> > > >
> > > >
> > > > Jeff
> > > >
> > > >
> > > > On Fri, Jun 16, 2017 at 3:12 PM, John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > > 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
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > 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 23 13:46:09 2017

Yes, that's right.  The dimensions should be named "lat" and "lon"...
which
is a rather silly requirement anyway.

The real confusion here is that I was testing using met-6.0 which
included
a problematic bug.

But that bug does not exist in met-5.2.

John

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

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
>
> ohhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
>
> I thought the problem was with the index settings I was using...
>
> So the real limitation here was that I was using the wrong dimension
names
> then? That's it????
>
> Jeff
>
> On Fri, Jun 23, 2017 at 1:46 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Using the original indices works too:
> >
> > met-5.2/bin/plot_data_plane \
> > fcst_neighborhood_precip_20170501f01_mod.nc plot.ps \
> > 'name="forecast_probability"; level="(0,0,*,*)";'
> >
> > All I did was switch the name of the dimensions from "latitude"
and
> > "longitude" to "lat" and "lon".
> >
> > This is the error that shows up when using the "latitude" and
"longitude"
> > dimensions:
> > ERROR  : MetNcFile::data(NcVar *, const LongArray &, DataPlane &)
const
> ->
> > star found in bad slot
> >
> > John
> >
> > On Fri, Jun 23, 2017 at 12:36 PM, Jeff Duda via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> > >
> > > Okay, all you changed there was the index values. In my original
email
> > the
> > > indices were (0,0,*,*), and that didn't work. Now using
(0,1,*,*) it
> does
> > > work. Why does the latter work but the former doesn't?
> > >
> > > Jeff
> > >
> > > On Fri, Jun 23, 2017 at 12:47 PM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > > Jeff,
> > > >
> > > > I should have asked the version you were using in the
beginning!  I
> > > posted
> > > > a bugfix for 6.0, not 5.2.
> > > >
> > > > In fact, going back and testing with 5.2, it works fine!  The
bug was
> > > > introduced in version 6.0 (and patched by the bugfix I
posted).
> > > >
> > > > Here's the 5.2 plot_data_plane command I ran after changing
the
> > dimension
> > > > names to lat and lon:
> > > >
> > > > met-5.2/bin/plot_data_plane \
> > > > fcst_neighborhood_precip_20170501f01_mod.nc plot.ps \
> > > > 'name="forecast_probability"; level="(0,1,*,*)";'
> > > >
> > > > Since your 5.2 build is now in a broken state, I'd suggest
asking
> your
> > > sys
> > > > admin to download MET 5.2 from scratch and then apply the
latest set
> of
> > > 5.2
> > > > patches.
> > > >
> > > > Or you could take this opportunity to switch to 6.0.  But
> unfortunately
> > > the
> > > > compilation environment has changed a lot with the switch from
> NetCDF3
> > to
> > > > NetCDF4.
> > > >
> > > > Sorry for all the confusion.
> > > >
> > > > John
> > > >
> > > > On Thu, Jun 22, 2017 at 3:20 PM, Jeff Duda via RT
<met_help at ucar.edu
> >
> > > > wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> > > > >
> > > > > John,
> > > > > My local IT sysadmin sent me this email about the issue:
> > > > >
> > > > > The change you specified:
> > > > >
> > > > > The file is src/libcode/vx_data2d_nc_met/met_file.cc. The
code to
> > fix
> > > > > (look
> > > > > around line 168) is
> > > > >
> > > > > OLD:  for (j=0; j<Ndims; ++j)  {
> > > > > NEW: for (j=0; j<gDimNames.n_elements(); ++j) {
> > > > >
> > > > >
> > > > >
> > > > > is not compiling because there is no definition of
gDimNames.
> > > > >
> > > > >
> > > > >
> > > > > The exact error is:
> > > > >
> > > > > met_file.cc(173): error: identifier "gDimNames" is undefined
> > > > >
> > > > >   for (j=0; j<gDimNames.n_elements(); ++j)  {
> > > > >
> > > > >
> > > > > Can you suggest a solution? This is MET v 5.2.
> > > > >
> > > > >
> > > > > Jeff
> > > > >
> > > > >
> > > > > On Fri, Jun 16, 2017 at 3:12 PM, John Halley Gotway via RT <
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > > > 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
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 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 23 13:53:39 2017

Okay, well then this ticket is completed. Thanks for your help!

Jeff

On Fri, Jun 23, 2017 at 2:46 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:

> Yes, that's right.  The dimensions should be named "lat" and
"lon"... which
> is a rather silly requirement anyway.
>
> The real confusion here is that I was testing using met-6.0 which
included
> a problematic bug.
>
> But that bug does not exist in met-5.2.
>
> John
>
> On Fri, Jun 23, 2017 at 1:41 PM, Jeff Duda via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> >
> > ohhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
> >
> > I thought the problem was with the index settings I was using...
> >
> > So the real limitation here was that I was using the wrong
dimension
> names
> > then? That's it????
> >
> > Jeff
> >
> > On Fri, Jun 23, 2017 at 1:46 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Using the original indices works too:
> > >
> > > met-5.2/bin/plot_data_plane \
> > > fcst_neighborhood_precip_20170501f01_mod.nc plot.ps \
> > > 'name="forecast_probability"; level="(0,0,*,*)";'
> > >
> > > All I did was switch the name of the dimensions from "latitude"
and
> > > "longitude" to "lat" and "lon".
> > >
> > > This is the error that shows up when using the "latitude" and
> "longitude"
> > > dimensions:
> > > ERROR  : MetNcFile::data(NcVar *, const LongArray &, DataPlane
&) const
> > ->
> > > star found in bad slot
> > >
> > > John
> > >
> > > On Fri, Jun 23, 2017 at 12:36 PM, Jeff Duda via RT
<met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859
>
> > > >
> > > > Okay, all you changed there was the index values. In my
original
> email
> > > the
> > > > indices were (0,0,*,*), and that didn't work. Now using
(0,1,*,*) it
> > does
> > > > work. Why does the latter work but the former doesn't?
> > > >
> > > > Jeff
> > > >
> > > > On Fri, Jun 23, 2017 at 12:47 PM, John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > > Jeff,
> > > > >
> > > > > I should have asked the version you were using in the
beginning!  I
> > > > posted
> > > > > a bugfix for 6.0, not 5.2.
> > > > >
> > > > > In fact, going back and testing with 5.2, it works fine!
The bug
> was
> > > > > introduced in version 6.0 (and patched by the bugfix I
posted).
> > > > >
> > > > > Here's the 5.2 plot_data_plane command I ran after changing
the
> > > dimension
> > > > > names to lat and lon:
> > > > >
> > > > > met-5.2/bin/plot_data_plane \
> > > > > fcst_neighborhood_precip_20170501f01_mod.nc plot.ps \
> > > > > 'name="forecast_probability"; level="(0,1,*,*)";'
> > > > >
> > > > > Since your 5.2 build is now in a broken state, I'd suggest
asking
> > your
> > > > sys
> > > > > admin to download MET 5.2 from scratch and then apply the
latest
> set
> > of
> > > > 5.2
> > > > > patches.
> > > > >
> > > > > Or you could take this opportunity to switch to 6.0.  But
> > unfortunately
> > > > the
> > > > > compilation environment has changed a lot with the switch
from
> > NetCDF3
> > > to
> > > > > NetCDF4.
> > > > >
> > > > > Sorry for all the confusion.
> > > > >
> > > > > John
> > > > >
> > > > > On Thu, Jun 22, 2017 at 3:20 PM, Jeff Duda via RT <
> met_help at ucar.edu
> > >
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> > > > > >
> > > > > > John,
> > > > > > My local IT sysadmin sent me this email about the issue:
> > > > > >
> > > > > > The change you specified:
> > > > > >
> > > > > > The file is src/libcode/vx_data2d_nc_met/met_file.cc. The
code
> to
> > > fix
> > > > > > (look
> > > > > > around line 168) is
> > > > > >
> > > > > > OLD:  for (j=0; j<Ndims; ++j)  {
> > > > > > NEW: for (j=0; j<gDimNames.n_elements(); ++j) {
> > > > > >
> > > > > >
> > > > > >
> > > > > > is not compiling because there is no definition of
gDimNames.
> > > > > >
> > > > > >
> > > > > >
> > > > > > The exact error is:
> > > > > >
> > > > > > met_file.cc(173): error: identifier "gDimNames" is
undefined
> > > > > >
> > > > > >   for (j=0; j<gDimNames.n_elements(); ++j)  {
> > > > > >
> > > > > >
> > > > > > Can you suggest a solution? This is MET v 5.2.
> > > > > >
> > > > > >
> > > > > > Jeff
> > > > > >
> > > > > >
> > > > > > On Fri, Jun 16, 2017 at 3:12 PM, John Halley Gotway via RT
<
> > > > > > met_help at ucar.edu> wrote:
> > > > > >
> > > > > > > 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
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 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: Tue Jun 27 15:11:47 2017

John,
I know our help ticket has been closed, but I have one last question
that
is more generic (not specifically MET related).

You said I should add certain timing attributes to my input files so
that
MODE would know the timing in the files. Well I did that except for
one set:

-a init_time_ut,forecast_probability,o,c,"1493596800" \
-a valid_time_ut,forecast_probability,o,c,"1493600400"

I assume the value here is UNIX epoch time. Is there a FORTRAN or UNIX
routine that can compute that for certain inputs? MODE seems to care
more
about this particular attribute than any other attributes, as the
output
file names didn't change much when i added all the other attributes
EXCEPT
for the above ones.

mode_ens_NP_precip_s10_t001_000000L_19700101_000000V_010000A_R1_T2.ps

The date string should say something more like 20170501_220000V
instead of
what it says...

Jeff

On Fri, Jun 23, 2017 at 2:53 PM, Jeff Duda <jeffduda319 at gmail.com>
wrote:

> Okay, well then this ticket is completed. Thanks for your help!
>
> Jeff
>
> On Fri, Jun 23, 2017 at 2:46 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Yes, that's right.  The dimensions should be named "lat" and
"lon"...
>> which
>> is a rather silly requirement anyway.
>>
>> The real confusion here is that I was testing using met-6.0 which
included
>> a problematic bug.
>>
>> But that bug does not exist in met-5.2.
>>
>> John
>>
>> On Fri, Jun 23, 2017 at 1:41 PM, Jeff Duda via RT
<met_help at ucar.edu>
>> wrote:
>>
>> >
>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
>> >
>> > ohhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
>> >
>> > I thought the problem was with the index settings I was using...
>> >
>> > So the real limitation here was that I was using the wrong
dimension
>> names
>> > then? That's it????
>> >
>> > Jeff
>> >
>> > On Fri, Jun 23, 2017 at 1:46 PM, John Halley Gotway via RT <
>> > met_help at ucar.edu> wrote:
>> >
>> > > Using the original indices works too:
>> > >
>> > > met-5.2/bin/plot_data_plane \
>> > > fcst_neighborhood_precip_20170501f01_mod.nc plot.ps \
>> > > 'name="forecast_probability"; level="(0,0,*,*)";'
>> > >
>> > > All I did was switch the name of the dimensions from "latitude"
and
>> > > "longitude" to "lat" and "lon".
>> > >
>> > > This is the error that shows up when using the "latitude" and
>> "longitude"
>> > > dimensions:
>> > > ERROR  : MetNcFile::data(NcVar *, const LongArray &, DataPlane
&)
>> const
>> > ->
>> > > star found in bad slot
>> > >
>> > > John
>> > >
>> > > On Fri, Jun 23, 2017 at 12:36 PM, Jeff Duda via RT
<met_help at ucar.edu
>> >
>> > > wrote:
>> > >
>> > > >
>> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859
>
>> > > >
>> > > > Okay, all you changed there was the index values. In my
original
>> email
>> > > the
>> > > > indices were (0,0,*,*), and that didn't work. Now using
(0,1,*,*) it
>> > does
>> > > > work. Why does the latter work but the former doesn't?
>> > > >
>> > > > Jeff
>> > > >
>> > > > On Fri, Jun 23, 2017 at 12:47 PM, John Halley Gotway via RT <
>> > > > met_help at ucar.edu> wrote:
>> > > >
>> > > > > Jeff,
>> > > > >
>> > > > > I should have asked the version you were using in the
beginning!
>> I
>> > > > posted
>> > > > > a bugfix for 6.0, not 5.2.
>> > > > >
>> > > > > In fact, going back and testing with 5.2, it works fine!
The bug
>> was
>> > > > > introduced in version 6.0 (and patched by the bugfix I
posted).
>> > > > >
>> > > > > Here's the 5.2 plot_data_plane command I ran after changing
the
>> > > dimension
>> > > > > names to lat and lon:
>> > > > >
>> > > > > met-5.2/bin/plot_data_plane \
>> > > > > fcst_neighborhood_precip_20170501f01_mod.nc plot.ps \
>> > > > > 'name="forecast_probability"; level="(0,1,*,*)";'
>> > > > >
>> > > > > Since your 5.2 build is now in a broken state, I'd suggest
asking
>> > your
>> > > > sys
>> > > > > admin to download MET 5.2 from scratch and then apply the
latest
>> set
>> > of
>> > > > 5.2
>> > > > > patches.
>> > > > >
>> > > > > Or you could take this opportunity to switch to 6.0.  But
>> > unfortunately
>> > > > the
>> > > > > compilation environment has changed a lot with the switch
from
>> > NetCDF3
>> > > to
>> > > > > NetCDF4.
>> > > > >
>> > > > > Sorry for all the confusion.
>> > > > >
>> > > > > John
>> > > > >
>> > > > > On Thu, Jun 22, 2017 at 3:20 PM, Jeff Duda via RT <
>> met_help at ucar.edu
>> > >
>> > > > > wrote:
>> > > > >
>> > > > > >
>> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
>> > > > > >
>> > > > > > John,
>> > > > > > My local IT sysadmin sent me this email about the issue:
>> > > > > >
>> > > > > > The change you specified:
>> > > > > >
>> > > > > > The file is src/libcode/vx_data2d_nc_met/met_file.cc. The
code
>> to
>> > > fix
>> > > > > > (look
>> > > > > > around line 168) is
>> > > > > >
>> > > > > > OLD:  for (j=0; j<Ndims; ++j)  {
>> > > > > > NEW: for (j=0; j<gDimNames.n_elements(); ++j) {
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > is not compiling because there is no definition of
gDimNames.
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > The exact error is:
>> > > > > >
>> > > > > > met_file.cc(173): error: identifier "gDimNames" is
undefined
>> > > > > >
>> > > > > >   for (j=0; j<gDimNames.n_elements(); ++j)  {
>> > > > > >
>> > > > > >
>> > > > > > Can you suggest a solution? This is MET v 5.2.
>> > > > > >
>> > > > > >
>> > > > > > Jeff
>> > > > > >
>> > > > > >
>> > > > > > On Fri, Jun 16, 2017 at 3:12 PM, John Halley Gotway via
RT <
>> > > > > > met_help at ucar.edu> wrote:
>> > > > > >
>> > > > > > > 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/Tic
>> ket/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_probab
>> ility,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/neig
>> hborhood_fcsts/precip/
>> > > > > > > > > > > > fcst_neighborhood_precip_20170501f01.nc ....
>> > > > > > > > > > > > DEBUG 1: Opening data file:
>> > > > > > > > > > > > /condo/map/jdduda/HWT2017/neig
>> hborhood_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/neig
>> hborhood_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_s
>> cale,
>> > > > > > 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/neig
>> hborhood_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
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > 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: Tue Jun 27 15:39:55 2017

Jeff,

Yes, you're right.  MET (including the MODE tool) actually keys off of
the
init_time_ut, valid_time_ut, and accum_time_sec attributes.

I wish we had made the code smarter so that if those were missing,
it'd
check for init_time, valid_time, and accum_time instead and just parse
those time for you!

But for now, they're required.

When writing scripts, the "date" command is very useful for formatting
time, including unixtime.  If you have a timestring, you can convert
it to
unixtime using the "%s" formatting option:

   date -ud ' '2017-05-01' UTC '22:00:00' ' +%s

Alternatively, you can pass unixtime to date, and format it however
you'd
like:

   date -ud '1970-01-01 UTC '1493676000' seconds' +%Y%m%d_%H%M%S

Unfortunately, I can't advise on the best way of doing these
conversions in
Fortran.

Hope that helps.

Thanks,
John

On Tue, Jun 27, 2017 at 3:11 PM, Jeff Duda via RT <met_help at ucar.edu>
wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
>
> John,
> I know our help ticket has been closed, but I have one last question
that
> is more generic (not specifically MET related).
>
> You said I should add certain timing attributes to my input files so
that
> MODE would know the timing in the files. Well I did that except for
one
> set:
>
> -a init_time_ut,forecast_probability,o,c,"1493596800" \
> -a valid_time_ut,forecast_probability,o,c,"1493600400"
>
> I assume the value here is UNIX epoch time. Is there a FORTRAN or
UNIX
> routine that can compute that for certain inputs? MODE seems to care
more
> about this particular attribute than any other attributes, as the
output
> file names didn't change much when i added all the other attributes
EXCEPT
> for the above ones.
>
>
mode_ens_NP_precip_s10_t001_000000L_19700101_000000V_010000A_R1_T2.ps
>
> The date string should say something more like 20170501_220000V
instead of
> what it says...
>
> Jeff
>
> On Fri, Jun 23, 2017 at 2:53 PM, Jeff Duda <jeffduda319 at gmail.com>
wrote:
>
> > Okay, well then this ticket is completed. Thanks for your help!
> >
> > Jeff
> >
> > On Fri, Jun 23, 2017 at 2:46 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> >> Yes, that's right.  The dimensions should be named "lat" and
"lon"...
> >> which
> >> is a rather silly requirement anyway.
> >>
> >> The real confusion here is that I was testing using met-6.0 which
> included
> >> a problematic bug.
> >>
> >> But that bug does not exist in met-5.2.
> >>
> >> John
> >>
> >> On Fri, Jun 23, 2017 at 1:41 PM, Jeff Duda via RT
<met_help at ucar.edu>
> >> wrote:
> >>
> >> >
> >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> >> >
> >> > ohhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
> >> >
> >> > I thought the problem was with the index settings I was
using...
> >> >
> >> > So the real limitation here was that I was using the wrong
dimension
> >> names
> >> > then? That's it????
> >> >
> >> > Jeff
> >> >
> >> > On Fri, Jun 23, 2017 at 1:46 PM, John Halley Gotway via RT <
> >> > met_help at ucar.edu> wrote:
> >> >
> >> > > Using the original indices works too:
> >> > >
> >> > > met-5.2/bin/plot_data_plane \
> >> > > fcst_neighborhood_precip_20170501f01_mod.nc plot.ps \
> >> > > 'name="forecast_probability"; level="(0,0,*,*)";'
> >> > >
> >> > > All I did was switch the name of the dimensions from
"latitude" and
> >> > > "longitude" to "lat" and "lon".
> >> > >
> >> > > This is the error that shows up when using the "latitude" and
> >> "longitude"
> >> > > dimensions:
> >> > > ERROR  : MetNcFile::data(NcVar *, const LongArray &,
DataPlane &)
> >> const
> >> > ->
> >> > > star found in bad slot
> >> > >
> >> > > John
> >> > >
> >> > > On Fri, Jun 23, 2017 at 12:36 PM, Jeff Duda via RT <
> met_help at ucar.edu
> >> >
> >> > > wrote:
> >> > >
> >> > > >
> >> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
> >> > > >
> >> > > > Okay, all you changed there was the index values. In my
original
> >> email
> >> > > the
> >> > > > indices were (0,0,*,*), and that didn't work. Now using
(0,1,*,*)
> it
> >> > does
> >> > > > work. Why does the latter work but the former doesn't?
> >> > > >
> >> > > > Jeff
> >> > > >
> >> > > > On Fri, Jun 23, 2017 at 12:47 PM, John Halley Gotway via RT
<
> >> > > > met_help at ucar.edu> wrote:
> >> > > >
> >> > > > > Jeff,
> >> > > > >
> >> > > > > I should have asked the version you were using in the
beginning!
> >> I
> >> > > > posted
> >> > > > > a bugfix for 6.0, not 5.2.
> >> > > > >
> >> > > > > In fact, going back and testing with 5.2, it works fine!
The
> bug
> >> was
> >> > > > > introduced in version 6.0 (and patched by the bugfix I
posted).
> >> > > > >
> >> > > > > Here's the 5.2 plot_data_plane command I ran after
changing the
> >> > > dimension
> >> > > > > names to lat and lon:
> >> > > > >
> >> > > > > met-5.2/bin/plot_data_plane \
> >> > > > > fcst_neighborhood_precip_20170501f01_mod.nc plot.ps \
> >> > > > > 'name="forecast_probability"; level="(0,1,*,*)";'
> >> > > > >
> >> > > > > Since your 5.2 build is now in a broken state, I'd
suggest
> asking
> >> > your
> >> > > > sys
> >> > > > > admin to download MET 5.2 from scratch and then apply the
latest
> >> set
> >> > of
> >> > > > 5.2
> >> > > > > patches.
> >> > > > >
> >> > > > > Or you could take this opportunity to switch to 6.0.  But
> >> > unfortunately
> >> > > > the
> >> > > > > compilation environment has changed a lot with the switch
from
> >> > NetCDF3
> >> > > to
> >> > > > > NetCDF4.
> >> > > > >
> >> > > > > Sorry for all the confusion.
> >> > > > >
> >> > > > > John
> >> > > > >
> >> > > > > On Thu, Jun 22, 2017 at 3:20 PM, Jeff Duda via RT <
> >> met_help at ucar.edu
> >> > >
> >> > > > > wrote:
> >> > > > >
> >> > > > > >
> >> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859
> >
> >> > > > > >
> >> > > > > > John,
> >> > > > > > My local IT sysadmin sent me this email about the
issue:
> >> > > > > >
> >> > > > > > The change you specified:
> >> > > > > >
> >> > > > > > The file is src/libcode/vx_data2d_nc_met/met_file.cc.
The
> code
> >> to
> >> > > fix
> >> > > > > > (look
> >> > > > > > around line 168) is
> >> > > > > >
> >> > > > > > OLD:  for (j=0; j<Ndims; ++j)  {
> >> > > > > > NEW: for (j=0; j<gDimNames.n_elements(); ++j) {
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > is not compiling because there is no definition of
gDimNames.
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > The exact error is:
> >> > > > > >
> >> > > > > > met_file.cc(173): error: identifier "gDimNames" is
undefined
> >> > > > > >
> >> > > > > >   for (j=0; j<gDimNames.n_elements(); ++j)  {
> >> > > > > >
> >> > > > > >
> >> > > > > > Can you suggest a solution? This is MET v 5.2.
> >> > > > > >
> >> > > > > >
> >> > > > > > Jeff
> >> > > > > >
> >> > > > > >
> >> > > > > > On Fri, Jun 16, 2017 at 3:12 PM, John Halley Gotway via
RT <
> >> > > > > > met_help at ucar.edu> wrote:
> >> > > > > >
> >> > > > > > > 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/Tic
> >> ket/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_probab
> >> ility,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/neig
> >> hborhood_fcsts/precip/
> >> > > > > > > > > > > > fcst_neighborhood_precip_20170501f01.nc
....
> >> > > > > > > > > > > > DEBUG 1: Opening data file:
> >> > > > > > > > > > > > /condo/map/jdduda/HWT2017/neig
> >> hborhood_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/neig
> >> hborhood_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_s
> >> cale,
> >> > > > > > 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/neig
> >> hborhood_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
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > --
> >> > > > > > 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: Tue Jun 27 15:45:50 2017

Jeff,

Not sure if this helps solve your problem or not, but I've attached a
korn
shell script I wrote along the way called list_valid.ksh.

I find it pretty useful for building a list of dates.  And then you
can
string in along with calls to sed and awk to build up filenames.  Or
use
the "-fmt" option to create the filename as well.

       Usage: ./list_valid.ksh beg end inc [-fmt str]
          where "beg" and "end" are times in YYYYMMDD_[HH[MM[SS]]]
format
                "inc" is in HH[MM[SS]] format
                "-fmt str" specifies the output time format

Here's how you can run it:

./list_valid.ksh 20150605 20150610 24

... or use the -fmt option to define some fancy formatting...

./list_valid.ksh 20150605 20150610 24 -fmt %Y%m%d_in_unixtime_is_%s

John

On Tue, Jun 27, 2017 at 3:39 PM, John Halley Gotway <johnhg at ucar.edu>
wrote:

> Jeff,
>
> Yes, you're right.  MET (including the MODE tool) actually keys off
of the
> init_time_ut, valid_time_ut, and accum_time_sec attributes.
>
> I wish we had made the code smarter so that if those were missing,
it'd
> check for init_time, valid_time, and accum_time instead and just
parse
> those time for you!
>
> But for now, they're required.
>
> When writing scripts, the "date" command is very useful for
formatting
> time, including unixtime.  If you have a timestring, you can convert
it to
> unixtime using the "%s" formatting option:
>
>    date -ud ' '2017-05-01' UTC '22:00:00' ' +%s
>
> Alternatively, you can pass unixtime to date, and format it however
you'd
> like:
>
>    date -ud '1970-01-01 UTC '1493676000' seconds' +%Y%m%d_%H%M%S
>
> Unfortunately, I can't advise on the best way of doing these
conversions
> in Fortran.
>
> Hope that helps.
>
> Thanks,
> John
>
>
> On Tue, Jun 27, 2017 at 3:11 PM, Jeff Duda via RT
<met_help at ucar.edu>
> wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
>>
>> John,
>> I know our help ticket has been closed, but I have one last
question that
>> is more generic (not specifically MET related).
>>
>> You said I should add certain timing attributes to my input files
so that
>> MODE would know the timing in the files. Well I did that except for
one
>> set:
>>
>> -a init_time_ut,forecast_probability,o,c,"1493596800" \
>> -a valid_time_ut,forecast_probability,o,c,"1493600400"
>>
>> I assume the value here is UNIX epoch time. Is there a FORTRAN or
UNIX
>> routine that can compute that for certain inputs? MODE seems to
care more
>> about this particular attribute than any other attributes, as the
output
>> file names didn't change much when i added all the other attributes
EXCEPT
>> for the above ones.
>>
>>
mode_ens_NP_precip_s10_t001_000000L_19700101_000000V_010000A_R1_T2.ps
>>
>> The date string should say something more like 20170501_220000V
instead of
>> what it says...
>>
>> Jeff
>>
>> On Fri, Jun 23, 2017 at 2:53 PM, Jeff Duda <jeffduda319 at gmail.com>
wrote:
>>
>> > Okay, well then this ticket is completed. Thanks for your help!
>> >
>> > Jeff
>> >
>> > On Fri, Jun 23, 2017 at 2:46 PM, John Halley Gotway via RT <
>> > met_help at ucar.edu> wrote:
>> >
>> >> Yes, that's right.  The dimensions should be named "lat" and
"lon"...
>> >> which
>> >> is a rather silly requirement anyway.
>> >>
>> >> The real confusion here is that I was testing using met-6.0
which
>> included
>> >> a problematic bug.
>> >>
>> >> But that bug does not exist in met-5.2.
>> >>
>> >> John
>> >>
>> >> On Fri, Jun 23, 2017 at 1:41 PM, Jeff Duda via RT
<met_help at ucar.edu>
>> >> wrote:
>> >>
>> >> >
>> >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859
>
>> >> >
>> >> > ohhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
>> >> >
>> >> > I thought the problem was with the index settings I was
using...
>> >> >
>> >> > So the real limitation here was that I was using the wrong
dimension
>> >> names
>> >> > then? That's it????
>> >> >
>> >> > Jeff
>> >> >
>> >> > On Fri, Jun 23, 2017 at 1:46 PM, John Halley Gotway via RT <
>> >> > met_help at ucar.edu> wrote:
>> >> >
>> >> > > Using the original indices works too:
>> >> > >
>> >> > > met-5.2/bin/plot_data_plane \
>> >> > > fcst_neighborhood_precip_20170501f01_mod.nc plot.ps \
>> >> > > 'name="forecast_probability"; level="(0,0,*,*)";'
>> >> > >
>> >> > > All I did was switch the name of the dimensions from
"latitude" and
>> >> > > "longitude" to "lat" and "lon".
>> >> > >
>> >> > > This is the error that shows up when using the "latitude"
and
>> >> "longitude"
>> >> > > dimensions:
>> >> > > ERROR  : MetNcFile::data(NcVar *, const LongArray &,
DataPlane &)
>> >> const
>> >> > ->
>> >> > > star found in bad slot
>> >> > >
>> >> > > John
>> >> > >
>> >> > > On Fri, Jun 23, 2017 at 12:36 PM, Jeff Duda via RT <
>> met_help at ucar.edu
>> >> >
>> >> > > wrote:
>> >> > >
>> >> > > >
>> >> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80859 >
>> >> > > >
>> >> > > > Okay, all you changed there was the index values. In my
original
>> >> email
>> >> > > the
>> >> > > > indices were (0,0,*,*), and that didn't work. Now using
>> (0,1,*,*) it
>> >> > does
>> >> > > > work. Why does the latter work but the former doesn't?
>> >> > > >
>> >> > > > Jeff
>> >> > > >
>> >> > > > On Fri, Jun 23, 2017 at 12:47 PM, John Halley Gotway via
RT <
>> >> > > > met_help at ucar.edu> wrote:
>> >> > > >
>> >> > > > > Jeff,
>> >> > > > >
>> >> > > > > I should have asked the version you were using in the
>> beginning!
>> >> I
>> >> > > > posted
>> >> > > > > a bugfix for 6.0, not 5.2.
>> >> > > > >
>> >> > > > > In fact, going back and testing with 5.2, it works fine!
The
>> bug
>> >> was
>> >> > > > > introduced in version 6.0 (and patched by the bugfix I
posted).
>> >> > > > >
>> >> > > > > Here's the 5.2 plot_data_plane command I ran after
changing the
>> >> > > dimension
>> >> > > > > names to lat and lon:
>> >> > > > >
>> >> > > > > met-5.2/bin/plot_data_plane \
>> >> > > > > fcst_neighborhood_precip_20170501f01_mod.nc plot.ps \
>> >> > > > > 'name="forecast_probability"; level="(0,1,*,*)";'
>> >> > > > >
>> >> > > > > Since your 5.2 build is now in a broken state, I'd
suggest
>> asking
>> >> > your
>> >> > > > sys
>> >> > > > > admin to download MET 5.2 from scratch and then apply
the
>> latest
>> >> set
>> >> > of
>> >> > > > 5.2
>> >> > > > > patches.
>> >> > > > >
>> >> > > > > Or you could take this opportunity to switch to 6.0.
But
>> >> > unfortunately
>> >> > > > the
>> >> > > > > compilation environment has changed a lot with the
switch from
>> >> > NetCDF3
>> >> > > to
>> >> > > > > NetCDF4.
>> >> > > > >
>> >> > > > > Sorry for all the confusion.
>> >> > > > >
>> >> > > > > John
>> >> > > > >
>> >> > > > > On Thu, Jun 22, 2017 at 3:20 PM, Jeff Duda via RT <
>> >> met_help at ucar.edu
>> >> > >
>> >> > > > > wrote:
>> >> > > > >
>> >> > > > > >
>> >> > > > > > <URL: https://rt.rap.ucar.edu/rt/Tic
>> ket/Display.html?id=80859 >
>> >> > > > > >
>> >> > > > > > John,
>> >> > > > > > My local IT sysadmin sent me this email about the
issue:
>> >> > > > > >
>> >> > > > > > The change you specified:
>> >> > > > > >
>> >> > > > > > The file is src/libcode/vx_data2d_nc_met/met_file.cc.
The
>> code
>> >> to
>> >> > > fix
>> >> > > > > > (look
>> >> > > > > > around line 168) is
>> >> > > > > >
>> >> > > > > > OLD:  for (j=0; j<Ndims; ++j)  {
>> >> > > > > > NEW: for (j=0; j<gDimNames.n_elements(); ++j) {
>> >> > > > > >
>> >> > > > > >
>> >> > > > > >
>> >> > > > > > is not compiling because there is no definition of
gDimNames.
>> >> > > > > >
>> >> > > > > >
>> >> > > > > >
>> >> > > > > > The exact error is:
>> >> > > > > >
>> >> > > > > > met_file.cc(173): error: identifier "gDimNames" is
undefined
>> >> > > > > >
>> >> > > > > >   for (j=0; j<gDimNames.n_elements(); ++j)  {
>> >> > > > > >
>> >> > > > > >
>> >> > > > > > Can you suggest a solution? This is MET v 5.2.
>> >> > > > > >
>> >> > > > > >
>> >> > > > > > Jeff
>> >> > > > > >
>> >> > > > > >
>> >> > > > > > On Fri, Jun 16, 2017 at 3:12 PM, John Halley Gotway
via RT <
>> >> > > > > > met_help at ucar.edu> wrote:
>> >> > > > > >
>> >> > > > > > > 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/Tic
>> >> ket/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_probab
>> >> ility,o,l,3600
>> >> > \
>> >> > > > > > > > >             fcst_neighborhood_precip_2017
>> 0501f01_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/neig
>> >> hborhood_fcsts/precip/
>> >> > > > > > > > > > > > fcst_neighborhood_precip_20170501f01.nc
....
>> >> > > > > > > > > > > > DEBUG 1: Opening data file:
>> >> > > > > > > > > > > > /condo/map/jdduda/HWT2017/neig
>> >> hborhood_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/neig
>> >> hborhood_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_s
>> >> cale,
>> >> > > > > > 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/neig
>> >> hborhood_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
>> >> > > > > > > >
>> >> > > > > > > >
>> >> > > > > > >
>> >> > > > > > >
>> >> > > > > >
>> >> > > > > >
>> >> > > > > > --
>> >> > > > > > 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
>>
>>
>

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