[Met_help] [rt.rap.ucar.edu #75519] History for MODE projection question
John Halley Gotway via RT
met_help at ucar.edu
Wed Mar 16 11:04:33 MDT 2016
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
I'm having an issue running MODE on some updated HRRR data that I was wondering if you can address. When I run MODE, I'm getting an the error:
ERROR : process_fcst_obs_files() -> The forecast and observation grids do not match: Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL: 21.138 Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623 Bx: 899.1693 By: 3198.9984 != Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL: 21.138 Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623 Bx: 899.1870 By: 3198.9983
I thought this was due to the HRRR latitude and longitude grid updating to a double point array, but even after updating my observation grid to match the HRRR grid, I am still getting this error. Do you know the cause of this error?
I'm posted a HRRR GRIB2 file, GOES observation netcdf files, and the MODE config file to ftp://ftp.rap.ucar.edu/incoming/irap/met_help/griffin_data/.
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: MODE projection question
From: John Halley Gotway
Time: Mon Mar 14 12:25:24 2016
Sarah,
The problem is in the grid specification for the CF-compliant NetCDF
file you're using. Here's the Projection info from your NetCDF file:
int Projection(time) ;
Projection:grid_mapping_name =
"lambert_conformal_conic" ;
Projection:standard_parallel = 38.5f ;
Projection:longitude_of_central_meridian = 262.5f ;
Projection:latitude_of_projection_origin = 21.138f ;
Projection:longitude_of_projection_origin = -122.72f ;
Compare this with the CF specification:
http://cfconventions.org/cf-conventions/v1.6.0/cf-
conventions.html#_lambert_conformal
And notice that "longitude_of_projection_origin" is not actually a
valid attribute.
Instead, the CF convention specifies the reference location at the
latitude of the origin and the longitude of the central meridian.
Then the "x" and "y" variables are used to specify the location in the
grid of those reference longitude and latitude values.
I've talked to other engineers here and we think this is pretty
ridiculous. It makes specifying grid information way overly
complicated. But unfortunately, that's how the spec is written.
To summarize, you should remove the "longitude_of_projection_origin"
attribute since it isn't valid or used. And you should change the
range of values for x from:
0 ... 5394000 to
-something ... +something
And the 0 occurs at the x value which coincides with the longitude of
the central meridian.
Unfortunately, I think I've also discovered a small bug in the Lambert
Conformal grid code, where we've failed to put a longitude value in
the correct range before using it.
Confused yet?
John
------------------------------------------------
Subject: MODE projection question
From: John Halley Gotway
Time: Mon Mar 14 12:26:06 2016
Sarah,
The problem is in the grid specification for the CF-compliant NetCDF
file you're using. Here's the Projection info from your NetCDF file:
int Projection(time) ;
Projection:grid_mapping_name = "lambert_conformal_conic" ;
Projection:standard_parallel = 38.5f ;
Projection:longitude_of_central_meridian = 262.5f ;
Projection:latitude_of_projection_origin = 21.138f ;
Projection:longitude_of_projection_origin = -122.72f ;
Compare this with the CF specification:
http://cfconventions.org/cf-conventions/v1.6.0/cf-
conventions.html#_lambert_conformal
And notice that "longitude_of_projection_origin" is not actually a
valid attribute.
Instead, the CF convention specifies the reference location at the
latitude of the origin and the longitude of the central meridian. Then
the "x" and "y" variables are used to specify the location in the grid
of those reference longitude and latitude values.
I've talked to other engineers here and we think this is pretty
ridiculous. It makes specifying grid information way overly
complicated. But unfortunately, that's how the spec is written.
To summarize, you should remove the "longitude_of_projection_origin"
attribute since it isn't valid or used. And you should change the
range of values for x from:
0 ... 5394000 to
-something ... +something
And the 0 occurs at the x value which coincides with the longitude of
the central meridian.
Unfortunately, I think I've also discovered a small bug in the Lambert
Conformal grid code, where we've failed to put a longitude value in
the correct range before using it.
Confused yet?
John
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #75519] MODE projection question
From: Sarah Griffin
Time: Mon Mar 14 13:22:06 2016
Hi John,
I am incredibly confused.
Removing longitude_of_projection_origin makes sense, and I've done
that.
I've put 2 new files into the incoming directory on the ftp site:
GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 and
remap_GOES-13.2015213.1300_75W.nc. MODE can run on these 2 files just
fine. I converted the 2 GRIB2 files in
incoming/irap/met_help/griffin_data/ to netcdf files, both x's range
from 0 to 5394000. The x's of both remapped GOES observation files
also
range from 0 to 5394000. Yet, MODE will run on one pair but not the
other. So could the 'x' variable still be the problem?
Any ideas?
Sarah
On 3/14/16 1:26 PM, John Halley Gotway via RT wrote:
> Sarah,
>
> The problem is in the grid specification for the CF-compliant NetCDF
file you're using. Here's the Projection info from your NetCDF file:
>
> int Projection(time) ;
> Projection:grid_mapping_name = "lambert_conformal_conic" ;
> Projection:standard_parallel = 38.5f ;
> Projection:longitude_of_central_meridian = 262.5f ;
> Projection:latitude_of_projection_origin = 21.138f ;
> Projection:longitude_of_projection_origin = -122.72f ;
>
> Compare this with the CF specification:
> http://cfconventions.org/cf-conventions/v1.6.0/cf-
conventions.html#_lambert_conformal
>
> And notice that "longitude_of_projection_origin" is not actually a
valid attribute.
>
> Instead, the CF convention specifies the reference location at the
latitude of the origin and the longitude of the central meridian. Then
the "x" and "y" variables are used to specify the location in the grid
of those reference longitude and latitude values.
>
> I've talked to other engineers here and we think this is pretty
ridiculous. It makes specifying grid information way overly
complicated. But unfortunately, that's how the spec is written.
>
> To summarize, you should remove the "longitude_of_projection_origin"
attribute since it isn't valid or used. And you should change the
range of values for x from:
> 0 ... 5394000 to
> -something ... +something
> And the 0 occurs at the x value which coincides with the longitude
of the central meridian.
>
> Unfortunately, I think I've also discovered a small bug in the
Lambert Conformal grid code, where we've failed to put a longitude
value in the correct range before using it.
>
> Confused yet?
>
> John
--
----------------------------------------------------------------------------
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: MODE projection question
From: John Halley Gotway
Time: Mon Mar 14 15:29:00 2016
Sarah,
Running the following MODE command produces that same error:
met-5.1/bin/mode \
GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 \
remap_GOES-13.2015213.1300_75W.nc \
East_2015213_1300_4_0_mode_config_file
ERROR : parse_vx_grid() -> The forecast and observation grids do not
match:
ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623 Bx:
899.1870
By: 3198.9983 !=
ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
Lon_LL: -44.200 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623 Bx:
2312.7166 By: -2386.0992
I am not sure why it's running successfully on your machine. Did we
perhaps apply a hack to your version of the code to get MODE to run on
this
data?
I just forwarded you a message from back in Nov 2015 when we last
discussed
this Lambert Conformal CF-compliant NetCDF issue.
Also, I am still aware of a small bug in the lambert conformal grid
info
that I need to fix and post a bugfix.
John
On Mon, Mar 14, 2016 at 1:22 PM, Sarah Griffin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
>
> Hi John,
>
> I am incredibly confused.
>
> Removing longitude_of_projection_origin makes sense, and I've done
that.
>
> I've put 2 new files into the incoming directory on the ftp site:
> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 and
> remap_GOES-13.2015213.1300_75W.nc. MODE can run on these 2 files
just
> fine. I converted the 2 GRIB2 files in
> incoming/irap/met_help/griffin_data/ to netcdf files, both x's range
> from 0 to 5394000. The x's of both remapped GOES observation files
also
> range from 0 to 5394000. Yet, MODE will run on one pair but not the
> other. So could the 'x' variable still be the problem?
>
> Any ideas?
> Sarah
>
> On 3/14/16 1:26 PM, John Halley Gotway via RT wrote:
> > Sarah,
> >
> > The problem is in the grid specification for the CF-compliant
NetCDF
> file you're using. Here's the Projection info from your NetCDF file:
> >
> > int Projection(time) ;
> > Projection:grid_mapping_name = "lambert_conformal_conic" ;
> > Projection:standard_parallel = 38.5f ;
> > Projection:longitude_of_central_meridian = 262.5f ;
> > Projection:latitude_of_projection_origin = 21.138f ;
> > Projection:longitude_of_projection_origin = -122.72f ;
> >
> > Compare this with the CF specification:
> >
> http://cfconventions.org/cf-conventions/v1.6.0/cf-
conventions.html#_lambert_conformal
> >
> > And notice that "longitude_of_projection_origin" is not actually a
valid
> attribute.
> >
> > Instead, the CF convention specifies the reference location at the
> latitude of the origin and the longitude of the central meridian.
Then the
> "x" and "y" variables are used to specify the location in the grid
of those
> reference longitude and latitude values.
> >
> > I've talked to other engineers here and we think this is pretty
> ridiculous. It makes specifying grid information way overly
complicated.
> But unfortunately, that's how the spec is written.
> >
> > To summarize, you should remove the
"longitude_of_projection_origin"
> attribute since it isn't valid or used. And you should change the
range of
> values for x from:
> > 0 ... 5394000 to
> > -something ... +something
> > And the 0 occurs at the x value which coincides with the longitude
of
> the central meridian.
> >
> > Unfortunately, I think I've also discovered a small bug in the
Lambert
> Conformal grid code, where we've failed to put a longitude value in
the
> correct range before using it.
> >
> > Confused yet?
> >
> > John
>
>
> --
>
>
----------------------------------------------------------------------------
> 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: MODE projection question
From: John Halley Gotway
Time: Mon Mar 14 16:53:05 2016
Sarah,
OK, I just posted this 1 line bugfix for lambert conformal grids in
MET:
http://www.dtcenter.org/met/users/support/known_issues/METv5.1/index.php
Just follow the instructions to apply the patch and recompile.
Next, not sure why the files worked previously for you but not for me.
You
have a few options...
(1) First, I ran the nco commands listed below to update the grid
definition in the file you sent. Rather than specifying the lower-
left
corner as the reference location, we're using x = 899.1693, y = 0 as
the
reference location. Looking in the Latitude and Longitude variables,
I see
the point (900, 0) = lat 24.3646, lon -97.5.
# Subtract 2697507.9 from all the x values
ncap -O -s "x=x-2697507.9" remap_GOES-13.2016032.1300_75W.nc
remap_GOES_patch.nc
# Add back on the x variable attributes and update the reference
latitude value
ncatted -a long_name,x,o,c,"x coordinate of projection" \
-a standard_name,x,o,c,"projection_x_coordinate" \
-a units,x,o,c,"m" \
-a grid_spacing,x,o,c,"3000.0000" \
-a latitude_of_projection_origin,Projection,o,f,24.3646
\
remap_GOES_patch.nc
# Plot the result using the patched version of MET
plot_data_plane \
remap_GOES_patch.nc remap_GOES_patch.ps \
'name = "channel_14_brightness_temperature"; level = "(*,*)";'
I've attached the resulting image. It looks very good. But when I
run it
through MODE, I still get this error:
ERROR : parse_vx_grid() -> The forecast and observation grids do not
match:
ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623 Bx:
899.1693
By: 3198.9984 !=
ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623 Bx:
899.1693
By: 3198.9975
This is a actually a short-coming in MET. MET is doing the simplest
check
for grid equality, and since these grids we not instantiated using the
same
info, MET says they're not equal.
(2) Second, in our development code we've added a new interpolation
"method" called FORCE. It basically means, don't worry about checking
the
grid info. Instead, as long as Nx and Ny match, go ahead and compare
the
data. I ran the development version of MODE using this config file
option:
regrid = {
to_grid = FCST;
method = FORCE;
width = 1;
vld_thresh = 0.5;
}
This says, run MODE using the forecast grid definition. And only
check
that the fcst and obs grid dimensions match.
I could either send you a beta release of the development code for
testing
or you could wait until the next release.
(3) A third option we're considering adding is letting the user
specify the
grid definition to be used directly in the config file. So if your
data
has no grid info... or bad grid info... just specify the desired grid
in
the config file. But that option will be new development and will
take a
few weeks.
What's your timeline? How soon do you need to get this done?
Thanks,
John
On Mon, Mar 14, 2016 at 3:28 PM, John Halley Gotway <johnhg at ucar.edu>
wrote:
> Sarah,
>
> Running the following MODE command produces that same error:
>
> met-5.1/bin/mode \
> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 \
> remap_GOES-13.2015213.1300_75W.nc \
> East_2015213_1300_4_0_mode_config_file
>
> ERROR : parse_vx_grid() -> The forecast and observation grids do
not
> match:
> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623 Bx:
899.1870
> By: 3198.9983 !=
> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
> Lon_LL: -44.200 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623 Bx:
> 2312.7166 By: -2386.0992
>
> I am not sure why it's running successfully on your machine. Did we
> perhaps apply a hack to your version of the code to get MODE to run
on this
> data?
>
> I just forwarded you a message from back in Nov 2015 when we last
> discussed this Lambert Conformal CF-compliant NetCDF issue.
>
> Also, I am still aware of a small bug in the lambert conformal grid
info
> that I need to fix and post a bugfix.
>
> John
>
>
> On Mon, Mar 14, 2016 at 1:22 PM, Sarah Griffin via RT
<met_help at ucar.edu>
> wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
>>
>> Hi John,
>>
>> I am incredibly confused.
>>
>> Removing longitude_of_projection_origin makes sense, and I've done
that.
>>
>> I've put 2 new files into the incoming directory on the ftp site:
>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 and
>> remap_GOES-13.2015213.1300_75W.nc. MODE can run on these 2 files
just
>> fine. I converted the 2 GRIB2 files in
>> incoming/irap/met_help/griffin_data/ to netcdf files, both x's
range
>> from 0 to 5394000. The x's of both remapped GOES observation files
also
>> range from 0 to 5394000. Yet, MODE will run on one pair but not the
>> other. So could the 'x' variable still be the problem?
>>
>> Any ideas?
>> Sarah
>>
>> On 3/14/16 1:26 PM, John Halley Gotway via RT wrote:
>> > Sarah,
>> >
>> > The problem is in the grid specification for the CF-compliant
NetCDF
>> file you're using. Here's the Projection info from your NetCDF
file:
>> >
>> > int Projection(time) ;
>> > Projection:grid_mapping_name = "lambert_conformal_conic" ;
>> > Projection:standard_parallel = 38.5f ;
>> > Projection:longitude_of_central_meridian = 262.5f ;
>> > Projection:latitude_of_projection_origin = 21.138f ;
>> > Projection:longitude_of_projection_origin = -122.72f ;
>> >
>> > Compare this with the CF specification:
>> >
>> http://cfconventions.org/cf-conventions/v1.6.0/cf-
conventions.html#_lambert_conformal
>> >
>> > And notice that "longitude_of_projection_origin" is not actually
a
>> valid attribute.
>> >
>> > Instead, the CF convention specifies the reference location at
the
>> latitude of the origin and the longitude of the central meridian.
Then the
>> "x" and "y" variables are used to specify the location in the grid
of those
>> reference longitude and latitude values.
>> >
>> > I've talked to other engineers here and we think this is pretty
>> ridiculous. It makes specifying grid information way overly
complicated.
>> But unfortunately, that's how the spec is written.
>> >
>> > To summarize, you should remove the
"longitude_of_projection_origin"
>> attribute since it isn't valid or used. And you should change the
range of
>> values for x from:
>> > 0 ... 5394000 to
>> > -something ... +something
>> > And the 0 occurs at the x value which coincides with the
longitude of
>> the central meridian.
>> >
>> > Unfortunately, I think I've also discovered a small bug in the
Lambert
>> Conformal grid code, where we've failed to put a longitude value in
the
>> correct range before using it.
>> >
>> > Confused yet?
>> >
>> > John
>>
>>
>> --
>>
>>
----------------------------------------------------------------------------
>> 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: MODE projection question
From: Sarah Griffin
Time: Tue Mar 15 09:15:06 2016
Hi John,
Thanks for looking into this. I should mention, I'm running using
METv5.0. That could be why something worked previously for me and not
for you.
It seem like option 2 would probably be our best option, since I know
the HRRR grids and remapped GOES grids line up. We are looking to do
something in the next month.
I also wanted to add one more tidbit. I said:
MODE *would* run on
GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 &
remap_GOES-13.2015213.1300_75W.nc
MODE *would **NOT* run on
GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200 &
remap_GOES-13.2016032.1300_75W.nc
I decided to have some fun and discovered:
MODE *will* run on
GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 &
remap_GOES-13.2016032.1300_75W.nc. I know the times do not match up, I
was just curious if it would actually work. I did not change the
remapped GOES file like to recommend in option (1).
Does this mean there is something that changed with the HRRR grib2
file
that it will no longer run in MODE?
Have a great day!
Sarah
On 3/14/16 5:53 PM, John Halley Gotway via RT wrote:
> Sarah,
>
> OK, I just posted this 1 line bugfix for lambert conformal grids in
MET:
>
http://www.dtcenter.org/met/users/support/known_issues/METv5.1/index.php
>
> Just follow the instructions to apply the patch and recompile.
>
> Next, not sure why the files worked previously for you but not for
me. You
> have a few options...
>
> (1) First, I ran the nco commands listed below to update the grid
> definition in the file you sent. Rather than specifying the lower-
left
> corner as the reference location, we're using x = 899.1693, y = 0 as
the
> reference location. Looking in the Latitude and Longitude
variables, I see
> the point (900, 0) = lat 24.3646, lon -97.5.
>
> # Subtract 2697507.9 from all the x values
> ncap -O -s "x=x-2697507.9" remap_GOES-13.2016032.1300_75W.nc
> remap_GOES_patch.nc
>
> # Add back on the x variable attributes and update the reference
> latitude value
> ncatted -a long_name,x,o,c,"x coordinate of projection" \
> -a standard_name,x,o,c,"projection_x_coordinate" \
> -a units,x,o,c,"m" \
> -a grid_spacing,x,o,c,"3000.0000" \
> -a
latitude_of_projection_origin,Projection,o,f,24.3646 \
> remap_GOES_patch.nc
>
> # Plot the result using the patched version of MET
> plot_data_plane \
> remap_GOES_patch.nc remap_GOES_patch.ps \
> 'name = "channel_14_brightness_temperature"; level =
"(*,*)";'
>
> I've attached the resulting image. It looks very good. But when I
run it
> through MODE, I still get this error:
>
> ERROR : parse_vx_grid() -> The forecast and observation grids do
not match:
> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623 Bx:
899.1693
> By: 3198.9984 !=
> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623 Bx:
899.1693
> By: 3198.9975
>
> This is a actually a short-coming in MET. MET is doing the simplest
check
> for grid equality, and since these grids we not instantiated using
the same
> info, MET says they're not equal.
>
> (2) Second, in our development code we've added a new interpolation
> "method" called FORCE. It basically means, don't worry about
checking the
> grid info. Instead, as long as Nx and Ny match, go ahead and
compare the
> data. I ran the development version of MODE using this config file
option:
>
> regrid = {
> to_grid = FCST;
> method = FORCE;
> width = 1;
> vld_thresh = 0.5;
> }
>
> This says, run MODE using the forecast grid definition. And only
check
> that the fcst and obs grid dimensions match.
>
> I could either send you a beta release of the development code for
testing
> or you could wait until the next release.
>
> (3) A third option we're considering adding is letting the user
specify the
> grid definition to be used directly in the config file. So if your
data
> has no grid info... or bad grid info... just specify the desired
grid in
> the config file. But that option will be new development and will
take a
> few weeks.
>
> What's your timeline? How soon do you need to get this done?
>
> Thanks,
> John
>
>
>
> On Mon, Mar 14, 2016 at 3:28 PM, John Halley Gotway
<johnhg at ucar.edu> wrote:
>
>> Sarah,
>>
>> Running the following MODE command produces that same error:
>>
>> met-5.1/bin/mode \
>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 \
>> remap_GOES-13.2015213.1300_75W.nc \
>> East_2015213_1300_4_0_mode_config_file
>>
>> ERROR : parse_vx_grid() -> The forecast and observation grids do
not
>> match:
>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
>> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623 Bx:
899.1870
>> By: 3198.9983 !=
>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
>> Lon_LL: -44.200 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623 Bx:
>> 2312.7166 By: -2386.0992
>>
>> I am not sure why it's running successfully on your machine. Did
we
>> perhaps apply a hack to your version of the code to get MODE to run
on this
>> data?
>>
>> I just forwarded you a message from back in Nov 2015 when we last
>> discussed this Lambert Conformal CF-compliant NetCDF issue.
>>
>> Also, I am still aware of a small bug in the lambert conformal grid
info
>> that I need to fix and post a bugfix.
>>
>> John
>>
>>
>> On Mon, Mar 14, 2016 at 1:22 PM, Sarah Griffin via RT
<met_help at ucar.edu>
>> wrote:
>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
>>>
>>> Hi John,
>>>
>>> I am incredibly confused.
>>>
>>> Removing longitude_of_projection_origin makes sense, and I've done
that.
>>>
>>> I've put 2 new files into the incoming directory on the ftp site:
>>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300
and
>>> remap_GOES-13.2015213.1300_75W.nc. MODE can run on these 2 files
just
>>> fine. I converted the 2 GRIB2 files in
>>> incoming/irap/met_help/griffin_data/ to netcdf files, both x's
range
>>> from 0 to 5394000. The x's of both remapped GOES observation files
also
>>> range from 0 to 5394000. Yet, MODE will run on one pair but not
the
>>> other. So could the 'x' variable still be the problem?
>>>
>>> Any ideas?
>>> Sarah
>>>
>>> On 3/14/16 1:26 PM, John Halley Gotway via RT wrote:
>>>> Sarah,
>>>>
>>>> The problem is in the grid specification for the CF-compliant
NetCDF
>>> file you're using. Here's the Projection info from your NetCDF
file:
>>>> int Projection(time) ;
>>>> Projection:grid_mapping_name = "lambert_conformal_conic" ;
>>>> Projection:standard_parallel = 38.5f ;
>>>> Projection:longitude_of_central_meridian = 262.5f ;
>>>> Projection:latitude_of_projection_origin = 21.138f ;
>>>> Projection:longitude_of_projection_origin = -122.72f ;
>>>>
>>>> Compare this with the CF specification:
>>>>
>>> http://cfconventions.org/cf-conventions/v1.6.0/cf-
conventions.html#_lambert_conformal
>>>> And notice that "longitude_of_projection_origin" is not actually
a
>>> valid attribute.
>>>> Instead, the CF convention specifies the reference location at
the
>>> latitude of the origin and the longitude of the central meridian.
Then the
>>> "x" and "y" variables are used to specify the location in the grid
of those
>>> reference longitude and latitude values.
>>>> I've talked to other engineers here and we think this is pretty
>>> ridiculous. It makes specifying grid information way overly
complicated.
>>> But unfortunately, that's how the spec is written.
>>>> To summarize, you should remove the
"longitude_of_projection_origin"
>>> attribute since it isn't valid or used. And you should change the
range of
>>> values for x from:
>>>> 0 ... 5394000 to
>>>> -something ... +something
>>>> And the 0 occurs at the x value which coincides with the
longitude of
>>> the central meridian.
>>>> Unfortunately, I think I've also discovered a small bug in the
Lambert
>>> Conformal grid code, where we've failed to put a longitude value
in the
>>> correct range before using it.
>>>> Confused yet?
>>>>
>>>> John
>>>
>>> --
>>>
>>>
----------------------------------------------------------------------------
>>> 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: MODE projection question
From: John Halley Gotway
Time: Tue Mar 15 09:42:14 2016
Sarah,
Using wgrib2 with the -V option to look at the grid definition, I see
the
following:
[johnhg at number5]% wgrib2 -V
GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300
1:0:vt=2015080113:top of atmosphere:anl:var discipline=3 center=59
local_table=1 parmcat=192 parm=2:
ndata=1905141:undef=0:mean=284.12:min=186.7:max=302.2
grid_template=30:winds(grid):
Lambert Conformal: (1799 x 1059) input WE:SN output WE:SN res
8
Lat1 21.138000 Lon1 237.280000 LoV 262.500000
LatD 38.500000 Latin1 38.500000 Latin2 38.500000
LatSP 0.000000 LonSP 0.000000
North Pole (1799 x 1059) Dx 3000.000000 m Dy 3000.000000 m
mode 8
[johnhg at number5]% wgrib2 -V
GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200
1:0:vt=2016020113:top of atmosphere:1 hour fcst:var discipline=3
center=59
local_table=1 parmcat=192 parm=2:
ndata=1905141:undef=0:mean=268.375:min=198.78:max=297.32
grid_template=30:winds(grid):
Lambert Conformal: (1799 x 1059) input WE:SN output WE:SN res
8
Lat1 21.138123 Lon1 237.280472 LoV 262.500000
LatD 38.500000 Latin1 38.500000 Latin2 38.500000
LatSP 0.000000 LonSP 0.000000
North Pole (1799 x 1059) Dx 3000.000000 m Dy 3000.000000 m
mode 8
Note the slight difference in the reference lat/lon value. The 2015
file
uses up to 3 decimal points while the 2016 file uses up to 6 decimal
points. While 6 decimal points is fine in GRIB2, only 3 decimal
points (up
to 1/1000th) can be represented in GRIB1.
Perhaps in 2015 you had GRIB1 data that was being converted to GRIB2
and in
2016 you have GRIB2 directly.
I know that the difference is slight, but MET will flag these grids as
being different.
John
On Tue, Mar 15, 2016 at 9:15 AM, Sarah Griffin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
>
> Hi John,
>
> Thanks for looking into this. I should mention, I'm running using
> METv5.0. That could be why something worked previously for me and
not
> for you.
>
> It seem like option 2 would probably be our best option, since I
know
> the HRRR grids and remapped GOES grids line up. We are looking to do
> something in the next month.
>
> I also wanted to add one more tidbit. I said:
> MODE *would* run on
> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 &
> remap_GOES-13.2015213.1300_75W.nc
> MODE *would **NOT* run on
> GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200 &
> remap_GOES-13.2016032.1300_75W.nc
>
> I decided to have some fun and discovered:
> MODE *will* run on
> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 &
> remap_GOES-13.2016032.1300_75W.nc. I know the times do not match up,
I
> was just curious if it would actually work. I did not change the
> remapped GOES file like to recommend in option (1).
>
> Does this mean there is something that changed with the HRRR grib2
file
> that it will no longer run in MODE?
>
> Have a great day!
> Sarah
>
>
> On 3/14/16 5:53 PM, John Halley Gotway via RT wrote:
> > Sarah,
> >
> > OK, I just posted this 1 line bugfix for lambert conformal grids
in MET:
> >
>
http://www.dtcenter.org/met/users/support/known_issues/METv5.1/index.php
> >
> > Just follow the instructions to apply the patch and recompile.
> >
> > Next, not sure why the files worked previously for you but not for
me.
> You
> > have a few options...
> >
> > (1) First, I ran the nco commands listed below to update the grid
> > definition in the file you sent. Rather than specifying the
lower-left
> > corner as the reference location, we're using x = 899.1693, y = 0
as the
> > reference location. Looking in the Latitude and Longitude
variables, I
> see
> > the point (900, 0) = lat 24.3646, lon -97.5.
> >
> > # Subtract 2697507.9 from all the x values
> > ncap -O -s "x=x-2697507.9" remap_GOES-13.2016032.1300_75W.nc
> > remap_GOES_patch.nc
> >
> > # Add back on the x variable attributes and update the
reference
> > latitude value
> > ncatted -a long_name,x,o,c,"x coordinate of projection" \
> > -a standard_name,x,o,c,"projection_x_coordinate" \
> > -a units,x,o,c,"m" \
> > -a grid_spacing,x,o,c,"3000.0000" \
> > -a
latitude_of_projection_origin,Projection,o,f,24.3646 \
> > remap_GOES_patch.nc
> >
> > # Plot the result using the patched version of MET
> > plot_data_plane \
> > remap_GOES_patch.nc remap_GOES_patch.ps \
> > 'name = "channel_14_brightness_temperature"; level =
"(*,*)";'
> >
> > I've attached the resulting image. It looks very good. But when
I run
> it
> > through MODE, I still get this error:
> >
> > ERROR : parse_vx_grid() -> The forecast and observation grids do
not
> match:
> > ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
> > Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623 Bx:
> 899.1693
> > By: 3198.9984 !=
> > ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
> > Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623 Bx:
> 899.1693
> > By: 3198.9975
> >
> > This is a actually a short-coming in MET. MET is doing the
simplest
> check
> > for grid equality, and since these grids we not instantiated using
the
> same
> > info, MET says they're not equal.
> >
> > (2) Second, in our development code we've added a new
interpolation
> > "method" called FORCE. It basically means, don't worry about
checking
> the
> > grid info. Instead, as long as Nx and Ny match, go ahead and
compare the
> > data. I ran the development version of MODE using this config
file
> option:
> >
> > regrid = {
> > to_grid = FCST;
> > method = FORCE;
> > width = 1;
> > vld_thresh = 0.5;
> > }
> >
> > This says, run MODE using the forecast grid definition. And only
check
> > that the fcst and obs grid dimensions match.
> >
> > I could either send you a beta release of the development code for
> testing
> > or you could wait until the next release.
> >
> > (3) A third option we're considering adding is letting the user
specify
> the
> > grid definition to be used directly in the config file. So if
your data
> > has no grid info... or bad grid info... just specify the desired
grid in
> > the config file. But that option will be new development and will
take a
> > few weeks.
> >
> > What's your timeline? How soon do you need to get this done?
> >
> > Thanks,
> > John
> >
> >
> >
> > On Mon, Mar 14, 2016 at 3:28 PM, John Halley Gotway
<johnhg at ucar.edu>
> wrote:
> >
> >> Sarah,
> >>
> >> Running the following MODE command produces that same error:
> >>
> >> met-5.1/bin/mode \
> >> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 \
> >> remap_GOES-13.2015213.1300_75W.nc \
> >> East_2015213_1300_4_0_mode_config_file
> >>
> >> ERROR : parse_vx_grid() -> The forecast and observation grids do
not
> >> match:
> >> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
> >> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623
Bx:
> 899.1870
> >> By: 3198.9983 !=
> >> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
> >> Lon_LL: -44.200 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623
Bx:
> >> 2312.7166 By: -2386.0992
> >>
> >> I am not sure why it's running successfully on your machine. Did
we
> >> perhaps apply a hack to your version of the code to get MODE to
run on
> this
> >> data?
> >>
> >> I just forwarded you a message from back in Nov 2015 when we last
> >> discussed this Lambert Conformal CF-compliant NetCDF issue.
> >>
> >> Also, I am still aware of a small bug in the lambert conformal
grid info
> >> that I need to fix and post a bugfix.
> >>
> >> John
> >>
> >>
> >> On Mon, Mar 14, 2016 at 1:22 PM, Sarah Griffin via RT <
> met_help at ucar.edu>
> >> wrote:
> >>
> >>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
> >>>
> >>> Hi John,
> >>>
> >>> I am incredibly confused.
> >>>
> >>> Removing longitude_of_projection_origin makes sense, and I've
done
> that.
> >>>
> >>> I've put 2 new files into the incoming directory on the ftp
site:
> >>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300
and
> >>> remap_GOES-13.2015213.1300_75W.nc. MODE can run on these 2 files
just
> >>> fine. I converted the 2 GRIB2 files in
> >>> incoming/irap/met_help/griffin_data/ to netcdf files, both x's
range
> >>> from 0 to 5394000. The x's of both remapped GOES observation
files also
> >>> range from 0 to 5394000. Yet, MODE will run on one pair but not
the
> >>> other. So could the 'x' variable still be the problem?
> >>>
> >>> Any ideas?
> >>> Sarah
> >>>
> >>> On 3/14/16 1:26 PM, John Halley Gotway via RT wrote:
> >>>> Sarah,
> >>>>
> >>>> The problem is in the grid specification for the CF-compliant
NetCDF
> >>> file you're using. Here's the Projection info from your NetCDF
file:
> >>>> int Projection(time) ;
> >>>> Projection:grid_mapping_name = "lambert_conformal_conic" ;
> >>>> Projection:standard_parallel = 38.5f ;
> >>>> Projection:longitude_of_central_meridian = 262.5f ;
> >>>> Projection:latitude_of_projection_origin = 21.138f ;
> >>>> Projection:longitude_of_projection_origin = -122.72f ;
> >>>>
> >>>> Compare this with the CF specification:
> >>>>
> >>>
> http://cfconventions.org/cf-conventions/v1.6.0/cf-
conventions.html#_lambert_conformal
> >>>> And notice that "longitude_of_projection_origin" is not
actually a
> >>> valid attribute.
> >>>> Instead, the CF convention specifies the reference location at
the
> >>> latitude of the origin and the longitude of the central
meridian. Then
> the
> >>> "x" and "y" variables are used to specify the location in the
grid of
> those
> >>> reference longitude and latitude values.
> >>>> I've talked to other engineers here and we think this is pretty
> >>> ridiculous. It makes specifying grid information way overly
> complicated.
> >>> But unfortunately, that's how the spec is written.
> >>>> To summarize, you should remove the
"longitude_of_projection_origin"
> >>> attribute since it isn't valid or used. And you should change
the
> range of
> >>> values for x from:
> >>>> 0 ... 5394000 to
> >>>> -something ... +something
> >>>> And the 0 occurs at the x value which coincides with the
longitude of
> >>> the central meridian.
> >>>> Unfortunately, I think I've also discovered a small bug in the
Lambert
> >>> Conformal grid code, where we've failed to put a longitude value
in the
> >>> correct range before using it.
> >>>> Confused yet?
> >>>>
> >>>> John
> >>>
> >>> --
> >>>
> >>>
>
----------------------------------------------------------------------------
> >>> 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 #75519] MODE projection question
From: Sarah Griffin
Time: Tue Mar 15 10:08:38 2016
Hi John,
I did not know wgrib2 -V was an option so thanks for finding the grid
definitions. Seems like that narrows down the issue for why MODE
wouldn't run, the HRRR grid changed slightly. I tried updating the
remapped observation using:
cp remap_GOES-13.2016032.1300_75W.nc remap_GOES_patch.nc
ncatted -a latitude_of_projection_origin,Projection,o,f,21.138123
remap_GOES_patch.nc
to account for the updated center lat, but that did not solve the
issue.
Do you have any other thoughts?
Thanks,
Sarah
On 3/15/16 10:42 AM, John Halley Gotway via RT wrote:
> Sarah,
>
> Using wgrib2 with the -V option to look at the grid definition, I
see the
> following:
>
> [johnhg at number5]% wgrib2 -V
> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300
> 1:0:vt=2015080113:top of atmosphere:anl:var discipline=3 center=59
> local_table=1 parmcat=192 parm=2:
> ndata=1905141:undef=0:mean=284.12:min=186.7:max=302.2
> grid_template=30:winds(grid):
> Lambert Conformal: (1799 x 1059) input WE:SN output WE:SN
res 8
> Lat1 21.138000 Lon1 237.280000 LoV 262.500000
> LatD 38.500000 Latin1 38.500000 Latin2 38.500000
> LatSP 0.000000 LonSP 0.000000
> North Pole (1799 x 1059) Dx 3000.000000 m Dy 3000.000000 m
mode 8
>
> [johnhg at number5]% wgrib2 -V
> GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200
> 1:0:vt=2016020113:top of atmosphere:1 hour fcst:var discipline=3
center=59
> local_table=1 parmcat=192 parm=2:
> ndata=1905141:undef=0:mean=268.375:min=198.78:max=297.32
> grid_template=30:winds(grid):
> Lambert Conformal: (1799 x 1059) input WE:SN output WE:SN
res 8
> Lat1 21.138123 Lon1 237.280472 LoV 262.500000
> LatD 38.500000 Latin1 38.500000 Latin2 38.500000
> LatSP 0.000000 LonSP 0.000000
> North Pole (1799 x 1059) Dx 3000.000000 m Dy 3000.000000 m
mode 8
>
> Note the slight difference in the reference lat/lon value. The 2015
file
> uses up to 3 decimal points while the 2016 file uses up to 6 decimal
> points. While 6 decimal points is fine in GRIB2, only 3 decimal
points (up
> to 1/1000th) can be represented in GRIB1.
>
> Perhaps in 2015 you had GRIB1 data that was being converted to GRIB2
and in
> 2016 you have GRIB2 directly.
>
> I know that the difference is slight, but MET will flag these grids
as
> being different.
>
> John
>
>
>
> On Tue, Mar 15, 2016 at 9:15 AM, Sarah Griffin via RT
<met_help at ucar.edu>
> wrote:
>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
>>
>> Hi John,
>>
>> Thanks for looking into this. I should mention, I'm running using
>> METv5.0. That could be why something worked previously for me and
not
>> for you.
>>
>> It seem like option 2 would probably be our best option, since I
know
>> the HRRR grids and remapped GOES grids line up. We are looking to
do
>> something in the next month.
>>
>> I also wanted to add one more tidbit. I said:
>> MODE *would* run on
>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 &
>> remap_GOES-13.2015213.1300_75W.nc
>> MODE *would **NOT* run on
>> GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200 &
>> remap_GOES-13.2016032.1300_75W.nc
>>
>> I decided to have some fun and discovered:
>> MODE *will* run on
>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 &
>> remap_GOES-13.2016032.1300_75W.nc. I know the times do not match
up, I
>> was just curious if it would actually work. I did not change the
>> remapped GOES file like to recommend in option (1).
>>
>> Does this mean there is something that changed with the HRRR grib2
file
>> that it will no longer run in MODE?
>>
>> Have a great day!
>> Sarah
>>
>>
>> On 3/14/16 5:53 PM, John Halley Gotway via RT wrote:
>>> Sarah,
>>>
>>> OK, I just posted this 1 line bugfix for lambert conformal grids
in MET:
>>>
>>
http://www.dtcenter.org/met/users/support/known_issues/METv5.1/index.php
>>> Just follow the instructions to apply the patch and recompile.
>>>
>>> Next, not sure why the files worked previously for you but not for
me.
>> You
>>> have a few options...
>>>
>>> (1) First, I ran the nco commands listed below to update the grid
>>> definition in the file you sent. Rather than specifying the
lower-left
>>> corner as the reference location, we're using x = 899.1693, y = 0
as the
>>> reference location. Looking in the Latitude and Longitude
variables, I
>> see
>>> the point (900, 0) = lat 24.3646, lon -97.5.
>>>
>>> # Subtract 2697507.9 from all the x values
>>> ncap -O -s "x=x-2697507.9" remap_GOES-13.2016032.1300_75W.nc
>>> remap_GOES_patch.nc
>>>
>>> # Add back on the x variable attributes and update the
reference
>>> latitude value
>>> ncatted -a long_name,x,o,c,"x coordinate of projection" \
>>> -a standard_name,x,o,c,"projection_x_coordinate"
\
>>> -a units,x,o,c,"m" \
>>> -a grid_spacing,x,o,c,"3000.0000" \
>>> -a
latitude_of_projection_origin,Projection,o,f,24.3646 \
>>> remap_GOES_patch.nc
>>>
>>> # Plot the result using the patched version of MET
>>> plot_data_plane \
>>> remap_GOES_patch.nc remap_GOES_patch.ps \
>>> 'name = "channel_14_brightness_temperature"; level =
"(*,*)";'
>>>
>>> I've attached the resulting image. It looks very good. But when
I run
>> it
>>> through MODE, I still get this error:
>>>
>>> ERROR : parse_vx_grid() -> The forecast and observation grids do
not
>> match:
>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
>>> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623 Bx:
>> 899.1693
>>> By: 3198.9984 !=
>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
>>> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623 Bx:
>> 899.1693
>>> By: 3198.9975
>>>
>>> This is a actually a short-coming in MET. MET is doing the
simplest
>> check
>>> for grid equality, and since these grids we not instantiated using
the
>> same
>>> info, MET says they're not equal.
>>>
>>> (2) Second, in our development code we've added a new
interpolation
>>> "method" called FORCE. It basically means, don't worry about
checking
>> the
>>> grid info. Instead, as long as Nx and Ny match, go ahead and
compare the
>>> data. I ran the development version of MODE using this config
file
>> option:
>>> regrid = {
>>> to_grid = FCST;
>>> method = FORCE;
>>> width = 1;
>>> vld_thresh = 0.5;
>>> }
>>>
>>> This says, run MODE using the forecast grid definition. And only
check
>>> that the fcst and obs grid dimensions match.
>>>
>>> I could either send you a beta release of the development code for
>> testing
>>> or you could wait until the next release.
>>>
>>> (3) A third option we're considering adding is letting the user
specify
>> the
>>> grid definition to be used directly in the config file. So if
your data
>>> has no grid info... or bad grid info... just specify the desired
grid in
>>> the config file. But that option will be new development and will
take a
>>> few weeks.
>>>
>>> What's your timeline? How soon do you need to get this done?
>>>
>>> Thanks,
>>> John
>>>
>>>
>>>
>>> On Mon, Mar 14, 2016 at 3:28 PM, John Halley Gotway
<johnhg at ucar.edu>
>> wrote:
>>>> Sarah,
>>>>
>>>> Running the following MODE command produces that same error:
>>>>
>>>> met-5.1/bin/mode \
>>>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 \
>>>> remap_GOES-13.2015213.1300_75W.nc \
>>>> East_2015213_1300_4_0_mode_config_file
>>>>
>>>> ERROR : parse_vx_grid() -> The forecast and observation grids do
not
>>>> match:
>>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
>>>> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623
Bx:
>> 899.1870
>>>> By: 3198.9983 !=
>>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
>>>> Lon_LL: -44.200 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623
Bx:
>>>> 2312.7166 By: -2386.0992
>>>>
>>>> I am not sure why it's running successfully on your machine. Did
we
>>>> perhaps apply a hack to your version of the code to get MODE to
run on
>> this
>>>> data?
>>>>
>>>> I just forwarded you a message from back in Nov 2015 when we last
>>>> discussed this Lambert Conformal CF-compliant NetCDF issue.
>>>>
>>>> Also, I am still aware of a small bug in the lambert conformal
grid info
>>>> that I need to fix and post a bugfix.
>>>>
>>>> John
>>>>
>>>>
>>>> On Mon, Mar 14, 2016 at 1:22 PM, Sarah Griffin via RT <
>> met_help at ucar.edu>
>>>> wrote:
>>>>
>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
>>>>>
>>>>> Hi John,
>>>>>
>>>>> I am incredibly confused.
>>>>>
>>>>> Removing longitude_of_projection_origin makes sense, and I've
done
>> that.
>>>>> I've put 2 new files into the incoming directory on the ftp
site:
>>>>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300
and
>>>>> remap_GOES-13.2015213.1300_75W.nc. MODE can run on these 2 files
just
>>>>> fine. I converted the 2 GRIB2 files in
>>>>> incoming/irap/met_help/griffin_data/ to netcdf files, both x's
range
>>>>> from 0 to 5394000. The x's of both remapped GOES observation
files also
>>>>> range from 0 to 5394000. Yet, MODE will run on one pair but not
the
>>>>> other. So could the 'x' variable still be the problem?
>>>>>
>>>>> Any ideas?
>>>>> Sarah
>>>>>
>>>>> On 3/14/16 1:26 PM, John Halley Gotway via RT wrote:
>>>>>> Sarah,
>>>>>>
>>>>>> The problem is in the grid specification for the CF-compliant
NetCDF
>>>>> file you're using. Here's the Projection info from your NetCDF
file:
>>>>>> int Projection(time) ;
>>>>>> Projection:grid_mapping_name = "lambert_conformal_conic" ;
>>>>>> Projection:standard_parallel = 38.5f ;
>>>>>> Projection:longitude_of_central_meridian = 262.5f ;
>>>>>> Projection:latitude_of_projection_origin = 21.138f ;
>>>>>> Projection:longitude_of_projection_origin = -122.72f ;
>>>>>>
>>>>>> Compare this with the CF specification:
>>>>>>
>> http://cfconventions.org/cf-conventions/v1.6.0/cf-
conventions.html#_lambert_conformal
>>>>>> And notice that "longitude_of_projection_origin" is not
actually a
>>>>> valid attribute.
>>>>>> Instead, the CF convention specifies the reference location at
the
>>>>> latitude of the origin and the longitude of the central
meridian. Then
>> the
>>>>> "x" and "y" variables are used to specify the location in the
grid of
>> those
>>>>> reference longitude and latitude values.
>>>>>> I've talked to other engineers here and we think this is pretty
>>>>> ridiculous. It makes specifying grid information way overly
>> complicated.
>>>>> But unfortunately, that's how the spec is written.
>>>>>> To summarize, you should remove the
"longitude_of_projection_origin"
>>>>> attribute since it isn't valid or used. And you should change
the
>> range of
>>>>> values for x from:
>>>>>> 0 ... 5394000 to
>>>>>> -something ... +something
>>>>>> And the 0 occurs at the x value which coincides with the
longitude of
>>>>> the central meridian.
>>>>>> Unfortunately, I think I've also discovered a small bug in the
Lambert
>>>>> Conformal grid code, where we've failed to put a longitude value
in the
>>>>> correct range before using it.
>>>>>> Confused yet?
>>>>>>
>>>>>> John
>>>>> --
>>>>>
>>>>>
>>
----------------------------------------------------------------------------
>>>>> 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: MODE projection question
From: John Halley Gotway
Time: Tue Mar 15 10:40:11 2016
Sarah,
I was confused as to why the 2015 case is working for you in MET 5.0
but
not for me. After doing some searching I see that I sent you guys a
hacked
version of nccf_file.cc back on 7/22/2015. It just hardcodes the HRRR
domain. So even though the Lambert Conformal grid isn't set right in
the
NetCDF file, it doesn't matter. MET ignores that and uses the hard-
coded
grid definition.
The reason for the trouble you're having now is the slight change to
the
HRRR grid... i.e. 3 decimal points changed to 6 decimal points.
So the hardcoded HRRR grid definition in nccf_file.cc is no longer
consistent. This hacking of the code is not a good long term
solution.
Until we get a better solution, you have a couple of choices.
(1) Edit the hack in nccf_file.cc to match the updated grid definition
and
recompile MET.
(2) Run your HRRR GRIB2 file through the cnvgrib utility to convert
from
GRIB2 to GRIB1. That'll change the 6 decimal points back to 3 and
match
the existing definition.
cnvgrib -g21 \
GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200 \
GRIB1.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200
As a side-note, this has actually uncovered 2 problems in MET...
(1) The lambert conformal grid code was failing to rescale a longitude
value when it should have (posted met-5.1 bugfix).
(2) The lambert conformal grid equality checking is still
insufficient.
There are many ways the same grid could be specified... but MET only
says
they are equal if they're specified in exactly the same way. In you
case,
GRIB2 specifies the lower-left corner while CF-compliant NetCDF
specifies
the location of the lower center grid point. MET should be smart
enough to
recognize these as being the same grids. This is an open issue.
John
On Tue, Mar 15, 2016 at 10:08 AM, Sarah Griffin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
>
> Hi John,
>
> I did not know wgrib2 -V was an option so thanks for finding the
grid
> definitions. Seems like that narrows down the issue for why MODE
> wouldn't run, the HRRR grid changed slightly. I tried updating the
> remapped observation using:
>
> cp remap_GOES-13.2016032.1300_75W.nc remap_GOES_patch.nc
> ncatted -a latitude_of_projection_origin,Projection,o,f,21.138123
> remap_GOES_patch.nc
>
> to account for the updated center lat, but that did not solve the
issue.
> Do you have any other thoughts?
>
> Thanks,
> Sarah
>
> On 3/15/16 10:42 AM, John Halley Gotway via RT wrote:
> > Sarah,
> >
> > Using wgrib2 with the -V option to look at the grid definition, I
see the
> > following:
> >
> > [johnhg at number5]% wgrib2 -V
> > GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300
> > 1:0:vt=2015080113:top of atmosphere:anl:var discipline=3 center=59
> > local_table=1 parmcat=192 parm=2:
> > ndata=1905141:undef=0:mean=284.12:min=186.7:max=302.2
> > grid_template=30:winds(grid):
> > Lambert Conformal: (1799 x 1059) input WE:SN output WE:SN
res 8
> > Lat1 21.138000 Lon1 237.280000 LoV 262.500000
> > LatD 38.500000 Latin1 38.500000 Latin2 38.500000
> > LatSP 0.000000 LonSP 0.000000
> > North Pole (1799 x 1059) Dx 3000.000000 m Dy 3000.000000
m mode
> 8
> >
> > [johnhg at number5]% wgrib2 -V
> > GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200
> > 1:0:vt=2016020113:top of atmosphere:1 hour fcst:var discipline=3
> center=59
> > local_table=1 parmcat=192 parm=2:
> > ndata=1905141:undef=0:mean=268.375:min=198.78:max=297.32
> > grid_template=30:winds(grid):
> > Lambert Conformal: (1799 x 1059) input WE:SN output WE:SN
res 8
> > Lat1 21.138123 Lon1 237.280472 LoV 262.500000
> > LatD 38.500000 Latin1 38.500000 Latin2 38.500000
> > LatSP 0.000000 LonSP 0.000000
> > North Pole (1799 x 1059) Dx 3000.000000 m Dy 3000.000000
m mode
> 8
> >
> > Note the slight difference in the reference lat/lon value. The
2015 file
> > uses up to 3 decimal points while the 2016 file uses up to 6
decimal
> > points. While 6 decimal points is fine in GRIB2, only 3 decimal
points
> (up
> > to 1/1000th) can be represented in GRIB1.
> >
> > Perhaps in 2015 you had GRIB1 data that was being converted to
GRIB2 and
> in
> > 2016 you have GRIB2 directly.
> >
> > I know that the difference is slight, but MET will flag these
grids as
> > being different.
> >
> > John
> >
> >
> >
> > On Tue, Mar 15, 2016 at 9:15 AM, Sarah Griffin via RT
<met_help at ucar.edu
> >
> > wrote:
> >
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
> >>
> >> Hi John,
> >>
> >> Thanks for looking into this. I should mention, I'm running using
> >> METv5.0. That could be why something worked previously for me and
not
> >> for you.
> >>
> >> It seem like option 2 would probably be our best option, since I
know
> >> the HRRR grids and remapped GOES grids line up. We are looking to
do
> >> something in the next month.
> >>
> >> I also wanted to add one more tidbit. I said:
> >> MODE *would* run on
> >> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 &
> >> remap_GOES-13.2015213.1300_75W.nc
> >> MODE *would **NOT* run on
> >> GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200 &
> >> remap_GOES-13.2016032.1300_75W.nc
> >>
> >> I decided to have some fun and discovered:
> >> MODE *will* run on
> >> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 &
> >> remap_GOES-13.2016032.1300_75W.nc. I know the times do not match
up, I
> >> was just curious if it would actually work. I did not change the
> >> remapped GOES file like to recommend in option (1).
> >>
> >> Does this mean there is something that changed with the HRRR
grib2 file
> >> that it will no longer run in MODE?
> >>
> >> Have a great day!
> >> Sarah
> >>
> >>
> >> On 3/14/16 5:53 PM, John Halley Gotway via RT wrote:
> >>> Sarah,
> >>>
> >>> OK, I just posted this 1 line bugfix for lambert conformal grids
in
> MET:
> >>>
> >>
>
http://www.dtcenter.org/met/users/support/known_issues/METv5.1/index.php
> >>> Just follow the instructions to apply the patch and recompile.
> >>>
> >>> Next, not sure why the files worked previously for you but not
for me.
> >> You
> >>> have a few options...
> >>>
> >>> (1) First, I ran the nco commands listed below to update the
grid
> >>> definition in the file you sent. Rather than specifying the
lower-left
> >>> corner as the reference location, we're using x = 899.1693, y =
0 as
> the
> >>> reference location. Looking in the Latitude and Longitude
variables, I
> >> see
> >>> the point (900, 0) = lat 24.3646, lon -97.5.
> >>>
> >>> # Subtract 2697507.9 from all the x values
> >>> ncap -O -s "x=x-2697507.9" remap_GOES-
13.2016032.1300_75W.nc
> >>> remap_GOES_patch.nc
> >>>
> >>> # Add back on the x variable attributes and update the
reference
> >>> latitude value
> >>> ncatted -a long_name,x,o,c,"x coordinate of projection" \
> >>> -a
standard_name,x,o,c,"projection_x_coordinate" \
> >>> -a units,x,o,c,"m" \
> >>> -a grid_spacing,x,o,c,"3000.0000" \
> >>> -a
> latitude_of_projection_origin,Projection,o,f,24.3646 \
> >>> remap_GOES_patch.nc
> >>>
> >>> # Plot the result using the patched version of MET
> >>> plot_data_plane \
> >>> remap_GOES_patch.nc remap_GOES_patch.ps \
> >>> 'name = "channel_14_brightness_temperature"; level =
"(*,*)";'
> >>>
> >>> I've attached the resulting image. It looks very good. But
when I run
> >> it
> >>> through MODE, I still get this error:
> >>>
> >>> ERROR : parse_vx_grid() -> The forecast and observation grids
do not
> >> match:
> >>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
> >>> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623
Bx:
> >> 899.1693
> >>> By: 3198.9984 !=
> >>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
> >>> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623
Bx:
> >> 899.1693
> >>> By: 3198.9975
> >>>
> >>> This is a actually a short-coming in MET. MET is doing the
simplest
> >> check
> >>> for grid equality, and since these grids we not instantiated
using the
> >> same
> >>> info, MET says they're not equal.
> >>>
> >>> (2) Second, in our development code we've added a new
interpolation
> >>> "method" called FORCE. It basically means, don't worry about
checking
> >> the
> >>> grid info. Instead, as long as Nx and Ny match, go ahead and
compare
> the
> >>> data. I ran the development version of MODE using this config
file
> >> option:
> >>> regrid = {
> >>> to_grid = FCST;
> >>> method = FORCE;
> >>> width = 1;
> >>> vld_thresh = 0.5;
> >>> }
> >>>
> >>> This says, run MODE using the forecast grid definition. And
only check
> >>> that the fcst and obs grid dimensions match.
> >>>
> >>> I could either send you a beta release of the development code
for
> >> testing
> >>> or you could wait until the next release.
> >>>
> >>> (3) A third option we're considering adding is letting the user
specify
> >> the
> >>> grid definition to be used directly in the config file. So if
your
> data
> >>> has no grid info... or bad grid info... just specify the desired
grid
> in
> >>> the config file. But that option will be new development and
will
> take a
> >>> few weeks.
> >>>
> >>> What's your timeline? How soon do you need to get this done?
> >>>
> >>> Thanks,
> >>> John
> >>>
> >>>
> >>>
> >>> On Mon, Mar 14, 2016 at 3:28 PM, John Halley Gotway
<johnhg at ucar.edu>
> >> wrote:
> >>>> Sarah,
> >>>>
> >>>> Running the following MODE command produces that same error:
> >>>>
> >>>> met-5.1/bin/mode \
> >>>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300
\
> >>>> remap_GOES-13.2015213.1300_75W.nc \
> >>>> East_2015213_1300_4_0_mode_config_file
> >>>>
> >>>> ERROR : parse_vx_grid() -> The forecast and observation grids
do not
> >>>> match:
> >>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059
Lat_LL:
> 21.138
> >>>> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623
Bx:
> >> 899.1870
> >>>> By: 3198.9983 !=
> >>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059
Lat_LL:
> 21.138
> >>>> Lon_LL: -44.200 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623
Bx:
> >>>> 2312.7166 By: -2386.0992
> >>>>
> >>>> I am not sure why it's running successfully on your machine.
Did we
> >>>> perhaps apply a hack to your version of the code to get MODE to
run on
> >> this
> >>>> data?
> >>>>
> >>>> I just forwarded you a message from back in Nov 2015 when we
last
> >>>> discussed this Lambert Conformal CF-compliant NetCDF issue.
> >>>>
> >>>> Also, I am still aware of a small bug in the lambert conformal
grid
> info
> >>>> that I need to fix and post a bugfix.
> >>>>
> >>>> John
> >>>>
> >>>>
> >>>> On Mon, Mar 14, 2016 at 1:22 PM, Sarah Griffin via RT <
> >> met_help at ucar.edu>
> >>>> wrote:
> >>>>
> >>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519
>
> >>>>>
> >>>>> Hi John,
> >>>>>
> >>>>> I am incredibly confused.
> >>>>>
> >>>>> Removing longitude_of_projection_origin makes sense, and I've
done
> >> that.
> >>>>> I've put 2 new files into the incoming directory on the ftp
site:
> >>>>>
GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 and
> >>>>> remap_GOES-13.2015213.1300_75W.nc. MODE can run on these 2
files
> just
> >>>>> fine. I converted the 2 GRIB2 files in
> >>>>> incoming/irap/met_help/griffin_data/ to netcdf files, both x's
range
> >>>>> from 0 to 5394000. The x's of both remapped GOES observation
files
> also
> >>>>> range from 0 to 5394000. Yet, MODE will run on one pair but
not the
> >>>>> other. So could the 'x' variable still be the problem?
> >>>>>
> >>>>> Any ideas?
> >>>>> Sarah
> >>>>>
> >>>>> On 3/14/16 1:26 PM, John Halley Gotway via RT wrote:
> >>>>>> Sarah,
> >>>>>>
> >>>>>> The problem is in the grid specification for the CF-compliant
NetCDF
> >>>>> file you're using. Here's the Projection info from your NetCDF
file:
> >>>>>> int Projection(time) ;
> >>>>>> Projection:grid_mapping_name = "lambert_conformal_conic" ;
> >>>>>> Projection:standard_parallel = 38.5f ;
> >>>>>> Projection:longitude_of_central_meridian = 262.5f ;
> >>>>>> Projection:latitude_of_projection_origin = 21.138f ;
> >>>>>> Projection:longitude_of_projection_origin = -122.72f ;
> >>>>>>
> >>>>>> Compare this with the CF specification:
> >>>>>>
> >>
> http://cfconventions.org/cf-conventions/v1.6.0/cf-
conventions.html#_lambert_conformal
> >>>>>> And notice that "longitude_of_projection_origin" is not
actually a
> >>>>> valid attribute.
> >>>>>> Instead, the CF convention specifies the reference location
at the
> >>>>> latitude of the origin and the longitude of the central
meridian.
> Then
> >> the
> >>>>> "x" and "y" variables are used to specify the location in the
grid of
> >> those
> >>>>> reference longitude and latitude values.
> >>>>>> I've talked to other engineers here and we think this is
pretty
> >>>>> ridiculous. It makes specifying grid information way overly
> >> complicated.
> >>>>> But unfortunately, that's how the spec is written.
> >>>>>> To summarize, you should remove the
"longitude_of_projection_origin"
> >>>>> attribute since it isn't valid or used. And you should change
the
> >> range of
> >>>>> values for x from:
> >>>>>> 0 ... 5394000 to
> >>>>>> -something ... +something
> >>>>>> And the 0 occurs at the x value which coincides with the
longitude
> of
> >>>>> the central meridian.
> >>>>>> Unfortunately, I think I've also discovered a small bug in
the
> Lambert
> >>>>> Conformal grid code, where we've failed to put a longitude
value in
> the
> >>>>> correct range before using it.
> >>>>>> Confused yet?
> >>>>>>
> >>>>>> John
> >>>>> --
> >>>>>
> >>>>>
> >>
>
----------------------------------------------------------------------------
> >>>>> 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: Re: [rt.rap.ucar.edu #75519] MODE projection question
From: Sarah Griffin
Time: Tue Mar 15 11:53:28 2016
Thanks John.
Have you tried converting from grib2 to grib1 using cnvgrib? Did that
run in MODE?
Thanks,
Sarah
On 3/15/16 11:40 AM, John Halley Gotway via RT wrote:
> Sarah,
>
> I was confused as to why the 2015 case is working for you in MET 5.0
but
> not for me. After doing some searching I see that I sent you guys a
hacked
> version of nccf_file.cc back on 7/22/2015. It just hardcodes the
HRRR
> domain. So even though the Lambert Conformal grid isn't set right
in the
> NetCDF file, it doesn't matter. MET ignores that and uses the hard-
coded
> grid definition.
>
> The reason for the trouble you're having now is the slight change to
the
> HRRR grid... i.e. 3 decimal points changed to 6 decimal points.
>
> So the hardcoded HRRR grid definition in nccf_file.cc is no longer
> consistent. This hacking of the code is not a good long term
solution.
> Until we get a better solution, you have a couple of choices.
>
> (1) Edit the hack in nccf_file.cc to match the updated grid
definition and
> recompile MET.
>
> (2) Run your HRRR GRIB2 file through the cnvgrib utility to convert
from
> GRIB2 to GRIB1. That'll change the 6 decimal points back to 3 and
match
> the existing definition.
>
> cnvgrib -g21 \
> GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200
\
> GRIB1.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200
>
> As a side-note, this has actually uncovered 2 problems in MET...
>
> (1) The lambert conformal grid code was failing to rescale a
longitude
> value when it should have (posted met-5.1 bugfix).
>
> (2) The lambert conformal grid equality checking is still
insufficient.
> There are many ways the same grid could be specified... but MET only
says
> they are equal if they're specified in exactly the same way. In you
case,
> GRIB2 specifies the lower-left corner while CF-compliant NetCDF
specifies
> the location of the lower center grid point. MET should be smart
enough to
> recognize these as being the same grids. This is an open issue.
>
> John
>
> On Tue, Mar 15, 2016 at 10:08 AM, Sarah Griffin via RT
<met_help at ucar.edu>
> wrote:
>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
>>
>> Hi John,
>>
>> I did not know wgrib2 -V was an option so thanks for finding the
grid
>> definitions. Seems like that narrows down the issue for why MODE
>> wouldn't run, the HRRR grid changed slightly. I tried updating the
>> remapped observation using:
>>
>> cp remap_GOES-13.2016032.1300_75W.nc remap_GOES_patch.nc
>> ncatted -a latitude_of_projection_origin,Projection,o,f,21.138123
>> remap_GOES_patch.nc
>>
>> to account for the updated center lat, but that did not solve the
issue.
>> Do you have any other thoughts?
>>
>> Thanks,
>> Sarah
>>
>> On 3/15/16 10:42 AM, John Halley Gotway via RT wrote:
>>> Sarah,
>>>
>>> Using wgrib2 with the -V option to look at the grid definition, I
see the
>>> following:
>>>
>>> [johnhg at number5]% wgrib2 -V
>>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300
>>> 1:0:vt=2015080113:top of atmosphere:anl:var discipline=3 center=59
>>> local_table=1 parmcat=192 parm=2:
>>> ndata=1905141:undef=0:mean=284.12:min=186.7:max=302.2
>>> grid_template=30:winds(grid):
>>> Lambert Conformal: (1799 x 1059) input WE:SN output
WE:SN res 8
>>> Lat1 21.138000 Lon1 237.280000 LoV 262.500000
>>> LatD 38.500000 Latin1 38.500000 Latin2 38.500000
>>> LatSP 0.000000 LonSP 0.000000
>>> North Pole (1799 x 1059) Dx 3000.000000 m Dy 3000.000000
m mode
>> 8
>>> [johnhg at number5]% wgrib2 -V
>>> GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200
>>> 1:0:vt=2016020113:top of atmosphere:1 hour fcst:var discipline=3
>> center=59
>>> local_table=1 parmcat=192 parm=2:
>>> ndata=1905141:undef=0:mean=268.375:min=198.78:max=297.32
>>> grid_template=30:winds(grid):
>>> Lambert Conformal: (1799 x 1059) input WE:SN output
WE:SN res 8
>>> Lat1 21.138123 Lon1 237.280472 LoV 262.500000
>>> LatD 38.500000 Latin1 38.500000 Latin2 38.500000
>>> LatSP 0.000000 LonSP 0.000000
>>> North Pole (1799 x 1059) Dx 3000.000000 m Dy 3000.000000
m mode
>> 8
>>> Note the slight difference in the reference lat/lon value. The
2015 file
>>> uses up to 3 decimal points while the 2016 file uses up to 6
decimal
>>> points. While 6 decimal points is fine in GRIB2, only 3 decimal
points
>> (up
>>> to 1/1000th) can be represented in GRIB1.
>>>
>>> Perhaps in 2015 you had GRIB1 data that was being converted to
GRIB2 and
>> in
>>> 2016 you have GRIB2 directly.
>>>
>>> I know that the difference is slight, but MET will flag these
grids as
>>> being different.
>>>
>>> John
>>>
>>>
>>>
>>> On Tue, Mar 15, 2016 at 9:15 AM, Sarah Griffin via RT
<met_help at ucar.edu
>>>
>>> wrote:
>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
>>>>
>>>> Hi John,
>>>>
>>>> Thanks for looking into this. I should mention, I'm running using
>>>> METv5.0. That could be why something worked previously for me and
not
>>>> for you.
>>>>
>>>> It seem like option 2 would probably be our best option, since I
know
>>>> the HRRR grids and remapped GOES grids line up. We are looking to
do
>>>> something in the next month.
>>>>
>>>> I also wanted to add one more tidbit. I said:
>>>> MODE *would* run on
>>>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 &
>>>> remap_GOES-13.2015213.1300_75W.nc
>>>> MODE *would **NOT* run on
>>>> GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200 &
>>>> remap_GOES-13.2016032.1300_75W.nc
>>>>
>>>> I decided to have some fun and discovered:
>>>> MODE *will* run on
>>>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 &
>>>> remap_GOES-13.2016032.1300_75W.nc. I know the times do not match
up, I
>>>> was just curious if it would actually work. I did not change the
>>>> remapped GOES file like to recommend in option (1).
>>>>
>>>> Does this mean there is something that changed with the HRRR
grib2 file
>>>> that it will no longer run in MODE?
>>>>
>>>> Have a great day!
>>>> Sarah
>>>>
>>>>
>>>> On 3/14/16 5:53 PM, John Halley Gotway via RT wrote:
>>>>> Sarah,
>>>>>
>>>>> OK, I just posted this 1 line bugfix for lambert conformal grids
in
>> MET:
>>
http://www.dtcenter.org/met/users/support/known_issues/METv5.1/index.php
>>>>> Just follow the instructions to apply the patch and recompile.
>>>>>
>>>>> Next, not sure why the files worked previously for you but not
for me.
>>>> You
>>>>> have a few options...
>>>>>
>>>>> (1) First, I ran the nco commands listed below to update the
grid
>>>>> definition in the file you sent. Rather than specifying the
lower-left
>>>>> corner as the reference location, we're using x = 899.1693, y =
0 as
>> the
>>>>> reference location. Looking in the Latitude and Longitude
variables, I
>>>> see
>>>>> the point (900, 0) = lat 24.3646, lon -97.5.
>>>>>
>>>>> # Subtract 2697507.9 from all the x values
>>>>> ncap -O -s "x=x-2697507.9" remap_GOES-
13.2016032.1300_75W.nc
>>>>> remap_GOES_patch.nc
>>>>>
>>>>> # Add back on the x variable attributes and update the
reference
>>>>> latitude value
>>>>> ncatted -a long_name,x,o,c,"x coordinate of projection" \
>>>>> -a
standard_name,x,o,c,"projection_x_coordinate" \
>>>>> -a units,x,o,c,"m" \
>>>>> -a grid_spacing,x,o,c,"3000.0000" \
>>>>> -a
>> latitude_of_projection_origin,Projection,o,f,24.3646 \
>>>>> remap_GOES_patch.nc
>>>>>
>>>>> # Plot the result using the patched version of MET
>>>>> plot_data_plane \
>>>>> remap_GOES_patch.nc remap_GOES_patch.ps \
>>>>> 'name = "channel_14_brightness_temperature"; level =
"(*,*)";'
>>>>>
>>>>> I've attached the resulting image. It looks very good. But
when I run
>>>> it
>>>>> through MODE, I still get this error:
>>>>>
>>>>> ERROR : parse_vx_grid() -> The forecast and observation grids
do not
>>>> match:
>>>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
>>>>> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623
Bx:
>>>> 899.1693
>>>>> By: 3198.9984 !=
>>>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
>>>>> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623
Bx:
>>>> 899.1693
>>>>> By: 3198.9975
>>>>>
>>>>> This is a actually a short-coming in MET. MET is doing the
simplest
>>>> check
>>>>> for grid equality, and since these grids we not instantiated
using the
>>>> same
>>>>> info, MET says they're not equal.
>>>>>
>>>>> (2) Second, in our development code we've added a new
interpolation
>>>>> "method" called FORCE. It basically means, don't worry about
checking
>>>> the
>>>>> grid info. Instead, as long as Nx and Ny match, go ahead and
compare
>> the
>>>>> data. I ran the development version of MODE using this config
file
>>>> option:
>>>>> regrid = {
>>>>> to_grid = FCST;
>>>>> method = FORCE;
>>>>> width = 1;
>>>>> vld_thresh = 0.5;
>>>>> }
>>>>>
>>>>> This says, run MODE using the forecast grid definition. And
only check
>>>>> that the fcst and obs grid dimensions match.
>>>>>
>>>>> I could either send you a beta release of the development code
for
>>>> testing
>>>>> or you could wait until the next release.
>>>>>
>>>>> (3) A third option we're considering adding is letting the user
specify
>>>> the
>>>>> grid definition to be used directly in the config file. So if
your
>> data
>>>>> has no grid info... or bad grid info... just specify the desired
grid
>> in
>>>>> the config file. But that option will be new development and
will
>> take a
>>>>> few weeks.
>>>>>
>>>>> What's your timeline? How soon do you need to get this done?
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Mar 14, 2016 at 3:28 PM, John Halley Gotway
<johnhg at ucar.edu>
>>>> wrote:
>>>>>> Sarah,
>>>>>>
>>>>>> Running the following MODE command produces that same error:
>>>>>>
>>>>>> met-5.1/bin/mode \
>>>>>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300
\
>>>>>> remap_GOES-13.2015213.1300_75W.nc \
>>>>>> East_2015213_1300_4_0_mode_config_file
>>>>>>
>>>>>> ERROR : parse_vx_grid() -> The forecast and observation grids
do not
>>>>>> match:
>>>>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059
Lat_LL:
>> 21.138
>>>>>> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623
Bx:
>>>> 899.1870
>>>>>> By: 3198.9983 !=
>>>>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059
Lat_LL:
>> 21.138
>>>>>> Lon_LL: -44.200 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623
Bx:
>>>>>> 2312.7166 By: -2386.0992
>>>>>>
>>>>>> I am not sure why it's running successfully on your machine.
Did we
>>>>>> perhaps apply a hack to your version of the code to get MODE to
run on
>>>> this
>>>>>> data?
>>>>>>
>>>>>> I just forwarded you a message from back in Nov 2015 when we
last
>>>>>> discussed this Lambert Conformal CF-compliant NetCDF issue.
>>>>>>
>>>>>> Also, I am still aware of a small bug in the lambert conformal
grid
>> info
>>>>>> that I need to fix and post a bugfix.
>>>>>>
>>>>>> John
>>>>>>
>>>>>>
>>>>>> On Mon, Mar 14, 2016 at 1:22 PM, Sarah Griffin via RT <
>>>> met_help at ucar.edu>
>>>>>> wrote:
>>>>>>
>>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519
>
>>>>>>>
>>>>>>> Hi John,
>>>>>>>
>>>>>>> I am incredibly confused.
>>>>>>>
>>>>>>> Removing longitude_of_projection_origin makes sense, and I've
done
>>>> that.
>>>>>>> I've put 2 new files into the incoming directory on the ftp
site:
>>>>>>>
GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 and
>>>>>>> remap_GOES-13.2015213.1300_75W.nc. MODE can run on these 2
files
>> just
>>>>>>> fine. I converted the 2 GRIB2 files in
>>>>>>> incoming/irap/met_help/griffin_data/ to netcdf files, both x's
range
>>>>>>> from 0 to 5394000. The x's of both remapped GOES observation
files
>> also
>>>>>>> range from 0 to 5394000. Yet, MODE will run on one pair but
not the
>>>>>>> other. So could the 'x' variable still be the problem?
>>>>>>>
>>>>>>> Any ideas?
>>>>>>> Sarah
>>>>>>>
>>>>>>> On 3/14/16 1:26 PM, John Halley Gotway via RT wrote:
>>>>>>>> Sarah,
>>>>>>>>
>>>>>>>> The problem is in the grid specification for the CF-compliant
NetCDF
>>>>>>> file you're using. Here's the Projection info from your NetCDF
file:
>>>>>>>> int Projection(time) ;
>>>>>>>> Projection:grid_mapping_name = "lambert_conformal_conic" ;
>>>>>>>> Projection:standard_parallel = 38.5f ;
>>>>>>>> Projection:longitude_of_central_meridian = 262.5f ;
>>>>>>>> Projection:latitude_of_projection_origin = 21.138f ;
>>>>>>>> Projection:longitude_of_projection_origin = -122.72f ;
>>>>>>>>
>>>>>>>> Compare this with the CF specification:
>>>>>>>>
>> http://cfconventions.org/cf-conventions/v1.6.0/cf-
conventions.html#_lambert_conformal
>>>>>>>> And notice that "longitude_of_projection_origin" is not
actually a
>>>>>>> valid attribute.
>>>>>>>> Instead, the CF convention specifies the reference location
at the
>>>>>>> latitude of the origin and the longitude of the central
meridian.
>> Then
>>>> the
>>>>>>> "x" and "y" variables are used to specify the location in the
grid of
>>>> those
>>>>>>> reference longitude and latitude values.
>>>>>>>> I've talked to other engineers here and we think this is
pretty
>>>>>>> ridiculous. It makes specifying grid information way overly
>>>> complicated.
>>>>>>> But unfortunately, that's how the spec is written.
>>>>>>>> To summarize, you should remove the
"longitude_of_projection_origin"
>>>>>>> attribute since it isn't valid or used. And you should change
the
>>>> range of
>>>>>>> values for x from:
>>>>>>>> 0 ... 5394000 to
>>>>>>>> -something ... +something
>>>>>>>> And the 0 occurs at the x value which coincides with the
longitude
>> of
>>>>>>> the central meridian.
>>>>>>>> Unfortunately, I think I've also discovered a small bug in
the
>> Lambert
>>>>>>> Conformal grid code, where we've failed to put a longitude
value in
>> the
>>>>>>> correct range before using it.
>>>>>>>> Confused yet?
>>>>>>>>
>>>>>>>> John
>>>>>>> --
>>>>>>>
>>>>>>>
>>
----------------------------------------------------------------------------
>>>>>>> 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
>>
>>
----------------------------------------------------------------------------
>>
>>
>>
--
----------------------------------------------------------------------------
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 #75519] MODE projection question
From: Sarah Griffin
Time: Wed Mar 16 08:02:14 2016
Hi John,
I did a bit more (accidental) digging.
For the MODE file that worked, I typed:
./wgrib2 -ijlat 10 10
GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201508011300
and got
1:0:(10,10),lon=237.453103,lat=21.424798,val=289.2
so, does this mean the HRRR file that worked is also GRIB2 and doesn't
need to be converted to GRIB1 to work? I've tried downloading cnvgrib
but can't get it to compile.
I updated the nccf_file.cc to read:
data.lat_pin = 21.138123;
data.lon_pin = 122.71953;
and recompiled MET. However, that also did not work.
Do you have any ideas?
Have a great day!
Sarah
On 3/15/16 11:40 AM, John Halley Gotway via RT wrote:
> Sarah,
>
> I was confused as to why the 2015 case is working for you in MET 5.0
but
> not for me. After doing some searching I see that I sent you guys a
hacked
> version of nccf_file.cc back on 7/22/2015. It just hardcodes the
HRRR
> domain. So even though the Lambert Conformal grid isn't set right
in the
> NetCDF file, it doesn't matter. MET ignores that and uses the hard-
coded
> grid definition.
>
> The reason for the trouble you're having now is the slight change to
the
> HRRR grid... i.e. 3 decimal points changed to 6 decimal points.
>
> So the hardcoded HRRR grid definition in nccf_file.cc is no longer
> consistent. This hacking of the code is not a good long term
solution.
> Until we get a better solution, you have a couple of choices.
>
> (1) Edit the hack in nccf_file.cc to match the updated grid
definition and
> recompile MET.
>
> (2) Run your HRRR GRIB2 file through the cnvgrib utility to convert
from
> GRIB2 to GRIB1. That'll change the 6 decimal points back to 3 and
match
> the existing definition.
>
> cnvgrib -g21 \
> GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200
\
> GRIB1.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200
>
> As a side-note, this has actually uncovered 2 problems in MET...
>
> (1) The lambert conformal grid code was failing to rescale a
longitude
> value when it should have (posted met-5.1 bugfix).
>
> (2) The lambert conformal grid equality checking is still
insufficient.
> There are many ways the same grid could be specified... but MET only
says
> they are equal if they're specified in exactly the same way. In you
case,
> GRIB2 specifies the lower-left corner while CF-compliant NetCDF
specifies
> the location of the lower center grid point. MET should be smart
enough to
> recognize these as being the same grids. This is an open issue.
>
> John
>
> On Tue, Mar 15, 2016 at 10:08 AM, Sarah Griffin via RT
<met_help at ucar.edu>
> wrote:
>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
>>
>> Hi John,
>>
>> I did not know wgrib2 -V was an option so thanks for finding the
grid
>> definitions. Seems like that narrows down the issue for why MODE
>> wouldn't run, the HRRR grid changed slightly. I tried updating the
>> remapped observation using:
>>
>> cp remap_GOES-13.2016032.1300_75W.nc remap_GOES_patch.nc
>> ncatted -a latitude_of_projection_origin,Projection,o,f,21.138123
>> remap_GOES_patch.nc
>>
>> to account for the updated center lat, but that did not solve the
issue.
>> Do you have any other thoughts?
>>
>> Thanks,
>> Sarah
>>
>> On 3/15/16 10:42 AM, John Halley Gotway via RT wrote:
>>> Sarah,
>>>
>>> Using wgrib2 with the -V option to look at the grid definition, I
see the
>>> following:
>>>
>>> [johnhg at number5]% wgrib2 -V
>>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300
>>> 1:0:vt=2015080113:top of atmosphere:anl:var discipline=3 center=59
>>> local_table=1 parmcat=192 parm=2:
>>> ndata=1905141:undef=0:mean=284.12:min=186.7:max=302.2
>>> grid_template=30:winds(grid):
>>> Lambert Conformal: (1799 x 1059) input WE:SN output
WE:SN res 8
>>> Lat1 21.138000 Lon1 237.280000 LoV 262.500000
>>> LatD 38.500000 Latin1 38.500000 Latin2 38.500000
>>> LatSP 0.000000 LonSP 0.000000
>>> North Pole (1799 x 1059) Dx 3000.000000 m Dy 3000.000000
m mode
>> 8
>>> [johnhg at number5]% wgrib2 -V
>>> GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200
>>> 1:0:vt=2016020113:top of atmosphere:1 hour fcst:var discipline=3
>> center=59
>>> local_table=1 parmcat=192 parm=2:
>>> ndata=1905141:undef=0:mean=268.375:min=198.78:max=297.32
>>> grid_template=30:winds(grid):
>>> Lambert Conformal: (1799 x 1059) input WE:SN output
WE:SN res 8
>>> Lat1 21.138123 Lon1 237.280472 LoV 262.500000
>>> LatD 38.500000 Latin1 38.500000 Latin2 38.500000
>>> LatSP 0.000000 LonSP 0.000000
>>> North Pole (1799 x 1059) Dx 3000.000000 m Dy 3000.000000
m mode
>> 8
>>> Note the slight difference in the reference lat/lon value. The
2015 file
>>> uses up to 3 decimal points while the 2016 file uses up to 6
decimal
>>> points. While 6 decimal points is fine in GRIB2, only 3 decimal
points
>> (up
>>> to 1/1000th) can be represented in GRIB1.
>>>
>>> Perhaps in 2015 you had GRIB1 data that was being converted to
GRIB2 and
>> in
>>> 2016 you have GRIB2 directly.
>>>
>>> I know that the difference is slight, but MET will flag these
grids as
>>> being different.
>>>
>>> John
>>>
>>>
>>>
>>> On Tue, Mar 15, 2016 at 9:15 AM, Sarah Griffin via RT
<met_help at ucar.edu
>>>
>>> wrote:
>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
>>>>
>>>> Hi John,
>>>>
>>>> Thanks for looking into this. I should mention, I'm running using
>>>> METv5.0. That could be why something worked previously for me and
not
>>>> for you.
>>>>
>>>> It seem like option 2 would probably be our best option, since I
know
>>>> the HRRR grids and remapped GOES grids line up. We are looking to
do
>>>> something in the next month.
>>>>
>>>> I also wanted to add one more tidbit. I said:
>>>> MODE *would* run on
>>>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 &
>>>> remap_GOES-13.2015213.1300_75W.nc
>>>> MODE *would **NOT* run on
>>>> GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200 &
>>>> remap_GOES-13.2016032.1300_75W.nc
>>>>
>>>> I decided to have some fun and discovered:
>>>> MODE *will* run on
>>>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 &
>>>> remap_GOES-13.2016032.1300_75W.nc. I know the times do not match
up, I
>>>> was just curious if it would actually work. I did not change the
>>>> remapped GOES file like to recommend in option (1).
>>>>
>>>> Does this mean there is something that changed with the HRRR
grib2 file
>>>> that it will no longer run in MODE?
>>>>
>>>> Have a great day!
>>>> Sarah
>>>>
>>>>
>>>> On 3/14/16 5:53 PM, John Halley Gotway via RT wrote:
>>>>> Sarah,
>>>>>
>>>>> OK, I just posted this 1 line bugfix for lambert conformal grids
in
>> MET:
>>
http://www.dtcenter.org/met/users/support/known_issues/METv5.1/index.php
>>>>> Just follow the instructions to apply the patch and recompile.
>>>>>
>>>>> Next, not sure why the files worked previously for you but not
for me.
>>>> You
>>>>> have a few options...
>>>>>
>>>>> (1) First, I ran the nco commands listed below to update the
grid
>>>>> definition in the file you sent. Rather than specifying the
lower-left
>>>>> corner as the reference location, we're using x = 899.1693, y =
0 as
>> the
>>>>> reference location. Looking in the Latitude and Longitude
variables, I
>>>> see
>>>>> the point (900, 0) = lat 24.3646, lon -97.5.
>>>>>
>>>>> # Subtract 2697507.9 from all the x values
>>>>> ncap -O -s "x=x-2697507.9" remap_GOES-
13.2016032.1300_75W.nc
>>>>> remap_GOES_patch.nc
>>>>>
>>>>> # Add back on the x variable attributes and update the
reference
>>>>> latitude value
>>>>> ncatted -a long_name,x,o,c,"x coordinate of projection" \
>>>>> -a
standard_name,x,o,c,"projection_x_coordinate" \
>>>>> -a units,x,o,c,"m" \
>>>>> -a grid_spacing,x,o,c,"3000.0000" \
>>>>> -a
>> latitude_of_projection_origin,Projection,o,f,24.3646 \
>>>>> remap_GOES_patch.nc
>>>>>
>>>>> # Plot the result using the patched version of MET
>>>>> plot_data_plane \
>>>>> remap_GOES_patch.nc remap_GOES_patch.ps \
>>>>> 'name = "channel_14_brightness_temperature"; level =
"(*,*)";'
>>>>>
>>>>> I've attached the resulting image. It looks very good. But
when I run
>>>> it
>>>>> through MODE, I still get this error:
>>>>>
>>>>> ERROR : parse_vx_grid() -> The forecast and observation grids
do not
>>>> match:
>>>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
>>>>> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623
Bx:
>>>> 899.1693
>>>>> By: 3198.9984 !=
>>>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059 Lat_LL:
21.138
>>>>> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623
Bx:
>>>> 899.1693
>>>>> By: 3198.9975
>>>>>
>>>>> This is a actually a short-coming in MET. MET is doing the
simplest
>>>> check
>>>>> for grid equality, and since these grids we not instantiated
using the
>>>> same
>>>>> info, MET says they're not equal.
>>>>>
>>>>> (2) Second, in our development code we've added a new
interpolation
>>>>> "method" called FORCE. It basically means, don't worry about
checking
>>>> the
>>>>> grid info. Instead, as long as Nx and Ny match, go ahead and
compare
>> the
>>>>> data. I ran the development version of MODE using this config
file
>>>> option:
>>>>> regrid = {
>>>>> to_grid = FCST;
>>>>> method = FORCE;
>>>>> width = 1;
>>>>> vld_thresh = 0.5;
>>>>> }
>>>>>
>>>>> This says, run MODE using the forecast grid definition. And
only check
>>>>> that the fcst and obs grid dimensions match.
>>>>>
>>>>> I could either send you a beta release of the development code
for
>>>> testing
>>>>> or you could wait until the next release.
>>>>>
>>>>> (3) A third option we're considering adding is letting the user
specify
>>>> the
>>>>> grid definition to be used directly in the config file. So if
your
>> data
>>>>> has no grid info... or bad grid info... just specify the desired
grid
>> in
>>>>> the config file. But that option will be new development and
will
>> take a
>>>>> few weeks.
>>>>>
>>>>> What's your timeline? How soon do you need to get this done?
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Mar 14, 2016 at 3:28 PM, John Halley Gotway
<johnhg at ucar.edu>
>>>> wrote:
>>>>>> Sarah,
>>>>>>
>>>>>> Running the following MODE command produces that same error:
>>>>>>
>>>>>> met-5.1/bin/mode \
>>>>>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300
\
>>>>>> remap_GOES-13.2015213.1300_75W.nc \
>>>>>> East_2015213_1300_4_0_mode_config_file
>>>>>>
>>>>>> ERROR : parse_vx_grid() -> The forecast and observation grids
do not
>>>>>> match:
>>>>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059
Lat_LL:
>> 21.138
>>>>>> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623
Bx:
>>>> 899.1870
>>>>>> By: 3198.9983 !=
>>>>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059
Lat_LL:
>> 21.138
>>>>>> Lon_LL: -44.200 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623
Bx:
>>>>>> 2312.7166 By: -2386.0992
>>>>>>
>>>>>> I am not sure why it's running successfully on your machine.
Did we
>>>>>> perhaps apply a hack to your version of the code to get MODE to
run on
>>>> this
>>>>>> data?
>>>>>>
>>>>>> I just forwarded you a message from back in Nov 2015 when we
last
>>>>>> discussed this Lambert Conformal CF-compliant NetCDF issue.
>>>>>>
>>>>>> Also, I am still aware of a small bug in the lambert conformal
grid
>> info
>>>>>> that I need to fix and post a bugfix.
>>>>>>
>>>>>> John
>>>>>>
>>>>>>
>>>>>> On Mon, Mar 14, 2016 at 1:22 PM, Sarah Griffin via RT <
>>>> met_help at ucar.edu>
>>>>>> wrote:
>>>>>>
>>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519
>
>>>>>>>
>>>>>>> Hi John,
>>>>>>>
>>>>>>> I am incredibly confused.
>>>>>>>
>>>>>>> Removing longitude_of_projection_origin makes sense, and I've
done
>>>> that.
>>>>>>> I've put 2 new files into the incoming directory on the ftp
site:
>>>>>>>
GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 and
>>>>>>> remap_GOES-13.2015213.1300_75W.nc. MODE can run on these 2
files
>> just
>>>>>>> fine. I converted the 2 GRIB2 files in
>>>>>>> incoming/irap/met_help/griffin_data/ to netcdf files, both x's
range
>>>>>>> from 0 to 5394000. The x's of both remapped GOES observation
files
>> also
>>>>>>> range from 0 to 5394000. Yet, MODE will run on one pair but
not the
>>>>>>> other. So could the 'x' variable still be the problem?
>>>>>>>
>>>>>>> Any ideas?
>>>>>>> Sarah
>>>>>>>
>>>>>>> On 3/14/16 1:26 PM, John Halley Gotway via RT wrote:
>>>>>>>> Sarah,
>>>>>>>>
>>>>>>>> The problem is in the grid specification for the CF-compliant
NetCDF
>>>>>>> file you're using. Here's the Projection info from your NetCDF
file:
>>>>>>>> int Projection(time) ;
>>>>>>>> Projection:grid_mapping_name = "lambert_conformal_conic" ;
>>>>>>>> Projection:standard_parallel = 38.5f ;
>>>>>>>> Projection:longitude_of_central_meridian = 262.5f ;
>>>>>>>> Projection:latitude_of_projection_origin = 21.138f ;
>>>>>>>> Projection:longitude_of_projection_origin = -122.72f ;
>>>>>>>>
>>>>>>>> Compare this with the CF specification:
>>>>>>>>
>> http://cfconventions.org/cf-conventions/v1.6.0/cf-
conventions.html#_lambert_conformal
>>>>>>>> And notice that "longitude_of_projection_origin" is not
actually a
>>>>>>> valid attribute.
>>>>>>>> Instead, the CF convention specifies the reference location
at the
>>>>>>> latitude of the origin and the longitude of the central
meridian.
>> Then
>>>> the
>>>>>>> "x" and "y" variables are used to specify the location in the
grid of
>>>> those
>>>>>>> reference longitude and latitude values.
>>>>>>>> I've talked to other engineers here and we think this is
pretty
>>>>>>> ridiculous. It makes specifying grid information way overly
>>>> complicated.
>>>>>>> But unfortunately, that's how the spec is written.
>>>>>>>> To summarize, you should remove the
"longitude_of_projection_origin"
>>>>>>> attribute since it isn't valid or used. And you should change
the
>>>> range of
>>>>>>> values for x from:
>>>>>>>> 0 ... 5394000 to
>>>>>>>> -something ... +something
>>>>>>>> And the 0 occurs at the x value which coincides with the
longitude
>> of
>>>>>>> the central meridian.
>>>>>>>> Unfortunately, I think I've also discovered a small bug in
the
>> Lambert
>>>>>>> Conformal grid code, where we've failed to put a longitude
value in
>> the
>>>>>>> correct range before using it.
>>>>>>>> Confused yet?
>>>>>>>>
>>>>>>>> John
>>>>>>> --
>>>>>>>
>>>>>>>
>>
----------------------------------------------------------------------------
>>>>>>> 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
>>
>>
----------------------------------------------------------------------------
>>
>>
>>
--
----------------------------------------------------------------------------
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: MODE projection question
From: John Halley Gotway
Time: Wed Mar 16 09:41:13 2016
Sarah,
That's a cool option in wgrib2. I wasn't aware of that. We can use
that
to demonstrate the (very slight) difference in the grids you sent me.
Look
at the lat/lon of the first point in each file (i.e. i=1, j=1):
[johnhg at number5]% wgrib2 -ijlat 1 1
GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300
1:0:(1,1),lon=237.280000,lat=21.138000,val=289.4
[johnhg at number5]% wgrib2 -ijlat 1 1
GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200
1:0:(1,1),lon=237.280472,lat=21.138123,val=282.84
Notice the slight difference? 237.28 changes to 237.280472 and 21.138
changes to 21.138123.
I thought of another method for getting the 2016 data back on to the
"old"
HRRR grid. You can use wgrib2 to "regrid" GRIB2 data.
I followed these instructions:
http://www.cpc.ncep.noaa.gov/products/wesley/wgrib2/index.html
And ran the following wgrib2 command:
wgrib2 \
GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200 \
-new_grid lambert:262.5:38.5 237.28:1799:3000 21.138:1059:3000 \
GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200_FIX_GRID
The output file should now be on the "old" grid.
It possible that your build of wgrib2 was not compiled with support
for
regridding. If that's the case, getting cnvgrib compiled is a lot
easier
than recompiling wgrib2 with support for regridding!
To summarize, your options are:
(1) Compile cnvgrib and use it to truncate the newer HRRR grid
definitions
to the older one.
(2) Use wgrib2 to regrid the newer HRRR grid definition to the older
one.
(3) Modify the nccf_file.cc patch and recompile MET to use the newer
HRRR
grid def. That'll make MET work with the newer HRRR files but not the
older ones. Here are the values you should be using:
data.lat_pin = 21.138123;
data.lon_pin = 122.719528;
Be sure to do a "make clean" followed by a "make install" for MET.
Thanks,
John
On Wed, Mar 16, 2016 at 8:02 AM, Sarah Griffin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
>
> Hi John,
>
> I did a bit more (accidental) digging.
>
> For the MODE file that worked, I typed:
> ./wgrib2 -ijlat 10 10
> GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201508011300
> and got
> 1:0:(10,10),lon=237.453103,lat=21.424798,val=289.2
> so, does this mean the HRRR file that worked is also GRIB2 and
doesn't
> need to be converted to GRIB1 to work? I've tried downloading
cnvgrib
> but can't get it to compile.
>
> I updated the nccf_file.cc to read:
> data.lat_pin = 21.138123;
> data.lon_pin = 122.71953;
> and recompiled MET. However, that also did not work.
>
> Do you have any ideas?
>
> Have a great day!
> Sarah
>
> On 3/15/16 11:40 AM, John Halley Gotway via RT wrote:
> > Sarah,
> >
> > I was confused as to why the 2015 case is working for you in MET
5.0 but
> > not for me. After doing some searching I see that I sent you guys
a
> hacked
> > version of nccf_file.cc back on 7/22/2015. It just hardcodes the
HRRR
> > domain. So even though the Lambert Conformal grid isn't set right
in the
> > NetCDF file, it doesn't matter. MET ignores that and uses the
hard-coded
> > grid definition.
> >
> > The reason for the trouble you're having now is the slight change
to the
> > HRRR grid... i.e. 3 decimal points changed to 6 decimal points.
> >
> > So the hardcoded HRRR grid definition in nccf_file.cc is no longer
> > consistent. This hacking of the code is not a good long term
solution.
> > Until we get a better solution, you have a couple of choices.
> >
> > (1) Edit the hack in nccf_file.cc to match the updated grid
definition
> and
> > recompile MET.
> >
> > (2) Run your HRRR GRIB2 file through the cnvgrib utility to
convert from
> > GRIB2 to GRIB1. That'll change the 6 decimal points back to 3 and
match
> > the existing definition.
> >
> > cnvgrib -g21 \
> >
GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200 \
> >
GRIB1.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200
> >
> > As a side-note, this has actually uncovered 2 problems in MET...
> >
> > (1) The lambert conformal grid code was failing to rescale a
longitude
> > value when it should have (posted met-5.1 bugfix).
> >
> > (2) The lambert conformal grid equality checking is still
insufficient.
> > There are many ways the same grid could be specified... but MET
only says
> > they are equal if they're specified in exactly the same way. In
you
> case,
> > GRIB2 specifies the lower-left corner while CF-compliant NetCDF
specifies
> > the location of the lower center grid point. MET should be smart
enough
> to
> > recognize these as being the same grids. This is an open issue.
> >
> > John
> >
> > On Tue, Mar 15, 2016 at 10:08 AM, Sarah Griffin via RT <
> met_help at ucar.edu>
> > wrote:
> >
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
> >>
> >> Hi John,
> >>
> >> I did not know wgrib2 -V was an option so thanks for finding the
grid
> >> definitions. Seems like that narrows down the issue for why MODE
> >> wouldn't run, the HRRR grid changed slightly. I tried updating
the
> >> remapped observation using:
> >>
> >> cp remap_GOES-13.2016032.1300_75W.nc remap_GOES_patch.nc
> >> ncatted -a latitude_of_projection_origin,Projection,o,f,21.138123
> >> remap_GOES_patch.nc
> >>
> >> to account for the updated center lat, but that did not solve the
issue.
> >> Do you have any other thoughts?
> >>
> >> Thanks,
> >> Sarah
> >>
> >> On 3/15/16 10:42 AM, John Halley Gotway via RT wrote:
> >>> Sarah,
> >>>
> >>> Using wgrib2 with the -V option to look at the grid definition,
I see
> the
> >>> following:
> >>>
> >>> [johnhg at number5]% wgrib2 -V
> >>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300
> >>> 1:0:vt=2015080113:top of atmosphere:anl:var discipline=3
center=59
> >>> local_table=1 parmcat=192 parm=2:
> >>> ndata=1905141:undef=0:mean=284.12:min=186.7:max=302.2
> >>> grid_template=30:winds(grid):
> >>> Lambert Conformal: (1799 x 1059) input WE:SN output
WE:SN
> res 8
> >>> Lat1 21.138000 Lon1 237.280000 LoV 262.500000
> >>> LatD 38.500000 Latin1 38.500000 Latin2 38.500000
> >>> LatSP 0.000000 LonSP 0.000000
> >>> North Pole (1799 x 1059) Dx 3000.000000 m Dy
3000.000000 m
> mode
> >> 8
> >>> [johnhg at number5]% wgrib2 -V
> >>> GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200
> >>> 1:0:vt=2016020113:top of atmosphere:1 hour fcst:var discipline=3
> >> center=59
> >>> local_table=1 parmcat=192 parm=2:
> >>> ndata=1905141:undef=0:mean=268.375:min=198.78:max=297.32
> >>> grid_template=30:winds(grid):
> >>> Lambert Conformal: (1799 x 1059) input WE:SN output
WE:SN
> res 8
> >>> Lat1 21.138123 Lon1 237.280472 LoV 262.500000
> >>> LatD 38.500000 Latin1 38.500000 Latin2 38.500000
> >>> LatSP 0.000000 LonSP 0.000000
> >>> North Pole (1799 x 1059) Dx 3000.000000 m Dy
3000.000000 m
> mode
> >> 8
> >>> Note the slight difference in the reference lat/lon value. The
2015
> file
> >>> uses up to 3 decimal points while the 2016 file uses up to 6
decimal
> >>> points. While 6 decimal points is fine in GRIB2, only 3 decimal
points
> >> (up
> >>> to 1/1000th) can be represented in GRIB1.
> >>>
> >>> Perhaps in 2015 you had GRIB1 data that was being converted to
GRIB2
> and
> >> in
> >>> 2016 you have GRIB2 directly.
> >>>
> >>> I know that the difference is slight, but MET will flag these
grids as
> >>> being different.
> >>>
> >>> John
> >>>
> >>>
> >>>
> >>> On Tue, Mar 15, 2016 at 9:15 AM, Sarah Griffin via RT <
> met_help at ucar.edu
> >>>
> >>> wrote:
> >>>
> >>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
> >>>>
> >>>> Hi John,
> >>>>
> >>>> Thanks for looking into this. I should mention, I'm running
using
> >>>> METv5.0. That could be why something worked previously for me
and not
> >>>> for you.
> >>>>
> >>>> It seem like option 2 would probably be our best option, since
I know
> >>>> the HRRR grids and remapped GOES grids line up. We are looking
to do
> >>>> something in the next month.
> >>>>
> >>>> I also wanted to add one more tidbit. I said:
> >>>> MODE *would* run on
> >>>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300
&
> >>>> remap_GOES-13.2015213.1300_75W.nc
> >>>> MODE *would **NOT* run on
> >>>> GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200
&
> >>>> remap_GOES-13.2016032.1300_75W.nc
> >>>>
> >>>> I decided to have some fun and discovered:
> >>>> MODE *will* run on
> >>>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300
&
> >>>> remap_GOES-13.2016032.1300_75W.nc. I know the times do not
match up,
> I
> >>>> was just curious if it would actually work. I did not change
the
> >>>> remapped GOES file like to recommend in option (1).
> >>>>
> >>>> Does this mean there is something that changed with the HRRR
grib2
> file
> >>>> that it will no longer run in MODE?
> >>>>
> >>>> Have a great day!
> >>>> Sarah
> >>>>
> >>>>
> >>>> On 3/14/16 5:53 PM, John Halley Gotway via RT wrote:
> >>>>> Sarah,
> >>>>>
> >>>>> OK, I just posted this 1 line bugfix for lambert conformal
grids in
> >> MET:
> >>
>
http://www.dtcenter.org/met/users/support/known_issues/METv5.1/index.php
> >>>>> Just follow the instructions to apply the patch and recompile.
> >>>>>
> >>>>> Next, not sure why the files worked previously for you but not
for
> me.
> >>>> You
> >>>>> have a few options...
> >>>>>
> >>>>> (1) First, I ran the nco commands listed below to update the
grid
> >>>>> definition in the file you sent. Rather than specifying the
> lower-left
> >>>>> corner as the reference location, we're using x = 899.1693, y
= 0 as
> >> the
> >>>>> reference location. Looking in the Latitude and Longitude
> variables, I
> >>>> see
> >>>>> the point (900, 0) = lat 24.3646, lon -97.5.
> >>>>>
> >>>>> # Subtract 2697507.9 from all the x values
> >>>>> ncap -O -s "x=x-2697507.9" remap_GOES-
13.2016032.1300_75W.nc
> >>>>> remap_GOES_patch.nc
> >>>>>
> >>>>> # Add back on the x variable attributes and update the
> reference
> >>>>> latitude value
> >>>>> ncatted -a long_name,x,o,c,"x coordinate of projection"
\
> >>>>> -a
standard_name,x,o,c,"projection_x_coordinate" \
> >>>>> -a units,x,o,c,"m" \
> >>>>> -a grid_spacing,x,o,c,"3000.0000" \
> >>>>> -a
> >> latitude_of_projection_origin,Projection,o,f,24.3646 \
> >>>>> remap_GOES_patch.nc
> >>>>>
> >>>>> # Plot the result using the patched version of MET
> >>>>> plot_data_plane \
> >>>>> remap_GOES_patch.nc remap_GOES_patch.ps \
> >>>>> 'name = "channel_14_brightness_temperature"; level =
> "(*,*)";'
> >>>>>
> >>>>> I've attached the resulting image. It looks very good. But
when I
> run
> >>>> it
> >>>>> through MODE, I still get this error:
> >>>>>
> >>>>> ERROR : parse_vx_grid() -> The forecast and observation grids
do not
> >>>> match:
> >>>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059
Lat_LL:
> 21.138
> >>>>> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623
Bx:
> >>>> 899.1693
> >>>>> By: 3198.9984 !=
> >>>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059
Lat_LL:
> 21.138
> >>>>> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623
Bx:
> >>>> 899.1693
> >>>>> By: 3198.9975
> >>>>>
> >>>>> This is a actually a short-coming in MET. MET is doing the
simplest
> >>>> check
> >>>>> for grid equality, and since these grids we not instantiated
using
> the
> >>>> same
> >>>>> info, MET says they're not equal.
> >>>>>
> >>>>> (2) Second, in our development code we've added a new
interpolation
> >>>>> "method" called FORCE. It basically means, don't worry about
> checking
> >>>> the
> >>>>> grid info. Instead, as long as Nx and Ny match, go ahead and
compare
> >> the
> >>>>> data. I ran the development version of MODE using this config
file
> >>>> option:
> >>>>> regrid = {
> >>>>> to_grid = FCST;
> >>>>> method = FORCE;
> >>>>> width = 1;
> >>>>> vld_thresh = 0.5;
> >>>>> }
> >>>>>
> >>>>> This says, run MODE using the forecast grid definition. And
only
> check
> >>>>> that the fcst and obs grid dimensions match.
> >>>>>
> >>>>> I could either send you a beta release of the development code
for
> >>>> testing
> >>>>> or you could wait until the next release.
> >>>>>
> >>>>> (3) A third option we're considering adding is letting the
user
> specify
> >>>> the
> >>>>> grid definition to be used directly in the config file. So if
your
> >> data
> >>>>> has no grid info... or bad grid info... just specify the
desired grid
> >> in
> >>>>> the config file. But that option will be new development and
will
> >> take a
> >>>>> few weeks.
> >>>>>
> >>>>> What's your timeline? How soon do you need to get this done?
> >>>>>
> >>>>> Thanks,
> >>>>> John
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mon, Mar 14, 2016 at 3:28 PM, John Halley Gotway
<johnhg at ucar.edu
> >
> >>>> wrote:
> >>>>>> Sarah,
> >>>>>>
> >>>>>> Running the following MODE command produces that same error:
> >>>>>>
> >>>>>> met-5.1/bin/mode \
> >>>>>>
GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 \
> >>>>>> remap_GOES-13.2015213.1300_75W.nc \
> >>>>>> East_2015213_1300_4_0_mode_config_file
> >>>>>>
> >>>>>> ERROR : parse_vx_grid() -> The forecast and observation
grids do
> not
> >>>>>> match:
> >>>>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059
Lat_LL:
> >> 21.138
> >>>>>> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone:
0.623 Bx:
> >>>> 899.1870
> >>>>>> By: 3198.9983 !=
> >>>>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059
Lat_LL:
> >> 21.138
> >>>>>> Lon_LL: -44.200 Lon_orient: 97.500 Alpha: 4203.494 Cone:
0.623 Bx:
> >>>>>> 2312.7166 By: -2386.0992
> >>>>>>
> >>>>>> I am not sure why it's running successfully on your machine.
Did we
> >>>>>> perhaps apply a hack to your version of the code to get MODE
to run
> on
> >>>> this
> >>>>>> data?
> >>>>>>
> >>>>>> I just forwarded you a message from back in Nov 2015 when we
last
> >>>>>> discussed this Lambert Conformal CF-compliant NetCDF issue.
> >>>>>>
> >>>>>> Also, I am still aware of a small bug in the lambert
conformal grid
> >> info
> >>>>>> that I need to fix and post a bugfix.
> >>>>>>
> >>>>>> John
> >>>>>>
> >>>>>>
> >>>>>> On Mon, Mar 14, 2016 at 1:22 PM, Sarah Griffin via RT <
> >>>> met_help at ucar.edu>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
> >>>>>>>
> >>>>>>> Hi John,
> >>>>>>>
> >>>>>>> I am incredibly confused.
> >>>>>>>
> >>>>>>> Removing longitude_of_projection_origin makes sense, and
I've done
> >>>> that.
> >>>>>>> I've put 2 new files into the incoming directory on the ftp
site:
> >>>>>>>
GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 and
> >>>>>>> remap_GOES-13.2015213.1300_75W.nc. MODE can run on these 2
files
> >> just
> >>>>>>> fine. I converted the 2 GRIB2 files in
> >>>>>>> incoming/irap/met_help/griffin_data/ to netcdf files, both
x's
> range
> >>>>>>> from 0 to 5394000. The x's of both remapped GOES observation
files
> >> also
> >>>>>>> range from 0 to 5394000. Yet, MODE will run on one pair but
not the
> >>>>>>> other. So could the 'x' variable still be the problem?
> >>>>>>>
> >>>>>>> Any ideas?
> >>>>>>> Sarah
> >>>>>>>
> >>>>>>> On 3/14/16 1:26 PM, John Halley Gotway via RT wrote:
> >>>>>>>> Sarah,
> >>>>>>>>
> >>>>>>>> The problem is in the grid specification for the CF-
compliant
> NetCDF
> >>>>>>> file you're using. Here's the Projection info from your
NetCDF
> file:
> >>>>>>>> int Projection(time) ;
> >>>>>>>> Projection:grid_mapping_name = "lambert_conformal_conic" ;
> >>>>>>>> Projection:standard_parallel = 38.5f ;
> >>>>>>>> Projection:longitude_of_central_meridian = 262.5f ;
> >>>>>>>> Projection:latitude_of_projection_origin = 21.138f ;
> >>>>>>>> Projection:longitude_of_projection_origin = -122.72f ;
> >>>>>>>>
> >>>>>>>> Compare this with the CF specification:
> >>>>>>>>
> >>
> http://cfconventions.org/cf-conventions/v1.6.0/cf-
conventions.html#_lambert_conformal
> >>>>>>>> And notice that "longitude_of_projection_origin" is not
actually a
> >>>>>>> valid attribute.
> >>>>>>>> Instead, the CF convention specifies the reference location
at the
> >>>>>>> latitude of the origin and the longitude of the central
meridian.
> >> Then
> >>>> the
> >>>>>>> "x" and "y" variables are used to specify the location in
the grid
> of
> >>>> those
> >>>>>>> reference longitude and latitude values.
> >>>>>>>> I've talked to other engineers here and we think this is
pretty
> >>>>>>> ridiculous. It makes specifying grid information way overly
> >>>> complicated.
> >>>>>>> But unfortunately, that's how the spec is written.
> >>>>>>>> To summarize, you should remove the
> "longitude_of_projection_origin"
> >>>>>>> attribute since it isn't valid or used. And you should
change the
> >>>> range of
> >>>>>>> values for x from:
> >>>>>>>> 0 ... 5394000 to
> >>>>>>>> -something ... +something
> >>>>>>>> And the 0 occurs at the x value which coincides with the
longitude
> >> of
> >>>>>>> the central meridian.
> >>>>>>>> Unfortunately, I think I've also discovered a small bug in
the
> >> Lambert
> >>>>>>> Conformal grid code, where we've failed to put a longitude
value in
> >> the
> >>>>>>> correct range before using it.
> >>>>>>>> Confused yet?
> >>>>>>>>
> >>>>>>>> John
> >>>>>>> --
> >>>>>>>
> >>>>>>>
> >>
>
----------------------------------------------------------------------------
> >>>>>>> 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
> >>
> >>
>
----------------------------------------------------------------------------
> >>
> >>
> >>
>
>
> --
>
>
----------------------------------------------------------------------------
> 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 #75519] MODE projection question
From: Sarah Griffin
Time: Wed Mar 16 10:10:03 2016
Hi John,
*Bang head on table*
I thought I tried to update the nccf_file.cc file for the new HRRR
data,
but was getting the same error. Turns out math in IDL is:
IDL> 360.0-237.280472
122.71953
So I had data.lon_pin = 122.71953; instead of data.lon_pin =
122.719528;
Thank you very much for listing out the values I need for the
nccf_file.cc!! I'm still going to look into other methods for
converting
the grids but for now 2 separate versions of MODE will work. Thank you
so much for your help!!
Have a great day!
Sarah
On 3/16/16 10:41 AM, John Halley Gotway via RT wrote:
> Sarah,
>
> That's a cool option in wgrib2. I wasn't aware of that. We can use
that
> to demonstrate the (very slight) difference in the grids you sent
me. Look
> at the lat/lon of the first point in each file (i.e. i=1, j=1):
>
> [johnhg at number5]% wgrib2 -ijlat 1 1
> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300
> 1:0:(1,1),lon=237.280000,lat=21.138000,val=289.4
>
> [johnhg at number5]% wgrib2 -ijlat 1 1
> GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200
> 1:0:(1,1),lon=237.280472,lat=21.138123,val=282.84
>
> Notice the slight difference? 237.28 changes to 237.280472 and
21.138
> changes to 21.138123.
>
> I thought of another method for getting the 2016 data back on to the
"old"
> HRRR grid. You can use wgrib2 to "regrid" GRIB2 data.
>
> I followed these instructions:
> http://www.cpc.ncep.noaa.gov/products/wesley/wgrib2/index.html
> And ran the following wgrib2 command:
>
> wgrib2 \
> GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200
\
> -new_grid lambert:262.5:38.5 237.28:1799:3000 21.138:1059:3000 \
>
GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200_FIX_GRID
>
> The output file should now be on the "old" grid.
>
> It possible that your build of wgrib2 was not compiled with support
for
> regridding. If that's the case, getting cnvgrib compiled is a lot
easier
> than recompiling wgrib2 with support for regridding!
>
> To summarize, your options are:
>
> (1) Compile cnvgrib and use it to truncate the newer HRRR grid
definitions
> to the older one.
> (2) Use wgrib2 to regrid the newer HRRR grid definition to the older
one.
> (3) Modify the nccf_file.cc patch and recompile MET to use the newer
HRRR
> grid def. That'll make MET work with the newer HRRR files but not
the
> older ones. Here are the values you should be using:
> data.lat_pin = 21.138123;
> data.lon_pin = 122.719528;
> Be sure to do a "make clean" followed by a "make install" for MET.
>
> Thanks,
> John
>
>
>
>
> On Wed, Mar 16, 2016 at 8:02 AM, Sarah Griffin via RT
<met_help at ucar.edu>
> wrote:
>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
>>
>> Hi John,
>>
>> I did a bit more (accidental) digging.
>>
>> For the MODE file that worked, I typed:
>> ./wgrib2 -ijlat 10 10
>> GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201508011300
>> and got
>> 1:0:(10,10),lon=237.453103,lat=21.424798,val=289.2
>> so, does this mean the HRRR file that worked is also GRIB2 and
doesn't
>> need to be converted to GRIB1 to work? I've tried downloading
cnvgrib
>> but can't get it to compile.
>>
>> I updated the nccf_file.cc to read:
>> data.lat_pin = 21.138123;
>> data.lon_pin = 122.71953;
>> and recompiled MET. However, that also did not work.
>>
>> Do you have any ideas?
>>
>> Have a great day!
>> Sarah
>>
>> On 3/15/16 11:40 AM, John Halley Gotway via RT wrote:
>>> Sarah,
>>>
>>> I was confused as to why the 2015 case is working for you in MET
5.0 but
>>> not for me. After doing some searching I see that I sent you guys
a
>> hacked
>>> version of nccf_file.cc back on 7/22/2015. It just hardcodes the
HRRR
>>> domain. So even though the Lambert Conformal grid isn't set right
in the
>>> NetCDF file, it doesn't matter. MET ignores that and uses the
hard-coded
>>> grid definition.
>>>
>>> The reason for the trouble you're having now is the slight change
to the
>>> HRRR grid... i.e. 3 decimal points changed to 6 decimal points.
>>>
>>> So the hardcoded HRRR grid definition in nccf_file.cc is no longer
>>> consistent. This hacking of the code is not a good long term
solution.
>>> Until we get a better solution, you have a couple of choices.
>>>
>>> (1) Edit the hack in nccf_file.cc to match the updated grid
definition
>> and
>>> recompile MET.
>>>
>>> (2) Run your HRRR GRIB2 file through the cnvgrib utility to
convert from
>>> GRIB2 to GRIB1. That'll change the 6 decimal points back to 3 and
match
>>> the existing definition.
>>>
>>> cnvgrib -g21 \
>>>
GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200 \
>>>
GRIB1.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200
>>>
>>> As a side-note, this has actually uncovered 2 problems in MET...
>>>
>>> (1) The lambert conformal grid code was failing to rescale a
longitude
>>> value when it should have (posted met-5.1 bugfix).
>>>
>>> (2) The lambert conformal grid equality checking is still
insufficient.
>>> There are many ways the same grid could be specified... but MET
only says
>>> they are equal if they're specified in exactly the same way. In
you
>> case,
>>> GRIB2 specifies the lower-left corner while CF-compliant NetCDF
specifies
>>> the location of the lower center grid point. MET should be smart
enough
>> to
>>> recognize these as being the same grids. This is an open issue.
>>>
>>> John
>>>
>>> On Tue, Mar 15, 2016 at 10:08 AM, Sarah Griffin via RT <
>> met_help at ucar.edu>
>>> wrote:
>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
>>>>
>>>> Hi John,
>>>>
>>>> I did not know wgrib2 -V was an option so thanks for finding the
grid
>>>> definitions. Seems like that narrows down the issue for why MODE
>>>> wouldn't run, the HRRR grid changed slightly. I tried updating
the
>>>> remapped observation using:
>>>>
>>>> cp remap_GOES-13.2016032.1300_75W.nc remap_GOES_patch.nc
>>>> ncatted -a latitude_of_projection_origin,Projection,o,f,21.138123
>>>> remap_GOES_patch.nc
>>>>
>>>> to account for the updated center lat, but that did not solve the
issue.
>>>> Do you have any other thoughts?
>>>>
>>>> Thanks,
>>>> Sarah
>>>>
>>>> On 3/15/16 10:42 AM, John Halley Gotway via RT wrote:
>>>>> Sarah,
>>>>>
>>>>> Using wgrib2 with the -V option to look at the grid definition,
I see
>> the
>>>>> following:
>>>>>
>>>>> [johnhg at number5]% wgrib2 -V
>>>>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300
>>>>> 1:0:vt=2015080113:top of atmosphere:anl:var discipline=3
center=59
>>>>> local_table=1 parmcat=192 parm=2:
>>>>> ndata=1905141:undef=0:mean=284.12:min=186.7:max=302.2
>>>>> grid_template=30:winds(grid):
>>>>> Lambert Conformal: (1799 x 1059) input WE:SN output
WE:SN
>> res 8
>>>>> Lat1 21.138000 Lon1 237.280000 LoV 262.500000
>>>>> LatD 38.500000 Latin1 38.500000 Latin2 38.500000
>>>>> LatSP 0.000000 LonSP 0.000000
>>>>> North Pole (1799 x 1059) Dx 3000.000000 m Dy
3000.000000 m
>> mode
>>>> 8
>>>>> [johnhg at number5]% wgrib2 -V
>>>>> GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200
>>>>> 1:0:vt=2016020113:top of atmosphere:1 hour fcst:var discipline=3
>>>> center=59
>>>>> local_table=1 parmcat=192 parm=2:
>>>>> ndata=1905141:undef=0:mean=268.375:min=198.78:max=297.32
>>>>> grid_template=30:winds(grid):
>>>>> Lambert Conformal: (1799 x 1059) input WE:SN output
WE:SN
>> res 8
>>>>> Lat1 21.138123 Lon1 237.280472 LoV 262.500000
>>>>> LatD 38.500000 Latin1 38.500000 Latin2 38.500000
>>>>> LatSP 0.000000 LonSP 0.000000
>>>>> North Pole (1799 x 1059) Dx 3000.000000 m Dy
3000.000000 m
>> mode
>>>> 8
>>>>> Note the slight difference in the reference lat/lon value. The
2015
>> file
>>>>> uses up to 3 decimal points while the 2016 file uses up to 6
decimal
>>>>> points. While 6 decimal points is fine in GRIB2, only 3 decimal
points
>>>> (up
>>>>> to 1/1000th) can be represented in GRIB1.
>>>>>
>>>>> Perhaps in 2015 you had GRIB1 data that was being converted to
GRIB2
>> and
>>>> in
>>>>> 2016 you have GRIB2 directly.
>>>>>
>>>>> I know that the difference is slight, but MET will flag these
grids as
>>>>> being different.
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Mar 15, 2016 at 9:15 AM, Sarah Griffin via RT <
>> met_help at ucar.edu
>>>>> wrote:
>>>>>
>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
>>>>>>
>>>>>> Hi John,
>>>>>>
>>>>>> Thanks for looking into this. I should mention, I'm running
using
>>>>>> METv5.0. That could be why something worked previously for me
and not
>>>>>> for you.
>>>>>>
>>>>>> It seem like option 2 would probably be our best option, since
I know
>>>>>> the HRRR grids and remapped GOES grids line up. We are looking
to do
>>>>>> something in the next month.
>>>>>>
>>>>>> I also wanted to add one more tidbit. I said:
>>>>>> MODE *would* run on
>>>>>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300
&
>>>>>> remap_GOES-13.2015213.1300_75W.nc
>>>>>> MODE *would **NOT* run on
>>>>>> GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200
&
>>>>>> remap_GOES-13.2016032.1300_75W.nc
>>>>>>
>>>>>> I decided to have some fun and discovered:
>>>>>> MODE *will* run on
>>>>>> GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300
&
>>>>>> remap_GOES-13.2016032.1300_75W.nc. I know the times do not
match up,
>> I
>>>>>> was just curious if it would actually work. I did not change
the
>>>>>> remapped GOES file like to recommend in option (1).
>>>>>>
>>>>>> Does this mean there is something that changed with the HRRR
grib2
>> file
>>>>>> that it will no longer run in MODE?
>>>>>>
>>>>>> Have a great day!
>>>>>> Sarah
>>>>>>
>>>>>>
>>>>>> On 3/14/16 5:53 PM, John Halley Gotway via RT wrote:
>>>>>>> Sarah,
>>>>>>>
>>>>>>> OK, I just posted this 1 line bugfix for lambert conformal
grids in
>>>> MET:
>>>>
>>
http://www.dtcenter.org/met/users/support/known_issues/METv5.1/index.php
>>>>>>> Just follow the instructions to apply the patch and recompile.
>>>>>>>
>>>>>>> Next, not sure why the files worked previously for you but not
for
>> me.
>>>>>> You
>>>>>>> have a few options...
>>>>>>>
>>>>>>> (1) First, I ran the nco commands listed below to update the
grid
>>>>>>> definition in the file you sent. Rather than specifying the
>> lower-left
>>>>>>> corner as the reference location, we're using x = 899.1693, y
= 0 as
>>>> the
>>>>>>> reference location. Looking in the Latitude and Longitude
>> variables, I
>>>>>> see
>>>>>>> the point (900, 0) = lat 24.3646, lon -97.5.
>>>>>>>
>>>>>>> # Subtract 2697507.9 from all the x values
>>>>>>> ncap -O -s "x=x-2697507.9" remap_GOES-
13.2016032.1300_75W.nc
>>>>>>> remap_GOES_patch.nc
>>>>>>>
>>>>>>> # Add back on the x variable attributes and update the
>> reference
>>>>>>> latitude value
>>>>>>> ncatted -a long_name,x,o,c,"x coordinate of projection"
\
>>>>>>> -a
standard_name,x,o,c,"projection_x_coordinate" \
>>>>>>> -a units,x,o,c,"m" \
>>>>>>> -a grid_spacing,x,o,c,"3000.0000" \
>>>>>>> -a
>>>> latitude_of_projection_origin,Projection,o,f,24.3646 \
>>>>>>> remap_GOES_patch.nc
>>>>>>>
>>>>>>> # Plot the result using the patched version of MET
>>>>>>> plot_data_plane \
>>>>>>> remap_GOES_patch.nc remap_GOES_patch.ps \
>>>>>>> 'name = "channel_14_brightness_temperature"; level
=
>> "(*,*)";'
>>>>>>> I've attached the resulting image. It looks very good. But
when I
>> run
>>>>>> it
>>>>>>> through MODE, I still get this error:
>>>>>>>
>>>>>>> ERROR : parse_vx_grid() -> The forecast and observation grids
do not
>>>>>> match:
>>>>>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059
Lat_LL:
>> 21.138
>>>>>>> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623
Bx:
>>>>>> 899.1693
>>>>>>> By: 3198.9984 !=
>>>>>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059
Lat_LL:
>> 21.138
>>>>>>> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone: 0.623
Bx:
>>>>>> 899.1693
>>>>>>> By: 3198.9975
>>>>>>>
>>>>>>> This is a actually a short-coming in MET. MET is doing the
simplest
>>>>>> check
>>>>>>> for grid equality, and since these grids we not instantiated
using
>> the
>>>>>> same
>>>>>>> info, MET says they're not equal.
>>>>>>>
>>>>>>> (2) Second, in our development code we've added a new
interpolation
>>>>>>> "method" called FORCE. It basically means, don't worry about
>> checking
>>>>>> the
>>>>>>> grid info. Instead, as long as Nx and Ny match, go ahead and
compare
>>>> the
>>>>>>> data. I ran the development version of MODE using this config
file
>>>>>> option:
>>>>>>> regrid = {
>>>>>>> to_grid = FCST;
>>>>>>> method = FORCE;
>>>>>>> width = 1;
>>>>>>> vld_thresh = 0.5;
>>>>>>> }
>>>>>>>
>>>>>>> This says, run MODE using the forecast grid definition. And
only
>> check
>>>>>>> that the fcst and obs grid dimensions match.
>>>>>>>
>>>>>>> I could either send you a beta release of the development code
for
>>>>>> testing
>>>>>>> or you could wait until the next release.
>>>>>>>
>>>>>>> (3) A third option we're considering adding is letting the
user
>> specify
>>>>>> the
>>>>>>> grid definition to be used directly in the config file. So if
your
>>>> data
>>>>>>> has no grid info... or bad grid info... just specify the
desired grid
>>>> in
>>>>>>> the config file. But that option will be new development and
will
>>>> take a
>>>>>>> few weeks.
>>>>>>>
>>>>>>> What's your timeline? How soon do you need to get this done?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Mar 14, 2016 at 3:28 PM, John Halley Gotway
<johnhg at ucar.edu
>>>>>> wrote:
>>>>>>>> Sarah,
>>>>>>>>
>>>>>>>> Running the following MODE command produces that same error:
>>>>>>>>
>>>>>>>> met-5.1/bin/mode \
>>>>>>>>
GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 \
>>>>>>>> remap_GOES-13.2015213.1300_75W.nc \
>>>>>>>> East_2015213_1300_4_0_mode_config_file
>>>>>>>>
>>>>>>>> ERROR : parse_vx_grid() -> The forecast and observation
grids do
>> not
>>>>>>>> match:
>>>>>>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059
Lat_LL:
>>>> 21.138
>>>>>>>> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone:
0.623 Bx:
>>>>>> 899.1870
>>>>>>>> By: 3198.9983 !=
>>>>>>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059
Lat_LL:
>>>> 21.138
>>>>>>>> Lon_LL: -44.200 Lon_orient: 97.500 Alpha: 4203.494 Cone:
0.623 Bx:
>>>>>>>> 2312.7166 By: -2386.0992
>>>>>>>>
>>>>>>>> I am not sure why it's running successfully on your machine.
Did we
>>>>>>>> perhaps apply a hack to your version of the code to get MODE
to run
>> on
>>>>>> this
>>>>>>>> data?
>>>>>>>>
>>>>>>>> I just forwarded you a message from back in Nov 2015 when we
last
>>>>>>>> discussed this Lambert Conformal CF-compliant NetCDF issue.
>>>>>>>>
>>>>>>>> Also, I am still aware of a small bug in the lambert
conformal grid
>>>> info
>>>>>>>> that I need to fix and post a bugfix.
>>>>>>>>
>>>>>>>> John
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Mar 14, 2016 at 1:22 PM, Sarah Griffin via RT <
>>>>>> met_help at ucar.edu>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
>>>>>>>>>
>>>>>>>>> Hi John,
>>>>>>>>>
>>>>>>>>> I am incredibly confused.
>>>>>>>>>
>>>>>>>>> Removing longitude_of_projection_origin makes sense, and
I've done
>>>>>> that.
>>>>>>>>> I've put 2 new files into the incoming directory on the ftp
site:
>>>>>>>>>
GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 and
>>>>>>>>> remap_GOES-13.2015213.1300_75W.nc. MODE can run on these 2
files
>>>> just
>>>>>>>>> fine. I converted the 2 GRIB2 files in
>>>>>>>>> incoming/irap/met_help/griffin_data/ to netcdf files, both
x's
>> range
>>>>>>>>> from 0 to 5394000. The x's of both remapped GOES observation
files
>>>> also
>>>>>>>>> range from 0 to 5394000. Yet, MODE will run on one pair but
not the
>>>>>>>>> other. So could the 'x' variable still be the problem?
>>>>>>>>>
>>>>>>>>> Any ideas?
>>>>>>>>> Sarah
>>>>>>>>>
>>>>>>>>> On 3/14/16 1:26 PM, John Halley Gotway via RT wrote:
>>>>>>>>>> Sarah,
>>>>>>>>>>
>>>>>>>>>> The problem is in the grid specification for the CF-
compliant
>> NetCDF
>>>>>>>>> file you're using. Here's the Projection info from your
NetCDF
>> file:
>>>>>>>>>> int Projection(time) ;
>>>>>>>>>> Projection:grid_mapping_name = "lambert_conformal_conic" ;
>>>>>>>>>> Projection:standard_parallel = 38.5f ;
>>>>>>>>>> Projection:longitude_of_central_meridian = 262.5f ;
>>>>>>>>>> Projection:latitude_of_projection_origin = 21.138f ;
>>>>>>>>>> Projection:longitude_of_projection_origin = -122.72f ;
>>>>>>>>>>
>>>>>>>>>> Compare this with the CF specification:
>>>>>>>>>>
>> http://cfconventions.org/cf-conventions/v1.6.0/cf-
conventions.html#_lambert_conformal
>>>>>>>>>> And notice that "longitude_of_projection_origin" is not
actually a
>>>>>>>>> valid attribute.
>>>>>>>>>> Instead, the CF convention specifies the reference location
at the
>>>>>>>>> latitude of the origin and the longitude of the central
meridian.
>>>> Then
>>>>>> the
>>>>>>>>> "x" and "y" variables are used to specify the location in
the grid
>> of
>>>>>> those
>>>>>>>>> reference longitude and latitude values.
>>>>>>>>>> I've talked to other engineers here and we think this is
pretty
>>>>>>>>> ridiculous. It makes specifying grid information way overly
>>>>>> complicated.
>>>>>>>>> But unfortunately, that's how the spec is written.
>>>>>>>>>> To summarize, you should remove the
>> "longitude_of_projection_origin"
>>>>>>>>> attribute since it isn't valid or used. And you should
change the
>>>>>> range of
>>>>>>>>> values for x from:
>>>>>>>>>> 0 ... 5394000 to
>>>>>>>>>> -something ... +something
>>>>>>>>>> And the 0 occurs at the x value which coincides with the
longitude
>>>> of
>>>>>>>>> the central meridian.
>>>>>>>>>> Unfortunately, I think I've also discovered a small bug in
the
>>>> Lambert
>>>>>>>>> Conformal grid code, where we've failed to put a longitude
value in
>>>> the
>>>>>>>>> correct range before using it.
>>>>>>>>>> Confused yet?
>>>>>>>>>>
>>>>>>>>>> John
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>>
>>
----------------------------------------------------------------------------
>>>>>>>>> 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
>>>>
>>>>
>>
----------------------------------------------------------------------------
>>>>
>>>>
>>
>> --
>>
>>
----------------------------------------------------------------------------
>> 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: MODE projection question
From: John Halley Gotway
Time: Wed Mar 16 11:01:47 2016
Sarah,
Great! Glad this is a workable solution for now.
As I mentioned, in the next release expect two changes that would
apply
here.
(1) The FORCE interpolation option will enable two datasets of the
same
dimension to be compared even if their grids are not identical. This
is
already coded up.
(2) We'll probably add a config file entry to enable the user to
specify
the grid that should be used for a dataset. The grid in the data for
one
of our projects is wrong... and they are not willing/able to correct
it.
Adding the ability for the user to "overwrite" the grid seems like a
nice
solution here.
I'll go ahead and resolve this ticket now.
Thanks,
John
On Wed, Mar 16, 2016 at 10:10 AM, Sarah Griffin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
>
> Hi John,
>
> *Bang head on table*
>
> I thought I tried to update the nccf_file.cc file for the new HRRR
data,
> but was getting the same error. Turns out math in IDL is:
> IDL> 360.0-237.280472
> 122.71953
> So I had data.lon_pin = 122.71953; instead of data.lon_pin =
122.719528;
>
> Thank you very much for listing out the values I need for the
> nccf_file.cc!! I'm still going to look into other methods for
converting
> the grids but for now 2 separate versions of MODE will work. Thank
you
> so much for your help!!
>
> Have a great day!
> Sarah
>
> On 3/16/16 10:41 AM, John Halley Gotway via RT wrote:
> > Sarah,
> >
> > That's a cool option in wgrib2. I wasn't aware of that. We can
use that
> > to demonstrate the (very slight) difference in the grids you sent
me.
> Look
> > at the lat/lon of the first point in each file (i.e. i=1, j=1):
> >
> > [johnhg at number5]% wgrib2 -ijlat 1 1
> > GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300
> > 1:0:(1,1),lon=237.280000,lat=21.138000,val=289.4
> >
> > [johnhg at number5]% wgrib2 -ijlat 1 1
> > GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200
> > 1:0:(1,1),lon=237.280472,lat=21.138123,val=282.84
> >
> > Notice the slight difference? 237.28 changes to 237.280472 and
21.138
> > changes to 21.138123.
> >
> > I thought of another method for getting the 2016 data back on to
the
> "old"
> > HRRR grid. You can use wgrib2 to "regrid" GRIB2 data.
> >
> > I followed these instructions:
> > http://www.cpc.ncep.noaa.gov/products/wesley/wgrib2/index.html
> > And ran the following wgrib2 command:
> >
> > wgrib2 \
> >
GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200 \
> > -new_grid lambert:262.5:38.5 237.28:1799:3000 21.138:1059:3000
\
> >
>
GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200_FIX_GRID
> >
> > The output file should now be on the "old" grid.
> >
> > It possible that your build of wgrib2 was not compiled with
support for
> > regridding. If that's the case, getting cnvgrib compiled is a lot
easier
> > than recompiling wgrib2 with support for regridding!
> >
> > To summarize, your options are:
> >
> > (1) Compile cnvgrib and use it to truncate the newer HRRR grid
> definitions
> > to the older one.
> > (2) Use wgrib2 to regrid the newer HRRR grid definition to the
older one.
> > (3) Modify the nccf_file.cc patch and recompile MET to use the
newer HRRR
> > grid def. That'll make MET work with the newer HRRR files but not
the
> > older ones. Here are the values you should be using:
> > data.lat_pin = 21.138123;
> > data.lon_pin = 122.719528;
> > Be sure to do a "make clean" followed by a "make install" for MET.
> >
> > Thanks,
> > John
> >
> >
> >
> >
> > On Wed, Mar 16, 2016 at 8:02 AM, Sarah Griffin via RT
<met_help at ucar.edu
> >
> > wrote:
> >
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
> >>
> >> Hi John,
> >>
> >> I did a bit more (accidental) digging.
> >>
> >> For the MODE file that worked, I typed:
> >> ./wgrib2 -ijlat 10 10
> >> GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201508011300
> >> and got
> >> 1:0:(10,10),lon=237.453103,lat=21.424798,val=289.2
> >> so, does this mean the HRRR file that worked is also GRIB2 and
doesn't
> >> need to be converted to GRIB1 to work? I've tried downloading
cnvgrib
> >> but can't get it to compile.
> >>
> >> I updated the nccf_file.cc to read:
> >> data.lat_pin = 21.138123;
> >> data.lon_pin = 122.71953;
> >> and recompiled MET. However, that also did not work.
> >>
> >> Do you have any ideas?
> >>
> >> Have a great day!
> >> Sarah
> >>
> >> On 3/15/16 11:40 AM, John Halley Gotway via RT wrote:
> >>> Sarah,
> >>>
> >>> I was confused as to why the 2015 case is working for you in MET
5.0
> but
> >>> not for me. After doing some searching I see that I sent you
guys a
> >> hacked
> >>> version of nccf_file.cc back on 7/22/2015. It just hardcodes
the HRRR
> >>> domain. So even though the Lambert Conformal grid isn't set
right in
> the
> >>> NetCDF file, it doesn't matter. MET ignores that and uses the
> hard-coded
> >>> grid definition.
> >>>
> >>> The reason for the trouble you're having now is the slight
change to
> the
> >>> HRRR grid... i.e. 3 decimal points changed to 6 decimal points.
> >>>
> >>> So the hardcoded HRRR grid definition in nccf_file.cc is no
longer
> >>> consistent. This hacking of the code is not a good long term
solution.
> >>> Until we get a better solution, you have a couple of choices.
> >>>
> >>> (1) Edit the hack in nccf_file.cc to match the updated grid
definition
> >> and
> >>> recompile MET.
> >>>
> >>> (2) Run your HRRR GRIB2 file through the cnvgrib utility to
convert
> from
> >>> GRIB2 to GRIB1. That'll change the 6 decimal points back to 3
and
> match
> >>> the existing definition.
> >>>
> >>> cnvgrib -g21 \
> >>>
GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200 \
> >>>
GRIB1.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200
> >>>
> >>> As a side-note, this has actually uncovered 2 problems in MET...
> >>>
> >>> (1) The lambert conformal grid code was failing to rescale a
longitude
> >>> value when it should have (posted met-5.1 bugfix).
> >>>
> >>> (2) The lambert conformal grid equality checking is still
insufficient.
> >>> There are many ways the same grid could be specified... but MET
only
> says
> >>> they are equal if they're specified in exactly the same way. In
you
> >> case,
> >>> GRIB2 specifies the lower-left corner while CF-compliant NetCDF
> specifies
> >>> the location of the lower center grid point. MET should be
smart
> enough
> >> to
> >>> recognize these as being the same grids. This is an open issue.
> >>>
> >>> John
> >>>
> >>> On Tue, Mar 15, 2016 at 10:08 AM, Sarah Griffin via RT <
> >> met_help at ucar.edu>
> >>> wrote:
> >>>
> >>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
> >>>>
> >>>> Hi John,
> >>>>
> >>>> I did not know wgrib2 -V was an option so thanks for finding
the grid
> >>>> definitions. Seems like that narrows down the issue for why
MODE
> >>>> wouldn't run, the HRRR grid changed slightly. I tried updating
the
> >>>> remapped observation using:
> >>>>
> >>>> cp remap_GOES-13.2016032.1300_75W.nc remap_GOES_patch.nc
> >>>> ncatted -a
latitude_of_projection_origin,Projection,o,f,21.138123
> >>>> remap_GOES_patch.nc
> >>>>
> >>>> to account for the updated center lat, but that did not solve
the
> issue.
> >>>> Do you have any other thoughts?
> >>>>
> >>>> Thanks,
> >>>> Sarah
> >>>>
> >>>> On 3/15/16 10:42 AM, John Halley Gotway via RT wrote:
> >>>>> Sarah,
> >>>>>
> >>>>> Using wgrib2 with the -V option to look at the grid
definition, I see
> >> the
> >>>>> following:
> >>>>>
> >>>>> [johnhg at number5]% wgrib2 -V
> >>>>>
GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300
> >>>>> 1:0:vt=2015080113:top of atmosphere:anl:var discipline=3
center=59
> >>>>> local_table=1 parmcat=192 parm=2:
> >>>>> ndata=1905141:undef=0:mean=284.12:min=186.7:max=302.2
> >>>>> grid_template=30:winds(grid):
> >>>>> Lambert Conformal: (1799 x 1059) input WE:SN output
WE:SN
> >> res 8
> >>>>> Lat1 21.138000 Lon1 237.280000 LoV 262.500000
> >>>>> LatD 38.500000 Latin1 38.500000 Latin2 38.500000
> >>>>> LatSP 0.000000 LonSP 0.000000
> >>>>> North Pole (1799 x 1059) Dx 3000.000000 m Dy
3000.000000 m
> >> mode
> >>>> 8
> >>>>> [johnhg at number5]% wgrib2 -V
> >>>>>
GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200
> >>>>> 1:0:vt=2016020113:top of atmosphere:1 hour fcst:var
discipline=3
> >>>> center=59
> >>>>> local_table=1 parmcat=192 parm=2:
> >>>>>
ndata=1905141:undef=0:mean=268.375:min=198.78:max=297.32
> >>>>> grid_template=30:winds(grid):
> >>>>> Lambert Conformal: (1799 x 1059) input WE:SN output
WE:SN
> >> res 8
> >>>>> Lat1 21.138123 Lon1 237.280472 LoV 262.500000
> >>>>> LatD 38.500000 Latin1 38.500000 Latin2 38.500000
> >>>>> LatSP 0.000000 LonSP 0.000000
> >>>>> North Pole (1799 x 1059) Dx 3000.000000 m Dy
3000.000000 m
> >> mode
> >>>> 8
> >>>>> Note the slight difference in the reference lat/lon value.
The 2015
> >> file
> >>>>> uses up to 3 decimal points while the 2016 file uses up to 6
decimal
> >>>>> points. While 6 decimal points is fine in GRIB2, only 3
decimal
> points
> >>>> (up
> >>>>> to 1/1000th) can be represented in GRIB1.
> >>>>>
> >>>>> Perhaps in 2015 you had GRIB1 data that was being converted to
GRIB2
> >> and
> >>>> in
> >>>>> 2016 you have GRIB2 directly.
> >>>>>
> >>>>> I know that the difference is slight, but MET will flag these
grids
> as
> >>>>> being different.
> >>>>>
> >>>>> John
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Mar 15, 2016 at 9:15 AM, Sarah Griffin via RT <
> >> met_help at ucar.edu
> >>>>> wrote:
> >>>>>
> >>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519
>
> >>>>>>
> >>>>>> Hi John,
> >>>>>>
> >>>>>> Thanks for looking into this. I should mention, I'm running
using
> >>>>>> METv5.0. That could be why something worked previously for me
and
> not
> >>>>>> for you.
> >>>>>>
> >>>>>> It seem like option 2 would probably be our best option,
since I
> know
> >>>>>> the HRRR grids and remapped GOES grids line up. We are
looking to do
> >>>>>> something in the next month.
> >>>>>>
> >>>>>> I also wanted to add one more tidbit. I said:
> >>>>>> MODE *would* run on
> >>>>>>
GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 &
> >>>>>> remap_GOES-13.2015213.1300_75W.nc
> >>>>>> MODE *would **NOT* run on
> >>>>>>
GRIB2.FSL.HRRR.1905141_Lambert.001Hour.SBT124.NTOP.201602011200 &
> >>>>>> remap_GOES-13.2016032.1300_75W.nc
> >>>>>>
> >>>>>> I decided to have some fun and discovered:
> >>>>>> MODE *will* run on
> >>>>>>
GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 &
> >>>>>> remap_GOES-13.2016032.1300_75W.nc. I know the times do not
match
> up,
> >> I
> >>>>>> was just curious if it would actually work. I did not change
the
> >>>>>> remapped GOES file like to recommend in option (1).
> >>>>>>
> >>>>>> Does this mean there is something that changed with the HRRR
grib2
> >> file
> >>>>>> that it will no longer run in MODE?
> >>>>>>
> >>>>>> Have a great day!
> >>>>>> Sarah
> >>>>>>
> >>>>>>
> >>>>>> On 3/14/16 5:53 PM, John Halley Gotway via RT wrote:
> >>>>>>> Sarah,
> >>>>>>>
> >>>>>>> OK, I just posted this 1 line bugfix for lambert conformal
grids in
> >>>> MET:
> >>>>
> >>
>
http://www.dtcenter.org/met/users/support/known_issues/METv5.1/index.php
> >>>>>>> Just follow the instructions to apply the patch and
recompile.
> >>>>>>>
> >>>>>>> Next, not sure why the files worked previously for you but
not for
> >> me.
> >>>>>> You
> >>>>>>> have a few options...
> >>>>>>>
> >>>>>>> (1) First, I ran the nco commands listed below to update the
grid
> >>>>>>> definition in the file you sent. Rather than specifying the
> >> lower-left
> >>>>>>> corner as the reference location, we're using x = 899.1693,
y = 0
> as
> >>>> the
> >>>>>>> reference location. Looking in the Latitude and Longitude
> >> variables, I
> >>>>>> see
> >>>>>>> the point (900, 0) = lat 24.3646, lon -97.5.
> >>>>>>>
> >>>>>>> # Subtract 2697507.9 from all the x values
> >>>>>>> ncap -O -s "x=x-2697507.9"
> remap_GOES-13.2016032.1300_75W.nc
> >>>>>>> remap_GOES_patch.nc
> >>>>>>>
> >>>>>>> # Add back on the x variable attributes and update
the
> >> reference
> >>>>>>> latitude value
> >>>>>>> ncatted -a long_name,x,o,c,"x coordinate of
projection" \
> >>>>>>> -a
> standard_name,x,o,c,"projection_x_coordinate" \
> >>>>>>> -a units,x,o,c,"m" \
> >>>>>>> -a grid_spacing,x,o,c,"3000.0000" \
> >>>>>>> -a
> >>>> latitude_of_projection_origin,Projection,o,f,24.3646 \
> >>>>>>> remap_GOES_patch.nc
> >>>>>>>
> >>>>>>> # Plot the result using the patched version of MET
> >>>>>>> plot_data_plane \
> >>>>>>> remap_GOES_patch.nc remap_GOES_patch.ps \
> >>>>>>> 'name = "channel_14_brightness_temperature";
level =
> >> "(*,*)";'
> >>>>>>> I've attached the resulting image. It looks very good. But
when I
> >> run
> >>>>>> it
> >>>>>>> through MODE, I still get this error:
> >>>>>>>
> >>>>>>> ERROR : parse_vx_grid() -> The forecast and observation
grids do
> not
> >>>>>> match:
> >>>>>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059
Lat_LL:
> >> 21.138
> >>>>>>> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone:
0.623 Bx:
> >>>>>> 899.1693
> >>>>>>> By: 3198.9984 !=
> >>>>>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059
Lat_LL:
> >> 21.138
> >>>>>>> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone:
0.623 Bx:
> >>>>>> 899.1693
> >>>>>>> By: 3198.9975
> >>>>>>>
> >>>>>>> This is a actually a short-coming in MET. MET is doing the
> simplest
> >>>>>> check
> >>>>>>> for grid equality, and since these grids we not instantiated
using
> >> the
> >>>>>> same
> >>>>>>> info, MET says they're not equal.
> >>>>>>>
> >>>>>>> (2) Second, in our development code we've added a new
interpolation
> >>>>>>> "method" called FORCE. It basically means, don't worry
about
> >> checking
> >>>>>> the
> >>>>>>> grid info. Instead, as long as Nx and Ny match, go ahead
and
> compare
> >>>> the
> >>>>>>> data. I ran the development version of MODE using this
config file
> >>>>>> option:
> >>>>>>> regrid = {
> >>>>>>> to_grid = FCST;
> >>>>>>> method = FORCE;
> >>>>>>> width = 1;
> >>>>>>> vld_thresh = 0.5;
> >>>>>>> }
> >>>>>>>
> >>>>>>> This says, run MODE using the forecast grid definition. And
only
> >> check
> >>>>>>> that the fcst and obs grid dimensions match.
> >>>>>>>
> >>>>>>> I could either send you a beta release of the development
code for
> >>>>>> testing
> >>>>>>> or you could wait until the next release.
> >>>>>>>
> >>>>>>> (3) A third option we're considering adding is letting the
user
> >> specify
> >>>>>> the
> >>>>>>> grid definition to be used directly in the config file. So
if your
> >>>> data
> >>>>>>> has no grid info... or bad grid info... just specify the
desired
> grid
> >>>> in
> >>>>>>> the config file. But that option will be new development
and will
> >>>> take a
> >>>>>>> few weeks.
> >>>>>>>
> >>>>>>> What's your timeline? How soon do you need to get this
done?
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> John
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Mon, Mar 14, 2016 at 3:28 PM, John Halley Gotway <
> johnhg at ucar.edu
> >>>>>> wrote:
> >>>>>>>> Sarah,
> >>>>>>>>
> >>>>>>>> Running the following MODE command produces that same
error:
> >>>>>>>>
> >>>>>>>> met-5.1/bin/mode \
> >>>>>>>>
GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300 \
> >>>>>>>> remap_GOES-13.2015213.1300_75W.nc \
> >>>>>>>> East_2015213_1300_4_0_mode_config_file
> >>>>>>>>
> >>>>>>>> ERROR : parse_vx_grid() -> The forecast and observation
grids do
> >> not
> >>>>>>>> match:
> >>>>>>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059
Lat_LL:
> >>>> 21.138
> >>>>>>>> Lon_LL: 122.720 Lon_orient: 97.500 Alpha: 4203.494 Cone:
0.623 Bx:
> >>>>>> 899.1870
> >>>>>>>> By: 3198.9983 !=
> >>>>>>>> ERROR : Projection: Lambert Conformal Nx: 1799 Ny: 1059
Lat_LL:
> >>>> 21.138
> >>>>>>>> Lon_LL: -44.200 Lon_orient: 97.500 Alpha: 4203.494 Cone:
0.623 Bx:
> >>>>>>>> 2312.7166 By: -2386.0992
> >>>>>>>>
> >>>>>>>> I am not sure why it's running successfully on your
machine. Did
> we
> >>>>>>>> perhaps apply a hack to your version of the code to get
MODE to
> run
> >> on
> >>>>>> this
> >>>>>>>> data?
> >>>>>>>>
> >>>>>>>> I just forwarded you a message from back in Nov 2015 when
we last
> >>>>>>>> discussed this Lambert Conformal CF-compliant NetCDF issue.
> >>>>>>>>
> >>>>>>>> Also, I am still aware of a small bug in the lambert
conformal
> grid
> >>>> info
> >>>>>>>> that I need to fix and post a bugfix.
> >>>>>>>>
> >>>>>>>> John
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Mon, Mar 14, 2016 at 1:22 PM, Sarah Griffin via RT <
> >>>>>> met_help at ucar.edu>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=75519 >
> >>>>>>>>>
> >>>>>>>>> Hi John,
> >>>>>>>>>
> >>>>>>>>> I am incredibly confused.
> >>>>>>>>>
> >>>>>>>>> Removing longitude_of_projection_origin makes sense, and
I've
> done
> >>>>>> that.
> >>>>>>>>> I've put 2 new files into the incoming directory on the
ftp site:
> >>>>>>>>>
GRIB2.FSL.HRRR.1905141_Lambert.000Hour.SBT124.NTOP.201508011300
> and
> >>>>>>>>> remap_GOES-13.2015213.1300_75W.nc. MODE can run on these 2
files
> >>>> just
> >>>>>>>>> fine. I converted the 2 GRIB2 files in
> >>>>>>>>> incoming/irap/met_help/griffin_data/ to netcdf files, both
x's
> >> range
> >>>>>>>>> from 0 to 5394000. The x's of both remapped GOES
observation
> files
> >>>> also
> >>>>>>>>> range from 0 to 5394000. Yet, MODE will run on one pair
but not
> the
> >>>>>>>>> other. So could the 'x' variable still be the problem?
> >>>>>>>>>
> >>>>>>>>> Any ideas?
> >>>>>>>>> Sarah
> >>>>>>>>>
> >>>>>>>>> On 3/14/16 1:26 PM, John Halley Gotway via RT wrote:
> >>>>>>>>>> Sarah,
> >>>>>>>>>>
> >>>>>>>>>> The problem is in the grid specification for the CF-
compliant
> >> NetCDF
> >>>>>>>>> file you're using. Here's the Projection info from your
NetCDF
> >> file:
> >>>>>>>>>> int Projection(time) ;
> >>>>>>>>>> Projection:grid_mapping_name = "lambert_conformal_conic"
;
> >>>>>>>>>> Projection:standard_parallel = 38.5f ;
> >>>>>>>>>> Projection:longitude_of_central_meridian = 262.5f ;
> >>>>>>>>>> Projection:latitude_of_projection_origin = 21.138f ;
> >>>>>>>>>> Projection:longitude_of_projection_origin = -122.72f ;
> >>>>>>>>>>
> >>>>>>>>>> Compare this with the CF specification:
> >>>>>>>>>>
> >>
> http://cfconventions.org/cf-conventions/v1.6.0/cf-
conventions.html#_lambert_conformal
> >>>>>>>>>> And notice that "longitude_of_projection_origin" is not
> actually a
> >>>>>>>>> valid attribute.
> >>>>>>>>>> Instead, the CF convention specifies the reference
location at
> the
> >>>>>>>>> latitude of the origin and the longitude of the central
meridian.
> >>>> Then
> >>>>>> the
> >>>>>>>>> "x" and "y" variables are used to specify the location in
the
> grid
> >> of
> >>>>>> those
> >>>>>>>>> reference longitude and latitude values.
> >>>>>>>>>> I've talked to other engineers here and we think this is
pretty
> >>>>>>>>> ridiculous. It makes specifying grid information way
overly
> >>>>>> complicated.
> >>>>>>>>> But unfortunately, that's how the spec is written.
> >>>>>>>>>> To summarize, you should remove the
> >> "longitude_of_projection_origin"
> >>>>>>>>> attribute since it isn't valid or used. And you should
change the
> >>>>>> range of
> >>>>>>>>> values for x from:
> >>>>>>>>>> 0 ... 5394000 to
> >>>>>>>>>> -something ... +something
> >>>>>>>>>> And the 0 occurs at the x value which coincides with the
> longitude
> >>>> of
> >>>>>>>>> the central meridian.
> >>>>>>>>>> Unfortunately, I think I've also discovered a small bug
in the
> >>>> Lambert
> >>>>>>>>> Conformal grid code, where we've failed to put a longitude
value
> in
> >>>> the
> >>>>>>>>> correct range before using it.
> >>>>>>>>>> Confused yet?
> >>>>>>>>>>
> >>>>>>>>>> John
> >>>>>>>>> --
> >>>>>>>>>
> >>>>>>>>>
> >>
>
----------------------------------------------------------------------------
> >>>>>>>>> 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
> >>>>
> >>>>
> >>
>
----------------------------------------------------------------------------
> >>>>
> >>>>
> >>
> >> --
> >>
> >>
>
----------------------------------------------------------------------------
> >> 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
>
>
----------------------------------------------------------------------------
>
>
>
------------------------------------------------
More information about the Met_help
mailing list