[Met_help] [rt.rap.ucar.edu #81134] History for problem reading netdcf file
John Halley Gotway via RT
met_help at ucar.edu
Wed Aug 9 10:12:58 MDT 2017
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
MET Help:
I am getting the following warning/errors when trying to apply the MET gridstat program to a netcdf file that was created from a grib2 file via ncl_convert2nc:
Inline image 1
I have attached an ncdump output file. The full file could be accessed via anonymous ftp at:
ftp.gfdl.noaa.gov
cd /pub/wfs
The file name is: PRATEsfc6all.nc
I notice that there are no specific lat and lon data listed in the ncdump, but a detailed description of the grid coordinates is included in the netcdf meta data.
The reason for converting to netcdf, is that there was a need to further process the original GRIB2 file and I am much more familiar with tools to manipulate nc files than tools for working with GRIB files. I would appreciate some guidance.
Thanks,
Bill
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: problem reading netdcf file
From: John Halley Gotway
Time: Fri Jul 07 10:44:12 2017
Hi Bill,
I moved your question over into the MET-Help support ticketing system.
I see that you're having trouble processing the NetCDF output of the
ncl_convert2nc utility in MET. MET is only set up to read a handful
of NetCDF file formats, and unfortunately, the output of
ncl_convert2nc is not one of them. The 3 NetCDF flavors that MET
reads are CF-complaint (climate-forecast convention) files, the output
of the wrf_interp utility, and the internal NetCDF format written by
the MET tools themselves.
I understand that you'd like to do additional processing on the
precipitation rate data... and NetCDF is much easier to work with than
GRIB2.
Rather than using ncl_convert2nc to reformat the GRIB2 data, let's use
the MET regrid_data_plane tool instead. I'll demonstrate this below.
# I'll start with a sample GRIB2 GFS file that includes PRATE:
wgrib2 gfs_2012040900_F012.grib2 | grep PRATE
199:37137213:d=2012040900:PRATE:surface:6-12 hour ave fcst:
# Call regrid_data_plane using the -field option to select the PRATE
record
/usr/local/met-6.0/bin/regrid_data_plane \
gfs_2012040900_F012.grib2 gfs_2012040900_F012.grib2 prate.nc \
-field 'name="PRATE"; level="A6";'
DEBUG 1: Reading data file: gfs_2012040900_F012.grib2
DEBUG 2: Input grid: Projection: Lat/Lon Nx: 720 Ny: 361 lat_ll:
-90.000 lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
DEBUG 2: Output grid: Projection: Lat/Lon Nx: 720 Ny: 361 lat_ll:
-90.000 lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
DEBUG 2: Interpolation options: method = NEAREST, width = 1, shape =
SQUARE, vld_thresh = 0.5
DEBUG 2: Range of input data (name="PRATE"; level="A6";) is 0 to
0.004075.
DEBUG 2: Range of regridded data (name="PRATE"; level="A6";) is 0 to
0.004075.
DEBUG 1: Writing output file: prate.nc
Since the input and output grids are the same, no re-gridding is
actually being done. You could have also used the pcp_combine tool to
do the same thing. But the nice thing about regrid_data_plane is that
you could include multiple fields in the output by using the "-field"
command line option multiple times.
Then you can edit the NetCDF output of regrid_data_plane however you'd
like, and MET should be able to read that file.
Hope that helps.
Thanks,
John
------------------------------------------------
Subject: problem reading netdcf file
From: bill.stern at noaa.gov
Time: Fri Jul 07 17:50:28 2017
Thank you John! I will give regrid_data_plane a try.
Best regards,
Bill
On Fri, Jul 7, 2017 at 12:44 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Hi Bill,
>
> I moved your question over into the MET-Help support ticketing
system.
>
> I see that you're having trouble processing the NetCDF output of the
> ncl_convert2nc utility in MET. MET is only set up to read a handful
of
> NetCDF file formats, and unfortunately, the output of ncl_convert2nc
is not
> one of them. The 3 NetCDF flavors that MET reads are CF-complaint
> (climate-forecast convention) files, the output of the wrf_interp
utility,
> and the internal NetCDF format written by the MET tools themselves.
>
> I understand that you'd like to do additional processing on the
> precipitation rate data... and NetCDF is much easier to work with
than
> GRIB2.
>
> Rather than using ncl_convert2nc to reformat the GRIB2 data, let's
use the
> MET regrid_data_plane tool instead. I'll demonstrate this below.
>
> # I'll start with a sample GRIB2 GFS file that includes PRATE:
>
> wgrib2 gfs_2012040900_F012.grib2 | grep PRATE
> 199:37137213:d=2012040900:PRATE:surface:6-12 hour ave fcst:
>
> # Call regrid_data_plane using the -field option to select the PRATE
record
>
> /usr/local/met-6.0/bin/regrid_data_plane \
> gfs_2012040900_F012.grib2 gfs_2012040900_F012.grib2 prate.nc \
> -field 'name="PRATE"; level="A6";'
>
> DEBUG 1: Reading data file: gfs_2012040900_F012.grib2
> DEBUG 2: Input grid: Projection: Lat/Lon Nx: 720 Ny: 361 lat_ll:
-90.000
> lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> DEBUG 2: Output grid: Projection: Lat/Lon Nx: 720 Ny: 361 lat_ll:
-90.000
> lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> DEBUG 2: Interpolation options: method = NEAREST, width = 1, shape =
> SQUARE, vld_thresh = 0.5
> DEBUG 2: Range of input data (name="PRATE"; level="A6";) is 0 to
0.004075.
> DEBUG 2: Range of regridded data (name="PRATE"; level="A6";) is 0 to
> 0.004075.
> DEBUG 1: Writing output file: prate.nc
>
> Since the input and output grids are the same, no re-gridding is
actually
> being done. You could have also used the pcp_combine tool to do the
same
> thing. But the nice thing about regrid_data_plane is that you could
> include multiple fields in the output by using the "-field" command
line
> option multiple times.
>
> Then you can edit the NetCDF output of regrid_data_plane however
you'd
> like, and MET should be able to read that file.
>
> Hope that helps.
>
> Thanks,
> John
>
--
Bill Stern, Meteorologist
Room 206
NOAA/Geophysical Fluid Dynamics Laboratory
Princeton University Forrestal Campus
201 Forrestal Road Princeton, NJ 08540-6649
Tel: (609)452-6545
Fax: (609)987-5063
------------------------------
------------------------------------
Email Address: bill.stern at noaa.gov
------------------------------------------------------------------
Anonymous ftp Address: ftp.gfdl.noaa.gov
------------------------------------------------------------------
On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-gfdl-noaa
------------------------------------------------------------------
------------------------------------------------
Subject: problem reading netdcf file
From: bill.stern at noaa.gov
Time: Mon Jul 10 07:33:49 2017
Hi John,
I have followed your example of applying regrid_data_plane for
creating a
netcdf file from a grib2. The command below does create a netcdf, but
I am
only seem to be getting a single time level on the netcdf file, while
the
grib2 file has 21 time levels. Here is my regrid_data_plane command:
regrid_data_plane nam.2017051500.conusnest.hires.tm00.grib2
nam.2017051500.conusnest.hires.tm00.grib2
nam.2017051500.conusnest.APCP.nc
-field 'name = "APCP";level="A3";'
What am I missing?
Thanks,
Bill
On Fri, Jul 7, 2017 at 12:44 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Hi Bill,
>
> I moved your question over into the MET-Help support ticketing
system.
>
> I see that you're having trouble processing the NetCDF output of the
> ncl_convert2nc utility in MET. MET is only set up to read a handful
of
> NetCDF file formats, and unfortunately, the output of ncl_convert2nc
is not
> one of them. The 3 NetCDF flavors that MET reads are CF-complaint
> (climate-forecast convention) files, the output of the wrf_interp
utility,
> and the internal NetCDF format written by the MET tools themselves.
>
> I understand that you'd like to do additional processing on the
> precipitation rate data... and NetCDF is much easier to work with
than
> GRIB2.
>
> Rather than using ncl_convert2nc to reformat the GRIB2 data, let's
use the
> MET regrid_data_plane tool instead. I'll demonstrate this below.
>
> # I'll start with a sample GRIB2 GFS file that includes PRATE:
>
> wgrib2 gfs_2012040900_F012.grib2 | grep PRATE
> 199:37137213:d=2012040900:PRATE:surface:6-12 hour ave fcst:
>
> # Call regrid_data_plane using the -field option to select the PRATE
record
>
> /usr/local/met-6.0/bin/regrid_data_plane \
> gfs_2012040900_F012.grib2 gfs_2012040900_F012.grib2 prate.nc \
> -field 'name="PRATE"; level="A6";'
>
> DEBUG 1: Reading data file: gfs_2012040900_F012.grib2
> DEBUG 2: Input grid: Projection: Lat/Lon Nx: 720 Ny: 361 lat_ll:
-90.000
> lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> DEBUG 2: Output grid: Projection: Lat/Lon Nx: 720 Ny: 361 lat_ll:
-90.000
> lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> DEBUG 2: Interpolation options: method = NEAREST, width = 1, shape =
> SQUARE, vld_thresh = 0.5
> DEBUG 2: Range of input data (name="PRATE"; level="A6";) is 0 to
0.004075.
> DEBUG 2: Range of regridded data (name="PRATE"; level="A6";) is 0 to
> 0.004075.
> DEBUG 1: Writing output file: prate.nc
>
> Since the input and output grids are the same, no re-gridding is
actually
> being done. You could have also used the pcp_combine tool to do the
same
> thing. But the nice thing about regrid_data_plane is that you could
> include multiple fields in the output by using the "-field" command
line
> option multiple times.
>
> Then you can edit the NetCDF output of regrid_data_plane however
you'd
> like, and MET should be able to read that file.
>
> Hope that helps.
>
> Thanks,
> John
>
--
Bill Stern, Meteorologist
Room 206
NOAA/Geophysical Fluid Dynamics Laboratory
Princeton University Forrestal Campus
201 Forrestal Road Princeton, NJ 08540-6649
Tel: (609)452-6545
Fax: (609)987-5063
------------------------------
------------------------------------
Email Address: bill.stern at noaa.gov
------------------------------------------------------------------
Anonymous ftp Address: ftp.gfdl.noaa.gov
------------------------------------------------------------------
On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-gfdl-noaa
------------------------------------------------------------------
------------------------------------------------
Subject: problem reading netdcf file
From: John Halley Gotway
Time: Mon Jul 10 12:27:46 2017
Bill,
Ah, I understand. The regrid_data_plane tool is designed to read
exactly
one 2D data field for each "-field" entry you specify on the command
line.
When you ran it on a file containing 21 times, you probably got a
warning
about "multiple matching fields". By default, it'll just use the
first
match found.
You can include additional timing information in the "-field" entry to
specify which of the 21 times you actually want. Here's an excerpt
from
the met-6.0/data/config/README file about this:
// - The "init_time" entry specifies the initialization time in
YYYYMMDD[_HH[MMSS]]
// format. This entry can be included in the "fcst" entry as
shown
below or
// included in the "field" entry if the user would like to use
different
// initialization times for different fields.
//
// - The "valid_time" entry specifies the valid time in
YYYYMMDD[_HH[MMSS]]
// format. This entry can be included in the "fcst" entry as
shown
below or
// included in the "field" entry if the user would like to use
different
// valid times for different fields.
//
// - The "lead_time" entry specifies the lead time in HH[MMSS]
// format. This entry can be included in the "fcst" entry as
shown
below or
// included in the "field" entry if the user would like to use
different
// lead times for different fields.
So you could try running adding the "valid_time":
/usr/local/met-6.0/bin/regrid_data_plane \
gfs_2012040900_F012.grib2 gfs_2012040900_F012.grib2 prate.nc \
-field 'name="PRATE"; level="A6"; valid_time="20120409_120000";'
Technically, you could run regrid_data_plane once on each input file,
pass
in 21 "-field" settings, and write a single output file. But you'll
get an
error because it'll try to write the same NetCDF variable name
multiple
times. You could get around that by using the "-name" option to
passing in
21 unique output variables names... but that's a whole lot of details.
Instead, I'd suggest running regrid_data_plane once for each 3-hourly
output time and specify the "valid_time" currently being processed. I
think that logic would be cleaner.
Hope that helps.
Thanks,
John
On Mon, Jul 10, 2017 at 7:33 AM, bill.stern at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
>
> Hi John,
>
> I have followed your example of applying regrid_data_plane for
creating a
> netcdf file from a grib2. The command below does create a netcdf,
but I am
> only seem to be getting a single time level on the netcdf file,
while the
> grib2 file has 21 time levels. Here is my regrid_data_plane
command:
>
> regrid_data_plane nam.2017051500.conusnest.hires.tm00.grib2
> nam.2017051500.conusnest.hires.tm00.grib2
nam.2017051500.conusnest.APCP.nc
> -field 'name = "APCP";level="A3";'
>
> What am I missing?
>
> Thanks,
> Bill
>
> On Fri, Jul 7, 2017 at 12:44 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Hi Bill,
> >
> > I moved your question over into the MET-Help support ticketing
system.
> >
> > I see that you're having trouble processing the NetCDF output of
the
> > ncl_convert2nc utility in MET. MET is only set up to read a
handful of
> > NetCDF file formats, and unfortunately, the output of
ncl_convert2nc is
> not
> > one of them. The 3 NetCDF flavors that MET reads are CF-complaint
> > (climate-forecast convention) files, the output of the wrf_interp
> utility,
> > and the internal NetCDF format written by the MET tools
themselves.
> >
> > I understand that you'd like to do additional processing on the
> > precipitation rate data... and NetCDF is much easier to work with
than
> > GRIB2.
> >
> > Rather than using ncl_convert2nc to reformat the GRIB2 data, let's
use
> the
> > MET regrid_data_plane tool instead. I'll demonstrate this below.
> >
> > # I'll start with a sample GRIB2 GFS file that includes PRATE:
> >
> > wgrib2 gfs_2012040900_F012.grib2 | grep PRATE
> > 199:37137213:d=2012040900:PRATE:surface:6-12 hour ave fcst:
> >
> > # Call regrid_data_plane using the -field option to select the
PRATE
> record
> >
> > /usr/local/met-6.0/bin/regrid_data_plane \
> > gfs_2012040900_F012.grib2 gfs_2012040900_F012.grib2 prate.nc \
> > -field 'name="PRATE"; level="A6";'
> >
> > DEBUG 1: Reading data file: gfs_2012040900_F012.grib2
> > DEBUG 2: Input grid: Projection: Lat/Lon Nx: 720 Ny: 361 lat_ll:
-90.000
> > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> > DEBUG 2: Output grid: Projection: Lat/Lon Nx: 720 Ny: 361 lat_ll:
-90.000
> > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> > DEBUG 2: Interpolation options: method = NEAREST, width = 1, shape
=
> > SQUARE, vld_thresh = 0.5
> > DEBUG 2: Range of input data (name="PRATE"; level="A6";) is 0 to
> 0.004075.
> > DEBUG 2: Range of regridded data (name="PRATE"; level="A6";) is 0
to
> > 0.004075.
> > DEBUG 1: Writing output file: prate.nc
> >
> > Since the input and output grids are the same, no re-gridding is
actually
> > being done. You could have also used the pcp_combine tool to do
the same
> > thing. But the nice thing about regrid_data_plane is that you
could
> > include multiple fields in the output by using the "-field"
command line
> > option multiple times.
> >
> > Then you can edit the NetCDF output of regrid_data_plane however
you'd
> > like, and MET should be able to read that file.
> >
> > Hope that helps.
> >
> > Thanks,
> > John
> >
>
>
>
> --
> Bill Stern, Meteorologist
> Room 206
> NOAA/Geophysical Fluid Dynamics Laboratory
> Princeton University Forrestal Campus
> 201 Forrestal Road Princeton, NJ 08540-6649
> Tel: (609)452-6545
> Fax: (609)987-5063
> ------------------------------
> ------------------------------------
> Email Address: bill.stern at noaa.gov
> ------------------------------------------------------------------
> Anonymous ftp Address: ftp.gfdl.noaa.gov
> ------------------------------------------------------------------
> On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-gfdl-
noaa
> ------------------------------------------------------------------
>
>
------------------------------------------------
Subject: problem reading netdcf file
From: bill.stern at noaa.gov
Time: Sat Jul 15 11:03:29 2017
John and others,
I am now encountering a problem with MET's inability to read GFS
forecast
files that were processed to netcdf. There are more than 75 forecast
dates
each with 40 forecast time levels. It would be a very time consuming
task
to return to the original GRIB files and re-process each time level
with
MET regrid_data_plane tool. So, I would like to find a way to modify
the
existing netcdf files so they will be acceptable to MET.
Here is the error I am encountering:
/home/Shannon.Rees/met-5.2_orig/met-
5.2/src/tools/core/grid_stat/grid_stat
/vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc
/vftmp/Bill.Stern/pid43698/GFS_native/ST4.2015012300.06h
/work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip -outdir
/work/Bill.Stern/NGGPS/MET5.2/output/GFS_native/20150116.00Z/grid_stat//PRATEsfc/6hr/
-v 2
DEBUG 1: Default Config File:
/home/Shannon.Rees/met-5.2_orig/met-
5.2/share/met/config/GridStatConfig_default
DEBUG 1: User Config File:
/work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
ERROR :
ERROR : Trouble reading forecast file
"/vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
I have attached the output from "ncdump -c
/vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
The full file can be obtained from ftp.gfdl.noaa.gov
cd /pub/wfs
get PRATEsfc6all.nc
Thank you,
Bill
On Mon, Jul 10, 2017 at 2:27 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Bill,
>
> Ah, I understand. The regrid_data_plane tool is designed to read
exactly
> one 2D data field for each "-field" entry you specify on the command
line.
> When you ran it on a file containing 21 times, you probably got a
warning
> about "multiple matching fields". By default, it'll just use the
first
> match found.
>
> You can include additional timing information in the "-field" entry
to
> specify which of the 21 times you actually want. Here's an excerpt
from
> the met-6.0/data/config/README file about this:
>
> // - The "init_time" entry specifies the initialization time in
> YYYYMMDD[_HH[MMSS]]
> // format. This entry can be included in the "fcst" entry as
shown
> below or
> // included in the "field" entry if the user would like to use
> different
> // initialization times for different fields.
> //
> // - The "valid_time" entry specifies the valid time in
> YYYYMMDD[_HH[MMSS]]
> // format. This entry can be included in the "fcst" entry as
shown
> below or
> // included in the "field" entry if the user would like to use
> different
> // valid times for different fields.
> //
> // - The "lead_time" entry specifies the lead time in HH[MMSS]
> // format. This entry can be included in the "fcst" entry as
shown
> below or
> // included in the "field" entry if the user would like to use
> different
> // lead times for different fields.
>
> So you could try running adding the "valid_time":
>
> /usr/local/met-6.0/bin/regrid_data_plane \
> gfs_2012040900_F012.grib2 gfs_2012040900_F012.grib2 prate.nc \
> -field 'name="PRATE"; level="A6"; valid_time="20120409_120000";'
>
> Technically, you could run regrid_data_plane once on each input
file, pass
> in 21 "-field" settings, and write a single output file. But you'll
get an
> error because it'll try to write the same NetCDF variable name
multiple
> times. You could get around that by using the "-name" option to
passing in
> 21 unique output variables names... but that's a whole lot of
details.
>
> Instead, I'd suggest running regrid_data_plane once for each 3-
hourly
> output time and specify the "valid_time" currently being processed.
I
> think that logic would be cleaner.
>
> Hope that helps.
>
> Thanks,
> John
>
> On Mon, Jul 10, 2017 at 7:33 AM, bill.stern at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
> >
> > Hi John,
> >
> > I have followed your example of applying regrid_data_plane for
creating a
> > netcdf file from a grib2. The command below does create a netcdf,
but I
> am
> > only seem to be getting a single time level on the netcdf file,
while the
> > grib2 file has 21 time levels. Here is my regrid_data_plane
command:
> >
> > regrid_data_plane nam.2017051500.conusnest.hires.tm00.grib2
> > nam.2017051500.conusnest.hires.tm00.grib2
nam.2017051500.conusnest.APCP.
> nc
> > -field 'name = "APCP";level="A3";'
> >
> > What am I missing?
> >
> > Thanks,
> > Bill
> >
> > On Fri, Jul 7, 2017 at 12:44 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Hi Bill,
> > >
> > > I moved your question over into the MET-Help support ticketing
system.
> > >
> > > I see that you're having trouble processing the NetCDF output of
the
> > > ncl_convert2nc utility in MET. MET is only set up to read a
handful of
> > > NetCDF file formats, and unfortunately, the output of
ncl_convert2nc is
> > not
> > > one of them. The 3 NetCDF flavors that MET reads are CF-
complaint
> > > (climate-forecast convention) files, the output of the
wrf_interp
> > utility,
> > > and the internal NetCDF format written by the MET tools
themselves.
> > >
> > > I understand that you'd like to do additional processing on the
> > > precipitation rate data... and NetCDF is much easier to work
with than
> > > GRIB2.
> > >
> > > Rather than using ncl_convert2nc to reformat the GRIB2 data,
let's use
> > the
> > > MET regrid_data_plane tool instead. I'll demonstrate this
below.
> > >
> > > # I'll start with a sample GRIB2 GFS file that includes PRATE:
> > >
> > > wgrib2 gfs_2012040900_F012.grib2 | grep PRATE
> > > 199:37137213:d=2012040900:PRATE:surface:6-12 hour ave fcst:
> > >
> > > # Call regrid_data_plane using the -field option to select the
PRATE
> > record
> > >
> > > /usr/local/met-6.0/bin/regrid_data_plane \
> > > gfs_2012040900_F012.grib2 gfs_2012040900_F012.grib2 prate.nc \
> > > -field 'name="PRATE"; level="A6";'
> > >
> > > DEBUG 1: Reading data file: gfs_2012040900_F012.grib2
> > > DEBUG 2: Input grid: Projection: Lat/Lon Nx: 720 Ny: 361 lat_ll:
> -90.000
> > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> > > DEBUG 2: Output grid: Projection: Lat/Lon Nx: 720 Ny: 361
lat_ll:
> -90.000
> > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> > > DEBUG 2: Interpolation options: method = NEAREST, width = 1,
shape =
> > > SQUARE, vld_thresh = 0.5
> > > DEBUG 2: Range of input data (name="PRATE"; level="A6";) is 0 to
> > 0.004075.
> > > DEBUG 2: Range of regridded data (name="PRATE"; level="A6";) is
0 to
> > > 0.004075.
> > > DEBUG 1: Writing output file: prate.nc
> > >
> > > Since the input and output grids are the same, no re-gridding is
> actually
> > > being done. You could have also used the pcp_combine tool to do
the
> same
> > > thing. But the nice thing about regrid_data_plane is that you
could
> > > include multiple fields in the output by using the "-field"
command
> line
> > > option multiple times.
> > >
> > > Then you can edit the NetCDF output of regrid_data_plane however
you'd
> > > like, and MET should be able to read that file.
> > >
> > > Hope that helps.
> > >
> > > Thanks,
> > > John
> > >
> >
> >
> >
> > --
> > Bill Stern, Meteorologist
> > Room 206
> > NOAA/Geophysical Fluid Dynamics Laboratory
> > Princeton University Forrestal Campus
> > 201 Forrestal Road Princeton, NJ 08540-6649
> > Tel: (609)452-6545
> > Fax: (609)987-5063
> > ------------------------------
> > ------------------------------------
> > Email Address: bill.stern at noaa.gov
> > ------------------------------------------------------------------
> > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > ------------------------------------------------------------------
> > On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-gfdl-
noaa
> > ------------------------------------------------------------------
> >
> >
>
>
--
Bill Stern, Meteorologist
Room 206
NOAA/Geophysical Fluid Dynamics Laboratory
Princeton University Forrestal Campus
201 Forrestal Road Princeton, NJ 08540-6649
Tel: (609)452-6545
Fax: (609)987-5063
------------------------------
------------------------------------
Email Address: bill.stern at noaa.gov
------------------------------------------------------------------
Anonymous ftp Address: ftp.gfdl.noaa.gov
------------------------------------------------------------------
On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-gfdl-noaa
------------------------------------------------------------------
------------------------------------------------
Subject: problem reading netdcf file
From: bill.stern at noaa.gov
Time: Sat Jul 15 11:03:29 2017
netcdf PRATEsfc6all {
dimensions:
time = UNLIMITED ; // (40 currently)
g4_lat_0 = 1536 ;
g4_lon_1 = 3072 ;
variables:
int forecast_reference_time ;
forecast_reference_time:long_name = "reference time" ;
forecast_reference_time:units = "hours since 2015-01-
16 00:00:00" ;
float PRATEsfc(time, g4_lat_0, g4_lon_1) ;
PRATEsfc:_FillValue = 1.e+20f ;
PRATEsfc:center = "US National Weather Service - NCEP
(WMC)" ;
PRATEsfc:forecast_time = 6 ;
PRATEsfc:forecast_time_units = "hours" ;
PRATEsfc:gds_grid_type = 4 ;
PRATEsfc:initial_time = "01/16/2015 (00:00)" ;
PRATEsfc:level_indicator = 1 ;
PRATEsfc:long_name = "Precipitation rate" ;
PRATEsfc:model = "Spectral Statistical Interpolation
(SSI) analysis from \"Final\" run." ;
PRATEsfc:parameter_number = 59 ;
PRATEsfc:parameter_table_version = 2 ;
PRATEsfc:units = "kg/m^2/s" ;
float g4_lat_0(g4_lat_0) ;
g4_lat_0:La1 = 89.91f ;
g4_lat_0:Lo1 = 0.f ;
g4_lat_0:La2 = -89.91f ;
g4_lat_0:Lo2 = 359.883f ;
g4_lat_0:Di = 0.1171876f ;
g4_lat_0:N = 768.f ;
g4_lat_0:units = "degrees_north" ;
g4_lat_0:GridType = "Gaussian Latitude/Longitude Grid"
;
g4_lat_0:long_name = "latitude" ;
float g4_lon_1(g4_lon_1) ;
g4_lon_1:La1 = 89.91f ;
g4_lon_1:Lo1 = 0.f ;
g4_lon_1:La2 = -89.91f ;
g4_lon_1:Lo2 = 359.883f ;
g4_lon_1:Di = 0.1171876f ;
g4_lon_1:N = 768.f ;
g4_lon_1:units = "degrees_east" ;
g4_lon_1:GridType = "Gaussian Latitude/Longitude Grid"
;
g4_lon_1:long_name = "longitude" ;
float time(time) ;
time:long_name = "time" ;
time:units = "hours since 2015-01-16 00:00:00" ;
// global attributes:
:creation_date = "Thu Jul 14 15:03:37 EDT 2016" ;
:NCL_Version = "5.1.1" ;
:system = "Linux pp211 2.6.32-573.22.1.el6.x86_64 #1
SMP Wed Mar 23 03:35:39 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux" ;
:conventions = "CF-1.0" ;
:grib_source = "gfs.t00z.sfluxgrbf06.grb" ;
:title = "NCL: convert-GRIB-to-netCDF" ;
:history = "Sat Jul 15 12:02:49 2017: ncap2 -O -s
forecast_reference_time=0;forecast_reference_time at long_name=
\"reference time\"; \n",
" forecast_reference_time at units=\"hours since
2015-01-16 00:00:00\"
/vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc
/vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc\n",
"Sat Jul 15 12:02:47 2017: ncrcat
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot00.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot02.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot04.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot06.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot08.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot10.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot12.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot14.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot16.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot18.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot20.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot22.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot24.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot26.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot28.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot30.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot32.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot34.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot36.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot38.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot40.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot42.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot44.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot46.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot48.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot50.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot52.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot54.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot56.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot58.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot60.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot62.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot64.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot66.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot68.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot70.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot72.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot74.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot76.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot78.nc
/vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc\n",
"Sat Jul 15 12:02:43 2017: ncks -d time,0
/vftmp/Bill.Stern/pid43698/GFS_native/fcst_all.nc
/vftmp/Bill.Stern/pid43698/GFS_native/var6tot00.nc\n",
"Sat Jul 15 12:02:38 2017: ncap2 -O -s
PRATEsfc=PRATEsfc*21600
/vftmp/Bill.Stern/pid43698/GFS_native/fcst_all.nc
/vftmp/Bill.Stern/pid43698/GFS_native/fcst_all.nc\n",
"Sat Jul 15 12:02:38 2017: ncatted -a
conventions,global,o,c,CF-1.0
/vftmp/Bill.Stern/pid43698/GFS_native/fcst_all.nc\n",
"Sat Jul 15 12:02:36 2017: ncks -v PRATEsfc -d
time,0,39
/vftmp/Bill.Stern/pid43698/fcst_files/20150116_00Z_T1534_surf_10day.nc
/vftmp/Bill.Stern/pid43698/GFS_native/fcst_all.nc\n",
"Sat Jul 15 12:00:57 2017: ncatted -O -a
units,time,c,c,hours since 2015-01-16 00:00:00
/vftmp/Bill.Stern/pid43698/fcst_files/20150116_00Z_T1534_surf_10day.nc\n",
"Sat Jul 15 12:00:56 2017: ncks -A
/home/wfs/time_var_GFS.nc
/vftmp/Bill.Stern/pid43698/fcst_files/20150116_00Z_T1534_surf_10day.nc\n",
"Sat Jul 15 12:00:55 2017: ncrename -O -v
PRATE_GDS4_SFC_ave6h,PRATEsfc
/vftmp/Bill.Stern/pid43698/fcst_files/20150116_00Z_T1534_surf_10day.nc\n",
"Sat Jul 15 12:00:50 2017: ncks -v
PRATE_GDS4_SFC_ave6h
/archive/jhc/DATA/NCEP_GFS_fore/2015011600/20150116_00Z_T1534_surf_10day.nc
/vftmp/Bill.Stern/pid43698/fcst_files/20150116_00Z_T1534_surf_10day.nc\n",
"Fri Jul 15 16:51:52 2016: ncrcat
20150116_00Z06_T1534_surf.nc 20150116_00Z12_T1534_surf.nc
20150116_00Z18_T1534_surf.nc 20150116_00Z24_T1534_surf.nc
20150116_00Z30_T1534_surf.nc 20150116_00Z36_T1534_surf.nc
20150116_00Z42_T1534_surf.nc 20150116_00Z48_T1534_surf.nc
20150116_00Z54_T1534_surf.nc 20150116_00Z60_T1534_surf.nc
20150116_00Z66_T1534_surf.nc 20150116_00Z72_T1534_surf.nc
20150116_00Z78_T1534_surf.nc 20150116_00Z84_T1534_surf.nc
20150116_00Z90_T1534_surf.nc 20150116_00Z96_T1534_surf.nc
20150116_00Z102_T1534_surf.nc 20150116_00Z108_T1534_surf.nc
20150116_00Z114_T1534_surf.nc 20150116_00Z120_T1534_surf.nc
20150116_00Z126_T1534_surf.nc 20150116_00Z132_T1534_surf.nc
20150116_00Z138_T1534_surf.nc 20150116_00Z144_T1534_surf.nc
20150116_00Z150_T1534_surf.nc 20150116_00Z156_T1534_surf.nc
20150116_00Z162_T1534_surf.nc 20150116_00Z168_T1534_surf.nc
20150116_00Z174_T1534_surf.nc 20150116_00Z180_T1534_surf.nc
20150116_00Z186_T1534_surf.nc 20150116_00Z192_T1534_surf.nc
20150116_00Z198_T1534_surf.nc 20150116_00Z204_T1534_surf.nc
20150116_00Z210_T1534_surf.nc 20150116_00Z216_T1534_surf.nc
20150116_00Z222_T1534_surf.nc 20150116_00Z228_T1534_surf.nc
20150116_00Z234_T1534_surf.nc 20150116_00Z240_T1534_surf.nc
20150116_00Z_T1534_surf_10day.nc\n",
"Fri Jul 15 16:48:18 2016: ncecat -O -u time
20150116_00Z06_T1534_surf.nc 20150116_00Z06_T1534_surf.nc" ;
:nco_openmp_thread_number = 1 ;
:NCO = "\"4.5.4\"" ;
data:
g4_lat_0 = 89.91032, 89.79416, 89.67731, 89.5603, 89.44323, 89.32613,
89.20902, 89.0919, 88.97478, 88.85764, 88.74051, 88.62337,
88.50623,
88.38909, 88.27195, 88.1548, 88.03766, 87.92052, 87.80337,
87.68623,
87.56908, 87.45193, 87.33479, 87.21764, 87.10049, 86.98335,
86.8662,
86.74905, 86.6319, 86.51476, 86.39761, 86.28046, 86.16331,
86.04617,
85.92902, 85.81187, 85.69472, 85.57758, 85.46043, 85.34328,
85.22613,
85.10898, 84.99183, 84.87468, 84.75753, 84.64038, 84.52324,
84.40609,
84.28894, 84.17179, 84.05464, 83.93749, 83.82034, 83.70319,
83.58604,
83.46889, 83.35175, 83.2346, 83.11745, 83.0003, 82.88315,
82.76601,
82.64886, 82.53171, 82.41456, 82.29741, 82.18026, 82.06311,
81.94596,
81.82881, 81.71166, 81.59451, 81.47736, 81.36021, 81.24306,
81.12592,
81.00877, 80.89162, 80.77447, 80.65732, 80.54017, 80.42302,
80.30587,
80.18872, 80.07157, 79.95442, 79.83727, 79.72012, 79.60297,
79.48582,
79.36868, 79.25153, 79.13438, 79.01723, 78.90009, 78.78294,
78.66579,
78.54864, 78.43149, 78.31434, 78.19719, 78.08004, 77.96289,
77.84574,
77.72859, 77.61144, 77.49429, 77.37714, 77.25999, 77.14285,
77.0257,
76.90855, 76.7914, 76.67425, 76.5571, 76.43995, 76.3228, 76.20565,
76.0885, 75.97135, 75.8542, 75.73705, 75.6199, 75.50275, 75.3856,
75.26846, 75.15131, 75.03416, 74.91701, 74.79986, 74.68271,
74.56556,
74.44841, 74.33126, 74.21411, 74.09696, 73.97981, 73.86266,
73.74551,
73.62836, 73.51122, 73.39407, 73.27692, 73.15977, 73.04262,
72.92547,
72.80832, 72.69117, 72.57402, 72.45687, 72.33972, 72.22257,
72.10542,
71.98827, 71.87112, 71.75397, 71.63683, 71.51968, 71.40253,
71.28538,
71.16823, 71.05108, 70.93393, 70.81678, 70.69963, 70.58248,
70.46533,
70.34818, 70.23103, 70.11388, 69.99673, 69.87959, 69.76244,
69.64529,
69.52814, 69.41099, 69.29384, 69.17669, 69.05954, 68.94239,
68.82524,
68.70809, 68.59094, 68.47379, 68.35664, 68.23949, 68.12234,
68.0052,
67.88805, 67.7709, 67.65375, 67.5366, 67.41945, 67.3023, 67.18515,
67.068, 66.95085, 66.8337, 66.71656, 66.59941, 66.48226, 66.36511,
66.24796, 66.13081, 66.01366, 65.89651, 65.77937, 65.66222,
65.54507,
65.42792, 65.31077, 65.19362, 65.07647, 64.95932, 64.84217,
64.72502,
64.60787, 64.49072, 64.37357, 64.25642, 64.13927, 64.02213,
63.90497,
63.78782, 63.67067, 63.55352, 63.43637, 63.31923, 63.20208,
63.08493,
62.96778, 62.85063, 62.73348, 62.61633, 62.49918, 62.38203,
62.26488,
62.14773, 62.03058, 61.91343, 61.79628, 61.67913, 61.56199,
61.44484,
61.32769, 61.21054, 61.09339, 60.97624, 60.85909, 60.74194,
60.62479,
60.50764, 60.39049, 60.27334, 60.15619, 60.03904, 59.92189,
59.80474,
59.6876, 59.57045, 59.4533, 59.33615, 59.219, 59.10185, 58.9847,
58.86755, 58.7504, 58.63325, 58.5161, 58.39895, 58.2818, 58.16465,
58.0475, 57.93036, 57.81321, 57.69606, 57.57891, 57.46176,
57.34461,
57.22746, 57.11031, 56.99316, 56.87601, 56.75886, 56.64171,
56.52456,
56.40741, 56.29026, 56.17311, 56.05597, 55.93882, 55.82167,
55.70452,
55.58737, 55.47022, 55.35307, 55.23592, 55.11877, 55.00162,
54.88447,
54.76732, 54.65017, 54.53302, 54.41587, 54.29873, 54.18158,
54.06443,
53.94728, 53.83013, 53.71298, 53.59583, 53.47868, 53.36153,
53.24438,
53.12723, 53.01008, 52.89293, 52.77578, 52.65863, 52.54148,
52.42434,
52.30719, 52.19004, 52.07289, 51.95574, 51.83859, 51.72144,
51.60429,
51.48714, 51.36999, 51.25284, 51.13569, 51.01854, 50.90139,
50.78424,
50.6671, 50.54995, 50.4328, 50.31565, 50.1985, 50.08135, 49.9642,
49.84705, 49.7299, 49.61275, 49.4956, 49.37845, 49.2613, 49.14415,
49.027, 48.90985, 48.79271, 48.67556, 48.55841, 48.44126,
48.32411,
48.20696, 48.08981, 47.97266, 47.85551, 47.73836, 47.62121,
47.50406,
47.38691, 47.26976, 47.15261, 47.03547, 46.91832, 46.80117,
46.68402,
46.56687, 46.44972, 46.33257, 46.21542, 46.09827, 45.98112,
45.86397,
45.74682, 45.62967, 45.51252, 45.39537, 45.27822, 45.16108,
45.04393,
44.92678, 44.80963, 44.69248, 44.57533, 44.45818, 44.34103,
44.22388,
44.10673, 43.98958, 43.87243, 43.75528, 43.63813, 43.52098,
43.40384,
43.28669, 43.16954, 43.05239, 42.93524, 42.81809, 42.70094,
42.58379,
42.46664, 42.34949, 42.23234, 42.11519, 41.99804, 41.88089,
41.76374,
41.6466, 41.52945, 41.4123, 41.29515, 41.178, 41.06085, 40.9437,
40.82655, 40.7094, 40.59225, 40.4751, 40.35795, 40.2408, 40.12365,
40.0065, 39.88935, 39.77221, 39.65506, 39.53791, 39.42076,
39.30361,
39.18646, 39.06931, 38.95216, 38.83501, 38.71786, 38.60071,
38.48356,
38.36641, 38.24926, 38.13211, 38.01497, 37.89782, 37.78067,
37.66352,
37.54637, 37.42922, 37.31207, 37.19492, 37.07777, 36.96062,
36.84347,
36.72632, 36.60917, 36.49202, 36.37487, 36.25772, 36.14058,
36.02343,
35.90628, 35.78913, 35.67198, 35.55483, 35.43768, 35.32053,
35.20338,
35.08623, 34.96908, 34.85193, 34.73478, 34.61763, 34.50048,
34.38334,
34.26619, 34.14904, 34.03189, 33.91474, 33.79759, 33.68044,
33.56329,
33.44614, 33.32899, 33.21184, 33.09469, 32.97754, 32.86039,
32.74324,
32.62609, 32.50895, 32.3918, 32.27465, 32.1575, 32.04035, 31.9232,
31.80605, 31.6889, 31.57175, 31.4546, 31.33745, 31.2203, 31.10316,
30.98601, 30.86886, 30.75171, 30.63456, 30.51741, 30.40026,
30.28311,
30.16596, 30.04881, 29.93166, 29.81451, 29.69736, 29.58021,
29.46306,
29.34591, 29.22877, 29.11162, 28.99447, 28.87732, 28.76017,
28.64302,
28.52587, 28.40872, 28.29157, 28.17442, 28.05727, 27.94012,
27.82297,
27.70582, 27.58867, 27.47153, 27.35438, 27.23723, 27.12008,
27.00293,
26.88578, 26.76863, 26.65148, 26.53433, 26.41718, 26.30003,
26.18288,
26.06573, 25.94858, 25.83143, 25.71428, 25.59714, 25.47999,
25.36284,
25.24569, 25.12854, 25.01139, 24.89424, 24.77709, 24.65994,
24.54279,
24.42564, 24.30849, 24.19134, 24.07419, 23.95704, 23.8399,
23.72275,
23.6056, 23.48845, 23.3713, 23.25415, 23.137, 23.01985, 22.9027,
22.78555, 22.6684, 22.55125, 22.4341, 22.31695, 22.1998, 22.08265,
21.96551, 21.84836, 21.73121, 21.61406, 21.49691, 21.37976,
21.26261,
21.14546, 21.02831, 20.91116, 20.79401, 20.67686, 20.55971,
20.44256,
20.32541, 20.20827, 20.09112, 19.97397, 19.85682, 19.73967,
19.62252,
19.50537, 19.38822, 19.27107, 19.15392, 19.03677, 18.91962,
18.80247,
18.68532, 18.56817, 18.45102, 18.33387, 18.21672, 18.09958,
17.98243,
17.86528, 17.74813, 17.63098, 17.51383, 17.39668, 17.27953,
17.16238,
17.04523, 16.92808, 16.81093, 16.69378, 16.57663, 16.45948,
16.34233,
16.22519, 16.10804, 15.99089, 15.87374, 15.75659, 15.63944,
15.52229,
15.40514, 15.28799, 15.17084, 15.05369, 14.93654, 14.81939,
14.70224,
14.5851, 14.46795, 14.3508, 14.23365, 14.1165, 13.99935, 13.8822,
13.76505, 13.6479, 13.53075, 13.4136, 13.29645, 13.1793, 13.06215,
12.945, 12.82786, 12.71071, 12.59356, 12.47641, 12.35926,
12.24211,
12.12496, 12.00781, 11.89066, 11.77351, 11.65636, 11.53921,
11.42206,
11.30491, 11.18776, 11.07061, 10.95347, 10.83632, 10.71917,
10.60202,
10.48487, 10.36772, 10.25057, 10.13342, 10.01627, 9.899121,
9.781972,
9.664823, 9.547673, 9.430524, 9.313375, 9.196225, 9.079076,
8.961926,
8.844776, 8.727627, 8.610477, 8.493328, 8.376179, 8.259029,
8.14188,
8.024731, 7.907582, 7.790432, 7.673283, 7.556134, 7.438984,
7.321835,
7.204686, 7.087536, 6.970387, 6.853238, 6.736088, 6.618939,
6.50179,
6.38464, 6.267491, 6.150342, 6.033192, 5.916043, 5.798893,
5.681744,
5.564595, 5.447445, 5.330296, 5.213147, 5.095997, 4.978848,
4.861699,
4.744549, 4.6274, 4.510251, 4.393101, 4.275951, 4.158802,
4.041653,
3.924504, 3.807354, 3.690205, 3.573056, 3.455906, 3.338757,
3.221607,
3.104458, 2.987309, 2.870159, 2.75301, 2.635861, 2.518711,
2.401562,
2.284413, 2.167263, 2.050114, 1.932964, 1.815815, 1.698666,
1.581516,
1.464367, 1.347218, 1.230068, 1.112919, 0.9957696, 0.8786202,
0.7614709,
0.6443215, 0.5271721, 0.4100228, 0.2928734, 0.175724, 0.05857468,
-0.05857468, -0.175724, -0.2928734, -0.4100228, -0.5271721,
-0.6443215,
-0.7614709, -0.8786202, -0.9957696, -1.112919, -1.230068,
-1.347218,
-1.464367, -1.581516, -1.698666, -1.815815, -1.932964, -2.050114,
-2.167263, -2.284413, -2.401562, -2.518711, -2.635861, -2.75301,
-2.870159, -2.987309, -3.104458, -3.221607, -3.338757, -3.455906,
-3.573056, -3.690205, -3.807354, -3.924504, -4.041653, -4.158802,
-4.275951, -4.393101, -4.510251, -4.6274, -4.744549, -4.861699,
-4.978848, -5.095997, -5.213147, -5.330296, -5.447445, -5.564595,
-5.681744, -5.798893, -5.916043, -6.033192, -6.150342, -6.267491,
-6.38464, -6.50179, -6.618939, -6.736088, -6.853238, -6.970387,
-7.087536, -7.204686, -7.321835, -7.438984, -7.556134, -7.673283,
-7.790432, -7.907582, -8.024731, -8.14188, -8.259029, -8.376179,
-8.493328, -8.610477, -8.727627, -8.844776, -8.961926, -9.079076,
-9.196225, -9.313375, -9.430524, -9.547673, -9.664823, -9.781972,
-9.899121, -10.01627, -10.13342, -10.25057, -10.36772, -10.48487,
-10.60202, -10.71917, -10.83632, -10.95347, -11.07061, -11.18776,
-11.30491, -11.42206, -11.53921, -11.65636, -11.77351, -11.89066,
-12.00781, -12.12496, -12.24211, -12.35926, -12.47641, -12.59356,
-12.71071, -12.82786, -12.945, -13.06215, -13.1793, -13.29645,
-13.4136,
-13.53075, -13.6479, -13.76505, -13.8822, -13.99935, -14.1165,
-14.23365,
-14.3508, -14.46795, -14.5851, -14.70224, -14.81939, -14.93654,
-15.05369, -15.17084, -15.28799, -15.40514, -15.52229, -15.63944,
-15.75659, -15.87374, -15.99089, -16.10804, -16.22519, -16.34233,
-16.45948, -16.57663, -16.69378, -16.81093, -16.92808, -17.04523,
-17.16238, -17.27953, -17.39668, -17.51383, -17.63098, -17.74813,
-17.86528, -17.98243, -18.09958, -18.21672, -18.33387, -18.45102,
-18.56817, -18.68532, -18.80247, -18.91962, -19.03677, -19.15392,
-19.27107, -19.38822, -19.50537, -19.62252, -19.73967, -19.85682,
-19.97397, -20.09112, -20.20827, -20.32541, -20.44256, -20.55971,
-20.67686, -20.79401, -20.91116, -21.02831, -21.14546, -21.26261,
-21.37976, -21.49691, -21.61406, -21.73121, -21.84836, -21.96551,
-22.08265, -22.1998, -22.31695, -22.4341, -22.55125, -22.6684,
-22.78555,
-22.9027, -23.01985, -23.137, -23.25415, -23.3713, -23.48845,
-23.6056,
-23.72275, -23.8399, -23.95704, -24.07419, -24.19134, -24.30849,
-24.42564, -24.54279, -24.65994, -24.77709, -24.89424, -25.01139,
-25.12854, -25.24569, -25.36284, -25.47999, -25.59714, -25.71428,
-25.83143, -25.94858, -26.06573, -26.18288, -26.30003, -26.41718,
-26.53433, -26.65148, -26.76863, -26.88578, -27.00293, -27.12008,
-27.23723, -27.35438, -27.47153, -27.58867, -27.70582, -27.82297,
-27.94012, -28.05727, -28.17442, -28.29157, -28.40872, -28.52587,
-28.64302, -28.76017, -28.87732, -28.99447, -29.11162, -29.22877,
-29.34591, -29.46306, -29.58021, -29.69736, -29.81451, -29.93166,
-30.04881, -30.16596, -30.28311, -30.40026, -30.51741, -30.63456,
-30.75171, -30.86886, -30.98601, -31.10316, -31.2203, -31.33745,
-31.4546, -31.57175, -31.6889, -31.80605, -31.9232, -32.04035,
-32.1575,
-32.27465, -32.3918, -32.50895, -32.62609, -32.74324, -32.86039,
-32.97754, -33.09469, -33.21184, -33.32899, -33.44614, -33.56329,
-33.68044, -33.79759, -33.91474, -34.03189, -34.14904, -34.26619,
-34.38334, -34.50048, -34.61763, -34.73478, -34.85193, -34.96908,
-35.08623, -35.20338, -35.32053, -35.43768, -35.55483, -35.67198,
-35.78913, -35.90628, -36.02343, -36.14058, -36.25772, -36.37487,
-36.49202, -36.60917, -36.72632, -36.84347, -36.96062, -37.07777,
-37.19492, -37.31207, -37.42922, -37.54637, -37.66352, -37.78067,
-37.89782, -38.01497, -38.13211, -38.24926, -38.36641, -38.48356,
-38.60071, -38.71786, -38.83501, -38.95216, -39.06931, -39.18646,
-39.30361, -39.42076, -39.53791, -39.65506, -39.77221, -39.88935,
-40.0065, -40.12365, -40.2408, -40.35795, -40.4751, -40.59225,
-40.7094,
-40.82655, -40.9437, -41.06085, -41.178, -41.29515, -41.4123,
-41.52945,
-41.6466, -41.76374, -41.88089, -41.99804, -42.11519, -42.23234,
-42.34949, -42.46664, -42.58379, -42.70094, -42.81809, -42.93524,
-43.05239, -43.16954, -43.28669, -43.40384, -43.52098, -43.63813,
-43.75528, -43.87243, -43.98958, -44.10673, -44.22388, -44.34103,
-44.45818, -44.57533, -44.69248, -44.80963, -44.92678, -45.04393,
-45.16108, -45.27822, -45.39537, -45.51252, -45.62967, -45.74682,
-45.86397, -45.98112, -46.09827, -46.21542, -46.33257, -46.44972,
-46.56687, -46.68402, -46.80117, -46.91832, -47.03547, -47.15261,
-47.26976, -47.38691, -47.50406, -47.62121, -47.73836, -47.85551,
-47.97266, -48.08981, -48.20696, -48.32411, -48.44126, -48.55841,
-48.67556, -48.79271, -48.90985, -49.027, -49.14415, -49.2613,
-49.37845,
-49.4956, -49.61275, -49.7299, -49.84705, -49.9642, -50.08135,
-50.1985,
-50.31565, -50.4328, -50.54995, -50.6671, -50.78424, -50.90139,
-51.01854, -51.13569, -51.25284, -51.36999, -51.48714, -51.60429,
-51.72144, -51.83859, -51.95574, -52.07289, -52.19004, -52.30719,
-52.42434, -52.54148, -52.65863, -52.77578, -52.89293, -53.01008,
-53.12723, -53.24438, -53.36153, -53.47868, -53.59583, -53.71298,
-53.83013, -53.94728, -54.06443, -54.18158, -54.29873, -54.41587,
-54.53302, -54.65017, -54.76732, -54.88447, -55.00162, -55.11877,
-55.23592, -55.35307, -55.47022, -55.58737, -55.70452, -55.82167,
-55.93882, -56.05597, -56.17311, -56.29026, -56.40741, -56.52456,
-56.64171, -56.75886, -56.87601, -56.99316, -57.11031, -57.22746,
-57.34461, -57.46176, -57.57891, -57.69606, -57.81321, -57.93036,
-58.0475, -58.16465, -58.2818, -58.39895, -58.5161, -58.63325,
-58.7504,
-58.86755, -58.9847, -59.10185, -59.219, -59.33615, -59.4533,
-59.57045,
-59.6876, -59.80474, -59.92189, -60.03904, -60.15619, -60.27334,
-60.39049, -60.50764, -60.62479, -60.74194, -60.85909, -60.97624,
-61.09339, -61.21054, -61.32769, -61.44484, -61.56199, -61.67913,
-61.79628, -61.91343, -62.03058, -62.14773, -62.26488, -62.38203,
-62.49918, -62.61633, -62.73348, -62.85063, -62.96778, -63.08493,
-63.20208, -63.31923, -63.43637, -63.55352, -63.67067, -63.78782,
-63.90497, -64.02213, -64.13927, -64.25642, -64.37357, -64.49072,
-64.60787, -64.72502, -64.84217, -64.95932, -65.07647, -65.19362,
-65.31077, -65.42792, -65.54507, -65.66222, -65.77937, -65.89651,
-66.01366, -66.13081, -66.24796, -66.36511, -66.48226, -66.59941,
-66.71656, -66.8337, -66.95085, -67.068, -67.18515, -67.3023,
-67.41945,
-67.5366, -67.65375, -67.7709, -67.88805, -68.0052, -68.12234,
-68.23949,
-68.35664, -68.47379, -68.59094, -68.70809, -68.82524, -68.94239,
-69.05954, -69.17669, -69.29384, -69.41099, -69.52814, -69.64529,
-69.76244, -69.87959, -69.99673, -70.11388, -70.23103, -70.34818,
-70.46533, -70.58248, -70.69963, -70.81678, -70.93393, -71.05108,
-71.16823, -71.28538, -71.40253, -71.51968, -71.63683, -71.75397,
-71.87112, -71.98827, -72.10542, -72.22257, -72.33972, -72.45687,
-72.57402, -72.69117, -72.80832, -72.92547, -73.04262, -73.15977,
-73.27692, -73.39407, -73.51122, -73.62836, -73.74551, -73.86266,
-73.97981, -74.09696, -74.21411, -74.33126, -74.44841, -74.56556,
-74.68271, -74.79986, -74.91701, -75.03416, -75.15131, -75.26846,
-75.3856, -75.50275, -75.6199, -75.73705, -75.8542, -75.97135,
-76.0885,
-76.20565, -76.3228, -76.43995, -76.5571, -76.67425, -76.7914,
-76.90855,
-77.0257, -77.14285, -77.25999, -77.37714, -77.49429, -77.61144,
-77.72859, -77.84574, -77.96289, -78.08004, -78.19719, -78.31434,
-78.43149, -78.54864, -78.66579, -78.78294, -78.90009, -79.01723,
-79.13438, -79.25153, -79.36868, -79.48582, -79.60297, -79.72012,
-79.83727, -79.95442, -80.07157, -80.18872, -80.30587, -80.42302,
-80.54017, -80.65732, -80.77447, -80.89162, -81.00877, -81.12592,
-81.24306, -81.36021, -81.47736, -81.59451, -81.71166, -81.82881,
-81.94596, -82.06311, -82.18026, -82.29741, -82.41456, -82.53171,
-82.64886, -82.76601, -82.88315, -83.0003, -83.11745, -83.2346,
-83.35175, -83.46889, -83.58604, -83.70319, -83.82034, -83.93749,
-84.05464, -84.17179, -84.28894, -84.40609, -84.52324, -84.64038,
-84.75753, -84.87468, -84.99183, -85.10898, -85.22613, -85.34328,
-85.46043, -85.57758, -85.69472, -85.81187, -85.92902, -86.04617,
-86.16331, -86.28046, -86.39761, -86.51476, -86.6319, -86.74905,
-86.8662, -86.98335, -87.10049, -87.21764, -87.33479, -87.45193,
-87.56908, -87.68623, -87.80337, -87.92052, -88.03766, -88.1548,
-88.27195, -88.38909, -88.50623, -88.62337, -88.74051, -88.85764,
-88.97478, -89.0919, -89.20902, -89.32613, -89.44323, -89.5603,
-89.67731, -89.79416, -89.91032 ;
g4_lon_1 = 0, 0.1171876, 0.2343751, 0.3515627, 0.4687502, 0.5859378,
0.7031254, 0.8203129, 0.9375005, 1.054688, 1.171876, 1.289063,
1.406251,
1.523438, 1.640626, 1.757813, 1.875001, 1.992189, 2.109376,
2.226564,
2.343751, 2.460939, 2.578126, 2.695314, 2.812501, 2.929689,
3.046877,
3.164064, 3.281252, 3.398439, 3.515627, 3.632814, 3.750002,
3.867189,
3.984377, 4.101564, 4.218752, 4.33594, 4.453127, 4.570315,
4.687502,
4.80469, 4.921877, 5.039065, 5.156253, 5.27344, 5.390628,
5.507815,
5.625003, 5.74219, 5.859378, 5.976566, 6.093753, 6.210941,
6.328128,
6.445316, 6.562503, 6.679691, 6.796878, 6.914066, 7.031254,
7.148441,
7.265629, 7.382816, 7.500004, 7.617191, 7.734379, 7.851567,
7.968754,
8.085941, 8.203129, 8.320317, 8.437505, 8.554692, 8.67188,
8.789067,
8.906255, 9.023442, 9.14063, 9.257817, 9.375005, 9.492192,
9.60938,
9.726567, 9.843755, 9.960942, 10.07813, 10.19532, 10.31251,
10.42969,
10.54688, 10.66407, 10.78126, 10.89844, 11.01563, 11.13282,
11.25001,
11.36719, 11.48438, 11.60157, 11.71876, 11.83594, 11.95313,
12.07032,
12.18751, 12.30469, 12.42188, 12.53907, 12.65626, 12.77344,
12.89063,
13.00782, 13.12501, 13.24219, 13.35938, 13.47657, 13.59376,
13.71094,
13.82813, 13.94532, 14.06251, 14.1797, 14.29688, 14.41407,
14.53126,
14.64845, 14.76563, 14.88282, 15.00001, 15.1172, 15.23438,
15.35157,
15.46876, 15.58595, 15.70313, 15.82032, 15.93751, 16.0547,
16.17188,
16.28907, 16.40626, 16.52345, 16.64063, 16.75782, 16.87501,
16.9922,
17.10938, 17.22657, 17.34376, 17.46095, 17.57813, 17.69532,
17.81251,
17.9297, 18.04688, 18.16407, 18.28126, 18.39845, 18.51563,
18.63282,
18.75001, 18.8672, 18.98438, 19.10157, 19.21876, 19.33595,
19.45313,
19.57032, 19.68751, 19.8047, 19.92188, 20.03907, 20.15626,
20.27345,
20.39064, 20.50782, 20.62501, 20.7422, 20.85939, 20.97657,
21.09376,
21.21095, 21.32814, 21.44532, 21.56251, 21.6797, 21.79689,
21.91407,
22.03126, 22.14845, 22.26564, 22.38282, 22.50001, 22.6172,
22.73439,
22.85157, 22.96876, 23.08595, 23.20314, 23.32032, 23.43751,
23.5547,
23.67189, 23.78907, 23.90626, 24.02345, 24.14064, 24.25783,
24.37501,
24.4922, 24.60939, 24.72658, 24.84376, 24.96095, 25.07814,
25.19533,
25.31251, 25.4297, 25.54689, 25.66408, 25.78126, 25.89845,
26.01564,
26.13283, 26.25001, 26.3672, 26.48439, 26.60158, 26.71876,
26.83595,
26.95314, 27.07033, 27.18751, 27.3047, 27.42189, 27.53908,
27.65627,
27.77345, 27.89064, 28.00783, 28.12502, 28.2422, 28.35939,
28.47658,
28.59377, 28.71095, 28.82814, 28.94533, 29.06252, 29.1797,
29.29689,
29.41408, 29.53127, 29.64845, 29.76564, 29.88283, 30.00002,
30.1172,
30.23439, 30.35158, 30.46877, 30.58595, 30.70314, 30.82033,
30.93752,
31.0547, 31.17189, 31.28908, 31.40627, 31.52345, 31.64064,
31.75783,
31.87502, 31.9922, 32.10939, 32.22658, 32.34377, 32.46095,
32.57814,
32.69533, 32.81252, 32.9297, 33.04689, 33.16408, 33.28127,
33.39846,
33.51564, 33.63283, 33.75002, 33.86721, 33.98439, 34.10158,
34.21877,
34.33596, 34.45314, 34.57033, 34.68752, 34.80471, 34.92189,
35.03908,
35.15627, 35.27346, 35.39064, 35.50783, 35.62502, 35.74221,
35.85939,
35.97658, 36.09377, 36.21096, 36.32814, 36.44533, 36.56252,
36.67971,
36.79689, 36.91408, 37.03127, 37.14846, 37.26564, 37.38283,
37.50002,
37.61721, 37.73439, 37.85158, 37.96877, 38.08596, 38.20314,
38.32033,
38.43752, 38.55471, 38.67189, 38.78908, 38.90627, 39.02346,
39.14064,
39.25783, 39.37502, 39.49221, 39.60939, 39.72658, 39.84377,
39.96096,
40.07814, 40.19533, 40.31252, 40.42971, 40.5469, 40.66409,
40.78127,
40.89846, 41.01565, 41.13284, 41.25002, 41.36721, 41.4844,
41.60159,
41.71877, 41.83596, 41.95315, 42.07034, 42.18752, 42.30471,
42.4219,
42.53909, 42.65627, 42.77346, 42.89065, 43.00784, 43.12502,
43.24221,
43.3594, 43.47659, 43.59377, 43.71096, 43.82815, 43.94534,
44.06252,
44.17971, 44.2969, 44.41409, 44.53127, 44.64846, 44.76565,
44.88284,
45.00002, 45.11721, 45.2344, 45.35159, 45.46877, 45.58596,
45.70315,
45.82034, 45.93752, 46.05471, 46.1719, 46.28909, 46.40627,
46.52346,
46.64065, 46.75784, 46.87502, 46.99221, 47.1094, 47.22659,
47.34377,
47.46096, 47.57815, 47.69534, 47.81253, 47.92971, 48.0469,
48.16409,
48.28128, 48.39846, 48.51565, 48.63284, 48.75003, 48.86721,
48.9844,
49.10159, 49.21878, 49.33596, 49.45315, 49.57034, 49.68753,
49.80471,
49.9219, 50.03909, 50.15628, 50.27346, 50.39065, 50.50784,
50.62503,
50.74221, 50.8594, 50.97659, 51.09378, 51.21096, 51.32815,
51.44534,
51.56253, 51.67971, 51.7969, 51.91409, 52.03128, 52.14846,
52.26565,
52.38284, 52.50003, 52.61721, 52.7344, 52.85159, 52.96878,
53.08596,
53.20315, 53.32034, 53.43753, 53.55471, 53.6719, 53.78909,
53.90628,
54.02346, 54.14065, 54.25784, 54.37503, 54.49221, 54.6094,
54.72659,
54.84378, 54.96097, 55.07816, 55.19534, 55.31253, 55.42972,
55.54691,
55.66409, 55.78128, 55.89847, 56.01566, 56.13284, 56.25003,
56.36722,
56.48441, 56.60159, 56.71878, 56.83597, 56.95316, 57.07034,
57.18753,
57.30472, 57.42191, 57.53909, 57.65628, 57.77347, 57.89066,
58.00784,
58.12503, 58.24222, 58.35941, 58.47659, 58.59378, 58.71097,
58.82816,
58.94534, 59.06253, 59.17972, 59.29691, 59.41409, 59.53128,
59.64847,
59.76566, 59.88284, 60.00003, 60.11722, 60.23441, 60.35159,
60.46878,
60.58597, 60.70316, 60.82034, 60.93753, 61.05472, 61.17191,
61.28909,
61.40628, 61.52347, 61.64066, 61.75784, 61.87503, 61.99222,
62.10941,
62.22659, 62.34378, 62.46097, 62.57816, 62.69535, 62.81253,
62.92972,
63.04691, 63.1641, 63.28128, 63.39847, 63.51566, 63.63285,
63.75003,
63.86722, 63.98441, 64.10159, 64.21878, 64.33597, 64.45316,
64.57034,
64.68753, 64.80472, 64.92191, 65.03909, 65.15628, 65.27347,
65.39066,
65.50784, 65.62503, 65.74222, 65.85941, 65.9766, 66.09379,
66.21098,
66.32816, 66.44535, 66.56254, 66.67973, 66.79691, 66.9141,
67.03129,
67.14848, 67.26566, 67.38285, 67.50004, 67.61723, 67.73441,
67.8516,
67.96879, 68.08598, 68.20316, 68.32035, 68.43754, 68.55473,
68.67191,
68.7891, 68.90629, 69.02348, 69.14066, 69.25785, 69.37504,
69.49223,
69.60941, 69.7266, 69.84379, 69.96098, 70.07816, 70.19535,
70.31254,
70.42973, 70.54691, 70.6641, 70.78129, 70.89848, 71.01566,
71.13285,
71.25004, 71.36723, 71.48441, 71.6016, 71.71879, 71.83598,
71.95316,
72.07035, 72.18754, 72.30473, 72.42191, 72.5391, 72.65629,
72.77348,
72.89066, 73.00785, 73.12504, 73.24223, 73.35941, 73.4766,
73.59379,
73.71098, 73.82816, 73.94535, 74.06254, 74.17973, 74.29691,
74.4141,
74.53129, 74.64848, 74.76566, 74.88285, 75.00004, 75.11723,
75.23441,
75.3516, 75.46879, 75.58598, 75.70316, 75.82035, 75.93754,
76.05473,
76.17191, 76.2891, 76.40629, 76.52348, 76.64066, 76.75785,
76.87504,
76.99223, 77.10941, 77.2266, 77.34379, 77.46098, 77.57816,
77.69535,
77.81254, 77.92973, 78.04691, 78.1641, 78.28129, 78.39848,
78.51566,
78.63285, 78.75004, 78.86723, 78.98441, 79.1016, 79.21879,
79.33598,
79.45316, 79.57035, 79.68754, 79.80473, 79.92191, 80.0391,
80.15629,
80.27348, 80.39066, 80.50785, 80.62505, 80.74223, 80.85942,
80.97661,
81.0938, 81.21098, 81.32817, 81.44536, 81.56255, 81.67973,
81.79692,
81.91411, 82.0313, 82.14848, 82.26567, 82.38286, 82.50005,
82.61723,
82.73442, 82.85161, 82.9688, 83.08598, 83.20317, 83.32036,
83.43755,
83.55473, 83.67192, 83.78911, 83.9063, 84.02348, 84.14067,
84.25786,
84.37505, 84.49223, 84.60942, 84.72661, 84.8438, 84.96098,
85.07817,
85.19536, 85.31255, 85.42973, 85.54692, 85.66411, 85.7813,
85.89848,
86.01567, 86.13286, 86.25005, 86.36723, 86.48442, 86.60161,
86.7188,
86.83598, 86.95317, 87.07036, 87.18755, 87.30473, 87.42192,
87.53911,
87.6563, 87.77348, 87.89067, 88.00786, 88.12505, 88.24223,
88.35942,
88.47661, 88.5938, 88.71098, 88.82817, 88.94536, 89.06255,
89.17973,
89.29692, 89.41411, 89.5313, 89.64848, 89.76567, 89.88286,
90.00005,
90.11723, 90.23442, 90.35161, 90.4688, 90.58598, 90.70317,
90.82036,
90.93755, 91.05473, 91.17192, 91.28911, 91.4063, 91.52348,
91.64067,
91.75786, 91.87505, 91.99223, 92.10942, 92.22661, 92.3438,
92.46098,
92.57817, 92.69536, 92.81255, 92.92973, 93.04692, 93.16411,
93.2813,
93.39848, 93.51567, 93.63286, 93.75005, 93.86723, 93.98442,
94.10161,
94.2188, 94.33598, 94.45317, 94.57036, 94.68755, 94.80473,
94.92192,
95.03911, 95.1563, 95.27349, 95.39068, 95.50787, 95.62505,
95.74224,
95.85943, 95.97662, 96.0938, 96.21099, 96.32818, 96.44537,
96.56255,
96.67974, 96.79693, 96.91412, 97.0313, 97.14849, 97.26568,
97.38287,
97.50005, 97.61724, 97.73443, 97.85162, 97.9688, 98.08599,
98.20318,
98.32037, 98.43755, 98.55474, 98.67193, 98.78912, 98.9063,
99.02349,
99.14068, 99.25787, 99.37505, 99.49224, 99.60943, 99.72662,
99.8438,
99.96099, 100.0782, 100.1954, 100.3126, 100.4297, 100.5469,
100.6641,
100.7813, 100.8985, 101.0157, 101.1329, 101.2501, 101.3672,
101.4844,
101.6016, 101.7188, 101.836, 101.9532, 102.0704, 102.1876,
102.3047,
102.4219, 102.5391, 102.6563, 102.7735, 102.8907, 103.0079,
103.1251,
103.2422, 103.3594, 103.4766, 103.5938, 103.711, 103.8282,
103.9454,
104.0626, 104.1797, 104.2969, 104.4141, 104.5313, 104.6485,
104.7657,
104.8829, 105.0001, 105.1172, 105.2344, 105.3516, 105.4688,
105.586,
105.7032, 105.8204, 105.9376, 106.0547, 106.1719, 106.2891,
106.4063,
106.5235, 106.6407, 106.7579, 106.8751, 106.9922, 107.1094,
107.2266,
107.3438, 107.461, 107.5782, 107.6954, 107.8126, 107.9297,
108.0469,
108.1641, 108.2813, 108.3985, 108.5157, 108.6329, 108.7501,
108.8672,
108.9844, 109.1016, 109.2188, 109.336, 109.4532, 109.5704,
109.6876,
109.8047, 109.9219, 110.0391, 110.1563, 110.2735, 110.3907,
110.5079,
110.6251, 110.7422, 110.8594, 110.9766, 111.0938, 111.211,
111.3282,
111.4454, 111.5626, 111.6797, 111.7969, 111.9141, 112.0313,
112.1485,
112.2657, 112.3829, 112.5001, 112.6172, 112.7344, 112.8516,
112.9688,
113.086, 113.2032, 113.3204, 113.4376, 113.5547, 113.6719,
113.7891,
113.9063, 114.0235, 114.1407, 114.2579, 114.3751, 114.4922,
114.6094,
114.7266, 114.8438, 114.961, 115.0782, 115.1954, 115.3126,
115.4297,
115.5469, 115.6641, 115.7813, 115.8985, 116.0157, 116.1329,
116.2501,
116.3672, 116.4844, 116.6016, 116.7188, 116.836, 116.9532,
117.0704,
117.1876, 117.3047, 117.4219, 117.5391, 117.6563, 117.7735,
117.8907,
118.0079, 118.1251, 118.2422, 118.3594, 118.4766, 118.5938,
118.711,
118.8282, 118.9454, 119.0626, 119.1797, 119.2969, 119.4141,
119.5313,
119.6485, 119.7657, 119.8829, 120.0001, 120.1172, 120.2344,
120.3516,
120.4688, 120.586, 120.7032, 120.8204, 120.9376, 121.0547,
121.1719,
121.2891, 121.4063, 121.5235, 121.6407, 121.7579, 121.8751,
121.9922,
122.1094, 122.2266, 122.3438, 122.461, 122.5782, 122.6954,
122.8126,
122.9297, 123.0469, 123.1641, 123.2813, 123.3985, 123.5157,
123.6329,
123.7501, 123.8672, 123.9844, 124.1016, 124.2188, 124.336,
124.4532,
124.5704, 124.6876, 124.8048, 124.9219, 125.0391, 125.1563,
125.2735,
125.3907, 125.5079, 125.6251, 125.7423, 125.8594, 125.9766,
126.0938,
126.211, 126.3282, 126.4454, 126.5626, 126.6798, 126.7969,
126.9141,
127.0313, 127.1485, 127.2657, 127.3829, 127.5001, 127.6173,
127.7344,
127.8516, 127.9688, 128.086, 128.2032, 128.3204, 128.4376,
128.5547,
128.6719, 128.7891, 128.9063, 129.0235, 129.1407, 129.2579,
129.3751,
129.4922, 129.6094, 129.7266, 129.8438, 129.961, 130.0782,
130.1954,
130.3126, 130.4297, 130.5469, 130.6641, 130.7813, 130.8985,
131.0157,
131.1329, 131.2501, 131.3672, 131.4844, 131.6016, 131.7188,
131.836,
131.9532, 132.0704, 132.1876, 132.3048, 132.422, 132.5391,
132.6563,
132.7735, 132.8907, 133.0079, 133.1251, 133.2423, 133.3595,
133.4766,
133.5938, 133.711, 133.8282, 133.9454, 134.0626, 134.1798,
134.297,
134.4141, 134.5313, 134.6485, 134.7657, 134.8829, 135.0001,
135.1173,
135.2345, 135.3516, 135.4688, 135.586, 135.7032, 135.8204,
135.9376,
136.0548, 136.172, 136.2891, 136.4063, 136.5235, 136.6407,
136.7579,
136.8751, 136.9923, 137.1095, 137.2266, 137.3438, 137.461,
137.5782,
137.6954, 137.8126, 137.9298, 138.047, 138.1641, 138.2813,
138.3985,
138.5157, 138.6329, 138.7501, 138.8673, 138.9845, 139.1016,
139.2188,
139.336, 139.4532, 139.5704, 139.6876, 139.8048, 139.922,
140.0391,
140.1563, 140.2735, 140.3907, 140.5079, 140.6251, 140.7423,
140.8595,
140.9766, 141.0938, 141.211, 141.3282, 141.4454, 141.5626,
141.6798,
141.797, 141.9141, 142.0313, 142.1485, 142.2657, 142.3829,
142.5001,
142.6173, 142.7345, 142.8516, 142.9688, 143.086, 143.2032,
143.3204,
143.4376, 143.5548, 143.672, 143.7891, 143.9063, 144.0235,
144.1407,
144.2579, 144.3751, 144.4923, 144.6095, 144.7266, 144.8438,
144.961,
145.0782, 145.1954, 145.3126, 145.4298, 145.547, 145.6641,
145.7813,
145.8985, 146.0157, 146.1329, 146.2501, 146.3673, 146.4845,
146.6016,
146.7188, 146.836, 146.9532, 147.0704, 147.1876, 147.3048,
147.422,
147.5391, 147.6563, 147.7735, 147.8907, 148.0079, 148.1251,
148.2423,
148.3595, 148.4766, 148.5938, 148.711, 148.8282, 148.9454,
149.0626,
149.1798, 149.297, 149.4141, 149.5313, 149.6485, 149.7657,
149.8829,
150.0001, 150.1173, 150.2345, 150.3516, 150.4688, 150.586,
150.7032,
150.8204, 150.9376, 151.0548, 151.172, 151.2891, 151.4063,
151.5235,
151.6407, 151.7579, 151.8751, 151.9923, 152.1095, 152.2266,
152.3438,
152.461, 152.5782, 152.6954, 152.8126, 152.9298, 153.047,
153.1641,
153.2813, 153.3985, 153.5157, 153.6329, 153.7501, 153.8673,
153.9845,
154.1016, 154.2188, 154.336, 154.4532, 154.5704, 154.6876,
154.8048,
154.922, 155.0391, 155.1563, 155.2735, 155.3907, 155.5079,
155.6251,
155.7423, 155.8595, 155.9766, 156.0938, 156.211, 156.3282,
156.4454,
156.5626, 156.6798, 156.797, 156.9141, 157.0313, 157.1485,
157.2657,
157.3829, 157.5001, 157.6173, 157.7345, 157.8516, 157.9688,
158.086,
158.2032, 158.3204, 158.4376, 158.5548, 158.672, 158.7891,
158.9063,
159.0235, 159.1407, 159.2579, 159.3751, 159.4923, 159.6095,
159.7266,
159.8438, 159.961, 160.0782, 160.1954, 160.3126, 160.4298,
160.547,
160.6641, 160.7813, 160.8985, 161.0157, 161.1329, 161.2501,
161.3673,
161.4845, 161.6017, 161.7188, 161.836, 161.9532, 162.0704,
162.1876,
162.3048, 162.422, 162.5392, 162.6563, 162.7735, 162.8907,
163.0079,
163.1251, 163.2423, 163.3595, 163.4767, 163.5938, 163.711,
163.8282,
163.9454, 164.0626, 164.1798, 164.297, 164.4142, 164.5313,
164.6485,
164.7657, 164.8829, 165.0001, 165.1173, 165.2345, 165.3517,
165.4688,
165.586, 165.7032, 165.8204, 165.9376, 166.0548, 166.172,
166.2892,
166.4063, 166.5235, 166.6407, 166.7579, 166.8751, 166.9923,
167.1095,
167.2267, 167.3438, 167.461, 167.5782, 167.6954, 167.8126,
167.9298,
168.047, 168.1642, 168.2813, 168.3985, 168.5157, 168.6329,
168.7501,
168.8673, 168.9845, 169.1017, 169.2188, 169.336, 169.4532,
169.5704,
169.6876, 169.8048, 169.922, 170.0392, 170.1563, 170.2735,
170.3907,
170.5079, 170.6251, 170.7423, 170.8595, 170.9767, 171.0938,
171.211,
171.3282, 171.4454, 171.5626, 171.6798, 171.797, 171.9142,
172.0313,
172.1485, 172.2657, 172.3829, 172.5001, 172.6173, 172.7345,
172.8517,
172.9688, 173.086, 173.2032, 173.3204, 173.4376, 173.5548,
173.672,
173.7892, 173.9063, 174.0235, 174.1407, 174.2579, 174.3751,
174.4923,
174.6095, 174.7267, 174.8438, 174.961, 175.0782, 175.1954,
175.3126,
175.4298, 175.547, 175.6642, 175.7813, 175.8985, 176.0157,
176.1329,
176.2501, 176.3673, 176.4845, 176.6017, 176.7188, 176.836,
176.9532,
177.0704, 177.1876, 177.3048, 177.422, 177.5392, 177.6563,
177.7735,
177.8907, 178.0079, 178.1251, 178.2423, 178.3595, 178.4767,
178.5938,
178.711, 178.8282, 178.9454, 179.0626, 179.1798, 179.297,
179.4142,
179.5313, 179.6485, 179.7657, 179.8829, 180.0001, 180.1173,
180.2345,
180.3517, 180.4688, 180.586, 180.7032, 180.8204, 180.9376,
181.0548,
181.172, 181.2892, 181.4063, 181.5235, 181.6407, 181.7579,
181.8751,
181.9923, 182.1095, 182.2267, 182.3438, 182.461, 182.5782,
182.6954,
182.8126, 182.9298, 183.047, 183.1642, 183.2813, 183.3985,
183.5157,
183.6329, 183.7501, 183.8673, 183.9845, 184.1017, 184.2188,
184.336,
184.4532, 184.5704, 184.6876, 184.8048, 184.922, 185.0392,
185.1563,
185.2735, 185.3907, 185.5079, 185.6251, 185.7423, 185.8595,
185.9767,
186.0938, 186.211, 186.3282, 186.4454, 186.5626, 186.6798,
186.797,
186.9142, 187.0313, 187.1485, 187.2657, 187.3829, 187.5001,
187.6173,
187.7345, 187.8517, 187.9688, 188.086, 188.2032, 188.3204,
188.4376,
188.5548, 188.672, 188.7892, 188.9063, 189.0235, 189.1407,
189.2579,
189.3751, 189.4923, 189.6095, 189.7267, 189.8438, 189.961,
190.0782,
190.1954, 190.3126, 190.4298, 190.547, 190.6642, 190.7814,
190.8985,
191.0157, 191.1329, 191.2501, 191.3673, 191.4845, 191.6017,
191.7189,
191.836, 191.9532, 192.0704, 192.1876, 192.3048, 192.422,
192.5392,
192.6564, 192.7735, 192.8907, 193.0079, 193.1251, 193.2423,
193.3595,
193.4767, 193.5939, 193.711, 193.8282, 193.9454, 194.0626,
194.1798,
194.297, 194.4142, 194.5314, 194.6485, 194.7657, 194.8829,
195.0001,
195.1173, 195.2345, 195.3517, 195.4689, 195.586, 195.7032,
195.8204,
195.9376, 196.0548, 196.172, 196.2892, 196.4064, 196.5235,
196.6407,
196.7579, 196.8751, 196.9923, 197.1095, 197.2267, 197.3439,
197.461,
197.5782, 197.6954, 197.8126, 197.9298, 198.047, 198.1642,
198.2814,
198.3985, 198.5157, 198.6329, 198.7501, 198.8673, 198.9845,
199.1017,
199.2189, 199.336, 199.4532, 199.5704, 199.6876, 199.8048,
199.922,
200.0392, 200.1564, 200.2735, 200.3907, 200.5079, 200.6251,
200.7423,
200.8595, 200.9767, 201.0939, 201.211, 201.3282, 201.4454,
201.5626,
201.6798, 201.797, 201.9142, 202.0314, 202.1485, 202.2657,
202.3829,
202.5001, 202.6173, 202.7345, 202.8517, 202.9689, 203.086,
203.2032,
203.3204, 203.4376, 203.5548, 203.672, 203.7892, 203.9064,
204.0235,
204.1407, 204.2579, 204.3751, 204.4923, 204.6095, 204.7267,
204.8439,
204.961, 205.0782, 205.1954, 205.3126, 205.4298, 205.547,
205.6642,
205.7814, 205.8985, 206.0157, 206.1329, 206.2501, 206.3673,
206.4845,
206.6017, 206.7189, 206.836, 206.9532, 207.0704, 207.1876,
207.3048,
207.422, 207.5392, 207.6564, 207.7735, 207.8907, 208.0079,
208.1251,
208.2423, 208.3595, 208.4767, 208.5939, 208.711, 208.8282,
208.9454,
209.0626, 209.1798, 209.297, 209.4142, 209.5314, 209.6485,
209.7657,
209.8829, 210.0001, 210.1173, 210.2345, 210.3517, 210.4689,
210.586,
210.7032, 210.8204, 210.9376, 211.0548, 211.172, 211.2892,
211.4064,
211.5235, 211.6407, 211.7579, 211.8751, 211.9923, 212.1095,
212.2267,
212.3439, 212.461, 212.5782, 212.6954, 212.8126, 212.9298,
213.047,
213.1642, 213.2814, 213.3985, 213.5157, 213.6329, 213.7501,
213.8673,
213.9845, 214.1017, 214.2189, 214.336, 214.4532, 214.5704,
214.6876,
214.8048, 214.922, 215.0392, 215.1564, 215.2735, 215.3907,
215.5079,
215.6251, 215.7423, 215.8595, 215.9767, 216.0939, 216.211,
216.3282,
216.4454, 216.5626, 216.6798, 216.797, 216.9142, 217.0314,
217.1485,
217.2657, 217.3829, 217.5001, 217.6173, 217.7345, 217.8517,
217.9689,
218.086, 218.2032, 218.3204, 218.4376, 218.5548, 218.672,
218.7892,
218.9064, 219.0235, 219.1407, 219.2579, 219.3751, 219.4923,
219.6095,
219.7267, 219.8439, 219.9611, 220.0782, 220.1954, 220.3126,
220.4298,
220.547, 220.6642, 220.7814, 220.8986, 221.0157, 221.1329,
221.2501,
221.3673, 221.4845, 221.6017, 221.7189, 221.8361, 221.9532,
222.0704,
222.1876, 222.3048, 222.422, 222.5392, 222.6564, 222.7736,
222.8907,
223.0079, 223.1251, 223.2423, 223.3595, 223.4767, 223.5939,
223.7111,
223.8282, 223.9454, 224.0626, 224.1798, 224.297, 224.4142,
224.5314,
224.6486, 224.7657, 224.8829, 225.0001, 225.1173, 225.2345,
225.3517,
225.4689, 225.5861, 225.7032, 225.8204, 225.9376, 226.0548,
226.172,
226.2892, 226.4064, 226.5236, 226.6407, 226.7579, 226.8751,
226.9923,
227.1095, 227.2267, 227.3439, 227.4611, 227.5782, 227.6954,
227.8126,
227.9298, 228.047, 228.1642, 228.2814, 228.3986, 228.5157,
228.6329,
228.7501, 228.8673, 228.9845, 229.1017, 229.2189, 229.3361,
229.4532,
229.5704, 229.6876, 229.8048, 229.922, 230.0392, 230.1564,
230.2736,
230.3907, 230.5079, 230.6251, 230.7423, 230.8595, 230.9767,
231.0939,
231.2111, 231.3282, 231.4454, 231.5626, 231.6798, 231.797,
231.9142,
232.0314, 232.1486, 232.2657, 232.3829, 232.5001, 232.6173,
232.7345,
232.8517, 232.9689, 233.0861, 233.2032, 233.3204, 233.4376,
233.5548,
233.672, 233.7892, 233.9064, 234.0236, 234.1407, 234.2579,
234.3751,
234.4923, 234.6095, 234.7267, 234.8439, 234.9611, 235.0782,
235.1954,
235.3126, 235.4298, 235.547, 235.6642, 235.7814, 235.8986,
236.0157,
236.1329, 236.2501, 236.3673, 236.4845, 236.6017, 236.7189,
236.8361,
236.9532, 237.0704, 237.1876, 237.3048, 237.422, 237.5392,
237.6564,
237.7736, 237.8907, 238.0079, 238.1251, 238.2423, 238.3595,
238.4767,
238.5939, 238.7111, 238.8282, 238.9454, 239.0626, 239.1798,
239.297,
239.4142, 239.5314, 239.6486, 239.7657, 239.8829, 240.0001,
240.1173,
240.2345, 240.3517, 240.4689, 240.5861, 240.7032, 240.8204,
240.9376,
241.0548, 241.172, 241.2892, 241.4064, 241.5236, 241.6407,
241.7579,
241.8751, 241.9923, 242.1095, 242.2267, 242.3439, 242.4611,
242.5782,
242.6954, 242.8126, 242.9298, 243.047, 243.1642, 243.2814,
243.3986,
243.5157, 243.6329, 243.7501, 243.8673, 243.9845, 244.1017,
244.2189,
244.3361, 244.4532, 244.5704, 244.6876, 244.8048, 244.922,
245.0392,
245.1564, 245.2736, 245.3907, 245.5079, 245.6251, 245.7423,
245.8595,
245.9767, 246.0939, 246.2111, 246.3282, 246.4454, 246.5626,
246.6798,
246.797, 246.9142, 247.0314, 247.1486, 247.2657, 247.3829,
247.5001,
247.6173, 247.7345, 247.8517, 247.9689, 248.0861, 248.2032,
248.3204,
248.4376, 248.5548, 248.672, 248.7892, 248.9064, 249.0236,
249.1408,
249.2579, 249.3751, 249.4923, 249.6095, 249.7267, 249.8439,
249.9611,
250.0783, 250.1954, 250.3126, 250.4298, 250.547, 250.6642,
250.7814,
250.8986, 251.0158, 251.1329, 251.2501, 251.3673, 251.4845,
251.6017,
251.7189, 251.8361, 251.9533, 252.0704, 252.1876, 252.3048,
252.422,
252.5392, 252.6564, 252.7736, 252.8908, 253.0079, 253.1251,
253.2423,
253.3595, 253.4767, 253.5939, 253.7111, 253.8283, 253.9454,
254.0626,
254.1798, 254.297, 254.4142, 254.5314, 254.6486, 254.7658,
254.8829,
255.0001, 255.1173, 255.2345, 255.3517, 255.4689, 255.5861,
255.7033,
255.8204, 255.9376, 256.0548, 256.172, 256.2892, 256.4064,
256.5236,
256.6407, 256.7579, 256.8751, 256.9923, 257.1095, 257.2267,
257.3439,
257.4611, 257.5782, 257.6954, 257.8126, 257.9298, 258.047,
258.1642,
258.2814, 258.3986, 258.5157, 258.6329, 258.7501, 258.8673,
258.9845,
259.1017, 259.2189, 259.3361, 259.4532, 259.5704, 259.6876,
259.8048,
259.922, 260.0392, 260.1564, 260.2736, 260.3907, 260.5079,
260.6251,
260.7423, 260.8595, 260.9767, 261.0939, 261.2111, 261.3282,
261.4454,
261.5626, 261.6798, 261.797, 261.9142, 262.0314, 262.1486,
262.2657,
262.3829, 262.5001, 262.6173, 262.7345, 262.8517, 262.9689,
263.0861,
263.2032, 263.3204, 263.4376, 263.5548, 263.672, 263.7892,
263.9064,
264.0236, 264.1408, 264.258, 264.3752, 264.4923, 264.6095,
264.7267,
264.8439, 264.9611, 265.0783, 265.1955, 265.3127, 265.4298,
265.547,
265.6642, 265.7814, 265.8986, 266.0158, 266.133, 266.2502,
266.3673,
266.4845, 266.6017, 266.7189, 266.8361, 266.9533, 267.0705,
267.1877,
267.3048, 267.422, 267.5392, 267.6564, 267.7736, 267.8908,
268.008,
268.1252, 268.2423, 268.3595, 268.4767, 268.5939, 268.7111,
268.8283,
268.9455, 269.0627, 269.1798, 269.297, 269.4142, 269.5314,
269.6486,
269.7658, 269.883, 270.0002, 270.1173, 270.2345, 270.3517,
270.4689,
270.5861, 270.7033, 270.8205, 270.9377, 271.0548, 271.172,
271.2892,
271.4064, 271.5236, 271.6408, 271.758, 271.8752, 271.9923,
272.1095,
272.2267, 272.3439, 272.4611, 272.5783, 272.6955, 272.8127,
272.9298,
273.047, 273.1642, 273.2814, 273.3986, 273.5158, 273.633,
273.7502,
273.8673, 273.9845, 274.1017, 274.2189, 274.3361, 274.4533,
274.5705,
274.6877, 274.8048, 274.922, 275.0392, 275.1564, 275.2736,
275.3908,
275.508, 275.6252, 275.7423, 275.8595, 275.9767, 276.0939,
276.2111,
276.3283, 276.4455, 276.5627, 276.6798, 276.797, 276.9142,
277.0314,
277.1486, 277.2658, 277.383, 277.5002, 277.6173, 277.7345,
277.8517,
277.9689, 278.0861, 278.2033, 278.3205, 278.4377, 278.5548,
278.672,
278.7892, 278.9064, 279.0236, 279.1408, 279.258, 279.3752,
279.4923,
279.6095, 279.7267, 279.8439, 279.9611, 280.0783, 280.1955,
280.3127,
280.4298, 280.547, 280.6642, 280.7814, 280.8986, 281.0158,
281.133,
281.2502, 281.3673, 281.4845, 281.6017, 281.7189, 281.8361,
281.9533,
282.0705, 282.1877, 282.3048, 282.422, 282.5392, 282.6564,
282.7736,
282.8908, 283.008, 283.1252, 283.2423, 283.3595, 283.4767,
283.5939,
283.7111, 283.8283, 283.9455, 284.0627, 284.1798, 284.297,
284.4142,
284.5314, 284.6486, 284.7658, 284.883, 285.0002, 285.1173,
285.2345,
285.3517, 285.4689, 285.5861, 285.7033, 285.8205, 285.9377,
286.0548,
286.172, 286.2892, 286.4064, 286.5236, 286.6408, 286.758,
286.8752,
286.9923, 287.1095, 287.2267, 287.3439, 287.4611, 287.5783,
287.6955,
287.8127, 287.9298, 288.047, 288.1642, 288.2814, 288.3986,
288.5158,
288.633, 288.7502, 288.8673, 288.9845, 289.1017, 289.2189,
289.3361,
289.4533, 289.5705, 289.6877, 289.8048, 289.922, 290.0392,
290.1564,
290.2736, 290.3908, 290.508, 290.6252, 290.7423, 290.8595,
290.9767,
291.0939, 291.2111, 291.3283, 291.4455, 291.5627, 291.6798,
291.797,
291.9142, 292.0314, 292.1486, 292.2658, 292.383, 292.5002,
292.6173,
292.7345, 292.8517, 292.9689, 293.0861, 293.2033, 293.3205,
293.4377,
293.5548, 293.672, 293.7892, 293.9064, 294.0236, 294.1408,
294.258,
294.3752, 294.4923, 294.6095, 294.7267, 294.8439, 294.9611,
295.0783,
295.1955, 295.3127, 295.4298, 295.547, 295.6642, 295.7814,
295.8986,
296.0158, 296.133, 296.2502, 296.3673, 296.4845, 296.6017,
296.7189,
296.8361, 296.9533, 297.0705, 297.1877, 297.3048, 297.422,
297.5392,
297.6564, 297.7736, 297.8908, 298.008, 298.1252, 298.2423,
298.3595,
298.4767, 298.5939, 298.7111, 298.8283, 298.9455, 299.0627,
299.1798,
299.297, 299.4142, 299.5314, 299.6486, 299.7658, 299.883,
300.0002,
300.1173, 300.2345, 300.3517, 300.4689, 300.5861, 300.7033,
300.8205,
300.9377, 301.0548, 301.172, 301.2892, 301.4064, 301.5236,
301.6408,
301.758, 301.8752, 301.9923, 302.1095, 302.2267, 302.3439,
302.4611,
302.5783, 302.6955, 302.8127, 302.9298, 303.047, 303.1642,
303.2814,
303.3986, 303.5158, 303.633, 303.7502, 303.8673, 303.9845,
304.1017,
304.2189, 304.3361, 304.4533, 304.5705, 304.6877, 304.8048,
304.922,
305.0392, 305.1564, 305.2736, 305.3908, 305.508, 305.6252,
305.7423,
305.8595, 305.9767, 306.0939, 306.2111, 306.3283, 306.4455,
306.5627,
306.6798, 306.797, 306.9142, 307.0314, 307.1486, 307.2658,
307.383,
307.5002, 307.6173, 307.7345, 307.8517, 307.9689, 308.0861,
308.2033,
308.3205, 308.4377, 308.5548, 308.672, 308.7892, 308.9064,
309.0236,
309.1408, 309.258, 309.3752, 309.4923, 309.6095, 309.7267,
309.8439,
309.9611, 310.0783, 310.1955, 310.3127, 310.4298, 310.547,
310.6642,
310.7814, 310.8986, 311.0158, 311.133, 311.2502, 311.3673,
311.4845,
311.6017, 311.7189, 311.8361, 311.9533, 312.0705, 312.1877,
312.3048,
312.422, 312.5392, 312.6564, 312.7736, 312.8908, 313.008,
313.1252,
313.2423, 313.3595, 313.4767, 313.5939, 313.7111, 313.8283,
313.9455,
314.0627, 314.1798, 314.297, 314.4142, 314.5314, 314.6486,
314.7658,
314.883, 315.0002, 315.1173, 315.2345, 315.3517, 315.4689,
315.5861,
315.7033, 315.8205, 315.9377, 316.0548, 316.172, 316.2892,
316.4064,
316.5236, 316.6408, 316.758, 316.8752, 316.9923, 317.1095,
317.2267,
317.3439, 317.4611, 317.5783, 317.6955, 317.8127, 317.9298,
318.047,
318.1642, 318.2814, 318.3986, 318.5158, 318.633, 318.7502,
318.8673,
318.9845, 319.1017, 319.2189, 319.3361, 319.4533, 319.5705,
319.6877,
319.8048, 319.922, 320.0392, 320.1564, 320.2736, 320.3908,
320.508,
320.6252, 320.7423, 320.8595, 320.9767, 321.0939, 321.2111,
321.3283,
321.4455, 321.5627, 321.6798, 321.797, 321.9142, 322.0314,
322.1486,
322.2658, 322.383, 322.5002, 322.6174, 322.7346, 322.8517,
322.9689,
323.0861, 323.2033, 323.3205, 323.4377, 323.5549, 323.6721,
323.7892,
323.9064, 324.0236, 324.1408, 324.258, 324.3752, 324.4924,
324.6096,
324.7267, 324.8439, 324.9611, 325.0783, 325.1955, 325.3127,
325.4299,
325.5471, 325.6642, 325.7814, 325.8986, 326.0158, 326.133,
326.2502,
326.3674, 326.4846, 326.6017, 326.7189, 326.8361, 326.9533,
327.0705,
327.1877, 327.3049, 327.4221, 327.5392, 327.6564, 327.7736,
327.8908,
328.008, 328.1252, 328.2424, 328.3596, 328.4767, 328.5939,
328.7111,
328.8283, 328.9455, 329.0627, 329.1799, 329.2971, 329.4142,
329.5314,
329.6486, 329.7658, 329.883, 330.0002, 330.1174, 330.2346,
330.3517,
330.4689, 330.5861, 330.7033, 330.8205, 330.9377, 331.0549,
331.1721,
331.2892, 331.4064, 331.5236, 331.6408, 331.758, 331.8752,
331.9924,
332.1096, 332.2267, 332.3439, 332.4611, 332.5783, 332.6955,
332.8127,
332.9299, 333.0471, 333.1642, 333.2814, 333.3986, 333.5158,
333.633,
333.7502, 333.8674, 333.9846, 334.1017, 334.2189, 334.3361,
334.4533,
334.5705, 334.6877, 334.8049, 334.9221, 335.0392, 335.1564,
335.2736,
335.3908, 335.508, 335.6252, 335.7424, 335.8596, 335.9767,
336.0939,
336.2111, 336.3283, 336.4455, 336.5627, 336.6799, 336.7971,
336.9142,
337.0314, 337.1486, 337.2658, 337.383, 337.5002, 337.6174,
337.7346,
337.8517, 337.9689, 338.0861, 338.2033, 338.3205, 338.4377,
338.5549,
338.6721, 338.7892, 338.9064, 339.0236, 339.1408, 339.258,
339.3752,
339.4924, 339.6096, 339.7267, 339.8439, 339.9611, 340.0783,
340.1955,
340.3127, 340.4299, 340.5471, 340.6642, 340.7814, 340.8986,
341.0158,
341.133, 341.2502, 341.3674, 341.4846, 341.6017, 341.7189,
341.8361,
341.9533, 342.0705, 342.1877, 342.3049, 342.4221, 342.5392,
342.6564,
342.7736, 342.8908, 343.008, 343.1252, 343.2424, 343.3596,
343.4767,
343.5939, 343.7111, 343.8283, 343.9455, 344.0627, 344.1799,
344.2971,
344.4142, 344.5314, 344.6486, 344.7658, 344.883, 345.0002,
345.1174,
345.2346, 345.3517, 345.4689, 345.5861, 345.7033, 345.8205,
345.9377,
346.0549, 346.1721, 346.2892, 346.4064, 346.5236, 346.6408,
346.758,
346.8752, 346.9924, 347.1096, 347.2267, 347.3439, 347.4611,
347.5783,
347.6955, 347.8127, 347.9299, 348.0471, 348.1642, 348.2814,
348.3986,
348.5158, 348.633, 348.7502, 348.8674, 348.9846, 349.1017,
349.2189,
349.3361, 349.4533, 349.5705, 349.6877, 349.8049, 349.9221,
350.0392,
350.1564, 350.2736, 350.3908, 350.508, 350.6252, 350.7424,
350.8596,
350.9767, 351.0939, 351.2111, 351.3283, 351.4455, 351.5627,
351.6799,
351.7971, 351.9142, 352.0314, 352.1486, 352.2658, 352.383,
352.5002,
352.6174, 352.7346, 352.8517, 352.9689, 353.0861, 353.2033,
353.3205,
353.4377, 353.5549, 353.6721, 353.7892, 353.9064, 354.0236,
354.1408,
354.258, 354.3752, 354.4924, 354.6096, 354.7267, 354.8439,
354.9611,
355.0783, 355.1955, 355.3127, 355.4299, 355.5471, 355.6642,
355.7814,
355.8986, 356.0158, 356.133, 356.2502, 356.3674, 356.4846,
356.6017,
356.7189, 356.8361, 356.9533, 357.0705, 357.1877, 357.3049,
357.4221,
357.5392, 357.6564, 357.7736, 357.8908, 358.008, 358.1252,
358.2424,
358.3596, 358.4767, 358.5939, 358.7111, 358.8283, 358.9455,
359.0627,
359.1799, 359.2971, 359.4142, 359.5314, 359.6486, 359.7658,
359.883 ;
time = 6, 12, 18, 24, 30, 36, 42, 48, 54, 60, 66, 72, 78, 84, 90, 96,
102,
108, 114, 120, 126, 132, 138, 144, 150, 156, 162, 168, 174, 180,
186,
192, 198, 204, 210, 216, 222, 228, 234, 240 ;
------------------------------------------------
Subject: problem reading netdcf file
From: John Halley Gotway
Time: Wed Jul 19 17:05:03 2017
Bill,
Sorry for the delay in responding.
I logged on to the ftp site and grabbed your sample file:
PRATEsfc6all.nc
I was able to replicate the error message you saw from met-5.2:
ERROR : plot_data_plane -> file "PRATEsfc6all.nc" not a valid data
file
If you instruct MET to interpret this file as a CF-compliant NetCDF
file,
then it runs without error, but the data is packed upside down (see
attached prate_met-5.2.png):
met-5.2/bin/plot_data_plane \
PRATEsfc6all.nc prate_met-5.2.ps \
'name="PRATEsfc"; level="(4,*,*)"; file_type=NETCDF_NCCF;'
In met-6.0, we fixed this issue and turned the world back right side
up.
And in 6.0, you don't even need to tell it that it's CF compliant:
met-6.0/bin/plot_data_plane \
PRATEsfc6all.nc prate_met-6.0.ps \
'name="PRATEsfc"; level="(4,*,*)";'
So if possible, I'd suggest using met-6.0. Hope that helps.
Thanks,
John
On Sat, Jul 15, 2017 at 11:03 AM, bill.stern at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
>
> John and others,
>
> I am now encountering a problem with MET's inability to read GFS
forecast
> files that were processed to netcdf. There are more than 75
forecast dates
> each with 40 forecast time levels. It would be a very time
consuming task
> to return to the original GRIB files and re-process each time level
with
> MET regrid_data_plane tool. So, I would like to find a way to modify
the
> existing netcdf files so they will be acceptable to MET.
>
> Here is the error I am encountering:
> /home/Shannon.Rees/met-5.2_orig/met-
5.2/src/tools/core/grid_stat/grid_stat
> /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc
> /vftmp/Bill.Stern/pid43698/GFS_native/ST4.2015012300.06h
> /work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
-outdir
> /work/Bill.Stern/NGGPS/MET5.2/output/GFS_native/20150116.
> 00Z/grid_stat//PRATEsfc/6hr/
> -v 2
> DEBUG 1: Default Config File:
> /home/Shannon.Rees/met-5.2_orig/met-5.2/share/met/config/
> GridStatConfig_default
> DEBUG 1: User Config File:
> /work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
> ERROR :
> ERROR : Trouble reading forecast file
> "/vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
>
> I have attached the output from "ncdump -c
> /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
>
> The full file can be obtained from ftp.gfdl.noaa.gov
> cd /pub/wfs
> get PRATEsfc6all.nc
>
> Thank you,
> Bill
>
>
> On Mon, Jul 10, 2017 at 2:27 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Bill,
> >
> > Ah, I understand. The regrid_data_plane tool is designed to read
exactly
> > one 2D data field for each "-field" entry you specify on the
command
> line.
> > When you ran it on a file containing 21 times, you probably got a
warning
> > about "multiple matching fields". By default, it'll just use the
first
> > match found.
> >
> > You can include additional timing information in the "-field"
entry to
> > specify which of the 21 times you actually want. Here's an
excerpt from
> > the met-6.0/data/config/README file about this:
> >
> > // - The "init_time" entry specifies the initialization time in
> > YYYYMMDD[_HH[MMSS]]
> > // format. This entry can be included in the "fcst" entry as
shown
> > below or
> > // included in the "field" entry if the user would like to use
> > different
> > // initialization times for different fields.
> > //
> > // - The "valid_time" entry specifies the valid time in
> > YYYYMMDD[_HH[MMSS]]
> > // format. This entry can be included in the "fcst" entry as
shown
> > below or
> > // included in the "field" entry if the user would like to use
> > different
> > // valid times for different fields.
> > //
> > // - The "lead_time" entry specifies the lead time in HH[MMSS]
> > // format. This entry can be included in the "fcst" entry as
shown
> > below or
> > // included in the "field" entry if the user would like to use
> > different
> > // lead times for different fields.
> >
> > So you could try running adding the "valid_time":
> >
> > /usr/local/met-6.0/bin/regrid_data_plane \
> > gfs_2012040900_F012.grib2 gfs_2012040900_F012.grib2 prate.nc \
> > -field 'name="PRATE"; level="A6"; valid_time="20120409_120000";'
> >
> > Technically, you could run regrid_data_plane once on each input
file,
> pass
> > in 21 "-field" settings, and write a single output file. But
you'll get
> an
> > error because it'll try to write the same NetCDF variable name
multiple
> > times. You could get around that by using the "-name" option to
passing
> in
> > 21 unique output variables names... but that's a whole lot of
details.
> >
> > Instead, I'd suggest running regrid_data_plane once for each 3-
hourly
> > output time and specify the "valid_time" currently being
processed. I
> > think that logic would be cleaner.
> >
> > Hope that helps.
> >
> > Thanks,
> > John
> >
> > On Mon, Jul 10, 2017 at 7:33 AM, bill.stern at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
> > >
> > > Hi John,
> > >
> > > I have followed your example of applying regrid_data_plane for
> creating a
> > > netcdf file from a grib2. The command below does create a
netcdf, but
> I
> > am
> > > only seem to be getting a single time level on the netcdf file,
while
> the
> > > grib2 file has 21 time levels. Here is my regrid_data_plane
command:
> > >
> > > regrid_data_plane nam.2017051500.conusnest.hires.tm00.grib2
> > > nam.2017051500.conusnest.hires.tm00.grib2 nam.2017051500
> .conusnest.APCP.
> > nc
> > > -field 'name = "APCP";level="A3";'
> > >
> > > What am I missing?
> > >
> > > Thanks,
> > > Bill
> > >
> > > On Fri, Jul 7, 2017 at 12:44 PM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > > Hi Bill,
> > > >
> > > > I moved your question over into the MET-Help support ticketing
> system.
> > > >
> > > > I see that you're having trouble processing the NetCDF output
of the
> > > > ncl_convert2nc utility in MET. MET is only set up to read a
handful
> of
> > > > NetCDF file formats, and unfortunately, the output of
ncl_convert2nc
> is
> > > not
> > > > one of them. The 3 NetCDF flavors that MET reads are CF-
complaint
> > > > (climate-forecast convention) files, the output of the
wrf_interp
> > > utility,
> > > > and the internal NetCDF format written by the MET tools
themselves.
> > > >
> > > > I understand that you'd like to do additional processing on
the
> > > > precipitation rate data... and NetCDF is much easier to work
with
> than
> > > > GRIB2.
> > > >
> > > > Rather than using ncl_convert2nc to reformat the GRIB2 data,
let's
> use
> > > the
> > > > MET regrid_data_plane tool instead. I'll demonstrate this
below.
> > > >
> > > > # I'll start with a sample GRIB2 GFS file that includes PRATE:
> > > >
> > > > wgrib2 gfs_2012040900_F012.grib2 | grep PRATE
> > > > 199:37137213:d=2012040900:PRATE:surface:6-12 hour ave fcst:
> > > >
> > > > # Call regrid_data_plane using the -field option to select the
PRATE
> > > record
> > > >
> > > > /usr/local/met-6.0/bin/regrid_data_plane \
> > > > gfs_2012040900_F012.grib2 gfs_2012040900_F012.grib2 prate.nc \
> > > > -field 'name="PRATE"; level="A6";'
> > > >
> > > > DEBUG 1: Reading data file: gfs_2012040900_F012.grib2
> > > > DEBUG 2: Input grid: Projection: Lat/Lon Nx: 720 Ny: 361
lat_ll:
> > -90.000
> > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> > > > DEBUG 2: Output grid: Projection: Lat/Lon Nx: 720 Ny: 361
lat_ll:
> > -90.000
> > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> > > > DEBUG 2: Interpolation options: method = NEAREST, width = 1,
shape =
> > > > SQUARE, vld_thresh = 0.5
> > > > DEBUG 2: Range of input data (name="PRATE"; level="A6";) is 0
to
> > > 0.004075.
> > > > DEBUG 2: Range of regridded data (name="PRATE"; level="A6";)
is 0 to
> > > > 0.004075.
> > > > DEBUG 1: Writing output file: prate.nc
> > > >
> > > > Since the input and output grids are the same, no re-gridding
is
> > actually
> > > > being done. You could have also used the pcp_combine tool to
do the
> > same
> > > > thing. But the nice thing about regrid_data_plane is that you
could
> > > > include multiple fields in the output by using the "-field"
command
> > line
> > > > option multiple times.
> > > >
> > > > Then you can edit the NetCDF output of regrid_data_plane
however
> you'd
> > > > like, and MET should be able to read that file.
> > > >
> > > > Hope that helps.
> > > >
> > > > Thanks,
> > > > John
> > > >
> > >
> > >
> > >
> > > --
> > > Bill Stern, Meteorologist
> > > Room 206
> > > NOAA/Geophysical Fluid Dynamics Laboratory
> > > Princeton University Forrestal Campus
> > > 201 Forrestal Road Princeton, NJ 08540-6649
> > > Tel: (609)452-6545
> > > Fax: (609)987-5063
> > > ------------------------------
> > > ------------------------------------
> > > Email Address: bill.stern at noaa.gov
> > >
------------------------------------------------------------------
> > > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > >
------------------------------------------------------------------
> > > On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-
gfdl-noaa
> > >
------------------------------------------------------------------
> > >
> > >
> >
> >
>
>
> --
> Bill Stern, Meteorologist
> Room 206
> NOAA/Geophysical Fluid Dynamics Laboratory
> Princeton University Forrestal Campus
> 201 Forrestal Road Princeton, NJ 08540-6649
> Tel: (609)452-6545
> Fax: (609)987-5063
> ------------------------------
> ------------------------------------
> Email Address: bill.stern at noaa.gov
> ------------------------------------------------------------------
> Anonymous ftp Address: ftp.gfdl.noaa.gov
> ------------------------------------------------------------------
> On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-gfdl-
noaa
> ------------------------------------------------------------------
>
>
------------------------------------------------
Subject: problem reading netdcf file
From: bill.stern at noaa.gov
Time: Wed Jul 19 19:08:49 2017
Hi John,
This is very helpful. It looks like we should be working with met-6.0
Thank you,
Bill
On Wed, Jul 19, 2017 at 7:05 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Bill,
>
> Sorry for the delay in responding.
>
> I logged on to the ftp site and grabbed your sample file:
PRATEsfc6all.nc
>
> I was able to replicate the error message you saw from met-5.2:
> ERROR : plot_data_plane -> file "PRATEsfc6all.nc" not a valid data
file
>
> If you instruct MET to interpret this file as a CF-compliant NetCDF
file,
> then it runs without error, but the data is packed upside down (see
> attached prate_met-5.2.png):
>
> met-5.2/bin/plot_data_plane \
> PRATEsfc6all.nc prate_met-5.2.ps \
> 'name="PRATEsfc"; level="(4,*,*)"; file_type=NETCDF_NCCF;'
>
> In met-6.0, we fixed this issue and turned the world back right side
up.
> And in 6.0, you don't even need to tell it that it's CF compliant:
>
> met-6.0/bin/plot_data_plane \
> PRATEsfc6all.nc prate_met-6.0.ps \
> 'name="PRATEsfc"; level="(4,*,*)";'
>
> So if possible, I'd suggest using met-6.0. Hope that helps.
>
> Thanks,
> John
>
> On Sat, Jul 15, 2017 at 11:03 AM, bill.stern at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
> >
> > John and others,
> >
> > I am now encountering a problem with MET's inability to read GFS
forecast
> > files that were processed to netcdf. There are more than 75
forecast
> dates
> > each with 40 forecast time levels. It would be a very time
consuming
> task
> > to return to the original GRIB files and re-process each time
level with
> > MET regrid_data_plane tool. So, I would like to find a way to
modify the
> > existing netcdf files so they will be acceptable to MET.
> >
> > Here is the error I am encountering:
> > /home/Shannon.Rees/met-5.2_orig/met-5.2/src/tools/core/
> grid_stat/grid_stat
> > /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc
> > /vftmp/Bill.Stern/pid43698/GFS_native/ST4.2015012300.06h
> > /work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
-outdir
> > /work/Bill.Stern/NGGPS/MET5.2/output/GFS_native/20150116.
> > 00Z/grid_stat//PRATEsfc/6hr/
> > -v 2
> > DEBUG 1: Default Config File:
> > /home/Shannon.Rees/met-5.2_orig/met-5.2/share/met/config/
> > GridStatConfig_default
> > DEBUG 1: User Config File:
> > /work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
> > ERROR :
> > ERROR : Trouble reading forecast file
> > "/vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
> >
> > I have attached the output from "ncdump -c
> > /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
> >
> > The full file can be obtained from ftp.gfdl.noaa.gov
> > cd /pub/wfs
> > get PRATEsfc6all.nc
> >
> > Thank you,
> > Bill
> >
> >
> > On Mon, Jul 10, 2017 at 2:27 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Bill,
> > >
> > > Ah, I understand. The regrid_data_plane tool is designed to
read
> exactly
> > > one 2D data field for each "-field" entry you specify on the
command
> > line.
> > > When you ran it on a file containing 21 times, you probably got
a
> warning
> > > about "multiple matching fields". By default, it'll just use
the first
> > > match found.
> > >
> > > You can include additional timing information in the "-field"
entry to
> > > specify which of the 21 times you actually want. Here's an
excerpt
> from
> > > the met-6.0/data/config/README file about this:
> > >
> > > // - The "init_time" entry specifies the initialization time
in
> > > YYYYMMDD[_HH[MMSS]]
> > > // format. This entry can be included in the "fcst" entry
as shown
> > > below or
> > > // included in the "field" entry if the user would like to
use
> > > different
> > > // initialization times for different fields.
> > > //
> > > // - The "valid_time" entry specifies the valid time in
> > > YYYYMMDD[_HH[MMSS]]
> > > // format. This entry can be included in the "fcst" entry
as shown
> > > below or
> > > // included in the "field" entry if the user would like to
use
> > > different
> > > // valid times for different fields.
> > > //
> > > // - The "lead_time" entry specifies the lead time in HH[MMSS]
> > > // format. This entry can be included in the "fcst" entry
as shown
> > > below or
> > > // included in the "field" entry if the user would like to
use
> > > different
> > > // lead times for different fields.
> > >
> > > So you could try running adding the "valid_time":
> > >
> > > /usr/local/met-6.0/bin/regrid_data_plane \
> > > gfs_2012040900_F012.grib2 gfs_2012040900_F012.grib2 prate.nc \
> > > -field 'name="PRATE"; level="A6"; valid_time="20120409_120000";'
> > >
> > > Technically, you could run regrid_data_plane once on each input
file,
> > pass
> > > in 21 "-field" settings, and write a single output file. But
you'll
> get
> > an
> > > error because it'll try to write the same NetCDF variable name
multiple
> > > times. You could get around that by using the "-name" option to
> passing
> > in
> > > 21 unique output variables names... but that's a whole lot of
details.
> > >
> > > Instead, I'd suggest running regrid_data_plane once for each 3-
hourly
> > > output time and specify the "valid_time" currently being
processed. I
> > > think that logic would be cleaner.
> > >
> > > Hope that helps.
> > >
> > > Thanks,
> > > John
> > >
> > > On Mon, Jul 10, 2017 at 7:33 AM, bill.stern at noaa.gov via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134
>
> > > >
> > > > Hi John,
> > > >
> > > > I have followed your example of applying regrid_data_plane for
> > creating a
> > > > netcdf file from a grib2. The command below does create a
netcdf,
> but
> > I
> > > am
> > > > only seem to be getting a single time level on the netcdf
file, while
> > the
> > > > grib2 file has 21 time levels. Here is my regrid_data_plane
> command:
> > > >
> > > > regrid_data_plane nam.2017051500.conusnest.hires.tm00.grib2
> > > > nam.2017051500.conusnest.hires.tm00.grib2 nam.2017051500
> > .conusnest.APCP.
> > > nc
> > > > -field 'name = "APCP";level="A3";'
> > > >
> > > > What am I missing?
> > > >
> > > > Thanks,
> > > > Bill
> > > >
> > > > On Fri, Jul 7, 2017 at 12:44 PM, John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > > Hi Bill,
> > > > >
> > > > > I moved your question over into the MET-Help support
ticketing
> > system.
> > > > >
> > > > > I see that you're having trouble processing the NetCDF
output of
> the
> > > > > ncl_convert2nc utility in MET. MET is only set up to read a
> handful
> > of
> > > > > NetCDF file formats, and unfortunately, the output of
> ncl_convert2nc
> > is
> > > > not
> > > > > one of them. The 3 NetCDF flavors that MET reads are CF-
complaint
> > > > > (climate-forecast convention) files, the output of the
wrf_interp
> > > > utility,
> > > > > and the internal NetCDF format written by the MET tools
themselves.
> > > > >
> > > > > I understand that you'd like to do additional processing on
the
> > > > > precipitation rate data... and NetCDF is much easier to work
with
> > than
> > > > > GRIB2.
> > > > >
> > > > > Rather than using ncl_convert2nc to reformat the GRIB2 data,
let's
> > use
> > > > the
> > > > > MET regrid_data_plane tool instead. I'll demonstrate this
below.
> > > > >
> > > > > # I'll start with a sample GRIB2 GFS file that includes
PRATE:
> > > > >
> > > > > wgrib2 gfs_2012040900_F012.grib2 | grep PRATE
> > > > > 199:37137213:d=2012040900:PRATE:surface:6-12 hour ave fcst:
> > > > >
> > > > > # Call regrid_data_plane using the -field option to select
the
> PRATE
> > > > record
> > > > >
> > > > > /usr/local/met-6.0/bin/regrid_data_plane \
> > > > > gfs_2012040900_F012.grib2 gfs_2012040900_F012.grib2 prate.nc
\
> > > > > -field 'name="PRATE"; level="A6";'
> > > > >
> > > > > DEBUG 1: Reading data file: gfs_2012040900_F012.grib2
> > > > > DEBUG 2: Input grid: Projection: Lat/Lon Nx: 720 Ny: 361
lat_ll:
> > > -90.000
> > > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> > > > > DEBUG 2: Output grid: Projection: Lat/Lon Nx: 720 Ny: 361
lat_ll:
> > > -90.000
> > > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> > > > > DEBUG 2: Interpolation options: method = NEAREST, width = 1,
shape
> =
> > > > > SQUARE, vld_thresh = 0.5
> > > > > DEBUG 2: Range of input data (name="PRATE"; level="A6";) is
0 to
> > > > 0.004075.
> > > > > DEBUG 2: Range of regridded data (name="PRATE"; level="A6";)
is 0
> to
> > > > > 0.004075.
> > > > > DEBUG 1: Writing output file: prate.nc
> > > > >
> > > > > Since the input and output grids are the same, no re-
gridding is
> > > actually
> > > > > being done. You could have also used the pcp_combine tool
to do
> the
> > > same
> > > > > thing. But the nice thing about regrid_data_plane is that
you
> could
> > > > > include multiple fields in the output by using the "-field"
command
> > > line
> > > > > option multiple times.
> > > > >
> > > > > Then you can edit the NetCDF output of regrid_data_plane
however
> > you'd
> > > > > like, and MET should be able to read that file.
> > > > >
> > > > > Hope that helps.
> > > > >
> > > > > Thanks,
> > > > > John
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Bill Stern, Meteorologist
> > > > Room 206
> > > > NOAA/Geophysical Fluid Dynamics Laboratory
> > > > Princeton University Forrestal Campus
> > > > 201 Forrestal Road Princeton, NJ 08540-6649
> > > > Tel: (609)452-6545
> > > > Fax: (609)987-5063
> > > > ------------------------------
> > > > ------------------------------------
> > > > Email Address: bill.stern at noaa.gov
> > > >
------------------------------------------------------------------
> > > > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > > >
------------------------------------------------------------------
> > > > On the World Wide Web: http://www.gfdl.noaa.gov/bill-
> stern-gfdl-noaa
> > > >
------------------------------------------------------------------
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Bill Stern, Meteorologist
> > Room 206
> > NOAA/Geophysical Fluid Dynamics Laboratory
> > Princeton University Forrestal Campus
> > 201 Forrestal Road Princeton, NJ 08540-6649
> > Tel: (609)452-6545
> > Fax: (609)987-5063
> > ------------------------------
> > ------------------------------------
> > Email Address: bill.stern at noaa.gov
> > ------------------------------------------------------------------
> > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > ------------------------------------------------------------------
> > On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-gfdl-
noaa
> > ------------------------------------------------------------------
> >
> >
>
>
--
Bill Stern, Meteorologist
Room 206
NOAA/Geophysical Fluid Dynamics Laboratory
Princeton University Forrestal Campus
201 Forrestal Road Princeton, NJ 08540-6649
Tel: (609)452-6545
Fax: (609)987-5063
------------------------------
------------------------------------
Email Address: bill.stern at noaa.gov
------------------------------------------------------------------
Anonymous ftp Address: ftp.gfdl.noaa.gov
------------------------------------------------------------------
On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-gfdl-noaa
------------------------------------------------------------------
------------------------------------------------
Subject: problem reading netdcf file
From: John Halley Gotway
Time: Wed Jul 19 22:02:45 2017
You know Bill,
Looking more closely at these plots I sent, I suspect that there's
actually
a problem in met-6.0.
It looks like the data matches the map background of 5.2 well. In
6.0, we
flipped the map right side but the data no longer matches the map
well.
Do you agree?
John
On Wed, Jul 19, 2017 at 7:08 PM bill.stern at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
>
> Hi John,
>
> This is very helpful. It looks like we should be working with met-
6.0
>
> Thank you,
> Bill
>
> On Wed, Jul 19, 2017 at 7:05 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Bill,
> >
> > Sorry for the delay in responding.
> >
> > I logged on to the ftp site and grabbed your sample file:
PRATEsfc6all.nc
> >
> > I was able to replicate the error message you saw from met-5.2:
> > ERROR : plot_data_plane -> file "PRATEsfc6all.nc" not a valid
data file
> >
> > If you instruct MET to interpret this file as a CF-compliant
NetCDF file,
> > then it runs without error, but the data is packed upside down
(see
> > attached prate_met-5.2.png):
> >
> > met-5.2/bin/plot_data_plane \
> > PRATEsfc6all.nc prate_met-5.2.ps \
> > 'name="PRATEsfc"; level="(4,*,*)"; file_type=NETCDF_NCCF;'
> >
> > In met-6.0, we fixed this issue and turned the world back right
side up.
> > And in 6.0, you don't even need to tell it that it's CF compliant:
> >
> > met-6.0/bin/plot_data_plane \
> > PRATEsfc6all.nc prate_met-6.0.ps \
> > 'name="PRATEsfc"; level="(4,*,*)";'
> >
> > So if possible, I'd suggest using met-6.0. Hope that helps.
> >
> > Thanks,
> > John
> >
> > On Sat, Jul 15, 2017 at 11:03 AM, bill.stern at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
> > >
> > > John and others,
> > >
> > > I am now encountering a problem with MET's inability to read GFS
> forecast
> > > files that were processed to netcdf. There are more than 75
forecast
> > dates
> > > each with 40 forecast time levels. It would be a very time
consuming
> > task
> > > to return to the original GRIB files and re-process each time
level
> with
> > > MET regrid_data_plane tool. So, I would like to find a way to
modify
> the
> > > existing netcdf files so they will be acceptable to MET.
> > >
> > > Here is the error I am encountering:
> > > /home/Shannon.Rees/met-5.2_orig/met-5.2/src/tools/core/
> > grid_stat/grid_stat
> > > /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc
> > > /vftmp/Bill.Stern/pid43698/GFS_native/ST4.2015012300.06h
> > > /work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
-outdir
> > > /work/Bill.Stern/NGGPS/MET5.2/output/GFS_native/20150116.
> > > 00Z/grid_stat//PRATEsfc/6hr/
> > > -v 2
> > > DEBUG 1: Default Config File:
> > > /home/Shannon.Rees/met-5.2_orig/met-5.2/share/met/config/
> > > GridStatConfig_default
> > > DEBUG 1: User Config File:
> > > /work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
> > > ERROR :
> > > ERROR : Trouble reading forecast file
> > > "/vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
> > >
> > > I have attached the output from "ncdump -c
> > > /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
> > >
> > > The full file can be obtained from ftp.gfdl.noaa.gov
> > > cd /pub/wfs
> > > get PRATEsfc6all.nc
> > >
> > > Thank you,
> > > Bill
> > >
> > >
> > > On Mon, Jul 10, 2017 at 2:27 PM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > > Bill,
> > > >
> > > > Ah, I understand. The regrid_data_plane tool is designed to
read
> > exactly
> > > > one 2D data field for each "-field" entry you specify on the
command
> > > line.
> > > > When you ran it on a file containing 21 times, you probably
got a
> > warning
> > > > about "multiple matching fields". By default, it'll just use
the
> first
> > > > match found.
> > > >
> > > > You can include additional timing information in the "-field"
entry
> to
> > > > specify which of the 21 times you actually want. Here's an
excerpt
> > from
> > > > the met-6.0/data/config/README file about this:
> > > >
> > > > // - The "init_time" entry specifies the initialization time
in
> > > > YYYYMMDD[_HH[MMSS]]
> > > > // format. This entry can be included in the "fcst" entry
as
> shown
> > > > below or
> > > > // included in the "field" entry if the user would like to
use
> > > > different
> > > > // initialization times for different fields.
> > > > //
> > > > // - The "valid_time" entry specifies the valid time in
> > > > YYYYMMDD[_HH[MMSS]]
> > > > // format. This entry can be included in the "fcst" entry
as
> shown
> > > > below or
> > > > // included in the "field" entry if the user would like to
use
> > > > different
> > > > // valid times for different fields.
> > > > //
> > > > // - The "lead_time" entry specifies the lead time in
HH[MMSS]
> > > > // format. This entry can be included in the "fcst" entry
as
> shown
> > > > below or
> > > > // included in the "field" entry if the user would like to
use
> > > > different
> > > > // lead times for different fields.
> > > >
> > > > So you could try running adding the "valid_time":
> > > >
> > > > /usr/local/met-6.0/bin/regrid_data_plane \
> > > > gfs_2012040900_F012.grib2 gfs_2012040900_F012.grib2 prate.nc \
> > > > -field 'name="PRATE"; level="A6";
valid_time="20120409_120000";'
> > > >
> > > > Technically, you could run regrid_data_plane once on each
input file,
> > > pass
> > > > in 21 "-field" settings, and write a single output file. But
you'll
> > get
> > > an
> > > > error because it'll try to write the same NetCDF variable name
> multiple
> > > > times. You could get around that by using the "-name" option
to
> > passing
> > > in
> > > > 21 unique output variables names... but that's a whole lot of
> details.
> > > >
> > > > Instead, I'd suggest running regrid_data_plane once for each
3-hourly
> > > > output time and specify the "valid_time" currently being
processed.
> I
> > > > think that logic would be cleaner.
> > > >
> > > > Hope that helps.
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > > On Mon, Jul 10, 2017 at 7:33 AM, bill.stern at noaa.gov via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
> > > > >
> > > > > Hi John,
> > > > >
> > > > > I have followed your example of applying regrid_data_plane
for
> > > creating a
> > > > > netcdf file from a grib2. The command below does create a
netcdf,
> > but
> > > I
> > > > am
> > > > > only seem to be getting a single time level on the netcdf
file,
> while
> > > the
> > > > > grib2 file has 21 time levels. Here is my regrid_data_plane
> > command:
> > > > >
> > > > > regrid_data_plane nam.2017051500.conusnest.hires.tm00.grib2
> > > > > nam.2017051500.conusnest.hires.tm00.grib2 nam.2017051500
> > > .conusnest.APCP.
> > > > nc
> > > > > -field 'name = "APCP";level="A3";'
> > > > >
> > > > > What am I missing?
> > > > >
> > > > > Thanks,
> > > > > Bill
> > > > >
> > > > > On Fri, Jul 7, 2017 at 12:44 PM, John Halley Gotway via RT <
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > > > Hi Bill,
> > > > > >
> > > > > > I moved your question over into the MET-Help support
ticketing
> > > system.
> > > > > >
> > > > > > I see that you're having trouble processing the NetCDF
output of
> > the
> > > > > > ncl_convert2nc utility in MET. MET is only set up to read
a
> > handful
> > > of
> > > > > > NetCDF file formats, and unfortunately, the output of
> > ncl_convert2nc
> > > is
> > > > > not
> > > > > > one of them. The 3 NetCDF flavors that MET reads are
> CF-complaint
> > > > > > (climate-forecast convention) files, the output of the
wrf_interp
> > > > > utility,
> > > > > > and the internal NetCDF format written by the MET tools
> themselves.
> > > > > >
> > > > > > I understand that you'd like to do additional processing
on the
> > > > > > precipitation rate data... and NetCDF is much easier to
work with
> > > than
> > > > > > GRIB2.
> > > > > >
> > > > > > Rather than using ncl_convert2nc to reformat the GRIB2
data,
> let's
> > > use
> > > > > the
> > > > > > MET regrid_data_plane tool instead. I'll demonstrate this
below.
> > > > > >
> > > > > > # I'll start with a sample GRIB2 GFS file that includes
PRATE:
> > > > > >
> > > > > > wgrib2 gfs_2012040900_F012.grib2 | grep PRATE
> > > > > > 199:37137213:d=2012040900:PRATE:surface:6-12 hour ave
fcst:
> > > > > >
> > > > > > # Call regrid_data_plane using the -field option to select
the
> > PRATE
> > > > > record
> > > > > >
> > > > > > /usr/local/met-6.0/bin/regrid_data_plane \
> > > > > > gfs_2012040900_F012.grib2 gfs_2012040900_F012.grib2
prate.nc \
> > > > > > -field 'name="PRATE"; level="A6";'
> > > > > >
> > > > > > DEBUG 1: Reading data file: gfs_2012040900_F012.grib2
> > > > > > DEBUG 2: Input grid: Projection: Lat/Lon Nx: 720 Ny: 361
lat_ll:
> > > > -90.000
> > > > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> > > > > > DEBUG 2: Output grid: Projection: Lat/Lon Nx: 720 Ny: 361
lat_ll:
> > > > -90.000
> > > > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> > > > > > DEBUG 2: Interpolation options: method = NEAREST, width =
1,
> shape
> > =
> > > > > > SQUARE, vld_thresh = 0.5
> > > > > > DEBUG 2: Range of input data (name="PRATE"; level="A6";)
is 0 to
> > > > > 0.004075.
> > > > > > DEBUG 2: Range of regridded data (name="PRATE";
level="A6";) is 0
> > to
> > > > > > 0.004075.
> > > > > > DEBUG 1: Writing output file: prate.nc
> > > > > >
> > > > > > Since the input and output grids are the same, no re-
gridding is
> > > > actually
> > > > > > being done. You could have also used the pcp_combine tool
to do
> > the
> > > > same
> > > > > > thing. But the nice thing about regrid_data_plane is that
you
> > could
> > > > > > include multiple fields in the output by using the "-
field"
> command
> > > > line
> > > > > > option multiple times.
> > > > > >
> > > > > > Then you can edit the NetCDF output of regrid_data_plane
however
> > > you'd
> > > > > > like, and MET should be able to read that file.
> > > > > >
> > > > > > Hope that helps.
> > > > > >
> > > > > > Thanks,
> > > > > > John
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Bill Stern, Meteorologist
> > > > > Room 206
> > > > > NOAA/Geophysical Fluid Dynamics Laboratory
> > > > > Princeton University Forrestal Campus
> > > > > 201 Forrestal Road Princeton, NJ 08540-6649
> > > > > Tel: (609)452-6545
> > > > > Fax: (609)987-5063
> > > > > ------------------------------
> > > > > ------------------------------------
> > > > > Email Address: bill.stern at noaa.gov
> > > > >
------------------------------------------------------------------
> > > > > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > > > >
------------------------------------------------------------------
> > > > > On the World Wide Web: http://www.gfdl.noaa.gov/bill-
> > stern-gfdl-noaa
> > > > >
------------------------------------------------------------------
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Bill Stern, Meteorologist
> > > Room 206
> > > NOAA/Geophysical Fluid Dynamics Laboratory
> > > Princeton University Forrestal Campus
> > > 201 Forrestal Road Princeton, NJ 08540-6649
> > > Tel: (609)452-6545
> > > Fax: (609)987-5063
> > > ------------------------------
> > > ------------------------------------
> > > Email Address: bill.stern at noaa.gov
> > >
------------------------------------------------------------------
> > > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > >
------------------------------------------------------------------
> > > On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-
gfdl-noaa
> > >
------------------------------------------------------------------
> > >
> > >
> >
> >
>
>
> --
> Bill Stern, Meteorologist
> Room 206
> NOAA/Geophysical Fluid Dynamics Laboratory
> Princeton University Forrestal Campus
> 201 Forrestal Road Princeton, NJ 08540-6649
> Tel: (609)452-6545
> Fax: (609)987-5063
> ------------------------------
> ------------------------------------
> Email Address: bill.stern at noaa.gov
> ------------------------------------------------------------------
> Anonymous ftp Address: ftp.gfdl.noaa.gov
> ------------------------------------------------------------------
> On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-gfdl-
noaa
> ------------------------------------------------------------------
>
>
------------------------------------------------
Subject: problem reading netdcf file
From: bill.stern at noaa.gov
Time: Thu Jul 20 06:32:26 2017
HI John,
Yes I agree with your observation. I have attached a plot of the same
record on that file using ferret, which agrees with the MET5.2 plot
you did
when I flip the vertical (see second attachment). I noticed that the
latitudes on the PRATEsfc6all.nc file start at the north pole and go
southward, could this be a problem?
Thanks,
Bill
On Thu, Jul 20, 2017 at 12:02 AM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> You know Bill,
> Looking more closely at these plots I sent, I suspect that there's
actually
> a problem in met-6.0.
>
> It looks like the data matches the map background of 5.2 well. In
6.0, we
> flipped the map right side but the data no longer matches the map
well.
>
> Do you agree?
>
> John
>
> On Wed, Jul 19, 2017 at 7:08 PM bill.stern at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
> >
> > Hi John,
> >
> > This is very helpful. It looks like we should be working with
met-6.0
> >
> > Thank you,
> > Bill
> >
> > On Wed, Jul 19, 2017 at 7:05 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Bill,
> > >
> > > Sorry for the delay in responding.
> > >
> > > I logged on to the ftp site and grabbed your sample file:
> PRATEsfc6all.nc
> > >
> > > I was able to replicate the error message you saw from met-5.2:
> > > ERROR : plot_data_plane -> file "PRATEsfc6all.nc" not a valid
data
> file
> > >
> > > If you instruct MET to interpret this file as a CF-compliant
NetCDF
> file,
> > > then it runs without error, but the data is packed upside down
(see
> > > attached prate_met-5.2.png):
> > >
> > > met-5.2/bin/plot_data_plane \
> > > PRATEsfc6all.nc prate_met-5.2.ps \
> > > 'name="PRATEsfc"; level="(4,*,*)"; file_type=NETCDF_NCCF;'
> > >
> > > In met-6.0, we fixed this issue and turned the world back right
side
> up.
> > > And in 6.0, you don't even need to tell it that it's CF
compliant:
> > >
> > > met-6.0/bin/plot_data_plane \
> > > PRATEsfc6all.nc prate_met-6.0.ps \
> > > 'name="PRATEsfc"; level="(4,*,*)";'
> > >
> > > So if possible, I'd suggest using met-6.0. Hope that helps.
> > >
> > > Thanks,
> > > John
> > >
> > > On Sat, Jul 15, 2017 at 11:03 AM, bill.stern at noaa.gov via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134
>
> > > >
> > > > John and others,
> > > >
> > > > I am now encountering a problem with MET's inability to read
GFS
> > forecast
> > > > files that were processed to netcdf. There are more than 75
forecast
> > > dates
> > > > each with 40 forecast time levels. It would be a very time
consuming
> > > task
> > > > to return to the original GRIB files and re-process each time
level
> > with
> > > > MET regrid_data_plane tool. So, I would like to find a way to
modify
> > the
> > > > existing netcdf files so they will be acceptable to MET.
> > > >
> > > > Here is the error I am encountering:
> > > > /home/Shannon.Rees/met-5.2_orig/met-5.2/src/tools/core/
> > > grid_stat/grid_stat
> > > > /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc
> > > > /vftmp/Bill.Stern/pid43698/GFS_native/ST4.2015012300.06h
> > > > /work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
> -outdir
> > > > /work/Bill.Stern/NGGPS/MET5.2/output/GFS_native/20150116.
> > > > 00Z/grid_stat//PRATEsfc/6hr/
> > > > -v 2
> > > > DEBUG 1: Default Config File:
> > > > /home/Shannon.Rees/met-5.2_orig/met-5.2/share/met/config/
> > > > GridStatConfig_default
> > > > DEBUG 1: User Config File:
> > > > /work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
> > > > ERROR :
> > > > ERROR : Trouble reading forecast file
> > > > "/vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
> > > >
> > > > I have attached the output from "ncdump -c
> > > > /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
> > > >
> > > > The full file can be obtained from ftp.gfdl.noaa.gov
> > > > cd /pub/wfs
> > > > get PRATEsfc6all.nc
> > > >
> > > > Thank you,
> > > > Bill
> > > >
> > > >
> > > > On Mon, Jul 10, 2017 at 2:27 PM, John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > > Bill,
> > > > >
> > > > > Ah, I understand. The regrid_data_plane tool is designed to
read
> > > exactly
> > > > > one 2D data field for each "-field" entry you specify on the
> command
> > > > line.
> > > > > When you ran it on a file containing 21 times, you probably
got a
> > > warning
> > > > > about "multiple matching fields". By default, it'll just
use the
> > first
> > > > > match found.
> > > > >
> > > > > You can include additional timing information in the "-
field" entry
> > to
> > > > > specify which of the 21 times you actually want. Here's an
excerpt
> > > from
> > > > > the met-6.0/data/config/README file about this:
> > > > >
> > > > > // - The "init_time" entry specifies the initialization
time in
> > > > > YYYYMMDD[_HH[MMSS]]
> > > > > // format. This entry can be included in the "fcst"
entry as
> > shown
> > > > > below or
> > > > > // included in the "field" entry if the user would like
to use
> > > > > different
> > > > > // initialization times for different fields.
> > > > > //
> > > > > // - The "valid_time" entry specifies the valid time in
> > > > > YYYYMMDD[_HH[MMSS]]
> > > > > // format. This entry can be included in the "fcst"
entry as
> > shown
> > > > > below or
> > > > > // included in the "field" entry if the user would like
to use
> > > > > different
> > > > > // valid times for different fields.
> > > > > //
> > > > > // - The "lead_time" entry specifies the lead time in
HH[MMSS]
> > > > > // format. This entry can be included in the "fcst"
entry as
> > shown
> > > > > below or
> > > > > // included in the "field" entry if the user would like
to use
> > > > > different
> > > > > // lead times for different fields.
> > > > >
> > > > > So you could try running adding the "valid_time":
> > > > >
> > > > > /usr/local/met-6.0/bin/regrid_data_plane \
> > > > > gfs_2012040900_F012.grib2 gfs_2012040900_F012.grib2 prate.nc
\
> > > > > -field 'name="PRATE"; level="A6";
valid_time="20120409_120000";'
> > > > >
> > > > > Technically, you could run regrid_data_plane once on each
input
> file,
> > > > pass
> > > > > in 21 "-field" settings, and write a single output file.
But
> you'll
> > > get
> > > > an
> > > > > error because it'll try to write the same NetCDF variable
name
> > multiple
> > > > > times. You could get around that by using the "-name"
option to
> > > passing
> > > > in
> > > > > 21 unique output variables names... but that's a whole lot
of
> > details.
> > > > >
> > > > > Instead, I'd suggest running regrid_data_plane once for each
> 3-hourly
> > > > > output time and specify the "valid_time" currently being
processed.
> > I
> > > > > think that logic would be cleaner.
> > > > >
> > > > > Hope that helps.
> > > > >
> > > > > Thanks,
> > > > > John
> > > > >
> > > > > On Mon, Jul 10, 2017 at 7:33 AM, bill.stern at noaa.gov via RT
<
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > > >
> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
> > > > > >
> > > > > > Hi John,
> > > > > >
> > > > > > I have followed your example of applying regrid_data_plane
for
> > > > creating a
> > > > > > netcdf file from a grib2. The command below does create a
> netcdf,
> > > but
> > > > I
> > > > > am
> > > > > > only seem to be getting a single time level on the netcdf
file,
> > while
> > > > the
> > > > > > grib2 file has 21 time levels. Here is my
regrid_data_plane
> > > command:
> > > > > >
> > > > > > regrid_data_plane
nam.2017051500.conusnest.hires.tm00.grib2
> > > > > > nam.2017051500.conusnest.hires.tm00.grib2 nam.2017051500
> > > > .conusnest.APCP.
> > > > > nc
> > > > > > -field 'name = "APCP";level="A3";'
> > > > > >
> > > > > > What am I missing?
> > > > > >
> > > > > > Thanks,
> > > > > > Bill
> > > > > >
> > > > > > On Fri, Jul 7, 2017 at 12:44 PM, John Halley Gotway via RT
<
> > > > > > met_help at ucar.edu> wrote:
> > > > > >
> > > > > > > Hi Bill,
> > > > > > >
> > > > > > > I moved your question over into the MET-Help support
ticketing
> > > > system.
> > > > > > >
> > > > > > > I see that you're having trouble processing the NetCDF
output
> of
> > > the
> > > > > > > ncl_convert2nc utility in MET. MET is only set up to
read a
> > > handful
> > > > of
> > > > > > > NetCDF file formats, and unfortunately, the output of
> > > ncl_convert2nc
> > > > is
> > > > > > not
> > > > > > > one of them. The 3 NetCDF flavors that MET reads are
> > CF-complaint
> > > > > > > (climate-forecast convention) files, the output of the
> wrf_interp
> > > > > > utility,
> > > > > > > and the internal NetCDF format written by the MET tools
> > themselves.
> > > > > > >
> > > > > > > I understand that you'd like to do additional processing
on the
> > > > > > > precipitation rate data... and NetCDF is much easier to
work
> with
> > > > than
> > > > > > > GRIB2.
> > > > > > >
> > > > > > > Rather than using ncl_convert2nc to reformat the GRIB2
data,
> > let's
> > > > use
> > > > > > the
> > > > > > > MET regrid_data_plane tool instead. I'll demonstrate
this
> below.
> > > > > > >
> > > > > > > # I'll start with a sample GRIB2 GFS file that includes
PRATE:
> > > > > > >
> > > > > > > wgrib2 gfs_2012040900_F012.grib2 | grep PRATE
> > > > > > > 199:37137213:d=2012040900:PRATE:surface:6-12 hour ave
fcst:
> > > > > > >
> > > > > > > # Call regrid_data_plane using the -field option to
select the
> > > PRATE
> > > > > > record
> > > > > > >
> > > > > > > /usr/local/met-6.0/bin/regrid_data_plane \
> > > > > > > gfs_2012040900_F012.grib2 gfs_2012040900_F012.grib2
prate.nc \
> > > > > > > -field 'name="PRATE"; level="A6";'
> > > > > > >
> > > > > > > DEBUG 1: Reading data file: gfs_2012040900_F012.grib2
> > > > > > > DEBUG 2: Input grid: Projection: Lat/Lon Nx: 720 Ny: 361
> lat_ll:
> > > > > -90.000
> > > > > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> > > > > > > DEBUG 2: Output grid: Projection: Lat/Lon Nx: 720 Ny:
361
> lat_ll:
> > > > > -90.000
> > > > > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> > > > > > > DEBUG 2: Interpolation options: method = NEAREST, width
= 1,
> > shape
> > > =
> > > > > > > SQUARE, vld_thresh = 0.5
> > > > > > > DEBUG 2: Range of input data (name="PRATE"; level="A6";)
is 0
> to
> > > > > > 0.004075.
> > > > > > > DEBUG 2: Range of regridded data (name="PRATE";
level="A6";)
> is 0
> > > to
> > > > > > > 0.004075.
> > > > > > > DEBUG 1: Writing output file: prate.nc
> > > > > > >
> > > > > > > Since the input and output grids are the same, no re-
gridding
> is
> > > > > actually
> > > > > > > being done. You could have also used the pcp_combine
tool to
> do
> > > the
> > > > > same
> > > > > > > thing. But the nice thing about regrid_data_plane is
that you
> > > could
> > > > > > > include multiple fields in the output by using the "-
field"
> > command
> > > > > line
> > > > > > > option multiple times.
> > > > > > >
> > > > > > > Then you can edit the NetCDF output of regrid_data_plane
> however
> > > > you'd
> > > > > > > like, and MET should be able to read that file.
> > > > > > >
> > > > > > > Hope that helps.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > John
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Bill Stern, Meteorologist
> > > > > > Room 206
> > > > > > NOAA/Geophysical Fluid Dynamics Laboratory
> > > > > > Princeton University Forrestal Campus
> > > > > > 201 Forrestal Road Princeton, NJ 08540-6649
> > > > > > Tel: (609)452-6545
> > > > > > Fax: (609)987-5063
> > > > > > ------------------------------
> > > > > > ------------------------------------
> > > > > > Email Address: bill.stern at noaa.gov
> > > > > >
------------------------------------------------------------
> ------
> > > > > > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > > > > >
------------------------------------------------------------
> ------
> > > > > > On the World Wide Web: http://www.gfdl.noaa.gov/bill-
> > > stern-gfdl-noaa
> > > > > >
------------------------------------------------------------
> ------
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Bill Stern, Meteorologist
> > > > Room 206
> > > > NOAA/Geophysical Fluid Dynamics Laboratory
> > > > Princeton University Forrestal Campus
> > > > 201 Forrestal Road Princeton, NJ 08540-6649
> > > > Tel: (609)452-6545
> > > > Fax: (609)987-5063
> > > > ------------------------------
> > > > ------------------------------------
> > > > Email Address: bill.stern at noaa.gov
> > > >
------------------------------------------------------------------
> > > > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > > >
------------------------------------------------------------------
> > > > On the World Wide Web: http://www.gfdl.noaa.gov/bill-
> stern-gfdl-noaa
> > > >
------------------------------------------------------------------
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Bill Stern, Meteorologist
> > Room 206
> > NOAA/Geophysical Fluid Dynamics Laboratory
> > Princeton University Forrestal Campus
> > 201 Forrestal Road Princeton, NJ 08540-6649
> > Tel: (609)452-6545
> > Fax: (609)987-5063
> > ------------------------------
> > ------------------------------------
> > Email Address: bill.stern at noaa.gov
> > ------------------------------------------------------------------
> > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > ------------------------------------------------------------------
> > On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-gfdl-
noaa
> > ------------------------------------------------------------------
> >
> >
>
>
--
Bill Stern, Meteorologist
Room 206
NOAA/Geophysical Fluid Dynamics Laboratory
Princeton University Forrestal Campus
201 Forrestal Road Princeton, NJ 08540-6649
Tel: (609)452-6545
Fax: (609)987-5063
------------------------------
------------------------------------
Email Address: bill.stern at noaa.gov
------------------------------------------------------------------
Anonymous ftp Address: ftp.gfdl.noaa.gov
------------------------------------------------------------------
On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-gfdl-noaa
------------------------------------------------------------------
------------------------------------------------
Subject: problem reading netdcf file
From: bill.stern at noaa.gov
Time: Thu Jul 20 07:38:10 2017
Hi John,
Just another related question. I am somewhat confused regarding how
MET is
interpreting the file as being "CF compliant". I thought by setting
the
"conventions" attribute to: "CF-1.0", MET will interpret the netcdf
file as
being CF compliant, but you seemed to have to tell the MET
"plot_data_plane" tool to consider the file CF compliant by specifying
via
the option "file_type=NETCDF_NCCF"? Can you enlighten me?
Thanks,
Bill
On Wed, Jul 19, 2017 at 7:05 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Bill,
>
> Sorry for the delay in responding.
>
> I logged on to the ftp site and grabbed your sample file:
PRATEsfc6all.nc
>
> I was able to replicate the error message you saw from met-5.2:
> ERROR : plot_data_plane -> file "PRATEsfc6all.nc" not a valid data
file
>
> If you instruct MET to interpret this file as a CF-compliant NetCDF
file,
> then it runs without error, but the data is packed upside down (see
> attached prate_met-5.2.png):
>
> met-5.2/bin/plot_data_plane \
> PRATEsfc6all.nc prate_met-5.2.ps \
> 'name="PRATEsfc"; level="(4,*,*)"; file_type=NETCDF_NCCF;'
>
> In met-6.0, we fixed this issue and turned the world back right side
up.
> And in 6.0, you don't even need to tell it that it's CF compliant:
>
> met-6.0/bin/plot_data_plane \
> PRATEsfc6all.nc prate_met-6.0.ps \
> 'name="PRATEsfc"; level="(4,*,*)";'
>
> So if possible, I'd suggest using met-6.0. Hope that helps.
>
> Thanks,
> John
>
> On Sat, Jul 15, 2017 at 11:03 AM, bill.stern at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
> >
> > John and others,
> >
> > I am now encountering a problem with MET's inability to read GFS
forecast
> > files that were processed to netcdf. There are more than 75
forecast
> dates
> > each with 40 forecast time levels. It would be a very time
consuming
> task
> > to return to the original GRIB files and re-process each time
level with
> > MET regrid_data_plane tool. So, I would like to find a way to
modify the
> > existing netcdf files so they will be acceptable to MET.
> >
> > Here is the error I am encountering:
> > /home/Shannon.Rees/met-5.2_orig/met-5.2/src/tools/core/
> grid_stat/grid_stat
> > /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc
> > /vftmp/Bill.Stern/pid43698/GFS_native/ST4.2015012300.06h
> > /work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
-outdir
> > /work/Bill.Stern/NGGPS/MET5.2/output/GFS_native/20150116.
> > 00Z/grid_stat//PRATEsfc/6hr/
> > -v 2
> > DEBUG 1: Default Config File:
> > /home/Shannon.Rees/met-5.2_orig/met-5.2/share/met/config/
> > GridStatConfig_default
> > DEBUG 1: User Config File:
> > /work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
> > ERROR :
> > ERROR : Trouble reading forecast file
> > "/vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
> >
> > I have attached the output from "ncdump -c
> > /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
> >
> > The full file can be obtained from ftp.gfdl.noaa.gov
> > cd /pub/wfs
> > get PRATEsfc6all.nc
> >
> > Thank you,
> > Bill
> >
> >
> > On Mon, Jul 10, 2017 at 2:27 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Bill,
> > >
> > > Ah, I understand. The regrid_data_plane tool is designed to
read
> exactly
> > > one 2D data field for each "-field" entry you specify on the
command
> > line.
> > > When you ran it on a file containing 21 times, you probably got
a
> warning
> > > about "multiple matching fields". By default, it'll just use
the first
> > > match found.
> > >
> > > You can include additional timing information in the "-field"
entry to
> > > specify which of the 21 times you actually want. Here's an
excerpt
> from
> > > the met-6.0/data/config/README file about this:
> > >
> > > // - The "init_time" entry specifies the initialization time
in
> > > YYYYMMDD[_HH[MMSS]]
> > > // format. This entry can be included in the "fcst" entry
as shown
> > > below or
> > > // included in the "field" entry if the user would like to
use
> > > different
> > > // initialization times for different fields.
> > > //
> > > // - The "valid_time" entry specifies the valid time in
> > > YYYYMMDD[_HH[MMSS]]
> > > // format. This entry can be included in the "fcst" entry
as shown
> > > below or
> > > // included in the "field" entry if the user would like to
use
> > > different
> > > // valid times for different fields.
> > > //
> > > // - The "lead_time" entry specifies the lead time in HH[MMSS]
> > > // format. This entry can be included in the "fcst" entry
as shown
> > > below or
> > > // included in the "field" entry if the user would like to
use
> > > different
> > > // lead times for different fields.
> > >
> > > So you could try running adding the "valid_time":
> > >
> > > /usr/local/met-6.0/bin/regrid_data_plane \
> > > gfs_2012040900_F012.grib2 gfs_2012040900_F012.grib2 prate.nc \
> > > -field 'name="PRATE"; level="A6"; valid_time="20120409_120000";'
> > >
> > > Technically, you could run regrid_data_plane once on each input
file,
> > pass
> > > in 21 "-field" settings, and write a single output file. But
you'll
> get
> > an
> > > error because it'll try to write the same NetCDF variable name
multiple
> > > times. You could get around that by using the "-name" option to
> passing
> > in
> > > 21 unique output variables names... but that's a whole lot of
details.
> > >
> > > Instead, I'd suggest running regrid_data_plane once for each 3-
hourly
> > > output time and specify the "valid_time" currently being
processed. I
> > > think that logic would be cleaner.
> > >
> > > Hope that helps.
> > >
> > > Thanks,
> > > John
> > >
> > > On Mon, Jul 10, 2017 at 7:33 AM, bill.stern at noaa.gov via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134
>
> > > >
> > > > Hi John,
> > > >
> > > > I have followed your example of applying regrid_data_plane for
> > creating a
> > > > netcdf file from a grib2. The command below does create a
netcdf,
> but
> > I
> > > am
> > > > only seem to be getting a single time level on the netcdf
file, while
> > the
> > > > grib2 file has 21 time levels. Here is my regrid_data_plane
> command:
> > > >
> > > > regrid_data_plane nam.2017051500.conusnest.hires.tm00.grib2
> > > > nam.2017051500.conusnest.hires.tm00.grib2 nam.2017051500
> > .conusnest.APCP.
> > > nc
> > > > -field 'name = "APCP";level="A3";'
> > > >
> > > > What am I missing?
> > > >
> > > > Thanks,
> > > > Bill
> > > >
> > > > On Fri, Jul 7, 2017 at 12:44 PM, John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > > Hi Bill,
> > > > >
> > > > > I moved your question over into the MET-Help support
ticketing
> > system.
> > > > >
> > > > > I see that you're having trouble processing the NetCDF
output of
> the
> > > > > ncl_convert2nc utility in MET. MET is only set up to read a
> handful
> > of
> > > > > NetCDF file formats, and unfortunately, the output of
> ncl_convert2nc
> > is
> > > > not
> > > > > one of them. The 3 NetCDF flavors that MET reads are CF-
complaint
> > > > > (climate-forecast convention) files, the output of the
wrf_interp
> > > > utility,
> > > > > and the internal NetCDF format written by the MET tools
themselves.
> > > > >
> > > > > I understand that you'd like to do additional processing on
the
> > > > > precipitation rate data... and NetCDF is much easier to work
with
> > than
> > > > > GRIB2.
> > > > >
> > > > > Rather than using ncl_convert2nc to reformat the GRIB2 data,
let's
> > use
> > > > the
> > > > > MET regrid_data_plane tool instead. I'll demonstrate this
below.
> > > > >
> > > > > # I'll start with a sample GRIB2 GFS file that includes
PRATE:
> > > > >
> > > > > wgrib2 gfs_2012040900_F012.grib2 | grep PRATE
> > > > > 199:37137213:d=2012040900:PRATE:surface:6-12 hour ave fcst:
> > > > >
> > > > > # Call regrid_data_plane using the -field option to select
the
> PRATE
> > > > record
> > > > >
> > > > > /usr/local/met-6.0/bin/regrid_data_plane \
> > > > > gfs_2012040900_F012.grib2 gfs_2012040900_F012.grib2 prate.nc
\
> > > > > -field 'name="PRATE"; level="A6";'
> > > > >
> > > > > DEBUG 1: Reading data file: gfs_2012040900_F012.grib2
> > > > > DEBUG 2: Input grid: Projection: Lat/Lon Nx: 720 Ny: 361
lat_ll:
> > > -90.000
> > > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> > > > > DEBUG 2: Output grid: Projection: Lat/Lon Nx: 720 Ny: 361
lat_ll:
> > > -90.000
> > > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> > > > > DEBUG 2: Interpolation options: method = NEAREST, width = 1,
shape
> =
> > > > > SQUARE, vld_thresh = 0.5
> > > > > DEBUG 2: Range of input data (name="PRATE"; level="A6";) is
0 to
> > > > 0.004075.
> > > > > DEBUG 2: Range of regridded data (name="PRATE"; level="A6";)
is 0
> to
> > > > > 0.004075.
> > > > > DEBUG 1: Writing output file: prate.nc
> > > > >
> > > > > Since the input and output grids are the same, no re-
gridding is
> > > actually
> > > > > being done. You could have also used the pcp_combine tool
to do
> the
> > > same
> > > > > thing. But the nice thing about regrid_data_plane is that
you
> could
> > > > > include multiple fields in the output by using the "-field"
command
> > > line
> > > > > option multiple times.
> > > > >
> > > > > Then you can edit the NetCDF output of regrid_data_plane
however
> > you'd
> > > > > like, and MET should be able to read that file.
> > > > >
> > > > > Hope that helps.
> > > > >
> > > > > Thanks,
> > > > > John
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Bill Stern, Meteorologist
> > > > Room 206
> > > > NOAA/Geophysical Fluid Dynamics Laboratory
> > > > Princeton University Forrestal Campus
> > > > 201 Forrestal Road Princeton, NJ 08540-6649
> > > > Tel: (609)452-6545
> > > > Fax: (609)987-5063
> > > > ------------------------------
> > > > ------------------------------------
> > > > Email Address: bill.stern at noaa.gov
> > > >
------------------------------------------------------------------
> > > > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > > >
------------------------------------------------------------------
> > > > On the World Wide Web: http://www.gfdl.noaa.gov/bill-
> stern-gfdl-noaa
> > > >
------------------------------------------------------------------
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Bill Stern, Meteorologist
> > Room 206
> > NOAA/Geophysical Fluid Dynamics Laboratory
> > Princeton University Forrestal Campus
> > 201 Forrestal Road Princeton, NJ 08540-6649
> > Tel: (609)452-6545
> > Fax: (609)987-5063
> > ------------------------------
> > ------------------------------------
> > Email Address: bill.stern at noaa.gov
> > ------------------------------------------------------------------
> > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > ------------------------------------------------------------------
> > On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-gfdl-
noaa
> > ------------------------------------------------------------------
> >
> >
>
>
--
Bill Stern, Meteorologist
Room 206
NOAA/Geophysical Fluid Dynamics Laboratory
Princeton University Forrestal Campus
201 Forrestal Road Princeton, NJ 08540-6649
Tel: (609)452-6545
Fax: (609)987-5063
------------------------------
------------------------------------
Email Address: bill.stern at noaa.gov
------------------------------------------------------------------
Anonymous ftp Address: ftp.gfdl.noaa.gov
------------------------------------------------------------------
On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-gfdl-noaa
------------------------------------------------------------------
------------------------------------------------
Subject: problem reading netdcf file
From: John Halley Gotway
Time: Thu Jul 20 10:15:55 2017
Bill,
Yes, you're right. Setting "conventions = "CF-1.0" *should* tell MET
that
the NetCDF file is CF-compliant. Unfortunately, there are some
wrinkles in
the logic in 5.2 that we've ironed out in 6.0 :) And that's why
setting
"file_type = NETCDF_NCCF;" is still needed in 5.2.
However, the incorrect orientation of your data in 6.0 really is a
bug.
And I've asked the developer who worked on that logic to find and fix
the
problem. Once we have a fix, we'll post it to the website and let you
know.
Additionally, version 6.0 contains some major run time improvements,
mostly
for Grid-Stat. The speed of reading/writing NetCDF is improved, but
more
importantly the allocation of memory is dramatically improved. For
small
numbers of matched pairs, it's not really noticeable. But for large
numbers, the improvements are significant. I ran Grid-Stat on your
data
(4,718,592 matched pairs) using both 5.2 and 6.0 and just computing
scalar
partial sums. On my machine 5.2 took 18.5 seconds while 6.0 took only
5.5
seconds.
So yes, I would recommend using met-6.0.
Thanks,
John
On Thu, Jul 20, 2017 at 7:38 AM, Bill Stern - NOAA Affiliate <
bill.stern at noaa.gov> wrote:
> Hi John,
>
> Just another related question. I am somewhat confused regarding how
MET
> is interpreting the file as being "CF compliant". I thought by
setting the
> "conventions" attribute to: "CF-1.0", MET will interpret the netcdf
file as
> being CF compliant, but you seemed to have to tell the MET
> "plot_data_plane" tool to consider the file CF compliant by
specifying via
> the option "file_type=NETCDF_NCCF"? Can you enlighten me?
>
> Thanks,
> Bill
>
> On Wed, Jul 19, 2017 at 7:05 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Bill,
>>
>> Sorry for the delay in responding.
>>
>> I logged on to the ftp site and grabbed your sample file:
PRATEsfc6all.nc
>>
>> I was able to replicate the error message you saw from met-5.2:
>> ERROR : plot_data_plane -> file "PRATEsfc6all.nc" not a valid data
file
>>
>> If you instruct MET to interpret this file as a CF-compliant NetCDF
file,
>> then it runs without error, but the data is packed upside down (see
>> attached prate_met-5.2.png):
>>
>> met-5.2/bin/plot_data_plane \
>> PRATEsfc6all.nc prate_met-5.2.ps \
>> 'name="PRATEsfc"; level="(4,*,*)"; file_type=NETCDF_NCCF;'
>>
>> In met-6.0, we fixed this issue and turned the world back right
side up.
>> And in 6.0, you don't even need to tell it that it's CF compliant:
>>
>> met-6.0/bin/plot_data_plane \
>> PRATEsfc6all.nc prate_met-6.0.ps \
>> 'name="PRATEsfc"; level="(4,*,*)";'
>>
>> So if possible, I'd suggest using met-6.0. Hope that helps.
>>
>> Thanks,
>> John
>>
>> On Sat, Jul 15, 2017 at 11:03 AM, bill.stern at noaa.gov via RT <
>> met_help at ucar.edu> wrote:
>>
>> >
>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
>> >
>> > John and others,
>> >
>> > I am now encountering a problem with MET's inability to read GFS
>> forecast
>> > files that were processed to netcdf. There are more than 75
forecast
>> dates
>> > each with 40 forecast time levels. It would be a very time
consuming
>> task
>> > to return to the original GRIB files and re-process each time
level with
>> > MET regrid_data_plane tool. So, I would like to find a way to
modify the
>> > existing netcdf files so they will be acceptable to MET.
>> >
>> > Here is the error I am encountering:
>> > /home/Shannon.Rees/met-5.2_orig/met-5.2/src/tools/core/grid_
>> stat/grid_stat
>> > /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc
>> > /vftmp/Bill.Stern/pid43698/GFS_native/ST4.2015012300
<(201)%20501-2300>
>> .06h
>> > /work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
-outdir
>> > /work/Bill.Stern/NGGPS/MET5.2/output/GFS_native/20150116.
>> > 00Z/grid_stat//PRATEsfc/6hr/
>> > -v 2
>> > DEBUG 1: Default Config File:
>> > /home/Shannon.Rees/met-5.2_orig/met-5.2/share/met/config/
>> > GridStatConfig_default
>> > DEBUG 1: User Config File:
>> > /work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
>> > ERROR :
>> > ERROR : Trouble reading forecast file
>> > "/vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
>> >
>> > I have attached the output from "ncdump -c
>> > /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
>> >
>> > The full file can be obtained from ftp.gfdl.noaa.gov
>> > cd /pub/wfs
>> > get PRATEsfc6all.nc
>> >
>> > Thank you,
>> > Bill
>> >
>> >
>> > On Mon, Jul 10, 2017 at 2:27 PM, John Halley Gotway via RT <
>> > met_help at ucar.edu> wrote:
>> >
>> > > Bill,
>> > >
>> > > Ah, I understand. The regrid_data_plane tool is designed to
read
>> exactly
>> > > one 2D data field for each "-field" entry you specify on the
command
>> > line.
>> > > When you ran it on a file containing 21 times, you probably got
a
>> warning
>> > > about "multiple matching fields". By default, it'll just use
the
>> first
>> > > match found.
>> > >
>> > > You can include additional timing information in the "-field"
entry to
>> > > specify which of the 21 times you actually want. Here's an
excerpt
>> from
>> > > the met-6.0/data/config/README file about this:
>> > >
>> > > // - The "init_time" entry specifies the initialization time
in
>> > > YYYYMMDD[_HH[MMSS]]
>> > > // format. This entry can be included in the "fcst" entry
as
>> shown
>> > > below or
>> > > // included in the "field" entry if the user would like to
use
>> > > different
>> > > // initialization times for different fields.
>> > > //
>> > > // - The "valid_time" entry specifies the valid time in
>> > > YYYYMMDD[_HH[MMSS]]
>> > > // format. This entry can be included in the "fcst" entry
as
>> shown
>> > > below or
>> > > // included in the "field" entry if the user would like to
use
>> > > different
>> > > // valid times for different fields.
>> > > //
>> > > // - The "lead_time" entry specifies the lead time in
HH[MMSS]
>> > > // format. This entry can be included in the "fcst" entry
as
>> shown
>> > > below or
>> > > // included in the "field" entry if the user would like to
use
>> > > different
>> > > // lead times for different fields.
>> > >
>> > > So you could try running adding the "valid_time":
>> > >
>> > > /usr/local/met-6.0/bin/regrid_data_plane \
>> > > gfs_2012040900_F012.grib2 gfs_2012040900 <(201)%20204-
0900>_F012.grib2
>> prate.nc \
>> > > -field 'name="PRATE"; level="A6";
valid_time="20120409_120000";'
>> > >
>> > > Technically, you could run regrid_data_plane once on each input
file,
>> > pass
>> > > in 21 "-field" settings, and write a single output file. But
you'll
>> get
>> > an
>> > > error because it'll try to write the same NetCDF variable name
>> multiple
>> > > times. You could get around that by using the "-name" option
to
>> passing
>> > in
>> > > 21 unique output variables names... but that's a whole lot of
details.
>> > >
>> > > Instead, I'd suggest running regrid_data_plane once for each 3-
hourly
>> > > output time and specify the "valid_time" currently being
processed. I
>> > > think that logic would be cleaner.
>> > >
>> > > Hope that helps.
>> > >
>> > > Thanks,
>> > > John
>> > >
>> > > On Mon, Jul 10, 2017 at 7:33 AM, bill.stern at noaa.gov via RT <
>> > > met_help at ucar.edu> wrote:
>> > >
>> > > >
>> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134
>
>> > > >
>> > > > Hi John,
>> > > >
>> > > > I have followed your example of applying regrid_data_plane
for
>> > creating a
>> > > > netcdf file from a grib2. The command below does create a
netcdf,
>> but
>> > I
>> > > am
>> > > > only seem to be getting a single time level on the netcdf
file,
>> while
>> > the
>> > > > grib2 file has 21 time levels. Here is my regrid_data_plane
>> command:
>> > > >
>> > > > regrid_data_plane nam.2017051500.conusnest.hires.tm00.grib2
>> > > > nam.2017051500.conusnest.hires.tm00.grib2 nam.2017051500
>> > .conusnest.APCP.
>> > > nc
>> > > > -field 'name = "APCP";level="A3";'
>> > > >
>> > > > What am I missing?
>> > > >
>> > > > Thanks,
>> > > > Bill
>> > > >
>> > > > On Fri, Jul 7, 2017 at 12:44 PM, John Halley Gotway via RT <
>> > > > met_help at ucar.edu> wrote:
>> > > >
>> > > > > Hi Bill,
>> > > > >
>> > > > > I moved your question over into the MET-Help support
ticketing
>> > system.
>> > > > >
>> > > > > I see that you're having trouble processing the NetCDF
output of
>> the
>> > > > > ncl_convert2nc utility in MET. MET is only set up to read
a
>> handful
>> > of
>> > > > > NetCDF file formats, and unfortunately, the output of
>> ncl_convert2nc
>> > is
>> > > > not
>> > > > > one of them. The 3 NetCDF flavors that MET reads are CF-
complaint
>> > > > > (climate-forecast convention) files, the output of the
wrf_interp
>> > > > utility,
>> > > > > and the internal NetCDF format written by the MET tools
>> themselves.
>> > > > >
>> > > > > I understand that you'd like to do additional processing on
the
>> > > > > precipitation rate data... and NetCDF is much easier to
work with
>> > than
>> > > > > GRIB2.
>> > > > >
>> > > > > Rather than using ncl_convert2nc to reformat the GRIB2
data, let's
>> > use
>> > > > the
>> > > > > MET regrid_data_plane tool instead. I'll demonstrate this
below.
>> > > > >
>> > > > > # I'll start with a sample GRIB2 GFS file that includes
PRATE:
>> > > > >
>> > > > > wgrib2 gfs_2012040900_F012.grib2 | grep PRATE
>> > > > > 199:37137213:d=2012040900 <(201)%20204-
0900>:PRATE:surface:6-12
>> hour ave fcst:
>> > > > >
>> > > > > # Call regrid_data_plane using the -field option to select
the
>> PRATE
>> > > > record
>> > > > >
>> > > > > /usr/local/met-6.0/bin/regrid_data_plane \
>> > > > > gfs_2012040900 <(201)%20204-0900>_F012.grib2 gfs_2012040900
>> <(201)%20204-0900>_F012.grib2 prate.nc \
>> > > > > -field 'name="PRATE"; level="A6";'
>> > > > >
>> > > > > DEBUG 1: Reading data file: gfs_2012040900_F012.grib2
>> > > > > DEBUG 2: Input grid: Projection: Lat/Lon Nx: 720 Ny: 361
lat_ll:
>> > > -90.000
>> > > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
>> > > > > DEBUG 2: Output grid: Projection: Lat/Lon Nx: 720 Ny: 361
lat_ll:
>> > > -90.000
>> > > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
>> > > > > DEBUG 2: Interpolation options: method = NEAREST, width =
1,
>> shape =
>> > > > > SQUARE, vld_thresh = 0.5
>> > > > > DEBUG 2: Range of input data (name="PRATE"; level="A6";) is
0 to
>> > > > 0.004075.
>> > > > > DEBUG 2: Range of regridded data (name="PRATE";
level="A6";) is 0
>> to
>> > > > > 0.004075.
>> > > > > DEBUG 1: Writing output file: prate.nc
>> > > > >
>> > > > > Since the input and output grids are the same, no re-
gridding is
>> > > actually
>> > > > > being done. You could have also used the pcp_combine tool
to do
>> the
>> > > same
>> > > > > thing. But the nice thing about regrid_data_plane is that
you
>> could
>> > > > > include multiple fields in the output by using the "-field"
>> command
>> > > line
>> > > > > option multiple times.
>> > > > >
>> > > > > Then you can edit the NetCDF output of regrid_data_plane
however
>> > you'd
>> > > > > like, and MET should be able to read that file.
>> > > > >
>> > > > > Hope that helps.
>> > > > >
>> > > > > Thanks,
>> > > > > John
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Bill Stern, Meteorologist
>> > > > Room 206
>> > > > NOAA/Geophysical Fluid Dynamics Laboratory
>> > > > Princeton University Forrestal Campus
>> > > > 201 Forrestal Road Princeton, NJ 08540-6649
>> > > > Tel: (609)452-6545
>> > > > Fax: (609)987-5063
>> > > > ------------------------------
>> > > > ------------------------------------
>> > > > Email Address: bill.stern at noaa.gov
>> > > >
------------------------------------------------------------------
>> > > > Anonymous ftp Address: ftp.gfdl.noaa.gov
>> > > >
------------------------------------------------------------------
>> > > > On the World Wide Web: http://www.gfdl.noaa.gov/bill-
>> stern-gfdl-noaa
>> > > >
------------------------------------------------------------------
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> > --
>> > Bill Stern, Meteorologist
>> > Room 206
>> > NOAA/Geophysical Fluid Dynamics Laboratory
>> > Princeton University Forrestal Campus
>> > 201 Forrestal Road Princeton, NJ 08540-6649
>> > Tel: (609)452-6545
>> > Fax: (609)987-5063
>> > ------------------------------
>> > ------------------------------------
>> > Email Address: bill.stern at noaa.gov
>> >
------------------------------------------------------------------
>> > Anonymous ftp Address: ftp.gfdl.noaa.gov
>> >
------------------------------------------------------------------
>> > On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-gfdl-
noaa
>> >
------------------------------------------------------------------
>> >
>> >
>>
>>
>
>
> --
> Bill Stern, Meteorologist
> Room 206
> NOAA/Geophysical Fluid Dynamics Laboratory
> Princeton University Forrestal Campus
> 201 Forrestal Road Princeton, NJ 08540-6649
> Tel: (609)452-6545
> Fax: (609)987-5063
> ------------------------------
> ------------------------------------
> Email Address: bill.stern at noaa.gov
> ------------------------------------------------------------------
> Anonymous ftp Address: ftp.gfdl.noaa.gov
> ------------------------------------------------------------------
> On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-gfdl-
noaa
> ------------------------------------------------------------------
>
------------------------------------------------
Subject: problem reading netdcf file
From: Shannon Rees - NOAA Affiliate
Time: Thu Jul 20 10:22:10 2017
Hi John,
I remember you made some grid-stat memory allocation improvements in
January of this year and released a 5.2 patch for us. Does 6.0 have
further
improvements or is that what you were referring to? We are using the
5.2
patch to make it faster and while I do want to update to 6.0 anyways,
I am
just curious if 6.0 will be any faster.
Thanks,
Shannon
On Thu, Jul 20, 2017 at 12:15 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Bill,
>
> Yes, you're right. Setting "conventions = "CF-1.0" *should* tell
MET that
> the NetCDF file is CF-compliant. Unfortunately, there are some
wrinkles in
> the logic in 5.2 that we've ironed out in 6.0 :) And that's why
setting
> "file_type = NETCDF_NCCF;" is still needed in 5.2.
>
> However, the incorrect orientation of your data in 6.0 really is a
bug.
> And I've asked the developer who worked on that logic to find and
fix the
> problem. Once we have a fix, we'll post it to the website and let
you
> know.
>
> Additionally, version 6.0 contains some major run time improvements,
mostly
> for Grid-Stat. The speed of reading/writing NetCDF is improved, but
more
> importantly the allocation of memory is dramatically improved. For
small
> numbers of matched pairs, it's not really noticeable. But for large
> numbers, the improvements are significant. I ran Grid-Stat on your
data
> (4,718,592 matched pairs) using both 5.2 and 6.0 and just computing
scalar
> partial sums. On my machine 5.2 took 18.5 seconds while 6.0 took
only 5.5
> seconds.
>
> So yes, I would recommend using met-6.0.
>
> Thanks,
> John
>
> On Thu, Jul 20, 2017 at 7:38 AM, Bill Stern - NOAA Affiliate <
> bill.stern at noaa.gov> wrote:
>
> > Hi John,
> >
> > Just another related question. I am somewhat confused regarding
how MET
> > is interpreting the file as being "CF compliant". I thought by
setting
> the
> > "conventions" attribute to: "CF-1.0", MET will interpret the
netcdf file
> as
> > being CF compliant, but you seemed to have to tell the MET
> > "plot_data_plane" tool to consider the file CF compliant by
specifying
> via
> > the option "file_type=NETCDF_NCCF"? Can you enlighten me?
> >
> > Thanks,
> > Bill
> >
> > On Wed, Jul 19, 2017 at 7:05 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> >> Bill,
> >>
> >> Sorry for the delay in responding.
> >>
> >> I logged on to the ftp site and grabbed your sample file:
> PRATEsfc6all.nc
> >>
> >> I was able to replicate the error message you saw from met-5.2:
> >> ERROR : plot_data_plane -> file "PRATEsfc6all.nc" not a valid
data file
> >>
> >> If you instruct MET to interpret this file as a CF-compliant
NetCDF
> file,
> >> then it runs without error, but the data is packed upside down
(see
> >> attached prate_met-5.2.png):
> >>
> >> met-5.2/bin/plot_data_plane \
> >> PRATEsfc6all.nc prate_met-5.2.ps \
> >> 'name="PRATEsfc"; level="(4,*,*)"; file_type=NETCDF_NCCF;'
> >>
> >> In met-6.0, we fixed this issue and turned the world back right
side up.
> >> And in 6.0, you don't even need to tell it that it's CF
compliant:
> >>
> >> met-6.0/bin/plot_data_plane \
> >> PRATEsfc6all.nc prate_met-6.0.ps \
> >> 'name="PRATEsfc"; level="(4,*,*)";'
> >>
> >> So if possible, I'd suggest using met-6.0. Hope that helps.
> >>
> >> Thanks,
> >> John
> >>
> >> On Sat, Jul 15, 2017 at 11:03 AM, bill.stern at noaa.gov via RT <
> >> met_help at ucar.edu> wrote:
> >>
> >> >
> >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
> >> >
> >> > John and others,
> >> >
> >> > I am now encountering a problem with MET's inability to read
GFS
> >> forecast
> >> > files that were processed to netcdf. There are more than 75
forecast
> >> dates
> >> > each with 40 forecast time levels. It would be a very time
consuming
> >> task
> >> > to return to the original GRIB files and re-process each time
level
> with
> >> > MET regrid_data_plane tool. So, I would like to find a way to
modify
> the
> >> > existing netcdf files so they will be acceptable to MET.
> >> >
> >> > Here is the error I am encountering:
> >> > /home/Shannon.Rees/met-5.2_orig/met-5.2/src/tools/core/grid_
> >> stat/grid_stat
> >> > /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc
> >> > /vftmp/Bill.Stern/pid43698/GFS_native/ST4.2015012300
> <(201)%20501-2300>
> >> .06h
> >> > /work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
> -outdir
> >> > /work/Bill.Stern/NGGPS/MET5.2/output/GFS_native/20150116.
> >> > 00Z/grid_stat//PRATEsfc/6hr/
> >> > -v 2
> >> > DEBUG 1: Default Config File:
> >> > /home/Shannon.Rees/met-5.2_orig/met-5.2/share/met/config/
> >> > GridStatConfig_default
> >> > DEBUG 1: User Config File:
> >> > /work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
> >> > ERROR :
> >> > ERROR : Trouble reading forecast file
> >> > "/vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
> >> >
> >> > I have attached the output from "ncdump -c
> >> > /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
> >> >
> >> > The full file can be obtained from ftp.gfdl.noaa.gov
> >> > cd /pub/wfs
> >> > get PRATEsfc6all.nc
> >> >
> >> > Thank you,
> >> > Bill
> >> >
> >> >
> >> > On Mon, Jul 10, 2017 at 2:27 PM, John Halley Gotway via RT <
> >> > met_help at ucar.edu> wrote:
> >> >
> >> > > Bill,
> >> > >
> >> > > Ah, I understand. The regrid_data_plane tool is designed to
read
> >> exactly
> >> > > one 2D data field for each "-field" entry you specify on the
command
> >> > line.
> >> > > When you ran it on a file containing 21 times, you probably
got a
> >> warning
> >> > > about "multiple matching fields". By default, it'll just use
the
> >> first
> >> > > match found.
> >> > >
> >> > > You can include additional timing information in the "-field"
entry
> to
> >> > > specify which of the 21 times you actually want. Here's an
excerpt
> >> from
> >> > > the met-6.0/data/config/README file about this:
> >> > >
> >> > > // - The "init_time" entry specifies the initialization
time in
> >> > > YYYYMMDD[_HH[MMSS]]
> >> > > // format. This entry can be included in the "fcst"
entry as
> >> shown
> >> > > below or
> >> > > // included in the "field" entry if the user would like
to use
> >> > > different
> >> > > // initialization times for different fields.
> >> > > //
> >> > > // - The "valid_time" entry specifies the valid time in
> >> > > YYYYMMDD[_HH[MMSS]]
> >> > > // format. This entry can be included in the "fcst"
entry as
> >> shown
> >> > > below or
> >> > > // included in the "field" entry if the user would like
to use
> >> > > different
> >> > > // valid times for different fields.
> >> > > //
> >> > > // - The "lead_time" entry specifies the lead time in
HH[MMSS]
> >> > > // format. This entry can be included in the "fcst"
entry as
> >> shown
> >> > > below or
> >> > > // included in the "field" entry if the user would like
to use
> >> > > different
> >> > > // lead times for different fields.
> >> > >
> >> > > So you could try running adding the "valid_time":
> >> > >
> >> > > /usr/local/met-6.0/bin/regrid_data_plane \
> >> > > gfs_2012040900_F012.grib2 gfs_2012040900
> <(201)%20204-0900>_F012.grib2
> >> prate.nc \
> >> > > -field 'name="PRATE"; level="A6";
valid_time="20120409_120000";'
> >> > >
> >> > > Technically, you could run regrid_data_plane once on each
input
> file,
> >> > pass
> >> > > in 21 "-field" settings, and write a single output file. But
you'll
> >> get
> >> > an
> >> > > error because it'll try to write the same NetCDF variable
name
> >> multiple
> >> > > times. You could get around that by using the "-name" option
to
> >> passing
> >> > in
> >> > > 21 unique output variables names... but that's a whole lot of
> details.
> >> > >
> >> > > Instead, I'd suggest running regrid_data_plane once for each
> 3-hourly
> >> > > output time and specify the "valid_time" currently being
> processed. I
> >> > > think that logic would be cleaner.
> >> > >
> >> > > Hope that helps.
> >> > >
> >> > > Thanks,
> >> > > John
> >> > >
> >> > > On Mon, Jul 10, 2017 at 7:33 AM, bill.stern at noaa.gov via RT <
> >> > > met_help at ucar.edu> wrote:
> >> > >
> >> > > >
> >> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
> >> > > >
> >> > > > Hi John,
> >> > > >
> >> > > > I have followed your example of applying regrid_data_plane
for
> >> > creating a
> >> > > > netcdf file from a grib2. The command below does create a
netcdf,
> >> but
> >> > I
> >> > > am
> >> > > > only seem to be getting a single time level on the netcdf
file,
> >> while
> >> > the
> >> > > > grib2 file has 21 time levels. Here is my
regrid_data_plane
> >> command:
> >> > > >
> >> > > > regrid_data_plane nam.2017051500.conusnest.hires.tm00.grib2
> >> > > > nam.2017051500.conusnest.hires.tm00.grib2 nam.2017051500
> >> > .conusnest.APCP.
> >> > > nc
> >> > > > -field 'name = "APCP";level="A3";'
> >> > > >
> >> > > > What am I missing?
> >> > > >
> >> > > > Thanks,
> >> > > > Bill
> >> > > >
> >> > > > On Fri, Jul 7, 2017 at 12:44 PM, John Halley Gotway via RT
<
> >> > > > met_help at ucar.edu> wrote:
> >> > > >
> >> > > > > Hi Bill,
> >> > > > >
> >> > > > > I moved your question over into the MET-Help support
ticketing
> >> > system.
> >> > > > >
> >> > > > > I see that you're having trouble processing the NetCDF
output of
> >> the
> >> > > > > ncl_convert2nc utility in MET. MET is only set up to
read a
> >> handful
> >> > of
> >> > > > > NetCDF file formats, and unfortunately, the output of
> >> ncl_convert2nc
> >> > is
> >> > > > not
> >> > > > > one of them. The 3 NetCDF flavors that MET reads are
> CF-complaint
> >> > > > > (climate-forecast convention) files, the output of the
> wrf_interp
> >> > > > utility,
> >> > > > > and the internal NetCDF format written by the MET tools
> >> themselves.
> >> > > > >
> >> > > > > I understand that you'd like to do additional processing
on the
> >> > > > > precipitation rate data... and NetCDF is much easier to
work
> with
> >> > than
> >> > > > > GRIB2.
> >> > > > >
> >> > > > > Rather than using ncl_convert2nc to reformat the GRIB2
data,
> let's
> >> > use
> >> > > > the
> >> > > > > MET regrid_data_plane tool instead. I'll demonstrate
this
> below.
> >> > > > >
> >> > > > > # I'll start with a sample GRIB2 GFS file that includes
PRATE:
> >> > > > >
> >> > > > > wgrib2 gfs_2012040900_F012.grib2 | grep PRATE
> >> > > > > 199:37137213:d=2012040900 <(201)%20204-
0900>:PRATE:surface:6-12
> >> hour ave fcst:
> >> > > > >
> >> > > > > # Call regrid_data_plane using the -field option to
select the
> >> PRATE
> >> > > > record
> >> > > > >
> >> > > > > /usr/local/met-6.0/bin/regrid_data_plane \
> >> > > > > gfs_2012040900 <(201)%20204-0900>_F012.grib2
gfs_2012040900
> >> <(201)%20204-0900>_F012.grib2 prate.nc \
> >> > > > > -field 'name="PRATE"; level="A6";'
> >> > > > >
> >> > > > > DEBUG 1: Reading data file: gfs_2012040900_F012.grib2
> >> > > > > DEBUG 2: Input grid: Projection: Lat/Lon Nx: 720 Ny: 361
lat_ll:
> >> > > -90.000
> >> > > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> >> > > > > DEBUG 2: Output grid: Projection: Lat/Lon Nx: 720 Ny: 361
> lat_ll:
> >> > > -90.000
> >> > > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> >> > > > > DEBUG 2: Interpolation options: method = NEAREST, width =
1,
> >> shape =
> >> > > > > SQUARE, vld_thresh = 0.5
> >> > > > > DEBUG 2: Range of input data (name="PRATE"; level="A6";)
is 0 to
> >> > > > 0.004075.
> >> > > > > DEBUG 2: Range of regridded data (name="PRATE";
level="A6";) is
> 0
> >> to
> >> > > > > 0.004075.
> >> > > > > DEBUG 1: Writing output file: prate.nc
> >> > > > >
> >> > > > > Since the input and output grids are the same, no re-
gridding is
> >> > > actually
> >> > > > > being done. You could have also used the pcp_combine
tool to do
> >> the
> >> > > same
> >> > > > > thing. But the nice thing about regrid_data_plane is
that you
> >> could
> >> > > > > include multiple fields in the output by using the "-
field"
> >> command
> >> > > line
> >> > > > > option multiple times.
> >> > > > >
> >> > > > > Then you can edit the NetCDF output of regrid_data_plane
however
> >> > you'd
> >> > > > > like, and MET should be able to read that file.
> >> > > > >
> >> > > > > Hope that helps.
> >> > > > >
> >> > > > > Thanks,
> >> > > > > John
> >> > > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Bill Stern, Meteorologist
> >> > > > Room 206
> >> > > > NOAA/Geophysical Fluid Dynamics Laboratory
> >> > > > Princeton University Forrestal Campus
> >> > > > 201 Forrestal Road Princeton, NJ 08540-6649
> >> > > > Tel: (609)452-6545
> >> > > > Fax: (609)987-5063 <(609)%20987-5063>
> >> > > > ------------------------------
> >> > > > ------------------------------------
> >> > > > Email Address: bill.stern at noaa.gov
> >> > > >
------------------------------------------------------------
> ------
> >> > > > Anonymous ftp Address: ftp.gfdl.noaa.gov
> >> > > >
------------------------------------------------------------
> ------
> >> > > > On the World Wide Web: http://www.gfdl.noaa.gov/bill-
> >> stern-gfdl-noaa
> >> > > >
------------------------------------------------------------
> ------
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > Bill Stern, Meteorologist
> >> > Room 206
> >> > NOAA/Geophysical Fluid Dynamics Laboratory
> >> > Princeton University Forrestal Campus
> >> > 201 Forrestal Road Princeton, NJ 08540-6649
> >> > Tel: (609)452-6545 <(609)%20452-6545>
> >> > Fax: (609)987-5063 <(609)%20987-5063>
> >> > ------------------------------
> >> > ------------------------------------
> >> > Email Address: bill.stern at noaa.gov
> >> >
------------------------------------------------------------------
> >> > Anonymous ftp Address: ftp.gfdl.noaa.gov
> >> >
------------------------------------------------------------------
> >> > On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-
gfdl-noaa
> >> >
------------------------------------------------------------------
> >> >
> >> >
> >>
> >>
> >
> >
> > --
> > Bill Stern, Meteorologist
> > Room 206
> > NOAA/Geophysical Fluid Dynamics Laboratory
> > Princeton University Forrestal Campus
> > 201 Forrestal Road Princeton, NJ 08540-6649
> > Tel: (609)452-6545 <(609)%20452-6545>
> > Fax: (609)987-5063 <(609)%20987-5063>
> > ------------------------------
> > ------------------------------------
> > Email Address: bill.stern at noaa.gov
> > ------------------------------------------------------------------
> > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > ------------------------------------------------------------------
> > On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-gfdl-
noaa
> > ------------------------------------------------------------------
> >
>
>
--
Shannon Rees
Meteorologist
Engility
Geophysical Fluid Dynamics Lab
Princeton University Forrestal Campus
201 Forrestal Rd Princeton, NJ
609-452-5384 <(609)%20452-5384>
------------------------------------------------
Subject: problem reading netdcf file
From: bill.stern at noaa.gov
Time: Thu Jul 20 10:25:39 2017
John,
Is that orientation bug just in the plotting or would it also affect
the
grid_stat tool?
Thanks,
Bill
On Thu, Jul 20, 2017 at 12:15 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Bill,
>
> Yes, you're right. Setting "conventions = "CF-1.0" *should* tell
MET that
> the NetCDF file is CF-compliant. Unfortunately, there are some
wrinkles in
> the logic in 5.2 that we've ironed out in 6.0 :) And that's why
setting
> "file_type = NETCDF_NCCF;" is still needed in 5.2.
>
> However, the incorrect orientation of your data in 6.0 really is a
bug.
> And I've asked the developer who worked on that logic to find and
fix the
> problem. Once we have a fix, we'll post it to the website and let
you
> know.
>
> Additionally, version 6.0 contains some major run time improvements,
mostly
> for Grid-Stat. The speed of reading/writing NetCDF is improved, but
more
> importantly the allocation of memory is dramatically improved. For
small
> numbers of matched pairs, it's not really noticeable. But for large
> numbers, the improvements are significant. I ran Grid-Stat on your
data
> (4,718,592 matched pairs) using both 5.2 and 6.0 and just computing
scalar
> partial sums. On my machine 5.2 took 18.5 seconds while 6.0 took
only 5.5
> seconds.
>
> So yes, I would recommend using met-6.0.
>
> Thanks,
> John
>
> On Thu, Jul 20, 2017 at 7:38 AM, Bill Stern - NOAA Affiliate <
> bill.stern at noaa.gov> wrote:
>
> > Hi John,
> >
> > Just another related question. I am somewhat confused regarding
how MET
> > is interpreting the file as being "CF compliant". I thought by
setting
> the
> > "conventions" attribute to: "CF-1.0", MET will interpret the
netcdf file
> as
> > being CF compliant, but you seemed to have to tell the MET
> > "plot_data_plane" tool to consider the file CF compliant by
specifying
> via
> > the option "file_type=NETCDF_NCCF"? Can you enlighten me?
> >
> > Thanks,
> > Bill
> >
> > On Wed, Jul 19, 2017 at 7:05 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> >> Bill,
> >>
> >> Sorry for the delay in responding.
> >>
> >> I logged on to the ftp site and grabbed your sample file:
> PRATEsfc6all.nc
> >>
> >> I was able to replicate the error message you saw from met-5.2:
> >> ERROR : plot_data_plane -> file "PRATEsfc6all.nc" not a valid
data file
> >>
> >> If you instruct MET to interpret this file as a CF-compliant
NetCDF
> file,
> >> then it runs without error, but the data is packed upside down
(see
> >> attached prate_met-5.2.png):
> >>
> >> met-5.2/bin/plot_data_plane \
> >> PRATEsfc6all.nc prate_met-5.2.ps \
> >> 'name="PRATEsfc"; level="(4,*,*)"; file_type=NETCDF_NCCF;'
> >>
> >> In met-6.0, we fixed this issue and turned the world back right
side up.
> >> And in 6.0, you don't even need to tell it that it's CF
compliant:
> >>
> >> met-6.0/bin/plot_data_plane \
> >> PRATEsfc6all.nc prate_met-6.0.ps \
> >> 'name="PRATEsfc"; level="(4,*,*)";'
> >>
> >> So if possible, I'd suggest using met-6.0. Hope that helps.
> >>
> >> Thanks,
> >> John
> >>
> >> On Sat, Jul 15, 2017 at 11:03 AM, bill.stern at noaa.gov via RT <
> >> met_help at ucar.edu> wrote:
> >>
> >> >
> >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
> >> >
> >> > John and others,
> >> >
> >> > I am now encountering a problem with MET's inability to read
GFS
> >> forecast
> >> > files that were processed to netcdf. There are more than 75
forecast
> >> dates
> >> > each with 40 forecast time levels. It would be a very time
consuming
> >> task
> >> > to return to the original GRIB files and re-process each time
level
> with
> >> > MET regrid_data_plane tool. So, I would like to find a way to
modify
> the
> >> > existing netcdf files so they will be acceptable to MET.
> >> >
> >> > Here is the error I am encountering:
> >> > /home/Shannon.Rees/met-5.2_orig/met-5.2/src/tools/core/grid_
> >> stat/grid_stat
> >> > /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc
> >> > /vftmp/Bill.Stern/pid43698/GFS_native/ST4.2015012300
> <(201)%20501-2300>
> >> .06h
> >> > /work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
> -outdir
> >> > /work/Bill.Stern/NGGPS/MET5.2/output/GFS_native/20150116.
> >> > 00Z/grid_stat//PRATEsfc/6hr/
> >> > -v 2
> >> > DEBUG 1: Default Config File:
> >> > /home/Shannon.Rees/met-5.2_orig/met-5.2/share/met/config/
> >> > GridStatConfig_default
> >> > DEBUG 1: User Config File:
> >> > /work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
> >> > ERROR :
> >> > ERROR : Trouble reading forecast file
> >> > "/vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
> >> >
> >> > I have attached the output from "ncdump -c
> >> > /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
> >> >
> >> > The full file can be obtained from ftp.gfdl.noaa.gov
> >> > cd /pub/wfs
> >> > get PRATEsfc6all.nc
> >> >
> >> > Thank you,
> >> > Bill
> >> >
> >> >
> >> > On Mon, Jul 10, 2017 at 2:27 PM, John Halley Gotway via RT <
> >> > met_help at ucar.edu> wrote:
> >> >
> >> > > Bill,
> >> > >
> >> > > Ah, I understand. The regrid_data_plane tool is designed to
read
> >> exactly
> >> > > one 2D data field for each "-field" entry you specify on the
command
> >> > line.
> >> > > When you ran it on a file containing 21 times, you probably
got a
> >> warning
> >> > > about "multiple matching fields". By default, it'll just use
the
> >> first
> >> > > match found.
> >> > >
> >> > > You can include additional timing information in the "-field"
entry
> to
> >> > > specify which of the 21 times you actually want. Here's an
excerpt
> >> from
> >> > > the met-6.0/data/config/README file about this:
> >> > >
> >> > > // - The "init_time" entry specifies the initialization
time in
> >> > > YYYYMMDD[_HH[MMSS]]
> >> > > // format. This entry can be included in the "fcst"
entry as
> >> shown
> >> > > below or
> >> > > // included in the "field" entry if the user would like
to use
> >> > > different
> >> > > // initialization times for different fields.
> >> > > //
> >> > > // - The "valid_time" entry specifies the valid time in
> >> > > YYYYMMDD[_HH[MMSS]]
> >> > > // format. This entry can be included in the "fcst"
entry as
> >> shown
> >> > > below or
> >> > > // included in the "field" entry if the user would like
to use
> >> > > different
> >> > > // valid times for different fields.
> >> > > //
> >> > > // - The "lead_time" entry specifies the lead time in
HH[MMSS]
> >> > > // format. This entry can be included in the "fcst"
entry as
> >> shown
> >> > > below or
> >> > > // included in the "field" entry if the user would like
to use
> >> > > different
> >> > > // lead times for different fields.
> >> > >
> >> > > So you could try running adding the "valid_time":
> >> > >
> >> > > /usr/local/met-6.0/bin/regrid_data_plane \
> >> > > gfs_2012040900_F012.grib2 gfs_2012040900
> <(201)%20204-0900>_F012.grib2
> >> prate.nc \
> >> > > -field 'name="PRATE"; level="A6";
valid_time="20120409_120000";'
> >> > >
> >> > > Technically, you could run regrid_data_plane once on each
input
> file,
> >> > pass
> >> > > in 21 "-field" settings, and write a single output file. But
you'll
> >> get
> >> > an
> >> > > error because it'll try to write the same NetCDF variable
name
> >> multiple
> >> > > times. You could get around that by using the "-name" option
to
> >> passing
> >> > in
> >> > > 21 unique output variables names... but that's a whole lot of
> details.
> >> > >
> >> > > Instead, I'd suggest running regrid_data_plane once for each
> 3-hourly
> >> > > output time and specify the "valid_time" currently being
> processed. I
> >> > > think that logic would be cleaner.
> >> > >
> >> > > Hope that helps.
> >> > >
> >> > > Thanks,
> >> > > John
> >> > >
> >> > > On Mon, Jul 10, 2017 at 7:33 AM, bill.stern at noaa.gov via RT <
> >> > > met_help at ucar.edu> wrote:
> >> > >
> >> > > >
> >> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
> >> > > >
> >> > > > Hi John,
> >> > > >
> >> > > > I have followed your example of applying regrid_data_plane
for
> >> > creating a
> >> > > > netcdf file from a grib2. The command below does create a
netcdf,
> >> but
> >> > I
> >> > > am
> >> > > > only seem to be getting a single time level on the netcdf
file,
> >> while
> >> > the
> >> > > > grib2 file has 21 time levels. Here is my
regrid_data_plane
> >> command:
> >> > > >
> >> > > > regrid_data_plane nam.2017051500.conusnest.hires.tm00.grib2
> >> > > > nam.2017051500.conusnest.hires.tm00.grib2 nam.2017051500
> >> > .conusnest.APCP.
> >> > > nc
> >> > > > -field 'name = "APCP";level="A3";'
> >> > > >
> >> > > > What am I missing?
> >> > > >
> >> > > > Thanks,
> >> > > > Bill
> >> > > >
> >> > > > On Fri, Jul 7, 2017 at 12:44 PM, John Halley Gotway via RT
<
> >> > > > met_help at ucar.edu> wrote:
> >> > > >
> >> > > > > Hi Bill,
> >> > > > >
> >> > > > > I moved your question over into the MET-Help support
ticketing
> >> > system.
> >> > > > >
> >> > > > > I see that you're having trouble processing the NetCDF
output of
> >> the
> >> > > > > ncl_convert2nc utility in MET. MET is only set up to
read a
> >> handful
> >> > of
> >> > > > > NetCDF file formats, and unfortunately, the output of
> >> ncl_convert2nc
> >> > is
> >> > > > not
> >> > > > > one of them. The 3 NetCDF flavors that MET reads are
> CF-complaint
> >> > > > > (climate-forecast convention) files, the output of the
> wrf_interp
> >> > > > utility,
> >> > > > > and the internal NetCDF format written by the MET tools
> >> themselves.
> >> > > > >
> >> > > > > I understand that you'd like to do additional processing
on the
> >> > > > > precipitation rate data... and NetCDF is much easier to
work
> with
> >> > than
> >> > > > > GRIB2.
> >> > > > >
> >> > > > > Rather than using ncl_convert2nc to reformat the GRIB2
data,
> let's
> >> > use
> >> > > > the
> >> > > > > MET regrid_data_plane tool instead. I'll demonstrate
this
> below.
> >> > > > >
> >> > > > > # I'll start with a sample GRIB2 GFS file that includes
PRATE:
> >> > > > >
> >> > > > > wgrib2 gfs_2012040900_F012.grib2 | grep PRATE
> >> > > > > 199:37137213:d=2012040900 <(201)%20204-
0900>:PRATE:surface:6-12
> >> hour ave fcst:
> >> > > > >
> >> > > > > # Call regrid_data_plane using the -field option to
select the
> >> PRATE
> >> > > > record
> >> > > > >
> >> > > > > /usr/local/met-6.0/bin/regrid_data_plane \
> >> > > > > gfs_2012040900 <(201)%20204-0900>_F012.grib2
gfs_2012040900
> >> <(201)%20204-0900>_F012.grib2 prate.nc \
> >> > > > > -field 'name="PRATE"; level="A6";'
> >> > > > >
> >> > > > > DEBUG 1: Reading data file: gfs_2012040900_F012.grib2
> >> > > > > DEBUG 2: Input grid: Projection: Lat/Lon Nx: 720 Ny: 361
lat_ll:
> >> > > -90.000
> >> > > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> >> > > > > DEBUG 2: Output grid: Projection: Lat/Lon Nx: 720 Ny: 361
> lat_ll:
> >> > > -90.000
> >> > > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> >> > > > > DEBUG 2: Interpolation options: method = NEAREST, width =
1,
> >> shape =
> >> > > > > SQUARE, vld_thresh = 0.5
> >> > > > > DEBUG 2: Range of input data (name="PRATE"; level="A6";)
is 0 to
> >> > > > 0.004075.
> >> > > > > DEBUG 2: Range of regridded data (name="PRATE";
level="A6";) is
> 0
> >> to
> >> > > > > 0.004075.
> >> > > > > DEBUG 1: Writing output file: prate.nc
> >> > > > >
> >> > > > > Since the input and output grids are the same, no re-
gridding is
> >> > > actually
> >> > > > > being done. You could have also used the pcp_combine
tool to do
> >> the
> >> > > same
> >> > > > > thing. But the nice thing about regrid_data_plane is
that you
> >> could
> >> > > > > include multiple fields in the output by using the "-
field"
> >> command
> >> > > line
> >> > > > > option multiple times.
> >> > > > >
> >> > > > > Then you can edit the NetCDF output of regrid_data_plane
however
> >> > you'd
> >> > > > > like, and MET should be able to read that file.
> >> > > > >
> >> > > > > Hope that helps.
> >> > > > >
> >> > > > > Thanks,
> >> > > > > John
> >> > > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Bill Stern, Meteorologist
> >> > > > Room 206
> >> > > > NOAA/Geophysical Fluid Dynamics Laboratory
> >> > > > Princeton University Forrestal Campus
> >> > > > 201 Forrestal Road Princeton, NJ 08540-6649
> >> > > > Tel: (609)452-6545
> >> > > > Fax: (609)987-5063
> >> > > > ------------------------------
> >> > > > ------------------------------------
> >> > > > Email Address: bill.stern at noaa.gov
> >> > > >
------------------------------------------------------------
> ------
> >> > > > Anonymous ftp Address: ftp.gfdl.noaa.gov
> >> > > >
------------------------------------------------------------
> ------
> >> > > > On the World Wide Web: http://www.gfdl.noaa.gov/bill-
> >> stern-gfdl-noaa
> >> > > >
------------------------------------------------------------
> ------
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > Bill Stern, Meteorologist
> >> > Room 206
> >> > NOAA/Geophysical Fluid Dynamics Laboratory
> >> > Princeton University Forrestal Campus
> >> > 201 Forrestal Road Princeton, NJ 08540-6649
> >> > Tel: (609)452-6545
> >> > Fax: (609)987-5063
> >> > ------------------------------
> >> > ------------------------------------
> >> > Email Address: bill.stern at noaa.gov
> >> >
------------------------------------------------------------------
> >> > Anonymous ftp Address: ftp.gfdl.noaa.gov
> >> >
------------------------------------------------------------------
> >> > On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-
gfdl-noaa
> >> >
------------------------------------------------------------------
> >> >
> >> >
> >>
> >>
> >
> >
> > --
> > Bill Stern, Meteorologist
> > Room 206
> > NOAA/Geophysical Fluid Dynamics Laboratory
> > Princeton University Forrestal Campus
> > 201 Forrestal Road Princeton, NJ 08540-6649
> > Tel: (609)452-6545
> > Fax: (609)987-5063
> > ------------------------------
> > ------------------------------------
> > Email Address: bill.stern at noaa.gov
> > ------------------------------------------------------------------
> > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > ------------------------------------------------------------------
> > On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-gfdl-
noaa
> > ------------------------------------------------------------------
> >
>
>
--
Bill Stern, Meteorologist
Room 206
NOAA/Geophysical Fluid Dynamics Laboratory
Princeton University Forrestal Campus
201 Forrestal Road Princeton, NJ 08540-6649
Tel: (609)452-6545
Fax: (609)987-5063
------------------------------
------------------------------------
Email Address: bill.stern at noaa.gov
------------------------------------------------------------------
Anonymous ftp Address: ftp.gfdl.noaa.gov
------------------------------------------------------------------
On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-gfdl-noaa
------------------------------------------------------------------
------------------------------------------------
Subject: problem reading netdcf file
From: John Halley Gotway
Time: Thu Jul 20 10:54:26 2017
Shannon,
Ah yes, good point. I see that we posted that met-5.2 bugfix on
1/26/17:
http://www.dtcenter.org/met/users/support/known_issues/METv5.2/index.php
I can't remember all the details... so I just ran my test using the
latest
5.2 bugfix branch and the latest 6.0 bugfix branch. Indeed, 6.0 took
5.2
seconds while 5.2 took 17.2 seconds. So yes, I would expect 6.0 to be
faster.
Bill,
Unfortunately yes, this is a bug in the library code and would affect
all
the tool (plot_data_plane and grid_stat included).
I'll let you know when we have a fix ready for 6.0.
Thanks,
John
On Thu, Jul 20, 2017 at 10:25 AM, bill.stern at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
>
> John,
>
> Is that orientation bug just in the plotting or would it also affect
the
> grid_stat tool?
> Thanks,
> Bill
>
>
>
> On Thu, Jul 20, 2017 at 12:15 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Bill,
> >
> > Yes, you're right. Setting "conventions = "CF-1.0" *should* tell
MET
> that
> > the NetCDF file is CF-compliant. Unfortunately, there are some
wrinkles
> in
> > the logic in 5.2 that we've ironed out in 6.0 :) And that's why
setting
> > "file_type = NETCDF_NCCF;" is still needed in 5.2.
> >
> > However, the incorrect orientation of your data in 6.0 really is a
bug.
> > And I've asked the developer who worked on that logic to find and
fix the
> > problem. Once we have a fix, we'll post it to the website and let
you
> > know.
> >
> > Additionally, version 6.0 contains some major run time
improvements,
> mostly
> > for Grid-Stat. The speed of reading/writing NetCDF is improved,
but more
> > importantly the allocation of memory is dramatically improved.
For small
> > numbers of matched pairs, it's not really noticeable. But for
large
> > numbers, the improvements are significant. I ran Grid-Stat on
your data
> > (4,718,592 matched pairs) using both 5.2 and 6.0 and just
computing
> scalar
> > partial sums. On my machine 5.2 took 18.5 seconds while 6.0 took
only
> 5.5
> > seconds.
> >
> > So yes, I would recommend using met-6.0.
> >
> > Thanks,
> > John
> >
> > On Thu, Jul 20, 2017 at 7:38 AM, Bill Stern - NOAA Affiliate <
> > bill.stern at noaa.gov> wrote:
> >
> > > Hi John,
> > >
> > > Just another related question. I am somewhat confused regarding
how
> MET
> > > is interpreting the file as being "CF compliant". I thought by
setting
> > the
> > > "conventions" attribute to: "CF-1.0", MET will interpret the
netcdf
> file
> > as
> > > being CF compliant, but you seemed to have to tell the MET
> > > "plot_data_plane" tool to consider the file CF compliant by
specifying
> > via
> > > the option "file_type=NETCDF_NCCF"? Can you enlighten me?
> > >
> > > Thanks,
> > > Bill
> > >
> > > On Wed, Jul 19, 2017 at 7:05 PM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > >> Bill,
> > >>
> > >> Sorry for the delay in responding.
> > >>
> > >> I logged on to the ftp site and grabbed your sample file:
> > PRATEsfc6all.nc
> > >>
> > >> I was able to replicate the error message you saw from met-5.2:
> > >> ERROR : plot_data_plane -> file "PRATEsfc6all.nc" not a valid
data
> file
> > >>
> > >> If you instruct MET to interpret this file as a CF-compliant
NetCDF
> > file,
> > >> then it runs without error, but the data is packed upside down
(see
> > >> attached prate_met-5.2.png):
> > >>
> > >> met-5.2/bin/plot_data_plane \
> > >> PRATEsfc6all.nc prate_met-5.2.ps \
> > >> 'name="PRATEsfc"; level="(4,*,*)"; file_type=NETCDF_NCCF;'
> > >>
> > >> In met-6.0, we fixed this issue and turned the world back right
side
> up.
> > >> And in 6.0, you don't even need to tell it that it's CF
compliant:
> > >>
> > >> met-6.0/bin/plot_data_plane \
> > >> PRATEsfc6all.nc prate_met-6.0.ps \
> > >> 'name="PRATEsfc"; level="(4,*,*)";'
> > >>
> > >> So if possible, I'd suggest using met-6.0. Hope that helps.
> > >>
> > >> Thanks,
> > >> John
> > >>
> > >> On Sat, Jul 15, 2017 at 11:03 AM, bill.stern at noaa.gov via RT <
> > >> met_help at ucar.edu> wrote:
> > >>
> > >> >
> > >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134
>
> > >> >
> > >> > John and others,
> > >> >
> > >> > I am now encountering a problem with MET's inability to read
GFS
> > >> forecast
> > >> > files that were processed to netcdf. There are more than 75
> forecast
> > >> dates
> > >> > each with 40 forecast time levels. It would be a very time
> consuming
> > >> task
> > >> > to return to the original GRIB files and re-process each time
level
> > with
> > >> > MET regrid_data_plane tool. So, I would like to find a way to
modify
> > the
> > >> > existing netcdf files so they will be acceptable to MET.
> > >> >
> > >> > Here is the error I am encountering:
> > >> > /home/Shannon.Rees/met-5.2_orig/met-5.2/src/tools/core/grid_
> > >> stat/grid_stat
> > >> > /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc
> > >> > /vftmp/Bill.Stern/pid43698/GFS_native/ST4.2015012300
> > <(201)%20501-2300>
> > >> .06h
> > >> >
/work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
> > -outdir
> > >> > /work/Bill.Stern/NGGPS/MET5.2/output/GFS_native/20150116.
> > >> > 00Z/grid_stat//PRATEsfc/6hr/
> > >> > -v 2
> > >> > DEBUG 1: Default Config File:
> > >> > /home/Shannon.Rees/met-5.2_orig/met-5.2/share/met/config/
> > >> > GridStatConfig_default
> > >> > DEBUG 1: User Config File:
> > >> >
/work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
> > >> > ERROR :
> > >> > ERROR : Trouble reading forecast file
> > >> > "/vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
> > >> >
> > >> > I have attached the output from "ncdump -c
> > >> > /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
> > >> >
> > >> > The full file can be obtained from ftp.gfdl.noaa.gov
> > >> > cd /pub/wfs
> > >> > get PRATEsfc6all.nc
> > >> >
> > >> > Thank you,
> > >> > Bill
> > >> >
> > >> >
> > >> > On Mon, Jul 10, 2017 at 2:27 PM, John Halley Gotway via RT <
> > >> > met_help at ucar.edu> wrote:
> > >> >
> > >> > > Bill,
> > >> > >
> > >> > > Ah, I understand. The regrid_data_plane tool is designed
to read
> > >> exactly
> > >> > > one 2D data field for each "-field" entry you specify on
the
> command
> > >> > line.
> > >> > > When you ran it on a file containing 21 times, you probably
got a
> > >> warning
> > >> > > about "multiple matching fields". By default, it'll just
use the
> > >> first
> > >> > > match found.
> > >> > >
> > >> > > You can include additional timing information in the "-
field"
> entry
> > to
> > >> > > specify which of the 21 times you actually want. Here's an
> excerpt
> > >> from
> > >> > > the met-6.0/data/config/README file about this:
> > >> > >
> > >> > > // - The "init_time" entry specifies the initialization
time in
> > >> > > YYYYMMDD[_HH[MMSS]]
> > >> > > // format. This entry can be included in the "fcst"
entry as
> > >> shown
> > >> > > below or
> > >> > > // included in the "field" entry if the user would like
to use
> > >> > > different
> > >> > > // initialization times for different fields.
> > >> > > //
> > >> > > // - The "valid_time" entry specifies the valid time in
> > >> > > YYYYMMDD[_HH[MMSS]]
> > >> > > // format. This entry can be included in the "fcst"
entry as
> > >> shown
> > >> > > below or
> > >> > > // included in the "field" entry if the user would like
to use
> > >> > > different
> > >> > > // valid times for different fields.
> > >> > > //
> > >> > > // - The "lead_time" entry specifies the lead time in
HH[MMSS]
> > >> > > // format. This entry can be included in the "fcst"
entry as
> > >> shown
> > >> > > below or
> > >> > > // included in the "field" entry if the user would like
to use
> > >> > > different
> > >> > > // lead times for different fields.
> > >> > >
> > >> > > So you could try running adding the "valid_time":
> > >> > >
> > >> > > /usr/local/met-6.0/bin/regrid_data_plane \
> > >> > > gfs_2012040900_F012.grib2 gfs_2012040900
> > <(201)%20204-0900>_F012.grib2
> > >> prate.nc \
> > >> > > -field 'name="PRATE"; level="A6";
valid_time="20120409_120000";'
> > >> > >
> > >> > > Technically, you could run regrid_data_plane once on each
input
> > file,
> > >> > pass
> > >> > > in 21 "-field" settings, and write a single output file.
But
> you'll
> > >> get
> > >> > an
> > >> > > error because it'll try to write the same NetCDF variable
name
> > >> multiple
> > >> > > times. You could get around that by using the "-name"
option to
> > >> passing
> > >> > in
> > >> > > 21 unique output variables names... but that's a whole lot
of
> > details.
> > >> > >
> > >> > > Instead, I'd suggest running regrid_data_plane once for
each
> > 3-hourly
> > >> > > output time and specify the "valid_time" currently being
> > processed. I
> > >> > > think that logic would be cleaner.
> > >> > >
> > >> > > Hope that helps.
> > >> > >
> > >> > > Thanks,
> > >> > > John
> > >> > >
> > >> > > On Mon, Jul 10, 2017 at 7:33 AM, bill.stern at noaa.gov via RT
<
> > >> > > met_help at ucar.edu> wrote:
> > >> > >
> > >> > > >
> > >> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
> > >> > > >
> > >> > > > Hi John,
> > >> > > >
> > >> > > > I have followed your example of applying
regrid_data_plane for
> > >> > creating a
> > >> > > > netcdf file from a grib2. The command below does create
a
> netcdf,
> > >> but
> > >> > I
> > >> > > am
> > >> > > > only seem to be getting a single time level on the netcdf
file,
> > >> while
> > >> > the
> > >> > > > grib2 file has 21 time levels. Here is my
regrid_data_plane
> > >> command:
> > >> > > >
> > >> > > > regrid_data_plane
nam.2017051500.conusnest.hires.tm00.grib2
> > >> > > > nam.2017051500.conusnest.hires.tm00.grib2 nam.2017051500
> > >> > .conusnest.APCP.
> > >> > > nc
> > >> > > > -field 'name = "APCP";level="A3";'
> > >> > > >
> > >> > > > What am I missing?
> > >> > > >
> > >> > > > Thanks,
> > >> > > > Bill
> > >> > > >
> > >> > > > On Fri, Jul 7, 2017 at 12:44 PM, John Halley Gotway via
RT <
> > >> > > > met_help at ucar.edu> wrote:
> > >> > > >
> > >> > > > > Hi Bill,
> > >> > > > >
> > >> > > > > I moved your question over into the MET-Help support
ticketing
> > >> > system.
> > >> > > > >
> > >> > > > > I see that you're having trouble processing the NetCDF
output
> of
> > >> the
> > >> > > > > ncl_convert2nc utility in MET. MET is only set up to
read a
> > >> handful
> > >> > of
> > >> > > > > NetCDF file formats, and unfortunately, the output of
> > >> ncl_convert2nc
> > >> > is
> > >> > > > not
> > >> > > > > one of them. The 3 NetCDF flavors that MET reads are
> > CF-complaint
> > >> > > > > (climate-forecast convention) files, the output of the
> > wrf_interp
> > >> > > > utility,
> > >> > > > > and the internal NetCDF format written by the MET tools
> > >> themselves.
> > >> > > > >
> > >> > > > > I understand that you'd like to do additional
processing on
> the
> > >> > > > > precipitation rate data... and NetCDF is much easier to
work
> > with
> > >> > than
> > >> > > > > GRIB2.
> > >> > > > >
> > >> > > > > Rather than using ncl_convert2nc to reformat the GRIB2
data,
> > let's
> > >> > use
> > >> > > > the
> > >> > > > > MET regrid_data_plane tool instead. I'll demonstrate
this
> > below.
> > >> > > > >
> > >> > > > > # I'll start with a sample GRIB2 GFS file that includes
PRATE:
> > >> > > > >
> > >> > > > > wgrib2 gfs_2012040900_F012.grib2 | grep PRATE
> > >> > > > > 199:37137213:d=2012040900 <(201)%20204-0900>:PRATE:
> surface:6-12
> > >> hour ave fcst:
> > >> > > > >
> > >> > > > > # Call regrid_data_plane using the -field option to
select the
> > >> PRATE
> > >> > > > record
> > >> > > > >
> > >> > > > > /usr/local/met-6.0/bin/regrid_data_plane \
> > >> > > > > gfs_2012040900 <(201)%20204-0900>_F012.grib2
gfs_2012040900
> > >> <(201)%20204-0900>_F012.grib2 prate.nc \
> > >> > > > > -field 'name="PRATE"; level="A6";'
> > >> > > > >
> > >> > > > > DEBUG 1: Reading data file: gfs_2012040900_F012.grib2
> > >> > > > > DEBUG 2: Input grid: Projection: Lat/Lon Nx: 720 Ny:
361
> lat_ll:
> > >> > > -90.000
> > >> > > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> > >> > > > > DEBUG 2: Output grid: Projection: Lat/Lon Nx: 720 Ny:
361
> > lat_ll:
> > >> > > -90.000
> > >> > > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> > >> > > > > DEBUG 2: Interpolation options: method = NEAREST, width
= 1,
> > >> shape =
> > >> > > > > SQUARE, vld_thresh = 0.5
> > >> > > > > DEBUG 2: Range of input data (name="PRATE";
level="A6";) is 0
> to
> > >> > > > 0.004075.
> > >> > > > > DEBUG 2: Range of regridded data (name="PRATE";
level="A6";)
> is
> > 0
> > >> to
> > >> > > > > 0.004075.
> > >> > > > > DEBUG 1: Writing output file: prate.nc
> > >> > > > >
> > >> > > > > Since the input and output grids are the same, no re-
gridding
> is
> > >> > > actually
> > >> > > > > being done. You could have also used the pcp_combine
tool to
> do
> > >> the
> > >> > > same
> > >> > > > > thing. But the nice thing about regrid_data_plane is
that you
> > >> could
> > >> > > > > include multiple fields in the output by using the "-
field"
> > >> command
> > >> > > line
> > >> > > > > option multiple times.
> > >> > > > >
> > >> > > > > Then you can edit the NetCDF output of
regrid_data_plane
> however
> > >> > you'd
> > >> > > > > like, and MET should be able to read that file.
> > >> > > > >
> > >> > > > > Hope that helps.
> > >> > > > >
> > >> > > > > Thanks,
> > >> > > > > John
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > --
> > >> > > > Bill Stern, Meteorologist
> > >> > > > Room 206
> > >> > > > NOAA/Geophysical Fluid Dynamics Laboratory
> > >> > > > Princeton University Forrestal Campus
> > >> > > > 201 Forrestal Road Princeton, NJ 08540-6649
> > >> > > > Tel: (609)452-6545
> > >> > > > Fax: (609)987-5063
> > >> > > > ------------------------------
> > >> > > > ------------------------------------
> > >> > > > Email Address: bill.stern at noaa.gov
> > >> > > >
------------------------------------------------------------
> > ------
> > >> > > > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > >> > > >
------------------------------------------------------------
> > ------
> > >> > > > On the World Wide Web: http://www.gfdl.noaa.gov/bill-
> > >> stern-gfdl-noaa
> > >> > > >
------------------------------------------------------------
> > ------
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> > --
> > >> > Bill Stern, Meteorologist
> > >> > Room 206
> > >> > NOAA/Geophysical Fluid Dynamics Laboratory
> > >> > Princeton University Forrestal Campus
> > >> > 201 Forrestal Road Princeton, NJ 08540-6649
> > >> > Tel: (609)452-6545
> > >> > Fax: (609)987-5063
> > >> > ------------------------------
> > >> > ------------------------------------
> > >> > Email Address: bill.stern at noaa.gov
> > >> >
------------------------------------------------------------------
> > >> > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > >> >
------------------------------------------------------------------
> > >> > On the World Wide Web: http://www.gfdl.noaa.gov/bill-
> stern-gfdl-noaa
> > >> >
------------------------------------------------------------------
> > >> >
> > >> >
> > >>
> > >>
> > >
> > >
> > > --
> > > Bill Stern, Meteorologist
> > > Room 206
> > > NOAA/Geophysical Fluid Dynamics Laboratory
> > > Princeton University Forrestal Campus
> > > 201 Forrestal Road Princeton, NJ 08540-6649
> > > Tel: (609)452-6545
> > > Fax: (609)987-5063
> > > ------------------------------
> > > ------------------------------------
> > > Email Address: bill.stern at noaa.gov
> > >
------------------------------------------------------------------
> > > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > >
------------------------------------------------------------------
> > > On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-
gfdl-noaa
> > >
------------------------------------------------------------------
> > >
> >
> >
>
>
> --
> Bill Stern, Meteorologist
> Room 206
> NOAA/Geophysical Fluid Dynamics Laboratory
> Princeton University Forrestal Campus
> 201 Forrestal Road Princeton, NJ 08540-6649
> Tel: (609)452-6545
> Fax: (609)987-5063
> ------------------------------
> ------------------------------------
> Email Address: bill.stern at noaa.gov
> ------------------------------------------------------------------
> Anonymous ftp Address: ftp.gfdl.noaa.gov
> ------------------------------------------------------------------
> On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-gfdl-
noaa
> ------------------------------------------------------------------
>
>
------------------------------------------------
Subject: problem reading netdcf file
From: Shannon Rees - NOAA Affiliate
Time: Thu Jul 20 10:57:33 2017
John,
Great! Thanks for the clarification. We will switch to 6.0 once
you've
posted the bug fix.
Shannon
On Thu, Jul 20, 2017 at 12:54 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Shannon,
>
> Ah yes, good point. I see that we posted that met-5.2 bugfix on
1/26/17:
> http://www.dtcenter.org/met/users/support/known_issues/
> METv5.2/index.php
>
> I can't remember all the details... so I just ran my test using the
latest
> 5.2 bugfix branch and the latest 6.0 bugfix branch. Indeed, 6.0
took 5.2
> seconds while 5.2 took 17.2 seconds. So yes, I would expect 6.0 to
be
> faster.
>
> Bill,
>
> Unfortunately yes, this is a bug in the library code and would
affect all
> the tool (plot_data_plane and grid_stat included).
>
> I'll let you know when we have a fix ready for 6.0.
>
> Thanks,
> John
>
> On Thu, Jul 20, 2017 at 10:25 AM, bill.stern at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
> >
> > John,
> >
> > Is that orientation bug just in the plotting or would it also
affect the
> > grid_stat tool?
> > Thanks,
> > Bill
> >
> >
> >
> > On Thu, Jul 20, 2017 at 12:15 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Bill,
> > >
> > > Yes, you're right. Setting "conventions = "CF-1.0" *should*
tell MET
> > that
> > > the NetCDF file is CF-compliant. Unfortunately, there are some
> wrinkles
> > in
> > > the logic in 5.2 that we've ironed out in 6.0 :) And that's why
> setting
> > > "file_type = NETCDF_NCCF;" is still needed in 5.2.
> > >
> > > However, the incorrect orientation of your data in 6.0 really is
a bug.
> > > And I've asked the developer who worked on that logic to find
and fix
> the
> > > problem. Once we have a fix, we'll post it to the website and
let you
> > > know.
> > >
> > > Additionally, version 6.0 contains some major run time
improvements,
> > mostly
> > > for Grid-Stat. The speed of reading/writing NetCDF is improved,
but
> more
> > > importantly the allocation of memory is dramatically improved.
For
> small
> > > numbers of matched pairs, it's not really noticeable. But for
large
> > > numbers, the improvements are significant. I ran Grid-Stat on
your
> data
> > > (4,718,592 matched pairs) using both 5.2 and 6.0 and just
computing
> > scalar
> > > partial sums. On my machine 5.2 took 18.5 seconds while 6.0
took only
> > 5.5
> > > seconds.
> > >
> > > So yes, I would recommend using met-6.0.
> > >
> > > Thanks,
> > > John
> > >
> > > On Thu, Jul 20, 2017 at 7:38 AM, Bill Stern - NOAA Affiliate <
> > > bill.stern at noaa.gov> wrote:
> > >
> > > > Hi John,
> > > >
> > > > Just another related question. I am somewhat confused
regarding how
> > MET
> > > > is interpreting the file as being "CF compliant". I thought
by
> setting
> > > the
> > > > "conventions" attribute to: "CF-1.0", MET will interpret the
netcdf
> > file
> > > as
> > > > being CF compliant, but you seemed to have to tell the MET
> > > > "plot_data_plane" tool to consider the file CF compliant by
> specifying
> > > via
> > > > the option "file_type=NETCDF_NCCF"? Can you enlighten me?
> > > >
> > > > Thanks,
> > > > Bill
> > > >
> > > > On Wed, Jul 19, 2017 at 7:05 PM, John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > >> Bill,
> > > >>
> > > >> Sorry for the delay in responding.
> > > >>
> > > >> I logged on to the ftp site and grabbed your sample file:
> > > PRATEsfc6all.nc
> > > >>
> > > >> I was able to replicate the error message you saw from met-
5.2:
> > > >> ERROR : plot_data_plane -> file "PRATEsfc6all.nc" not a
valid data
> > file
> > > >>
> > > >> If you instruct MET to interpret this file as a CF-compliant
NetCDF
> > > file,
> > > >> then it runs without error, but the data is packed upside
down (see
> > > >> attached prate_met-5.2.png):
> > > >>
> > > >> met-5.2/bin/plot_data_plane \
> > > >> PRATEsfc6all.nc prate_met-5.2.ps \
> > > >> 'name="PRATEsfc"; level="(4,*,*)"; file_type=NETCDF_NCCF;'
> > > >>
> > > >> In met-6.0, we fixed this issue and turned the world back
right side
> > up.
> > > >> And in 6.0, you don't even need to tell it that it's CF
compliant:
> > > >>
> > > >> met-6.0/bin/plot_data_plane \
> > > >> PRATEsfc6all.nc prate_met-6.0.ps \
> > > >> 'name="PRATEsfc"; level="(4,*,*)";'
> > > >>
> > > >> So if possible, I'd suggest using met-6.0. Hope that helps.
> > > >>
> > > >> Thanks,
> > > >> John
> > > >>
> > > >> On Sat, Jul 15, 2017 at 11:03 AM, bill.stern at noaa.gov via RT
<
> > > >> met_help at ucar.edu> wrote:
> > > >>
> > > >> >
> > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
> > > >> >
> > > >> > John and others,
> > > >> >
> > > >> > I am now encountering a problem with MET's inability to
read GFS
> > > >> forecast
> > > >> > files that were processed to netcdf. There are more than
75
> > forecast
> > > >> dates
> > > >> > each with 40 forecast time levels. It would be a very time
> > consuming
> > > >> task
> > > >> > to return to the original GRIB files and re-process each
time
> level
> > > with
> > > >> > MET regrid_data_plane tool. So, I would like to find a way
to
> modify
> > > the
> > > >> > existing netcdf files so they will be acceptable to MET.
> > > >> >
> > > >> > Here is the error I am encountering:
> > > >> > /home/Shannon.Rees/met-5.2_orig/met-
5.2/src/tools/core/grid_
> > > >> stat/grid_stat
> > > >> > /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc
> > > >> > /vftmp/Bill.Stern/pid43698/GFS_native/ST4.2015012300
> > > <(201)%20501-2300>
> > > >> .06h
> > > >> >
/work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
> > > -outdir
> > > >> > /work/Bill.Stern/NGGPS/MET5.2/output/GFS_native/20150116.
> > > >> > 00Z/grid_stat//PRATEsfc/6hr/
> > > >> > -v 2
> > > >> > DEBUG 1: Default Config File:
> > > >> > /home/Shannon.Rees/met-5.2_orig/met-5.2/share/met/config/
> > > >> > GridStatConfig_default
> > > >> > DEBUG 1: User Config File:
> > > >> >
/work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
> > > >> > ERROR :
> > > >> > ERROR : Trouble reading forecast file
> > > >> > "/vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
> > > >> >
> > > >> > I have attached the output from "ncdump -c
> > > >> > /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
> > > >> >
> > > >> > The full file can be obtained from ftp.gfdl.noaa.gov
> > > >> > cd /pub/wfs
> > > >> > get PRATEsfc6all.nc
> > > >> >
> > > >> > Thank you,
> > > >> > Bill
> > > >> >
> > > >> >
> > > >> > On Mon, Jul 10, 2017 at 2:27 PM, John Halley Gotway via RT
<
> > > >> > met_help at ucar.edu> wrote:
> > > >> >
> > > >> > > Bill,
> > > >> > >
> > > >> > > Ah, I understand. The regrid_data_plane tool is designed
to
> read
> > > >> exactly
> > > >> > > one 2D data field for each "-field" entry you specify on
the
> > command
> > > >> > line.
> > > >> > > When you ran it on a file containing 21 times, you
probably got
> a
> > > >> warning
> > > >> > > about "multiple matching fields". By default, it'll just
use
> the
> > > >> first
> > > >> > > match found.
> > > >> > >
> > > >> > > You can include additional timing information in the "-
field"
> > entry
> > > to
> > > >> > > specify which of the 21 times you actually want. Here's
an
> > excerpt
> > > >> from
> > > >> > > the met-6.0/data/config/README file about this:
> > > >> > >
> > > >> > > // - The "init_time" entry specifies the initialization
time
> in
> > > >> > > YYYYMMDD[_HH[MMSS]]
> > > >> > > // format. This entry can be included in the "fcst"
entry
> as
> > > >> shown
> > > >> > > below or
> > > >> > > // included in the "field" entry if the user would
like to
> use
> > > >> > > different
> > > >> > > // initialization times for different fields.
> > > >> > > //
> > > >> > > // - The "valid_time" entry specifies the valid time in
> > > >> > > YYYYMMDD[_HH[MMSS]]
> > > >> > > // format. This entry can be included in the "fcst"
entry
> as
> > > >> shown
> > > >> > > below or
> > > >> > > // included in the "field" entry if the user would
like to
> use
> > > >> > > different
> > > >> > > // valid times for different fields.
> > > >> > > //
> > > >> > > // - The "lead_time" entry specifies the lead time in
HH[MMSS]
> > > >> > > // format. This entry can be included in the "fcst"
entry
> as
> > > >> shown
> > > >> > > below or
> > > >> > > // included in the "field" entry if the user would
like to
> use
> > > >> > > different
> > > >> > > // lead times for different fields.
> > > >> > >
> > > >> > > So you could try running adding the "valid_time":
> > > >> > >
> > > >> > > /usr/local/met-6.0/bin/regrid_data_plane \
> > > >> > > gfs_2012040900_F012.grib2 gfs_2012040900
> > > <(201)%20204-0900>_F012.grib2
> > > >> prate.nc \
> > > >> > > -field 'name="PRATE"; level="A6";
valid_time="20120409_120000";'
> > > >> > >
> > > >> > > Technically, you could run regrid_data_plane once on each
input
> > > file,
> > > >> > pass
> > > >> > > in 21 "-field" settings, and write a single output file.
But
> > you'll
> > > >> get
> > > >> > an
> > > >> > > error because it'll try to write the same NetCDF variable
name
> > > >> multiple
> > > >> > > times. You could get around that by using the "-name"
option to
> > > >> passing
> > > >> > in
> > > >> > > 21 unique output variables names... but that's a whole
lot of
> > > details.
> > > >> > >
> > > >> > > Instead, I'd suggest running regrid_data_plane once for
each
> > > 3-hourly
> > > >> > > output time and specify the "valid_time" currently being
> > > processed. I
> > > >> > > think that logic would be cleaner.
> > > >> > >
> > > >> > > Hope that helps.
> > > >> > >
> > > >> > > Thanks,
> > > >> > > John
> > > >> > >
> > > >> > > On Mon, Jul 10, 2017 at 7:33 AM, bill.stern at noaa.gov via
RT <
> > > >> > > met_help at ucar.edu> wrote:
> > > >> > >
> > > >> > > >
> > > >> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134
> >
> > > >> > > >
> > > >> > > > Hi John,
> > > >> > > >
> > > >> > > > I have followed your example of applying
regrid_data_plane for
> > > >> > creating a
> > > >> > > > netcdf file from a grib2. The command below does
create a
> > netcdf,
> > > >> but
> > > >> > I
> > > >> > > am
> > > >> > > > only seem to be getting a single time level on the
netcdf
> file,
> > > >> while
> > > >> > the
> > > >> > > > grib2 file has 21 time levels. Here is my
regrid_data_plane
> > > >> command:
> > > >> > > >
> > > >> > > > regrid_data_plane
nam.2017051500.conusnest.hires.tm00.grib2
> > > >> > > > nam.2017051500.conusnest.hires.tm00.grib2
nam.2017051500
> > > >> > .conusnest.APCP.
> > > >> > > nc
> > > >> > > > -field 'name = "APCP";level="A3";'
> > > >> > > >
> > > >> > > > What am I missing?
> > > >> > > >
> > > >> > > > Thanks,
> > > >> > > > Bill
> > > >> > > >
> > > >> > > > On Fri, Jul 7, 2017 at 12:44 PM, John Halley Gotway via
RT <
> > > >> > > > met_help at ucar.edu> wrote:
> > > >> > > >
> > > >> > > > > Hi Bill,
> > > >> > > > >
> > > >> > > > > I moved your question over into the MET-Help support
> ticketing
> > > >> > system.
> > > >> > > > >
> > > >> > > > > I see that you're having trouble processing the
NetCDF
> output
> > of
> > > >> the
> > > >> > > > > ncl_convert2nc utility in MET. MET is only set up to
read a
> > > >> handful
> > > >> > of
> > > >> > > > > NetCDF file formats, and unfortunately, the output of
> > > >> ncl_convert2nc
> > > >> > is
> > > >> > > > not
> > > >> > > > > one of them. The 3 NetCDF flavors that MET reads are
> > > CF-complaint
> > > >> > > > > (climate-forecast convention) files, the output of
the
> > > wrf_interp
> > > >> > > > utility,
> > > >> > > > > and the internal NetCDF format written by the MET
tools
> > > >> themselves.
> > > >> > > > >
> > > >> > > > > I understand that you'd like to do additional
processing on
> > the
> > > >> > > > > precipitation rate data... and NetCDF is much easier
to work
> > > with
> > > >> > than
> > > >> > > > > GRIB2.
> > > >> > > > >
> > > >> > > > > Rather than using ncl_convert2nc to reformat the
GRIB2 data,
> > > let's
> > > >> > use
> > > >> > > > the
> > > >> > > > > MET regrid_data_plane tool instead. I'll demonstrate
this
> > > below.
> > > >> > > > >
> > > >> > > > > # I'll start with a sample GRIB2 GFS file that
includes
> PRATE:
> > > >> > > > >
> > > >> > > > > wgrib2 gfs_2012040900_F012.grib2 | grep PRATE
> > > >> > > > > 199:37137213:d=2012040900 <(201)%20204-0900>:PRATE:
> > surface:6-12
> > > >> hour ave fcst:
> > > >> > > > >
> > > >> > > > > # Call regrid_data_plane using the -field option to
select
> the
> > > >> PRATE
> > > >> > > > record
> > > >> > > > >
> > > >> > > > > /usr/local/met-6.0/bin/regrid_data_plane \
> > > >> > > > > gfs_2012040900 <(201)%20204-0900>_F012.grib2
gfs_2012040900
> > > >> <(201)%20204-0900>_F012.grib2 prate.nc \
> > > >> > > > > -field 'name="PRATE"; level="A6";'
> > > >> > > > >
> > > >> > > > > DEBUG 1: Reading data file: gfs_2012040900_F012.grib2
> > > >> > > > > DEBUG 2: Input grid: Projection: Lat/Lon Nx: 720 Ny:
361
> > lat_ll:
> > > >> > > -90.000
> > > >> > > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> > > >> > > > > DEBUG 2: Output grid: Projection: Lat/Lon Nx: 720 Ny:
361
> > > lat_ll:
> > > >> > > -90.000
> > > >> > > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> > > >> > > > > DEBUG 2: Interpolation options: method = NEAREST,
width = 1,
> > > >> shape =
> > > >> > > > > SQUARE, vld_thresh = 0.5
> > > >> > > > > DEBUG 2: Range of input data (name="PRATE";
level="A6";) is
> 0
> > to
> > > >> > > > 0.004075.
> > > >> > > > > DEBUG 2: Range of regridded data (name="PRATE";
level="A6";)
> > is
> > > 0
> > > >> to
> > > >> > > > > 0.004075.
> > > >> > > > > DEBUG 1: Writing output file: prate.nc
> > > >> > > > >
> > > >> > > > > Since the input and output grids are the same, no
> re-gridding
> > is
> > > >> > > actually
> > > >> > > > > being done. You could have also used the pcp_combine
tool
> to
> > do
> > > >> the
> > > >> > > same
> > > >> > > > > thing. But the nice thing about regrid_data_plane is
that
> you
> > > >> could
> > > >> > > > > include multiple fields in the output by using the "-
field"
> > > >> command
> > > >> > > line
> > > >> > > > > option multiple times.
> > > >> > > > >
> > > >> > > > > Then you can edit the NetCDF output of
regrid_data_plane
> > however
> > > >> > you'd
> > > >> > > > > like, and MET should be able to read that file.
> > > >> > > > >
> > > >> > > > > Hope that helps.
> > > >> > > > >
> > > >> > > > > Thanks,
> > > >> > > > > John
> > > >> > > > >
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > --
> > > >> > > > Bill Stern, Meteorologist
> > > >> > > > Room 206
> > > >> > > > NOAA/Geophysical Fluid Dynamics Laboratory
> > > >> > > > Princeton University Forrestal Campus
> > > >> > > > 201 Forrestal Road Princeton, NJ 08540-6649
> > > >> > > > Tel: (609)452-6545
> > > >> > > > Fax: (609)987-5063
> > > >> > > > ------------------------------
> > > >> > > > ------------------------------------
> > > >> > > > Email Address: bill.stern at noaa.gov
> > > >> > > >
------------------------------------------------------------
> > > ------
> > > >> > > > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > > >> > > >
------------------------------------------------------------
> > > ------
> > > >> > > > On the World Wide Web: http://www.gfdl.noaa.gov/bill-
> > > >> stern-gfdl-noaa
> > > >> > > >
------------------------------------------------------------
> > > ------
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Bill Stern, Meteorologist
> > > >> > Room 206
> > > >> > NOAA/Geophysical Fluid Dynamics Laboratory
> > > >> > Princeton University Forrestal Campus
> > > >> > 201 Forrestal Road Princeton, NJ 08540-6649
> > > >> > Tel: (609)452-6545
> > > >> > Fax: (609)987-5063
> > > >> > ------------------------------
> > > >> > ------------------------------------
> > > >> > Email Address: bill.stern at noaa.gov
> > > >> >
------------------------------------------------------------
> ------
> > > >> > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > > >> >
------------------------------------------------------------
> ------
> > > >> > On the World Wide Web: http://www.gfdl.noaa.gov/bill-
> > stern-gfdl-noaa
> > > >> >
------------------------------------------------------------
> ------
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > Bill Stern, Meteorologist
> > > > Room 206
> > > > NOAA/Geophysical Fluid Dynamics Laboratory
> > > > Princeton University Forrestal Campus
> > > > 201 Forrestal Road Princeton, NJ 08540-6649
> > > > Tel: (609)452-6545
> > > > Fax: (609)987-5063
> > > > ------------------------------
> > > > ------------------------------------
> > > > Email Address: bill.stern at noaa.gov
> > > >
------------------------------------------------------------------
> > > > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > > >
------------------------------------------------------------------
> > > > On the World Wide Web: http://www.gfdl.noaa.gov/bill-
> stern-gfdl-noaa
> > > >
------------------------------------------------------------------
> > > >
> > >
> > >
> >
> >
> > --
> > Bill Stern, Meteorologist
> > Room 206
> > NOAA/Geophysical Fluid Dynamics Laboratory
> > Princeton University Forrestal Campus
> > 201 Forrestal Road Princeton, NJ 08540-6649
> > Tel: (609)452-6545
> > Fax: (609)987-5063
> > ------------------------------
> > ------------------------------------
> > Email Address: bill.stern at noaa.gov
> > ------------------------------------------------------------------
> > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > ------------------------------------------------------------------
> > On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-gfdl-
noaa
> > ------------------------------------------------------------------
> >
> >
>
>
--
Shannon Rees
Meteorologist
Engility
Geophysical Fluid Dynamics Lab
Princeton University Forrestal Campus
201 Forrestal Rd Princeton, NJ
609-452-5384
------------------------------------------------
Subject: problem reading netdcf file
From: John Halley Gotway
Time: Fri Jul 21 14:35:06 2017
Bill and Shannon,
FYI, I just posted the bugfix for met-6.0:
http://www.dtcenter.org/met/users/support/known_issues/METv6.0/
Have a good weekend.
John
On Thu, Jul 20, 2017 at 10:57 AM, Shannon Rees - NOAA Affiliate via RT
<
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
>
> John,
>
> Great! Thanks for the clarification. We will switch to 6.0 once
you've
> posted the bug fix.
>
> Shannon
>
> On Thu, Jul 20, 2017 at 12:54 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Shannon,
> >
> > Ah yes, good point. I see that we posted that met-5.2 bugfix on
1/26/17:
> > http://www.dtcenter.org/met/users/support/known_issues/
> > METv5.2/index.php
> >
> > I can't remember all the details... so I just ran my test using
the
> latest
> > 5.2 bugfix branch and the latest 6.0 bugfix branch. Indeed, 6.0
took 5.2
> > seconds while 5.2 took 17.2 seconds. So yes, I would expect 6.0
to be
> > faster.
> >
> > Bill,
> >
> > Unfortunately yes, this is a bug in the library code and would
affect all
> > the tool (plot_data_plane and grid_stat included).
> >
> > I'll let you know when we have a fix ready for 6.0.
> >
> > Thanks,
> > John
> >
> > On Thu, Jul 20, 2017 at 10:25 AM, bill.stern at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
> > >
> > > John,
> > >
> > > Is that orientation bug just in the plotting or would it also
affect
> the
> > > grid_stat tool?
> > > Thanks,
> > > Bill
> > >
> > >
> > >
> > > On Thu, Jul 20, 2017 at 12:15 PM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > > Bill,
> > > >
> > > > Yes, you're right. Setting "conventions = "CF-1.0" *should*
tell MET
> > > that
> > > > the NetCDF file is CF-compliant. Unfortunately, there are
some
> > wrinkles
> > > in
> > > > the logic in 5.2 that we've ironed out in 6.0 :) And that's
why
> > setting
> > > > "file_type = NETCDF_NCCF;" is still needed in 5.2.
> > > >
> > > > However, the incorrect orientation of your data in 6.0 really
is a
> bug.
> > > > And I've asked the developer who worked on that logic to find
and fix
> > the
> > > > problem. Once we have a fix, we'll post it to the website and
let
> you
> > > > know.
> > > >
> > > > Additionally, version 6.0 contains some major run time
improvements,
> > > mostly
> > > > for Grid-Stat. The speed of reading/writing NetCDF is
improved, but
> > more
> > > > importantly the allocation of memory is dramatically improved.
For
> > small
> > > > numbers of matched pairs, it's not really noticeable. But for
large
> > > > numbers, the improvements are significant. I ran Grid-Stat on
your
> > data
> > > > (4,718,592 matched pairs) using both 5.2 and 6.0 and just
computing
> > > scalar
> > > > partial sums. On my machine 5.2 took 18.5 seconds while 6.0
took
> only
> > > 5.5
> > > > seconds.
> > > >
> > > > So yes, I would recommend using met-6.0.
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > > On Thu, Jul 20, 2017 at 7:38 AM, Bill Stern - NOAA Affiliate <
> > > > bill.stern at noaa.gov> wrote:
> > > >
> > > > > Hi John,
> > > > >
> > > > > Just another related question. I am somewhat confused
regarding
> how
> > > MET
> > > > > is interpreting the file as being "CF compliant". I thought
by
> > setting
> > > > the
> > > > > "conventions" attribute to: "CF-1.0", MET will interpret the
netcdf
> > > file
> > > > as
> > > > > being CF compliant, but you seemed to have to tell the MET
> > > > > "plot_data_plane" tool to consider the file CF compliant by
> > specifying
> > > > via
> > > > > the option "file_type=NETCDF_NCCF"? Can you enlighten me?
> > > > >
> > > > > Thanks,
> > > > > Bill
> > > > >
> > > > > On Wed, Jul 19, 2017 at 7:05 PM, John Halley Gotway via RT <
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > >> Bill,
> > > > >>
> > > > >> Sorry for the delay in responding.
> > > > >>
> > > > >> I logged on to the ftp site and grabbed your sample file:
> > > > PRATEsfc6all.nc
> > > > >>
> > > > >> I was able to replicate the error message you saw from met-
5.2:
> > > > >> ERROR : plot_data_plane -> file "PRATEsfc6all.nc" not a
valid
> data
> > > file
> > > > >>
> > > > >> If you instruct MET to interpret this file as a CF-
compliant
> NetCDF
> > > > file,
> > > > >> then it runs without error, but the data is packed upside
down
> (see
> > > > >> attached prate_met-5.2.png):
> > > > >>
> > > > >> met-5.2/bin/plot_data_plane \
> > > > >> PRATEsfc6all.nc prate_met-5.2.ps \
> > > > >> 'name="PRATEsfc"; level="(4,*,*)"; file_type=NETCDF_NCCF;'
> > > > >>
> > > > >> In met-6.0, we fixed this issue and turned the world back
right
> side
> > > up.
> > > > >> And in 6.0, you don't even need to tell it that it's CF
compliant:
> > > > >>
> > > > >> met-6.0/bin/plot_data_plane \
> > > > >> PRATEsfc6all.nc prate_met-6.0.ps \
> > > > >> 'name="PRATEsfc"; level="(4,*,*)";'
> > > > >>
> > > > >> So if possible, I'd suggest using met-6.0. Hope that
helps.
> > > > >>
> > > > >> Thanks,
> > > > >> John
> > > > >>
> > > > >> On Sat, Jul 15, 2017 at 11:03 AM, bill.stern at noaa.gov via
RT <
> > > > >> met_help at ucar.edu> wrote:
> > > > >>
> > > > >> >
> > > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
> > > > >> >
> > > > >> > John and others,
> > > > >> >
> > > > >> > I am now encountering a problem with MET's inability to
read GFS
> > > > >> forecast
> > > > >> > files that were processed to netcdf. There are more than
75
> > > forecast
> > > > >> dates
> > > > >> > each with 40 forecast time levels. It would be a very
time
> > > consuming
> > > > >> task
> > > > >> > to return to the original GRIB files and re-process each
time
> > level
> > > > with
> > > > >> > MET regrid_data_plane tool. So, I would like to find a
way to
> > modify
> > > > the
> > > > >> > existing netcdf files so they will be acceptable to MET.
> > > > >> >
> > > > >> > Here is the error I am encountering:
> > > > >> > /home/Shannon.Rees/met-5.2_orig/met-
5.2/src/tools/core/grid_
> > > > >> stat/grid_stat
> > > > >> > /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc
> > > > >> > /vftmp/Bill.Stern/pid43698/GFS_native/ST4.2015012300
> > > > <(201)%20501-2300>
> > > > >> .06h
> > > > >> >
/work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
> > > > -outdir
> > > > >> > /work/Bill.Stern/NGGPS/MET5.2/output/GFS_native/20150116.
> > > > >> > 00Z/grid_stat//PRATEsfc/6hr/
> > > > >> > -v 2
> > > > >> > DEBUG 1: Default Config File:
> > > > >> > /home/Shannon.Rees/met-5.2_orig/met-5.2/share/met/config/
> > > > >> > GridStatConfig_default
> > > > >> > DEBUG 1: User Config File:
> > > > >> >
/work/s4m/MET5.2/scripts/Gridstat/config/GridStatConfig_precip
> > > > >> > ERROR :
> > > > >> > ERROR : Trouble reading forecast file
> > > > >> > "/vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
> > > > >> >
> > > > >> > I have attached the output from "ncdump -c
> > > > >> > /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
> > > > >> >
> > > > >> > The full file can be obtained from ftp.gfdl.noaa.gov
> > > > >> > cd /pub/wfs
> > > > >> > get PRATEsfc6all.nc
> > > > >> >
> > > > >> > Thank you,
> > > > >> > Bill
> > > > >> >
> > > > >> >
> > > > >> > On Mon, Jul 10, 2017 at 2:27 PM, John Halley Gotway via
RT <
> > > > >> > met_help at ucar.edu> wrote:
> > > > >> >
> > > > >> > > Bill,
> > > > >> > >
> > > > >> > > Ah, I understand. The regrid_data_plane tool is
designed to
> > read
> > > > >> exactly
> > > > >> > > one 2D data field for each "-field" entry you specify
on the
> > > command
> > > > >> > line.
> > > > >> > > When you ran it on a file containing 21 times, you
probably
> got
> > a
> > > > >> warning
> > > > >> > > about "multiple matching fields". By default, it'll
just use
> > the
> > > > >> first
> > > > >> > > match found.
> > > > >> > >
> > > > >> > > You can include additional timing information in the "-
field"
> > > entry
> > > > to
> > > > >> > > specify which of the 21 times you actually want.
Here's an
> > > excerpt
> > > > >> from
> > > > >> > > the met-6.0/data/config/README file about this:
> > > > >> > >
> > > > >> > > // - The "init_time" entry specifies the
initialization time
> > in
> > > > >> > > YYYYMMDD[_HH[MMSS]]
> > > > >> > > // format. This entry can be included in the
"fcst" entry
> > as
> > > > >> shown
> > > > >> > > below or
> > > > >> > > // included in the "field" entry if the user would
like to
> > use
> > > > >> > > different
> > > > >> > > // initialization times for different fields.
> > > > >> > > //
> > > > >> > > // - The "valid_time" entry specifies the valid time
in
> > > > >> > > YYYYMMDD[_HH[MMSS]]
> > > > >> > > // format. This entry can be included in the
"fcst" entry
> > as
> > > > >> shown
> > > > >> > > below or
> > > > >> > > // included in the "field" entry if the user would
like to
> > use
> > > > >> > > different
> > > > >> > > // valid times for different fields.
> > > > >> > > //
> > > > >> > > // - The "lead_time" entry specifies the lead time in
> HH[MMSS]
> > > > >> > > // format. This entry can be included in the
"fcst" entry
> > as
> > > > >> shown
> > > > >> > > below or
> > > > >> > > // included in the "field" entry if the user would
like to
> > use
> > > > >> > > different
> > > > >> > > // lead times for different fields.
> > > > >> > >
> > > > >> > > So you could try running adding the "valid_time":
> > > > >> > >
> > > > >> > > /usr/local/met-6.0/bin/regrid_data_plane \
> > > > >> > > gfs_2012040900_F012.grib2 gfs_2012040900
> > > > <(201)%20204-0900>_F012.grib2
> > > > >> prate.nc \
> > > > >> > > -field 'name="PRATE"; level="A6";
> valid_time="20120409_120000";'
> > > > >> > >
> > > > >> > > Technically, you could run regrid_data_plane once on
each
> input
> > > > file,
> > > > >> > pass
> > > > >> > > in 21 "-field" settings, and write a single output
file. But
> > > you'll
> > > > >> get
> > > > >> > an
> > > > >> > > error because it'll try to write the same NetCDF
variable name
> > > > >> multiple
> > > > >> > > times. You could get around that by using the "-name"
option
> to
> > > > >> passing
> > > > >> > in
> > > > >> > > 21 unique output variables names... but that's a whole
lot of
> > > > details.
> > > > >> > >
> > > > >> > > Instead, I'd suggest running regrid_data_plane once for
each
> > > > 3-hourly
> > > > >> > > output time and specify the "valid_time" currently
being
> > > > processed. I
> > > > >> > > think that logic would be cleaner.
> > > > >> > >
> > > > >> > > Hope that helps.
> > > > >> > >
> > > > >> > > Thanks,
> > > > >> > > John
> > > > >> > >
> > > > >> > > On Mon, Jul 10, 2017 at 7:33 AM, bill.stern at noaa.gov
via RT <
> > > > >> > > met_help at ucar.edu> wrote:
> > > > >> > >
> > > > >> > > >
> > > > >> > > > <URL: https://rt.rap.ucar.edu/rt/
> Ticket/Display.html?id=81134
> > >
> > > > >> > > >
> > > > >> > > > Hi John,
> > > > >> > > >
> > > > >> > > > I have followed your example of applying
regrid_data_plane
> for
> > > > >> > creating a
> > > > >> > > > netcdf file from a grib2. The command below does
create a
> > > netcdf,
> > > > >> but
> > > > >> > I
> > > > >> > > am
> > > > >> > > > only seem to be getting a single time level on the
netcdf
> > file,
> > > > >> while
> > > > >> > the
> > > > >> > > > grib2 file has 21 time levels. Here is my
regrid_data_plane
> > > > >> command:
> > > > >> > > >
> > > > >> > > > regrid_data_plane
nam.2017051500.conusnest.hires.tm00.grib2
> > > > >> > > > nam.2017051500.conusnest.hires.tm00.grib2
nam.2017051500
> > > > >> > .conusnest.APCP.
> > > > >> > > nc
> > > > >> > > > -field 'name = "APCP";level="A3";'
> > > > >> > > >
> > > > >> > > > What am I missing?
> > > > >> > > >
> > > > >> > > > Thanks,
> > > > >> > > > Bill
> > > > >> > > >
> > > > >> > > > On Fri, Jul 7, 2017 at 12:44 PM, John Halley Gotway
via RT <
> > > > >> > > > met_help at ucar.edu> wrote:
> > > > >> > > >
> > > > >> > > > > Hi Bill,
> > > > >> > > > >
> > > > >> > > > > I moved your question over into the MET-Help
support
> > ticketing
> > > > >> > system.
> > > > >> > > > >
> > > > >> > > > > I see that you're having trouble processing the
NetCDF
> > output
> > > of
> > > > >> the
> > > > >> > > > > ncl_convert2nc utility in MET. MET is only set up
to
> read a
> > > > >> handful
> > > > >> > of
> > > > >> > > > > NetCDF file formats, and unfortunately, the output
of
> > > > >> ncl_convert2nc
> > > > >> > is
> > > > >> > > > not
> > > > >> > > > > one of them. The 3 NetCDF flavors that MET reads
are
> > > > CF-complaint
> > > > >> > > > > (climate-forecast convention) files, the output of
the
> > > > wrf_interp
> > > > >> > > > utility,
> > > > >> > > > > and the internal NetCDF format written by the MET
tools
> > > > >> themselves.
> > > > >> > > > >
> > > > >> > > > > I understand that you'd like to do additional
processing
> on
> > > the
> > > > >> > > > > precipitation rate data... and NetCDF is much
easier to
> work
> > > > with
> > > > >> > than
> > > > >> > > > > GRIB2.
> > > > >> > > > >
> > > > >> > > > > Rather than using ncl_convert2nc to reformat the
GRIB2
> data,
> > > > let's
> > > > >> > use
> > > > >> > > > the
> > > > >> > > > > MET regrid_data_plane tool instead. I'll
demonstrate this
> > > > below.
> > > > >> > > > >
> > > > >> > > > > # I'll start with a sample GRIB2 GFS file that
includes
> > PRATE:
> > > > >> > > > >
> > > > >> > > > > wgrib2 gfs_2012040900_F012.grib2 | grep PRATE
> > > > >> > > > > 199:37137213:d=2012040900 <(201)%20204-0900>:PRATE:
> > > surface:6-12
> > > > >> hour ave fcst:
> > > > >> > > > >
> > > > >> > > > > # Call regrid_data_plane using the -field option to
select
> > the
> > > > >> PRATE
> > > > >> > > > record
> > > > >> > > > >
> > > > >> > > > > /usr/local/met-6.0/bin/regrid_data_plane \
> > > > >> > > > > gfs_2012040900 <(201)%20204-0900>_F012.grib2
> gfs_2012040900
> > > > >> <(201)%20204-0900>_F012.grib2 prate.nc \
> > > > >> > > > > -field 'name="PRATE"; level="A6";'
> > > > >> > > > >
> > > > >> > > > > DEBUG 1: Reading data file:
gfs_2012040900_F012.grib2
> > > > >> > > > > DEBUG 2: Input grid: Projection: Lat/Lon Nx: 720
Ny: 361
> > > lat_ll:
> > > > >> > > -90.000
> > > > >> > > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> > > > >> > > > > DEBUG 2: Output grid: Projection: Lat/Lon Nx: 720
Ny: 361
> > > > lat_ll:
> > > > >> > > -90.000
> > > > >> > > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> > > > >> > > > > DEBUG 2: Interpolation options: method = NEAREST,
width =
> 1,
> > > > >> shape =
> > > > >> > > > > SQUARE, vld_thresh = 0.5
> > > > >> > > > > DEBUG 2: Range of input data (name="PRATE";
level="A6";)
> is
> > 0
> > > to
> > > > >> > > > 0.004075.
> > > > >> > > > > DEBUG 2: Range of regridded data (name="PRATE";
> level="A6";)
> > > is
> > > > 0
> > > > >> to
> > > > >> > > > > 0.004075.
> > > > >> > > > > DEBUG 1: Writing output file: prate.nc
> > > > >> > > > >
> > > > >> > > > > Since the input and output grids are the same, no
> > re-gridding
> > > is
> > > > >> > > actually
> > > > >> > > > > being done. You could have also used the
pcp_combine tool
> > to
> > > do
> > > > >> the
> > > > >> > > same
> > > > >> > > > > thing. But the nice thing about regrid_data_plane
is that
> > you
> > > > >> could
> > > > >> > > > > include multiple fields in the output by using the
> "-field"
> > > > >> command
> > > > >> > > line
> > > > >> > > > > option multiple times.
> > > > >> > > > >
> > > > >> > > > > Then you can edit the NetCDF output of
regrid_data_plane
> > > however
> > > > >> > you'd
> > > > >> > > > > like, and MET should be able to read that file.
> > > > >> > > > >
> > > > >> > > > > Hope that helps.
> > > > >> > > > >
> > > > >> > > > > Thanks,
> > > > >> > > > > John
> > > > >> > > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > --
> > > > >> > > > Bill Stern, Meteorologist
> > > > >> > > > Room 206
> > > > >> > > > NOAA/Geophysical Fluid Dynamics Laboratory
> > > > >> > > > Princeton University Forrestal Campus
> > > > >> > > > 201 Forrestal Road Princeton, NJ 08540-6649
> > > > >> > > > Tel: (609)452-6545
> > > > >> > > > Fax: (609)987-5063
> > > > >> > > > ------------------------------
> > > > >> > > > ------------------------------------
> > > > >> > > > Email Address: bill.stern at noaa.gov
> > > > >> > > > ------------------------------
> ------------------------------
> > > > ------
> > > > >> > > > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > > > >> > > > ------------------------------
> ------------------------------
> > > > ------
> > > > >> > > > On the World Wide Web:
http://www.gfdl.noaa.gov/bill-
> > > > >> stern-gfdl-noaa
> > > > >> > > > ------------------------------
> ------------------------------
> > > > ------
> > > > >> > > >
> > > > >> > > >
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >> >
> > > > >> > --
> > > > >> > Bill Stern, Meteorologist
> > > > >> > Room 206
> > > > >> > NOAA/Geophysical Fluid Dynamics Laboratory
> > > > >> > Princeton University Forrestal Campus
> > > > >> > 201 Forrestal Road Princeton, NJ 08540-6649
> > > > >> > Tel: (609)452-6545
> > > > >> > Fax: (609)987-5063
> > > > >> > ------------------------------
> > > > >> > ------------------------------------
> > > > >> > Email Address: bill.stern at noaa.gov
> > > > >> >
------------------------------------------------------------
> > ------
> > > > >> > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > > > >> >
------------------------------------------------------------
> > ------
> > > > >> > On the World Wide Web: http://www.gfdl.noaa.gov/bill-
> > > stern-gfdl-noaa
> > > > >> >
------------------------------------------------------------
> > ------
> > > > >> >
> > > > >> >
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > > --
> > > > > Bill Stern, Meteorologist
> > > > > Room 206
> > > > > NOAA/Geophysical Fluid Dynamics Laboratory
> > > > > Princeton University Forrestal Campus
> > > > > 201 Forrestal Road Princeton, NJ 08540-6649
> > > > > Tel: (609)452-6545
> > > > > Fax: (609)987-5063
> > > > > ------------------------------
> > > > > ------------------------------------
> > > > > Email Address: bill.stern at noaa.gov
> > > > >
------------------------------------------------------------------
> > > > > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > > > >
------------------------------------------------------------------
> > > > > On the World Wide Web: http://www.gfdl.noaa.gov/bill-
> > stern-gfdl-noaa
> > > > >
------------------------------------------------------------------
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Bill Stern, Meteorologist
> > > Room 206
> > > NOAA/Geophysical Fluid Dynamics Laboratory
> > > Princeton University Forrestal Campus
> > > 201 Forrestal Road Princeton, NJ 08540-6649
> > > Tel: (609)452-6545
> > > Fax: (609)987-5063
> > > ------------------------------
> > > ------------------------------------
> > > Email Address: bill.stern at noaa.gov
> > >
------------------------------------------------------------------
> > > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > >
------------------------------------------------------------------
> > > On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-
gfdl-noaa
> > >
------------------------------------------------------------------
> > >
> > >
> >
> >
>
>
> --
> Shannon Rees
> Meteorologist
> Engility
> Geophysical Fluid Dynamics Lab
> Princeton University Forrestal Campus
> 201 Forrestal Rd Princeton, NJ
> 609-452-5384
>
>
------------------------------------------------
Subject: problem reading netdcf file
From: bill.stern at noaa.gov
Time: Sat Jul 22 12:01:40 2017
Thank you John.
Bill
On Fri, Jul 21, 2017 at 4:35 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Bill and Shannon,
>
> FYI, I just posted the bugfix for met-6.0:
> http://www.dtcenter.org/met/users/support/known_issues/METv6.0/
>
> Have a good weekend.
>
> John
>
> On Thu, Jul 20, 2017 at 10:57 AM, Shannon Rees - NOAA Affiliate via
RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134 >
> >
> > John,
> >
> > Great! Thanks for the clarification. We will switch to 6.0 once
you've
> > posted the bug fix.
> >
> > Shannon
> >
> > On Thu, Jul 20, 2017 at 12:54 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Shannon,
> > >
> > > Ah yes, good point. I see that we posted that met-5.2 bugfix on
> 1/26/17:
> > > http://www.dtcenter.org/met/users/support/known_issues/
> > > METv5.2/index.php
> > >
> > > I can't remember all the details... so I just ran my test using
the
> > latest
> > > 5.2 bugfix branch and the latest 6.0 bugfix branch. Indeed, 6.0
took
> 5.2
> > > seconds while 5.2 took 17.2 seconds. So yes, I would expect 6.0
to be
> > > faster.
> > >
> > > Bill,
> > >
> > > Unfortunately yes, this is a bug in the library code and would
affect
> all
> > > the tool (plot_data_plane and grid_stat included).
> > >
> > > I'll let you know when we have a fix ready for 6.0.
> > >
> > > Thanks,
> > > John
> > >
> > > On Thu, Jul 20, 2017 at 10:25 AM, bill.stern at noaa.gov via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134
>
> > > >
> > > > John,
> > > >
> > > > Is that orientation bug just in the plotting or would it also
affect
> > the
> > > > grid_stat tool?
> > > > Thanks,
> > > > Bill
> > > >
> > > >
> > > >
> > > > On Thu, Jul 20, 2017 at 12:15 PM, John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > > Bill,
> > > > >
> > > > > Yes, you're right. Setting "conventions = "CF-1.0" *should*
tell
> MET
> > > > that
> > > > > the NetCDF file is CF-compliant. Unfortunately, there are
some
> > > wrinkles
> > > > in
> > > > > the logic in 5.2 that we've ironed out in 6.0 :) And that's
why
> > > setting
> > > > > "file_type = NETCDF_NCCF;" is still needed in 5.2.
> > > > >
> > > > > However, the incorrect orientation of your data in 6.0
really is a
> > bug.
> > > > > And I've asked the developer who worked on that logic to
find and
> fix
> > > the
> > > > > problem. Once we have a fix, we'll post it to the website
and let
> > you
> > > > > know.
> > > > >
> > > > > Additionally, version 6.0 contains some major run time
> improvements,
> > > > mostly
> > > > > for Grid-Stat. The speed of reading/writing NetCDF is
improved,
> but
> > > more
> > > > > importantly the allocation of memory is dramatically
improved. For
> > > small
> > > > > numbers of matched pairs, it's not really noticeable. But
for
> large
> > > > > numbers, the improvements are significant. I ran Grid-Stat
on your
> > > data
> > > > > (4,718,592 matched pairs) using both 5.2 and 6.0 and just
computing
> > > > scalar
> > > > > partial sums. On my machine 5.2 took 18.5 seconds while 6.0
took
> > only
> > > > 5.5
> > > > > seconds.
> > > > >
> > > > > So yes, I would recommend using met-6.0.
> > > > >
> > > > > Thanks,
> > > > > John
> > > > >
> > > > > On Thu, Jul 20, 2017 at 7:38 AM, Bill Stern - NOAA Affiliate
<
> > > > > bill.stern at noaa.gov> wrote:
> > > > >
> > > > > > Hi John,
> > > > > >
> > > > > > Just another related question. I am somewhat confused
regarding
> > how
> > > > MET
> > > > > > is interpreting the file as being "CF compliant". I
thought by
> > > setting
> > > > > the
> > > > > > "conventions" attribute to: "CF-1.0", MET will interpret
the
> netcdf
> > > > file
> > > > > as
> > > > > > being CF compliant, but you seemed to have to tell the MET
> > > > > > "plot_data_plane" tool to consider the file CF compliant
by
> > > specifying
> > > > > via
> > > > > > the option "file_type=NETCDF_NCCF"? Can you enlighten me?
> > > > > >
> > > > > > Thanks,
> > > > > > Bill
> > > > > >
> > > > > > On Wed, Jul 19, 2017 at 7:05 PM, John Halley Gotway via RT
<
> > > > > > met_help at ucar.edu> wrote:
> > > > > >
> > > > > >> Bill,
> > > > > >>
> > > > > >> Sorry for the delay in responding.
> > > > > >>
> > > > > >> I logged on to the ftp site and grabbed your sample file:
> > > > > PRATEsfc6all.nc
> > > > > >>
> > > > > >> I was able to replicate the error message you saw from
met-5.2:
> > > > > >> ERROR : plot_data_plane -> file "PRATEsfc6all.nc" not a
valid
> > data
> > > > file
> > > > > >>
> > > > > >> If you instruct MET to interpret this file as a CF-
compliant
> > NetCDF
> > > > > file,
> > > > > >> then it runs without error, but the data is packed upside
down
> > (see
> > > > > >> attached prate_met-5.2.png):
> > > > > >>
> > > > > >> met-5.2/bin/plot_data_plane \
> > > > > >> PRATEsfc6all.nc prate_met-5.2.ps \
> > > > > >> 'name="PRATEsfc"; level="(4,*,*)";
file_type=NETCDF_NCCF;'
> > > > > >>
> > > > > >> In met-6.0, we fixed this issue and turned the world back
right
> > side
> > > > up.
> > > > > >> And in 6.0, you don't even need to tell it that it's CF
> compliant:
> > > > > >>
> > > > > >> met-6.0/bin/plot_data_plane \
> > > > > >> PRATEsfc6all.nc prate_met-6.0.ps \
> > > > > >> 'name="PRATEsfc"; level="(4,*,*)";'
> > > > > >>
> > > > > >> So if possible, I'd suggest using met-6.0. Hope that
helps.
> > > > > >>
> > > > > >> Thanks,
> > > > > >> John
> > > > > >>
> > > > > >> On Sat, Jul 15, 2017 at 11:03 AM, bill.stern at noaa.gov via
RT <
> > > > > >> met_help at ucar.edu> wrote:
> > > > > >>
> > > > > >> >
> > > > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81134
> >
> > > > > >> >
> > > > > >> > John and others,
> > > > > >> >
> > > > > >> > I am now encountering a problem with MET's inability to
read
> GFS
> > > > > >> forecast
> > > > > >> > files that were processed to netcdf. There are more
than 75
> > > > forecast
> > > > > >> dates
> > > > > >> > each with 40 forecast time levels. It would be a very
time
> > > > consuming
> > > > > >> task
> > > > > >> > to return to the original GRIB files and re-process
each time
> > > level
> > > > > with
> > > > > >> > MET regrid_data_plane tool. So, I would like to find a
way to
> > > modify
> > > > > the
> > > > > >> > existing netcdf files so they will be acceptable to
MET.
> > > > > >> >
> > > > > >> > Here is the error I am encountering:
> > > > > >> > /home/Shannon.Rees/met-5.2_orig/met-
5.2/src/tools/core/grid_
> > > > > >> stat/grid_stat
> > > > > >> > /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc
> > > > > >> > /vftmp/Bill.Stern/pid43698/GFS_native/ST4.2015012300
> > > > > <(201)%20501-2300>
> > > > > >> .06h
> > > > > >> > /work/s4m/MET5.2/scripts/Gridstat/config/
> GridStatConfig_precip
> > > > > -outdir
> > > > > >> >
/work/Bill.Stern/NGGPS/MET5.2/output/GFS_native/20150116.
> > > > > >> > 00Z/grid_stat//PRATEsfc/6hr/
> > > > > >> > -v 2
> > > > > >> > DEBUG 1: Default Config File:
> > > > > >> > /home/Shannon.Rees/met-5.2_orig/met-
5.2/share/met/config/
> > > > > >> > GridStatConfig_default
> > > > > >> > DEBUG 1: User Config File:
> > > > > >> > /work/s4m/MET5.2/scripts/Gridstat/config/
> GridStatConfig_precip
> > > > > >> > ERROR :
> > > > > >> > ERROR : Trouble reading forecast file
> > > > > >> > "/vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
> > > > > >> >
> > > > > >> > I have attached the output from "ncdump -c
> > > > > >> > /vftmp/Bill.Stern/pid43698/GFS_native/PRATEsfc6all.nc"
> > > > > >> >
> > > > > >> > The full file can be obtained from ftp.gfdl.noaa.gov
> > > > > >> > cd /pub/wfs
> > > > > >> > get PRATEsfc6all.nc
> > > > > >> >
> > > > > >> > Thank you,
> > > > > >> > Bill
> > > > > >> >
> > > > > >> >
> > > > > >> > On Mon, Jul 10, 2017 at 2:27 PM, John Halley Gotway via
RT <
> > > > > >> > met_help at ucar.edu> wrote:
> > > > > >> >
> > > > > >> > > Bill,
> > > > > >> > >
> > > > > >> > > Ah, I understand. The regrid_data_plane tool is
designed to
> > > read
> > > > > >> exactly
> > > > > >> > > one 2D data field for each "-field" entry you specify
on the
> > > > command
> > > > > >> > line.
> > > > > >> > > When you ran it on a file containing 21 times, you
probably
> > got
> > > a
> > > > > >> warning
> > > > > >> > > about "multiple matching fields". By default, it'll
just
> use
> > > the
> > > > > >> first
> > > > > >> > > match found.
> > > > > >> > >
> > > > > >> > > You can include additional timing information in the
> "-field"
> > > > entry
> > > > > to
> > > > > >> > > specify which of the 21 times you actually want.
Here's an
> > > > excerpt
> > > > > >> from
> > > > > >> > > the met-6.0/data/config/README file about this:
> > > > > >> > >
> > > > > >> > > // - The "init_time" entry specifies the
initialization
> time
> > > in
> > > > > >> > > YYYYMMDD[_HH[MMSS]]
> > > > > >> > > // format. This entry can be included in the
"fcst"
> entry
> > > as
> > > > > >> shown
> > > > > >> > > below or
> > > > > >> > > // included in the "field" entry if the user
would like
> to
> > > use
> > > > > >> > > different
> > > > > >> > > // initialization times for different fields.
> > > > > >> > > //
> > > > > >> > > // - The "valid_time" entry specifies the valid
time in
> > > > > >> > > YYYYMMDD[_HH[MMSS]]
> > > > > >> > > // format. This entry can be included in the
"fcst"
> entry
> > > as
> > > > > >> shown
> > > > > >> > > below or
> > > > > >> > > // included in the "field" entry if the user
would like
> to
> > > use
> > > > > >> > > different
> > > > > >> > > // valid times for different fields.
> > > > > >> > > //
> > > > > >> > > // - The "lead_time" entry specifies the lead time
in
> > HH[MMSS]
> > > > > >> > > // format. This entry can be included in the
"fcst"
> entry
> > > as
> > > > > >> shown
> > > > > >> > > below or
> > > > > >> > > // included in the "field" entry if the user
would like
> to
> > > use
> > > > > >> > > different
> > > > > >> > > // lead times for different fields.
> > > > > >> > >
> > > > > >> > > So you could try running adding the "valid_time":
> > > > > >> > >
> > > > > >> > > /usr/local/met-6.0/bin/regrid_data_plane \
> > > > > >> > > gfs_2012040900_F012.grib2 gfs_2012040900
> > > > > <(201)%20204-0900>_F012.grib2
> > > > > >> prate.nc \
> > > > > >> > > -field 'name="PRATE"; level="A6";
> > valid_time="20120409_120000";'
> > > > > >> > >
> > > > > >> > > Technically, you could run regrid_data_plane once on
each
> > input
> > > > > file,
> > > > > >> > pass
> > > > > >> > > in 21 "-field" settings, and write a single output
file.
> But
> > > > you'll
> > > > > >> get
> > > > > >> > an
> > > > > >> > > error because it'll try to write the same NetCDF
variable
> name
> > > > > >> multiple
> > > > > >> > > times. You could get around that by using the "-
name"
> option
> > to
> > > > > >> passing
> > > > > >> > in
> > > > > >> > > 21 unique output variables names... but that's a
whole lot
> of
> > > > > details.
> > > > > >> > >
> > > > > >> > > Instead, I'd suggest running regrid_data_plane once
for each
> > > > > 3-hourly
> > > > > >> > > output time and specify the "valid_time" currently
being
> > > > > processed. I
> > > > > >> > > think that logic would be cleaner.
> > > > > >> > >
> > > > > >> > > Hope that helps.
> > > > > >> > >
> > > > > >> > > Thanks,
> > > > > >> > > John
> > > > > >> > >
> > > > > >> > > On Mon, Jul 10, 2017 at 7:33 AM, bill.stern at noaa.gov
via
> RT <
> > > > > >> > > met_help at ucar.edu> wrote:
> > > > > >> > >
> > > > > >> > > >
> > > > > >> > > > <URL: https://rt.rap.ucar.edu/rt/
> > Ticket/Display.html?id=81134
> > > >
> > > > > >> > > >
> > > > > >> > > > Hi John,
> > > > > >> > > >
> > > > > >> > > > I have followed your example of applying
regrid_data_plane
> > for
> > > > > >> > creating a
> > > > > >> > > > netcdf file from a grib2. The command below does
create a
> > > > netcdf,
> > > > > >> but
> > > > > >> > I
> > > > > >> > > am
> > > > > >> > > > only seem to be getting a single time level on the
netcdf
> > > file,
> > > > > >> while
> > > > > >> > the
> > > > > >> > > > grib2 file has 21 time levels. Here is my
> regrid_data_plane
> > > > > >> command:
> > > > > >> > > >
> > > > > >> > > > regrid_data_plane
nam.2017051500.conusnest.hires.tm00.
> grib2
> > > > > >> > > > nam.2017051500.conusnest.hires.tm00.grib2
nam.2017051500
> > > > > >> > .conusnest.APCP.
> > > > > >> > > nc
> > > > > >> > > > -field 'name = "APCP";level="A3";'
> > > > > >> > > >
> > > > > >> > > > What am I missing?
> > > > > >> > > >
> > > > > >> > > > Thanks,
> > > > > >> > > > Bill
> > > > > >> > > >
> > > > > >> > > > On Fri, Jul 7, 2017 at 12:44 PM, John Halley Gotway
via
> RT <
> > > > > >> > > > met_help at ucar.edu> wrote:
> > > > > >> > > >
> > > > > >> > > > > Hi Bill,
> > > > > >> > > > >
> > > > > >> > > > > I moved your question over into the MET-Help
support
> > > ticketing
> > > > > >> > system.
> > > > > >> > > > >
> > > > > >> > > > > I see that you're having trouble processing the
NetCDF
> > > output
> > > > of
> > > > > >> the
> > > > > >> > > > > ncl_convert2nc utility in MET. MET is only set
up to
> > read a
> > > > > >> handful
> > > > > >> > of
> > > > > >> > > > > NetCDF file formats, and unfortunately, the
output of
> > > > > >> ncl_convert2nc
> > > > > >> > is
> > > > > >> > > > not
> > > > > >> > > > > one of them. The 3 NetCDF flavors that MET reads
are
> > > > > CF-complaint
> > > > > >> > > > > (climate-forecast convention) files, the output
of the
> > > > > wrf_interp
> > > > > >> > > > utility,
> > > > > >> > > > > and the internal NetCDF format written by the MET
tools
> > > > > >> themselves.
> > > > > >> > > > >
> > > > > >> > > > > I understand that you'd like to do additional
processing
> > on
> > > > the
> > > > > >> > > > > precipitation rate data... and NetCDF is much
easier to
> > work
> > > > > with
> > > > > >> > than
> > > > > >> > > > > GRIB2.
> > > > > >> > > > >
> > > > > >> > > > > Rather than using ncl_convert2nc to reformat the
GRIB2
> > data,
> > > > > let's
> > > > > >> > use
> > > > > >> > > > the
> > > > > >> > > > > MET regrid_data_plane tool instead. I'll
demonstrate
> this
> > > > > below.
> > > > > >> > > > >
> > > > > >> > > > > # I'll start with a sample GRIB2 GFS file that
includes
> > > PRATE:
> > > > > >> > > > >
> > > > > >> > > > > wgrib2 gfs_2012040900_F012.grib2 | grep PRATE
> > > > > >> > > > > 199:37137213:d=2012040900 <(201)%20204-
0900>:PRATE:
> > > > surface:6-12
> > > > > >> hour ave fcst:
> > > > > >> > > > >
> > > > > >> > > > > # Call regrid_data_plane using the -field option
to
> select
> > > the
> > > > > >> PRATE
> > > > > >> > > > record
> > > > > >> > > > >
> > > > > >> > > > > /usr/local/met-6.0/bin/regrid_data_plane \
> > > > > >> > > > > gfs_2012040900 <(201)%20204-0900>_F012.grib2
> > gfs_2012040900
> > > > > >> <(201)%20204-0900>_F012.grib2 prate.nc \
> > > > > >> > > > > -field 'name="PRATE"; level="A6";'
> > > > > >> > > > >
> > > > > >> > > > > DEBUG 1: Reading data file:
gfs_2012040900_F012.grib2
> > > > > >> > > > > DEBUG 2: Input grid: Projection: Lat/Lon Nx: 720
Ny: 361
> > > > lat_ll:
> > > > > >> > > -90.000
> > > > > >> > > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> > > > > >> > > > > DEBUG 2: Output grid: Projection: Lat/Lon Nx: 720
Ny:
> 361
> > > > > lat_ll:
> > > > > >> > > -90.000
> > > > > >> > > > > lon_ll: -0.000 delta_lat: 0.500 delta_lon: 0.500
> > > > > >> > > > > DEBUG 2: Interpolation options: method = NEAREST,
width
> =
> > 1,
> > > > > >> shape =
> > > > > >> > > > > SQUARE, vld_thresh = 0.5
> > > > > >> > > > > DEBUG 2: Range of input data (name="PRATE";
level="A6";)
> > is
> > > 0
> > > > to
> > > > > >> > > > 0.004075.
> > > > > >> > > > > DEBUG 2: Range of regridded data (name="PRATE";
> > level="A6";)
> > > > is
> > > > > 0
> > > > > >> to
> > > > > >> > > > > 0.004075.
> > > > > >> > > > > DEBUG 1: Writing output file: prate.nc
> > > > > >> > > > >
> > > > > >> > > > > Since the input and output grids are the same, no
> > > re-gridding
> > > > is
> > > > > >> > > actually
> > > > > >> > > > > being done. You could have also used the
pcp_combine
> tool
> > > to
> > > > do
> > > > > >> the
> > > > > >> > > same
> > > > > >> > > > > thing. But the nice thing about
regrid_data_plane is
> that
> > > you
> > > > > >> could
> > > > > >> > > > > include multiple fields in the output by using
the
> > "-field"
> > > > > >> command
> > > > > >> > > line
> > > > > >> > > > > option multiple times.
> > > > > >> > > > >
> > > > > >> > > > > Then you can edit the NetCDF output of
regrid_data_plane
> > > > however
> > > > > >> > you'd
> > > > > >> > > > > like, and MET should be able to read that file.
> > > > > >> > > > >
> > > > > >> > > > > Hope that helps.
> > > > > >> > > > >
> > > > > >> > > > > Thanks,
> > > > > >> > > > > John
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > --
> > > > > >> > > > Bill Stern, Meteorologist
> > > > > >> > > > Room 206
> > > > > >> > > > NOAA/Geophysical Fluid Dynamics Laboratory
> > > > > >> > > > Princeton University Forrestal Campus
> > > > > >> > > > 201 Forrestal Road Princeton, NJ 08540-6649
> > > > > >> > > > Tel: (609)452-6545
> > > > > >> > > > Fax: (609)987-5063
> > > > > >> > > > ------------------------------
> > > > > >> > > > ------------------------------------
> > > > > >> > > > Email Address: bill.stern at noaa.gov
> > > > > >> > > > ------------------------------
> > ------------------------------
> > > > > ------
> > > > > >> > > > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > > > > >> > > > ------------------------------
> > ------------------------------
> > > > > ------
> > > > > >> > > > On the World Wide Web:
http://www.gfdl.noaa.gov/bill-
> > > > > >> stern-gfdl-noaa
> > > > > >> > > > ------------------------------
> > ------------------------------
> > > > > ------
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> >
> > > > > >> >
> > > > > >> > --
> > > > > >> > Bill Stern, Meteorologist
> > > > > >> > Room 206
> > > > > >> > NOAA/Geophysical Fluid Dynamics Laboratory
> > > > > >> > Princeton University Forrestal Campus
> > > > > >> > 201 Forrestal Road Princeton, NJ 08540-6649
> > > > > >> > Tel: (609)452-6545
> > > > > >> > Fax: (609)987-5063
> > > > > >> > ------------------------------
> > > > > >> > ------------------------------------
> > > > > >> > Email Address: bill.stern at noaa.gov
> > > > > >> >
------------------------------------------------------------
> > > ------
> > > > > >> > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > > > > >> >
------------------------------------------------------------
> > > ------
> > > > > >> > On the World Wide Web: http://www.gfdl.noaa.gov/bill-
> > > > stern-gfdl-noaa
> > > > > >> >
------------------------------------------------------------
> > > ------
> > > > > >> >
> > > > > >> >
> > > > > >>
> > > > > >>
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Bill Stern, Meteorologist
> > > > > > Room 206
> > > > > > NOAA/Geophysical Fluid Dynamics Laboratory
> > > > > > Princeton University Forrestal Campus
> > > > > > 201 Forrestal Road Princeton, NJ 08540-6649
> > > > > > Tel: (609)452-6545
> > > > > > Fax: (609)987-5063
> > > > > > ------------------------------
> > > > > > ------------------------------------
> > > > > > Email Address: bill.stern at noaa.gov
> > > > > >
------------------------------------------------------------
> ------
> > > > > > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > > > > >
------------------------------------------------------------
> ------
> > > > > > On the World Wide Web: http://www.gfdl.noaa.gov/bill-
> > > stern-gfdl-noaa
> > > > > >
------------------------------------------------------------
> ------
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Bill Stern, Meteorologist
> > > > Room 206
> > > > NOAA/Geophysical Fluid Dynamics Laboratory
> > > > Princeton University Forrestal Campus
> > > > 201 Forrestal Road Princeton, NJ 08540-6649
> > > > Tel: (609)452-6545
> > > > Fax: (609)987-5063
> > > > ------------------------------
> > > > ------------------------------------
> > > > Email Address: bill.stern at noaa.gov
> > > >
------------------------------------------------------------------
> > > > Anonymous ftp Address: ftp.gfdl.noaa.gov
> > > >
------------------------------------------------------------------
> > > > On the World Wide Web: http://www.gfdl.noaa.gov/bill-
> stern-gfdl-noaa
> > > >
------------------------------------------------------------------
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Shannon Rees
> > Meteorologist
> > Engility
> > Geophysical Fluid Dynamics Lab
> > Princeton University Forrestal Campus
> > 201 Forrestal Rd Princeton, NJ
> > 609-452-5384
> >
> >
>
>
--
Bill Stern, Meteorologist
Room 206
NOAA/Geophysical Fluid Dynamics Laboratory
Princeton University Forrestal Campus
201 Forrestal Road Princeton, NJ 08540-6649
Tel: (609)452-6545
Fax: (609)987-5063
------------------------------
------------------------------------
Email Address: bill.stern at noaa.gov
------------------------------------------------------------------
Anonymous ftp Address: ftp.gfdl.noaa.gov
------------------------------------------------------------------
On the World Wide Web: http://www.gfdl.noaa.gov/bill-stern-gfdl-noaa
------------------------------------------------------------------
------------------------------------------------
More information about the Met_help
mailing list