[Met_help] [rt.rap.ucar.edu #80230] History for Support for lat/lon netcdf input files in regrid_data_plane

John Halley Gotway via RT met_help at ucar.edu
Wed May 10 12:01:36 MDT 2017


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

John,

I am now trying to input a lat/lon ncdf file to regrid_data_plane, but it doesn't look like that simple grid is supported. Is there any way that a regular lat/lon grid can be used as the input grid?

As well, it looks like a typo for the value of variable 'mercator_default_gridname' in the file
met-6.0/src/libcode/vx_data2d_nc_pinterp/get_pinterp_grid.cc

////////////////////////////////////////////////////////////////////////

static const char proj_att_name             [] = "MAP_PROJ_CHAR";
static const char ps_proj_att_name          [] = "Polar Stereographic";
static const char lambert_proj_att_name     [] = "Lambert Conformal";
static const char mercator_proj_att_name    [] = "Mercator";

static const char ps_proj_var_name          [] = "Polar_Stereographic";
static const char lambert_proj_var_name     [] = "Lambert_Conformal";
static const char mercator_proj_var_name    [] = "Mercator";

static const char nx_dimension_name         [] = "west_east";
static const char ny_dimension_name         [] = "south_north";

static const char ps_default_gridname       [] = "polar";
static const char lambert_default_gridname  [] = "lambert";
static const char mercator_default_gridname [] = "lambert";

static const double default_grib_radius_km     = 6371.20;


////////////////////////////////////////////////////////////////////////

Thanks.

John


On 4/10/17, 4:37 PM, "John Halley Gotway via RT" <met_help at ucar.edu> wrote:

    John,

    I suspect the reason why you're seeing different results from MET and
    ncview is that they're placing the data using different methods.

    The ncview utility likely reads the location information from the lat() and
    lon() variables and then plots data at those lat/lon's.  It doesn't
    actually instantiate a grid.

    However, MET is doing more than plotting data.  The projection info is
    required to do interpolation operations for the grid.  In the file you
    sent, the projection information likely doesn't result in the lat/lon
    values the file contains.

    Unfortunately, other than latlon projections, there's no well-defined
    method or converting a set of lat/lon values to the projection to which
    they correspond.  Wish there were as it would simplify a lot of these
    details.

    Thanks,
    John

    On Mon, Apr 10, 2017 at 2:21 PM, jhenders at aer.com via RT <met_help at ucar.edu>
    wrote:

    >
    > <URL:https://urldefense.proofpoint.com/v2/url?u=https-3A__rt.rap.ucar.edu_rt_Ticket_Display.html-3Fid-3D79960&d=DwIDaQ&c=birp9sjcGzT9DCP3EIAtLA&r=cwsO3u-EzDa8rEVrli7TzQ&m=5hTRj5lOV26iUIzu8obSs964AOnpN-Ny8A4tZBoPCE4&s=fHgcf5kiEfSP6mHdMpL39FA8SELhXMBcY4inCAZ0x2E&e= >
    >
    > Hi John,
    >
    > Yes, for unknown reasons MET does not place the domain correctly over the
    > SW US. Since ncdump and ncview show the correct placement, I was hoping
    > there might be something obvious to you in what MET is doing.
    >
    > In any case, I've managed to get wrf_interp to generate wrf files that are
    > placed properly by MET. Now I need to see what wrf_interp did to my raw
    > wrfout files to make them readable by MET. That'll form the set of changes
    > I need to make to my true input file.
    >
    > Thanks for your help.
    >
    > John
    >
    > On 4/10/17, 4:13 PM, "John Halley Gotway via RT" <met_help at ucar.edu>
    > wrote:
    >
    >     John,
    >
    >     OK, I ran it through plot_data_plane version 5.2:
    >        met-5.2/bin/plot_data_plane wrfout_d02_20161224000000-cf.nc tas.ps
    >     'name="tas"; level="(0,0,*,*)"; file_type=NETCDF_NCCF;'
    >
    >     While it ran without error, the plot looks really bad. See attached
    > plot
    >     (tas.png).  The data looks reasonable but I can't tell on what part of
    > the
    >     earth the map data resides.
    >
    >     To figure out where it lives, I ran regrid_data_plane to put it onto a
    >     global grid:
    >
    >     # Regrid
    >     met-5.2/bin/regrid_data_plane wrfout_d02_20161224000000-cf.nc G003
    >     tas_G003.nc -field 'name="tas"; level="(0,0,*,*)";
    > file_type=NETCDF_NCCF;'
    >
    >     # Plot
    >     met-5.2/bin/plot_data_plane tas_G003.nc tas_G003.ps 'name="tas";
    >     level="(*,*)";'
    >
    >     As you can see in the attached plot (tas_G003.png), MET thinks this
    > data
    >     lives over eastern Europe... and I'm guessing that's wrong.
    > Unfortunately,
    >     defining a non-latlon CF-compliant grid is really hard!
    >
    >     If all you really need is the grid definition from this file, I
    > recommend
    >     one of two things:
    >
    >     (1) Run the wrf_interp utility which is a pretty lightweight and easy
    > tool
    >     to run.
    >
    >     (2) Look at the wrfout attributes to figure out the definition of the
    > grid
    >     and use them to define the grid as a string in this format:
    >     //         - lambert Nx Ny lat_ll lon_ll lon_orient D_km R_km
    >     standard_parallel_1
    >     //           [standard_parallel_2]
    >
    >     Look in met-5.2/data/config/README and search for "lambert".
    >
    >     Thanks,
    >     John
    >
    >
    >
    >
    >
    >     On Fri, Apr 7, 2017 at 5:30 PM, jhenders at aer.com via RT <
    > met_help at ucar.edu>
    >     wrote:
    >
    >     >
    >     > <URL:https://urldefense.proofpoint.com/v2/url?u=https-> 3A__rt.rap.ucar.edu_rt_Ticket_Display.html-3Fid-3D79960&d=DwIBaQ&c=
    > birp9sjcGzT9DCP3EIAtLA&r=cwsO3u-EzDa8rEVrli7TzQ&m=
    > 3A3hkfr8YvQEvAeKxoThS90lYvhwdr7rIQl9a1nMnzk&s=
    > TG5Bu0RIHg9GvdmBSCXkoYvplNpOkJ3f5NbcQ_3pm4g&e= >
    >     >
    >     > Hi John,
    >     >
    >     > Thanks for the response. Ultimately I need to take a simple,
    > single-field
    >     > ncdf file and regrid using a wrfout file as the 'to-grid' file, with
    > output
    >     > in ncdf format. I thought a good first step in this overall effort,
    > since
    >     > I'm not very familiar with CF rules, would be to create a
    > CF-compliant WRF
    >     > file as input. (I believe that I might already have the 'to-grid'
    > wrfout
    >     > file in grib format, but I still need to be able to properly format
    > the
    >     > input ncdf file.)
    >     >
    >     > If you don't mind, could you please run the supposed CF-compliant
    > wrf file
    >     > (it's pretty bare boned) that I've placed as per your instructions?
    > If that
    >     > has serious problems, I could try wrf_interp to get a ncdf file that
    > is
    >     > clearly supported by MET.
    >     >
    >     > Thanks.
    >     >
    >     > John
    >     >
    >     > On 4/7/17, 6:49 PM, "John Halley Gotway via RT" <met_help at ucar.edu>
    > wrote:
    >     >
    >     >     John,
    >     >
    >     >     So you're trying to process the output from WRF in MET.
    >     >
    >     >     My first suggestion is always to use the Unified PostProcess
    > (UPP) to
    >     > read
    >     >     wrfout files and write GRIB1 or GRIB2 format.
    >     >
    >     >     I realize that some users would prefer not to run UPP, so they
    > could
    >     > use
    >     >     the wrf_interp utility to post-process ARW output instead.
    >     >
    >     >     MET is set up to read the NetCDF output of wrf_interp.
    >     >
    >     >     It sounds like you've written your own "post-processing" logic to
    >     > reformat
    >     >     WRFOUT into a cf-compliant format.  Unfortunately, I'm not an
    > expert
    >     > of the
    >     >     cf-conventions.  However, if you'd like to send me a sample data
    > file,
    >     > I
    >     >     could run it here and let you know what I'm seeing.
    >     >
    >     >     You could post it to our anonymous ftp site following these
    >     > instructions:
    >     >     https://urldefense.proofpoint.com/v2/url?u=http-3A__www.
    >     > dtcenter.org_met_users_support_met-5Fhelp.php-23ftp&d=DwIDaQ&c=
    >     > birp9sjcGzT9DCP3EIAtLA&r=cwsO3u-EzDa8rEVrli7TzQ&m=
    >     > kRXeZSIOW9t1zO62EiWWK0WmW21Aq3qHAVLUUbOD84Q&s=
    >     > r2Y3xKkocZpam8fbdlX7Sh2dYMBj7c9CntNr-j8ZBdY&e=
    >     >
    >     >     Thanks,
    >     >     John
    >     >
    >     >     On Wed, Apr 5, 2017 at 4:28 PM, jhenders at aer.com via RT <
    >     > met_help at ucar.edu>
    >     >     wrote:
    >     >
    >     >     >
    >     >     > <URL:https://urldefense.proofpoint.com/v2/url?u=https->
    > 3A__rt.rap.ucar.edu_rt_Ticket_Display.html-3Fid-3D79960&d=DwIDaQ&c=
    >     > birp9sjcGzT9DCP3EIAtLA&r=cwsO3u-EzDa8rEVrli7TzQ&m=
    >     > kRXeZSIOW9t1zO62EiWWK0WmW21Aq3qHAVLUUbOD84Q&s=
    >     > 9k8Bg6W1ChE6KzSD6JYX6PkIFCAUPmL7ayf-aXQNQzc&e= >
    >     >     >
    >     >     > Hello again John,
    >     >     >
    >     >     > Thanks for your earlier clarification.
    >     >     >
    >     >     > I'm now having problems with a regrid_data_plane test run in
    > which it
    >     >     > misidentifies where the WRF grids are positioned (supposed to
    > be
    >     > over the
    >     >     > SW US):
    >     >     >
    >     >     > ./regrid_data_plane wrfout_d02_2016122400-cf.nc
    >     >     > wrfout_d03_2016122400-cf.nc \
    >     >     > test-output-on-d03.nc -method BUDGET -log test.log.txt \
    >     >     > -field 'name="prls"; level="(1,*,*)";file_type=NETCDF_NCCF;'
    > -v 1000
    >     >     > -width 2
    >     >     >
    >     >     > DEBUG 1: Reading data file: wrfout_d02_2016122400-cf.nc
    >     >     > DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() ->
    > created new
    >     >     > Met2dDataFile object of type "FileType_NcCF".
    >     >     > DEBUG 4: NcCfFile::open() -> parsing units for the time
    > variable
    >     > "hours
    >     >     > since 1950-01-01_00:00:00"
    >     >     > DEBUG 4: parse_cf_time_string() -> parsed NetCDF CF convention
    > time
    >     > unit
    >     >     > string "hours since 1950-01-01_00:00:00" as a reference time of
    >     >     > 19500101_000000 and 3600 second(s) per time step.
    >     >     > DEBUG 4: NcCfFile::open() -> parsing units for the
    >     > forecast_reference_time
    >     >     > variable "hours since 1950-01-01_00:00:00"
    >     >     > DEBUG 4: parse_cf_time_string() -> parsed NetCDF CF convention
    > time
    >     > unit
    >     >     > string "hours since 1950-01-01_00:00:00" as a reference time of
    >     >     > 19500101_000000 and 3600 second(s) per time step.
    >     >     > DEBUG 2: Input grid: Projection: Lambert Conformal Nx: 207 Ny:
    > 150
    >     > Lat_LL:
    >     >     > 48.262 Lon_LL: -39.529 Lon_orient: -45.000 Alpha: 3113.924
    > Cone:
    >     > 0.630 Bx:
    >     >     > 102.0000 By: 1692.2901
    >     >     > ...
    >     >     >
    >     >     >
    >     >     > ncdump -h wrfout_d02_2016122400-cf.nc :
    >     >     >
    >     >     > netcdf wrfout_d02_2016122400-cf {
    >     >     > dimensions:
    >     >     >         x = 207 ;
    >     >     >         y = 150 ;
    >     >     >         time = UNLIMITED ; // (2 currently)
    >     >     >         height = 1 ;
    >     >     > variables:
    >     >     >         char Lambert_Conformal ;
    >     >     >                 Lambert_Conformal:grid_mapping_name =
    >     >     > "lambert_conformal_conic" ;
    >     >     >                 Lambert_Conformal:cone_type = "secant" ;
    >     >     >                 Lambert_Conformal:northern_parallel = "45.0" ;
    >     >     >                 Lambert_Conformal:southern_parallel = "33.0" ;
    >     >     >                 Lambert_Conformal:longitude_of_central_meridian
    > =
    >     >     > "-118.6" ;
    >     >     >                 Lambert_Conformal:latitude_of_projection_origin
    > =
    >     > "34.1" ;
    >     >     >                 Lambert_Conformal:standard_parallel = 33.f,
    > 45.f ;
    >     >     >
    >     >     > It took a bit of effort getting a CF-compliant WRF file and I
    > was
    >     >     > wondering if I have something wrong in the grid specification
    > in the
    >     > input
    >     >     > WRF file.
    >     >     >
    >     >     > Any help would be much appreciated.
    >     >     >
    >     >     > Thanks.
    >     >     >
    >     >     > John Henderson
    >     >     >
    >     >     >
    >     >     >
    >     >     > ________________________________
    >     >     >
    >     >     > This email is intended solely for the recipient. It may contain
    >     >     > privileged, proprietary or confidential information or
    > material. If
    >     > you are
    >     >     > not the intended recipient, please delete this email and any
    >     > attachments
    >     >     > and notify the sender of the error.
    >     >     >
    >     >     >
    >     >     >
    >     >
    >     >
    >     >
    >     >
    >     > ________________________________
    >     >
    >     > This email is intended solely for the recipient. It may contain
    >     > privileged, proprietary or confidential information or material. If
    > you are
    >     > not the intended recipient, please delete this email and any
    > attachments
    >     > and notify the sender of the error.
    >     >
    >     >
    >     >
    >
    >
    >
    >
    > ________________________________
    >
    > This email is intended solely for the recipient. It may contain
    > privileged, proprietary or confidential information or material. If you are
    > not the intended recipient, please delete this email and any attachments
    > and notify the sender of the error.
    >
    >
    >




________________________________

This email is intended solely for the recipient. It may contain privileged, proprietary or confidential information or material. If you are not the intended recipient, please delete this email and any attachments and notify the sender of the error.



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

Subject: Support for lat/lon netcdf input files in regrid_data_plane
From: John Halley Gotway
Time: Tue Apr 25 22:07:03 2017

John,

Thanks for letting us know about this typo.  I'm on travel all this
week
but will take a closer look when I get back into he office next
Monday.

Thanks,
John

On Fri, Apr 21, 2017 at 10:14 AM jhenders at aer.com via RT
<met_help at ucar.edu>
wrote:

>
> Fri Apr 21 08:14:33 2017: Request 80230 was acted upon.
> Transaction: Ticket created by jhenders at aer.com
>        Queue: met_help
>      Subject: Support for lat/lon netcdf input files in
regrid_data_plane
>        Owner: Nobody
>   Requestors: jhenders at aer.com
>       Status: new
>  Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80230 >
>
>
> John,
>
> I am now trying to input a lat/lon ncdf file to regrid_data_plane,
but it
> doesn't look like that simple grid is supported. Is there any way
that a
> regular lat/lon grid can be used as the input grid?
>
> As well, it looks like a typo for the value of variable
> 'mercator_default_gridname' in the file
> met-6.0/src/libcode/vx_data2d_nc_pinterp/get_pinterp_grid.cc
>
>
////////////////////////////////////////////////////////////////////////
>
> static const char proj_att_name             [] = "MAP_PROJ_CHAR";
> static const char ps_proj_att_name          [] = "Polar
Stereographic";
> static const char lambert_proj_att_name     [] = "Lambert
Conformal";
> static const char mercator_proj_att_name    [] = "Mercator";
>
> static const char ps_proj_var_name          [] =
"Polar_Stereographic";
> static const char lambert_proj_var_name     [] =
"Lambert_Conformal";
> static const char mercator_proj_var_name    [] = "Mercator";
>
> static const char nx_dimension_name         [] = "west_east";
> static const char ny_dimension_name         [] = "south_north";
>
> static const char ps_default_gridname       [] = "polar";
> static const char lambert_default_gridname  [] = "lambert";
> static const char mercator_default_gridname [] = "lambert";
>
> static const double default_grib_radius_km     = 6371.20;
>
>
>
////////////////////////////////////////////////////////////////////////
>
> Thanks.
>
> John
>
>
> On 4/10/17, 4:37 PM, "John Halley Gotway via RT" <met_help at ucar.edu>
> wrote:
>
>     John,
>
>     I suspect the reason why you're seeing different results from
MET and
>     ncview is that they're placing the data using different methods.
>
>     The ncview utility likely reads the location information from
the
> lat() and
>     lon() variables and then plots data at those lat/lon's.  It
doesn't
>     actually instantiate a grid.
>
>     However, MET is doing more than plotting data.  The projection
info is
>     required to do interpolation operations for the grid.  In the
file you
>     sent, the projection information likely doesn't result in the
lat/lon
>     values the file contains.
>
>     Unfortunately, other than latlon projections, there's no well-
defined
>     method or converting a set of lat/lon values to the projection
to which
>     they correspond.  Wish there were as it would simplify a lot of
these
>     details.
>
>     Thanks,
>     John
>
>     On Mon, Apr 10, 2017 at 2:21 PM, jhenders at aer.com via RT <
> met_help at ucar.edu>
>     wrote:
>
>     >
>     > <URL:
> https://urldefense.proofpoint.com/v2/url?u=https-
3A__rt.rap.ucar.edu_rt_Ticket_Display.html-3Fid-
3D79960&d=DwIDaQ&c=birp9sjcGzT9DCP3EIAtLA&r=cwsO3u-
EzDa8rEVrli7TzQ&m=5hTRj5lOV26iUIzu8obSs964AOnpN-
Ny8A4tZBoPCE4&s=fHgcf5kiEfSP6mHdMpL39FA8SELhXMBcY4inCAZ0x2E&e=
> >
>     >
>     > Hi John,
>     >
>     > Yes, for unknown reasons MET does not place the domain
correctly
> over the
>     > SW US. Since ncdump and ncview show the correct placement, I
was
> hoping
>     > there might be something obvious to you in what MET is doing.
>     >
>     > In any case, I've managed to get wrf_interp to generate wrf
files
> that are
>     > placed properly by MET. Now I need to see what wrf_interp did
to my
> raw
>     > wrfout files to make them readable by MET. That'll form the
set of
> changes
>     > I need to make to my true input file.
>     >
>     > Thanks for your help.
>     >
>     > John
>     >
>     > On 4/10/17, 4:13 PM, "John Halley Gotway via RT"
<met_help at ucar.edu>
>     > wrote:
>     >
>     >     John,
>     >
>     >     OK, I ran it through plot_data_plane version 5.2:
>     >        met-5.2/bin/plot_data_plane wrfout_d02_20161224000000-
cf.nc
> tas.ps
>     >     'name="tas"; level="(0,0,*,*)"; file_type=NETCDF_NCCF;'
>     >
>     >     While it ran without error, the plot looks really bad. See
> attached
>     > plot
>     >     (tas.png).  The data looks reasonable but I can't tell on
what
> part of
>     > the
>     >     earth the map data resides.
>     >
>     >     To figure out where it lives, I ran regrid_data_plane to
put it
> onto a
>     >     global grid:
>     >
>     >     # Regrid
>     >     met-5.2/bin/regrid_data_plane wrfout_d02_20161224000000-
cf.nc
> G003
>     >     tas_G003.nc -field 'name="tas"; level="(0,0,*,*)";
>     > file_type=NETCDF_NCCF;'
>     >
>     >     # Plot
>     >     met-5.2/bin/plot_data_plane tas_G003.nc tas_G003.ps
'name="tas";
>     >     level="(*,*)";'
>     >
>     >     As you can see in the attached plot (tas_G003.png), MET
thinks
> this
>     > data
>     >     lives over eastern Europe... and I'm guessing that's
wrong.
>     > Unfortunately,
>     >     defining a non-latlon CF-compliant grid is really hard!
>     >
>     >     If all you really need is the grid definition from this
file, I
>     > recommend
>     >     one of two things:
>     >
>     >     (1) Run the wrf_interp utility which is a pretty
lightweight and
> easy
>     > tool
>     >     to run.
>     >
>     >     (2) Look at the wrfout attributes to figure out the
definition
> of the
>     > grid
>     >     and use them to define the grid as a string in this
format:
>     >     //         - lambert Nx Ny lat_ll lon_ll lon_orient D_km
R_km
>     >     standard_parallel_1
>     >     //           [standard_parallel_2]
>     >
>     >     Look in met-5.2/data/config/README and search for
"lambert".
>     >
>     >     Thanks,
>     >     John
>     >
>     >
>     >
>     >
>     >
>     >     On Fri, Apr 7, 2017 at 5:30 PM, jhenders at aer.com via RT <
>     > met_help at ucar.edu>
>     >     wrote:
>     >
>     >     >
>     >     > <URL:https://urldefense.proofpoint.com/v2/url?u=https->
> 3A__rt.rap.ucar.edu_rt_Ticket_Display.html-3Fid-3D79960&d=DwIBaQ&c=
>     > birp9sjcGzT9DCP3EIAtLA&r=cwsO3u-EzDa8rEVrli7TzQ&m=
>     > 3A3hkfr8YvQEvAeKxoThS90lYvhwdr7rIQl9a1nMnzk&s=
>     > TG5Bu0RIHg9GvdmBSCXkoYvplNpOkJ3f5NbcQ_3pm4g&e= >
>     >     >
>     >     > Hi John,
>     >     >
>     >     > Thanks for the response. Ultimately I need to take a
simple,
>     > single-field
>     >     > ncdf file and regrid using a wrfout file as the 'to-
grid'
> file, with
>     > output
>     >     > in ncdf format. I thought a good first step in this
overall
> effort,
>     > since
>     >     > I'm not very familiar with CF rules, would be to create
a
>     > CF-compliant WRF
>     >     > file as input. (I believe that I might already have the
> 'to-grid'
>     > wrfout
>     >     > file in grib format, but I still need to be able to
properly
> format
>     > the
>     >     > input ncdf file.)
>     >     >
>     >     > If you don't mind, could you please run the supposed
> CF-compliant
>     > wrf file
>     >     > (it's pretty bare boned) that I've placed as per your
> instructions?
>     > If that
>     >     > has serious problems, I could try wrf_interp to get a
ncdf
> file that
>     > is
>     >     > clearly supported by MET.
>     >     >
>     >     > Thanks.
>     >     >
>     >     > John
>     >     >
>     >     > On 4/7/17, 6:49 PM, "John Halley Gotway via RT" <
> met_help at ucar.edu>
>     > wrote:
>     >     >
>     >     >     John,
>     >     >
>     >     >     So you're trying to process the output from WRF in
MET.
>     >     >
>     >     >     My first suggestion is always to use the Unified
> PostProcess
>     > (UPP) to
>     >     > read
>     >     >     wrfout files and write GRIB1 or GRIB2 format.
>     >     >
>     >     >     I realize that some users would prefer not to run
UPP, so
> they
>     > could
>     >     > use
>     >     >     the wrf_interp utility to post-process ARW output
instead.
>     >     >
>     >     >     MET is set up to read the NetCDF output of
wrf_interp.
>     >     >
>     >     >     It sounds like you've written your own "post-
processing"
> logic to
>     >     > reformat
>     >     >     WRFOUT into a cf-compliant format.  Unfortunately,
I'm not
> an
>     > expert
>     >     > of the
>     >     >     cf-conventions.  However, if you'd like to send me a
> sample data
>     > file,
>     >     > I
>     >     >     could run it here and let you know what I'm seeing.
>     >     >
>     >     >     You could post it to our anonymous ftp site
following these
>     >     > instructions:
>     >     >     https://urldefense.proofpoint.com/v2/url?u=http-
3A__www.
>     >     > dtcenter.org_met_users_support_met-5Fhelp.php-
23ftp&d=DwIDaQ&c=
>     >     > birp9sjcGzT9DCP3EIAtLA&r=cwsO3u-EzDa8rEVrli7TzQ&m=
>     >     > kRXeZSIOW9t1zO62EiWWK0WmW21Aq3qHAVLUUbOD84Q&s=
>     >     > r2Y3xKkocZpam8fbdlX7Sh2dYMBj7c9CntNr-j8ZBdY&e=
>     >     >
>     >     >     Thanks,
>     >     >     John
>     >     >
>     >     >     On Wed, Apr 5, 2017 at 4:28 PM, jhenders at aer.com via
RT <
>     >     > met_help at ucar.edu>
>     >     >     wrote:
>     >     >
>     >     >     >
>     >     >     >
<URL:https://urldefense.proofpoint.com/v2/url?u=https->
>     > 3A__rt.rap.ucar.edu_rt_Ticket_Display.html-3Fid-
3D79960&d=DwIDaQ&c=
>     >     > birp9sjcGzT9DCP3EIAtLA&r=cwsO3u-EzDa8rEVrli7TzQ&m=
>     >     > kRXeZSIOW9t1zO62EiWWK0WmW21Aq3qHAVLUUbOD84Q&s=
>     >     > 9k8Bg6W1ChE6KzSD6JYX6PkIFCAUPmL7ayf-aXQNQzc&e= >
>     >     >     >
>     >     >     > Hello again John,
>     >     >     >
>     >     >     > Thanks for your earlier clarification.
>     >     >     >
>     >     >     > I'm now having problems with a regrid_data_plane
test
> run in
>     > which it
>     >     >     > misidentifies where the WRF grids are positioned
> (supposed to
>     > be
>     >     > over the
>     >     >     > SW US):
>     >     >     >
>     >     >     > ./regrid_data_plane wrfout_d02_2016122400-cf.nc
>     >     >     > wrfout_d03_2016122400-cf.nc \
>     >     >     > test-output-on-d03.nc -method BUDGET -log
test.log.txt \
>     >     >     > -field 'name="prls";
> level="(1,*,*)";file_type=NETCDF_NCCF;'
>     > -v 1000
>     >     >     > -width 2
>     >     >     >
>     >     >     > DEBUG 1: Reading data file: wrfout_d02_2016122400-
cf.nc
>     >     >     > DEBUG 4:
Met2dDataFileFactory::new_met_2d_data_file() ->
>     > created new
>     >     >     > Met2dDataFile object of type "FileType_NcCF".
>     >     >     > DEBUG 4: NcCfFile::open() -> parsing units for the
time
>     > variable
>     >     > "hours
>     >     >     > since 1950-01-01_00:00:00"
>     >     >     > DEBUG 4: parse_cf_time_string() -> parsed NetCDF
CF
> convention
>     > time
>     >     > unit
>     >     >     > string "hours since 1950-01-01_00:00:00" as a
reference
> time of
>     >     >     > 19500101_000000 and 3600 second(s) per time step.
>     >     >     > DEBUG 4: NcCfFile::open() -> parsing units for the
>     >     > forecast_reference_time
>     >     >     > variable "hours since 1950-01-01_00:00:00"
>     >     >     > DEBUG 4: parse_cf_time_string() -> parsed NetCDF
CF
> convention
>     > time
>     >     > unit
>     >     >     > string "hours since 1950-01-01_00:00:00" as a
reference
> time of
>     >     >     > 19500101_000000 and 3600 second(s) per time step.
>     >     >     > DEBUG 2: Input grid: Projection: Lambert Conformal
Nx:
> 207 Ny:
>     > 150
>     >     > Lat_LL:
>     >     >     > 48.262 Lon_LL: -39.529 Lon_orient: -45.000 Alpha:
> 3113.924
>     > Cone:
>     >     > 0.630 Bx:
>     >     >     > 102.0000 By: 1692.2901
>     >     >     > ...
>     >     >     >
>     >     >     >
>     >     >     > ncdump -h wrfout_d02_2016122400-cf.nc :
>     >     >     >
>     >     >     > netcdf wrfout_d02_2016122400-cf {
>     >     >     > dimensions:
>     >     >     >         x = 207 ;
>     >     >     >         y = 150 ;
>     >     >     >         time = UNLIMITED ; // (2 currently)
>     >     >     >         height = 1 ;
>     >     >     > variables:
>     >     >     >         char Lambert_Conformal ;
>     >     >     >
Lambert_Conformal:grid_mapping_name =
>     >     >     > "lambert_conformal_conic" ;
>     >     >     >                 Lambert_Conformal:cone_type =
"secant" ;
>     >     >     >
Lambert_Conformal:northern_parallel =
> "45.0" ;
>     >     >     >
Lambert_Conformal:southern_parallel =
> "33.0" ;
>     >     >     >
>  Lambert_Conformal:longitude_of_central_meridian
>     > =
>     >     >     > "-118.6" ;
>     >     >     >
>  Lambert_Conformal:latitude_of_projection_origin
>     > =
>     >     > "34.1" ;
>     >     >     >
Lambert_Conformal:standard_parallel =
> 33.f,
>     > 45.f ;
>     >     >     >
>     >     >     > It took a bit of effort getting a CF-compliant WRF
file
> and I
>     > was
>     >     >     > wondering if I have something wrong in the grid
> specification
>     > in the
>     >     > input
>     >     >     > WRF file.
>     >     >     >
>     >     >     > Any help would be much appreciated.
>     >     >     >
>     >     >     > Thanks.
>     >     >     >
>     >     >     > John Henderson
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     > ________________________________
>     >     >     >
>     >     >     > This email is intended solely for the recipient.
It may
> contain
>     >     >     > privileged, proprietary or confidential
information or
>     > material. If
>     >     > you are
>     >     >     > not the intended recipient, please delete this
email and
> any
>     >     > attachments
>     >     >     > and notify the sender of the error.
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >
>     >     >
>     >     >
>     >     >
>     >     > ________________________________
>     >     >
>     >     > This email is intended solely for the recipient. It may
contain
>     >     > privileged, proprietary or confidential information or
> material. If
>     > you are
>     >     > not the intended recipient, please delete this email and
any
>     > attachments
>     >     > and notify the sender of the error.
>     >     >
>     >     >
>     >     >
>     >
>     >
>     >
>     >
>     > ________________________________
>     >
>     > This email is intended solely for the recipient. It may
contain
>     > privileged, proprietary or confidential information or
material. If
> you are
>     > not the intended recipient, please delete this email and any
> attachments
>     > and notify the sender of the error.
>     >
>     >
>     >
>
>
>
>
> ________________________________
>
> This email is intended solely for the recipient. It may contain
> privileged, proprietary or confidential information or material. If
you are
> not the intended recipient, please delete this email and any
attachments
> and notify the sender of the error.
>
>
>

------------------------------------------------
Subject: Support for lat/lon netcdf input files in regrid_data_plane
From: John Halley Gotway
Time: Mon May 01 14:08:40 2017

John,

Sorry for the delayed response.  I was out of the office last week.

And thanks for pointing out the bug in the default Mercator grid name
in
the vx_data2d_nc_pinterp library.  I fixed it in the development
version
and in the bugfix branch for version 6.0.  So it'll be included in the
next
set of bugfixes for 6.0.

Yes, MET definitely supports simple lat/lon grids.  The confusion here
is
that MET supports 3 different flavors of NetCDF:

(1) The output of the pinterp (or newer wrf_interp) utility (in MET
internal library named vx_data2d_nc_pinterp).
(2) CF-compliant NetCDF files (in MET internal library named
vx_data2d_nccf).
(3) The internal NetCDF format written by the MET tools (in MET
internal
library vx_data2d_nc_met).

There are different conventions for how to specify grid information
for
each flavor of NetCDF.

I see that you want to pass a NetCDF file on a simple lat/lon to
regrid_data_plane.  I'd suggest telling MET to interpret it as a
CF-compliant file.  When you do that, MET tries to read projection
info in
a CF-compliant way, but if it's not present, it'll figure out the
lat/lon
spacing by interrogating the lat/lon variables.  Your call to
regrid_data_plane will look something like this:

regrid_data_plane in.nc G212 out.nc -field 'name="TMP"; level="(*,*)";
file_type=NETCDF_NCCF;'

Note that I'm using the "file_type" option to tell MET how process the
input NetCDF file.  If your input file has a global "Conventions"
attribute
set to "CF-*", then MET will interpret it as CF-compliant by default.
The
"file_type" config entry overrides any defaults.

Hope that helps.

John


On Tue, Apr 25, 2017 at 10:07 PM, The RT System itself via RT <
met_help at ucar.edu> wrote:

>
> Tue Apr 25 22:07:03 2017: Request 80230 was acted upon.
> Transaction: Given to johnhg (John Halley Gotway) by RT_System
>        Queue: met_help
>      Subject: Support for lat/lon netcdf input files in
regrid_data_plane
>        Owner: johnhg
>   Requestors: jhenders at aer.com
>       Status: new
>  Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80230 >
>
>
> This transaction appears to have no content
>

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


More information about the Met_help mailing list