[Met_help] [rt.rap.ucar.edu #91053] History for Incorrect lat and lon data on objects
John Halley Gotway via RT
met_help at ucar.edu
Thu Jul 18 09:31:27 MDT 2019
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi,
I'm using Met 8.0 with the bug fixes to run MODE for two netCDF files.
MODE seems to run just fine, however the latitude and longitude of the
output is messed up. How can I fix the latitude and longitude? I've
uploaded the data and MODE output to the met_help ftp directory. Thanks!
Have a great day!
Sarah
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu
(608) 262-0986
----------------------------------------------------------------------------
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Incorrect lat and lon data on objects
From: David Fillmore
Time: Fri Jul 12 15:25:32 2019
On Fri Jul 12 14:56:24 2019, sarah.griffin at ssec.wisc.edu wrote:
> Hi,
>
> I'm using Met 8.0 with the bug fixes to run MODE for two netCDF
files.
> MODE seems to run just fine, however the latitude and longitude of
the
> output is messed up. How can I fix the latitude and longitude? I've
> uploaded the data and MODE output to the met_help ftp directory.
Thanks!
>
> Have a great day!
> Sarah
>
Hi Sarah -
Thanks for the data upload.
I've passed this ticket along to Randy, our resident MODE specialist.
He should get a change to look at this early next week.
David
------------------------------------------------
Subject: Incorrect lat and lon data on objects
From: John Halley Gotway
Time: Fri Jul 12 16:45:57 2019
Hi Sarah,
Thought I'd chime in here to mention the following. This is not
actually a
problem in MODE tool itself, but more of an issue in how MET is
reading
data your input files and placing them on the earth. I usually
recommend
that people run MET's plot_data_plane tool when working with a new
data
source to make sure MET is reading the data well:
*plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
<http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc> plot.ps
<http://plot.ps> 'name="channel_10_brightness_temperature";
level="(*,*)";'
-v 4*
This produces a nice looking plot, but there's no country outlines on
top
of the data! And that usually indicates a problem in the projection
information. But I did find one thing which seems to have helped. I
changed the longitude_of_central_meridian from 262.5 to -97.5, by
running
the following command:
*ncatted -a longitude_of_central_meridian,Projection,o,f,-97.5
remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
<http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc>
remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
<http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>*
Those two longitudes are the same since they differ by 360 degrees.
Surprisingly, running plot_data_plane on that modified file did plot
the
map data (see attached image):
*plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
<http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc> plot.ps
<http://plot.ps> 'name="channel_10_brightness_temperature";
level="(*,*)";'
-v 4*
Can you confirm that the data lives on the right place on the earth?
Should it be covering the Eastern CONUS and Atlantic? If so, then
we'll
likely need to make a one line fix in MET's library code to rescale
the
longitude values to the expected range of (-180, 180] when we read
them in.
Thanks,
John
On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> On Fri Jul 12 14:56:24 2019, sarah.griffin at ssec.wisc.edu wrote:
> > Hi,
> >
> > I'm using Met 8.0 with the bug fixes to run MODE for two netCDF
files.
> > MODE seems to run just fine, however the latitude and longitude of
the
> > output is messed up. How can I fix the latitude and longitude?
I've
> > uploaded the data and MODE output to the met_help ftp directory.
Thanks!
> >
> > Have a great day!
> > Sarah
> >
>
>
> Hi Sarah -
> Thanks for the data upload.
> I've passed this ticket along to Randy, our resident MODE
specialist.
> He should get a change to look at this early next week.
> David
>
------------------------------------------------
Subject: Incorrect lat and lon data on objects
From: John Halley Gotway
Time: Fri Jul 12 16:53:06 2019
Sarah,
I'm pretty sure that didn't fix it entirely. When I plot the channel
15
data with plot_data_plane, I clearly see the outline of FL and the
Eastern
seaboard in the data, but it doesn't line up with the map data. So
there's
clearly still a problem.
I see that you're using GOES-16 data here. MET's regrid_data_plane
tool
should be able to read GOES-16 data and regrid it to a user-defined
grid.
That would be another alternatively for using GOES-16 data in MET.
Thanks,
John
On Fri, Jul 12, 2019 at 4:45 PM John Halley Gotway <johnhg at ucar.edu>
wrote:
> Hi Sarah,
>
> Thought I'd chime in here to mention the following. This is not
actually
> a problem in MODE tool itself, but more of an issue in how MET is
reading
> data your input files and placing them on the earth. I usually
recommend
> that people run MET's plot_data_plane tool when working with a new
data
> source to make sure MET is reading the data well:
>
> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc> plot.ps
> <http://plot.ps> 'name="channel_10_brightness_temperature";
level="(*,*)";'
> -v 4*
>
> This produces a nice looking plot, but there's no country outlines
on top
> of the data! And that usually indicates a problem in the projection
> information. But I did find one thing which seems to have helped.
I
> changed the longitude_of_central_meridian from 262.5 to -97.5, by
running
> the following command:
>
> *ncatted -a longitude_of_central_meridian,Projection,o,f,-97.5
> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc>
> remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>*
>
> Those two longitudes are the same since they differ by 360 degrees.
> Surprisingly, running plot_data_plane on that modified file did plot
the
> map data (see attached image):
>
> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc> plot.ps
> <http://plot.ps> 'name="channel_10_brightness_temperature";
level="(*,*)";'
> -v 4*
>
> Can you confirm that the data lives on the right place on the earth?
> Should it be covering the Eastern CONUS and Atlantic? If so, then
we'll
> likely need to make a one line fix in MET's library code to rescale
the
> longitude values to the expected range of (-180, 180] when we read
them in.
>
> Thanks,
> John
>
> On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT
<met_help at ucar.edu>
> wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>
>> On Fri Jul 12 14:56:24 2019, sarah.griffin at ssec.wisc.edu wrote:
>> > Hi,
>> >
>> > I'm using Met 8.0 with the bug fixes to run MODE for two netCDF
files.
>> > MODE seems to run just fine, however the latitude and longitude
of the
>> > output is messed up. How can I fix the latitude and longitude?
I've
>> > uploaded the data and MODE output to the met_help ftp directory.
Thanks!
>> >
>> > Have a great day!
>> > Sarah
>> >
>>
>>
>> Hi Sarah -
>> Thanks for the data upload.
>> I've passed this ticket along to Randy, our resident MODE
specialist.
>> He should get a change to look at this early next week.
>> David
>>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #91053] Incorrect lat and lon data on objects
From: Sarah Griffin
Time: Mon Jul 15 08:55:50 2019
Hi John,
How does the regrid_data_plane tool work? Does it work with two netcdf
files? I've tried
bin/regrid_data_plane \
emap_geocatL1.GOES-16.CONUS.2018007.000230.nc \
Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_00_00.nc \
remap_geocatL1.GOES-16.CONUS.2018007.000230.nc_new \
field 'name = "channel_13_brightness_temperature"; level = "(*,*)";
file_type = NETCDF_MET;' \
-v 4
But the only output I am getting is the help page for
bin/regrid_data_plane.
What do I need to include in the "to_grid" file for MET to recognize
it?
Thanks!
Sarah
On 7/12/19 5:53 PM, John Halley Gotway via RT wrote:
> Sarah,
>
> I'm pretty sure that didn't fix it entirely. When I plot the
channel 15
> data with plot_data_plane, I clearly see the outline of FL and the
Eastern
> seaboard in the data, but it doesn't line up with the map data. So
there's
> clearly still a problem.
>
> I see that you're using GOES-16 data here. MET's regrid_data_plane
tool
> should be able to read GOES-16 data and regrid it to a user-defined
grid.
> That would be another alternatively for using GOES-16 data in MET.
>
> Thanks,
> John
>
> On Fri, Jul 12, 2019 at 4:45 PM John Halley Gotway <johnhg at ucar.edu>
wrote:
>
>> Hi Sarah,
>>
>> Thought I'd chime in here to mention the following. This is not
actually
>> a problem in MODE tool itself, but more of an issue in how MET is
reading
>> data your input files and placing them on the earth. I usually
recommend
>> that people run MET's plot_data_plane tool when working with a new
data
>> source to make sure MET is reading the data well:
>>
>> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc> plot.ps
>> <http://plot.ps> 'name="channel_10_brightness_temperature";
level="(*,*)";'
>> -v 4*
>>
>> This produces a nice looking plot, but there's no country outlines
on top
>> of the data! And that usually indicates a problem in the
projection
>> information. But I did find one thing which seems to have helped.
I
>> changed the longitude_of_central_meridian from 262.5 to -97.5, by
running
>> the following command:
>>
>> *ncatted -a longitude_of_central_meridian,Projection,o,f,-97.5
>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc>
>> remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>*
>>
>> Those two longitudes are the same since they differ by 360 degrees.
>> Surprisingly, running plot_data_plane on that modified file did
plot the
>> map data (see attached image):
>>
>> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc> plot.ps
>> <http://plot.ps> 'name="channel_10_brightness_temperature";
level="(*,*)";'
>> -v 4*
>>
>> Can you confirm that the data lives on the right place on the
earth?
>> Should it be covering the Eastern CONUS and Atlantic? If so, then
we'll
>> likely need to make a one line fix in MET's library code to rescale
the
>> longitude values to the expected range of (-180, 180] when we read
them in.
>>
>> Thanks,
>> John
>>
>> On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT
<met_help at ucar.edu>
>> wrote:
>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>>
>>> On Fri Jul 12 14:56:24 2019, sarah.griffin at ssec.wisc.edu wrote:
>>>> Hi,
>>>>
>>>> I'm using Met 8.0 with the bug fixes to run MODE for two netCDF
files.
>>>> MODE seems to run just fine, however the latitude and longitude
of the
>>>> output is messed up. How can I fix the latitude and longitude?
I've
>>>> uploaded the data and MODE output to the met_help ftp directory.
Thanks!
>>>>
>>>> Have a great day!
>>>> Sarah
>>>>
>>>
>>> Hi Sarah -
>>> Thanks for the data upload.
>>> I've passed this ticket along to Randy, our resident MODE
specialist.
>>> He should get a change to look at this early next week.
>>> David
>>>
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC UW-
Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu
(608) 262-0986
----------------------------------------------------------------------------
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #91053] Incorrect lat and lon data on objects
From: Sarah Griffin
Time: Mon Jul 15 09:28:15 2019
Hi John,
Update, please ignore the other email I sent. Looks like I was missing
'-field' instead of field.
However, now I'm getting the error "ERROR :
NcCfFile::read_netcdf_grid() -> Couldn't figure out projection from
information in netCDF file." It seems like I'm a bit stuck because I
don't know the projection. If I did, I wouldn't need to use
regrid_data_plane. Any thoughts?
Thanks!
Sarah
On 7/12/19 5:53 PM, John Halley Gotway via RT wrote:
> Sarah,
>
> I'm pretty sure that didn't fix it entirely. When I plot the
channel 15
> data with plot_data_plane, I clearly see the outline of FL and the
Eastern
> seaboard in the data, but it doesn't line up with the map data. So
there's
> clearly still a problem.
>
> I see that you're using GOES-16 data here. MET's regrid_data_plane
tool
> should be able to read GOES-16 data and regrid it to a user-defined
grid.
> That would be another alternatively for using GOES-16 data in MET.
>
> Thanks,
> John
>
> On Fri, Jul 12, 2019 at 4:45 PM John Halley Gotway <johnhg at ucar.edu>
wrote:
>
>> Hi Sarah,
>>
>> Thought I'd chime in here to mention the following. This is not
actually
>> a problem in MODE tool itself, but more of an issue in how MET is
reading
>> data your input files and placing them on the earth. I usually
recommend
>> that people run MET's plot_data_plane tool when working with a new
data
>> source to make sure MET is reading the data well:
>>
>> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc> plot.ps
>> <http://plot.ps> 'name="channel_10_brightness_temperature";
level="(*,*)";'
>> -v 4*
>>
>> This produces a nice looking plot, but there's no country outlines
on top
>> of the data! And that usually indicates a problem in the
projection
>> information. But I did find one thing which seems to have helped.
I
>> changed the longitude_of_central_meridian from 262.5 to -97.5, by
running
>> the following command:
>>
>> *ncatted -a longitude_of_central_meridian,Projection,o,f,-97.5
>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc>
>> remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>*
>>
>> Those two longitudes are the same since they differ by 360 degrees.
>> Surprisingly, running plot_data_plane on that modified file did
plot the
>> map data (see attached image):
>>
>> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc> plot.ps
>> <http://plot.ps> 'name="channel_10_brightness_temperature";
level="(*,*)";'
>> -v 4*
>>
>> Can you confirm that the data lives on the right place on the
earth?
>> Should it be covering the Eastern CONUS and Atlantic? If so, then
we'll
>> likely need to make a one line fix in MET's library code to rescale
the
>> longitude values to the expected range of (-180, 180] when we read
them in.
>>
>> Thanks,
>> John
>>
>> On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT
<met_help at ucar.edu>
>> wrote:
>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>>
>>> On Fri Jul 12 14:56:24 2019, sarah.griffin at ssec.wisc.edu wrote:
>>>> Hi,
>>>>
>>>> I'm using Met 8.0 with the bug fixes to run MODE for two netCDF
files.
>>>> MODE seems to run just fine, however the latitude and longitude
of the
>>>> output is messed up. How can I fix the latitude and longitude?
I've
>>>> uploaded the data and MODE output to the met_help ftp directory.
Thanks!
>>>>
>>>> Have a great day!
>>>> Sarah
>>>>
>>>
>>> Hi Sarah -
>>> Thanks for the data upload.
>>> I've passed this ticket along to Randy, our resident MODE
specialist.
>>> He should get a change to look at this early next week.
>>> David
>>>
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC UW-
Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu
(608) 262-0986
----------------------------------------------------------------------------
------------------------------------------------
Subject: Incorrect lat and lon data on objects
From: John Halley Gotway
Time: Mon Jul 15 10:58:27 2019
Sarah,
Can you please send me a link to the GOES-16 data you're trying to
use? I
see you have a NetCDF file by this name:
emap_geocatL1.GOES-16.CONUS.2018007.000230.nc
Where did you get this file? Is is a publicly available ftp site?
In general, MET reads gridded data that lives on regular projections.
GOES
data is a special case... it is not defined on a projection. Instead,
it's
a whole bunch of high resolution pixels of data. Each pixel has a
lat/lon
associated with it. We enhanced regrid_data_plane to read those
lat/lon's
and interpolate them to a user-requested domain.
I'm hoping to get a sample GOES-16 file and send you example commands
for
interpolating it to your model domain using regrid_data_plane.
Thanks,
John
On Mon, Jul 15, 2019 at 9:28 AM Sarah Griffin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> Update, please ignore the other email I sent. Looks like I was
missing
> '-field' instead of field.
>
> However, now I'm getting the error "ERROR :
> NcCfFile::read_netcdf_grid() -> Couldn't figure out projection from
> information in netCDF file." It seems like I'm a bit stuck because I
> don't know the projection. If I did, I wouldn't need to use
> regrid_data_plane. Any thoughts?
>
> Thanks!
> Sarah
>
> On 7/12/19 5:53 PM, John Halley Gotway via RT wrote:
> > Sarah,
> >
> > I'm pretty sure that didn't fix it entirely. When I plot the
channel 15
> > data with plot_data_plane, I clearly see the outline of FL and the
> Eastern
> > seaboard in the data, but it doesn't line up with the map data.
So
> there's
> > clearly still a problem.
> >
> > I see that you're using GOES-16 data here. MET's
regrid_data_plane tool
> > should be able to read GOES-16 data and regrid it to a user-
defined grid.
> > That would be another alternatively for using GOES-16 data in MET.
> >
> > Thanks,
> > John
> >
> > On Fri, Jul 12, 2019 at 4:45 PM John Halley Gotway
<johnhg at ucar.edu>
> wrote:
> >
> >> Hi Sarah,
> >>
> >> Thought I'd chime in here to mention the following. This is not
> actually
> >> a problem in MODE tool itself, but more of an issue in how MET is
> reading
> >> data your input files and placing them on the earth. I usually
> recommend
> >> that people run MET's plot_data_plane tool when working with a
new data
> >> source to make sure MET is reading the data well:
> >>
> >> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
> >> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc> plot.ps
> >> <http://plot.ps> 'name="channel_10_brightness_temperature";
> level="(*,*)";'
> >> -v 4*
> >>
> >> This produces a nice looking plot, but there's no country
outlines on
> top
> >> of the data! And that usually indicates a problem in the
projection
> >> information. But I did find one thing which seems to have
helped. I
> >> changed the longitude_of_central_meridian from 262.5 to -97.5, by
> running
> >> the following command:
> >>
> >> *ncatted -a longitude_of_central_meridian,Projection,o,f,-97.5
> >> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
> >> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc>
> >> remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
> >> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>*
> >>
> >> Those two longitudes are the same since they differ by 360
degrees.
> >> Surprisingly, running plot_data_plane on that modified file did
plot the
> >> map data (see attached image):
> >>
> >> *plot_data_plane remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc
> >> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>
plot.ps
> >> <http://plot.ps> 'name="channel_10_brightness_temperature";
> level="(*,*)";'
> >> -v 4*
> >>
> >> Can you confirm that the data lives on the right place on the
earth?
> >> Should it be covering the Eastern CONUS and Atlantic? If so,
then we'll
> >> likely need to make a one line fix in MET's library code to
rescale the
> >> longitude values to the expected range of (-180, 180] when we
read them
> in.
> >>
> >> Thanks,
> >> John
> >>
> >> On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT <
> met_help at ucar.edu>
> >> wrote:
> >>
> >>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
> >>>
> >>> On Fri Jul 12 14:56:24 2019, sarah.griffin at ssec.wisc.edu wrote:
> >>>> Hi,
> >>>>
> >>>> I'm using Met 8.0 with the bug fixes to run MODE for two netCDF
files.
> >>>> MODE seems to run just fine, however the latitude and longitude
of the
> >>>> output is messed up. How can I fix the latitude and longitude?
I've
> >>>> uploaded the data and MODE output to the met_help ftp
directory.
> Thanks!
> >>>>
> >>>> Have a great day!
> >>>> Sarah
> >>>>
> >>>
> >>> Hi Sarah -
> >>> Thanks for the data upload.
> >>> I've passed this ticket along to Randy, our resident MODE
specialist.
> >>> He should get a change to look at this early next week.
> >>> David
> >>>
>
>
> --
>
>
----------------------------------------------------------------------------
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
> sarah.griffin at ssec.wisc.edu
> (608) 262-0986
>
>
----------------------------------------------------------------------------
>
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #91053] Incorrect lat and lon data on objects
From: Sarah Griffin
Time: Mon Jul 15 11:17:29 2019
Hi John,
The GOES-16 data I'm trying to use was created after remapping the
native GOES data to the WRF projection from
mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc.
So does it matter what the GOES projection is if I'm trying to remap
it
to a different projection?
I've messed around some more and have gotten to this error on
regrid_data_plane. MetNcFile::data(NcVar *, const LongArray &,
DataPlane
&) const -> star found in bad slot
when using this command:
bin/regrid_data_plane \
remap_geocatL1.GOES-16.CONUS.2018007.060230.nc \
Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
-field 'name = "channel_13_brightness_temperature"; level = "(*,*)";
file_type = NETCDF_MET;' \
-v 4
Thanks!
Sarah
On 7/15/19 11:58 AM, John Halley Gotway via RT wrote:
> Sarah,
>
> Can you please send me a link to the GOES-16 data you're trying to
use? I
> see you have a NetCDF file by this name:
> emap_geocatL1.GOES-16.CONUS.2018007.000230.nc
> Where did you get this file? Is is a publicly available ftp site?
>
> In general, MET reads gridded data that lives on regular
projections. GOES
> data is a special case... it is not defined on a projection.
Instead, it's
> a whole bunch of high resolution pixels of data. Each pixel has a
lat/lon
> associated with it. We enhanced regrid_data_plane to read those
lat/lon's
> and interpolate them to a user-requested domain.
>
> I'm hoping to get a sample GOES-16 file and send you example
commands for
> interpolating it to your model domain using regrid_data_plane.
>
> Thanks,
> John
>
> On Mon, Jul 15, 2019 at 9:28 AM Sarah Griffin via RT
<met_help at ucar.edu>
> wrote:
>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>
>> Hi John,
>>
>> Update, please ignore the other email I sent. Looks like I was
missing
>> '-field' instead of field.
>>
>> However, now I'm getting the error "ERROR :
>> NcCfFile::read_netcdf_grid() -> Couldn't figure out projection from
>> information in netCDF file." It seems like I'm a bit stuck because
I
>> don't know the projection. If I did, I wouldn't need to use
>> regrid_data_plane. Any thoughts?
>>
>> Thanks!
>> Sarah
>>
>> On 7/12/19 5:53 PM, John Halley Gotway via RT wrote:
>>> Sarah,
>>>
>>> I'm pretty sure that didn't fix it entirely. When I plot the
channel 15
>>> data with plot_data_plane, I clearly see the outline of FL and the
>> Eastern
>>> seaboard in the data, but it doesn't line up with the map data.
So
>> there's
>>> clearly still a problem.
>>>
>>> I see that you're using GOES-16 data here. MET's
regrid_data_plane tool
>>> should be able to read GOES-16 data and regrid it to a user-
defined grid.
>>> That would be another alternatively for using GOES-16 data in MET.
>>>
>>> Thanks,
>>> John
>>>
>>> On Fri, Jul 12, 2019 at 4:45 PM John Halley Gotway
<johnhg at ucar.edu>
>> wrote:
>>>> Hi Sarah,
>>>>
>>>> Thought I'd chime in here to mention the following. This is not
>> actually
>>>> a problem in MODE tool itself, but more of an issue in how MET is
>> reading
>>>> data your input files and placing them on the earth. I usually
>> recommend
>>>> that people run MET's plot_data_plane tool when working with a
new data
>>>> source to make sure MET is reading the data well:
>>>>
>>>> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
>>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc> plot.ps
>>>> <http://plot.ps> 'name="channel_10_brightness_temperature";
>> level="(*,*)";'
>>>> -v 4*
>>>>
>>>> This produces a nice looking plot, but there's no country
outlines on
>> top
>>>> of the data! And that usually indicates a problem in the
projection
>>>> information. But I did find one thing which seems to have
helped. I
>>>> changed the longitude_of_central_meridian from 262.5 to -97.5, by
>> running
>>>> the following command:
>>>>
>>>> *ncatted -a longitude_of_central_meridian,Projection,o,f,-97.5
>>>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
>>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc>
>>>> remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
>>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>*
>>>>
>>>> Those two longitudes are the same since they differ by 360
degrees.
>>>> Surprisingly, running plot_data_plane on that modified file did
plot the
>>>> map data (see attached image):
>>>>
>>>> *plot_data_plane remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc
>>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>
plot.ps
>>>> <http://plot.ps> 'name="channel_10_brightness_temperature";
>> level="(*,*)";'
>>>> -v 4*
>>>>
>>>> Can you confirm that the data lives on the right place on the
earth?
>>>> Should it be covering the Eastern CONUS and Atlantic? If so,
then we'll
>>>> likely need to make a one line fix in MET's library code to
rescale the
>>>> longitude values to the expected range of (-180, 180] when we
read them
>> in.
>>>> Thanks,
>>>> John
>>>>
>>>> On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT <
>> met_help at ucar.edu>
>>>> wrote:
>>>>
>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>>>>
>>>>> On Fri Jul 12 14:56:24 2019, sarah.griffin at ssec.wisc.edu wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm using Met 8.0 with the bug fixes to run MODE for two netCDF
files.
>>>>>> MODE seems to run just fine, however the latitude and longitude
of the
>>>>>> output is messed up. How can I fix the latitude and longitude?
I've
>>>>>> uploaded the data and MODE output to the met_help ftp
directory.
>> Thanks!
>>>>>> Have a great day!
>>>>>> Sarah
>>>>>>
>>>>> Hi Sarah -
>>>>> Thanks for the data upload.
>>>>> I've passed this ticket along to Randy, our resident MODE
specialist.
>>>>> He should get a change to look at this early next week.
>>>>> David
>>>>>
>>
>> --
>>
>>
----------------------------------------------------------------------------
>> Sarah M. Griffin
>> Associate Research Scientist
>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>> UW-Madison
>> 1225 W Dayton St. Rm 243
>> Madison, WI 53706
>> sarah.griffin at ssec.wisc.edu
>> (608) 262-0986
>>
>>
----------------------------------------------------------------------------
>>
>>
>>
>>
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC UW-
Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu
(608) 262-0986
----------------------------------------------------------------------------
------------------------------------------------
Subject: Incorrect lat and lon data on objects
From: John Halley Gotway
Time: Mon Jul 15 12:07:16 2019
Sarah,
What I'm recommending is that we go back to the original GOES-16 data,
and
run it through regrid_data_plane to do that remapping step. If we can
get
that to work, it'll result in an output file that can easily be read
by
MODE.
Otherwise, we're stuck with trying to get the CF-convention
specification
of the WRF domain exactly right, which can be pretty tedious.
John
On Mon, Jul 15, 2019 at 11:17 AM Sarah Griffin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> The GOES-16 data I'm trying to use was created after remapping the
> native GOES data to the WRF projection from
>
> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc.
>
> So does it matter what the GOES projection is if I'm trying to remap
it
> to a different projection?
>
> I've messed around some more and have gotten to this error on
> regrid_data_plane. MetNcFile::data(NcVar *, const LongArray &,
DataPlane
> &) const -> star found in bad slot
>
> when using this command:
> bin/regrid_data_plane \
> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc \
> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
> -field 'name = "channel_13_brightness_temperature"; level =
"(*,*)";
> file_type = NETCDF_MET;' \
> -v 4
>
> Thanks!
> Sarah
>
> On 7/15/19 11:58 AM, John Halley Gotway via RT wrote:
> > Sarah,
> >
> > Can you please send me a link to the GOES-16 data you're trying to
use?
> I
> > see you have a NetCDF file by this name:
> > emap_geocatL1.GOES-16.CONUS.2018007.000230.nc
> > Where did you get this file? Is is a publicly available ftp site?
> >
> > In general, MET reads gridded data that lives on regular
projections.
> GOES
> > data is a special case... it is not defined on a projection.
Instead,
> it's
> > a whole bunch of high resolution pixels of data. Each pixel has a
> lat/lon
> > associated with it. We enhanced regrid_data_plane to read those
> lat/lon's
> > and interpolate them to a user-requested domain.
> >
> > I'm hoping to get a sample GOES-16 file and send you example
commands for
> > interpolating it to your model domain using regrid_data_plane.
> >
> > Thanks,
> > John
> >
> > On Mon, Jul 15, 2019 at 9:28 AM Sarah Griffin via RT
<met_help at ucar.edu>
> > wrote:
> >
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
> >>
> >> Hi John,
> >>
> >> Update, please ignore the other email I sent. Looks like I was
missing
> >> '-field' instead of field.
> >>
> >> However, now I'm getting the error "ERROR :
> >> NcCfFile::read_netcdf_grid() -> Couldn't figure out projection
from
> >> information in netCDF file." It seems like I'm a bit stuck
because I
> >> don't know the projection. If I did, I wouldn't need to use
> >> regrid_data_plane. Any thoughts?
> >>
> >> Thanks!
> >> Sarah
> >>
> >> On 7/12/19 5:53 PM, John Halley Gotway via RT wrote:
> >>> Sarah,
> >>>
> >>> I'm pretty sure that didn't fix it entirely. When I plot the
channel
> 15
> >>> data with plot_data_plane, I clearly see the outline of FL and
the
> >> Eastern
> >>> seaboard in the data, but it doesn't line up with the map data.
So
> >> there's
> >>> clearly still a problem.
> >>>
> >>> I see that you're using GOES-16 data here. MET's
regrid_data_plane
> tool
> >>> should be able to read GOES-16 data and regrid it to a user-
defined
> grid.
> >>> That would be another alternatively for using GOES-16 data in
MET.
> >>>
> >>> Thanks,
> >>> John
> >>>
> >>> On Fri, Jul 12, 2019 at 4:45 PM John Halley Gotway
<johnhg at ucar.edu>
> >> wrote:
> >>>> Hi Sarah,
> >>>>
> >>>> Thought I'd chime in here to mention the following. This is
not
> >> actually
> >>>> a problem in MODE tool itself, but more of an issue in how MET
is
> >> reading
> >>>> data your input files and placing them on the earth. I usually
> >> recommend
> >>>> that people run MET's plot_data_plane tool when working with a
new
> data
> >>>> source to make sure MET is reading the data well:
> >>>>
> >>>> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
> >>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc> plot.ps
> >>>> <http://plot.ps> 'name="channel_10_brightness_temperature";
> >> level="(*,*)";'
> >>>> -v 4*
> >>>>
> >>>> This produces a nice looking plot, but there's no country
outlines on
> >> top
> >>>> of the data! And that usually indicates a problem in the
projection
> >>>> information. But I did find one thing which seems to have
helped. I
> >>>> changed the longitude_of_central_meridian from 262.5 to -97.5,
by
> >> running
> >>>> the following command:
> >>>>
> >>>> *ncatted -a longitude_of_central_meridian,Projection,o,f,-97.5
> >>>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
> >>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc>
> >>>> remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
> >>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>*
> >>>>
> >>>> Those two longitudes are the same since they differ by 360
degrees.
> >>>> Surprisingly, running plot_data_plane on that modified file did
plot
> the
> >>>> map data (see attached image):
> >>>>
> >>>> *plot_data_plane remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc
> >>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>
plot.ps
> >>>> <http://plot.ps> 'name="channel_10_brightness_temperature";
> >> level="(*,*)";'
> >>>> -v 4*
> >>>>
> >>>> Can you confirm that the data lives on the right place on the
earth?
> >>>> Should it be covering the Eastern CONUS and Atlantic? If so,
then
> we'll
> >>>> likely need to make a one line fix in MET's library code to
rescale
> the
> >>>> longitude values to the expected range of (-180, 180] when we
read
> them
> >> in.
> >>>> Thanks,
> >>>> John
> >>>>
> >>>> On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT <
> >> met_help at ucar.edu>
> >>>> wrote:
> >>>>
> >>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053
>
> >>>>>
> >>>>> On Fri Jul 12 14:56:24 2019, sarah.griffin at ssec.wisc.edu
wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> I'm using Met 8.0 with the bug fixes to run MODE for two
netCDF
> files.
> >>>>>> MODE seems to run just fine, however the latitude and
longitude of
> the
> >>>>>> output is messed up. How can I fix the latitude and
longitude? I've
> >>>>>> uploaded the data and MODE output to the met_help ftp
directory.
> >> Thanks!
> >>>>>> Have a great day!
> >>>>>> Sarah
> >>>>>>
> >>>>> Hi Sarah -
> >>>>> Thanks for the data upload.
> >>>>> I've passed this ticket along to Randy, our resident MODE
specialist.
> >>>>> He should get a change to look at this early next week.
> >>>>> David
> >>>>>
> >>
> >> --
> >>
> >>
>
----------------------------------------------------------------------------
> >> Sarah M. Griffin
> >> Associate Research Scientist
> >> Cooperative Institute for Meteorological Satellite Studies / SSEC
> >> UW-Madison
> >> 1225 W Dayton St. Rm 243
> >> Madison, WI 53706
> >> sarah.griffin at ssec.wisc.edu
> >> (608) 262-0986
> >>
> >>
>
----------------------------------------------------------------------------
> >>
> >>
> >>
> >>
>
>
> --
>
>
----------------------------------------------------------------------------
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
> sarah.griffin at ssec.wisc.edu
> (608) 262-0986
>
>
----------------------------------------------------------------------------
>
>
>
>
------------------------------------------------
Subject: Incorrect lat and lon data on objects
From: Sarah Griffin
Time: Mon Jul 15 12:36:29 2019
Hi John,
Ok, I've added the original GOES-16 data to the ftp site. I've also
added 'geocatL1.GOES-16.2018007.000200.nc' since the original GOES-16
data needs to be rewritten to actually get the brightness
temperatures.
I then did:
bin/regrid_data_plane \
geocatL1.GOES-16.2018007.000200.nc \
Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
-field 'name = "channel_13_brightness_temperature"; level = "(*,*)";
file_type = NETCDF_MET;' \
-v 4
and got the same error "MetNcFile::data(NcVar *, const LongArray &,
DataPlane &) const -> star found in bad slot"
I also added some radar data, Radar_Reflectivity_2018_0107_00_00.nc
and Radar_Reflectivity_2018_0107_00_00.nc_new. I was able to do:
bin/regrid_data_plane \
Radar_Reflectivity_2018_0107_00_00.nc \
Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
Radar_Reflectivity_2018_0107_00_00.nc_new \
-field 'name = "composite_n0q"; level = "(*,*)"; file_type =
NETCDF_MET;' \
-v 4
And get the remapping to work. I didn't try this is MODE, though,
because the composite_n0q data is empty. But I'm curious if any of the
global attribute data in Radar_Reflectivity_2018_0107_00_00.nc_new is
helpful in figuring out what I need to run MODE?
Thanks!
Sarah
On 7/15/19 1:07 PM, John Halley Gotway via RT wrote:
Sarah,
What I'm recommending is that we go back to the original GOES-16 data,
and
run it through regrid_data_plane to do that remapping step. If we can
get
that to work, it'll result in an output file that can easily be read
by
MODE.
Otherwise, we're stuck with trying to get the CF-convention
specification
of the WRF domain exactly right, which can be pretty tedious.
John
On Mon, Jul 15, 2019 at 11:17 AM Sarah Griffin via RT
<met_help at ucar.edu><mailto:met_help at ucar.edu>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
Hi John,
The GOES-16 data I'm trying to use was created after remapping the
native GOES data to the WRF projection from
mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc.
So does it matter what the GOES projection is if I'm trying to remap
it
to a different projection?
I've messed around some more and have gotten to this error on
regrid_data_plane. MetNcFile::data(NcVar *, const LongArray &,
DataPlane
&) const -> star found in bad slot
when using this command:
bin/regrid_data_plane \
remap_geocatL1.GOES-16.CONUS.2018007.060230.nc \
Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
-field 'name = "channel_13_brightness_temperature"; level = "(*,*)";
file_type = NETCDF_MET;' \
-v 4
Thanks!
Sarah
On 7/15/19 11:58 AM, John Halley Gotway via RT wrote:
Sarah,
Can you please send me a link to the GOES-16 data you're trying to
use?
I
see you have a NetCDF file by this name:
emap_geocatL1.GOES-16.CONUS.2018007.000230.nc
Where did you get this file? Is is a publicly available ftp site?
In general, MET reads gridded data that lives on regular projections.
GOES
data is a special case... it is not defined on a projection. Instead,
it's
a whole bunch of high resolution pixels of data. Each pixel has a
lat/lon
associated with it. We enhanced regrid_data_plane to read those
lat/lon's
and interpolate them to a user-requested domain.
I'm hoping to get a sample GOES-16 file and send you example commands
for
interpolating it to your model domain using regrid_data_plane.
Thanks,
John
On Mon, Jul 15, 2019 at 9:28 AM Sarah Griffin via RT
<met_help at ucar.edu><mailto:met_help at ucar.edu>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
Hi John,
Update, please ignore the other email I sent. Looks like I was missing
'-field' instead of field.
However, now I'm getting the error "ERROR :
NcCfFile::read_netcdf_grid() -> Couldn't figure out projection from
information in netCDF file." It seems like I'm a bit stuck because I
don't know the projection. If I did, I wouldn't need to use
regrid_data_plane. Any thoughts?
Thanks!
Sarah
On 7/12/19 5:53 PM, John Halley Gotway via RT wrote:
Sarah,
I'm pretty sure that didn't fix it entirely. When I plot the channel
15
data with plot_data_plane, I clearly see the outline of FL and the
Eastern
seaboard in the data, but it doesn't line up with the map data. So
there's
clearly still a problem.
I see that you're using GOES-16 data here. MET's regrid_data_plane
tool
should be able to read GOES-16 data and regrid it to a user-defined
grid.
That would be another alternatively for using GOES-16 data in MET.
Thanks,
John
On Fri, Jul 12, 2019 at 4:45 PM John Halley Gotway
<johnhg at ucar.edu><mailto:johnhg at ucar.edu>
wrote:
Hi Sarah,
Thought I'd chime in here to mention the following. This is not
actually
a problem in MODE tool itself, but more of an issue in how MET is
reading
data your input files and placing them on the earth. I usually
recommend
that people run MET's plot_data_plane tool when working with a new
data
source to make sure MET is reading the data well:
*plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
<http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc> plot.ps
<http://plot.ps><http://plot.ps>
'name="channel_10_brightness_temperature";
level="(*,*)";'
-v 4*
This produces a nice looking plot, but there's no country outlines on
top
of the data! And that usually indicates a problem in the projection
information. But I did find one thing which seems to have helped. I
changed the longitude_of_central_meridian from 262.5 to -97.5, by
running
the following command:
*ncatted -a longitude_of_central_meridian,Projection,o,f,-97.5
remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
<http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc>
remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
<http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc>*
Those two longitudes are the same since they differ by 360 degrees.
Surprisingly, running plot_data_plane on that modified file did plot
the
map data (see attached image):
*plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
<http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc> plot.ps
<http://plot.ps><http://plot.ps>
'name="channel_10_brightness_temperature";
level="(*,*)";'
-v 4*
Can you confirm that the data lives on the right place on the earth?
Should it be covering the Eastern CONUS and Atlantic? If so, then
we'll
likely need to make a one line fix in MET's library code to rescale
the
longitude values to the expected range of (-180, 180] when we read
them
in.
Thanks,
John
On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT <
met_help at ucar.edu<mailto:met_help at ucar.edu>>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
On Fri Jul 12 14:56:24 2019,
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu> wrote:
Hi,
I'm using Met 8.0 with the bug fixes to run MODE for two netCDF
files.
MODE seems to run just fine, however the latitude and longitude of
the
output is messed up. How can I fix the latitude and longitude? I've
uploaded the data and MODE output to the met_help ftp directory.
Thanks!
Have a great day!
Sarah
Hi Sarah -
Thanks for the data upload.
I've passed this ticket along to Randy, our resident MODE specialist.
He should get a change to look at this early next week.
David
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC UW-
Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
------------------------------------------------
Subject: Incorrect lat and lon data on objects
From: John Halley Gotway
Time: Mon Jul 15 13:12:04 2019
Sarah,
I grabbed that file from the ftp site and see this header:
*netcdf geocatL1.GOES-16.2018007.000200 {dimensions: x = 2312 ;
y = 1191 ;variables: float pixel_latitude(y, x) ;
float
pixel_longitude(y, x) ; float
channel_13_brightness_temperature(y,
x) ;}*
The original GOES-16 file has much more metadata in it that
regrid_data_plane expects and uses. I found some GOES-16 data on our
filesystem and am sending you an example of how it can be used by
regrid_data_plane. Here's the sample data file:
*ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
<ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-
M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc>*
And here's the command I ran to interpolate it to NCEP Grid 212 which
covers CONUS:
*met-8.1/bin/regrid_data_plane \*
*goes-16/ABI/L1/CONUS/C10/2019196/OR_ABI-L1b-RadC-
M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
\*
*G212 goes16_g212.nc <http://goes16_g212.nc> -field 'name="Rad";
level="(*,*)";' -method MAX -v 4*
And then I plotted the result:
*met-8.1/bin/plot_data_plane goes16_g212.nc <http://goes16_g212.nc>
goes16_g212.ps <http://goes16_g212.ps> 'name="Rad"; level="(*,*)";'*
And that plot is attached.
John
On Mon, Jul 15, 2019 at 12:37 PM Sarah Griffin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> Ok, I've added the original GOES-16 data to the ftp site. I've also
added '
> geocatL1.GOES-16.2018007.000200.nc' since the original GOES-16 data
needs
> to be rewritten to actually get the brightness temperatures.
>
> I then did:
> bin/regrid_data_plane \
> geocatL1.GOES-16.2018007.000200.nc \
> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
> -field 'name = "channel_13_brightness_temperature"; level =
"(*,*)";
> file_type = NETCDF_MET;' \
> -v 4
>
> and got the same error "MetNcFile::data(NcVar *, const LongArray &,
> DataPlane &) const -> star found in bad slot"
>
>
>
> I also added some radar data, Radar_Reflectivity_2018_0107_00_00.nc
and
> Radar_Reflectivity_2018_0107_00_00.nc_new. I was able to do:
>
> bin/regrid_data_plane \
> Radar_Reflectivity_2018_0107_00_00.nc \
> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
> Radar_Reflectivity_2018_0107_00_00.nc_new \
> -field 'name = "composite_n0q"; level = "(*,*)"; file_type =
NETCDF_MET;'
> \
> -v 4
>
> And get the remapping to work. I didn't try this is MODE, though,
because
> the composite_n0q data is empty. But I'm curious if any of the
global
> attribute data in Radar_Reflectivity_2018_0107_00_00.nc_new is
helpful in
> figuring out what I need to run MODE?
>
> Thanks!
> Sarah
>
> On 7/15/19 1:07 PM, John Halley Gotway via RT wrote:
>
> Sarah,
>
> What I'm recommending is that we go back to the original GOES-16
data, and
> run it through regrid_data_plane to do that remapping step. If we
can get
> that to work, it'll result in an output file that can easily be read
by
> MODE.
>
> Otherwise, we're stuck with trying to get the CF-convention
specification
> of the WRF domain exactly right, which can be pretty tedious.
>
> John
>
> On Mon, Jul 15, 2019 at 11:17 AM Sarah Griffin via RT
<met_help at ucar.edu
> ><mailto:met_help at ucar.edu>
> wrote:
>
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> The GOES-16 data I'm trying to use was created after remapping the
> native GOES data to the WRF projection from
>
>
> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
> .
>
> So does it matter what the GOES projection is if I'm trying to remap
it
> to a different projection?
>
> I've messed around some more and have gotten to this error on
> regrid_data_plane. MetNcFile::data(NcVar *, const LongArray &,
DataPlane
> &) const -> star found in bad slot
>
> when using this command:
> bin/regrid_data_plane \
> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc \
> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
> -field 'name = "channel_13_brightness_temperature"; level =
"(*,*)";
> file_type = NETCDF_MET;' \
> -v 4
>
> Thanks!
> Sarah
>
> On 7/15/19 11:58 AM, John Halley Gotway via RT wrote:
>
>
> Sarah,
>
> Can you please send me a link to the GOES-16 data you're trying to
use?
>
>
> I
>
>
> see you have a NetCDF file by this name:
> emap_geocatL1.GOES-16.CONUS.2018007.000230.nc
> Where did you get this file? Is is a publicly available ftp site?
>
> In general, MET reads gridded data that lives on regular
projections.
>
>
> GOES
>
>
> data is a special case... it is not defined on a projection.
Instead,
>
>
> it's
>
>
> a whole bunch of high resolution pixels of data. Each pixel has a
>
>
> lat/lon
>
>
> associated with it. We enhanced regrid_data_plane to read those
>
>
> lat/lon's
>
>
> and interpolate them to a user-requested domain.
>
> I'm hoping to get a sample GOES-16 file and send you example
commands for
> interpolating it to your model domain using regrid_data_plane.
>
> Thanks,
> John
>
> On Mon, Jul 15, 2019 at 9:28 AM Sarah Griffin via RT
<met_help at ucar.edu
> ><mailto:met_help at ucar.edu>
> wrote:
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> Update, please ignore the other email I sent. Looks like I was
missing
> '-field' instead of field.
>
> However, now I'm getting the error "ERROR :
> NcCfFile::read_netcdf_grid() -> Couldn't figure out projection from
> information in netCDF file." It seems like I'm a bit stuck because I
> don't know the projection. If I did, I wouldn't need to use
> regrid_data_plane. Any thoughts?
>
> Thanks!
> Sarah
>
> On 7/12/19 5:53 PM, John Halley Gotway via RT wrote:
>
>
> Sarah,
>
> I'm pretty sure that didn't fix it entirely. When I plot the
channel
>
>
> 15
>
>
> data with plot_data_plane, I clearly see the outline of FL and the
>
>
> Eastern
>
>
> seaboard in the data, but it doesn't line up with the map data. So
>
>
> there's
>
>
> clearly still a problem.
>
> I see that you're using GOES-16 data here. MET's regrid_data_plane
>
>
> tool
>
>
> should be able to read GOES-16 data and regrid it to a user-defined
>
>
> grid.
>
>
> That would be another alternatively for using GOES-16 data in MET.
>
> Thanks,
> John
>
> On Fri, Jul 12, 2019 at 4:45 PM John Halley Gotway <johnhg at ucar.edu
> ><mailto:johnhg at ucar.edu>
>
>
> wrote:
>
>
> Hi Sarah,
>
> Thought I'd chime in here to mention the following. This is not
>
>
> actually
>
>
> a problem in MODE tool itself, but more of an issue in how MET is
>
>
> reading
>
>
> data your input files and placing them on the earth. I usually
>
>
> recommend
>
>
> that people run MET's plot_data_plane tool when working with a new
>
>
> data
>
>
> source to make sure MET is reading the data well:
>
> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc> plot.ps
> <http://plot.ps><http://plot.ps>
> 'name="channel_10_brightness_temperature";
>
>
> level="(*,*)";'
>
>
> -v 4*
>
> This produces a nice looking plot, but there's no country outlines
on
>
>
> top
>
>
> of the data! And that usually indicates a problem in the projection
> information. But I did find one thing which seems to have helped.
I
> changed the longitude_of_central_meridian from 262.5 to -97.5, by
>
>
> running
>
>
> the following command:
>
> *ncatted -a longitude_of_central_meridian,Projection,o,f,-97.5
> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc>
> remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>*
>
> Those two longitudes are the same since they differ by 360 degrees.
> Surprisingly, running plot_data_plane on that modified file did plot
>
>
> the
>
>
> map data (see attached image):
>
> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc> plot.ps
> <http://plot.ps><http://plot.ps>
> 'name="channel_10_brightness_temperature";
>
>
> level="(*,*)";'
>
>
> -v 4*
>
> Can you confirm that the data lives on the right place on the earth?
> Should it be covering the Eastern CONUS and Atlantic? If so, then
>
>
> we'll
>
>
> likely need to make a one line fix in MET's library code to rescale
>
>
> the
>
>
> longitude values to the expected range of (-180, 180] when we read
>
>
> them
>
>
> in.
>
>
> Thanks,
> John
>
> On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT <
>
>
> met_help at ucar.edu<mailto:met_help at ucar.edu>>
>
>
> wrote:
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> On Fri Jul 12 14:56:24 2019, sarah.griffin at ssec.wisc.edu<mailto:
> sarah.griffin at ssec.wisc.edu> wrote:
>
>
> Hi,
>
> I'm using Met 8.0 with the bug fixes to run MODE for two netCDF
>
>
> files.
>
>
> MODE seems to run just fine, however the latitude and longitude of
>
>
> the
>
>
> output is messed up. How can I fix the latitude and longitude? I've
> uploaded the data and MODE output to the met_help ftp directory.
>
>
> Thanks!
>
>
> Have a great day!
> Sarah
>
>
>
> Hi Sarah -
> Thanks for the data upload.
> I've passed this ticket along to Randy, our resident MODE
specialist.
> He should get a change to look at this early next week.
> David
>
>
>
>
> --
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
>
> --
>
>
>
----------------------------------------------------------------------------
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
>
>
> --
>
>
----------------------------------------------------------------------------
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
----------------------------------------------------------------------------
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #91053] Incorrect lat and lon data on objects
From: Sarah Griffin
Time: Mon Jul 15 13:18:38 2019
Hi John,
Can you send me the goes16_g212.nc netcdf file as well?
Thanks!
Sarah
On 7/15/19 2:12 PM, John Halley Gotway via RT wrote:
> Sarah,
>
> I grabbed that file from the ftp site and see this header:
>
>
>
>
>
>
>
>
>
> *netcdf geocatL1.GOES-16.2018007.000200 {dimensions: x = 2312
;
> y = 1191 ;variables: float pixel_latitude(y, x) ;
float
> pixel_longitude(y, x) ; float
channel_13_brightness_temperature(y,
> x) ;}*
>
> The original GOES-16 file has much more metadata in it that
> regrid_data_plane expects and uses. I found some GOES-16 data on
our
> filesystem and am sending you an example of how it can be used by
> regrid_data_plane. Here's the sample data file:
>
> *ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
> <ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-
M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc>*
>
> And here's the command I ran to interpolate it to NCEP Grid 212
which
> covers CONUS:
>
> *met-8.1/bin/regrid_data_plane \*
> *goes-16/ABI/L1/CONUS/C10/2019196/OR_ABI-L1b-RadC-
M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
> \*
> *G212 goes16_g212.nc <http://goes16_g212.nc> -field 'name="Rad";
> level="(*,*)";' -method MAX -v 4*
>
> And then I plotted the result:
>
> *met-8.1/bin/plot_data_plane goes16_g212.nc <http://goes16_g212.nc>
> goes16_g212.ps <http://goes16_g212.ps> 'name="Rad"; level="(*,*)";'*
>
> And that plot is attached.
>
> John
>
> On Mon, Jul 15, 2019 at 12:37 PM Sarah Griffin via RT
<met_help at ucar.edu>
> wrote:
>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>
>> Hi John,
>>
>> Ok, I've added the original GOES-16 data to the ftp site. I've also
added '
>> geocatL1.GOES-16.2018007.000200.nc' since the original GOES-16 data
needs
>> to be rewritten to actually get the brightness temperatures.
>>
>> I then did:
>> bin/regrid_data_plane \
>> geocatL1.GOES-16.2018007.000200.nc \
>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
>> -field 'name = "channel_13_brightness_temperature"; level =
"(*,*)";
>> file_type = NETCDF_MET;' \
>> -v 4
>>
>> and got the same error "MetNcFile::data(NcVar *, const LongArray &,
>> DataPlane &) const -> star found in bad slot"
>>
>>
>>
>> I also added some radar data, Radar_Reflectivity_2018_0107_00_00.nc
and
>> Radar_Reflectivity_2018_0107_00_00.nc_new. I was able to do:
>>
>> bin/regrid_data_plane \
>> Radar_Reflectivity_2018_0107_00_00.nc \
>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
>> Radar_Reflectivity_2018_0107_00_00.nc_new \
>> -field 'name = "composite_n0q"; level = "(*,*)"; file_type =
NETCDF_MET;'
>> \
>> -v 4
>>
>> And get the remapping to work. I didn't try this is MODE, though,
because
>> the composite_n0q data is empty. But I'm curious if any of the
global
>> attribute data in Radar_Reflectivity_2018_0107_00_00.nc_new is
helpful in
>> figuring out what I need to run MODE?
>>
>> Thanks!
>> Sarah
>>
>> On 7/15/19 1:07 PM, John Halley Gotway via RT wrote:
>>
>> Sarah,
>>
>> What I'm recommending is that we go back to the original GOES-16
data, and
>> run it through regrid_data_plane to do that remapping step. If we
can get
>> that to work, it'll result in an output file that can easily be
read by
>> MODE.
>>
>> Otherwise, we're stuck with trying to get the CF-convention
specification
>> of the WRF domain exactly right, which can be pretty tedious.
>>
>> John
>>
>> On Mon, Jul 15, 2019 at 11:17 AM Sarah Griffin via RT
<met_help at ucar.edu
>>> <mailto:met_help at ucar.edu>
>> wrote:
>>
>>
>>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>
>> Hi John,
>>
>> The GOES-16 data I'm trying to use was created after remapping the
>> native GOES data to the WRF projection from
>>
>>
>> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
>> .
>>
>> So does it matter what the GOES projection is if I'm trying to
remap it
>> to a different projection?
>>
>> I've messed around some more and have gotten to this error on
>> regrid_data_plane. MetNcFile::data(NcVar *, const LongArray &,
DataPlane
>> &) const -> star found in bad slot
>>
>> when using this command:
>> bin/regrid_data_plane \
>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc \
>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
>> -field 'name = "channel_13_brightness_temperature"; level =
"(*,*)";
>> file_type = NETCDF_MET;' \
>> -v 4
>>
>> Thanks!
>> Sarah
>>
>> On 7/15/19 11:58 AM, John Halley Gotway via RT wrote:
>>
>>
>> Sarah,
>>
>> Can you please send me a link to the GOES-16 data you're trying to
use?
>>
>>
>> I
>>
>>
>> see you have a NetCDF file by this name:
>> emap_geocatL1.GOES-16.CONUS.2018007.000230.nc
>> Where did you get this file? Is is a publicly available ftp site?
>>
>> In general, MET reads gridded data that lives on regular
projections.
>>
>>
>> GOES
>>
>>
>> data is a special case... it is not defined on a projection.
Instead,
>>
>>
>> it's
>>
>>
>> a whole bunch of high resolution pixels of data. Each pixel has a
>>
>>
>> lat/lon
>>
>>
>> associated with it. We enhanced regrid_data_plane to read those
>>
>>
>> lat/lon's
>>
>>
>> and interpolate them to a user-requested domain.
>>
>> I'm hoping to get a sample GOES-16 file and send you example
commands for
>> interpolating it to your model domain using regrid_data_plane.
>>
>> Thanks,
>> John
>>
>> On Mon, Jul 15, 2019 at 9:28 AM Sarah Griffin via RT
<met_help at ucar.edu
>>> <mailto:met_help at ucar.edu>
>> wrote:
>>
>>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>
>> Hi John,
>>
>> Update, please ignore the other email I sent. Looks like I was
missing
>> '-field' instead of field.
>>
>> However, now I'm getting the error "ERROR :
>> NcCfFile::read_netcdf_grid() -> Couldn't figure out projection from
>> information in netCDF file." It seems like I'm a bit stuck because
I
>> don't know the projection. If I did, I wouldn't need to use
>> regrid_data_plane. Any thoughts?
>>
>> Thanks!
>> Sarah
>>
>> On 7/12/19 5:53 PM, John Halley Gotway via RT wrote:
>>
>>
>> Sarah,
>>
>> I'm pretty sure that didn't fix it entirely. When I plot the
channel
>>
>>
>> 15
>>
>>
>> data with plot_data_plane, I clearly see the outline of FL and the
>>
>>
>> Eastern
>>
>>
>> seaboard in the data, but it doesn't line up with the map data. So
>>
>>
>> there's
>>
>>
>> clearly still a problem.
>>
>> I see that you're using GOES-16 data here. MET's regrid_data_plane
>>
>>
>> tool
>>
>>
>> should be able to read GOES-16 data and regrid it to a user-defined
>>
>>
>> grid.
>>
>>
>> That would be another alternatively for using GOES-16 data in MET.
>>
>> Thanks,
>> John
>>
>> On Fri, Jul 12, 2019 at 4:45 PM John Halley Gotway <johnhg at ucar.edu
>>> <mailto:johnhg at ucar.edu>
>>
>> wrote:
>>
>>
>> Hi Sarah,
>>
>> Thought I'd chime in here to mention the following. This is not
>>
>>
>> actually
>>
>>
>> a problem in MODE tool itself, but more of an issue in how MET is
>>
>>
>> reading
>>
>>
>> data your input files and placing them on the earth. I usually
>>
>>
>> recommend
>>
>>
>> that people run MET's plot_data_plane tool when working with a new
>>
>>
>> data
>>
>>
>> source to make sure MET is reading the data well:
>>
>> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc> plot.ps
>> <http://plot.ps><http://plot.ps>
>> 'name="channel_10_brightness_temperature";
>>
>>
>> level="(*,*)";'
>>
>>
>> -v 4*
>>
>> This produces a nice looking plot, but there's no country outlines
on
>>
>>
>> top
>>
>>
>> of the data! And that usually indicates a problem in the
projection
>> information. But I did find one thing which seems to have helped.
I
>> changed the longitude_of_central_meridian from 262.5 to -97.5, by
>>
>>
>> running
>>
>>
>> the following command:
>>
>> *ncatted -a longitude_of_central_meridian,Projection,o,f,-97.5
>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc>
>> remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>*
>>
>> Those two longitudes are the same since they differ by 360 degrees.
>> Surprisingly, running plot_data_plane on that modified file did
plot
>>
>>
>> the
>>
>>
>> map data (see attached image):
>>
>> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc> plot.ps
>> <http://plot.ps><http://plot.ps>
>> 'name="channel_10_brightness_temperature";
>>
>>
>> level="(*,*)";'
>>
>>
>> -v 4*
>>
>> Can you confirm that the data lives on the right place on the
earth?
>> Should it be covering the Eastern CONUS and Atlantic? If so, then
>>
>>
>> we'll
>>
>>
>> likely need to make a one line fix in MET's library code to rescale
>>
>>
>> the
>>
>>
>> longitude values to the expected range of (-180, 180] when we read
>>
>>
>> them
>>
>>
>> in.
>>
>>
>> Thanks,
>> John
>>
>> On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT <
>>
>>
>> met_help at ucar.edu<mailto:met_help at ucar.edu>>
>>
>>
>> wrote:
>>
>>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>
>> On Fri Jul 12 14:56:24 2019, sarah.griffin at ssec.wisc.edu<mailto:
>> sarah.griffin at ssec.wisc.edu> wrote:
>>
>>
>> Hi,
>>
>> I'm using Met 8.0 with the bug fixes to run MODE for two netCDF
>>
>>
>> files.
>>
>>
>> MODE seems to run just fine, however the latitude and longitude of
>>
>>
>> the
>>
>>
>> output is messed up. How can I fix the latitude and longitude? I've
>> uploaded the data and MODE output to the met_help ftp directory.
>>
>>
>> Thanks!
>>
>>
>> Have a great day!
>> Sarah
>>
>>
>>
>> Hi Sarah -
>> Thanks for the data upload.
>> I've passed this ticket along to Randy, our resident MODE
specialist.
>> He should get a change to look at this early next week.
>> David
>>
>>
>>
>>
>> --
>>
>>
>>
>>
>>
>>
----------------------------------------------------------------------------
>>
>>
>> Sarah M. Griffin
>> Associate Research Scientist
>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>> UW-Madison
>> 1225 W Dayton St. Rm 243
>> Madison, WI 53706
>> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
>> (608) 262-0986
>>
>>
>>
>>
>>
>>
----------------------------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>
>>
----------------------------------------------------------------------------
>> Sarah M. Griffin
>> Associate Research Scientist
>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>> UW-Madison
>> 1225 W Dayton St. Rm 243
>> Madison, WI 53706
>> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
>> (608) 262-0986
>>
>>
>>
----------------------------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>
----------------------------------------------------------------------------
>> Sarah M. Griffin
>> Associate Research Scientist
>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>> UW-Madison
>> 1225 W Dayton St. Rm 243
>> Madison, WI 53706
>> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
>> (608) 262-0986
>>
>>
----------------------------------------------------------------------------
>>
>>
>>
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC UW-
Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu
(608) 262-0986
----------------------------------------------------------------------------
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #91053] Incorrect lat and lon data on objects
From: Sarah Griffin
Time: Mon Jul 15 13:35:18 2019
Hi John,
Reading this a bit more, can you try to run a regrid to the grid that
I
want, which can be found in:
Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc?
Unfortunately, remapping it to NCEP Grid 212 is not useful.
Have a great day!
Sarah
On 7/15/19 2:12 PM, John Halley Gotway via RT wrote:
> Sarah,
>
> I grabbed that file from the ftp site and see this header:
>
>
>
>
>
>
>
>
>
> *netcdf geocatL1.GOES-16.2018007.000200 {dimensions: x = 2312
;
> y = 1191 ;variables: float pixel_latitude(y, x) ;
float
> pixel_longitude(y, x) ; float
channel_13_brightness_temperature(y,
> x) ;}*
>
> The original GOES-16 file has much more metadata in it that
> regrid_data_plane expects and uses. I found some GOES-16 data on
our
> filesystem and am sending you an example of how it can be used by
> regrid_data_plane. Here's the sample data file:
>
> *ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
> <ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-
M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc>*
>
> And here's the command I ran to interpolate it to NCEP Grid 212
which
> covers CONUS:
>
> *met-8.1/bin/regrid_data_plane \*
> *goes-16/ABI/L1/CONUS/C10/2019196/OR_ABI-L1b-RadC-
M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
> \*
> *G212 goes16_g212.nc <http://goes16_g212.nc> -field 'name="Rad";
> level="(*,*)";' -method MAX -v 4*
>
> And then I plotted the result:
>
> *met-8.1/bin/plot_data_plane goes16_g212.nc <http://goes16_g212.nc>
> goes16_g212.ps <http://goes16_g212.ps> 'name="Rad"; level="(*,*)";'*
>
> And that plot is attached.
>
> John
>
> On Mon, Jul 15, 2019 at 12:37 PM Sarah Griffin via RT
<met_help at ucar.edu>
> wrote:
>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>
>> Hi John,
>>
>> Ok, I've added the original GOES-16 data to the ftp site. I've also
added '
>> geocatL1.GOES-16.2018007.000200.nc' since the original GOES-16 data
needs
>> to be rewritten to actually get the brightness temperatures.
>>
>> I then did:
>> bin/regrid_data_plane \
>> geocatL1.GOES-16.2018007.000200.nc \
>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
>> -field 'name = "channel_13_brightness_temperature"; level =
"(*,*)";
>> file_type = NETCDF_MET;' \
>> -v 4
>>
>> and got the same error "MetNcFile::data(NcVar *, const LongArray &,
>> DataPlane &) const -> star found in bad slot"
>>
>>
>>
>> I also added some radar data, Radar_Reflectivity_2018_0107_00_00.nc
and
>> Radar_Reflectivity_2018_0107_00_00.nc_new. I was able to do:
>>
>> bin/regrid_data_plane \
>> Radar_Reflectivity_2018_0107_00_00.nc \
>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
>> Radar_Reflectivity_2018_0107_00_00.nc_new \
>> -field 'name = "composite_n0q"; level = "(*,*)"; file_type =
NETCDF_MET;'
>> \
>> -v 4
>>
>> And get the remapping to work. I didn't try this is MODE, though,
because
>> the composite_n0q data is empty. But I'm curious if any of the
global
>> attribute data in Radar_Reflectivity_2018_0107_00_00.nc_new is
helpful in
>> figuring out what I need to run MODE?
>>
>> Thanks!
>> Sarah
>>
>> On 7/15/19 1:07 PM, John Halley Gotway via RT wrote:
>>
>> Sarah,
>>
>> What I'm recommending is that we go back to the original GOES-16
data, and
>> run it through regrid_data_plane to do that remapping step. If we
can get
>> that to work, it'll result in an output file that can easily be
read by
>> MODE.
>>
>> Otherwise, we're stuck with trying to get the CF-convention
specification
>> of the WRF domain exactly right, which can be pretty tedious.
>>
>> John
>>
>> On Mon, Jul 15, 2019 at 11:17 AM Sarah Griffin via RT
<met_help at ucar.edu
>>> <mailto:met_help at ucar.edu>
>> wrote:
>>
>>
>>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>
>> Hi John,
>>
>> The GOES-16 data I'm trying to use was created after remapping the
>> native GOES data to the WRF projection from
>>
>>
>> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
>> .
>>
>> So does it matter what the GOES projection is if I'm trying to
remap it
>> to a different projection?
>>
>> I've messed around some more and have gotten to this error on
>> regrid_data_plane. MetNcFile::data(NcVar *, const LongArray &,
DataPlane
>> &) const -> star found in bad slot
>>
>> when using this command:
>> bin/regrid_data_plane \
>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc \
>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
>> -field 'name = "channel_13_brightness_temperature"; level =
"(*,*)";
>> file_type = NETCDF_MET;' \
>> -v 4
>>
>> Thanks!
>> Sarah
>>
>> On 7/15/19 11:58 AM, John Halley Gotway via RT wrote:
>>
>>
>> Sarah,
>>
>> Can you please send me a link to the GOES-16 data you're trying to
use?
>>
>>
>> I
>>
>>
>> see you have a NetCDF file by this name:
>> emap_geocatL1.GOES-16.CONUS.2018007.000230.nc
>> Where did you get this file? Is is a publicly available ftp site?
>>
>> In general, MET reads gridded data that lives on regular
projections.
>>
>>
>> GOES
>>
>>
>> data is a special case... it is not defined on a projection.
Instead,
>>
>>
>> it's
>>
>>
>> a whole bunch of high resolution pixels of data. Each pixel has a
>>
>>
>> lat/lon
>>
>>
>> associated with it. We enhanced regrid_data_plane to read those
>>
>>
>> lat/lon's
>>
>>
>> and interpolate them to a user-requested domain.
>>
>> I'm hoping to get a sample GOES-16 file and send you example
commands for
>> interpolating it to your model domain using regrid_data_plane.
>>
>> Thanks,
>> John
>>
>> On Mon, Jul 15, 2019 at 9:28 AM Sarah Griffin via RT
<met_help at ucar.edu
>>> <mailto:met_help at ucar.edu>
>> wrote:
>>
>>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>
>> Hi John,
>>
>> Update, please ignore the other email I sent. Looks like I was
missing
>> '-field' instead of field.
>>
>> However, now I'm getting the error "ERROR :
>> NcCfFile::read_netcdf_grid() -> Couldn't figure out projection from
>> information in netCDF file." It seems like I'm a bit stuck because
I
>> don't know the projection. If I did, I wouldn't need to use
>> regrid_data_plane. Any thoughts?
>>
>> Thanks!
>> Sarah
>>
>> On 7/12/19 5:53 PM, John Halley Gotway via RT wrote:
>>
>>
>> Sarah,
>>
>> I'm pretty sure that didn't fix it entirely. When I plot the
channel
>>
>>
>> 15
>>
>>
>> data with plot_data_plane, I clearly see the outline of FL and the
>>
>>
>> Eastern
>>
>>
>> seaboard in the data, but it doesn't line up with the map data. So
>>
>>
>> there's
>>
>>
>> clearly still a problem.
>>
>> I see that you're using GOES-16 data here. MET's regrid_data_plane
>>
>>
>> tool
>>
>>
>> should be able to read GOES-16 data and regrid it to a user-defined
>>
>>
>> grid.
>>
>>
>> That would be another alternatively for using GOES-16 data in MET.
>>
>> Thanks,
>> John
>>
>> On Fri, Jul 12, 2019 at 4:45 PM John Halley Gotway <johnhg at ucar.edu
>>> <mailto:johnhg at ucar.edu>
>>
>> wrote:
>>
>>
>> Hi Sarah,
>>
>> Thought I'd chime in here to mention the following. This is not
>>
>>
>> actually
>>
>>
>> a problem in MODE tool itself, but more of an issue in how MET is
>>
>>
>> reading
>>
>>
>> data your input files and placing them on the earth. I usually
>>
>>
>> recommend
>>
>>
>> that people run MET's plot_data_plane tool when working with a new
>>
>>
>> data
>>
>>
>> source to make sure MET is reading the data well:
>>
>> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc> plot.ps
>> <http://plot.ps><http://plot.ps>
>> 'name="channel_10_brightness_temperature";
>>
>>
>> level="(*,*)";'
>>
>>
>> -v 4*
>>
>> This produces a nice looking plot, but there's no country outlines
on
>>
>>
>> top
>>
>>
>> of the data! And that usually indicates a problem in the
projection
>> information. But I did find one thing which seems to have helped.
I
>> changed the longitude_of_central_meridian from 262.5 to -97.5, by
>>
>>
>> running
>>
>>
>> the following command:
>>
>> *ncatted -a longitude_of_central_meridian,Projection,o,f,-97.5
>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc>
>> remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>*
>>
>> Those two longitudes are the same since they differ by 360 degrees.
>> Surprisingly, running plot_data_plane on that modified file did
plot
>>
>>
>> the
>>
>>
>> map data (see attached image):
>>
>> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc> plot.ps
>> <http://plot.ps><http://plot.ps>
>> 'name="channel_10_brightness_temperature";
>>
>>
>> level="(*,*)";'
>>
>>
>> -v 4*
>>
>> Can you confirm that the data lives on the right place on the
earth?
>> Should it be covering the Eastern CONUS and Atlantic? If so, then
>>
>>
>> we'll
>>
>>
>> likely need to make a one line fix in MET's library code to rescale
>>
>>
>> the
>>
>>
>> longitude values to the expected range of (-180, 180] when we read
>>
>>
>> them
>>
>>
>> in.
>>
>>
>> Thanks,
>> John
>>
>> On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT <
>>
>>
>> met_help at ucar.edu<mailto:met_help at ucar.edu>>
>>
>>
>> wrote:
>>
>>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>
>> On Fri Jul 12 14:56:24 2019, sarah.griffin at ssec.wisc.edu<mailto:
>> sarah.griffin at ssec.wisc.edu> wrote:
>>
>>
>> Hi,
>>
>> I'm using Met 8.0 with the bug fixes to run MODE for two netCDF
>>
>>
>> files.
>>
>>
>> MODE seems to run just fine, however the latitude and longitude of
>>
>>
>> the
>>
>>
>> output is messed up. How can I fix the latitude and longitude? I've
>> uploaded the data and MODE output to the met_help ftp directory.
>>
>>
>> Thanks!
>>
>>
>> Have a great day!
>> Sarah
>>
>>
>>
>> Hi Sarah -
>> Thanks for the data upload.
>> I've passed this ticket along to Randy, our resident MODE
specialist.
>> He should get a change to look at this early next week.
>> David
>>
>>
>>
>>
>> --
>>
>>
>>
>>
>>
>>
----------------------------------------------------------------------------
>>
>>
>> Sarah M. Griffin
>> Associate Research Scientist
>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>> UW-Madison
>> 1225 W Dayton St. Rm 243
>> Madison, WI 53706
>> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
>> (608) 262-0986
>>
>>
>>
>>
>>
>>
----------------------------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>
>>
----------------------------------------------------------------------------
>> Sarah M. Griffin
>> Associate Research Scientist
>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>> UW-Madison
>> 1225 W Dayton St. Rm 243
>> Madison, WI 53706
>> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
>> (608) 262-0986
>>
>>
>>
----------------------------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>
----------------------------------------------------------------------------
>> Sarah M. Griffin
>> Associate Research Scientist
>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>> UW-Madison
>> 1225 W Dayton St. Rm 243
>> Madison, WI 53706
>> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
>> (608) 262-0986
>>
>>
----------------------------------------------------------------------------
>>
>>
>>
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC UW-
Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu
(608) 262-0986
----------------------------------------------------------------------------
------------------------------------------------
Subject: Incorrect lat and lon data on objects
From: John Halley Gotway
Time: Mon Jul 15 13:40:55 2019
I just posted it. But realize that the whole point is that you can
generate it yourself by running the regrid_data_plane command. And
instead
of using "G212" on the command, just list a gridded data file that MET
knows how to read that's already on your desired model domain. The
tool
will read the grid info from that gridded data file and regrid the
input
GOES-16 values to that domain.
Thanks,
John
On Mon, Jul 15, 2019 at 1:36 PM Sarah Griffin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> Reading this a bit more, can you try to run a regrid to the grid
that I
> want, which can be found in:
> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc?
> Unfortunately, remapping it to NCEP Grid 212 is not useful.
>
> Have a great day!
> Sarah
>
> On 7/15/19 2:12 PM, John Halley Gotway via RT wrote:
> > Sarah,
> >
> > I grabbed that file from the ftp site and see this header:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > *netcdf geocatL1.GOES-16.2018007.000200 {dimensions: x =
2312 ;
> > y = 1191 ;variables: float pixel_latitude(y, x) ;
float
> > pixel_longitude(y, x) ; float
channel_13_brightness_temperature(y,
> > x) ;}*
> >
> > The original GOES-16 file has much more metadata in it that
> > regrid_data_plane expects and uses. I found some GOES-16 data on
our
> > filesystem and am sending you an example of how it can be used by
> > regrid_data_plane. Here's the sample data file:
> >
> > *
> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
> > <
> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
> >*
> >
> > And here's the command I ran to interpolate it to NCEP Grid 212
which
> > covers CONUS:
> >
> > *met-8.1/bin/regrid_data_plane \*
> >
> *goes-16/ABI/L1/CONUS/C10/2019196/OR_ABI-L1b-RadC-
M6C10_G16_s20191961811348_e20191961814132_
> c20191961814170.nc
> > \*
> > *G212 goes16_g212.nc <http://goes16_g212.nc> -field 'name="Rad";
> > level="(*,*)";' -method MAX -v 4*
> >
> > And then I plotted the result:
> >
> > *met-8.1/bin/plot_data_plane goes16_g212.nc
<http://goes16_g212.nc>
> > goes16_g212.ps <http://goes16_g212.ps> 'name="Rad";
level="(*,*)";'*
> >
> > And that plot is attached.
> >
> > John
> >
> > On Mon, Jul 15, 2019 at 12:37 PM Sarah Griffin via RT
<met_help at ucar.edu
> >
> > wrote:
> >
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
> >>
> >> Hi John,
> >>
> >> Ok, I've added the original GOES-16 data to the ftp site. I've
also
> added '
> >> geocatL1.GOES-16.2018007.000200.nc' since the original GOES-16
data
> needs
> >> to be rewritten to actually get the brightness temperatures.
> >>
> >> I then did:
> >> bin/regrid_data_plane \
> >> geocatL1.GOES-16.2018007.000200.nc \
> >> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
> >> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
> >> -field 'name = "channel_13_brightness_temperature"; level =
"(*,*)";
> >> file_type = NETCDF_MET;' \
> >> -v 4
> >>
> >> and got the same error "MetNcFile::data(NcVar *, const LongArray
&,
> >> DataPlane &) const -> star found in bad slot"
> >>
> >>
> >>
> >> I also added some radar data,
Radar_Reflectivity_2018_0107_00_00.nc and
> >> Radar_Reflectivity_2018_0107_00_00.nc_new. I was able to do:
> >>
> >> bin/regrid_data_plane \
> >> Radar_Reflectivity_2018_0107_00_00.nc \
> >> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
> >> Radar_Reflectivity_2018_0107_00_00.nc_new \
> >> -field 'name = "composite_n0q"; level = "(*,*)"; file_type =
> NETCDF_MET;'
> >> \
> >> -v 4
> >>
> >> And get the remapping to work. I didn't try this is MODE, though,
> because
> >> the composite_n0q data is empty. But I'm curious if any of the
global
> >> attribute data in Radar_Reflectivity_2018_0107_00_00.nc_new is
helpful
> in
> >> figuring out what I need to run MODE?
> >>
> >> Thanks!
> >> Sarah
> >>
> >> On 7/15/19 1:07 PM, John Halley Gotway via RT wrote:
> >>
> >> Sarah,
> >>
> >> What I'm recommending is that we go back to the original GOES-16
data,
> and
> >> run it through regrid_data_plane to do that remapping step. If
we can
> get
> >> that to work, it'll result in an output file that can easily be
read by
> >> MODE.
> >>
> >> Otherwise, we're stuck with trying to get the CF-convention
> specification
> >> of the WRF domain exactly right, which can be pretty tedious.
> >>
> >> John
> >>
> >> On Mon, Jul 15, 2019 at 11:17 AM Sarah Griffin via RT <
> met_help at ucar.edu
> >>> <mailto:met_help at ucar.edu>
> >> wrote:
> >>
> >>
> >>
> >>
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
> >>
> >> Hi John,
> >>
> >> The GOES-16 data I'm trying to use was created after remapping
the
> >> native GOES data to the WRF projection from
> >>
> >>
> >>
> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
> >> .
> >>
> >> So does it matter what the GOES projection is if I'm trying to
remap it
> >> to a different projection?
> >>
> >> I've messed around some more and have gotten to this error on
> >> regrid_data_plane. MetNcFile::data(NcVar *, const LongArray &,
DataPlane
> >> &) const -> star found in bad slot
> >>
> >> when using this command:
> >> bin/regrid_data_plane \
> >> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc \
> >> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
> >> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
> >> -field 'name = "channel_13_brightness_temperature"; level =
"(*,*)";
> >> file_type = NETCDF_MET;' \
> >> -v 4
> >>
> >> Thanks!
> >> Sarah
> >>
> >> On 7/15/19 11:58 AM, John Halley Gotway via RT wrote:
> >>
> >>
> >> Sarah,
> >>
> >> Can you please send me a link to the GOES-16 data you're trying
to use?
> >>
> >>
> >> I
> >>
> >>
> >> see you have a NetCDF file by this name:
> >> emap_geocatL1.GOES-16.CONUS.2018007.000230.nc
> >> Where did you get this file? Is is a publicly available ftp
site?
> >>
> >> In general, MET reads gridded data that lives on regular
projections.
> >>
> >>
> >> GOES
> >>
> >>
> >> data is a special case... it is not defined on a projection.
Instead,
> >>
> >>
> >> it's
> >>
> >>
> >> a whole bunch of high resolution pixels of data. Each pixel has
a
> >>
> >>
> >> lat/lon
> >>
> >>
> >> associated with it. We enhanced regrid_data_plane to read those
> >>
> >>
> >> lat/lon's
> >>
> >>
> >> and interpolate them to a user-requested domain.
> >>
> >> I'm hoping to get a sample GOES-16 file and send you example
commands
> for
> >> interpolating it to your model domain using regrid_data_plane.
> >>
> >> Thanks,
> >> John
> >>
> >> On Mon, Jul 15, 2019 at 9:28 AM Sarah Griffin via RT
<met_help at ucar.edu
> >>> <mailto:met_help at ucar.edu>
> >> wrote:
> >>
> >>
> >>
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
> >>
> >> Hi John,
> >>
> >> Update, please ignore the other email I sent. Looks like I was
missing
> >> '-field' instead of field.
> >>
> >> However, now I'm getting the error "ERROR :
> >> NcCfFile::read_netcdf_grid() -> Couldn't figure out projection
from
> >> information in netCDF file." It seems like I'm a bit stuck
because I
> >> don't know the projection. If I did, I wouldn't need to use
> >> regrid_data_plane. Any thoughts?
> >>
> >> Thanks!
> >> Sarah
> >>
> >> On 7/12/19 5:53 PM, John Halley Gotway via RT wrote:
> >>
> >>
> >> Sarah,
> >>
> >> I'm pretty sure that didn't fix it entirely. When I plot the
channel
> >>
> >>
> >> 15
> >>
> >>
> >> data with plot_data_plane, I clearly see the outline of FL and
the
> >>
> >>
> >> Eastern
> >>
> >>
> >> seaboard in the data, but it doesn't line up with the map data.
So
> >>
> >>
> >> there's
> >>
> >>
> >> clearly still a problem.
> >>
> >> I see that you're using GOES-16 data here. MET's
regrid_data_plane
> >>
> >>
> >> tool
> >>
> >>
> >> should be able to read GOES-16 data and regrid it to a user-
defined
> >>
> >>
> >> grid.
> >>
> >>
> >> That would be another alternatively for using GOES-16 data in
MET.
> >>
> >> Thanks,
> >> John
> >>
> >> On Fri, Jul 12, 2019 at 4:45 PM John Halley Gotway
<johnhg at ucar.edu
> >>> <mailto:johnhg at ucar.edu>
> >>
> >> wrote:
> >>
> >>
> >> Hi Sarah,
> >>
> >> Thought I'd chime in here to mention the following. This is not
> >>
> >>
> >> actually
> >>
> >>
> >> a problem in MODE tool itself, but more of an issue in how MET is
> >>
> >>
> >> reading
> >>
> >>
> >> data your input files and placing them on the earth. I usually
> >>
> >>
> >> recommend
> >>
> >>
> >> that people run MET's plot_data_plane tool when working with a
new
> >>
> >>
> >> data
> >>
> >>
> >> source to make sure MET is reading the data well:
> >>
> >> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
> >> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> >> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc> plot.ps
> >> <http://plot.ps><http://plot.ps>
> >> 'name="channel_10_brightness_temperature";
> >>
> >>
> >> level="(*,*)";'
> >>
> >>
> >> -v 4*
> >>
> >> This produces a nice looking plot, but there's no country
outlines on
> >>
> >>
> >> top
> >>
> >>
> >> of the data! And that usually indicates a problem in the
projection
> >> information. But I did find one thing which seems to have
helped. I
> >> changed the longitude_of_central_meridian from 262.5 to -97.5, by
> >>
> >>
> >> running
> >>
> >>
> >> the following command:
> >>
> >> *ncatted -a longitude_of_central_meridian,Projection,o,f,-97.5
> >> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
> >> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> >> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc>
> >> remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
> >> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> >> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>*
> >>
> >> Those two longitudes are the same since they differ by 360
degrees.
> >> Surprisingly, running plot_data_plane on that modified file did
plot
> >>
> >>
> >> the
> >>
> >>
> >> map data (see attached image):
> >>
> >> *plot_data_plane remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc
> >> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> >> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>
plot.ps
> >> <http://plot.ps><http://plot.ps>
> >> 'name="channel_10_brightness_temperature";
> >>
> >>
> >> level="(*,*)";'
> >>
> >>
> >> -v 4*
> >>
> >> Can you confirm that the data lives on the right place on the
earth?
> >> Should it be covering the Eastern CONUS and Atlantic? If so,
then
> >>
> >>
> >> we'll
> >>
> >>
> >> likely need to make a one line fix in MET's library code to
rescale
> >>
> >>
> >> the
> >>
> >>
> >> longitude values to the expected range of (-180, 180] when we
read
> >>
> >>
> >> them
> >>
> >>
> >> in.
> >>
> >>
> >> Thanks,
> >> John
> >>
> >> On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT <
> >>
> >>
> >> met_help at ucar.edu<mailto:met_help at ucar.edu>>
> >>
> >>
> >> wrote:
> >>
> >>
> >>
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
> >>
> >> On Fri Jul 12 14:56:24 2019, sarah.griffin at ssec.wisc.edu<mailto:
> >> sarah.griffin at ssec.wisc.edu> wrote:
> >>
> >>
> >> Hi,
> >>
> >> I'm using Met 8.0 with the bug fixes to run MODE for two netCDF
> >>
> >>
> >> files.
> >>
> >>
> >> MODE seems to run just fine, however the latitude and longitude
of
> >>
> >>
> >> the
> >>
> >>
> >> output is messed up. How can I fix the latitude and longitude?
I've
> >> uploaded the data and MODE output to the met_help ftp directory.
> >>
> >>
> >> Thanks!
> >>
> >>
> >> Have a great day!
> >> Sarah
> >>
> >>
> >>
> >> Hi Sarah -
> >> Thanks for the data upload.
> >> I've passed this ticket along to Randy, our resident MODE
specialist.
> >> He should get a change to look at this early next week.
> >> David
> >>
> >>
> >>
> >>
> >> --
> >>
> >>
> >>
> >>
> >>
> >>
>
----------------------------------------------------------------------------
> >>
> >>
> >> Sarah M. Griffin
> >> Associate Research Scientist
> >> Cooperative Institute for Meteorological Satellite Studies / SSEC
> >> UW-Madison
> >> 1225 W Dayton St. Rm 243
> >> Madison, WI 53706
> >> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
> >> (608) 262-0986
> >>
> >>
> >>
> >>
> >>
> >>
>
----------------------------------------------------------------------------
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >>
> >>
> >>
>
----------------------------------------------------------------------------
> >> Sarah M. Griffin
> >> Associate Research Scientist
> >> Cooperative Institute for Meteorological Satellite Studies / SSEC
> >> UW-Madison
> >> 1225 W Dayton St. Rm 243
> >> Madison, WI 53706
> >> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
> >> (608) 262-0986
> >>
> >>
> >>
>
----------------------------------------------------------------------------
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >>
> >>
>
----------------------------------------------------------------------------
> >> Sarah M. Griffin
> >> Associate Research Scientist
> >> Cooperative Institute for Meteorological Satellite Studies / SSEC
> >> UW-Madison
> >> 1225 W Dayton St. Rm 243
> >> Madison, WI 53706
> >> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
> >> (608) 262-0986
> >>
> >>
>
----------------------------------------------------------------------------
> >>
> >>
> >>
>
>
> --
>
>
----------------------------------------------------------------------------
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
> sarah.griffin at ssec.wisc.edu
> (608) 262-0986
>
>
----------------------------------------------------------------------------
>
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #91053] Incorrect lat and lon data on objects
From: Sarah Griffin
Time: Mon Jul 15 13:50:39 2019
When you say "gridded data file" does that not include a netCDF file?
I'm trying to use a netCDF file as a grid, which I thought MET knows
how
to read. However, I ran my file using regrid_data_plane and then mode
and I get this file
(mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_19700101_000000V_NAA.ps)
that I uploaded and the grid is still offset from when I want. Can you
please test and see what happens when you use my file
Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc as the grid
instead of G212?
Also, what does
MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
found in bad slot
mean?
Thanks!
Sarah
On 7/15/19 2:40 PM, John Halley Gotway via RT wrote:
> I just posted it. But realize that the whole point is that you can
> generate it yourself by running the regrid_data_plane command. And
instead
> of using "G212" on the command, just list a gridded data file that
MET
> knows how to read that's already on your desired model domain. The
tool
> will read the grid info from that gridded data file and regrid the
input
> GOES-16 values to that domain.
>
> Thanks,
> John
>
> On Mon, Jul 15, 2019 at 1:36 PM Sarah Griffin via RT
<met_help at ucar.edu>
> wrote:
>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>
>> Hi John,
>>
>> Reading this a bit more, can you try to run a regrid to the grid
that I
>> want, which can be found in:
>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc?
>> Unfortunately, remapping it to NCEP Grid 212 is not useful.
>>
>> Have a great day!
>> Sarah
>>
>> On 7/15/19 2:12 PM, John Halley Gotway via RT wrote:
>>> Sarah,
>>>
>>> I grabbed that file from the ftp site and see this header:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *netcdf geocatL1.GOES-16.2018007.000200 {dimensions: x =
2312 ;
>>> y = 1191 ;variables: float pixel_latitude(y, x) ;
float
>>> pixel_longitude(y, x) ; float
channel_13_brightness_temperature(y,
>>> x) ;}*
>>>
>>> The original GOES-16 file has much more metadata in it that
>>> regrid_data_plane expects and uses. I found some GOES-16 data on
our
>>> filesystem and am sending you an example of how it can be used by
>>> regrid_data_plane. Here's the sample data file:
>>>
>>> *
>> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
>>> <
>> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
>>> *
>>>
>>> And here's the command I ran to interpolate it to NCEP Grid 212
which
>>> covers CONUS:
>>>
>>> *met-8.1/bin/regrid_data_plane \*
>>>
>> *goes-16/ABI/L1/CONUS/C10/2019196/OR_ABI-L1b-RadC-
M6C10_G16_s20191961811348_e20191961814132_
>> c20191961814170.nc
>>> \*
>>> *G212 goes16_g212.nc <http://goes16_g212.nc> -field 'name="Rad";
>>> level="(*,*)";' -method MAX -v 4*
>>>
>>> And then I plotted the result:
>>>
>>> *met-8.1/bin/plot_data_plane goes16_g212.nc
<http://goes16_g212.nc>
>>> goes16_g212.ps <http://goes16_g212.ps> 'name="Rad";
level="(*,*)";'*
>>>
>>> And that plot is attached.
>>>
>>> John
>>>
>>> On Mon, Jul 15, 2019 at 12:37 PM Sarah Griffin via RT
<met_help at ucar.edu
>>>
>>> wrote:
>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>>>
>>>> Hi John,
>>>>
>>>> Ok, I've added the original GOES-16 data to the ftp site. I've
also
>> added '
>>>> geocatL1.GOES-16.2018007.000200.nc' since the original GOES-16
data
>> needs
>>>> to be rewritten to actually get the brightness temperatures.
>>>>
>>>> I then did:
>>>> bin/regrid_data_plane \
>>>> geocatL1.GOES-16.2018007.000200.nc \
>>>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
>>>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
>>>> -field 'name = "channel_13_brightness_temperature"; level =
"(*,*)";
>>>> file_type = NETCDF_MET;' \
>>>> -v 4
>>>>
>>>> and got the same error "MetNcFile::data(NcVar *, const LongArray
&,
>>>> DataPlane &) const -> star found in bad slot"
>>>>
>>>>
>>>>
>>>> I also added some radar data,
Radar_Reflectivity_2018_0107_00_00.nc and
>>>> Radar_Reflectivity_2018_0107_00_00.nc_new. I was able to do:
>>>>
>>>> bin/regrid_data_plane \
>>>> Radar_Reflectivity_2018_0107_00_00.nc \
>>>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
>>>> Radar_Reflectivity_2018_0107_00_00.nc_new \
>>>> -field 'name = "composite_n0q"; level = "(*,*)"; file_type =
>> NETCDF_MET;'
>>>> \
>>>> -v 4
>>>>
>>>> And get the remapping to work. I didn't try this is MODE, though,
>> because
>>>> the composite_n0q data is empty. But I'm curious if any of the
global
>>>> attribute data in Radar_Reflectivity_2018_0107_00_00.nc_new is
helpful
>> in
>>>> figuring out what I need to run MODE?
>>>>
>>>> Thanks!
>>>> Sarah
>>>>
>>>> On 7/15/19 1:07 PM, John Halley Gotway via RT wrote:
>>>>
>>>> Sarah,
>>>>
>>>> What I'm recommending is that we go back to the original GOES-16
data,
>> and
>>>> run it through regrid_data_plane to do that remapping step. If
we can
>> get
>>>> that to work, it'll result in an output file that can easily be
read by
>>>> MODE.
>>>>
>>>> Otherwise, we're stuck with trying to get the CF-convention
>> specification
>>>> of the WRF domain exactly right, which can be pretty tedious.
>>>>
>>>> John
>>>>
>>>> On Mon, Jul 15, 2019 at 11:17 AM Sarah Griffin via RT <
>> met_help at ucar.edu
>>>>> <mailto:met_help at ucar.edu>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>>>
>>>> Hi John,
>>>>
>>>> The GOES-16 data I'm trying to use was created after remapping
the
>>>> native GOES data to the WRF projection from
>>>>
>>>>
>>>>
>> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
>>>> .
>>>>
>>>> So does it matter what the GOES projection is if I'm trying to
remap it
>>>> to a different projection?
>>>>
>>>> I've messed around some more and have gotten to this error on
>>>> regrid_data_plane. MetNcFile::data(NcVar *, const LongArray &,
DataPlane
>>>> &) const -> star found in bad slot
>>>>
>>>> when using this command:
>>>> bin/regrid_data_plane \
>>>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc \
>>>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
>>>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
>>>> -field 'name = "channel_13_brightness_temperature"; level =
"(*,*)";
>>>> file_type = NETCDF_MET;' \
>>>> -v 4
>>>>
>>>> Thanks!
>>>> Sarah
>>>>
>>>> On 7/15/19 11:58 AM, John Halley Gotway via RT wrote:
>>>>
>>>>
>>>> Sarah,
>>>>
>>>> Can you please send me a link to the GOES-16 data you're trying
to use?
>>>>
>>>>
>>>> I
>>>>
>>>>
>>>> see you have a NetCDF file by this name:
>>>> emap_geocatL1.GOES-16.CONUS.2018007.000230.nc
>>>> Where did you get this file? Is is a publicly available ftp
site?
>>>>
>>>> In general, MET reads gridded data that lives on regular
projections.
>>>>
>>>>
>>>> GOES
>>>>
>>>>
>>>> data is a special case... it is not defined on a projection.
Instead,
>>>>
>>>>
>>>> it's
>>>>
>>>>
>>>> a whole bunch of high resolution pixels of data. Each pixel has
a
>>>>
>>>>
>>>> lat/lon
>>>>
>>>>
>>>> associated with it. We enhanced regrid_data_plane to read those
>>>>
>>>>
>>>> lat/lon's
>>>>
>>>>
>>>> and interpolate them to a user-requested domain.
>>>>
>>>> I'm hoping to get a sample GOES-16 file and send you example
commands
>> for
>>>> interpolating it to your model domain using regrid_data_plane.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>> On Mon, Jul 15, 2019 at 9:28 AM Sarah Griffin via RT
<met_help at ucar.edu
>>>>> <mailto:met_help at ucar.edu>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>>>
>>>> Hi John,
>>>>
>>>> Update, please ignore the other email I sent. Looks like I was
missing
>>>> '-field' instead of field.
>>>>
>>>> However, now I'm getting the error "ERROR :
>>>> NcCfFile::read_netcdf_grid() -> Couldn't figure out projection
from
>>>> information in netCDF file." It seems like I'm a bit stuck
because I
>>>> don't know the projection. If I did, I wouldn't need to use
>>>> regrid_data_plane. Any thoughts?
>>>>
>>>> Thanks!
>>>> Sarah
>>>>
>>>> On 7/12/19 5:53 PM, John Halley Gotway via RT wrote:
>>>>
>>>>
>>>> Sarah,
>>>>
>>>> I'm pretty sure that didn't fix it entirely. When I plot the
channel
>>>>
>>>>
>>>> 15
>>>>
>>>>
>>>> data with plot_data_plane, I clearly see the outline of FL and
the
>>>>
>>>>
>>>> Eastern
>>>>
>>>>
>>>> seaboard in the data, but it doesn't line up with the map data.
So
>>>>
>>>>
>>>> there's
>>>>
>>>>
>>>> clearly still a problem.
>>>>
>>>> I see that you're using GOES-16 data here. MET's
regrid_data_plane
>>>>
>>>>
>>>> tool
>>>>
>>>>
>>>> should be able to read GOES-16 data and regrid it to a user-
defined
>>>>
>>>>
>>>> grid.
>>>>
>>>>
>>>> That would be another alternatively for using GOES-16 data in
MET.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>> On Fri, Jul 12, 2019 at 4:45 PM John Halley Gotway
<johnhg at ucar.edu
>>>>> <mailto:johnhg at ucar.edu>
>>>> wrote:
>>>>
>>>>
>>>> Hi Sarah,
>>>>
>>>> Thought I'd chime in here to mention the following. This is not
>>>>
>>>>
>>>> actually
>>>>
>>>>
>>>> a problem in MODE tool itself, but more of an issue in how MET is
>>>>
>>>>
>>>> reading
>>>>
>>>>
>>>> data your input files and placing them on the earth. I usually
>>>>
>>>>
>>>> recommend
>>>>
>>>>
>>>> that people run MET's plot_data_plane tool when working with a
new
>>>>
>>>>
>>>> data
>>>>
>>>>
>>>> source to make sure MET is reading the data well:
>>>>
>>>> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
>>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>>>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc> plot.ps
>>>> <http://plot.ps><http://plot.ps>
>>>> 'name="channel_10_brightness_temperature";
>>>>
>>>>
>>>> level="(*,*)";'
>>>>
>>>>
>>>> -v 4*
>>>>
>>>> This produces a nice looking plot, but there's no country
outlines on
>>>>
>>>>
>>>> top
>>>>
>>>>
>>>> of the data! And that usually indicates a problem in the
projection
>>>> information. But I did find one thing which seems to have
helped. I
>>>> changed the longitude_of_central_meridian from 262.5 to -97.5, by
>>>>
>>>>
>>>> running
>>>>
>>>>
>>>> the following command:
>>>>
>>>> *ncatted -a longitude_of_central_meridian,Projection,o,f,-97.5
>>>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
>>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>>>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc>
>>>> remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
>>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>>>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>*
>>>>
>>>> Those two longitudes are the same since they differ by 360
degrees.
>>>> Surprisingly, running plot_data_plane on that modified file did
plot
>>>>
>>>>
>>>> the
>>>>
>>>>
>>>> map data (see attached image):
>>>>
>>>> *plot_data_plane remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc
>>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>>>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>
plot.ps
>>>> <http://plot.ps><http://plot.ps>
>>>> 'name="channel_10_brightness_temperature";
>>>>
>>>>
>>>> level="(*,*)";'
>>>>
>>>>
>>>> -v 4*
>>>>
>>>> Can you confirm that the data lives on the right place on the
earth?
>>>> Should it be covering the Eastern CONUS and Atlantic? If so,
then
>>>>
>>>>
>>>> we'll
>>>>
>>>>
>>>> likely need to make a one line fix in MET's library code to
rescale
>>>>
>>>>
>>>> the
>>>>
>>>>
>>>> longitude values to the expected range of (-180, 180] when we
read
>>>>
>>>>
>>>> them
>>>>
>>>>
>>>> in.
>>>>
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>> On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT <
>>>>
>>>>
>>>> met_help at ucar.edu<mailto:met_help at ucar.edu>>
>>>>
>>>>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>>>
>>>> On Fri Jul 12 14:56:24 2019, sarah.griffin at ssec.wisc.edu<mailto:
>>>> sarah.griffin at ssec.wisc.edu> wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I'm using Met 8.0 with the bug fixes to run MODE for two netCDF
>>>>
>>>>
>>>> files.
>>>>
>>>>
>>>> MODE seems to run just fine, however the latitude and longitude
of
>>>>
>>>>
>>>> the
>>>>
>>>>
>>>> output is messed up. How can I fix the latitude and longitude?
I've
>>>> uploaded the data and MODE output to the met_help ftp directory.
>>>>
>>>>
>>>> Thanks!
>>>>
>>>>
>>>> Have a great day!
>>>> Sarah
>>>>
>>>>
>>>>
>>>> Hi Sarah -
>>>> Thanks for the data upload.
>>>> I've passed this ticket along to Randy, our resident MODE
specialist.
>>>> He should get a change to look at this early next week.
>>>> David
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
----------------------------------------------------------------------------
>>>>
>>>> Sarah M. Griffin
>>>> Associate Research Scientist
>>>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>>>> UW-Madison
>>>> 1225 W Dayton St. Rm 243
>>>> Madison, WI 53706
>>>> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
>>>> (608) 262-0986
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
----------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>>
>>
----------------------------------------------------------------------------
>>>> Sarah M. Griffin
>>>> Associate Research Scientist
>>>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>>>> UW-Madison
>>>> 1225 W Dayton St. Rm 243
>>>> Madison, WI 53706
>>>> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
>>>> (608) 262-0986
>>>>
>>>>
>>>>
>>
----------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>
----------------------------------------------------------------------------
>>>> Sarah M. Griffin
>>>> Associate Research Scientist
>>>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>>>> UW-Madison
>>>> 1225 W Dayton St. Rm 243
>>>> Madison, WI 53706
>>>> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
>>>> (608) 262-0986
>>>>
>>>>
>>
----------------------------------------------------------------------------
>>>>
>>>>
>>
>> --
>>
>>
----------------------------------------------------------------------------
>> Sarah M. Griffin
>> Associate Research Scientist
>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>> UW-Madison
>> 1225 W Dayton St. Rm 243
>> Madison, WI 53706
>> sarah.griffin at ssec.wisc.edu
>> (608) 262-0986
>>
>>
----------------------------------------------------------------------------
>>
>>
>>
>>
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC UW-
Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu
(608) 262-0986
----------------------------------------------------------------------------
------------------------------------------------
Subject: Incorrect lat and lon data on objects
From: John Halley Gotway
Time: Mon Jul 15 16:22:14 2019
Sarah,
OK, I just ran the following command:
*regrid_data_plane \*
*OR_ABI-L1b-RadC-
M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
\*
*mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
<http://mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc>
\*
*goes16_MODE_GRID.nc \*
*-field 'name="Rad"; level="(*,*)";'*
And that produced an output file with bad data values everywhere. The
problem is that the projection information in that MODE output file is
messed up in some way (
mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc)...
which was the original reason you wrote.
So I tried a different route. The "to_grid" option for
regrid_data_plane
can be defined as a named grid (i.e. G212), the path to a gridded data
file, or an explicit grid definition. I tried the latter. Below is
an
excerpt from met-8.1/share/met/config/README:
// - to_grid = "spec"; To define a grid specified as follows:
// - lambert Nx Ny lat_ll lon_ll lon_orient D_km R_km
standard_parallel_1
// [standard_parallel_2] N|S
I used the metadata from the NetCDF files you sent to define the
following
grid definition info:
'lambert 1535 1023 22.45395 -119.2807 262.5 3 6371.2 38.5 N'
And I ran this command:
*regrid_data_plane \*
*OR_ABI-L1b-RadC-
M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
\*
*'lambert 1535 1023 22.45395 -119.2807 262.5 3 6371.2 38.5 N' \*
*goes16_USER_DEFINED.nc -field 'name="Rad"; level="(*,*)";'*
And plotted the output. The result (see attached) looks much more
promising. I assume that pattern of missing data values is due to
insufficient GOES 16 data at those locations.
Thanks,
John
On Mon, Jul 15, 2019 at 1:51 PM Sarah Griffin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> When you say "gridded data file" does that not include a netCDF
file?
> I'm trying to use a netCDF file as a grid, which I thought MET knows
how
> to read. However, I ran my file using regrid_data_plane and then
mode
> and I get this file
> (
> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_19700101_000000V_NAA.ps)
>
> that I uploaded and the grid is still offset from when I want. Can
you
> please test and see what happens when you use my file
> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc as the
grid
> instead of G212?
>
> Also, what does
> MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
> found in bad slot
> mean?
>
> Thanks!
> Sarah
>
> On 7/15/19 2:40 PM, John Halley Gotway via RT wrote:
> > I just posted it. But realize that the whole point is that you
can
> > generate it yourself by running the regrid_data_plane command.
And
> instead
> > of using "G212" on the command, just list a gridded data file that
MET
> > knows how to read that's already on your desired model domain.
The tool
> > will read the grid info from that gridded data file and regrid the
input
> > GOES-16 values to that domain.
> >
> > Thanks,
> > John
> >
> > On Mon, Jul 15, 2019 at 1:36 PM Sarah Griffin via RT
<met_help at ucar.edu>
> > wrote:
> >
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
> >>
> >> Hi John,
> >>
> >> Reading this a bit more, can you try to run a regrid to the grid
that I
> >> want, which can be found in:
> >> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc?
> >> Unfortunately, remapping it to NCEP Grid 212 is not useful.
> >>
> >> Have a great day!
> >> Sarah
> >>
> >> On 7/15/19 2:12 PM, John Halley Gotway via RT wrote:
> >>> Sarah,
> >>>
> >>> I grabbed that file from the ftp site and see this header:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> *netcdf geocatL1.GOES-16.2018007.000200 {dimensions: x =
2312 ;
> >>> y = 1191 ;variables: float pixel_latitude(y, x) ;
> float
> >>> pixel_longitude(y, x) ; float
> channel_13_brightness_temperature(y,
> >>> x) ;}*
> >>>
> >>> The original GOES-16 file has much more metadata in it that
> >>> regrid_data_plane expects and uses. I found some GOES-16 data
on our
> >>> filesystem and am sending you an example of how it can be used
by
> >>> regrid_data_plane. Here's the sample data file:
> >>>
> >>> *
> >>
> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
> >>> <
> >>
> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
> >>> *
> >>>
> >>> And here's the command I ran to interpolate it to NCEP Grid 212
which
> >>> covers CONUS:
> >>>
> >>> *met-8.1/bin/regrid_data_plane \*
> >>>
> >>
> *goes-16/ABI/L1/CONUS/C10/2019196/OR_ABI-L1b-RadC-
M6C10_G16_s20191961811348_e20191961814132_
> >> c20191961814170.nc
> >>> \*
> >>> *G212 goes16_g212.nc <http://goes16_g212.nc> -field 'name="Rad";
> >>> level="(*,*)";' -method MAX -v 4*
> >>>
> >>> And then I plotted the result:
> >>>
> >>> *met-8.1/bin/plot_data_plane goes16_g212.nc
<http://goes16_g212.nc>
> >>> goes16_g212.ps <http://goes16_g212.ps> 'name="Rad";
level="(*,*)";'*
> >>>
> >>> And that plot is attached.
> >>>
> >>> John
> >>>
> >>> On Mon, Jul 15, 2019 at 12:37 PM Sarah Griffin via RT <
> met_help at ucar.edu
> >>>
> >>> wrote:
> >>>
> >>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
> >>>>
> >>>> Hi John,
> >>>>
> >>>> Ok, I've added the original GOES-16 data to the ftp site. I've
also
> >> added '
> >>>> geocatL1.GOES-16.2018007.000200.nc' since the original GOES-16
data
> >> needs
> >>>> to be rewritten to actually get the brightness temperatures.
> >>>>
> >>>> I then did:
> >>>> bin/regrid_data_plane \
> >>>> geocatL1.GOES-16.2018007.000200.nc \
> >>>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
> >>>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
> >>>> -field 'name = "channel_13_brightness_temperature"; level =
"(*,*)";
> >>>> file_type = NETCDF_MET;' \
> >>>> -v 4
> >>>>
> >>>> and got the same error "MetNcFile::data(NcVar *, const
LongArray &,
> >>>> DataPlane &) const -> star found in bad slot"
> >>>>
> >>>>
> >>>>
> >>>> I also added some radar data,
Radar_Reflectivity_2018_0107_00_00.nc
> and
> >>>> Radar_Reflectivity_2018_0107_00_00.nc_new. I was able to do:
> >>>>
> >>>> bin/regrid_data_plane \
> >>>> Radar_Reflectivity_2018_0107_00_00.nc \
> >>>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
> >>>> Radar_Reflectivity_2018_0107_00_00.nc_new \
> >>>> -field 'name = "composite_n0q"; level = "(*,*)"; file_type =
> >> NETCDF_MET;'
> >>>> \
> >>>> -v 4
> >>>>
> >>>> And get the remapping to work. I didn't try this is MODE,
though,
> >> because
> >>>> the composite_n0q data is empty. But I'm curious if any of the
global
> >>>> attribute data in Radar_Reflectivity_2018_0107_00_00.nc_new is
helpful
> >> in
> >>>> figuring out what I need to run MODE?
> >>>>
> >>>> Thanks!
> >>>> Sarah
> >>>>
> >>>> On 7/15/19 1:07 PM, John Halley Gotway via RT wrote:
> >>>>
> >>>> Sarah,
> >>>>
> >>>> What I'm recommending is that we go back to the original GOES-
16 data,
> >> and
> >>>> run it through regrid_data_plane to do that remapping step. If
we can
> >> get
> >>>> that to work, it'll result in an output file that can easily be
read
> by
> >>>> MODE.
> >>>>
> >>>> Otherwise, we're stuck with trying to get the CF-convention
> >> specification
> >>>> of the WRF domain exactly right, which can be pretty tedious.
> >>>>
> >>>> John
> >>>>
> >>>> On Mon, Jul 15, 2019 at 11:17 AM Sarah Griffin via RT <
> >> met_help at ucar.edu
> >>>>> <mailto:met_help at ucar.edu>
> >>>> wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
> >>>>
> >>>> Hi John,
> >>>>
> >>>> The GOES-16 data I'm trying to use was created after remapping
the
> >>>> native GOES data to the WRF projection from
> >>>>
> >>>>
> >>>>
> >>
> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
> >>>> .
> >>>>
> >>>> So does it matter what the GOES projection is if I'm trying to
remap
> it
> >>>> to a different projection?
> >>>>
> >>>> I've messed around some more and have gotten to this error on
> >>>> regrid_data_plane. MetNcFile::data(NcVar *, const LongArray &,
> DataPlane
> >>>> &) const -> star found in bad slot
> >>>>
> >>>> when using this command:
> >>>> bin/regrid_data_plane \
> >>>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc \
> >>>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
> >>>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
> >>>> -field 'name = "channel_13_brightness_temperature"; level =
"(*,*)";
> >>>> file_type = NETCDF_MET;' \
> >>>> -v 4
> >>>>
> >>>> Thanks!
> >>>> Sarah
> >>>>
> >>>> On 7/15/19 11:58 AM, John Halley Gotway via RT wrote:
> >>>>
> >>>>
> >>>> Sarah,
> >>>>
> >>>> Can you please send me a link to the GOES-16 data you're trying
to
> use?
> >>>>
> >>>>
> >>>> I
> >>>>
> >>>>
> >>>> see you have a NetCDF file by this name:
> >>>> emap_geocatL1.GOES-16.CONUS.2018007.000230.nc
> >>>> Where did you get this file? Is is a publicly available ftp
site?
> >>>>
> >>>> In general, MET reads gridded data that lives on regular
projections.
> >>>>
> >>>>
> >>>> GOES
> >>>>
> >>>>
> >>>> data is a special case... it is not defined on a projection.
Instead,
> >>>>
> >>>>
> >>>> it's
> >>>>
> >>>>
> >>>> a whole bunch of high resolution pixels of data. Each pixel
has a
> >>>>
> >>>>
> >>>> lat/lon
> >>>>
> >>>>
> >>>> associated with it. We enhanced regrid_data_plane to read
those
> >>>>
> >>>>
> >>>> lat/lon's
> >>>>
> >>>>
> >>>> and interpolate them to a user-requested domain.
> >>>>
> >>>> I'm hoping to get a sample GOES-16 file and send you example
commands
> >> for
> >>>> interpolating it to your model domain using regrid_data_plane.
> >>>>
> >>>> Thanks,
> >>>> John
> >>>>
> >>>> On Mon, Jul 15, 2019 at 9:28 AM Sarah Griffin via RT <
> met_help at ucar.edu
> >>>>> <mailto:met_help at ucar.edu>
> >>>> wrote:
> >>>>
> >>>>
> >>>>
> >>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
> >>>>
> >>>> Hi John,
> >>>>
> >>>> Update, please ignore the other email I sent. Looks like I was
missing
> >>>> '-field' instead of field.
> >>>>
> >>>> However, now I'm getting the error "ERROR :
> >>>> NcCfFile::read_netcdf_grid() -> Couldn't figure out projection
from
> >>>> information in netCDF file." It seems like I'm a bit stuck
because I
> >>>> don't know the projection. If I did, I wouldn't need to use
> >>>> regrid_data_plane. Any thoughts?
> >>>>
> >>>> Thanks!
> >>>> Sarah
> >>>>
> >>>> On 7/12/19 5:53 PM, John Halley Gotway via RT wrote:
> >>>>
> >>>>
> >>>> Sarah,
> >>>>
> >>>> I'm pretty sure that didn't fix it entirely. When I plot the
channel
> >>>>
> >>>>
> >>>> 15
> >>>>
> >>>>
> >>>> data with plot_data_plane, I clearly see the outline of FL and
the
> >>>>
> >>>>
> >>>> Eastern
> >>>>
> >>>>
> >>>> seaboard in the data, but it doesn't line up with the map data.
So
> >>>>
> >>>>
> >>>> there's
> >>>>
> >>>>
> >>>> clearly still a problem.
> >>>>
> >>>> I see that you're using GOES-16 data here. MET's
regrid_data_plane
> >>>>
> >>>>
> >>>> tool
> >>>>
> >>>>
> >>>> should be able to read GOES-16 data and regrid it to a user-
defined
> >>>>
> >>>>
> >>>> grid.
> >>>>
> >>>>
> >>>> That would be another alternatively for using GOES-16 data in
MET.
> >>>>
> >>>> Thanks,
> >>>> John
> >>>>
> >>>> On Fri, Jul 12, 2019 at 4:45 PM John Halley Gotway
<johnhg at ucar.edu
> >>>>> <mailto:johnhg at ucar.edu>
> >>>> wrote:
> >>>>
> >>>>
> >>>> Hi Sarah,
> >>>>
> >>>> Thought I'd chime in here to mention the following. This is
not
> >>>>
> >>>>
> >>>> actually
> >>>>
> >>>>
> >>>> a problem in MODE tool itself, but more of an issue in how MET
is
> >>>>
> >>>>
> >>>> reading
> >>>>
> >>>>
> >>>> data your input files and placing them on the earth. I usually
> >>>>
> >>>>
> >>>> recommend
> >>>>
> >>>>
> >>>> that people run MET's plot_data_plane tool when working with a
new
> >>>>
> >>>>
> >>>> data
> >>>>
> >>>>
> >>>> source to make sure MET is reading the data well:
> >>>>
> >>>> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
> >>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> >>>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc> plot.ps
> >>>> <http://plot.ps><http://plot.ps>
> >>>> 'name="channel_10_brightness_temperature";
> >>>>
> >>>>
> >>>> level="(*,*)";'
> >>>>
> >>>>
> >>>> -v 4*
> >>>>
> >>>> This produces a nice looking plot, but there's no country
outlines on
> >>>>
> >>>>
> >>>> top
> >>>>
> >>>>
> >>>> of the data! And that usually indicates a problem in the
projection
> >>>> information. But I did find one thing which seems to have
helped. I
> >>>> changed the longitude_of_central_meridian from 262.5 to -97.5,
by
> >>>>
> >>>>
> >>>> running
> >>>>
> >>>>
> >>>> the following command:
> >>>>
> >>>> *ncatted -a longitude_of_central_meridian,Projection,o,f,-97.5
> >>>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
> >>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> >>>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc>
> >>>> remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
> >>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> >>>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>*
> >>>>
> >>>> Those two longitudes are the same since they differ by 360
degrees.
> >>>> Surprisingly, running plot_data_plane on that modified file did
plot
> >>>>
> >>>>
> >>>> the
> >>>>
> >>>>
> >>>> map data (see attached image):
> >>>>
> >>>> *plot_data_plane remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc
> >>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> >>>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>
plot.ps
> >>>> <http://plot.ps><http://plot.ps>
> >>>> 'name="channel_10_brightness_temperature";
> >>>>
> >>>>
> >>>> level="(*,*)";'
> >>>>
> >>>>
> >>>> -v 4*
> >>>>
> >>>> Can you confirm that the data lives on the right place on the
earth?
> >>>> Should it be covering the Eastern CONUS and Atlantic? If so,
then
> >>>>
> >>>>
> >>>> we'll
> >>>>
> >>>>
> >>>> likely need to make a one line fix in MET's library code to
rescale
> >>>>
> >>>>
> >>>> the
> >>>>
> >>>>
> >>>> longitude values to the expected range of (-180, 180] when we
read
> >>>>
> >>>>
> >>>> them
> >>>>
> >>>>
> >>>> in.
> >>>>
> >>>>
> >>>> Thanks,
> >>>> John
> >>>>
> >>>> On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT <
> >>>>
> >>>>
> >>>> met_help at ucar.edu<mailto:met_help at ucar.edu>>
> >>>>
> >>>>
> >>>> wrote:
> >>>>
> >>>>
> >>>>
> >>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
> >>>>
> >>>> On Fri Jul 12 14:56:24 2019,
sarah.griffin at ssec.wisc.edu<mailto:
> >>>> sarah.griffin at ssec.wisc.edu> wrote:
> >>>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> I'm using Met 8.0 with the bug fixes to run MODE for two netCDF
> >>>>
> >>>>
> >>>> files.
> >>>>
> >>>>
> >>>> MODE seems to run just fine, however the latitude and longitude
of
> >>>>
> >>>>
> >>>> the
> >>>>
> >>>>
> >>>> output is messed up. How can I fix the latitude and longitude?
I've
> >>>> uploaded the data and MODE output to the met_help ftp
directory.
> >>>>
> >>>>
> >>>> Thanks!
> >>>>
> >>>>
> >>>> Have a great day!
> >>>> Sarah
> >>>>
> >>>>
> >>>>
> >>>> Hi Sarah -
> >>>> Thanks for the data upload.
> >>>> I've passed this ticket along to Randy, our resident MODE
specialist.
> >>>> He should get a change to look at this early next week.
> >>>> David
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
>
----------------------------------------------------------------------------
> >>>>
> >>>> Sarah M. Griffin
> >>>> Associate Research Scientist
> >>>> Cooperative Institute for Meteorological Satellite Studies /
SSEC
> >>>> UW-Madison
> >>>> 1225 W Dayton St. Rm 243
> >>>> Madison, WI 53706
> >>>> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
> >>>> (608) 262-0986
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
>
----------------------------------------------------------------------------
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>>
> >>>>
> >>
>
----------------------------------------------------------------------------
> >>>> Sarah M. Griffin
> >>>> Associate Research Scientist
> >>>> Cooperative Institute for Meteorological Satellite Studies /
SSEC
> >>>> UW-Madison
> >>>> 1225 W Dayton St. Rm 243
> >>>> Madison, WI 53706
> >>>> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
> >>>> (608) 262-0986
> >>>>
> >>>>
> >>>>
> >>
>
----------------------------------------------------------------------------
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>>
> >>
>
----------------------------------------------------------------------------
> >>>> Sarah M. Griffin
> >>>> Associate Research Scientist
> >>>> Cooperative Institute for Meteorological Satellite Studies /
SSEC
> >>>> UW-Madison
> >>>> 1225 W Dayton St. Rm 243
> >>>> Madison, WI 53706
> >>>> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
> >>>> (608) 262-0986
> >>>>
> >>>>
> >>
>
----------------------------------------------------------------------------
> >>>>
> >>>>
> >>
> >> --
> >>
> >>
>
----------------------------------------------------------------------------
> >> Sarah M. Griffin
> >> Associate Research Scientist
> >> Cooperative Institute for Meteorological Satellite Studies / SSEC
> >> UW-Madison
> >> 1225 W Dayton St. Rm 243
> >> Madison, WI 53706
> >> sarah.griffin at ssec.wisc.edu
> >> (608) 262-0986
> >>
> >>
>
----------------------------------------------------------------------------
> >>
> >>
> >>
> >>
>
>
> --
>
>
----------------------------------------------------------------------------
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
> sarah.griffin at ssec.wisc.edu
> (608) 262-0986
>
>
----------------------------------------------------------------------------
>
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #91053] Incorrect lat and lon data on objects
From: Sarah Griffin
Time: Tue Jul 16 11:34:43 2019
Thanks John. I hope I'm finally on the right track, but when I'm
running
MODE I'm still getting the error:
MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
found in bad slot
What does that error mean?
Have a great day!
Sarah
On 7/15/19 5:22 PM, John Halley Gotway via RT wrote:
> Sarah,
>
> OK, I just ran the following command:
>
> *regrid_data_plane \*
> *OR_ABI-L1b-RadC-
M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
> \*
> *mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
> <http://mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc>
> \*
> *goes16_MODE_GRID.nc \*
> *-field 'name="Rad"; level="(*,*)";'*
>
> And that produced an output file with bad data values everywhere.
The
> problem is that the projection information in that MODE output file
is
> messed up in some way (
> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc)...
> which was the original reason you wrote.
>
> So I tried a different route. The "to_grid" option for
regrid_data_plane
> can be defined as a named grid (i.e. G212), the path to a gridded
data
> file, or an explicit grid definition. I tried the latter. Below is
an
> excerpt from met-8.1/share/met/config/README:
>
> // - to_grid = "spec"; To define a grid specified as follows:
> // - lambert Nx Ny lat_ll lon_ll lon_orient D_km R_km
> standard_parallel_1
> // [standard_parallel_2] N|S
>
> I used the metadata from the NetCDF files you sent to define the
following
> grid definition info:
> 'lambert 1535 1023 22.45395 -119.2807 262.5 3 6371.2 38.5 N'
>
> And I ran this command:
>
> *regrid_data_plane \*
> *OR_ABI-L1b-RadC-
M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
> \*
> *'lambert 1535 1023 22.45395 -119.2807 262.5 3 6371.2 38.5 N' \*
> *goes16_USER_DEFINED.nc -field 'name="Rad"; level="(*,*)";'*
>
> And plotted the output. The result (see attached) looks much more
> promising. I assume that pattern of missing data values is due to
> insufficient GOES 16 data at those locations.
>
> Thanks,
> John
>
> On Mon, Jul 15, 2019 at 1:51 PM Sarah Griffin via RT
<met_help at ucar.edu>
> wrote:
>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>
>> When you say "gridded data file" does that not include a netCDF
file?
>> I'm trying to use a netCDF file as a grid, which I thought MET
knows how
>> to read. However, I ran my file using regrid_data_plane and then
mode
>> and I get this file
>> (
>> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_19700101_000000V_NAA.ps)
>>
>> that I uploaded and the grid is still offset from when I want. Can
you
>> please test and see what happens when you use my file
>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc as the
grid
>> instead of G212?
>>
>> Also, what does
>> MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
>> found in bad slot
>> mean?
>>
>> Thanks!
>> Sarah
>>
>> On 7/15/19 2:40 PM, John Halley Gotway via RT wrote:
>>> I just posted it. But realize that the whole point is that you
can
>>> generate it yourself by running the regrid_data_plane command.
And
>> instead
>>> of using "G212" on the command, just list a gridded data file that
MET
>>> knows how to read that's already on your desired model domain.
The tool
>>> will read the grid info from that gridded data file and regrid the
input
>>> GOES-16 values to that domain.
>>>
>>> Thanks,
>>> John
>>>
>>> On Mon, Jul 15, 2019 at 1:36 PM Sarah Griffin via RT
<met_help at ucar.edu>
>>> wrote:
>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>>>
>>>> Hi John,
>>>>
>>>> Reading this a bit more, can you try to run a regrid to the grid
that I
>>>> want, which can be found in:
>>>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc?
>>>> Unfortunately, remapping it to NCEP Grid 212 is not useful.
>>>>
>>>> Have a great day!
>>>> Sarah
>>>>
>>>> On 7/15/19 2:12 PM, John Halley Gotway via RT wrote:
>>>>> Sarah,
>>>>>
>>>>> I grabbed that file from the ftp site and see this header:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *netcdf geocatL1.GOES-16.2018007.000200 {dimensions: x =
2312 ;
>>>>> y = 1191 ;variables: float pixel_latitude(y, x) ;
>> float
>>>>> pixel_longitude(y, x) ; float
>> channel_13_brightness_temperature(y,
>>>>> x) ;}*
>>>>>
>>>>> The original GOES-16 file has much more metadata in it that
>>>>> regrid_data_plane expects and uses. I found some GOES-16 data
on our
>>>>> filesystem and am sending you an example of how it can be used
by
>>>>> regrid_data_plane. Here's the sample data file:
>>>>>
>>>>> *
>> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
>>>>> <
>> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
>>>>> *
>>>>>
>>>>> And here's the command I ran to interpolate it to NCEP Grid 212
which
>>>>> covers CONUS:
>>>>>
>>>>> *met-8.1/bin/regrid_data_plane \*
>>>>>
>> *goes-16/ABI/L1/CONUS/C10/2019196/OR_ABI-L1b-RadC-
M6C10_G16_s20191961811348_e20191961814132_
>>>> c20191961814170.nc
>>>>> \*
>>>>> *G212 goes16_g212.nc <http://goes16_g212.nc> -field 'name="Rad";
>>>>> level="(*,*)";' -method MAX -v 4*
>>>>>
>>>>> And then I plotted the result:
>>>>>
>>>>> *met-8.1/bin/plot_data_plane goes16_g212.nc
<http://goes16_g212.nc>
>>>>> goes16_g212.ps <http://goes16_g212.ps> 'name="Rad";
level="(*,*)";'*
>>>>>
>>>>> And that plot is attached.
>>>>>
>>>>> John
>>>>>
>>>>> On Mon, Jul 15, 2019 at 12:37 PM Sarah Griffin via RT <
>> met_help at ucar.edu
>>>>> wrote:
>>>>>
>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>>>>>
>>>>>> Hi John,
>>>>>>
>>>>>> Ok, I've added the original GOES-16 data to the ftp site. I've
also
>>>> added '
>>>>>> geocatL1.GOES-16.2018007.000200.nc' since the original GOES-16
data
>>>> needs
>>>>>> to be rewritten to actually get the brightness temperatures.
>>>>>>
>>>>>> I then did:
>>>>>> bin/regrid_data_plane \
>>>>>> geocatL1.GOES-16.2018007.000200.nc \
>>>>>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
>>>>>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
>>>>>> -field 'name = "channel_13_brightness_temperature"; level =
"(*,*)";
>>>>>> file_type = NETCDF_MET;' \
>>>>>> -v 4
>>>>>>
>>>>>> and got the same error "MetNcFile::data(NcVar *, const
LongArray &,
>>>>>> DataPlane &) const -> star found in bad slot"
>>>>>>
>>>>>>
>>>>>>
>>>>>> I also added some radar data,
Radar_Reflectivity_2018_0107_00_00.nc
>> and
>>>>>> Radar_Reflectivity_2018_0107_00_00.nc_new. I was able to do:
>>>>>>
>>>>>> bin/regrid_data_plane \
>>>>>> Radar_Reflectivity_2018_0107_00_00.nc \
>>>>>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
>>>>>> Radar_Reflectivity_2018_0107_00_00.nc_new \
>>>>>> -field 'name = "composite_n0q"; level = "(*,*)"; file_type =
>>>> NETCDF_MET;'
>>>>>> \
>>>>>> -v 4
>>>>>>
>>>>>> And get the remapping to work. I didn't try this is MODE,
though,
>>>> because
>>>>>> the composite_n0q data is empty. But I'm curious if any of the
global
>>>>>> attribute data in Radar_Reflectivity_2018_0107_00_00.nc_new is
helpful
>>>> in
>>>>>> figuring out what I need to run MODE?
>>>>>>
>>>>>> Thanks!
>>>>>> Sarah
>>>>>>
>>>>>> On 7/15/19 1:07 PM, John Halley Gotway via RT wrote:
>>>>>>
>>>>>> Sarah,
>>>>>>
>>>>>> What I'm recommending is that we go back to the original GOES-
16 data,
>>>> and
>>>>>> run it through regrid_data_plane to do that remapping step. If
we can
>>>> get
>>>>>> that to work, it'll result in an output file that can easily be
read
>> by
>>>>>> MODE.
>>>>>>
>>>>>> Otherwise, we're stuck with trying to get the CF-convention
>>>> specification
>>>>>> of the WRF domain exactly right, which can be pretty tedious.
>>>>>>
>>>>>> John
>>>>>>
>>>>>> On Mon, Jul 15, 2019 at 11:17 AM Sarah Griffin via RT <
>>>> met_help at ucar.edu
>>>>>>> <mailto:met_help at ucar.edu>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>>>>>
>>>>>> Hi John,
>>>>>>
>>>>>> The GOES-16 data I'm trying to use was created after remapping
the
>>>>>> native GOES data to the WRF projection from
>>>>>>
>>>>>>
>>>>>>
>> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
>>>>>> .
>>>>>>
>>>>>> So does it matter what the GOES projection is if I'm trying to
remap
>> it
>>>>>> to a different projection?
>>>>>>
>>>>>> I've messed around some more and have gotten to this error on
>>>>>> regrid_data_plane. MetNcFile::data(NcVar *, const LongArray &,
>> DataPlane
>>>>>> &) const -> star found in bad slot
>>>>>>
>>>>>> when using this command:
>>>>>> bin/regrid_data_plane \
>>>>>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc \
>>>>>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
>>>>>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
>>>>>> -field 'name = "channel_13_brightness_temperature"; level =
"(*,*)";
>>>>>> file_type = NETCDF_MET;' \
>>>>>> -v 4
>>>>>>
>>>>>> Thanks!
>>>>>> Sarah
>>>>>>
>>>>>> On 7/15/19 11:58 AM, John Halley Gotway via RT wrote:
>>>>>>
>>>>>>
>>>>>> Sarah,
>>>>>>
>>>>>> Can you please send me a link to the GOES-16 data you're trying
to
>> use?
>>>>>>
>>>>>> I
>>>>>>
>>>>>>
>>>>>> see you have a NetCDF file by this name:
>>>>>> emap_geocatL1.GOES-16.CONUS.2018007.000230.nc
>>>>>> Where did you get this file? Is is a publicly available ftp
site?
>>>>>>
>>>>>> In general, MET reads gridded data that lives on regular
projections.
>>>>>>
>>>>>>
>>>>>> GOES
>>>>>>
>>>>>>
>>>>>> data is a special case... it is not defined on a projection.
Instead,
>>>>>>
>>>>>>
>>>>>> it's
>>>>>>
>>>>>>
>>>>>> a whole bunch of high resolution pixels of data. Each pixel
has a
>>>>>>
>>>>>>
>>>>>> lat/lon
>>>>>>
>>>>>>
>>>>>> associated with it. We enhanced regrid_data_plane to read
those
>>>>>>
>>>>>>
>>>>>> lat/lon's
>>>>>>
>>>>>>
>>>>>> and interpolate them to a user-requested domain.
>>>>>>
>>>>>> I'm hoping to get a sample GOES-16 file and send you example
commands
>>>> for
>>>>>> interpolating it to your model domain using regrid_data_plane.
>>>>>>
>>>>>> Thanks,
>>>>>> John
>>>>>>
>>>>>> On Mon, Jul 15, 2019 at 9:28 AM Sarah Griffin via RT <
>> met_help at ucar.edu
>>>>>>> <mailto:met_help at ucar.edu>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>>>>>
>>>>>> Hi John,
>>>>>>
>>>>>> Update, please ignore the other email I sent. Looks like I was
missing
>>>>>> '-field' instead of field.
>>>>>>
>>>>>> However, now I'm getting the error "ERROR :
>>>>>> NcCfFile::read_netcdf_grid() -> Couldn't figure out projection
from
>>>>>> information in netCDF file." It seems like I'm a bit stuck
because I
>>>>>> don't know the projection. If I did, I wouldn't need to use
>>>>>> regrid_data_plane. Any thoughts?
>>>>>>
>>>>>> Thanks!
>>>>>> Sarah
>>>>>>
>>>>>> On 7/12/19 5:53 PM, John Halley Gotway via RT wrote:
>>>>>>
>>>>>>
>>>>>> Sarah,
>>>>>>
>>>>>> I'm pretty sure that didn't fix it entirely. When I plot the
channel
>>>>>>
>>>>>>
>>>>>> 15
>>>>>>
>>>>>>
>>>>>> data with plot_data_plane, I clearly see the outline of FL and
the
>>>>>>
>>>>>>
>>>>>> Eastern
>>>>>>
>>>>>>
>>>>>> seaboard in the data, but it doesn't line up with the map data.
So
>>>>>>
>>>>>>
>>>>>> there's
>>>>>>
>>>>>>
>>>>>> clearly still a problem.
>>>>>>
>>>>>> I see that you're using GOES-16 data here. MET's
regrid_data_plane
>>>>>>
>>>>>>
>>>>>> tool
>>>>>>
>>>>>>
>>>>>> should be able to read GOES-16 data and regrid it to a user-
defined
>>>>>>
>>>>>>
>>>>>> grid.
>>>>>>
>>>>>>
>>>>>> That would be another alternatively for using GOES-16 data in
MET.
>>>>>>
>>>>>> Thanks,
>>>>>> John
>>>>>>
>>>>>> On Fri, Jul 12, 2019 at 4:45 PM John Halley Gotway
<johnhg at ucar.edu
>>>>>>> <mailto:johnhg at ucar.edu>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Hi Sarah,
>>>>>>
>>>>>> Thought I'd chime in here to mention the following. This is
not
>>>>>>
>>>>>>
>>>>>> actually
>>>>>>
>>>>>>
>>>>>> a problem in MODE tool itself, but more of an issue in how MET
is
>>>>>>
>>>>>>
>>>>>> reading
>>>>>>
>>>>>>
>>>>>> data your input files and placing them on the earth. I usually
>>>>>>
>>>>>>
>>>>>> recommend
>>>>>>
>>>>>>
>>>>>> that people run MET's plot_data_plane tool when working with a
new
>>>>>>
>>>>>>
>>>>>> data
>>>>>>
>>>>>>
>>>>>> source to make sure MET is reading the data well:
>>>>>>
>>>>>> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
>>>>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>>>>>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc> plot.ps
>>>>>> <http://plot.ps><http://plot.ps>
>>>>>> 'name="channel_10_brightness_temperature";
>>>>>>
>>>>>>
>>>>>> level="(*,*)";'
>>>>>>
>>>>>>
>>>>>> -v 4*
>>>>>>
>>>>>> This produces a nice looking plot, but there's no country
outlines on
>>>>>>
>>>>>>
>>>>>> top
>>>>>>
>>>>>>
>>>>>> of the data! And that usually indicates a problem in the
projection
>>>>>> information. But I did find one thing which seems to have
helped. I
>>>>>> changed the longitude_of_central_meridian from 262.5 to -97.5,
by
>>>>>>
>>>>>>
>>>>>> running
>>>>>>
>>>>>>
>>>>>> the following command:
>>>>>>
>>>>>> *ncatted -a longitude_of_central_meridian,Projection,o,f,-97.5
>>>>>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
>>>>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>>>>>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc>
>>>>>> remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
>>>>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>>>>>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>*
>>>>>>
>>>>>> Those two longitudes are the same since they differ by 360
degrees.
>>>>>> Surprisingly, running plot_data_plane on that modified file did
plot
>>>>>>
>>>>>>
>>>>>> the
>>>>>>
>>>>>>
>>>>>> map data (see attached image):
>>>>>>
>>>>>> *plot_data_plane remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc
>>>>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>>>>>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>
plot.ps
>>>>>> <http://plot.ps><http://plot.ps>
>>>>>> 'name="channel_10_brightness_temperature";
>>>>>>
>>>>>>
>>>>>> level="(*,*)";'
>>>>>>
>>>>>>
>>>>>> -v 4*
>>>>>>
>>>>>> Can you confirm that the data lives on the right place on the
earth?
>>>>>> Should it be covering the Eastern CONUS and Atlantic? If so,
then
>>>>>>
>>>>>>
>>>>>> we'll
>>>>>>
>>>>>>
>>>>>> likely need to make a one line fix in MET's library code to
rescale
>>>>>>
>>>>>>
>>>>>> the
>>>>>>
>>>>>>
>>>>>> longitude values to the expected range of (-180, 180] when we
read
>>>>>>
>>>>>>
>>>>>> them
>>>>>>
>>>>>>
>>>>>> in.
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> John
>>>>>>
>>>>>> On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT <
>>>>>>
>>>>>>
>>>>>> met_help at ucar.edu<mailto:met_help at ucar.edu>>
>>>>>>
>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>>>>>
>>>>>> On Fri Jul 12 14:56:24 2019,
sarah.griffin at ssec.wisc.edu<mailto:
>>>>>> sarah.griffin at ssec.wisc.edu> wrote:
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm using Met 8.0 with the bug fixes to run MODE for two netCDF
>>>>>>
>>>>>>
>>>>>> files.
>>>>>>
>>>>>>
>>>>>> MODE seems to run just fine, however the latitude and longitude
of
>>>>>>
>>>>>>
>>>>>> the
>>>>>>
>>>>>>
>>>>>> output is messed up. How can I fix the latitude and longitude?
I've
>>>>>> uploaded the data and MODE output to the met_help ftp
directory.
>>>>>>
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>>
>>>>>> Have a great day!
>>>>>> Sarah
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Sarah -
>>>>>> Thanks for the data upload.
>>>>>> I've passed this ticket along to Randy, our resident MODE
specialist.
>>>>>> He should get a change to look at this early next week.
>>>>>> David
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>
----------------------------------------------------------------------------
>>>>>> Sarah M. Griffin
>>>>>> Associate Research Scientist
>>>>>> Cooperative Institute for Meteorological Satellite Studies /
SSEC
>>>>>> UW-Madison
>>>>>> 1225 W Dayton St. Rm 243
>>>>>> Madison, WI 53706
>>>>>> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
>>>>>> (608) 262-0986
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>
----------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>>
>>
----------------------------------------------------------------------------
>>>>>> Sarah M. Griffin
>>>>>> Associate Research Scientist
>>>>>> Cooperative Institute for Meteorological Satellite Studies /
SSEC
>>>>>> UW-Madison
>>>>>> 1225 W Dayton St. Rm 243
>>>>>> Madison, WI 53706
>>>>>> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
>>>>>> (608) 262-0986
>>>>>>
>>>>>>
>>>>>>
>>
----------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>
----------------------------------------------------------------------------
>>>>>> Sarah M. Griffin
>>>>>> Associate Research Scientist
>>>>>> Cooperative Institute for Meteorological Satellite Studies /
SSEC
>>>>>> UW-Madison
>>>>>> 1225 W Dayton St. Rm 243
>>>>>> Madison, WI 53706
>>>>>> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
>>>>>> (608) 262-0986
>>>>>>
>>>>>>
>>
----------------------------------------------------------------------------
>>>>>>
>>>> --
>>>>
>>>>
>>
----------------------------------------------------------------------------
>>>> Sarah M. Griffin
>>>> Associate Research Scientist
>>>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>>>> UW-Madison
>>>> 1225 W Dayton St. Rm 243
>>>> Madison, WI 53706
>>>> sarah.griffin at ssec.wisc.edu
>>>> (608) 262-0986
>>>>
>>>>
>>
----------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>
>> --
>>
>>
----------------------------------------------------------------------------
>> Sarah M. Griffin
>> Associate Research Scientist
>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>> UW-Madison
>> 1225 W Dayton St. Rm 243
>> Madison, WI 53706
>> sarah.griffin at ssec.wisc.edu
>> (608) 262-0986
>>
>>
----------------------------------------------------------------------------
>>
>>
>>
>>
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC UW-
Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu
(608) 262-0986
----------------------------------------------------------------------------
------------------------------------------------
Subject: Incorrect lat and lon data on objects
From: John Halley Gotway
Time: Tue Jul 16 11:42:34 2019
Sarah,
In the MODE config file, you request what data should be read from the
input gridded data file. The way you do this varies slightly
depending on
the type of file you're reading (GRIB1/2 versus NetCDF). For NetCDF
files
you'd specify:
* field = { name = "NETCDF_VARIABLE_NAME"; level =
"NETCDF_DIMENSION_INFO"; }*
Where NETCDF_DIMENSION_INFO defines how to extract a 2D filed of data
from
the specified NETCDF_VARIABLE_NAME. You put a * for the gridded
dimensions
(i.e. lat and lon). When reading the NetCDF output of
regrid_data_plane,
it's easy. Just set it to "(*,*)".
If you're NetCDF variable had 4 dimensions like this:
float data(time, level, lat, lon);
You could use:
level = "(0, 5, *, *)";
To read data for the first time (0-based) and 6th vertical level.
Thanks,
John
On Tue, Jul 16, 2019 at 11:34 AM Sarah Griffin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Thanks John. I hope I'm finally on the right track, but when I'm
running
> MODE I'm still getting the error:
>
> MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
> found in bad slot
>
> What does that error mean?
>
> Have a great day!
> Sarah
>
> On 7/15/19 5:22 PM, John Halley Gotway via RT wrote:
> > Sarah,
> >
> > OK, I just ran the following command:
> >
> > *regrid_data_plane \*
> > *OR_ABI-L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_
> c20191961814170.nc
> > \*
> > *
> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
> > <
> http://mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
> >
> > \*
> > *goes16_MODE_GRID.nc \*
> > *-field 'name="Rad"; level="(*,*)";'*
> >
> > And that produced an output file with bad data values everywhere.
The
> > problem is that the projection information in that MODE output
file is
> > messed up in some way (
> >
> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
> )...
> > which was the original reason you wrote.
> >
> > So I tried a different route. The "to_grid" option for
regrid_data_plane
> > can be defined as a named grid (i.e. G212), the path to a gridded
data
> > file, or an explicit grid definition. I tried the latter. Below
is an
> > excerpt from met-8.1/share/met/config/README:
> >
> > // - to_grid = "spec"; To define a grid specified as follows:
> > // - lambert Nx Ny lat_ll lon_ll lon_orient D_km R_km
> > standard_parallel_1
> > // [standard_parallel_2] N|S
> >
> > I used the metadata from the NetCDF files you sent to define the
> following
> > grid definition info:
> > 'lambert 1535 1023 22.45395 -119.2807 262.5 3 6371.2 38.5 N'
> >
> > And I ran this command:
> >
> > *regrid_data_plane \*
> > *OR_ABI-L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_
> c20191961814170.nc
> > \*
> > *'lambert 1535 1023 22.45395 -119.2807 262.5 3 6371.2 38.5 N' \*
> > *goes16_USER_DEFINED.nc -field 'name="Rad"; level="(*,*)";'*
> >
> > And plotted the output. The result (see attached) looks much more
> > promising. I assume that pattern of missing data values is due to
> > insufficient GOES 16 data at those locations.
> >
> > Thanks,
> > John
> >
> > On Mon, Jul 15, 2019 at 1:51 PM Sarah Griffin via RT
<met_help at ucar.edu>
> > wrote:
> >
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
> >>
> >> When you say "gridded data file" does that not include a netCDF
file?
> >> I'm trying to use a netCDF file as a grid, which I thought MET
knows how
> >> to read. However, I ran my file using regrid_data_plane and then
mode
> >> and I get this file
> >> (
> >>
> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_19700101_000000V_NAA.ps
> )
> >>
> >> that I uploaded and the grid is still offset from when I want.
Can you
> >> please test and see what happens when you use my file
> >> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc as the
grid
> >> instead of G212?
> >>
> >> Also, what does
> >> MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
> >> found in bad slot
> >> mean?
> >>
> >> Thanks!
> >> Sarah
> >>
> >> On 7/15/19 2:40 PM, John Halley Gotway via RT wrote:
> >>> I just posted it. But realize that the whole point is that you
can
> >>> generate it yourself by running the regrid_data_plane command.
And
> >> instead
> >>> of using "G212" on the command, just list a gridded data file
that MET
> >>> knows how to read that's already on your desired model domain.
The
> tool
> >>> will read the grid info from that gridded data file and regrid
the
> input
> >>> GOES-16 values to that domain.
> >>>
> >>> Thanks,
> >>> John
> >>>
> >>> On Mon, Jul 15, 2019 at 1:36 PM Sarah Griffin via RT <
> met_help at ucar.edu>
> >>> wrote:
> >>>
> >>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
> >>>>
> >>>> Hi John,
> >>>>
> >>>> Reading this a bit more, can you try to run a regrid to the
grid that
> I
> >>>> want, which can be found in:
> >>>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc?
> >>>> Unfortunately, remapping it to NCEP Grid 212 is not useful.
> >>>>
> >>>> Have a great day!
> >>>> Sarah
> >>>>
> >>>> On 7/15/19 2:12 PM, John Halley Gotway via RT wrote:
> >>>>> Sarah,
> >>>>>
> >>>>> I grabbed that file from the ftp site and see this header:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> *netcdf geocatL1.GOES-16.2018007.000200 {dimensions: x
= 2312
> ;
> >>>>> y = 1191 ;variables: float pixel_latitude(y, x) ;
> >> float
> >>>>> pixel_longitude(y, x) ; float
> >> channel_13_brightness_temperature(y,
> >>>>> x) ;}*
> >>>>>
> >>>>> The original GOES-16 file has much more metadata in it that
> >>>>> regrid_data_plane expects and uses. I found some GOES-16 data
on our
> >>>>> filesystem and am sending you an example of how it can be used
by
> >>>>> regrid_data_plane. Here's the sample data file:
> >>>>>
> >>>>> *
> >>
> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
> >>>>> <
> >>
> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
> >>>>> *
> >>>>>
> >>>>> And here's the command I ran to interpolate it to NCEP Grid
212 which
> >>>>> covers CONUS:
> >>>>>
> >>>>> *met-8.1/bin/regrid_data_plane \*
> >>>>>
> >>
> *goes-16/ABI/L1/CONUS/C10/2019196/OR_ABI-L1b-RadC-
M6C10_G16_s20191961811348_e20191961814132_
> >>>> c20191961814170.nc
> >>>>> \*
> >>>>> *G212 goes16_g212.nc <http://goes16_g212.nc> -field
'name="Rad";
> >>>>> level="(*,*)";' -method MAX -v 4*
> >>>>>
> >>>>> And then I plotted the result:
> >>>>>
> >>>>> *met-8.1/bin/plot_data_plane goes16_g212.nc
<http://goes16_g212.nc>
> >>>>> goes16_g212.ps <http://goes16_g212.ps> 'name="Rad";
level="(*,*)";'*
> >>>>>
> >>>>> And that plot is attached.
> >>>>>
> >>>>> John
> >>>>>
> >>>>> On Mon, Jul 15, 2019 at 12:37 PM Sarah Griffin via RT <
> >> met_help at ucar.edu
> >>>>> wrote:
> >>>>>
> >>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053
>
> >>>>>>
> >>>>>> Hi John,
> >>>>>>
> >>>>>> Ok, I've added the original GOES-16 data to the ftp site.
I've also
> >>>> added '
> >>>>>> geocatL1.GOES-16.2018007.000200.nc' since the original GOES-
16 data
> >>>> needs
> >>>>>> to be rewritten to actually get the brightness temperatures.
> >>>>>>
> >>>>>> I then did:
> >>>>>> bin/regrid_data_plane \
> >>>>>> geocatL1.GOES-16.2018007.000200.nc \
> >>>>>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
> >>>>>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
> >>>>>> -field 'name = "channel_13_brightness_temperature"; level =
> "(*,*)";
> >>>>>> file_type = NETCDF_MET;' \
> >>>>>> -v 4
> >>>>>>
> >>>>>> and got the same error "MetNcFile::data(NcVar *, const
LongArray &,
> >>>>>> DataPlane &) const -> star found in bad slot"
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I also added some radar data,
Radar_Reflectivity_2018_0107_00_00.nc
> >> and
> >>>>>> Radar_Reflectivity_2018_0107_00_00.nc_new. I was able to do:
> >>>>>>
> >>>>>> bin/regrid_data_plane \
> >>>>>> Radar_Reflectivity_2018_0107_00_00.nc \
> >>>>>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
> >>>>>> Radar_Reflectivity_2018_0107_00_00.nc_new \
> >>>>>> -field 'name = "composite_n0q"; level = "(*,*)"; file_type =
> >>>> NETCDF_MET;'
> >>>>>> \
> >>>>>> -v 4
> >>>>>>
> >>>>>> And get the remapping to work. I didn't try this is MODE,
though,
> >>>> because
> >>>>>> the composite_n0q data is empty. But I'm curious if any of
the
> global
> >>>>>> attribute data in Radar_Reflectivity_2018_0107_00_00.nc_new
is
> helpful
> >>>> in
> >>>>>> figuring out what I need to run MODE?
> >>>>>>
> >>>>>> Thanks!
> >>>>>> Sarah
> >>>>>>
> >>>>>> On 7/15/19 1:07 PM, John Halley Gotway via RT wrote:
> >>>>>>
> >>>>>> Sarah,
> >>>>>>
> >>>>>> What I'm recommending is that we go back to the original
GOES-16
> data,
> >>>> and
> >>>>>> run it through regrid_data_plane to do that remapping step.
If we
> can
> >>>> get
> >>>>>> that to work, it'll result in an output file that can easily
be read
> >> by
> >>>>>> MODE.
> >>>>>>
> >>>>>> Otherwise, we're stuck with trying to get the CF-convention
> >>>> specification
> >>>>>> of the WRF domain exactly right, which can be pretty tedious.
> >>>>>>
> >>>>>> John
> >>>>>>
> >>>>>> On Mon, Jul 15, 2019 at 11:17 AM Sarah Griffin via RT <
> >>>> met_help at ucar.edu
> >>>>>>> <mailto:met_help at ucar.edu>
> >>>>>> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053
>
> >>>>>>
> >>>>>> Hi John,
> >>>>>>
> >>>>>> The GOES-16 data I'm trying to use was created after
remapping the
> >>>>>> native GOES data to the WRF projection from
> >>>>>>
> >>>>>>
> >>>>>>
> >>
> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
> >>>>>> .
> >>>>>>
> >>>>>> So does it matter what the GOES projection is if I'm trying
to remap
> >> it
> >>>>>> to a different projection?
> >>>>>>
> >>>>>> I've messed around some more and have gotten to this error on
> >>>>>> regrid_data_plane. MetNcFile::data(NcVar *, const LongArray
&,
> >> DataPlane
> >>>>>> &) const -> star found in bad slot
> >>>>>>
> >>>>>> when using this command:
> >>>>>> bin/regrid_data_plane \
> >>>>>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc \
> >>>>>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
> >>>>>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
> >>>>>> -field 'name = "channel_13_brightness_temperature"; level =
> "(*,*)";
> >>>>>> file_type = NETCDF_MET;' \
> >>>>>> -v 4
> >>>>>>
> >>>>>> Thanks!
> >>>>>> Sarah
> >>>>>>
> >>>>>> On 7/15/19 11:58 AM, John Halley Gotway via RT wrote:
> >>>>>>
> >>>>>>
> >>>>>> Sarah,
> >>>>>>
> >>>>>> Can you please send me a link to the GOES-16 data you're
trying to
> >> use?
> >>>>>>
> >>>>>> I
> >>>>>>
> >>>>>>
> >>>>>> see you have a NetCDF file by this name:
> >>>>>> emap_geocatL1.GOES-16.CONUS.2018007.000230.nc
> >>>>>> Where did you get this file? Is is a publicly available ftp
site?
> >>>>>>
> >>>>>> In general, MET reads gridded data that lives on regular
> projections.
> >>>>>>
> >>>>>>
> >>>>>> GOES
> >>>>>>
> >>>>>>
> >>>>>> data is a special case... it is not defined on a projection.
> Instead,
> >>>>>>
> >>>>>>
> >>>>>> it's
> >>>>>>
> >>>>>>
> >>>>>> a whole bunch of high resolution pixels of data. Each pixel
has a
> >>>>>>
> >>>>>>
> >>>>>> lat/lon
> >>>>>>
> >>>>>>
> >>>>>> associated with it. We enhanced regrid_data_plane to read
those
> >>>>>>
> >>>>>>
> >>>>>> lat/lon's
> >>>>>>
> >>>>>>
> >>>>>> and interpolate them to a user-requested domain.
> >>>>>>
> >>>>>> I'm hoping to get a sample GOES-16 file and send you example
> commands
> >>>> for
> >>>>>> interpolating it to your model domain using
regrid_data_plane.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> John
> >>>>>>
> >>>>>> On Mon, Jul 15, 2019 at 9:28 AM Sarah Griffin via RT <
> >> met_help at ucar.edu
> >>>>>>> <mailto:met_help at ucar.edu>
> >>>>>> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053
>
> >>>>>>
> >>>>>> Hi John,
> >>>>>>
> >>>>>> Update, please ignore the other email I sent. Looks like I
was
> missing
> >>>>>> '-field' instead of field.
> >>>>>>
> >>>>>> However, now I'm getting the error "ERROR :
> >>>>>> NcCfFile::read_netcdf_grid() -> Couldn't figure out
projection from
> >>>>>> information in netCDF file." It seems like I'm a bit stuck
because I
> >>>>>> don't know the projection. If I did, I wouldn't need to use
> >>>>>> regrid_data_plane. Any thoughts?
> >>>>>>
> >>>>>> Thanks!
> >>>>>> Sarah
> >>>>>>
> >>>>>> On 7/12/19 5:53 PM, John Halley Gotway via RT wrote:
> >>>>>>
> >>>>>>
> >>>>>> Sarah,
> >>>>>>
> >>>>>> I'm pretty sure that didn't fix it entirely. When I plot the
> channel
> >>>>>>
> >>>>>>
> >>>>>> 15
> >>>>>>
> >>>>>>
> >>>>>> data with plot_data_plane, I clearly see the outline of FL
and the
> >>>>>>
> >>>>>>
> >>>>>> Eastern
> >>>>>>
> >>>>>>
> >>>>>> seaboard in the data, but it doesn't line up with the map
data. So
> >>>>>>
> >>>>>>
> >>>>>> there's
> >>>>>>
> >>>>>>
> >>>>>> clearly still a problem.
> >>>>>>
> >>>>>> I see that you're using GOES-16 data here. MET's
regrid_data_plane
> >>>>>>
> >>>>>>
> >>>>>> tool
> >>>>>>
> >>>>>>
> >>>>>> should be able to read GOES-16 data and regrid it to a user-
defined
> >>>>>>
> >>>>>>
> >>>>>> grid.
> >>>>>>
> >>>>>>
> >>>>>> That would be another alternatively for using GOES-16 data in
MET.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> John
> >>>>>>
> >>>>>> On Fri, Jul 12, 2019 at 4:45 PM John Halley Gotway
<johnhg at ucar.edu
> >>>>>>> <mailto:johnhg at ucar.edu>
> >>>>>> wrote:
> >>>>>>
> >>>>>>
> >>>>>> Hi Sarah,
> >>>>>>
> >>>>>> Thought I'd chime in here to mention the following. This is
not
> >>>>>>
> >>>>>>
> >>>>>> actually
> >>>>>>
> >>>>>>
> >>>>>> a problem in MODE tool itself, but more of an issue in how
MET is
> >>>>>>
> >>>>>>
> >>>>>> reading
> >>>>>>
> >>>>>>
> >>>>>> data your input files and placing them on the earth. I
usually
> >>>>>>
> >>>>>>
> >>>>>> recommend
> >>>>>>
> >>>>>>
> >>>>>> that people run MET's plot_data_plane tool when working with
a new
> >>>>>>
> >>>>>>
> >>>>>> data
> >>>>>>
> >>>>>>
> >>>>>> source to make sure MET is reading the data well:
> >>>>>>
> >>>>>> *plot_data_plane remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc
> >>>>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> >>>>>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc>
plot.ps
> >>>>>> <http://plot.ps><http://plot.ps>
> >>>>>> 'name="channel_10_brightness_temperature";
> >>>>>>
> >>>>>>
> >>>>>> level="(*,*)";'
> >>>>>>
> >>>>>>
> >>>>>> -v 4*
> >>>>>>
> >>>>>> This produces a nice looking plot, but there's no country
outlines
> on
> >>>>>>
> >>>>>>
> >>>>>> top
> >>>>>>
> >>>>>>
> >>>>>> of the data! And that usually indicates a problem in the
projection
> >>>>>> information. But I did find one thing which seems to have
helped.
> I
> >>>>>> changed the longitude_of_central_meridian from 262.5 to
-97.5, by
> >>>>>>
> >>>>>>
> >>>>>> running
> >>>>>>
> >>>>>>
> >>>>>> the following command:
> >>>>>>
> >>>>>> *ncatted -a longitude_of_central_meridian,Projection,o,f,-
97.5
> >>>>>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
> >>>>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> >>>>>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc>
> >>>>>> remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
> >>>>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> >>>>>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>*
> >>>>>>
> >>>>>> Those two longitudes are the same since they differ by 360
degrees.
> >>>>>> Surprisingly, running plot_data_plane on that modified file
did plot
> >>>>>>
> >>>>>>
> >>>>>> the
> >>>>>>
> >>>>>>
> >>>>>> map data (see attached image):
> >>>>>>
> >>>>>> *plot_data_plane remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc
> >>>>>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> >>>>>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>
plot.ps
> >>>>>> <http://plot.ps><http://plot.ps>
> >>>>>> 'name="channel_10_brightness_temperature";
> >>>>>>
> >>>>>>
> >>>>>> level="(*,*)";'
> >>>>>>
> >>>>>>
> >>>>>> -v 4*
> >>>>>>
> >>>>>> Can you confirm that the data lives on the right place on the
earth?
> >>>>>> Should it be covering the Eastern CONUS and Atlantic? If so,
then
> >>>>>>
> >>>>>>
> >>>>>> we'll
> >>>>>>
> >>>>>>
> >>>>>> likely need to make a one line fix in MET's library code to
rescale
> >>>>>>
> >>>>>>
> >>>>>> the
> >>>>>>
> >>>>>>
> >>>>>> longitude values to the expected range of (-180, 180] when we
read
> >>>>>>
> >>>>>>
> >>>>>> them
> >>>>>>
> >>>>>>
> >>>>>> in.
> >>>>>>
> >>>>>>
> >>>>>> Thanks,
> >>>>>> John
> >>>>>>
> >>>>>> On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT <
> >>>>>>
> >>>>>>
> >>>>>> met_help at ucar.edu<mailto:met_help at ucar.edu>>
> >>>>>>
> >>>>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053
>
> >>>>>>
> >>>>>> On Fri Jul 12 14:56:24 2019,
sarah.griffin at ssec.wisc.edu<mailto:
> >>>>>> sarah.griffin at ssec.wisc.edu> wrote:
> >>>>>>
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I'm using Met 8.0 with the bug fixes to run MODE for two
netCDF
> >>>>>>
> >>>>>>
> >>>>>> files.
> >>>>>>
> >>>>>>
> >>>>>> MODE seems to run just fine, however the latitude and
longitude of
> >>>>>>
> >>>>>>
> >>>>>> the
> >>>>>>
> >>>>>>
> >>>>>> output is messed up. How can I fix the latitude and
longitude? I've
> >>>>>> uploaded the data and MODE output to the met_help ftp
directory.
> >>>>>>
> >>>>>>
> >>>>>> Thanks!
> >>>>>>
> >>>>>>
> >>>>>> Have a great day!
> >>>>>> Sarah
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Hi Sarah -
> >>>>>> Thanks for the data upload.
> >>>>>> I've passed this ticket along to Randy, our resident MODE
> specialist.
> >>>>>> He should get a change to look at this early next week.
> >>>>>> David
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>
>
----------------------------------------------------------------------------
> >>>>>> Sarah M. Griffin
> >>>>>> Associate Research Scientist
> >>>>>> Cooperative Institute for Meteorological Satellite Studies /
SSEC
> >>>>>> UW-Madison
> >>>>>> 1225 W Dayton St. Rm 243
> >>>>>> Madison, WI 53706
> >>>>>>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
> >>>>>> (608) 262-0986
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>
>
----------------------------------------------------------------------------
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>>
> >>>>>>
> >>>>>>
> >>
>
----------------------------------------------------------------------------
> >>>>>> Sarah M. Griffin
> >>>>>> Associate Research Scientist
> >>>>>> Cooperative Institute for Meteorological Satellite Studies /
SSEC
> >>>>>> UW-Madison
> >>>>>> 1225 W Dayton St. Rm 243
> >>>>>> Madison, WI 53706
> >>>>>>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
> >>>>>> (608) 262-0986
> >>>>>>
> >>>>>>
> >>>>>>
> >>
>
----------------------------------------------------------------------------
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>>
> >>>>>>
> >>
>
----------------------------------------------------------------------------
> >>>>>> Sarah M. Griffin
> >>>>>> Associate Research Scientist
> >>>>>> Cooperative Institute for Meteorological Satellite Studies /
SSEC
> >>>>>> UW-Madison
> >>>>>> 1225 W Dayton St. Rm 243
> >>>>>> Madison, WI 53706
> >>>>>>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
> >>>>>> (608) 262-0986
> >>>>>>
> >>>>>>
> >>
>
----------------------------------------------------------------------------
> >>>>>>
> >>>> --
> >>>>
> >>>>
> >>
>
----------------------------------------------------------------------------
> >>>> Sarah M. Griffin
> >>>> Associate Research Scientist
> >>>> Cooperative Institute for Meteorological Satellite Studies /
SSEC
> >>>> UW-Madison
> >>>> 1225 W Dayton St. Rm 243
> >>>> Madison, WI 53706
> >>>> sarah.griffin at ssec.wisc.edu
> >>>> (608) 262-0986
> >>>>
> >>>>
> >>
>
----------------------------------------------------------------------------
> >>>>
> >>>>
> >>>>
> >>
> >> --
> >>
> >>
>
----------------------------------------------------------------------------
> >> Sarah M. Griffin
> >> Associate Research Scientist
> >> Cooperative Institute for Meteorological Satellite Studies / SSEC
> >> UW-Madison
> >> 1225 W Dayton St. Rm 243
> >> Madison, WI 53706
> >> sarah.griffin at ssec.wisc.edu
> >> (608) 262-0986
> >>
> >>
>
----------------------------------------------------------------------------
> >>
> >>
> >>
> >>
>
>
> --
>
>
----------------------------------------------------------------------------
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
> sarah.griffin at ssec.wisc.edu
> (608) 262-0986
>
>
----------------------------------------------------------------------------
>
>
>
>
------------------------------------------------
Subject: Incorrect lat and lon data on objects
From: Sarah Griffin
Time: Tue Jul 16 11:55:35 2019
Hi John,
I have. My data is :
float channel_14_brightness_temperature(y, x) ;
channel_14_brightness_temperature:name =
"channel_14_brightness_temperature" ;
channel_14_brightness_temperature:long_name =
"channel_14_brightness_temperature(*,*)" ;
channel_14_brightness_temperature:level = "(*,*)" ;
channel_14_brightness_temperature:reference = "all data are
referenced to the ABI channels" ;
channel_14_brightness_temperature:units = "K" ;
channel_14_brightness_temperature:_FillValue = -999.f ;
and I have
field = {
name = "channel_14_brightness_temperature";
level = "(*,*)";
file_type = NETCDF_MET;
};
in my mode config file and I'm still getting the MetNcFile::data(NcVar
*, const LongArray &, DataPlane &) const -> star found in bad slot
error.
Sorry this is being so difficult,
Sarah
On 7/16/19 12:42 PM, John Halley Gotway via RT wrote:
Sarah,
In the MODE config file, you request what data should be read from the
input gridded data file. The way you do this varies slightly
depending on
the type of file you're reading (GRIB1/2 versus NetCDF). For NetCDF
files
you'd specify:
* field = { name = "NETCDF_VARIABLE_NAME"; level =
"NETCDF_DIMENSION_INFO"; }*
Where NETCDF_DIMENSION_INFO defines how to extract a 2D filed of data
from
the specified NETCDF_VARIABLE_NAME. You put a * for the gridded
dimensions
(i.e. lat and lon). When reading the NetCDF output of
regrid_data_plane,
it's easy. Just set it to "(*,*)".
If you're NetCDF variable had 4 dimensions like this:
float data(time, level, lat, lon);
You could use:
level = "(0, 5, *, *)";
To read data for the first time (0-based) and 6th vertical level.
Thanks,
John
On Tue, Jul 16, 2019 at 11:34 AM Sarah Griffin via RT
<met_help at ucar.edu><mailto:met_help at ucar.edu>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
Thanks John. I hope I'm finally on the right track, but when I'm
running
MODE I'm still getting the error:
MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
found in bad slot
What does that error mean?
Have a great day!
Sarah
On 7/15/19 5:22 PM, John Halley Gotway via RT wrote:
Sarah,
OK, I just ran the following command:
*regrid_data_plane \*
*OR_ABI-L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_
c20191961814170.nc
\*
*
mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
<
http://mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
\*
*goes16_MODE_GRID.nc \*
*-field 'name="Rad"; level="(*,*)";'*
And that produced an output file with bad data values everywhere. The
problem is that the projection information in that MODE output file is
messed up in some way (
mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
)...
which was the original reason you wrote.
So I tried a different route. The "to_grid" option for
regrid_data_plane
can be defined as a named grid (i.e. G212), the path to a gridded data
file, or an explicit grid definition. I tried the latter. Below is
an
excerpt from met-8.1/share/met/config/README:
// - to_grid = "spec"; To define a grid specified as follows:
// - lambert Nx Ny lat_ll lon_ll lon_orient D_km R_km
standard_parallel_1
// [standard_parallel_2] N|S
I used the metadata from the NetCDF files you sent to define the
following
grid definition info:
'lambert 1535 1023 22.45395 -119.2807 262.5 3 6371.2 38.5 N'
And I ran this command:
*regrid_data_plane \*
*OR_ABI-L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_
c20191961814170.nc
\*
*'lambert 1535 1023 22.45395 -119.2807 262.5 3 6371.2 38.5 N' \*
*goes16_USER_DEFINED.nc -field 'name="Rad"; level="(*,*)";'*
And plotted the output. The result (see attached) looks much more
promising. I assume that pattern of missing data values is due to
insufficient GOES 16 data at those locations.
Thanks,
John
On Mon, Jul 15, 2019 at 1:51 PM Sarah Griffin via RT
<met_help at ucar.edu><mailto:met_help at ucar.edu>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
When you say "gridded data file" does that not include a netCDF file?
I'm trying to use a netCDF file as a grid, which I thought MET knows
how
to read. However, I ran my file using regrid_data_plane and then mode
and I get this file
(
mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_19700101_000000V_NAA.ps
)
that I uploaded and the grid is still offset from when I want. Can you
please test and see what happens when you use my file
Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc as the grid
instead of G212?
Also, what does
MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
found in bad slot
mean?
Thanks!
Sarah
On 7/15/19 2:40 PM, John Halley Gotway via RT wrote:
I just posted it. But realize that the whole point is that you can
generate it yourself by running the regrid_data_plane command. And
instead
of using "G212" on the command, just list a gridded data file that MET
knows how to read that's already on your desired model domain. The
tool
will read the grid info from that gridded data file and regrid the
input
GOES-16 values to that domain.
Thanks,
John
On Mon, Jul 15, 2019 at 1:36 PM Sarah Griffin via RT <
met_help at ucar.edu<mailto:met_help at ucar.edu>>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
Hi John,
Reading this a bit more, can you try to run a regrid to the grid that
I
want, which can be found in:
Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc?
Unfortunately, remapping it to NCEP Grid 212 is not useful.
Have a great day!
Sarah
On 7/15/19 2:12 PM, John Halley Gotway via RT wrote:
Sarah,
I grabbed that file from the ftp site and see this header:
*netcdf geocatL1.GOES-16.2018007.000200 {dimensions: x = 2312
;
y = 1191 ;variables: float pixel_latitude(y, x) ;
float
pixel_longitude(y, x) ; float
channel_13_brightness_temperature(y,
x) ;}*
The original GOES-16 file has much more metadata in it that
regrid_data_plane expects and uses. I found some GOES-16 data on our
filesystem and am sending you an example of how it can be used by
regrid_data_plane. Here's the sample data file:
*
ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-L1b-
RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
<
ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-L1b-
RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
*
And here's the command I ran to interpolate it to NCEP Grid 212 which
covers CONUS:
*met-8.1/bin/regrid_data_plane \*
*goes-16/ABI/L1/CONUS/C10/2019196/OR_ABI-L1b-RadC-
M6C10_G16_s20191961811348_e20191961814132_
c20191961814170.nc
\*
*G212 goes16_g212.nc <http://goes16_g212.nc><http://goes16_g212.nc>
-field 'name="Rad";
level="(*,*)";' -method MAX -v 4*
And then I plotted the result:
*met-8.1/bin/plot_data_plane goes16_g212.nc
<http://goes16_g212.nc><http://goes16_g212.nc>
goes16_g212.ps <http://goes16_g212.ps><http://goes16_g212.ps>
'name="Rad"; level="(*,*)";'*
And that plot is attached.
John
On Mon, Jul 15, 2019 at 12:37 PM Sarah Griffin via RT <
met_help at ucar.edu<mailto:met_help at ucar.edu>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
Hi John,
Ok, I've added the original GOES-16 data to the ftp site. I've also
added '
geocatL1.GOES-16.2018007.000200.nc' since the original GOES-16 data
needs
to be rewritten to actually get the brightness temperatures.
I then did:
bin/regrid_data_plane \
geocatL1.GOES-16.2018007.000200.nc \
Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
-field 'name = "channel_13_brightness_temperature"; level =
"(*,*)";
file_type = NETCDF_MET;' \
-v 4
and got the same error "MetNcFile::data(NcVar *, const LongArray &,
DataPlane &) const -> star found in bad slot"
I also added some radar data, Radar_Reflectivity_2018_0107_00_00.nc
and
Radar_Reflectivity_2018_0107_00_00.nc_new. I was able to do:
bin/regrid_data_plane \
Radar_Reflectivity_2018_0107_00_00.nc \
Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
Radar_Reflectivity_2018_0107_00_00.nc_new \
-field 'name = "composite_n0q"; level = "(*,*)"; file_type =
NETCDF_MET;'
\
-v 4
And get the remapping to work. I didn't try this is MODE, though,
because
the composite_n0q data is empty. But I'm curious if any of the
global
attribute data in Radar_Reflectivity_2018_0107_00_00.nc_new is
helpful
in
figuring out what I need to run MODE?
Thanks!
Sarah
On 7/15/19 1:07 PM, John Halley Gotway via RT wrote:
Sarah,
What I'm recommending is that we go back to the original GOES-16
data,
and
run it through regrid_data_plane to do that remapping step. If we
can
get
that to work, it'll result in an output file that can easily be read
by
MODE.
Otherwise, we're stuck with trying to get the CF-convention
specification
of the WRF domain exactly right, which can be pretty tedious.
John
On Mon, Jul 15, 2019 at 11:17 AM Sarah Griffin via RT <
met_help at ucar.edu<mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
Hi John,
The GOES-16 data I'm trying to use was created after remapping the
native GOES data to the WRF projection from
mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
.
So does it matter what the GOES projection is if I'm trying to remap
it
to a different projection?
I've messed around some more and have gotten to this error on
regrid_data_plane. MetNcFile::data(NcVar *, const LongArray &,
DataPlane
&) const -> star found in bad slot
when using this command:
bin/regrid_data_plane \
remap_geocatL1.GOES-16.CONUS.2018007.060230.nc \
Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
-field 'name = "channel_13_brightness_temperature"; level =
"(*,*)";
file_type = NETCDF_MET;' \
-v 4
Thanks!
Sarah
On 7/15/19 11:58 AM, John Halley Gotway via RT wrote:
Sarah,
Can you please send me a link to the GOES-16 data you're trying to
use?
I
see you have a NetCDF file by this name:
emap_geocatL1.GOES-16.CONUS.2018007.000230.nc
Where did you get this file? Is is a publicly available ftp site?
In general, MET reads gridded data that lives on regular
projections.
GOES
data is a special case... it is not defined on a projection.
Instead,
it's
a whole bunch of high resolution pixels of data. Each pixel has a
lat/lon
associated with it. We enhanced regrid_data_plane to read those
lat/lon's
and interpolate them to a user-requested domain.
I'm hoping to get a sample GOES-16 file and send you example
commands
for
interpolating it to your model domain using regrid_data_plane.
Thanks,
John
On Mon, Jul 15, 2019 at 9:28 AM Sarah Griffin via RT <
met_help at ucar.edu<mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
Hi John,
Update, please ignore the other email I sent. Looks like I was
missing
'-field' instead of field.
However, now I'm getting the error "ERROR :
NcCfFile::read_netcdf_grid() -> Couldn't figure out projection from
information in netCDF file." It seems like I'm a bit stuck because I
don't know the projection. If I did, I wouldn't need to use
regrid_data_plane. Any thoughts?
Thanks!
Sarah
On 7/12/19 5:53 PM, John Halley Gotway via RT wrote:
Sarah,
I'm pretty sure that didn't fix it entirely. When I plot the
channel
15
data with plot_data_plane, I clearly see the outline of FL and the
Eastern
seaboard in the data, but it doesn't line up with the map data. So
there's
clearly still a problem.
I see that you're using GOES-16 data here. MET's regrid_data_plane
tool
should be able to read GOES-16 data and regrid it to a user-defined
grid.
That would be another alternatively for using GOES-16 data in MET.
Thanks,
John
On Fri, Jul 12, 2019 at 4:45 PM John Halley Gotway
<johnhg at ucar.edu<mailto:johnhg at ucar.edu>
<mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu>
wrote:
Hi Sarah,
Thought I'd chime in here to mention the following. This is not
actually
a problem in MODE tool itself, but more of an issue in how MET is
reading
data your input files and placing them on the earth. I usually
recommend
that people run MET's plot_data_plane tool when working with a new
data
source to make sure MET is reading the data well:
*plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
<http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc> plot.ps
<http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps>
'name="channel_10_brightness_temperature";
level="(*,*)";'
-v 4*
This produces a nice looking plot, but there's no country outlines
on
top
of the data! And that usually indicates a problem in the projection
information. But I did find one thing which seems to have helped.
I
changed the longitude_of_central_meridian from 262.5 to -97.5, by
running
the following command:
*ncatted -a longitude_of_central_meridian,Projection,o,f,-97.5
remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
<http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc>
remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
<http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc>*
Those two longitudes are the same since they differ by 360 degrees.
Surprisingly, running plot_data_plane on that modified file did plot
the
map data (see attached image):
*plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
<http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc> plot.ps
<http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps>
'name="channel_10_brightness_temperature";
level="(*,*)";'
-v 4*
Can you confirm that the data lives on the right place on the earth?
Should it be covering the Eastern CONUS and Atlantic? If so, then
we'll
likely need to make a one line fix in MET's library code to rescale
the
longitude values to the expected range of (-180, 180] when we read
them
in.
Thanks,
John
On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT <
met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
On Fri Jul 12 14:56:24 2019,
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
wrote:
Hi,
I'm using Met 8.0 with the bug fixes to run MODE for two netCDF
files.
MODE seems to run just fine, however the latitude and longitude of
the
output is messed up. How can I fix the latitude and longitude? I've
uploaded the data and MODE output to the met_help ftp directory.
Thanks!
Have a great day!
Sarah
Hi Sarah -
Thanks for the data upload.
I've passed this ticket along to Randy, our resident MODE
specialist.
He should get a change to look at this early next week.
David
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC UW-
Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
------------------------------------------------
Subject: Incorrect lat and lon data on objects
From: John Halley Gotway
Time: Tue Jul 16 12:01:26 2019
Sarah,
That would work if the NetCDF file really were the output from one of
the
MET tools. Since it's not, the library code isn't reading the data
properly. Specifically, I'm guessing it's expecting the dimensions to
be
named lat/lon rather than y/x. I know that seems silly, but so it
goes.
You could upload you latest version to the ftp site if you'd like, and
I
could take a look.
Just let me know.
Thanks,
John
On Tue, Jul 16, 2019 at 11:55 AM Sarah Griffin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> I have. My data is :
>
> float channel_14_brightness_temperature(y, x) ;
> channel_14_brightness_temperature:name =
> "channel_14_brightness_temperature" ;
> channel_14_brightness_temperature:long_name =
> "channel_14_brightness_temperature(*,*)" ;
> channel_14_brightness_temperature:level = "(*,*)" ;
> channel_14_brightness_temperature:reference = "all data are
> referenced to the ABI channels" ;
> channel_14_brightness_temperature:units = "K" ;
> channel_14_brightness_temperature:_FillValue = -999.f ;
>
>
> and I have
>
> field = {
> name = "channel_14_brightness_temperature";
> level = "(*,*)";
> file_type = NETCDF_MET;
> };
>
> in my mode config file and I'm still getting the
MetNcFile::data(NcVar *,
> const LongArray &, DataPlane &) const -> star found in bad slot
error.
>
> Sorry this is being so difficult,
> Sarah
>
> On 7/16/19 12:42 PM, John Halley Gotway via RT wrote:
>
> Sarah,
>
> In the MODE config file, you request what data should be read from
the
> input gridded data file. The way you do this varies slightly
depending on
> the type of file you're reading (GRIB1/2 versus NetCDF). For NetCDF
files
> you'd specify:
>
>
>
> * field = { name = "NETCDF_VARIABLE_NAME"; level =
> "NETCDF_DIMENSION_INFO"; }*
>
> Where NETCDF_DIMENSION_INFO defines how to extract a 2D filed of
data from
> the specified NETCDF_VARIABLE_NAME. You put a * for the gridded
dimensions
> (i.e. lat and lon). When reading the NetCDF output of
regrid_data_plane,
> it's easy. Just set it to "(*,*)".
>
> If you're NetCDF variable had 4 dimensions like this:
> float data(time, level, lat, lon);
>
> You could use:
> level = "(0, 5, *, *)";
>
> To read data for the first time (0-based) and 6th vertical level.
>
> Thanks,
> John
>
>
>
>
>
>
> On Tue, Jul 16, 2019 at 11:34 AM Sarah Griffin via RT
<met_help at ucar.edu
> ><mailto:met_help at ucar.edu>
> wrote:
>
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Thanks John. I hope I'm finally on the right track, but when I'm
running
> MODE I'm still getting the error:
>
> MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
> found in bad slot
>
> What does that error mean?
>
> Have a great day!
> Sarah
>
> On 7/15/19 5:22 PM, John Halley Gotway via RT wrote:
>
>
> Sarah,
>
> OK, I just ran the following command:
>
> *regrid_data_plane \*
> *OR_ABI-L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_
>
>
> c20191961814170.nc
>
>
> \*
> *
>
>
>
> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
>
>
> <
>
>
>
> http://mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
>
>
>
> \*
> *goes16_MODE_GRID.nc \*
> *-field 'name="Rad"; level="(*,*)";'*
>
> And that produced an output file with bad data values everywhere.
The
> problem is that the projection information in that MODE output file
is
> messed up in some way (
>
>
>
>
> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
> )...
>
>
> which was the original reason you wrote.
>
> So I tried a different route. The "to_grid" option for
regrid_data_plane
> can be defined as a named grid (i.e. G212), the path to a gridded
data
> file, or an explicit grid definition. I tried the latter. Below is
an
> excerpt from met-8.1/share/met/config/README:
>
> // - to_grid = "spec"; To define a grid specified as follows:
> // - lambert Nx Ny lat_ll lon_ll lon_orient D_km R_km
> standard_parallel_1
> // [standard_parallel_2] N|S
>
> I used the metadata from the NetCDF files you sent to define the
>
>
> following
>
>
> grid definition info:
> 'lambert 1535 1023 22.45395 -119.2807 262.5 3 6371.2 38.5 N'
>
> And I ran this command:
>
> *regrid_data_plane \*
> *OR_ABI-L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_
>
>
> c20191961814170.nc
>
>
> \*
> *'lambert 1535 1023 22.45395 -119.2807 262.5 3 6371.2 38.5 N' \*
> *goes16_USER_DEFINED.nc -field 'name="Rad"; level="(*,*)";'*
>
> And plotted the output. The result (see attached) looks much more
> promising. I assume that pattern of missing data values is due to
> insufficient GOES 16 data at those locations.
>
> Thanks,
> John
>
> On Mon, Jul 15, 2019 at 1:51 PM Sarah Griffin via RT
<met_help at ucar.edu
> ><mailto:met_help at ucar.edu>
> wrote:
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> When you say "gridded data file" does that not include a netCDF
file?
> I'm trying to use a netCDF file as a grid, which I thought MET knows
how
> to read. However, I ran my file using regrid_data_plane and then
mode
> and I get this file
> (
>
>
>
>
> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_19700101_000000V_NAA.ps
> )
>
>
>
> that I uploaded and the grid is still offset from when I want. Can
you
> please test and see what happens when you use my file
> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc as the
grid
> instead of G212?
>
> Also, what does
> MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
> found in bad slot
> mean?
>
> Thanks!
> Sarah
>
> On 7/15/19 2:40 PM, John Halley Gotway via RT wrote:
>
>
> I just posted it. But realize that the whole point is that you can
> generate it yourself by running the regrid_data_plane command. And
>
>
> instead
>
>
> of using "G212" on the command, just list a gridded data file that
MET
> knows how to read that's already on your desired model domain. The
>
>
> tool
>
>
> will read the grid info from that gridded data file and regrid the
>
>
> input
>
>
> GOES-16 values to that domain.
>
> Thanks,
> John
>
> On Mon, Jul 15, 2019 at 1:36 PM Sarah Griffin via RT <
>
>
> met_help at ucar.edu<mailto:met_help at ucar.edu>>
>
>
> wrote:
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> Reading this a bit more, can you try to run a regrid to the grid
that
>
>
> I
>
>
> want, which can be found in:
> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc?
> Unfortunately, remapping it to NCEP Grid 212 is not useful.
>
> Have a great day!
> Sarah
>
> On 7/15/19 2:12 PM, John Halley Gotway via RT wrote:
>
>
> Sarah,
>
> I grabbed that file from the ftp site and see this header:
>
>
>
>
>
>
>
>
>
> *netcdf geocatL1.GOES-16.2018007.000200 {dimensions: x = 2312
>
>
> ;
>
>
> y = 1191 ;variables: float pixel_latitude(y, x) ;
>
>
> float
>
>
> pixel_longitude(y, x) ; float
>
>
> channel_13_brightness_temperature(y,
>
>
> x) ;}*
>
> The original GOES-16 file has much more metadata in it that
> regrid_data_plane expects and uses. I found some GOES-16 data on
our
> filesystem and am sending you an example of how it can be used by
> regrid_data_plane. Here's the sample data file:
>
> *
>
>
>
>
>
>
> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
>
>
> <
>
>
>
>
>
>
> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
>
>
> *
>
> And here's the command I ran to interpolate it to NCEP Grid 212
which
> covers CONUS:
>
> *met-8.1/bin/regrid_data_plane \*
>
>
>
>
>
>
>
> *goes-16/ABI/L1/CONUS/C10/2019196/OR_ABI-L1b-RadC-
M6C10_G16_s20191961811348_e20191961814132_
>
>
> c20191961814170.nc
>
>
> \*
> *G212 goes16_g212.nc <http://goes16_g212.nc><http://goes16_g212.nc>
> -field 'name="Rad";
> level="(*,*)";' -method MAX -v 4*
>
> And then I plotted the result:
>
> *met-8.1/bin/plot_data_plane goes16_g212.nc <http://goes16_g212.nc><
> http://goes16_g212.nc>
> goes16_g212.ps <http://goes16_g212.ps><http://goes16_g212.ps>
> 'name="Rad"; level="(*,*)";'*
>
> And that plot is attached.
>
> John
>
> On Mon, Jul 15, 2019 at 12:37 PM Sarah Griffin via RT <
>
>
> met_help at ucar.edu<mailto:met_help at ucar.edu>
>
>
> wrote:
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> Ok, I've added the original GOES-16 data to the ftp site. I've also
>
>
> added '
>
>
> geocatL1.GOES-16.2018007.000200.nc' since the original GOES-16 data
>
>
> needs
>
>
> to be rewritten to actually get the brightness temperatures.
>
> I then did:
> bin/regrid_data_plane \
> geocatL1.GOES-16.2018007.000200.nc \
> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
> -field 'name = "channel_13_brightness_temperature"; level =
>
>
> "(*,*)";
>
>
> file_type = NETCDF_MET;' \
> -v 4
>
> and got the same error "MetNcFile::data(NcVar *, const LongArray &,
> DataPlane &) const -> star found in bad slot"
>
>
>
> I also added some radar data, Radar_Reflectivity_2018_0107_00_00.nc
>
>
> and
>
>
> Radar_Reflectivity_2018_0107_00_00.nc_new. I was able to do:
>
> bin/regrid_data_plane \
> Radar_Reflectivity_2018_0107_00_00.nc \
> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
> Radar_Reflectivity_2018_0107_00_00.nc_new \
> -field 'name = "composite_n0q"; level = "(*,*)"; file_type =
>
>
> NETCDF_MET;'
>
>
> \
> -v 4
>
> And get the remapping to work. I didn't try this is MODE, though,
>
>
> because
>
>
> the composite_n0q data is empty. But I'm curious if any of the
>
>
> global
>
>
> attribute data in Radar_Reflectivity_2018_0107_00_00.nc_new is
>
>
> helpful
>
>
> in
>
>
> figuring out what I need to run MODE?
>
> Thanks!
> Sarah
>
> On 7/15/19 1:07 PM, John Halley Gotway via RT wrote:
>
> Sarah,
>
> What I'm recommending is that we go back to the original GOES-16
>
>
> data,
>
>
> and
>
>
> run it through regrid_data_plane to do that remapping step. If we
>
>
> can
>
>
> get
>
>
> that to work, it'll result in an output file that can easily be read
>
>
> by
>
>
> MODE.
>
> Otherwise, we're stuck with trying to get the CF-convention
>
>
> specification
>
>
> of the WRF domain exactly right, which can be pretty tedious.
>
> John
>
> On Mon, Jul 15, 2019 at 11:17 AM Sarah Griffin via RT <
>
>
> met_help at ucar.edu<mailto:met_help at ucar.edu>
>
>
> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
>
>
> wrote:
>
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> The GOES-16 data I'm trying to use was created after remapping the
> native GOES data to the WRF projection from
>
>
>
>
>
>
>
>
>
> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
>
>
> .
>
> So does it matter what the GOES projection is if I'm trying to remap
>
>
> it
>
>
> to a different projection?
>
> I've messed around some more and have gotten to this error on
> regrid_data_plane. MetNcFile::data(NcVar *, const LongArray &,
>
>
> DataPlane
>
>
> &) const -> star found in bad slot
>
> when using this command:
> bin/regrid_data_plane \
> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc \
> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
> -field 'name = "channel_13_brightness_temperature"; level =
>
>
> "(*,*)";
>
>
> file_type = NETCDF_MET;' \
> -v 4
>
> Thanks!
> Sarah
>
> On 7/15/19 11:58 AM, John Halley Gotway via RT wrote:
>
>
> Sarah,
>
> Can you please send me a link to the GOES-16 data you're trying to
>
>
> use?
>
>
>
> I
>
>
> see you have a NetCDF file by this name:
> emap_geocatL1.GOES-16.CONUS.2018007.000230.nc
> Where did you get this file? Is is a publicly available ftp site?
>
> In general, MET reads gridded data that lives on regular
>
>
> projections.
>
>
>
>
> GOES
>
>
> data is a special case... it is not defined on a projection.
>
>
> Instead,
>
>
>
>
> it's
>
>
> a whole bunch of high resolution pixels of data. Each pixel has a
>
>
> lat/lon
>
>
> associated with it. We enhanced regrid_data_plane to read those
>
>
> lat/lon's
>
>
> and interpolate them to a user-requested domain.
>
> I'm hoping to get a sample GOES-16 file and send you example
>
>
> commands
>
>
> for
>
>
> interpolating it to your model domain using regrid_data_plane.
>
> Thanks,
> John
>
> On Mon, Jul 15, 2019 at 9:28 AM Sarah Griffin via RT <
>
>
> met_help at ucar.edu<mailto:met_help at ucar.edu>
>
>
> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
>
>
> wrote:
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> Update, please ignore the other email I sent. Looks like I was
>
>
> missing
>
>
> '-field' instead of field.
>
> However, now I'm getting the error "ERROR :
> NcCfFile::read_netcdf_grid() -> Couldn't figure out projection from
> information in netCDF file." It seems like I'm a bit stuck because I
> don't know the projection. If I did, I wouldn't need to use
> regrid_data_plane. Any thoughts?
>
> Thanks!
> Sarah
>
> On 7/12/19 5:53 PM, John Halley Gotway via RT wrote:
>
>
> Sarah,
>
> I'm pretty sure that didn't fix it entirely. When I plot the
>
>
> channel
>
>
>
>
> 15
>
>
> data with plot_data_plane, I clearly see the outline of FL and the
>
>
> Eastern
>
>
> seaboard in the data, but it doesn't line up with the map data. So
>
>
> there's
>
>
> clearly still a problem.
>
> I see that you're using GOES-16 data here. MET's regrid_data_plane
>
>
> tool
>
>
> should be able to read GOES-16 data and regrid it to a user-defined
>
>
> grid.
>
>
> That would be another alternatively for using GOES-16 data in MET.
>
> Thanks,
> John
>
> On Fri, Jul 12, 2019 at 4:45 PM John Halley Gotway <johnhg at ucar.edu
> <mailto:johnhg at ucar.edu>
>
>
> <mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu>
>
>
> wrote:
>
>
> Hi Sarah,
>
> Thought I'd chime in here to mention the following. This is not
>
>
> actually
>
>
> a problem in MODE tool itself, but more of an issue in how MET is
>
>
> reading
>
>
> data your input files and placing them on the earth. I usually
>
>
> recommend
>
>
> that people run MET's plot_data_plane tool when working with a new
>
>
> data
>
>
> source to make sure MET is reading the data well:
>
> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc> plot.ps
> <http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps>
> 'name="channel_10_brightness_temperature";
>
>
> level="(*,*)";'
>
>
> -v 4*
>
> This produces a nice looking plot, but there's no country outlines
>
>
> on
>
>
>
>
> top
>
>
> of the data! And that usually indicates a problem in the projection
> information. But I did find one thing which seems to have helped.
>
>
> I
>
>
> changed the longitude_of_central_meridian from 262.5 to -97.5, by
>
>
> running
>
>
> the following command:
>
> *ncatted -a longitude_of_central_meridian,Projection,o,f,-97.5
> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc>
> remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>*
>
> Those two longitudes are the same since they differ by 360 degrees.
> Surprisingly, running plot_data_plane on that modified file did plot
>
>
> the
>
>
> map data (see attached image):
>
> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc> plot.ps
> <http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps>
> 'name="channel_10_brightness_temperature";
>
>
> level="(*,*)";'
>
>
> -v 4*
>
> Can you confirm that the data lives on the right place on the earth?
> Should it be covering the Eastern CONUS and Atlantic? If so, then
>
>
> we'll
>
>
> likely need to make a one line fix in MET's library code to rescale
>
>
> the
>
>
> longitude values to the expected range of (-180, 180] when we read
>
>
> them
>
>
> in.
>
>
> Thanks,
> John
>
> On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT <
>
>
> met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
> ><mailto:met_help at ucar.edu>>
>
>
> wrote:
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> On Fri Jul 12 14:56:24 2019, sarah.griffin at ssec.wisc.edu<mailto:
> sarah.griffin at ssec.wisc.edu><mailto:
> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
wrote:
>
>
> Hi,
>
> I'm using Met 8.0 with the bug fixes to run MODE for two netCDF
>
>
> files.
>
>
> MODE seems to run just fine, however the latitude and longitude of
>
>
> the
>
>
> output is messed up. How can I fix the latitude and longitude? I've
> uploaded the data and MODE output to the met_help ftp directory.
>
>
> Thanks!
>
>
> Have a great day!
> Sarah
>
>
>
> Hi Sarah -
> Thanks for the data upload.
> I've passed this ticket along to Randy, our resident MODE
>
>
> specialist.
>
>
> He should get a change to look at this early next week.
> David
>
>
>
>
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
>
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
>
> --
>
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
>
>
> --
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
> --
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
>
>
>
> --
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
>
> --
>
>
>
----------------------------------------------------------------------------
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
>
>
> --
>
>
----------------------------------------------------------------------------
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
----------------------------------------------------------------------------
>
>
>
------------------------------------------------
Subject: Incorrect lat and lon data on objects
From: Sarah Griffin
Time: Tue Jul 16 12:24:45 2019
Hi John,
Instead of uploading the latest version to the ftp site, I'll just
include this screen shot because lat/lon instead of y/x was the
solution![MODE output]
Have a great day!
Sarah
On 7/16/19 1:01 PM, John Halley Gotway via RT wrote:
Sarah,
That would work if the NetCDF file really were the output from one of
the
MET tools. Since it's not, the library code isn't reading the data
properly. Specifically, I'm guessing it's expecting the dimensions to
be
named lat/lon rather than y/x. I know that seems silly, but so it
goes.
You could upload you latest version to the ftp site if you'd like, and
I
could take a look.
Just let me know.
Thanks,
John
On Tue, Jul 16, 2019 at 11:55 AM Sarah Griffin via RT
<met_help at ucar.edu><mailto:met_help at ucar.edu>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
Hi John,
I have. My data is :
float channel_14_brightness_temperature(y, x) ;
channel_14_brightness_temperature:name =
"channel_14_brightness_temperature" ;
channel_14_brightness_temperature:long_name =
"channel_14_brightness_temperature(*,*)" ;
channel_14_brightness_temperature:level = "(*,*)" ;
channel_14_brightness_temperature:reference = "all data are
referenced to the ABI channels" ;
channel_14_brightness_temperature:units = "K" ;
channel_14_brightness_temperature:_FillValue = -999.f ;
and I have
field = {
name = "channel_14_brightness_temperature";
level = "(*,*)";
file_type = NETCDF_MET;
};
in my mode config file and I'm still getting the MetNcFile::data(NcVar
*,
const LongArray &, DataPlane &) const -> star found in bad slot
error.
Sorry this is being so difficult,
Sarah
On 7/16/19 12:42 PM, John Halley Gotway via RT wrote:
Sarah,
In the MODE config file, you request what data should be read from the
input gridded data file. The way you do this varies slightly
depending on
the type of file you're reading (GRIB1/2 versus NetCDF). For NetCDF
files
you'd specify:
* field = { name = "NETCDF_VARIABLE_NAME"; level =
"NETCDF_DIMENSION_INFO"; }*
Where NETCDF_DIMENSION_INFO defines how to extract a 2D filed of data
from
the specified NETCDF_VARIABLE_NAME. You put a * for the gridded
dimensions
(i.e. lat and lon). When reading the NetCDF output of
regrid_data_plane,
it's easy. Just set it to "(*,*)".
If you're NetCDF variable had 4 dimensions like this:
float data(time, level, lat, lon);
You could use:
level = "(0, 5, *, *)";
To read data for the first time (0-based) and 6th vertical level.
Thanks,
John
On Tue, Jul 16, 2019 at 11:34 AM Sarah Griffin via RT
<met_help at ucar.edu<mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
Thanks John. I hope I'm finally on the right track, but when I'm
running
MODE I'm still getting the error:
MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
found in bad slot
What does that error mean?
Have a great day!
Sarah
On 7/15/19 5:22 PM, John Halley Gotway via RT wrote:
Sarah,
OK, I just ran the following command:
*regrid_data_plane \*
*OR_ABI-L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_
c20191961814170.nc
\*
*
mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
<
http://mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
\*
*goes16_MODE_GRID.nc \*
*-field 'name="Rad"; level="(*,*)";'*
And that produced an output file with bad data values everywhere. The
problem is that the projection information in that MODE output file is
messed up in some way (
mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
)...
which was the original reason you wrote.
So I tried a different route. The "to_grid" option for
regrid_data_plane
can be defined as a named grid (i.e. G212), the path to a gridded data
file, or an explicit grid definition. I tried the latter. Below is
an
excerpt from met-8.1/share/met/config/README:
// - to_grid = "spec"; To define a grid specified as follows:
// - lambert Nx Ny lat_ll lon_ll lon_orient D_km R_km
standard_parallel_1
// [standard_parallel_2] N|S
I used the metadata from the NetCDF files you sent to define the
following
grid definition info:
'lambert 1535 1023 22.45395 -119.2807 262.5 3 6371.2 38.5 N'
And I ran this command:
*regrid_data_plane \*
*OR_ABI-L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_
c20191961814170.nc
\*
*'lambert 1535 1023 22.45395 -119.2807 262.5 3 6371.2 38.5 N' \*
*goes16_USER_DEFINED.nc -field 'name="Rad"; level="(*,*)";'*
And plotted the output. The result (see attached) looks much more
promising. I assume that pattern of missing data values is due to
insufficient GOES 16 data at those locations.
Thanks,
John
On Mon, Jul 15, 2019 at 1:51 PM Sarah Griffin via RT
<met_help at ucar.edu<mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
When you say "gridded data file" does that not include a netCDF file?
I'm trying to use a netCDF file as a grid, which I thought MET knows
how
to read. However, I ran my file using regrid_data_plane and then mode
and I get this file
(
mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_19700101_000000V_NAA.ps
)
that I uploaded and the grid is still offset from when I want. Can you
please test and see what happens when you use my file
Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc as the grid
instead of G212?
Also, what does
MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
found in bad slot
mean?
Thanks!
Sarah
On 7/15/19 2:40 PM, John Halley Gotway via RT wrote:
I just posted it. But realize that the whole point is that you can
generate it yourself by running the regrid_data_plane command. And
instead
of using "G212" on the command, just list a gridded data file that MET
knows how to read that's already on your desired model domain. The
tool
will read the grid info from that gridded data file and regrid the
input
GOES-16 values to that domain.
Thanks,
John
On Mon, Jul 15, 2019 at 1:36 PM Sarah Griffin via RT <
met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
Hi John,
Reading this a bit more, can you try to run a regrid to the grid that
I
want, which can be found in:
Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc?
Unfortunately, remapping it to NCEP Grid 212 is not useful.
Have a great day!
Sarah
On 7/15/19 2:12 PM, John Halley Gotway via RT wrote:
Sarah,
I grabbed that file from the ftp site and see this header:
*netcdf geocatL1.GOES-16.2018007.000200 {dimensions: x = 2312
;
y = 1191 ;variables: float pixel_latitude(y, x) ;
float
pixel_longitude(y, x) ; float
channel_13_brightness_temperature(y,
x) ;}*
The original GOES-16 file has much more metadata in it that
regrid_data_plane expects and uses. I found some GOES-16 data on our
filesystem and am sending you an example of how it can be used by
regrid_data_plane. Here's the sample data file:
*
ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-L1b-
RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
<
ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-L1b-
RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
*
And here's the command I ran to interpolate it to NCEP Grid 212 which
covers CONUS:
*met-8.1/bin/regrid_data_plane \*
*goes-16/ABI/L1/CONUS/C10/2019196/OR_ABI-L1b-RadC-
M6C10_G16_s20191961811348_e20191961814132_
c20191961814170.nc
\*
*G212 goes16_g212.nc
<http://goes16_g212.nc><http://goes16_g212.nc><http://goes16_g212.nc><http://goes16_g212.nc>
-field 'name="Rad";
level="(*,*)";' -method MAX -v 4*
And then I plotted the result:
*met-8.1/bin/plot_data_plane goes16_g212.nc
<http://goes16_g212.nc><http://goes16_g212.nc><
http://goes16_g212.nc><http://goes16_g212.nc>
goes16_g212.ps
<http://goes16_g212.ps><http://goes16_g212.ps><http://goes16_g212.ps><http://goes16_g212.ps>
'name="Rad"; level="(*,*)";'*
And that plot is attached.
John
On Mon, Jul 15, 2019 at 12:37 PM Sarah Griffin via RT <
met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
Hi John,
Ok, I've added the original GOES-16 data to the ftp site. I've also
added '
geocatL1.GOES-16.2018007.000200.nc' since the original GOES-16 data
needs
to be rewritten to actually get the brightness temperatures.
I then did:
bin/regrid_data_plane \
geocatL1.GOES-16.2018007.000200.nc \
Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
-field 'name = "channel_13_brightness_temperature"; level =
"(*,*)";
file_type = NETCDF_MET;' \
-v 4
and got the same error "MetNcFile::data(NcVar *, const LongArray &,
DataPlane &) const -> star found in bad slot"
I also added some radar data, Radar_Reflectivity_2018_0107_00_00.nc
and
Radar_Reflectivity_2018_0107_00_00.nc_new. I was able to do:
bin/regrid_data_plane \
Radar_Reflectivity_2018_0107_00_00.nc \
Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
Radar_Reflectivity_2018_0107_00_00.nc_new \
-field 'name = "composite_n0q"; level = "(*,*)"; file_type =
NETCDF_MET;'
\
-v 4
And get the remapping to work. I didn't try this is MODE, though,
because
the composite_n0q data is empty. But I'm curious if any of the
global
attribute data in Radar_Reflectivity_2018_0107_00_00.nc_new is
helpful
in
figuring out what I need to run MODE?
Thanks!
Sarah
On 7/15/19 1:07 PM, John Halley Gotway via RT wrote:
Sarah,
What I'm recommending is that we go back to the original GOES-16
data,
and
run it through regrid_data_plane to do that remapping step. If we
can
get
that to work, it'll result in an output file that can easily be read
by
MODE.
Otherwise, we're stuck with trying to get the CF-convention
specification
of the WRF domain exactly right, which can be pretty tedious.
John
On Mon, Jul 15, 2019 at 11:17 AM Sarah Griffin via RT <
met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
Hi John,
The GOES-16 data I'm trying to use was created after remapping the
native GOES data to the WRF projection from
mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
.
So does it matter what the GOES projection is if I'm trying to remap
it
to a different projection?
I've messed around some more and have gotten to this error on
regrid_data_plane. MetNcFile::data(NcVar *, const LongArray &,
DataPlane
&) const -> star found in bad slot
when using this command:
bin/regrid_data_plane \
remap_geocatL1.GOES-16.CONUS.2018007.060230.nc \
Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
-field 'name = "channel_13_brightness_temperature"; level =
"(*,*)";
file_type = NETCDF_MET;' \
-v 4
Thanks!
Sarah
On 7/15/19 11:58 AM, John Halley Gotway via RT wrote:
Sarah,
Can you please send me a link to the GOES-16 data you're trying to
use?
I
see you have a NetCDF file by this name:
emap_geocatL1.GOES-16.CONUS.2018007.000230.nc
Where did you get this file? Is is a publicly available ftp site?
In general, MET reads gridded data that lives on regular
projections.
GOES
data is a special case... it is not defined on a projection.
Instead,
it's
a whole bunch of high resolution pixels of data. Each pixel has a
lat/lon
associated with it. We enhanced regrid_data_plane to read those
lat/lon's
and interpolate them to a user-requested domain.
I'm hoping to get a sample GOES-16 file and send you example
commands
for
interpolating it to your model domain using regrid_data_plane.
Thanks,
John
On Mon, Jul 15, 2019 at 9:28 AM Sarah Griffin via RT <
met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
Hi John,
Update, please ignore the other email I sent. Looks like I was
missing
'-field' instead of field.
However, now I'm getting the error "ERROR :
NcCfFile::read_netcdf_grid() -> Couldn't figure out projection from
information in netCDF file." It seems like I'm a bit stuck because I
don't know the projection. If I did, I wouldn't need to use
regrid_data_plane. Any thoughts?
Thanks!
Sarah
On 7/12/19 5:53 PM, John Halley Gotway via RT wrote:
Sarah,
I'm pretty sure that didn't fix it entirely. When I plot the
channel
15
data with plot_data_plane, I clearly see the outline of FL and the
Eastern
seaboard in the data, but it doesn't line up with the map data. So
there's
clearly still a problem.
I see that you're using GOES-16 data here. MET's regrid_data_plane
tool
should be able to read GOES-16 data and regrid it to a user-defined
grid.
That would be another alternatively for using GOES-16 data in MET.
Thanks,
John
On Fri, Jul 12, 2019 at 4:45 PM John Halley Gotway
<johnhg at ucar.edu<mailto:johnhg at ucar.edu>
<mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu>
<mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu>
wrote:
Hi Sarah,
Thought I'd chime in here to mention the following. This is not
actually
a problem in MODE tool itself, but more of an issue in how MET is
reading
data your input files and placing them on the earth. I usually
recommend
that people run MET's plot_data_plane tool when working with a new
data
source to make sure MET is reading the data well:
*plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
<http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc> plot.ps
<http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps>
'name="channel_10_brightness_temperature";
level="(*,*)";'
-v 4*
This produces a nice looking plot, but there's no country outlines
on
top
of the data! And that usually indicates a problem in the projection
information. But I did find one thing which seems to have helped.
I
changed the longitude_of_central_meridian from 262.5 to -97.5, by
running
the following command:
*ncatted -a longitude_of_central_meridian,Projection,o,f,-97.5
remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
<http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc>
remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
<http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc>*
Those two longitudes are the same since they differ by 360 degrees.
Surprisingly, running plot_data_plane on that modified file did plot
the
map data (see attached image):
*plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
<http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc> plot.ps
<http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps>
'name="channel_10_brightness_temperature";
level="(*,*)";'
-v 4*
Can you confirm that the data lives on the right place on the earth?
Should it be covering the Eastern CONUS and Atlantic? If so, then
we'll
likely need to make a one line fix in MET's library code to rescale
the
longitude values to the expected range of (-180, 180] when we read
them
in.
Thanks,
John
On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT <
met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
On Fri Jul 12 14:56:24 2019,
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
wrote:
Hi,
I'm using Met 8.0 with the bug fixes to run MODE for two netCDF
files.
MODE seems to run just fine, however the latitude and longitude of
the
output is messed up. How can I fix the latitude and longitude? I've
uploaded the data and MODE output to the met_help ftp directory.
Thanks!
Have a great day!
Sarah
Hi Sarah -
Thanks for the data upload.
I've passed this ticket along to Randy, our resident MODE
specialist.
He should get a change to look at this early next week.
David
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC UW-
Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
------------------------------------------------
Subject: Incorrect lat and lon data on objects
From: John Halley Gotway
Time: Tue Jul 16 13:07:18 2019
Sarah,
Ah great! Looks like you're all set. Sorry that was such a hassle!
Do
you have any remaining issues or questions I can help answer?
Thanks,
John
On Tue, Jul 16, 2019 at 12:24 PM Sarah Griffin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> Instead of uploading the latest version to the ftp site, I'll just
include
> this screen shot because lat/lon instead of y/x was the
solution![MODE
> output]
>
> Have a great day!
> Sarah
>
> On 7/16/19 1:01 PM, John Halley Gotway via RT wrote:
>
> Sarah,
>
> That would work if the NetCDF file really were the output from one
of the
> MET tools. Since it's not, the library code isn't reading the data
> properly. Specifically, I'm guessing it's expecting the dimensions
to be
> named lat/lon rather than y/x. I know that seems silly, but so it
goes.
>
> You could upload you latest version to the ftp site if you'd like,
and I
> could take a look.
>
> Just let me know.
>
> Thanks,
> John
>
> On Tue, Jul 16, 2019 at 11:55 AM Sarah Griffin via RT
<met_help at ucar.edu
> ><mailto:met_help at ucar.edu>
> wrote:
>
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> I have. My data is :
>
> float channel_14_brightness_temperature(y, x) ;
> channel_14_brightness_temperature:name =
> "channel_14_brightness_temperature" ;
> channel_14_brightness_temperature:long_name =
> "channel_14_brightness_temperature(*,*)" ;
> channel_14_brightness_temperature:level = "(*,*)" ;
> channel_14_brightness_temperature:reference = "all data are
> referenced to the ABI channels" ;
> channel_14_brightness_temperature:units = "K" ;
> channel_14_brightness_temperature:_FillValue = -999.f ;
>
>
> and I have
>
> field = {
> name = "channel_14_brightness_temperature";
> level = "(*,*)";
> file_type = NETCDF_MET;
> };
>
> in my mode config file and I'm still getting the
MetNcFile::data(NcVar *,
> const LongArray &, DataPlane &) const -> star found in bad slot
error.
>
> Sorry this is being so difficult,
> Sarah
>
> On 7/16/19 12:42 PM, John Halley Gotway via RT wrote:
>
> Sarah,
>
> In the MODE config file, you request what data should be read from
the
> input gridded data file. The way you do this varies slightly
depending on
> the type of file you're reading (GRIB1/2 versus NetCDF). For NetCDF
files
> you'd specify:
>
>
>
> * field = { name = "NETCDF_VARIABLE_NAME"; level =
> "NETCDF_DIMENSION_INFO"; }*
>
> Where NETCDF_DIMENSION_INFO defines how to extract a 2D filed of
data from
> the specified NETCDF_VARIABLE_NAME. You put a * for the gridded
dimensions
> (i.e. lat and lon). When reading the NetCDF output of
regrid_data_plane,
> it's easy. Just set it to "(*,*)".
>
> If you're NetCDF variable had 4 dimensions like this:
> float data(time, level, lat, lon);
>
> You could use:
> level = "(0, 5, *, *)";
>
> To read data for the first time (0-based) and 6th vertical level.
>
> Thanks,
> John
>
>
>
>
>
>
> On Tue, Jul 16, 2019 at 11:34 AM Sarah Griffin via RT
<met_help at ucar.edu
> <mailto:met_help at ucar.edu>
>
>
> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
>
>
> wrote:
>
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Thanks John. I hope I'm finally on the right track, but when I'm
running
> MODE I'm still getting the error:
>
> MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
> found in bad slot
>
> What does that error mean?
>
> Have a great day!
> Sarah
>
> On 7/15/19 5:22 PM, John Halley Gotway via RT wrote:
>
>
> Sarah,
>
> OK, I just ran the following command:
>
> *regrid_data_plane \*
> *OR_ABI-L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_
>
>
> c20191961814170.nc
>
>
> \*
> *
>
>
>
>
> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
>
>
> <
>
>
>
>
> http://mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
>
>
>
> \*
> *goes16_MODE_GRID.nc \*
> *-field 'name="Rad"; level="(*,*)";'*
>
> And that produced an output file with bad data values everywhere.
The
> problem is that the projection information in that MODE output file
is
> messed up in some way (
>
>
>
>
>
> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
> )...
>
>
> which was the original reason you wrote.
>
> So I tried a different route. The "to_grid" option for
regrid_data_plane
> can be defined as a named grid (i.e. G212), the path to a gridded
data
> file, or an explicit grid definition. I tried the latter. Below is
an
> excerpt from met-8.1/share/met/config/README:
>
> // - to_grid = "spec"; To define a grid specified as follows:
> // - lambert Nx Ny lat_ll lon_ll lon_orient D_km R_km
> standard_parallel_1
> // [standard_parallel_2] N|S
>
> I used the metadata from the NetCDF files you sent to define the
>
>
> following
>
>
> grid definition info:
> 'lambert 1535 1023 22.45395 -119.2807 262.5 3 6371.2 38.5 N'
>
> And I ran this command:
>
> *regrid_data_plane \*
> *OR_ABI-L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_
>
>
> c20191961814170.nc
>
>
> \*
> *'lambert 1535 1023 22.45395 -119.2807 262.5 3 6371.2 38.5 N' \*
> *goes16_USER_DEFINED.nc -field 'name="Rad"; level="(*,*)";'*
>
> And plotted the output. The result (see attached) looks much more
> promising. I assume that pattern of missing data values is due to
> insufficient GOES 16 data at those locations.
>
> Thanks,
> John
>
> On Mon, Jul 15, 2019 at 1:51 PM Sarah Griffin via RT
<met_help at ucar.edu
> <mailto:met_help at ucar.edu>
>
>
> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
>
>
> wrote:
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> When you say "gridded data file" does that not include a netCDF
file?
> I'm trying to use a netCDF file as a grid, which I thought MET knows
how
> to read. However, I ran my file using regrid_data_plane and then
mode
> and I get this file
> (
>
>
>
>
>
> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_19700101_000000V_NAA.ps
> )
>
>
>
> that I uploaded and the grid is still offset from when I want. Can
you
> please test and see what happens when you use my file
> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc as the
grid
> instead of G212?
>
> Also, what does
> MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
> found in bad slot
> mean?
>
> Thanks!
> Sarah
>
> On 7/15/19 2:40 PM, John Halley Gotway via RT wrote:
>
>
> I just posted it. But realize that the whole point is that you can
> generate it yourself by running the regrid_data_plane command. And
>
>
> instead
>
>
> of using "G212" on the command, just list a gridded data file that
MET
> knows how to read that's already on your desired model domain. The
>
>
> tool
>
>
> will read the grid info from that gridded data file and regrid the
>
>
> input
>
>
> GOES-16 values to that domain.
>
> Thanks,
> John
>
> On Mon, Jul 15, 2019 at 1:36 PM Sarah Griffin via RT <
>
>
> met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
> ><mailto:met_help at ucar.edu>>
>
>
> wrote:
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> Reading this a bit more, can you try to run a regrid to the grid
that
>
>
> I
>
>
> want, which can be found in:
> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc?
> Unfortunately, remapping it to NCEP Grid 212 is not useful.
>
> Have a great day!
> Sarah
>
> On 7/15/19 2:12 PM, John Halley Gotway via RT wrote:
>
>
> Sarah,
>
> I grabbed that file from the ftp site and see this header:
>
>
>
>
>
>
>
>
>
> *netcdf geocatL1.GOES-16.2018007.000200 {dimensions: x = 2312
>
>
> ;
>
>
> y = 1191 ;variables: float pixel_latitude(y, x) ;
>
>
> float
>
>
> pixel_longitude(y, x) ; float
>
>
> channel_13_brightness_temperature(y,
>
>
> x) ;}*
>
> The original GOES-16 file has much more metadata in it that
> regrid_data_plane expects and uses. I found some GOES-16 data on
our
> filesystem and am sending you an example of how it can be used by
> regrid_data_plane. Here's the sample data file:
>
> *
>
>
>
>
>
>
>
> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
>
>
> <
>
>
>
>
>
>
>
> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
>
>
> *
>
> And here's the command I ran to interpolate it to NCEP Grid 212
which
> covers CONUS:
>
> *met-8.1/bin/regrid_data_plane \*
>
>
>
>
>
>
>
>
> *goes-16/ABI/L1/CONUS/C10/2019196/OR_ABI-L1b-RadC-
M6C10_G16_s20191961811348_e20191961814132_
>
>
> c20191961814170.nc
>
>
> \*
> *G212 goes16_g212.nc <http://goes16_g212.nc><http://goes16_g212.nc><
> http://goes16_g212.nc><http://goes16_g212.nc>
> -field 'name="Rad";
> level="(*,*)";' -method MAX -v 4*
>
> And then I plotted the result:
>
> *met-8.1/bin/plot_data_plane goes16_g212.nc <http://goes16_g212.nc><
> http://goes16_g212.nc><
> http://goes16_g212.nc><http://goes16_g212.nc>
> goes16_g212.ps <http://goes16_g212.ps><http://goes16_g212.ps><
> http://goes16_g212.ps><http://goes16_g212.ps>
> 'name="Rad"; level="(*,*)";'*
>
> And that plot is attached.
>
> John
>
> On Mon, Jul 15, 2019 at 12:37 PM Sarah Griffin via RT <
>
>
> met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
> ><mailto:met_help at ucar.edu>
>
>
> wrote:
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> Ok, I've added the original GOES-16 data to the ftp site. I've also
>
>
> added '
>
>
> geocatL1.GOES-16.2018007.000200.nc' since the original GOES-16 data
>
>
> needs
>
>
> to be rewritten to actually get the brightness temperatures.
>
> I then did:
> bin/regrid_data_plane \
> geocatL1.GOES-16.2018007.000200.nc \
> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
> -field 'name = "channel_13_brightness_temperature"; level =
>
>
> "(*,*)";
>
>
> file_type = NETCDF_MET;' \
> -v 4
>
> and got the same error "MetNcFile::data(NcVar *, const LongArray &,
> DataPlane &) const -> star found in bad slot"
>
>
>
> I also added some radar data, Radar_Reflectivity_2018_0107_00_00.nc
>
>
> and
>
>
> Radar_Reflectivity_2018_0107_00_00.nc_new. I was able to do:
>
> bin/regrid_data_plane \
> Radar_Reflectivity_2018_0107_00_00.nc \
> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
> Radar_Reflectivity_2018_0107_00_00.nc_new \
> -field 'name = "composite_n0q"; level = "(*,*)"; file_type =
>
>
> NETCDF_MET;'
>
>
> \
> -v 4
>
> And get the remapping to work. I didn't try this is MODE, though,
>
>
> because
>
>
> the composite_n0q data is empty. But I'm curious if any of the
>
>
> global
>
>
> attribute data in Radar_Reflectivity_2018_0107_00_00.nc_new is
>
>
> helpful
>
>
> in
>
>
> figuring out what I need to run MODE?
>
> Thanks!
> Sarah
>
> On 7/15/19 1:07 PM, John Halley Gotway via RT wrote:
>
> Sarah,
>
> What I'm recommending is that we go back to the original GOES-16
>
>
> data,
>
>
> and
>
>
> run it through regrid_data_plane to do that remapping step. If we
>
>
> can
>
>
> get
>
>
> that to work, it'll result in an output file that can easily be read
>
>
> by
>
>
> MODE.
>
> Otherwise, we're stuck with trying to get the CF-convention
>
>
> specification
>
>
> of the WRF domain exactly right, which can be pretty tedious.
>
> John
>
> On Mon, Jul 15, 2019 at 11:17 AM Sarah Griffin via RT <
>
>
> met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
> ><mailto:met_help at ucar.edu>
>
>
> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:
> met_help at ucar.edu><mailto:met_help at ucar.edu>
>
>
> wrote:
>
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> The GOES-16 data I'm trying to use was created after remapping the
> native GOES data to the WRF projection from
>
>
>
>
>
>
>
>
>
>
> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
>
>
> .
>
> So does it matter what the GOES projection is if I'm trying to remap
>
>
> it
>
>
> to a different projection?
>
> I've messed around some more and have gotten to this error on
> regrid_data_plane. MetNcFile::data(NcVar *, const LongArray &,
>
>
> DataPlane
>
>
> &) const -> star found in bad slot
>
> when using this command:
> bin/regrid_data_plane \
> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc \
> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
> -field 'name = "channel_13_brightness_temperature"; level =
>
>
> "(*,*)";
>
>
> file_type = NETCDF_MET;' \
> -v 4
>
> Thanks!
> Sarah
>
> On 7/15/19 11:58 AM, John Halley Gotway via RT wrote:
>
>
> Sarah,
>
> Can you please send me a link to the GOES-16 data you're trying to
>
>
> use?
>
>
>
> I
>
>
> see you have a NetCDF file by this name:
> emap_geocatL1.GOES-16.CONUS.2018007.000230.nc
> Where did you get this file? Is is a publicly available ftp site?
>
> In general, MET reads gridded data that lives on regular
>
>
> projections.
>
>
>
>
> GOES
>
>
> data is a special case... it is not defined on a projection.
>
>
> Instead,
>
>
>
>
> it's
>
>
> a whole bunch of high resolution pixels of data. Each pixel has a
>
>
> lat/lon
>
>
> associated with it. We enhanced regrid_data_plane to read those
>
>
> lat/lon's
>
>
> and interpolate them to a user-requested domain.
>
> I'm hoping to get a sample GOES-16 file and send you example
>
>
> commands
>
>
> for
>
>
> interpolating it to your model domain using regrid_data_plane.
>
> Thanks,
> John
>
> On Mon, Jul 15, 2019 at 9:28 AM Sarah Griffin via RT <
>
>
> met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
> ><mailto:met_help at ucar.edu>
>
>
> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:
> met_help at ucar.edu><mailto:met_help at ucar.edu>
>
>
> wrote:
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> Update, please ignore the other email I sent. Looks like I was
>
>
> missing
>
>
> '-field' instead of field.
>
> However, now I'm getting the error "ERROR :
> NcCfFile::read_netcdf_grid() -> Couldn't figure out projection from
> information in netCDF file." It seems like I'm a bit stuck because I
> don't know the projection. If I did, I wouldn't need to use
> regrid_data_plane. Any thoughts?
>
> Thanks!
> Sarah
>
> On 7/12/19 5:53 PM, John Halley Gotway via RT wrote:
>
>
> Sarah,
>
> I'm pretty sure that didn't fix it entirely. When I plot the
>
>
> channel
>
>
>
>
> 15
>
>
> data with plot_data_plane, I clearly see the outline of FL and the
>
>
> Eastern
>
>
> seaboard in the data, but it doesn't line up with the map data. So
>
>
> there's
>
>
> clearly still a problem.
>
> I see that you're using GOES-16 data here. MET's regrid_data_plane
>
>
> tool
>
>
> should be able to read GOES-16 data and regrid it to a user-defined
>
>
> grid.
>
>
> That would be another alternatively for using GOES-16 data in MET.
>
> Thanks,
> John
>
> On Fri, Jul 12, 2019 at 4:45 PM John Halley Gotway <johnhg at ucar.edu
> <mailto:johnhg at ucar.edu>
> <mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu>
>
>
>
<mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu
> ><mailto:johnhg at ucar.edu>
>
>
> wrote:
>
>
> Hi Sarah,
>
> Thought I'd chime in here to mention the following. This is not
>
>
> actually
>
>
> a problem in MODE tool itself, but more of an issue in how MET is
>
>
> reading
>
>
> data your input files and placing them on the earth. I usually
>
>
> recommend
>
>
> that people run MET's plot_data_plane tool when working with a new
>
>
> data
>
>
> source to make sure MET is reading the data well:
>
> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc> plot.ps
> <http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><
> http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps>
> 'name="channel_10_brightness_temperature";
>
>
> level="(*,*)";'
>
>
> -v 4*
>
> This produces a nice looking plot, but there's no country outlines
>
>
> on
>
>
>
>
> top
>
>
> of the data! And that usually indicates a problem in the projection
> information. But I did find one thing which seems to have helped.
>
>
> I
>
>
> changed the longitude_of_central_meridian from 262.5 to -97.5, by
>
>
> running
>
>
> the following command:
>
> *ncatted -a longitude_of_central_meridian,Projection,o,f,-97.5
> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc>
> remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>*
>
> Those two longitudes are the same since they differ by 360 degrees.
> Surprisingly, running plot_data_plane on that modified file did plot
>
>
> the
>
>
> map data (see attached image):
>
> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc> plot.ps
> <http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><
> http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps>
> 'name="channel_10_brightness_temperature";
>
>
> level="(*,*)";'
>
>
> -v 4*
>
> Can you confirm that the data lives on the right place on the earth?
> Should it be covering the Eastern CONUS and Atlantic? If so, then
>
>
> we'll
>
>
> likely need to make a one line fix in MET's library code to rescale
>
>
> the
>
>
> longitude values to the expected range of (-180, 180] when we read
>
>
> them
>
>
> in.
>
>
> Thanks,
> John
>
> On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT <
>
>
> met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
> ><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
>
>
> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>>
>
>
>
>
> wrote:
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> On Fri Jul 12 14:56:24 2019, sarah.griffin at ssec.wisc.edu<mailto:
> sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
wrote:
>
>
> Hi,
>
> I'm using Met 8.0 with the bug fixes to run MODE for two netCDF
>
>
> files.
>
>
> MODE seems to run just fine, however the latitude and longitude of
>
>
> the
>
>
> output is messed up. How can I fix the latitude and longitude? I've
> uploaded the data and MODE output to the met_help ftp directory.
>
>
> Thanks!
>
>
> Have a great day!
> Sarah
>
>
>
> Hi Sarah -
> Thanks for the data upload.
> I've passed this ticket along to Randy, our resident MODE
>
>
> specialist.
>
>
> He should get a change to look at this early next week.
> David
>
>
>
>
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
>
>
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
>
> --
>
>
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
>
>
> --
>
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
> --
>
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
>
>
>
> --
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
>
> --
>
>
>
>
----------------------------------------------------------------------------
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
>
>
> --
>
>
>
----------------------------------------------------------------------------
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
>
> --
>
>
----------------------------------------------------------------------------
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
----------------------------------------------------------------------------
>
>
>
------------------------------------------------
Subject: Incorrect lat and lon data on objects
From: Sarah Griffin
Time: Tue Jul 16 13:31:37 2019
Hi John,
It looks like the only other issue I'm dealing with (it's not a deal-
breaker but is just bugging me) is the valid time on my MODE output
files. I'm getting times like
_000000L_19700101_000000V_NAA.ps
instead of
_000000L_20180101_000000V_NAA.ps
It's almost like MODE isn't reading the seconds in my file since
19700101. I can easily fix it with some cp commands, but if you
happened to know what's going on I'd be interested in knowing.
Thanks!
Sarah
On 7/16/19 2:07 PM, John Halley Gotway via RT wrote:
Sarah,
Ah great! Looks like you're all set. Sorry that was such a hassle!
Do
you have any remaining issues or questions I can help answer?
Thanks,
John
On Tue, Jul 16, 2019 at 12:24 PM Sarah Griffin via RT
<met_help at ucar.edu><mailto:met_help at ucar.edu>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
Hi John,
Instead of uploading the latest version to the ftp site, I'll just
include
this screen shot because lat/lon instead of y/x was the solution![MODE
output]
Have a great day!
Sarah
On 7/16/19 1:01 PM, John Halley Gotway via RT wrote:
Sarah,
That would work if the NetCDF file really were the output from one of
the
MET tools. Since it's not, the library code isn't reading the data
properly. Specifically, I'm guessing it's expecting the dimensions to
be
named lat/lon rather than y/x. I know that seems silly, but so it
goes.
You could upload you latest version to the ftp site if you'd like, and
I
could take a look.
Just let me know.
Thanks,
John
On Tue, Jul 16, 2019 at 11:55 AM Sarah Griffin via RT
<met_help at ucar.edu<mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
Hi John,
I have. My data is :
float channel_14_brightness_temperature(y, x) ;
channel_14_brightness_temperature:name =
"channel_14_brightness_temperature" ;
channel_14_brightness_temperature:long_name =
"channel_14_brightness_temperature(*,*)" ;
channel_14_brightness_temperature:level = "(*,*)" ;
channel_14_brightness_temperature:reference = "all data are
referenced to the ABI channels" ;
channel_14_brightness_temperature:units = "K" ;
channel_14_brightness_temperature:_FillValue = -999.f ;
and I have
field = {
name = "channel_14_brightness_temperature";
level = "(*,*)";
file_type = NETCDF_MET;
};
in my mode config file and I'm still getting the MetNcFile::data(NcVar
*,
const LongArray &, DataPlane &) const -> star found in bad slot
error.
Sorry this is being so difficult,
Sarah
On 7/16/19 12:42 PM, John Halley Gotway via RT wrote:
Sarah,
In the MODE config file, you request what data should be read from the
input gridded data file. The way you do this varies slightly
depending on
the type of file you're reading (GRIB1/2 versus NetCDF). For NetCDF
files
you'd specify:
* field = { name = "NETCDF_VARIABLE_NAME"; level =
"NETCDF_DIMENSION_INFO"; }*
Where NETCDF_DIMENSION_INFO defines how to extract a 2D filed of data
from
the specified NETCDF_VARIABLE_NAME. You put a * for the gridded
dimensions
(i.e. lat and lon). When reading the NetCDF output of
regrid_data_plane,
it's easy. Just set it to "(*,*)".
If you're NetCDF variable had 4 dimensions like this:
float data(time, level, lat, lon);
You could use:
level = "(0, 5, *, *)";
To read data for the first time (0-based) and 6th vertical level.
Thanks,
John
On Tue, Jul 16, 2019 at 11:34 AM Sarah Griffin via RT
<met_help at ucar.edu<mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
Thanks John. I hope I'm finally on the right track, but when I'm
running
MODE I'm still getting the error:
MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
found in bad slot
What does that error mean?
Have a great day!
Sarah
On 7/15/19 5:22 PM, John Halley Gotway via RT wrote:
Sarah,
OK, I just ran the following command:
*regrid_data_plane \*
*OR_ABI-L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_
c20191961814170.nc
\*
*
mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
<
http://mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
\*
*goes16_MODE_GRID.nc \*
*-field 'name="Rad"; level="(*,*)";'*
And that produced an output file with bad data values everywhere. The
problem is that the projection information in that MODE output file is
messed up in some way (
mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
)...
which was the original reason you wrote.
So I tried a different route. The "to_grid" option for
regrid_data_plane
can be defined as a named grid (i.e. G212), the path to a gridded data
file, or an explicit grid definition. I tried the latter. Below is
an
excerpt from met-8.1/share/met/config/README:
// - to_grid = "spec"; To define a grid specified as follows:
// - lambert Nx Ny lat_ll lon_ll lon_orient D_km R_km
standard_parallel_1
// [standard_parallel_2] N|S
I used the metadata from the NetCDF files you sent to define the
following
grid definition info:
'lambert 1535 1023 22.45395 -119.2807 262.5 3 6371.2 38.5 N'
And I ran this command:
*regrid_data_plane \*
*OR_ABI-L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_
c20191961814170.nc
\*
*'lambert 1535 1023 22.45395 -119.2807 262.5 3 6371.2 38.5 N' \*
*goes16_USER_DEFINED.nc -field 'name="Rad"; level="(*,*)";'*
And plotted the output. The result (see attached) looks much more
promising. I assume that pattern of missing data values is due to
insufficient GOES 16 data at those locations.
Thanks,
John
On Mon, Jul 15, 2019 at 1:51 PM Sarah Griffin via RT
<met_help at ucar.edu<mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
When you say "gridded data file" does that not include a netCDF file?
I'm trying to use a netCDF file as a grid, which I thought MET knows
how
to read. However, I ran my file using regrid_data_plane and then mode
and I get this file
(
mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_19700101_000000V_NAA.ps
)
that I uploaded and the grid is still offset from when I want. Can you
please test and see what happens when you use my file
Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc as the grid
instead of G212?
Also, what does
MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
found in bad slot
mean?
Thanks!
Sarah
On 7/15/19 2:40 PM, John Halley Gotway via RT wrote:
I just posted it. But realize that the whole point is that you can
generate it yourself by running the regrid_data_plane command. And
instead
of using "G212" on the command, just list a gridded data file that MET
knows how to read that's already on your desired model domain. The
tool
will read the grid info from that gridded data file and regrid the
input
GOES-16 values to that domain.
Thanks,
John
On Mon, Jul 15, 2019 at 1:36 PM Sarah Griffin via RT <
met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
Hi John,
Reading this a bit more, can you try to run a regrid to the grid that
I
want, which can be found in:
Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc?
Unfortunately, remapping it to NCEP Grid 212 is not useful.
Have a great day!
Sarah
On 7/15/19 2:12 PM, John Halley Gotway via RT wrote:
Sarah,
I grabbed that file from the ftp site and see this header:
*netcdf geocatL1.GOES-16.2018007.000200 {dimensions: x = 2312
;
y = 1191 ;variables: float pixel_latitude(y, x) ;
float
pixel_longitude(y, x) ; float
channel_13_brightness_temperature(y,
x) ;}*
The original GOES-16 file has much more metadata in it that
regrid_data_plane expects and uses. I found some GOES-16 data on our
filesystem and am sending you an example of how it can be used by
regrid_data_plane. Here's the sample data file:
*
ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-L1b-
RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
<
ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-L1b-
RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
*
And here's the command I ran to interpolate it to NCEP Grid 212 which
covers CONUS:
*met-8.1/bin/regrid_data_plane \*
*goes-16/ABI/L1/CONUS/C10/2019196/OR_ABI-L1b-RadC-
M6C10_G16_s20191961811348_e20191961814132_
c20191961814170.nc
\*
*G212 goes16_g212.nc
<http://goes16_g212.nc><http://goes16_g212.nc><http://goes16_g212.nc><http://goes16_g212.nc><
http://goes16_g212.nc><http://goes16_g212.nc><http://goes16_g212.nc><http://goes16_g212.nc>
-field 'name="Rad";
level="(*,*)";' -method MAX -v 4*
And then I plotted the result:
*met-8.1/bin/plot_data_plane goes16_g212.nc
<http://goes16_g212.nc><http://goes16_g212.nc><
http://goes16_g212.nc><http://goes16_g212.nc><
http://goes16_g212.nc><http://goes16_g212.nc><http://goes16_g212.nc><http://goes16_g212.nc>
goes16_g212.ps
<http://goes16_g212.ps><http://goes16_g212.ps><http://goes16_g212.ps><http://goes16_g212.ps><
http://goes16_g212.ps><http://goes16_g212.ps><http://goes16_g212.ps><http://goes16_g212.ps>
'name="Rad"; level="(*,*)";'*
And that plot is attached.
John
On Mon, Jul 15, 2019 at 12:37 PM Sarah Griffin via RT <
met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
Hi John,
Ok, I've added the original GOES-16 data to the ftp site. I've also
added '
geocatL1.GOES-16.2018007.000200.nc' since the original GOES-16 data
needs
to be rewritten to actually get the brightness temperatures.
I then did:
bin/regrid_data_plane \
geocatL1.GOES-16.2018007.000200.nc \
Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
-field 'name = "channel_13_brightness_temperature"; level =
"(*,*)";
file_type = NETCDF_MET;' \
-v 4
and got the same error "MetNcFile::data(NcVar *, const LongArray &,
DataPlane &) const -> star found in bad slot"
I also added some radar data, Radar_Reflectivity_2018_0107_00_00.nc
and
Radar_Reflectivity_2018_0107_00_00.nc_new. I was able to do:
bin/regrid_data_plane \
Radar_Reflectivity_2018_0107_00_00.nc \
Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
Radar_Reflectivity_2018_0107_00_00.nc_new \
-field 'name = "composite_n0q"; level = "(*,*)"; file_type =
NETCDF_MET;'
\
-v 4
And get the remapping to work. I didn't try this is MODE, though,
because
the composite_n0q data is empty. But I'm curious if any of the
global
attribute data in Radar_Reflectivity_2018_0107_00_00.nc_new is
helpful
in
figuring out what I need to run MODE?
Thanks!
Sarah
On 7/15/19 1:07 PM, John Halley Gotway via RT wrote:
Sarah,
What I'm recommending is that we go back to the original GOES-16
data,
and
run it through regrid_data_plane to do that remapping step. If we
can
get
that to work, it'll result in an output file that can easily be read
by
MODE.
Otherwise, we're stuck with trying to get the CF-convention
specification
of the WRF domain exactly right, which can be pretty tedious.
John
On Mon, Jul 15, 2019 at 11:17 AM Sarah Griffin via RT <
met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:
met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
Hi John,
The GOES-16 data I'm trying to use was created after remapping the
native GOES data to the WRF projection from
mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
.
So does it matter what the GOES projection is if I'm trying to remap
it
to a different projection?
I've messed around some more and have gotten to this error on
regrid_data_plane. MetNcFile::data(NcVar *, const LongArray &,
DataPlane
&) const -> star found in bad slot
when using this command:
bin/regrid_data_plane \
remap_geocatL1.GOES-16.CONUS.2018007.060230.nc \
Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
-field 'name = "channel_13_brightness_temperature"; level =
"(*,*)";
file_type = NETCDF_MET;' \
-v 4
Thanks!
Sarah
On 7/15/19 11:58 AM, John Halley Gotway via RT wrote:
Sarah,
Can you please send me a link to the GOES-16 data you're trying to
use?
I
see you have a NetCDF file by this name:
emap_geocatL1.GOES-16.CONUS.2018007.000230.nc
Where did you get this file? Is is a publicly available ftp site?
In general, MET reads gridded data that lives on regular
projections.
GOES
data is a special case... it is not defined on a projection.
Instead,
it's
a whole bunch of high resolution pixels of data. Each pixel has a
lat/lon
associated with it. We enhanced regrid_data_plane to read those
lat/lon's
and interpolate them to a user-requested domain.
I'm hoping to get a sample GOES-16 file and send you example
commands
for
interpolating it to your model domain using regrid_data_plane.
Thanks,
John
On Mon, Jul 15, 2019 at 9:28 AM Sarah Griffin via RT <
met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:
met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
Hi John,
Update, please ignore the other email I sent. Looks like I was
missing
'-field' instead of field.
However, now I'm getting the error "ERROR :
NcCfFile::read_netcdf_grid() -> Couldn't figure out projection from
information in netCDF file." It seems like I'm a bit stuck because I
don't know the projection. If I did, I wouldn't need to use
regrid_data_plane. Any thoughts?
Thanks!
Sarah
On 7/12/19 5:53 PM, John Halley Gotway via RT wrote:
Sarah,
I'm pretty sure that didn't fix it entirely. When I plot the
channel
15
data with plot_data_plane, I clearly see the outline of FL and the
Eastern
seaboard in the data, but it doesn't line up with the map data. So
there's
clearly still a problem.
I see that you're using GOES-16 data here. MET's regrid_data_plane
tool
should be able to read GOES-16 data and regrid it to a user-defined
grid.
That would be another alternatively for using GOES-16 data in MET.
Thanks,
John
On Fri, Jul 12, 2019 at 4:45 PM John Halley Gotway
<johnhg at ucar.edu<mailto:johnhg at ucar.edu>
<mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu>
<mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu>
<mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu
<mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu>
wrote:
Hi Sarah,
Thought I'd chime in here to mention the following. This is not
actually
a problem in MODE tool itself, but more of an issue in how MET is
reading
data your input files and placing them on the earth. I usually
recommend
that people run MET's plot_data_plane tool when working with a new
data
source to make sure MET is reading the data well:
*plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
<http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc> plot.ps
<http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><
http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps>
'name="channel_10_brightness_temperature";
level="(*,*)";'
-v 4*
This produces a nice looking plot, but there's no country outlines
on
top
of the data! And that usually indicates a problem in the projection
information. But I did find one thing which seems to have helped.
I
changed the longitude_of_central_meridian from 262.5 to -97.5, by
running
the following command:
*ncatted -a longitude_of_central_meridian,Projection,o,f,-97.5
remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
<http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230.nc>
remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
<http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc>*
Those two longitudes are the same since they differ by 360 degrees.
Surprisingly, running plot_data_plane on that modified file did plot
the
map data (see attached image):
*plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
<http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><
http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc><http://remap_geocatL1.GOES-
16.CONUS.2018007.060230_mod.nc> plot.ps
<http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><
http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps>
'name="channel_10_brightness_temperature";
level="(*,*)";'
-v 4*
Can you confirm that the data lives on the right place on the earth?
Should it be covering the Eastern CONUS and Atlantic? If so, then
we'll
likely need to make a one line fix in MET's library code to rescale
the
longitude values to the expected range of (-180, 180] when we read
them
in.
Thanks,
John
On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT <
met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
On Fri Jul 12 14:56:24 2019,
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
wrote:
Hi,
I'm using Met 8.0 with the bug fixes to run MODE for two netCDF
files.
MODE seems to run just fine, however the latitude and longitude of
the
output is messed up. How can I fix the latitude and longitude? I've
uploaded the data and MODE output to the met_help ftp directory.
Thanks!
Have a great day!
Sarah
Hi Sarah -
Thanks for the data upload.
I've passed this ticket along to Randy, our resident MODE
specialist.
He should get a change to look at this early next week.
David
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC
UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC UW-
Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
(608) 262-0986
----------------------------------------------------------------------------
------------------------------------------------
Subject: Incorrect lat and lon data on objects
From: John Halley Gotway
Time: Tue Jul 16 16:16:10 2019
Sarah,
You are telling MET to interpret the input data like its the output
from
another MET tool:
file_type = NETCDF_MET;
So you just need to follow the example of how the other MET tools
store
timing information. For example, looking at the NetCDF output that
was
generated by your previous mode runs, you'll see timing information
listed
as variable attributes:
float fcst_raw(lat, lon) ;
fcst_raw:long_name = "Forecast Raw Values" ;
fcst_raw:_FillValue = -9999.f ;
fcst_raw:init_time = "20180107_060032" ;
fcst_raw:init_time_ut = "1515304832" ;
fcst_raw:valid_time = "20180107_060032" ;
fcst_raw:valid_time_ut = "1515304832" ;
Technically, I believe that the code reads the "init_time_ut" and
"valid_time_ut"
attributes, where "ut" means unixtime. The forecast lead time is the
difference between them. Note that while they look like integers,
they are
actually strings. That's to avoid the problem of integer overflow for
very
large values.
Adding those variable attributes will enable MET to read the timing
info
from these files.
Thanks,
John
On Tue, Jul 16, 2019 at 1:31 PM Sarah Griffin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> It looks like the only other issue I'm dealing with (it's not a
> deal-breaker but is just bugging me) is the valid time on my MODE
output
> files. I'm getting times like
> _000000L_19700101_000000V_NAA.ps
> instead of
> _000000L_20180101_000000V_NAA.ps
> It's almost like MODE isn't reading the seconds in my file since
19700101.
> I can easily fix it with some cp commands, but if you happened to
know
> what's going on I'd be interested in knowing.
>
> Thanks!
> Sarah
>
> On 7/16/19 2:07 PM, John Halley Gotway via RT wrote:
>
> Sarah,
>
> Ah great! Looks like you're all set. Sorry that was such a hassle!
Do
> you have any remaining issues or questions I can help answer?
>
> Thanks,
> John
>
> On Tue, Jul 16, 2019 at 12:24 PM Sarah Griffin via RT
<met_help at ucar.edu
> ><mailto:met_help at ucar.edu>
> wrote:
>
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> Instead of uploading the latest version to the ftp site, I'll just
include
> this screen shot because lat/lon instead of y/x was the
solution![MODE
> output]
>
> Have a great day!
> Sarah
>
> On 7/16/19 1:01 PM, John Halley Gotway via RT wrote:
>
> Sarah,
>
> That would work if the NetCDF file really were the output from one
of the
> MET tools. Since it's not, the library code isn't reading the data
> properly. Specifically, I'm guessing it's expecting the dimensions
to be
> named lat/lon rather than y/x. I know that seems silly, but so it
goes.
>
> You could upload you latest version to the ftp site if you'd like,
and I
> could take a look.
>
> Just let me know.
>
> Thanks,
> John
>
> On Tue, Jul 16, 2019 at 11:55 AM Sarah Griffin via RT
<met_help at ucar.edu
> <mailto:met_help at ucar.edu>
>
>
> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
>
>
> wrote:
>
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> I have. My data is :
>
> float channel_14_brightness_temperature(y, x) ;
> channel_14_brightness_temperature:name =
> "channel_14_brightness_temperature" ;
> channel_14_brightness_temperature:long_name =
> "channel_14_brightness_temperature(*,*)" ;
> channel_14_brightness_temperature:level = "(*,*)" ;
> channel_14_brightness_temperature:reference = "all data are
> referenced to the ABI channels" ;
> channel_14_brightness_temperature:units = "K" ;
> channel_14_brightness_temperature:_FillValue = -999.f ;
>
>
> and I have
>
> field = {
> name = "channel_14_brightness_temperature";
> level = "(*,*)";
> file_type = NETCDF_MET;
> };
>
> in my mode config file and I'm still getting the
MetNcFile::data(NcVar *,
> const LongArray &, DataPlane &) const -> star found in bad slot
error.
>
> Sorry this is being so difficult,
> Sarah
>
> On 7/16/19 12:42 PM, John Halley Gotway via RT wrote:
>
> Sarah,
>
> In the MODE config file, you request what data should be read from
the
> input gridded data file. The way you do this varies slightly
depending on
> the type of file you're reading (GRIB1/2 versus NetCDF). For NetCDF
files
> you'd specify:
>
>
>
> * field = { name = "NETCDF_VARIABLE_NAME"; level =
> "NETCDF_DIMENSION_INFO"; }*
>
> Where NETCDF_DIMENSION_INFO defines how to extract a 2D filed of
data from
> the specified NETCDF_VARIABLE_NAME. You put a * for the gridded
dimensions
> (i.e. lat and lon). When reading the NetCDF output of
regrid_data_plane,
> it's easy. Just set it to "(*,*)".
>
> If you're NetCDF variable had 4 dimensions like this:
> float data(time, level, lat, lon);
>
> You could use:
> level = "(0, 5, *, *)";
>
> To read data for the first time (0-based) and 6th vertical level.
>
> Thanks,
> John
>
>
>
>
>
>
> On Tue, Jul 16, 2019 at 11:34 AM Sarah Griffin via RT
<met_help at ucar.edu
> <mailto:met_help at ucar.edu>
> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
>
>
> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:
> met_help at ucar.edu><mailto:met_help at ucar.edu>
>
>
> wrote:
>
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Thanks John. I hope I'm finally on the right track, but when I'm
running
> MODE I'm still getting the error:
>
> MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
> found in bad slot
>
> What does that error mean?
>
> Have a great day!
> Sarah
>
> On 7/15/19 5:22 PM, John Halley Gotway via RT wrote:
>
>
> Sarah,
>
> OK, I just ran the following command:
>
> *regrid_data_plane \*
> *OR_ABI-L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_
>
>
> c20191961814170.nc
>
>
> \*
> *
>
>
>
>
>
> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
>
>
> <
>
>
>
>
>
> http://mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
>
>
>
> \*
> *goes16_MODE_GRID.nc \*
> *-field 'name="Rad"; level="(*,*)";'*
>
> And that produced an output file with bad data values everywhere.
The
> problem is that the projection information in that MODE output file
is
> messed up in some way (
>
>
>
>
>
>
> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
> )...
>
>
> which was the original reason you wrote.
>
> So I tried a different route. The "to_grid" option for
regrid_data_plane
> can be defined as a named grid (i.e. G212), the path to a gridded
data
> file, or an explicit grid definition. I tried the latter. Below is
an
> excerpt from met-8.1/share/met/config/README:
>
> // - to_grid = "spec"; To define a grid specified as follows:
> // - lambert Nx Ny lat_ll lon_ll lon_orient D_km R_km
> standard_parallel_1
> // [standard_parallel_2] N|S
>
> I used the metadata from the NetCDF files you sent to define the
>
>
> following
>
>
> grid definition info:
> 'lambert 1535 1023 22.45395 -119.2807 262.5 3 6371.2 38.5 N'
>
> And I ran this command:
>
> *regrid_data_plane \*
> *OR_ABI-L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_
>
>
> c20191961814170.nc
>
>
> \*
> *'lambert 1535 1023 22.45395 -119.2807 262.5 3 6371.2 38.5 N' \*
> *goes16_USER_DEFINED.nc -field 'name="Rad"; level="(*,*)";'*
>
> And plotted the output. The result (see attached) looks much more
> promising. I assume that pattern of missing data values is due to
> insufficient GOES 16 data at those locations.
>
> Thanks,
> John
>
> On Mon, Jul 15, 2019 at 1:51 PM Sarah Griffin via RT
<met_help at ucar.edu
> <mailto:met_help at ucar.edu>
> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
>
>
> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:
> met_help at ucar.edu><mailto:met_help at ucar.edu>
>
>
> wrote:
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> When you say "gridded data file" does that not include a netCDF
file?
> I'm trying to use a netCDF file as a grid, which I thought MET knows
how
> to read. However, I ran my file using regrid_data_plane and then
mode
> and I get this file
> (
>
>
>
>
>
>
> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_19700101_000000V_NAA.ps
> )
>
>
>
> that I uploaded and the grid is still offset from when I want. Can
you
> please test and see what happens when you use my file
> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc as the
grid
> instead of G212?
>
> Also, what does
> MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
> found in bad slot
> mean?
>
> Thanks!
> Sarah
>
> On 7/15/19 2:40 PM, John Halley Gotway via RT wrote:
>
>
> I just posted it. But realize that the whole point is that you can
> generate it yourself by running the regrid_data_plane command. And
>
>
> instead
>
>
> of using "G212" on the command, just list a gridded data file that
MET
> knows how to read that's already on your desired model domain. The
>
>
> tool
>
>
> will read the grid info from that gridded data file and regrid the
>
>
> input
>
>
> GOES-16 values to that domain.
>
> Thanks,
> John
>
> On Mon, Jul 15, 2019 at 1:36 PM Sarah Griffin via RT <
>
>
> met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
> ><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
>
>
> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>>
>
>
>
>
> wrote:
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> Reading this a bit more, can you try to run a regrid to the grid
that
>
>
> I
>
>
> want, which can be found in:
> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc?
> Unfortunately, remapping it to NCEP Grid 212 is not useful.
>
> Have a great day!
> Sarah
>
> On 7/15/19 2:12 PM, John Halley Gotway via RT wrote:
>
>
> Sarah,
>
> I grabbed that file from the ftp site and see this header:
>
>
>
>
>
>
>
>
>
> *netcdf geocatL1.GOES-16.2018007.000200 {dimensions: x = 2312
>
>
> ;
>
>
> y = 1191 ;variables: float pixel_latitude(y, x) ;
>
>
> float
>
>
> pixel_longitude(y, x) ; float
>
>
> channel_13_brightness_temperature(y,
>
>
> x) ;}*
>
> The original GOES-16 file has much more metadata in it that
> regrid_data_plane expects and uses. I found some GOES-16 data on
our
> filesystem and am sending you an example of how it can be used by
> regrid_data_plane. Here's the sample data file:
>
> *
>
>
>
>
>
>
>
>
> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
>
>
> <
>
>
>
>
>
>
>
>
> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
>
>
> *
>
> And here's the command I ran to interpolate it to NCEP Grid 212
which
> covers CONUS:
>
> *met-8.1/bin/regrid_data_plane \*
>
>
>
>
>
>
>
>
>
> *goes-16/ABI/L1/CONUS/C10/2019196/OR_ABI-L1b-RadC-
M6C10_G16_s20191961811348_e20191961814132_
>
>
> c20191961814170.nc
>
>
> \*
> *G212 goes16_g212.nc <http://goes16_g212.nc><http://goes16_g212.nc><
> http://goes16_g212.nc><http://goes16_g212.nc><
>
http://goes16_g212.nc><http://goes16_g212.nc><http://goes16_g212.nc><
> http://goes16_g212.nc>
> -field 'name="Rad";
> level="(*,*)";' -method MAX -v 4*
>
> And then I plotted the result:
>
> *met-8.1/bin/plot_data_plane goes16_g212.nc <http://goes16_g212.nc><
> http://goes16_g212.nc><
> http://goes16_g212.nc><http://goes16_g212.nc><
>
http://goes16_g212.nc><http://goes16_g212.nc><http://goes16_g212.nc><
> http://goes16_g212.nc>
> goes16_g212.ps <http://goes16_g212.ps><http://goes16_g212.ps><
> http://goes16_g212.ps><http://goes16_g212.ps><
>
http://goes16_g212.ps><http://goes16_g212.ps><http://goes16_g212.ps><
> http://goes16_g212.ps>
> 'name="Rad"; level="(*,*)";'*
>
> And that plot is attached.
>
> John
>
> On Mon, Jul 15, 2019 at 12:37 PM Sarah Griffin via RT <
>
>
> met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
> ><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
>
>
> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
>
>
>
>
> wrote:
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> Ok, I've added the original GOES-16 data to the ftp site. I've also
>
>
> added '
>
>
> geocatL1.GOES-16.2018007.000200.nc' since the original GOES-16 data
>
>
> needs
>
>
> to be rewritten to actually get the brightness temperatures.
>
> I then did:
> bin/regrid_data_plane \
> geocatL1.GOES-16.2018007.000200.nc \
> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
> -field 'name = "channel_13_brightness_temperature"; level =
>
>
> "(*,*)";
>
>
> file_type = NETCDF_MET;' \
> -v 4
>
> and got the same error "MetNcFile::data(NcVar *, const LongArray &,
> DataPlane &) const -> star found in bad slot"
>
>
>
> I also added some radar data, Radar_Reflectivity_2018_0107_00_00.nc
>
>
> and
>
>
> Radar_Reflectivity_2018_0107_00_00.nc_new. I was able to do:
>
> bin/regrid_data_plane \
> Radar_Reflectivity_2018_0107_00_00.nc \
> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
> Radar_Reflectivity_2018_0107_00_00.nc_new \
> -field 'name = "composite_n0q"; level = "(*,*)"; file_type =
>
>
> NETCDF_MET;'
>
>
> \
> -v 4
>
> And get the remapping to work. I didn't try this is MODE, though,
>
>
> because
>
>
> the composite_n0q data is empty. But I'm curious if any of the
>
>
> global
>
>
> attribute data in Radar_Reflectivity_2018_0107_00_00.nc_new is
>
>
> helpful
>
>
> in
>
>
> figuring out what I need to run MODE?
>
> Thanks!
> Sarah
>
> On 7/15/19 1:07 PM, John Halley Gotway via RT wrote:
>
> Sarah,
>
> What I'm recommending is that we go back to the original GOES-16
>
>
> data,
>
>
> and
>
>
> run it through regrid_data_plane to do that remapping step. If we
>
>
> can
>
>
> get
>
>
> that to work, it'll result in an output file that can easily be read
>
>
> by
>
>
> MODE.
>
> Otherwise, we're stuck with trying to get the CF-convention
>
>
> specification
>
>
> of the WRF domain exactly right, which can be pretty tedious.
>
> John
>
> On Mon, Jul 15, 2019 at 11:17 AM Sarah Griffin via RT <
>
>
> met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
> ><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
>
>
> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
>
>
>
>
> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:
> met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:
>
met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
> ><mailto:met_help at ucar.edu>
>
>
> wrote:
>
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> The GOES-16 data I'm trying to use was created after remapping the
> native GOES data to the WRF projection from
>
>
>
>
>
>
>
>
>
>
>
> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
>
>
> .
>
> So does it matter what the GOES projection is if I'm trying to remap
>
>
> it
>
>
> to a different projection?
>
> I've messed around some more and have gotten to this error on
> regrid_data_plane. MetNcFile::data(NcVar *, const LongArray &,
>
>
> DataPlane
>
>
> &) const -> star found in bad slot
>
> when using this command:
> bin/regrid_data_plane \
> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc \
> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
> -field 'name = "channel_13_brightness_temperature"; level =
>
>
> "(*,*)";
>
>
> file_type = NETCDF_MET;' \
> -v 4
>
> Thanks!
> Sarah
>
> On 7/15/19 11:58 AM, John Halley Gotway via RT wrote:
>
>
> Sarah,
>
> Can you please send me a link to the GOES-16 data you're trying to
>
>
> use?
>
>
>
> I
>
>
> see you have a NetCDF file by this name:
> emap_geocatL1.GOES-16.CONUS.2018007.000230.nc
> Where did you get this file? Is is a publicly available ftp site?
>
> In general, MET reads gridded data that lives on regular
>
>
> projections.
>
>
>
>
> GOES
>
>
> data is a special case... it is not defined on a projection.
>
>
> Instead,
>
>
>
>
> it's
>
>
> a whole bunch of high resolution pixels of data. Each pixel has a
>
>
> lat/lon
>
>
> associated with it. We enhanced regrid_data_plane to read those
>
>
> lat/lon's
>
>
> and interpolate them to a user-requested domain.
>
> I'm hoping to get a sample GOES-16 file and send you example
>
>
> commands
>
>
> for
>
>
> interpolating it to your model domain using regrid_data_plane.
>
> Thanks,
> John
>
> On Mon, Jul 15, 2019 at 9:28 AM Sarah Griffin via RT <
>
>
> met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
> ><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
>
>
> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
>
>
>
>
> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:
> met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:
>
met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
> ><mailto:met_help at ucar.edu>
>
>
> wrote:
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> Hi John,
>
> Update, please ignore the other email I sent. Looks like I was
>
>
> missing
>
>
> '-field' instead of field.
>
> However, now I'm getting the error "ERROR :
> NcCfFile::read_netcdf_grid() -> Couldn't figure out projection from
> information in netCDF file." It seems like I'm a bit stuck because I
> don't know the projection. If I did, I wouldn't need to use
> regrid_data_plane. Any thoughts?
>
> Thanks!
> Sarah
>
> On 7/12/19 5:53 PM, John Halley Gotway via RT wrote:
>
>
> Sarah,
>
> I'm pretty sure that didn't fix it entirely. When I plot the
>
>
> channel
>
>
>
>
> 15
>
>
> data with plot_data_plane, I clearly see the outline of FL and the
>
>
> Eastern
>
>
> seaboard in the data, but it doesn't line up with the map data. So
>
>
> there's
>
>
> clearly still a problem.
>
> I see that you're using GOES-16 data here. MET's regrid_data_plane
>
>
> tool
>
>
> should be able to read GOES-16 data and regrid it to a user-defined
>
>
> grid.
>
>
> That would be another alternatively for using GOES-16 data in MET.
>
> Thanks,
> John
>
> On Fri, Jul 12, 2019 at 4:45 PM John Halley Gotway <johnhg at ucar.edu
> <mailto:johnhg at ucar.edu>
> <mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu>
>
<mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu
> ><mailto:johnhg at ucar.edu>
>
>
>
<mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu
> ><mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu
>
>
> <mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu>
>
>
>
>
> wrote:
>
>
> Hi Sarah,
>
> Thought I'd chime in here to mention the following. This is not
>
>
> actually
>
>
> a problem in MODE tool itself, but more of an issue in how MET is
>
>
> reading
>
>
> data your input files and placing them on the earth. I usually
>
>
> recommend
>
>
> that people run MET's plot_data_plane tool when working with a new
>
>
> data
>
>
> source to make sure MET is reading the data well:
>
> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc> plot.ps
> <http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><
> http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><
> http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><
> http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps>
> 'name="channel_10_brightness_temperature";
>
>
> level="(*,*)";'
>
>
> -v 4*
>
> This produces a nice looking plot, but there's no country outlines
>
>
> on
>
>
>
>
> top
>
>
> of the data! And that usually indicates a problem in the projection
> information. But I did find one thing which seems to have helped.
>
>
> I
>
>
> changed the longitude_of_central_meridian from 262.5 to -97.5, by
>
>
> running
>
>
> the following command:
>
> *ncatted -a longitude_of_central_meridian,Projection,o,f,-97.5
> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc>
> remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>*
>
> Those two longitudes are the same since they differ by 360 degrees.
> Surprisingly, running plot_data_plane on that modified file did plot
>
>
> the
>
>
> map data (see attached image):
>
> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc> plot.ps
> <http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><
> http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><
> http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><
> http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps>
> 'name="channel_10_brightness_temperature";
>
>
> level="(*,*)";'
>
>
> -v 4*
>
> Can you confirm that the data lives on the right place on the earth?
> Should it be covering the Eastern CONUS and Atlantic? If so, then
>
>
> we'll
>
>
> likely need to make a one line fix in MET's library code to rescale
>
>
> the
>
>
> longitude values to the expected range of (-180, 180] when we read
>
>
> them
>
>
> in.
>
>
> Thanks,
> John
>
> On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT <
>
>
> met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
> ><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
>
>
> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:
> met_help at ucar.edu
>
>
>
>
> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:
> met_help at ucar.edu><mailto:met_help at ucar.edu>>
>
>
>
>
> wrote:
>
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>
> On Fri Jul 12 14:56:24 2019, sarah.griffin at ssec.wisc.edu<mailto:
> sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
wrote:
>
>
> Hi,
>
> I'm using Met 8.0 with the bug fixes to run MODE for two netCDF
>
>
> files.
>
>
> MODE seems to run just fine, however the latitude and longitude of
>
>
> the
>
>
> output is messed up. How can I fix the latitude and longitude? I've
> uploaded the data and MODE output to the met_help ftp directory.
>
>
> Thanks!
>
>
> Have a great day!
> Sarah
>
>
>
> Hi Sarah -
> Thanks for the data upload.
> I've passed this ticket along to Randy, our resident MODE
>
>
> specialist.
>
>
> He should get a change to look at this early next week.
> David
>
>
>
>
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
>
> --
>
>
>
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
>
>
> --
>
>
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
> --
>
>
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
>
>
>
> --
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
>
>
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
>
> --
>
>
>
>
>
----------------------------------------------------------------------------
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
>
>
> --
>
>
>
>
----------------------------------------------------------------------------
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
>
> --
>
>
>
----------------------------------------------------------------------------
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
>
----------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
>
> --
>
>
----------------------------------------------------------------------------
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
> (608) 262-0986
>
>
----------------------------------------------------------------------------
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #91053] Incorrect lat and lon data on objects
From: Sarah Griffin
Time: Thu Jul 18 09:08:56 2019
Thanks John. I think that's all the questions I have. Thanks for all
of
your help!
On 7/16/19 5:16 PM, John Halley Gotway via RT wrote:
> Sarah,
>
> You are telling MET to interpret the input data like its the output
from
> another MET tool:
> file_type = NETCDF_MET;
>
> So you just need to follow the example of how the other MET tools
store
> timing information. For example, looking at the NetCDF output that
was
> generated by your previous mode runs, you'll see timing information
listed
> as variable attributes:
>
> float fcst_raw(lat, lon) ;
> fcst_raw:long_name = "Forecast Raw Values" ;
> fcst_raw:_FillValue = -9999.f ;
> fcst_raw:init_time = "20180107_060032" ;
> fcst_raw:init_time_ut = "1515304832" ;
> fcst_raw:valid_time = "20180107_060032" ;
> fcst_raw:valid_time_ut = "1515304832" ;
>
> Technically, I believe that the code reads the "init_time_ut" and
> "valid_time_ut"
> attributes, where "ut" means unixtime. The forecast lead time is
the
> difference between them. Note that while they look like integers,
they are
> actually strings. That's to avoid the problem of integer overflow
for very
> large values.
>
> Adding those variable attributes will enable MET to read the timing
info
> from these files.
>
> Thanks,
> John
>
> On Tue, Jul 16, 2019 at 1:31 PM Sarah Griffin via RT
<met_help at ucar.edu>
> wrote:
>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>
>> Hi John,
>>
>> It looks like the only other issue I'm dealing with (it's not a
>> deal-breaker but is just bugging me) is the valid time on my MODE
output
>> files. I'm getting times like
>> _000000L_19700101_000000V_NAA.ps
>> instead of
>> _000000L_20180101_000000V_NAA.ps
>> It's almost like MODE isn't reading the seconds in my file since
19700101.
>> I can easily fix it with some cp commands, but if you happened to
know
>> what's going on I'd be interested in knowing.
>>
>> Thanks!
>> Sarah
>>
>> On 7/16/19 2:07 PM, John Halley Gotway via RT wrote:
>>
>> Sarah,
>>
>> Ah great! Looks like you're all set. Sorry that was such a
hassle! Do
>> you have any remaining issues or questions I can help answer?
>>
>> Thanks,
>> John
>>
>> On Tue, Jul 16, 2019 at 12:24 PM Sarah Griffin via RT
<met_help at ucar.edu
>>> <mailto:met_help at ucar.edu>
>> wrote:
>>
>>
>>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>
>> Hi John,
>>
>> Instead of uploading the latest version to the ftp site, I'll just
include
>> this screen shot because lat/lon instead of y/x was the
solution![MODE
>> output]
>>
>> Have a great day!
>> Sarah
>>
>> On 7/16/19 1:01 PM, John Halley Gotway via RT wrote:
>>
>> Sarah,
>>
>> That would work if the NetCDF file really were the output from one
of the
>> MET tools. Since it's not, the library code isn't reading the data
>> properly. Specifically, I'm guessing it's expecting the dimensions
to be
>> named lat/lon rather than y/x. I know that seems silly, but so it
goes.
>>
>> You could upload you latest version to the ftp site if you'd like,
and I
>> could take a look.
>>
>> Just let me know.
>>
>> Thanks,
>> John
>>
>> On Tue, Jul 16, 2019 at 11:55 AM Sarah Griffin via RT
<met_help at ucar.edu
>> <mailto:met_help at ucar.edu>
>>
>>
>> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
>>
>>
>> wrote:
>>
>>
>>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>
>> Hi John,
>>
>> I have. My data is :
>>
>> float channel_14_brightness_temperature(y, x) ;
>> channel_14_brightness_temperature:name =
>> "channel_14_brightness_temperature" ;
>> channel_14_brightness_temperature:long_name =
>> "channel_14_brightness_temperature(*,*)" ;
>> channel_14_brightness_temperature:level = "(*,*)" ;
>> channel_14_brightness_temperature:reference = "all data
are
>> referenced to the ABI channels" ;
>> channel_14_brightness_temperature:units = "K" ;
>> channel_14_brightness_temperature:_FillValue = -999.f ;
>>
>>
>> and I have
>>
>> field = {
>> name = "channel_14_brightness_temperature";
>> level = "(*,*)";
>> file_type = NETCDF_MET;
>> };
>>
>> in my mode config file and I'm still getting the
MetNcFile::data(NcVar *,
>> const LongArray &, DataPlane &) const -> star found in bad slot
error.
>>
>> Sorry this is being so difficult,
>> Sarah
>>
>> On 7/16/19 12:42 PM, John Halley Gotway via RT wrote:
>>
>> Sarah,
>>
>> In the MODE config file, you request what data should be read from
the
>> input gridded data file. The way you do this varies slightly
depending on
>> the type of file you're reading (GRIB1/2 versus NetCDF). For
NetCDF files
>> you'd specify:
>>
>>
>>
>> * field = { name = "NETCDF_VARIABLE_NAME"; level =
>> "NETCDF_DIMENSION_INFO"; }*
>>
>> Where NETCDF_DIMENSION_INFO defines how to extract a 2D filed of
data from
>> the specified NETCDF_VARIABLE_NAME. You put a * for the gridded
dimensions
>> (i.e. lat and lon). When reading the NetCDF output of
regrid_data_plane,
>> it's easy. Just set it to "(*,*)".
>>
>> If you're NetCDF variable had 4 dimensions like this:
>> float data(time, level, lat, lon);
>>
>> You could use:
>> level = "(0, 5, *, *)";
>>
>> To read data for the first time (0-based) and 6th vertical level.
>>
>> Thanks,
>> John
>>
>>
>>
>>
>>
>>
>> On Tue, Jul 16, 2019 at 11:34 AM Sarah Griffin via RT
<met_help at ucar.edu
>> <mailto:met_help at ucar.edu>
>> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
>>
>>
>> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:
>> met_help at ucar.edu><mailto:met_help at ucar.edu>
>>
>>
>> wrote:
>>
>>
>>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>
>> Thanks John. I hope I'm finally on the right track, but when I'm
running
>> MODE I'm still getting the error:
>>
>> MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
>> found in bad slot
>>
>> What does that error mean?
>>
>> Have a great day!
>> Sarah
>>
>> On 7/15/19 5:22 PM, John Halley Gotway via RT wrote:
>>
>>
>> Sarah,
>>
>> OK, I just ran the following command:
>>
>> *regrid_data_plane \*
>> *OR_ABI-L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_
>>
>>
>> c20191961814170.nc
>>
>>
>> \*
>> *
>>
>>
>>
>>
>>
>> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
>>
>>
>> <
>>
>>
>>
>>
>>
>> http://mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
>>
>>
>>
>> \*
>> *goes16_MODE_GRID.nc \*
>> *-field 'name="Rad"; level="(*,*)";'*
>>
>> And that produced an output file with bad data values everywhere.
The
>> problem is that the projection information in that MODE output file
is
>> messed up in some way (
>>
>>
>>
>>
>>
>>
>> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
>> )...
>>
>>
>> which was the original reason you wrote.
>>
>> So I tried a different route. The "to_grid" option for
regrid_data_plane
>> can be defined as a named grid (i.e. G212), the path to a gridded
data
>> file, or an explicit grid definition. I tried the latter. Below
is an
>> excerpt from met-8.1/share/met/config/README:
>>
>> // - to_grid = "spec"; To define a grid specified as follows:
>> // - lambert Nx Ny lat_ll lon_ll lon_orient D_km R_km
>> standard_parallel_1
>> // [standard_parallel_2] N|S
>>
>> I used the metadata from the NetCDF files you sent to define the
>>
>>
>> following
>>
>>
>> grid definition info:
>> 'lambert 1535 1023 22.45395 -119.2807 262.5 3 6371.2 38.5 N'
>>
>> And I ran this command:
>>
>> *regrid_data_plane \*
>> *OR_ABI-L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_
>>
>>
>> c20191961814170.nc
>>
>>
>> \*
>> *'lambert 1535 1023 22.45395 -119.2807 262.5 3 6371.2 38.5 N' \*
>> *goes16_USER_DEFINED.nc -field 'name="Rad"; level="(*,*)";'*
>>
>> And plotted the output. The result (see attached) looks much more
>> promising. I assume that pattern of missing data values is due to
>> insufficient GOES 16 data at those locations.
>>
>> Thanks,
>> John
>>
>> On Mon, Jul 15, 2019 at 1:51 PM Sarah Griffin via RT
<met_help at ucar.edu
>> <mailto:met_help at ucar.edu>
>> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
>>
>>
>> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:
>> met_help at ucar.edu><mailto:met_help at ucar.edu>
>>
>>
>> wrote:
>>
>>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>
>> When you say "gridded data file" does that not include a netCDF
file?
>> I'm trying to use a netCDF file as a grid, which I thought MET
knows how
>> to read. However, I ran my file using regrid_data_plane and then
mode
>> and I get this file
>> (
>>
>>
>>
>>
>>
>>
>> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_19700101_000000V_NAA.ps
>> )
>>
>>
>>
>> that I uploaded and the grid is still offset from when I want. Can
you
>> please test and see what happens when you use my file
>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc as the
grid
>> instead of G212?
>>
>> Also, what does
>> MetNcFile::data(NcVar *, const LongArray &, DataPlane &) const ->
star
>> found in bad slot
>> mean?
>>
>> Thanks!
>> Sarah
>>
>> On 7/15/19 2:40 PM, John Halley Gotway via RT wrote:
>>
>>
>> I just posted it. But realize that the whole point is that you can
>> generate it yourself by running the regrid_data_plane command. And
>>
>>
>> instead
>>
>>
>> of using "G212" on the command, just list a gridded data file that
MET
>> knows how to read that's already on your desired model domain. The
>>
>>
>> tool
>>
>>
>> will read the grid info from that gridded data file and regrid the
>>
>>
>> input
>>
>>
>> GOES-16 values to that domain.
>>
>> Thanks,
>> John
>>
>> On Mon, Jul 15, 2019 at 1:36 PM Sarah Griffin via RT <
>>
>>
>>
met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
>>> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
>>
>> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>>
>>
>>
>>
>>
>> wrote:
>>
>>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>
>> Hi John,
>>
>> Reading this a bit more, can you try to run a regrid to the grid
that
>>
>>
>> I
>>
>>
>> want, which can be found in:
>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc?
>> Unfortunately, remapping it to NCEP Grid 212 is not useful.
>>
>> Have a great day!
>> Sarah
>>
>> On 7/15/19 2:12 PM, John Halley Gotway via RT wrote:
>>
>>
>> Sarah,
>>
>> I grabbed that file from the ftp site and see this header:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *netcdf geocatL1.GOES-16.2018007.000200 {dimensions: x =
2312
>>
>>
>> ;
>>
>>
>> y = 1191 ;variables: float pixel_latitude(y, x) ;
>>
>>
>> float
>>
>>
>> pixel_longitude(y, x) ; float
>>
>>
>> channel_13_brightness_temperature(y,
>>
>>
>> x) ;}*
>>
>> The original GOES-16 file has much more metadata in it that
>> regrid_data_plane expects and uses. I found some GOES-16 data on
our
>> filesystem and am sending you an example of how it can be used by
>> regrid_data_plane. Here's the sample data file:
>>
>> *
>>
>>
>>
>>
>>
>>
>>
>>
>> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
>>
>>
>> <
>>
>>
>>
>>
>>
>>
>>
>>
>> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/OR_ABI-
L1b-RadC-M6C10_G16_s20191961811348_e20191961814132_c20191961814170.nc
>>
>>
>> *
>>
>> And here's the command I ran to interpolate it to NCEP Grid 212
which
>> covers CONUS:
>>
>> *met-8.1/bin/regrid_data_plane \*
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *goes-16/ABI/L1/CONUS/C10/2019196/OR_ABI-L1b-RadC-
M6C10_G16_s20191961811348_e20191961814132_
>>
>>
>> c20191961814170.nc
>>
>>
>> \*
>> *G212 goes16_g212.nc
<http://goes16_g212.nc><http://goes16_g212.nc><
>> http://goes16_g212.nc><http://goes16_g212.nc><
>>
http://goes16_g212.nc><http://goes16_g212.nc><http://goes16_g212.nc><
>> http://goes16_g212.nc>
>> -field 'name="Rad";
>> level="(*,*)";' -method MAX -v 4*
>>
>> And then I plotted the result:
>>
>> *met-8.1/bin/plot_data_plane goes16_g212.nc
<http://goes16_g212.nc><
>> http://goes16_g212.nc><
>> http://goes16_g212.nc><http://goes16_g212.nc><
>>
http://goes16_g212.nc><http://goes16_g212.nc><http://goes16_g212.nc><
>> http://goes16_g212.nc>
>> goes16_g212.ps <http://goes16_g212.ps><http://goes16_g212.ps><
>> http://goes16_g212.ps><http://goes16_g212.ps><
>>
http://goes16_g212.ps><http://goes16_g212.ps><http://goes16_g212.ps><
>> http://goes16_g212.ps>
>> 'name="Rad"; level="(*,*)";'*
>>
>> And that plot is attached.
>>
>> John
>>
>> On Mon, Jul 15, 2019 at 12:37 PM Sarah Griffin via RT <
>>
>>
>>
met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
>>> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
>>
>> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
>>
>>
>>
>>
>> wrote:
>>
>>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>
>> Hi John,
>>
>> Ok, I've added the original GOES-16 data to the ftp site. I've also
>>
>>
>> added '
>>
>>
>> geocatL1.GOES-16.2018007.000200.nc' since the original GOES-16 data
>>
>>
>> needs
>>
>>
>> to be rewritten to actually get the brightness temperatures.
>>
>> I then did:
>> bin/regrid_data_plane \
>> geocatL1.GOES-16.2018007.000200.nc \
>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
>> -field 'name = "channel_13_brightness_temperature"; level =
>>
>>
>> "(*,*)";
>>
>>
>> file_type = NETCDF_MET;' \
>> -v 4
>>
>> and got the same error "MetNcFile::data(NcVar *, const LongArray &,
>> DataPlane &) const -> star found in bad slot"
>>
>>
>>
>> I also added some radar data, Radar_Reflectivity_2018_0107_00_00.nc
>>
>>
>> and
>>
>>
>> Radar_Reflectivity_2018_0107_00_00.nc_new. I was able to do:
>>
>> bin/regrid_data_plane \
>> Radar_Reflectivity_2018_0107_00_00.nc \
>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
>> Radar_Reflectivity_2018_0107_00_00.nc_new \
>> -field 'name = "composite_n0q"; level = "(*,*)"; file_type =
>>
>>
>> NETCDF_MET;'
>>
>>
>> \
>> -v 4
>>
>> And get the remapping to work. I didn't try this is MODE, though,
>>
>>
>> because
>>
>>
>> the composite_n0q data is empty. But I'm curious if any of the
>>
>>
>> global
>>
>>
>> attribute data in Radar_Reflectivity_2018_0107_00_00.nc_new is
>>
>>
>> helpful
>>
>>
>> in
>>
>>
>> figuring out what I need to run MODE?
>>
>> Thanks!
>> Sarah
>>
>> On 7/15/19 1:07 PM, John Halley Gotway via RT wrote:
>>
>> Sarah,
>>
>> What I'm recommending is that we go back to the original GOES-16
>>
>>
>> data,
>>
>>
>> and
>>
>>
>> run it through regrid_data_plane to do that remapping step. If we
>>
>>
>> can
>>
>>
>> get
>>
>>
>> that to work, it'll result in an output file that can easily be
read
>>
>>
>> by
>>
>>
>> MODE.
>>
>> Otherwise, we're stuck with trying to get the CF-convention
>>
>>
>> specification
>>
>>
>> of the WRF domain exactly right, which can be pretty tedious.
>>
>> John
>>
>> On Mon, Jul 15, 2019 at 11:17 AM Sarah Griffin via RT <
>>
>>
>>
met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
>>> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
>>
>> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
>>
>>
>>
>>
>> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:
>> met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:
>>
met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
>>> <mailto:met_help at ucar.edu>
>>
>> wrote:
>>
>>
>>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>
>> Hi John,
>>
>> The GOES-16 data I'm trying to use was created after remapping the
>> native GOES data to the WRF projection from
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> mode_Yang_2018010700_mem0_BT-
thresh_of_235.0_000000L_20180107_060032V_000000A_obj.nc
>>
>>
>> .
>>
>> So does it matter what the GOES projection is if I'm trying to
remap
>>
>>
>> it
>>
>>
>> to a different projection?
>>
>> I've messed around some more and have gotten to this error on
>> regrid_data_plane. MetNcFile::data(NcVar *, const LongArray &,
>>
>>
>> DataPlane
>>
>>
>> &) const -> star found in bad slot
>>
>> when using this command:
>> bin/regrid_data_plane \
>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc \
>> Yang_2018010700_mem0_CRTM_ABI_BT_output_2018_0107_06_00.nc \
>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc_new \
>> -field 'name = "channel_13_brightness_temperature"; level =
>>
>>
>> "(*,*)";
>>
>>
>> file_type = NETCDF_MET;' \
>> -v 4
>>
>> Thanks!
>> Sarah
>>
>> On 7/15/19 11:58 AM, John Halley Gotway via RT wrote:
>>
>>
>> Sarah,
>>
>> Can you please send me a link to the GOES-16 data you're trying to
>>
>>
>> use?
>>
>>
>>
>> I
>>
>>
>> see you have a NetCDF file by this name:
>> emap_geocatL1.GOES-16.CONUS.2018007.000230.nc
>> Where did you get this file? Is is a publicly available ftp site?
>>
>> In general, MET reads gridded data that lives on regular
>>
>>
>> projections.
>>
>>
>>
>>
>> GOES
>>
>>
>> data is a special case... it is not defined on a projection.
>>
>>
>> Instead,
>>
>>
>>
>>
>> it's
>>
>>
>> a whole bunch of high resolution pixels of data. Each pixel has a
>>
>>
>> lat/lon
>>
>>
>> associated with it. We enhanced regrid_data_plane to read those
>>
>>
>> lat/lon's
>>
>>
>> and interpolate them to a user-requested domain.
>>
>> I'm hoping to get a sample GOES-16 file and send you example
>>
>>
>> commands
>>
>>
>> for
>>
>>
>> interpolating it to your model domain using regrid_data_plane.
>>
>> Thanks,
>> John
>>
>> On Mon, Jul 15, 2019 at 9:28 AM Sarah Griffin via RT <
>>
>>
>>
met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
>>> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
>>
>> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu>
>>
>>
>>
>>
>> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:
>> met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:
>>
met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
>>> <mailto:met_help at ucar.edu>
>>
>> wrote:
>>
>>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>
>> Hi John,
>>
>> Update, please ignore the other email I sent. Looks like I was
>>
>>
>> missing
>>
>>
>> '-field' instead of field.
>>
>> However, now I'm getting the error "ERROR :
>> NcCfFile::read_netcdf_grid() -> Couldn't figure out projection from
>> information in netCDF file." It seems like I'm a bit stuck because
I
>> don't know the projection. If I did, I wouldn't need to use
>> regrid_data_plane. Any thoughts?
>>
>> Thanks!
>> Sarah
>>
>> On 7/12/19 5:53 PM, John Halley Gotway via RT wrote:
>>
>>
>> Sarah,
>>
>> I'm pretty sure that didn't fix it entirely. When I plot the
>>
>>
>> channel
>>
>>
>>
>>
>> 15
>>
>>
>> data with plot_data_plane, I clearly see the outline of FL and the
>>
>>
>> Eastern
>>
>>
>> seaboard in the data, but it doesn't line up with the map data. So
>>
>>
>> there's
>>
>>
>> clearly still a problem.
>>
>> I see that you're using GOES-16 data here. MET's regrid_data_plane
>>
>>
>> tool
>>
>>
>> should be able to read GOES-16 data and regrid it to a user-defined
>>
>>
>> grid.
>>
>>
>> That would be another alternatively for using GOES-16 data in MET.
>>
>> Thanks,
>> John
>>
>> On Fri, Jul 12, 2019 at 4:45 PM John Halley Gotway <johnhg at ucar.edu
>> <mailto:johnhg at ucar.edu>
>> <mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu>
>>
<mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu
>>> <mailto:johnhg at ucar.edu>
>>
>>
<mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu
>>> <mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu
>>
>> <mailto:johnhg at ucar.edu><mailto:johnhg at ucar.edu>
>>
>>
>>
>>
>> wrote:
>>
>>
>> Hi Sarah,
>>
>> Thought I'd chime in here to mention the following. This is not
>>
>>
>> actually
>>
>>
>> a problem in MODE tool itself, but more of an issue in how MET is
>>
>>
>> reading
>>
>>
>> data your input files and placing them on the earth. I usually
>>
>>
>> recommend
>>
>>
>> that people run MET's plot_data_plane tool when working with a new
>>
>>
>> data
>>
>>
>> source to make sure MET is reading the data well:
>>
>> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc> plot.ps
>> <http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><
>> http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><
>> http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><
>> http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps>
>> 'name="channel_10_brightness_temperature";
>>
>>
>> level="(*,*)";'
>>
>>
>> -v 4*
>>
>> This produces a nice looking plot, but there's no country outlines
>>
>>
>> on
>>
>>
>>
>>
>> top
>>
>>
>> of the data! And that usually indicates a problem in the
projection
>> information. But I did find one thing which seems to have helped.
>>
>>
>> I
>>
>>
>> changed the longitude_of_central_meridian from 262.5 to -97.5, by
>>
>>
>> running
>>
>>
>> the following command:
>>
>> *ncatted -a longitude_of_central_meridian,Projection,o,f,-97.5
>> remap_geocatL1.GOES-16.CONUS.2018007.060230.nc
>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230.nc>
>> remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc>*
>>
>> Those two longitudes are the same since they differ by 360 degrees.
>> Surprisingly, running plot_data_plane on that modified file did
plot
>>
>>
>> the
>>
>>
>> map data (see attached image):
>>
>> *plot_data_plane remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc
>> <http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc><
>> http://remap_geocatL1.GOES-16.CONUS.2018007.060230_mod.nc> plot.ps
>> <http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><
>> http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><
>> http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps><
>> http://plot.ps><http://plot.ps><http://plot.ps><http://plot.ps>
>> 'name="channel_10_brightness_temperature";
>>
>>
>> level="(*,*)";'
>>
>>
>> -v 4*
>>
>> Can you confirm that the data lives on the right place on the
earth?
>> Should it be covering the Eastern CONUS and Atlantic? If so, then
>>
>>
>> we'll
>>
>>
>> likely need to make a one line fix in MET's library code to rescale
>>
>>
>> the
>>
>>
>> longitude values to the expected range of (-180, 180] when we read
>>
>>
>> them
>>
>>
>> in.
>>
>>
>> Thanks,
>> John
>>
>> On Fri, Jul 12, 2019 at 3:25 PM David Fillmore via RT <
>>
>>
>>
met_help at ucar.edu<mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
>>> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu
>>
>> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:
>> met_help at ucar.edu
>>
>>
>>
>>
>> <mailto:met_help at ucar.edu><mailto:met_help at ucar.edu><mailto:
>> met_help at ucar.edu><mailto:met_help at ucar.edu>>
>>
>>
>>
>>
>> wrote:
>>
>>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91053 >
>>
>> On Fri Jul 12 14:56:24 2019, sarah.griffin at ssec.wisc.edu<mailto:
>> sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
wrote:
>>
>>
>> Hi,
>>
>> I'm using Met 8.0 with the bug fixes to run MODE for two netCDF
>>
>>
>> files.
>>
>>
>> MODE seems to run just fine, however the latitude and longitude of
>>
>>
>> the
>>
>>
>> output is messed up. How can I fix the latitude and longitude? I've
>> uploaded the data and MODE output to the met_help ftp directory.
>>
>>
>> Thanks!
>>
>>
>> Have a great day!
>> Sarah
>>
>>
>>
>> Hi Sarah -
>> Thanks for the data upload.
>> I've passed this ticket along to Randy, our resident MODE
>>
>>
>> specialist.
>>
>>
>> He should get a change to look at this early next week.
>> David
>>
>>
>>
>>
>> --
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
----------------------------------------------------------------------------
>>
>>
>> Sarah M. Griffin
>> Associate Research Scientist
>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>> UW-Madison
>> 1225 W Dayton St. Rm 243
>> Madison, WI 53706
>>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
>> (608) 262-0986
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
----------------------------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
----------------------------------------------------------------------------
>>
>>
>> Sarah M. Griffin
>> Associate Research Scientist
>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>> UW-Madison
>> 1225 W Dayton St. Rm 243
>> Madison, WI 53706
>>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
>> (608) 262-0986
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
----------------------------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
----------------------------------------------------------------------------
>>
>>
>> Sarah M. Griffin
>> Associate Research Scientist
>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>> UW-Madison
>> 1225 W Dayton St. Rm 243
>> Madison, WI 53706
>>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
>> (608) 262-0986
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
----------------------------------------------------------------------------
>>
>>
>>
>>
>>
>> --
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
----------------------------------------------------------------------------
>>
>>
>> Sarah M. Griffin
>> Associate Research Scientist
>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>> UW-Madison
>> 1225 W Dayton St. Rm 243
>> Madison, WI 53706
>>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
>> (608) 262-0986
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
----------------------------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>
>>
>>
>>
>>
>>
>>
----------------------------------------------------------------------------
>>
>>
>> Sarah M. Griffin
>> Associate Research Scientist
>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>> UW-Madison
>> 1225 W Dayton St. Rm 243
>> Madison, WI 53706
>>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
>> (608) 262-0986
>>
>>
>>
>>
>>
>>
>>
>>
----------------------------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>
>>
>>
>>
----------------------------------------------------------------------------
>> Sarah M. Griffin
>> Associate Research Scientist
>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>> UW-Madison
>> 1225 W Dayton St. Rm 243
>> Madison, WI 53706
>>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
>> (608) 262-0986
>>
>>
>>
>>
>>
----------------------------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>
>>
>>
----------------------------------------------------------------------------
>> Sarah M. Griffin
>> Associate Research Scientist
>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>> UW-Madison
>> 1225 W Dayton St. Rm 243
>> Madison, WI 53706
>>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>>
sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu><mailto:
>> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
>> (608) 262-0986
>>
>>
>>
>>
----------------------------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>
>>
----------------------------------------------------------------------------
>> Sarah M. Griffin
>> Associate Research Scientist
>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>> UW-Madison
>> 1225 W Dayton St. Rm 243
>> Madison, WI 53706
>>
sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu><mailto:
>> sarah.griffin at ssec.wisc.edu><mailto:sarah.griffin at ssec.wisc.edu>
>> (608) 262-0986
>>
>>
>>
----------------------------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>
----------------------------------------------------------------------------
>> Sarah M. Griffin
>> Associate Research Scientist
>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>> UW-Madison
>> 1225 W Dayton St. Rm 243
>> Madison, WI 53706
>> sarah.griffin at ssec.wisc.edu<mailto:sarah.griffin at ssec.wisc.edu>
>> (608) 262-0986
>>
>>
----------------------------------------------------------------------------
>>
>>
>>
--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC UW-
Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu
(608) 262-0986
----------------------------------------------------------------------------
------------------------------------------------
More information about the Met_help
mailing list