[Met_help] [rt.rap.ucar.edu #95184] History for

John Halley Gotway via RT met_help at ucar.edu
Thu May 7 17:13:09 MDT 2020


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

Hello,

I'm trying to run plot_data_plane with a python embedding script on
eyewall. I'm getting the following error:

DataPlane::two_to_one() -> range check error: (Nx, Ny) = (360, 181), (x, y)
> = (0, 181)


I don't know what this means.
The command I'm running is:

/usr/local/met-9.0/bin/plot_data_plane PYTHON_NUMPY ivt_test.ps
'name="read_gefs.py
/d1/lblank/SBU/metplus_usecases/met9ivt/data/fv3/gfs.20160101/00/gfs.t00z.pgrb2.1p00.f024.reduced.grib2.npy";'

Best,
Lindsay

-- 

Lindsay R. Blank
Associate Scientist
Joint Numerical Testbed Program
National Center for Atmospheric Research
+1 (303)-497-2772

*My working day may not be your working day. Please do not feel obliged to
reply to this email outside of your normal working hours.*


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

Subject: 
From: Minna Win
Time: Wed May 06 17:45:45 2020

Hi Lindsay,

I'm assigning this issue to John Halley Gotway.

Regards,
Minna
---------------
Minna Win
National Center for Atmospheric Research
Developmental Testbed Center
Phone: 303-497-8423
Fax:   303-497-8401



On Wed, May 6, 2020 at 5:12 PM Lindsay Blank via RT
<met_help at ucar.edu>
wrote:

>
> Wed May 06 17:11:44 2020: Request 95184 was acted upon.
> Transaction: Ticket created by lblank at ucar.edu
>        Queue: met_help
>      Subject: (No subject given)
>        Owner: Nobody
>   Requestors: lblank at ucar.edu
>       Status: new
>  Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95184 >
>
>
> Hello,
>
> I'm trying to run plot_data_plane with a python embedding script on
> eyewall. I'm getting the following error:
>
> DataPlane::two_to_one() -> range check error: (Nx, Ny) = (360, 181),
(x, y)
> > = (0, 181)
>
>
> I don't know what this means.
> The command I'm running is:
>
> /usr/local/met-9.0/bin/plot_data_plane PYTHON_NUMPY ivt_test.ps
> 'name="read_gefs.py
>
>
/d1/lblank/SBU/metplus_usecases/met9ivt/data/fv3/gfs.20160101/00/gfs.t00z.pgrb2.1p00.f024.reduced.grib2.npy";'
>
> Best,
> Lindsay
>
> --
>
> Lindsay R. Blank
> Associate Scientist
> Joint Numerical Testbed Program
> National Center for Atmospheric Research
> +1 (303)-497-2772
>
> *My working day may not be your working day. Please do not feel
obliged to
> reply to this email outside of your normal working hours.*
>
>

------------------------------------------------
Subject: 
From: John Halley Gotway
Time: Thu May 07 11:01:38 2020

Lindsay,

OK, I was able to replicate this behavior by running on eyewall:

/usr/local/met-9.0/bin/plot_data_plane PYTHON_NUMPY ivt_test.ps
'name="/d1/lblank/SBU/metplus_usecases/met9ivt/read_gefs.py
/d1/lblank/SBU/metplus_usecases/met9ivt/data/fv3/gfs.20160101/00/gfs.t00z.pgrb2.1p00.f024.reduced.grib2.npy";'

ERROR  : DataPlane::two_to_one() -> range check error: (Nx, Ny) =
(360,
181), (x, y) = (0, 181)

This error means that we're attempting to access data for a grid point
beyond the bounds of the domain.  Since C++ is 0-based, when Ny = 181,
you
can access y values of 0 through 180, and not 181.  That's what the
error
message means.

And I suspect that is this caused by confusion between (lat, lon) and
(x,
y).  We often state things in this order, but really, (x, y)
corresponds to
(lon, lat), since the x-coordinate is longitude and the y-coordinate
is
latitude.

Looking in the python script, I see
(/d1/lblank/SBU/metplus_usecases/met9ivt/read_gefs.py) I see Nlat and
Nlon
defined as:
'Nlat' : 360,
'Nlon': 181

And that'd make the data twice as tall as it is wide.  To test I made
a
copy of your python script and change:
'Nlat' : 181,
'Nlon' : 360

And I attached the resulting image.  The next step is making sure that
this
data is oriented correctly.  It's very possible that it's upside-down,
backwards, or mirrored in some way, and you'd fix that in the python
script.

Thanks,
John


On Wed, May 6, 2020 at 5:47 PM Minna Win via RT <met_help at ucar.edu>
wrote:

>
> Wed May 06 17:46:27 2020: Request 95184 was acted upon.
> Transaction: Given to johnhg (John Halley Gotway) by minnawin
>        Queue: met_help
>      Subject: (No subject given)
>        Owner: johnhg
>   Requestors: lblank at ucar.edu
>       Status: open
>  Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95184 >
>
>
> This transaction appears to have no content
>

------------------------------------------------
Subject: 
From: Lindsay Blank
Time: Thu May 07 12:14:20 2020

Hi John,

Thanks for explaining and fixing this! This script was originally from
Taylor Mandelbaum at SBU, so I'll send the plot over to him and see if
it's
oriented correctly.

Thanks,
Lindsay

On Thu, May 7, 2020 at 11:06 AM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:

> Lindsay,
>
> OK, I was able to replicate this behavior by running on eyewall:
>
> /usr/local/met-9.0/bin/plot_data_plane PYTHON_NUMPY ivt_test.ps
> 'name="/d1/lblank/SBU/metplus_usecases/met9ivt/read_gefs.py
>
>
/d1/lblank/SBU/metplus_usecases/met9ivt/data/fv3/gfs.20160101/00/gfs.t00z.pgrb2.1p00.f024.reduced.grib2.npy";'
>
> ERROR  : DataPlane::two_to_one() -> range check error: (Nx, Ny) =
(360,
> 181), (x, y) = (0, 181)
>
> This error means that we're attempting to access data for a grid
point
> beyond the bounds of the domain.  Since C++ is 0-based, when Ny =
181, you
> can access y values of 0 through 180, and not 181.  That's what the
error
> message means.
>
> And I suspect that is this caused by confusion between (lat, lon)
and (x,
> y).  We often state things in this order, but really, (x, y)
corresponds to
> (lon, lat), since the x-coordinate is longitude and the y-coordinate
is
> latitude.
>
> Looking in the python script, I see
> (/d1/lblank/SBU/metplus_usecases/met9ivt/read_gefs.py) I see Nlat
and Nlon
> defined as:
> 'Nlat' : 360,
> 'Nlon': 181
>
> And that'd make the data twice as tall as it is wide.  To test I
made a
> copy of your python script and change:
> 'Nlat' : 181,
> 'Nlon' : 360
>
> And I attached the resulting image.  The next step is making sure
that this
> data is oriented correctly.  It's very possible that it's upside-
down,
> backwards, or mirrored in some way, and you'd fix that in the python
> script.
>
> Thanks,
> John
>
>
> On Wed, May 6, 2020 at 5:47 PM Minna Win via RT <met_help at ucar.edu>
wrote:
>
> >
> > Wed May 06 17:46:27 2020: Request 95184 was acted upon.
> > Transaction: Given to johnhg (John Halley Gotway) by minnawin
> >        Queue: met_help
> >      Subject: (No subject given)
> >        Owner: johnhg
> >   Requestors: lblank at ucar.edu
> >       Status: open
> >  Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95184 >
> >
> >
> > This transaction appears to have no content
> >
>
>

--
Lindsay R. Blank
Associate Scientist
Joint Numerical Testbed Program
National Center for Atmospheric Research
+1 (303)-497-2772

*My working day may not be your working day. Please do not feel
obliged to
reply to this email outside of your normal working hours.*

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


More information about the Met_help mailing list