[Met_help] [rt.rap.ucar.edu #79960] History for support for netcdf input files in regrid_data_plane
John Halley Gotway via RT
met_help at ucar.edu
Fri Apr 14 10:58:21 MDT 2017
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hello,
I'm trying to regrid a netcdf file using another as a target using regrid_data_plane and am getting an unknown file type error. The user manual suggests that this action should be possible, however, after digging into the code, I likely see why it doesn't recognize my files:
>from data2d_factory_utils.cc:
//
// List of file name extensions corresponding to these file types
//
static const char *gb_file_ext [] = { ".grib", ".grb", ".gb" };
static const int n_gb_file_ext = sizeof(gb_file_ext)/sizeof(*gb_file_ext);
static const char *gb2_file_ext [] = { ".grib2", ".grb2", ".gb2" };
static const int n_gb2_file_ext = sizeof(gb2_file_ext)/sizeof(*gb2_file_ext);
// static const char *nc_file_ext [] = { ".netcdf", ".ncf", ".nc" };
// static const int n_nc_file_ext = sizeof(nc_file_ext)/sizeof(*nc_file_ext);
static const char *bf_file_ext [] = { ".bufr", ".bfr", ".prepbufr", ".pb" };
static const int n_bf_file_ext = sizeof(bf_file_ext)/sizeof(*bf_file_ext);
Is this a case where the manual is getting ahead of the capabilities of the code? It looks like netcdf support is either incomplete or has otherwise been deactivated.
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.
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: support for netcdf input files in regrid_data_plane
From: John Halley Gotway
Time: Thu Mar 23 15:44:19 2017
John,
I can say with utmost confidence that the user manual is never ahead
of the
code ;)
MET supports 3 ways of determining the type of a file, listed in order
of
precedence...
(1) The user can explicitly tell the tools how to process the data
by
setting "file_type = ###;" in the configuration string (or file for
MET
tools that accept them), where #### is GRIB1, GRIB2, NETCDF_MET,
NETCDF_PINT, or NETCDF_NCCF.
(2) MET looks at the file extensions listed in
data2d_factory_utils.cc,
as you've found. Files using those suffixes are interpreted as those
types.
(3) If methods (1) and (2) are inconclusive, then MET opens up the
file
looking for a magic cookie in the first few bytes. GRIB1 and GRIB2
are
easy, but for NetCDF we look for particular global attributes to
indicate
the type.
If you'd like to force it to interpret the your data as CF-Compliant
NetCDF, you could try using: file_type = NETCDF_NCCF;
Hope that helps.
Thanks,
John Halley Gotway
On Thu, Mar 23, 2017 at 2:52 PM, jhenders at aer.com via RT
<met_help at ucar.edu>
wrote:
>
> Thu Mar 23 14:52:36 2017: Request 79960 was acted upon.
> Transaction: Ticket created by jhenders at aer.com
> Queue: met_help
> Subject: support for 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=79960 >
>
>
> Hello,
>
> I'm trying to regrid a netcdf file using another as a target using
> regrid_data_plane and am getting an unknown file type error. The
user
> manual suggests that this action should be possible, however, after
digging
> into the code, I likely see why it doesn't recognize my files:
>
> >from data2d_factory_utils.cc:
>
> //
> // List of file name extensions corresponding to these file types
> //
> static const char *gb_file_ext [] = { ".grib", ".grb", ".gb" };
> static const int n_gb_file_ext = sizeof(gb_file_ext)/sizeof(*
> gb_file_ext);
>
> static const char *gb2_file_ext [] = { ".grib2", ".grb2", ".gb2" };
> static const int n_gb2_file_ext = sizeof(gb2_file_ext)/sizeof(*
> gb2_file_ext);
>
> // static const char *nc_file_ext [] = { ".netcdf", ".ncf", ".nc" };
> // static const int n_nc_file_ext = sizeof(nc_file_ext)/sizeof(*
> nc_file_ext);
>
> static const char *bf_file_ext [] = { ".bufr", ".bfr", ".prepbufr",
".pb"
> };
> static const int n_bf_file_ext = sizeof(bf_file_ext)/sizeof(*
> bf_file_ext);
>
> Is this a case where the manual is getting ahead of the capabilities
of
> the code? It looks like netcdf support is either incomplete or has
> otherwise been deactivated.
>
> 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.
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #79960] support for netcdf input files in regrid_data_plane
From: jhenders at aer.com
Time: Fri Mar 24 12:52:57 2017
Hi John,
I checked the code and there don't seem to be any hooks to accept the
-file_type argument. Therefore, I don't see how your option (1) below
is ever used. That, the fact that option (2) is commented out for
netcdf format, and that regrid_data_plane doesn't accept a config
file, results in netcdf apparently not being supported.
(Ultimately, we are trying to regrid an input file that uses a datum
and not a spherical Earth as in WRF. But, that is another problem to
solve...)
Thanks.
John
On 3/23/17, 5:44 PM, "John Halley Gotway via RT" <met_help at ucar.edu>
wrote:
John,
I can say with utmost confidence that the user manual is never
ahead of the
code ;)
MET supports 3 ways of determining the type of a file, listed in
order of
precedence...
(1) The user can explicitly tell the tools how to process the
data by
setting "file_type = ###;" in the configuration string (or file
for MET
tools that accept them), where #### is GRIB1, GRIB2, NETCDF_MET,
NETCDF_PINT, or NETCDF_NCCF.
(2) MET looks at the file extensions listed in
data2d_factory_utils.cc,
as you've found. Files using those suffixes are interpreted as
those types.
(3) If methods (1) and (2) are inconclusive, then MET opens up
the file
looking for a magic cookie in the first few bytes. GRIB1 and
GRIB2 are
easy, but for NetCDF we look for particular global attributes to
indicate
the type.
If you'd like to force it to interpret the your data as CF-
Compliant
NetCDF, you could try using: file_type = NETCDF_NCCF;
Hope that helps.
Thanks,
John Halley Gotway
On Thu, Mar 23, 2017 at 2:52 PM, jhenders at aer.com via RT
<met_help at ucar.edu>
wrote:
>
> Thu Mar 23 14:52:36 2017: Request 79960 was acted upon.
> Transaction: Ticket created by jhenders at aer.com
> Queue: met_help
> Subject: support for 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=79960 >
>
>
> Hello,
>
> I'm trying to regrid a netcdf file using another as a target
using
> regrid_data_plane and am getting an unknown file type error. The
user
> manual suggests that this action should be possible, however,
after digging
> into the code, I likely see why it doesn't recognize my files:
>
> >from data2d_factory_utils.cc:
>
> //
> // List of file name extensions corresponding to these file
types
> //
> static const char *gb_file_ext [] = { ".grib", ".grb", ".gb" };
> static const int n_gb_file_ext = sizeof(gb_file_ext)/sizeof(*
> gb_file_ext);
>
> static const char *gb2_file_ext [] = { ".grib2", ".grb2", ".gb2"
};
> static const int n_gb2_file_ext =
sizeof(gb2_file_ext)/sizeof(*
> gb2_file_ext);
>
> // static const char *nc_file_ext [] = { ".netcdf", ".ncf",
".nc" };
> // static const int n_nc_file_ext =
sizeof(nc_file_ext)/sizeof(*
> nc_file_ext);
>
> static const char *bf_file_ext [] = { ".bufr", ".bfr",
".prepbufr", ".pb"
> };
> static const int n_bf_file_ext = sizeof(bf_file_ext)/sizeof(*
> bf_file_ext);
>
> Is this a case where the manual is getting ahead of the
capabilities of
> the code? It looks like netcdf support is either incomplete or
has
> otherwise been deactivated.
>
> 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.
------------------------------------------------
Subject: support for netcdf input files in regrid_data_plane
From: John Halley Gotway
Time: Tue Mar 28 16:51:02 2017
John,
Sorry for the confusion.
The "file_type" setting is not a command line option but is a config
file
option. It may either be specified in a config file passed to a MET
tool
or on the command line in a configuration string.
I see that you're using regrid_data_plane and let's say your NetCDF
file
includes a variable named "MyVar" with dimensions "(lat,lon)". Here's
an
example of calling regrid_data_plane to regrid to NCEP Grid 212:
met-5.2/bin/regrid_data_plane \
infile.nc G212 outfile.nc \
-field 'name="MyVar"; level="(*,*)"; file_type=NETCDF_NCCF;'
Notice that I've included "file_type" in my configuration string.
That
string is parsed as being a mini config file.
Hope that helps.
Thanks,
John
On Fri, Mar 24, 2017 at 12:52 PM, jhenders at aer.com via RT
<met_help at ucar.edu
> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79960 >
>
> Hi John,
>
> I checked the code and there don't seem to be any hooks to accept
the
> -file_type argument. Therefore, I don't see how your option (1)
below is
> ever used. That, the fact that option (2) is commented out for
netcdf
> format, and that regrid_data_plane doesn't accept a config file,
results in
> netcdf apparently not being supported.
>
> (Ultimately, we are trying to regrid an input file that uses a datum
and
> not a spherical Earth as in WRF. But, that is another problem to
solve...)
>
> Thanks.
>
> John
>
> On 3/23/17, 5:44 PM, "John Halley Gotway via RT" <met_help at ucar.edu>
> wrote:
>
> John,
>
> I can say with utmost confidence that the user manual is never
ahead
> of the
> code ;)
>
> MET supports 3 ways of determining the type of a file, listed in
order
> of
> precedence...
>
> (1) The user can explicitly tell the tools how to process the
data by
> setting "file_type = ###;" in the configuration string (or file
for MET
> tools that accept them), where #### is GRIB1, GRIB2, NETCDF_MET,
> NETCDF_PINT, or NETCDF_NCCF.
>
> (2) MET looks at the file extensions listed in
> data2d_factory_utils.cc,
> as you've found. Files using those suffixes are interpreted as
those
> types.
>
> (3) If methods (1) and (2) are inconclusive, then MET opens up
the
> file
> looking for a magic cookie in the first few bytes. GRIB1 and
GRIB2 are
> easy, but for NetCDF we look for particular global attributes to
> indicate
> the type.
>
> If you'd like to force it to interpret the your data as CF-
Compliant
> NetCDF, you could try using: file_type = NETCDF_NCCF;
>
> Hope that helps.
>
> Thanks,
> John Halley Gotway
>
>
>
>
> On Thu, Mar 23, 2017 at 2:52 PM, jhenders at aer.com via RT <
> met_help at ucar.edu>
> wrote:
>
> >
> > Thu Mar 23 14:52:36 2017: Request 79960 was acted upon.
> > Transaction: Ticket created by jhenders at aer.com
> > Queue: met_help
> > Subject: support for 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=79960 >
> >
> >
> > Hello,
> >
> > I'm trying to regrid a netcdf file using another as a target
using
> > regrid_data_plane and am getting an unknown file type error.
The user
> > manual suggests that this action should be possible, however,
after
> digging
> > into the code, I likely see why it doesn't recognize my files:
> >
> > >from data2d_factory_utils.cc:
> >
> > //
> > // List of file name extensions corresponding to these file
types
> > //
> > static const char *gb_file_ext [] = { ".grib", ".grb", ".gb"
};
> > static const int n_gb_file_ext =
sizeof(gb_file_ext)/sizeof(*
> > gb_file_ext);
> >
> > static const char *gb2_file_ext [] = { ".grib2", ".grb2",
".gb2" };
> > static const int n_gb2_file_ext =
sizeof(gb2_file_ext)/sizeof(*
> > gb2_file_ext);
> >
> > // static const char *nc_file_ext [] = { ".netcdf", ".ncf",
".nc" };
> > // static const int n_nc_file_ext =
sizeof(nc_file_ext)/sizeof(*
> > nc_file_ext);
> >
> > static const char *bf_file_ext [] = { ".bufr", ".bfr",
".prepbufr",
> ".pb"
> > };
> > static const int n_bf_file_ext =
sizeof(bf_file_ext)/sizeof(*
> > bf_file_ext);
> >
> > Is this a case where the manual is getting ahead of the
capabilities
> of
> > the code? It looks like netcdf support is either incomplete or
has
> > otherwise been deactivated.
> >
> > 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.
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #79960] support for netcdf input files in regrid_data_plane
From: jhenders at aer.com
Time: Thu Mar 30 14:04:48 2017
Thanks John. I can now get the code to recognize the -file_type
argument.
John
On 3/28/17, 6:51 PM, "John Halley Gotway via RT" <met_help at ucar.edu>
wrote:
John,
Sorry for the confusion.
The "file_type" setting is not a command line option but is a
config file
option. It may either be specified in a config file passed to a
MET tool
or on the command line in a configuration string.
I see that you're using regrid_data_plane and let's say your
NetCDF file
includes a variable named "MyVar" with dimensions "(lat,lon)".
Here's an
example of calling regrid_data_plane to regrid to NCEP Grid 212:
met-5.2/bin/regrid_data_plane \
infile.nc G212 outfile.nc \
-field 'name="MyVar"; level="(*,*)"; file_type=NETCDF_NCCF;'
Notice that I've included "file_type" in my configuration string.
That
string is parsed as being a mini config file.
Hope that helps.
Thanks,
John
On Fri, Mar 24, 2017 at 12:52 PM, jhenders at aer.com via RT
<met_help at ucar.edu
> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79960 >
>
> Hi John,
>
> I checked the code and there don't seem to be any hooks to
accept the
> -file_type argument. Therefore, I don't see how your option (1)
below is
> ever used. That, the fact that option (2) is commented out for
netcdf
> format, and that regrid_data_plane doesn't accept a config file,
results in
> netcdf apparently not being supported.
>
> (Ultimately, we are trying to regrid an input file that uses a
datum and
> not a spherical Earth as in WRF. But, that is another problem to
solve...)
>
> Thanks.
>
> John
>
> On 3/23/17, 5:44 PM, "John Halley Gotway via RT"
<met_help at ucar.edu>
> wrote:
>
> John,
>
> I can say with utmost confidence that the user manual is
never ahead
> of the
> code ;)
>
> MET supports 3 ways of determining the type of a file,
listed in order
> of
> precedence...
>
> (1) The user can explicitly tell the tools how to process
the data by
> setting "file_type = ###;" in the configuration string (or
file for MET
> tools that accept them), where #### is GRIB1, GRIB2,
NETCDF_MET,
> NETCDF_PINT, or NETCDF_NCCF.
>
> (2) MET looks at the file extensions listed in
> data2d_factory_utils.cc,
> as you've found. Files using those suffixes are interpreted
as those
> types.
>
> (3) If methods (1) and (2) are inconclusive, then MET
opens up the
> file
> looking for a magic cookie in the first few bytes. GRIB1
and GRIB2 are
> easy, but for NetCDF we look for particular global
attributes to
> indicate
> the type.
>
> If you'd like to force it to interpret the your data as CF-
Compliant
> NetCDF, you could try using: file_type = NETCDF_NCCF;
>
> Hope that helps.
>
> Thanks,
> John Halley Gotway
>
>
>
>
> On Thu, Mar 23, 2017 at 2:52 PM, jhenders at aer.com via RT <
> met_help at ucar.edu>
> wrote:
>
> >
> > Thu Mar 23 14:52:36 2017: Request 79960 was acted upon.
> > Transaction: Ticket created by jhenders at aer.com
> > Queue: met_help
> > Subject: support for 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=79960 >
> >
> >
> > Hello,
> >
> > I'm trying to regrid a netcdf file using another as a
target using
> > regrid_data_plane and am getting an unknown file type
error. The user
> > manual suggests that this action should be possible,
however, after
> digging
> > into the code, I likely see why it doesn't recognize my
files:
> >
> > >from data2d_factory_utils.cc:
> >
> > //
> > // List of file name extensions corresponding to these
file types
> > //
> > static const char *gb_file_ext [] = { ".grib", ".grb",
".gb" };
> > static const int n_gb_file_ext =
sizeof(gb_file_ext)/sizeof(*
> > gb_file_ext);
> >
> > static const char *gb2_file_ext [] = { ".grib2", ".grb2",
".gb2" };
> > static const int n_gb2_file_ext =
sizeof(gb2_file_ext)/sizeof(*
> > gb2_file_ext);
> >
> > // static const char *nc_file_ext [] = { ".netcdf",
".ncf", ".nc" };
> > // static const int n_nc_file_ext =
sizeof(nc_file_ext)/sizeof(*
> > nc_file_ext);
> >
> > static const char *bf_file_ext [] = { ".bufr", ".bfr",
".prepbufr",
> ".pb"
> > };
> > static const int n_bf_file_ext =
sizeof(bf_file_ext)/sizeof(*
> > bf_file_ext);
> >
> > Is this a case where the manual is getting ahead of the
capabilities
> of
> > the code? It looks like netcdf support is either
incomplete or has
> > otherwise been deactivated.
> >
> > 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.
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #79960] support for netcdf input files in regrid_data_plane
From: jhenders at aer.com
Time: Wed Apr 05 16:28:06 2017
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.
------------------------------------------------
Subject: support for netcdf input files in regrid_data_plane
From: John Halley Gotway
Time: Fri Apr 07 16:49:59 2017
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:
http://www.dtcenter.org/met/users/support/met_help.php#ftp
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://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79960 >
>
> 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.
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #79960] support for netcdf input files in regrid_data_plane
From: jhenders at aer.com
Time: Fri Apr 07 17:30:36 2017
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.
------------------------------------------------
Subject: support for netcdf input files in regrid_data_plane
From: John Halley Gotway
Time: Mon Apr 10 14:13:51 2017
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://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79960 >
>
> 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.
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #79960] support for netcdf input files in regrid_data_plane
From: jhenders at aer.com
Time: Mon Apr 10 14:21:18 2017
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.
------------------------------------------------
Subject: support for netcdf input files in regrid_data_plane
From: John Halley Gotway
Time: Mon Apr 10 14:37:22 2017
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://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79960 >
>
> 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.
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #79960] support for netcdf input files in regrid_data_plane
From: jhenders at aer.com
Time: Mon Apr 10 15:45:25 2017
John,
I agree that there must be something wrong with my projection info. I
had looked at the code, including error messages, and massaged the
supposedly CF-compliant wrf file but there is still something in the
MET code that isn't being fed the right info.
Thanks for looking into this.
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.
------------------------------------------------
More information about the Met_help
mailing list