[Met_help] [rt.rap.ucar.edu #57358] History for MET netcdf to grib1 converter yet?
Paul Oldenburg via RT
met_help at ucar.edu
Thu Aug 23 07:50:14 MDT 2012
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi MET Help,
In the more recent versions of MET (i.e., v3.1 and v4) is there a netcdf
to grib1 converter? I have a netcdf file with precipitation data (see
attached) that was outputted from radar software but it is not the
netcdf version that MET wants. What is the best way to get this into
the netcdf form or grib1 format that MET will read? (Note: This netcdf
format is not output from WRF so the CDO conversion is not applicable
and my NCL guru here at NOAA doesn't know of an NCL command that can do
the conversion.)
Thanks for your time!
Ellen Sukovich
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #57358] MET netcdf to grib1 converter yet?
From: Paul Oldenburg
Time: Tue Jul 10 10:55:59 2012
Ellen,
To our knowledge, converting from NetCDF to GRIB is an unsolved
problem. I think the easiest route would be to change
the structure of your precip NetCDF so that MET can read it - to a
format like the output of the pcp_combine tool. I
will try to whip up a script to do this for the one file you sent me.
Are you going to need this conversion performed
on more than just this one file? If so, I will try to make it more
user-friendly so you can use it.
Paul
On 07/10/2012 10:34 AM, Ellen.Sukovich at noaa.gov via RT wrote:
>
> Tue Jul 10 10:34:38 2012: Request 57358 was acted upon.
> Transaction: Ticket created by Ellen.Sukovich at noaa.gov
> Queue: met_help
> Subject: MET netcdf to grib1 converter yet?
> Owner: Nobody
> Requestors: Ellen.Sukovich at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>
>
> Hi MET Help,
>
> In the more recent versions of MET (i.e., v3.1 and v4) is there a
netcdf
> to grib1 converter? I have a netcdf file with precipitation data
(see
> attached) that was outputted from radar software but it is not the
> netcdf version that MET wants. What is the best way to get this
into
> the netcdf form or grib1 format that MET will read? (Note: This
netcdf
> format is not output from WRF so the CDO conversion is not
applicable
> and my NCL guru here at NOAA doesn't know of an NCL command that can
do
> the conversion.)
>
> Thanks for your time!
> Ellen Sukovich
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #57358] MET netcdf to grib1 converter yet?
From: Ellen.Sukovich at noaa.gov
Time: Tue Jul 10 11:01:00 2012
Hi Paul,
Thanks for the quick response! I was afraid the conversion wasn't
going
to be readily available. Eventually, I will have many (many!) files
like the one I sent you, however the colleague who is outputting the
data can probably put it into the correct format if he knows what the
MET netcdf format is. If you could show us how to make the correct
MET
netcdf format for the file I sent you, we can probably replicate it
for
future files.
Thanks again for your help!
Ellen
On 7/10/2012 10:55 AM, Paul Oldenburg via RT wrote:
> Ellen,
>
> To our knowledge, converting from NetCDF to GRIB is an unsolved
problem. I think the easiest route would be to change
> the structure of your precip NetCDF so that MET can read it - to a
format like the output of the pcp_combine tool. I
> will try to whip up a script to do this for the one file you sent
me. Are you going to need this conversion performed
> on more than just this one file? If so, I will try to make it more
user-friendly so you can use it.
>
> Paul
>
>
> On 07/10/2012 10:34 AM, Ellen.Sukovich at noaa.gov via RT wrote:
>> Tue Jul 10 10:34:38 2012: Request 57358 was acted upon.
>> Transaction: Ticket created by Ellen.Sukovich at noaa.gov
>> Queue: met_help
>> Subject: MET netcdf to grib1 converter yet?
>> Owner: Nobody
>> Requestors: Ellen.Sukovich at noaa.gov
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>>
>>
>> Hi MET Help,
>>
>> In the more recent versions of MET (i.e., v3.1 and v4) is there a
netcdf
>> to grib1 converter? I have a netcdf file with precipitation data
(see
>> attached) that was outputted from radar software but it is not the
>> netcdf version that MET wants. What is the best way to get this
into
>> the netcdf form or grib1 format that MET will read? (Note: This
netcdf
>> format is not output from WRF so the CDO conversion is not
applicable
>> and my NCL guru here at NOAA doesn't know of an NCL command that
can do
>> the conversion.)
>>
>> Thanks for your time!
>> Ellen Sukovich
>>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #57358] MET netcdf to grib1 converter yet?
From: Paul Oldenburg
Time: Tue Jul 10 13:14:05 2012
Ellen,
If your data dude can put it into the format shown below, MET should
be able to read it. I will probably hold off on
the conversion script unless you would still like me to put it
together. The format is really just a matter of having
certain attributes present with specific names and values. I also
showed how I regridded (to lat/lon projection) and
converted a test file included in the MET tarball file from GRIB to
MET NetCDF. If you have any questions about this
format, please let us know.
Paul
[pgoldenb at orval 20120710.sukovich]$ copygb.exe \
-xg 110 \
$MET_BASE/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212 \
wrfprs_ruc13_12.tm00_G212.grib
[pgoldenb at orval 20120710.sukovich]$ $MET_BASE/bin/pcp_combine -add \
wrfprs_ruc13_12.tm00_G212.grib 12 \
wrfprs_ruc13_12.tm00_G212.nc
DEBUG 1: Reading input file: wrfprs_ruc13_12.tm00_G212.grib
DEBUG 1: Writing output file: wrfprs_ruc13_12.tm00_G212.nc
[pgoldenb at orval 20120710.sukovich]$ ncdump -h
wrfprs_ruc13_12.tm00_G212.nc
netcdf wrfprs_ruc13_12.tm00_G212 {
dimensions:
lat = 224 ;
lon = 464 ;
variables:
float lat(lat, lon) ;
lat:long_name = "latitude" ;
lat:units = "degrees_north" ;
lat:standard_name = "latitude" ;
float lon(lat, lon) ;
lon:long_name = "longitude" ;
lon:units = "degrees_east" ;
lon:standard_name = "longitude" ;
float APCP_12(lat, lon) ;
APCP_12:name = "APCP_12" ;
APCP_12:long_name = "Total precipitation" ;
APCP_12:level = "A12" ;
APCP_12:units = "kg/m^2" ;
APCP_12:_FillValue = -9999.f ;
APCP_12:init_time = "20050807_000000" ;
APCP_12:init_time_ut = 1123372800 ;
APCP_12:valid_time = "20050807_120000" ;
APCP_12:valid_time_ut = 1123416000 ;
APCP_12:accum_time = "120000" ;
APCP_12:accum_time_sec = 43200 ;
// global attributes:
:FileOrigins = "File wrfprs_ruc13_12.tm00_G212.nc
generated 20120710_171301 UTC on host orval by the
MET pcp_combine tool" ;
:MET_version = "V4.0" ;
:MET_tool = "pcp_combine" ;
:RunCommand = "Addition: 1 files." ;
:Projection = "LatLon" ;
:lat_ll = "25.063000 degrees_north" ;
:lon_ll = "-124.938000 degrees_east" ;
:delta_lat = "0.125000 degrees" ;
:delta_lon = "0.125000 degrees" ;
:Nlat = "224 grid_points" ;
:Nlon = "464 grid_points" ;
}
On 07/10/2012 11:01 AM, Ellen.Sukovich at noaa.gov via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>
> Hi Paul,
>
> Thanks for the quick response! I was afraid the conversion wasn't
going
> to be readily available. Eventually, I will have many (many!) files
> like the one I sent you, however the colleague who is outputting the
> data can probably put it into the correct format if he knows what
the
> MET netcdf format is. If you could show us how to make the correct
MET
> netcdf format for the file I sent you, we can probably replicate it
for
> future files.
>
> Thanks again for your help!
> Ellen
>
>
> On 7/10/2012 10:55 AM, Paul Oldenburg via RT wrote:
>> Ellen,
>>
>> To our knowledge, converting from NetCDF to GRIB is an unsolved
problem. I think the easiest route would be to change
>> the structure of your precip NetCDF so that MET can read it - to a
format like the output of the pcp_combine tool. I
>> will try to whip up a script to do this for the one file you sent
me. Are you going to need this conversion performed
>> on more than just this one file? If so, I will try to make it more
user-friendly so you can use it.
>>
>> Paul
>>
>>
>> On 07/10/2012 10:34 AM, Ellen.Sukovich at noaa.gov via RT wrote:
>>> Tue Jul 10 10:34:38 2012: Request 57358 was acted upon.
>>> Transaction: Ticket created by Ellen.Sukovich at noaa.gov
>>> Queue: met_help
>>> Subject: MET netcdf to grib1 converter yet?
>>> Owner: Nobody
>>> Requestors: Ellen.Sukovich at noaa.gov
>>> Status: new
>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>>>
>>>
>>> Hi MET Help,
>>>
>>> In the more recent versions of MET (i.e., v3.1 and v4) is there a
netcdf
>>> to grib1 converter? I have a netcdf file with precipitation data
(see
>>> attached) that was outputted from radar software but it is not the
>>> netcdf version that MET wants. What is the best way to get this
into
>>> the netcdf form or grib1 format that MET will read? (Note: This
netcdf
>>> format is not output from WRF so the CDO conversion is not
applicable
>>> and my NCL guru here at NOAA doesn't know of an NCL command that
can do
>>> the conversion.)
>>>
>>> Thanks for your time!
>>> Ellen Sukovich
>>>
>>
>>
>
>
------------------------------------------------
Subject: MET netcdf to grib1 converter yet?
From: Ellen.Sukovich at noaa.gov
Time: Wed Jul 11 13:32:59 2012
Hi Paul,
We tried to reconfigure the netcdf file (see attached) but cannot get
it
to work. Haonan had two issues he wasn't sure about (see below). Any
suggestions? Note: Our data is precipitation data from radar QPE data
for a one hour time period.
Thanks again for your help on this!
Ellen
-------- Original Message --------
Subject: Re: Re: [rt.rap.ucar.edu #57358] MET netcdf to grib1
converter
yet?
Date: Tue, 10 Jul 2012 16:41:51 -0600
From: Haonan Chen <haonan.chen at noaa.gov>
To: Ellen Sukovich <ellen.sukovich at noaa.gov>
Hi Ellen
A sample file is attached. Could you please try to read it? I tried to
change all the field names to make sure it's readable by MET software.
However, there are several points I should mention, which may lead to
bugs.
1. the gridding method.
It is possible that MET is using an exact rectangular Lat/Lon grid.
But
the lat/lon values in our files are converted from a rectangular HRAP
coordinates. The rectangular HRAP area is not a rectangular Lat/Lon
area
because of some reasons like earth curvature. However, I do not think
it
matters much. I can re-grid the data to an exact rectangular Lat/Lon
area if needed.
2. the rainfall accumulation field
From the field list you forwarded to me earlier, I saw the rainfall
field was in APCP12 mode (the rainfall field name is APCP12). In my
conversion, I added this field. But I do not think we are really in
this
mode. I also tried to add the property names of APCP_12 like below.
Again, I doubt that our data has different properties. For example,
the
units might not be kg/m^2. I need to resolve this problem after
getting
more information about APCP_12. But any way, hopefully you can read in
the data values now. The sample file is a gauge only result. The data
inside (named APCP_12) is actually having a units mm.
APCP_12:name = "APCP_12" ;
APCP_12:long_name = "Total precipitation" ;
APCP_12:level = "A12" ;
APCP_12:units = "kg/m^2" ;
APCP_12:_FillValue = -9999.f ;
APCP_12:init_time = "20050807_000000" ;
APCP_12:init_time_ut = 1123372800 ;
APCP_12:valid_time = "20050807_120000" ;
APCP_12:valid_time_ut = 1123416000 ;
APCP_12:accum_time = "120000" ;
APCP_12:accum_time_sec = 43200 ;
On Tue, Jul 10, 2012 at 1:20 PM, Ellen Sukovich
<ellen.sukovich at noaa.gov
<mailto:ellen.sukovich at noaa.gov>> wrote:
Hi Haonan,
Could you put your netcdf file into the format listed below? See
email below this email.
Ellen
{
dimensions:
lat = 224 ;
lon = 464 ;
variables:
float lat(lat, lon) ;
lat:long_name = "latitude" ;
lat:units = "degrees_north" ;
lat:standard_name = "latitude" ;
float lon(lat, lon) ;
lon:long_name = "longitude" ;
lon:units = "degrees_east" ;
lon:standard_name = "longitude" ;
float APCP_12(lat, lon) ;
APCP_12:name = "APCP_12" ;
APCP_12:long_name = "Total precipitation" ;
APCP_12:level = "A12" ;
APCP_12:units = "kg/m^2" ;
APCP_12:_FillValue = -9999.f ;
APCP_12:init_time = "20050807_000000" ;
APCP_12:init_time_ut = 1123372800 ;
APCP_12:valid_time = "20050807_120000" ;
APCP_12:valid_time_ut = 1123416000 ;
APCP_12:accum_time = "120000" ;
APCP_12:accum_time_sec = 43200 ;
// global attributes:
:FileOrigins = "Filewrfprs_ruc13_12.tm00_G212.nc
<http://wrfprs_ruc13_12.tm00_G212.nc> generated 20120710_171301 UTC
on host orval by the
MET pcp_combine tool" ;
:MET_version = "V4.0" ;
:MET_tool = "pcp_combine" ;
:RunCommand = "Addition: 1 files." ;
:Projection = "LatLon" ;
:lat_ll = "25.063000 degrees_north" ;
:lon_ll = "-124.938000 degrees_east" ;
:delta_lat = "0.125000 degrees" ;
:delta_lon = "0.125000 degrees" ;
:Nlat = "224 grid_points" ;
:Nlon = "464 grid_points" ;
}
-------- Original Message --------
Subject: Re: [rt.rap.ucar.edu <http://rt.rap.ucar.edu> #57358]
MET
netcdf to grib1 converter yet?
Date: Tue, 10 Jul 2012 13:14:06 -0600
From: Paul Oldenburg via RT <met_help at ucar.edu>
<mailto:met_help at ucar.edu>
Reply-To: met_help at ucar.edu <mailto:met_help at ucar.edu>
To: Ellen.Sukovich at noaa.gov <mailto:Ellen.Sukovich at noaa.gov>
CC: met_help at mailman.ucar.edu <mailto:met_help at mailman.ucar.edu>
Ellen,
If your data dude can put it into the format shown below, MET
should be able to read it. I will probably hold off on
the conversion script unless you would still like me to put it
together. The format is really just a matter of having
certain attributes present with specific names and values. I also
showed how I regridded (to lat/lon projection) and
converted a test file included in the MET tarball file from GRIB
to MET NetCDF. If you have any questions about this
format, please let us know.
Paul
[pgoldenb at orval 20120710.sukovich]$ copygb.exe \
-xg 110 \
$MET_BASE/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212
\
wrfprs_ruc13_12.tm00_G212.grib
[pgoldenb at orval 20120710.sukovich]$ $MET_BASE/bin/pcp_combine -add
\
wrfprs_ruc13_12.tm00_G212.grib 12 \
wrfprs_ruc13_12.tm00_G212.nc
<http://wrfprs_ruc13_12.tm00_G212.nc>
DEBUG 1: Reading input file: wrfprs_ruc13_12.tm00_G212.grib
DEBUG 1: Writing output file:wrfprs_ruc13_12.tm00_G212.nc
<http://wrfprs_ruc13_12.tm00_G212.nc>
[pgoldenb at orval 20120710.sukovich]$ ncdump
-hwrfprs_ruc13_12.tm00_G212.nc <http://wrfprs_ruc13_12.tm00_G212.nc>
netcdf wrfprs_ruc13_12.tm00_G212 {
dimensions:
lat = 224 ;
lon = 464 ;
variables:
float lat(lat, lon) ;
lat:long_name = "latitude" ;
lat:units = "degrees_north" ;
lat:standard_name = "latitude" ;
float lon(lat, lon) ;
lon:long_name = "longitude" ;
lon:units = "degrees_east" ;
lon:standard_name = "longitude" ;
float APCP_12(lat, lon) ;
APCP_12:name = "APCP_12" ;
APCP_12:long_name = "Total precipitation" ;
APCP_12:level = "A12" ;
APCP_12:units = "kg/m^2" ;
APCP_12:_FillValue = -9999.f ;
APCP_12:init_time = "20050807_000000" ;
APCP_12:init_time_ut = 1123372800 ;
APCP_12:valid_time = "20050807_120000" ;
APCP_12:valid_time_ut = 1123416000 ;
APCP_12:accum_time = "120000" ;
APCP_12:accum_time_sec = 43200 ;
// global attributes:
:FileOrigins = "Filewrfprs_ruc13_12.tm00_G212.nc
<http://wrfprs_ruc13_12.tm00_G212.nc> generated 20120710_171301 UTC
on host orval by the
MET pcp_combine tool" ;
:MET_version = "V4.0" ;
:MET_tool = "pcp_combine" ;
:RunCommand = "Addition: 1 files." ;
:Projection = "LatLon" ;
:lat_ll = "25.063000 degrees_north" ;
:lon_ll = "-124.938000 degrees_east" ;
:delta_lat = "0.125000 degrees" ;
:delta_lon = "0.125000 degrees" ;
:Nlat = "224 grid_points" ;
:Nlon = "464 grid_points" ;
}
On 07/10/2012 11:01 AM,Ellen.Sukovich at noaa.gov
<mailto:Ellen.Sukovich at noaa.gov> via RT wrote:
>
> <URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>
> Hi Paul,
>
> Thanks for the quick response! I was afraid the conversion
wasn't going
> to be readily available. Eventually, I will have many (many!)
files
> like the one I sent you, however the colleague who is outputting
the
> data can probably put it into the correct format if he knows
what the
> MET netcdf format is. If you could show us how to make the
correct MET
> netcdf format for the file I sent you, we can probably replicate
it for
> future files.
>
> Thanks again for your help!
> Ellen
>
>
> On 7/10/2012 10:55 AM, Paul Oldenburg via RT wrote:
>> Ellen,
>>
>> To our knowledge, converting from NetCDF to GRIB is an unsolved
problem. I think the easiest route would be to change
>> the structure of your precip NetCDF so that MET can read it -
to a format like the output of the pcp_combine tool. I
>> will try to whip up a script to do this for the one file you
sent me. Are you going to need this conversion performed
>> on more than just this one file? If so, I will try to make it
more user-friendly so you can use it.
>>
>> Paul
>>
>>
>> On 07/10/2012 10:34 AM,Ellen.Sukovich at noaa.gov
<mailto:Ellen.Sukovich at noaa.gov> via RT wrote:
>>> Tue Jul 10 10:34:38 2012: Request 57358 was acted upon.
>>> Transaction: Ticket created byEllen.Sukovich at noaa.gov
<mailto:Ellen.Sukovich at noaa.gov>
>>> Queue: met_help
>>> Subject: MET netcdf to grib1 converter yet?
>>> Owner: Nobody
>>> Requestors:Ellen.Sukovich at noaa.gov
<mailto:Ellen.Sukovich at noaa.gov>
>>> Status: new
>>> Ticket
<URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>>>
>>>
>>> Hi MET Help,
>>>
>>> In the more recent versions of MET (i.e., v3.1 and v4) is
there a netcdf
>>> to grib1 converter? I have a netcdf file with precipitation
data (see
>>> attached) that was outputted from radar software but it is not
the
>>> netcdf version that MET wants. What is the best way to get
this into
>>> the netcdf form or grib1 format that MET will read? (Note:
This netcdf
>>> format is not output from WRF so the CDO conversion is not
applicable
>>> and my NCL guru here at NOAA doesn't know of an NCL command
that can do
>>> the conversion.)
>>>
>>> Thanks for your time!
>>> Ellen Sukovich
>>>
>>
>>
>
>
------------------------------------------------
Subject: Re: Fwd: Re: Re: [rt.rap.ucar.edu #57358] MET netcdf to grib1 converter yet?
From: Paul Oldenburg
Time: Wed Jul 11 15:24:47 2012
Ellen,
1. The only thing that really matters in the NetCDF files is the grid
specification in the global attributes. I should
have mentioned that Haonan does not have to include the following
variables:
float lat(lat, lon)
float lon(lat, lon)
In this case, I think regridding to a grid with rectangular lat/lon
cells (const lat at every lon and vice-versa) is
necessary.
2. I'm not sure exactly what the question is here, but I think that
it only matters that the units match between your
model data precip and the observed data precip. So, you only have to
worry about converting to kg/m^2 if that is the
units used in your model data. Also, I think kg/m^2 and mm are
equivalent, so you might already be using those units by
a different name.
I see another problem with your attached file, the init_time_ut
attribute variable for APCP_12 must be set to the unix
time equivalent of the time in the init_time attribute. The current
value is:
APCP_12:init_time_ut = "***" ;
Also, the valid_time_ut attribute seems to be missing for APCP_12.
It looks like you guys are getting close. Let me know if you have any
more problems.
Paul
On 07/11/2012 01:32 PM, Ellen.Sukovich at noaa.gov via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>
> Hi Paul,
>
> We tried to reconfigure the netcdf file (see attached) but cannot
get it
> to work. Haonan had two issues he wasn't sure about (see below).
Any
> suggestions? Note: Our data is precipitation data from radar QPE
data
> for a one hour time period.
>
> Thanks again for your help on this!
> Ellen
>
> -------- Original Message --------
> Subject: Re: Re: [rt.rap.ucar.edu #57358] MET netcdf to grib1
converter
> yet?
> Date: Tue, 10 Jul 2012 16:41:51 -0600
> From: Haonan Chen <haonan.chen at noaa.gov>
> To: Ellen Sukovich <ellen.sukovich at noaa.gov>
>
>
>
> Hi Ellen
>
> A sample file is attached. Could you please try to read it? I tried
to
> change all the field names to make sure it's readable by MET
software.
> However, there are several points I should mention, which may lead
to bugs.
>
> 1. the gridding method.
> It is possible that MET is using an exact rectangular Lat/Lon grid.
But
> the lat/lon values in our files are converted from a rectangular
HRAP
> coordinates. The rectangular HRAP area is not a rectangular Lat/Lon
area
> because of some reasons like earth curvature. However, I do not
think it
> matters much. I can re-grid the data to an exact rectangular Lat/Lon
> area if needed.
>
> 2. the rainfall accumulation field
> From the field list you forwarded to me earlier, I saw the
rainfall
> field was in APCP12 mode (the rainfall field name is APCP12). In my
> conversion, I added this field. But I do not think we are really in
this
> mode. I also tried to add the property names of APCP_12 like below.
> Again, I doubt that our data has different properties. For example,
the
> units might not be kg/m^2. I need to resolve this problem after
getting
> more information about APCP_12. But any way, hopefully you can read
in
> the data values now. The sample file is a gauge only result. The
data
> inside (named APCP_12) is actually having a units mm.
>
> APCP_12:name = "APCP_12" ;
> APCP_12:long_name = "Total precipitation" ;
> APCP_12:level = "A12" ;
> APCP_12:units = "kg/m^2" ;
> APCP_12:_FillValue = -9999.f ;
> APCP_12:init_time = "20050807_000000" ;
> APCP_12:init_time_ut = 1123372800 ;
> APCP_12:valid_time = "20050807_120000" ;
> APCP_12:valid_time_ut = 1123416000 ;
> APCP_12:accum_time = "120000" ;
> APCP_12:accum_time_sec = 43200 ;
>
>
>
>
> On Tue, Jul 10, 2012 at 1:20 PM, Ellen Sukovich
<ellen.sukovich at noaa.gov
> <mailto:ellen.sukovich at noaa.gov>> wrote:
>
> Hi Haonan,
>
> Could you put your netcdf file into the format listed below?
See
> email below this email.
>
> Ellen
>
> {
> dimensions:
> lat = 224 ;
> lon = 464 ;
> variables:
> float lat(lat, lon) ;
> lat:long_name = "latitude" ;
> lat:units = "degrees_north" ;
> lat:standard_name = "latitude" ;
> float lon(lat, lon) ;
> lon:long_name = "longitude" ;
> lon:units = "degrees_east" ;
> lon:standard_name = "longitude" ;
> float APCP_12(lat, lon) ;
> APCP_12:name = "APCP_12" ;
> APCP_12:long_name = "Total precipitation" ;
> APCP_12:level = "A12" ;
> APCP_12:units = "kg/m^2" ;
> APCP_12:_FillValue = -9999.f ;
> APCP_12:init_time = "20050807_000000" ;
> APCP_12:init_time_ut = 1123372800 ;
> APCP_12:valid_time = "20050807_120000" ;
> APCP_12:valid_time_ut = 1123416000 ;
> APCP_12:accum_time = "120000" ;
> APCP_12:accum_time_sec = 43200 ;
>
> // global attributes:
> :FileOrigins =
"Filewrfprs_ruc13_12.tm00_G212.nc
<http://wrfprs_ruc13_12.tm00_G212.nc> generated 20120710_171301 UTC
on host orval by the
> MET pcp_combine tool" ;
> :MET_version = "V4.0" ;
> :MET_tool = "pcp_combine" ;
> :RunCommand = "Addition: 1 files." ;
> :Projection = "LatLon" ;
> :lat_ll = "25.063000 degrees_north" ;
> :lon_ll = "-124.938000 degrees_east" ;
> :delta_lat = "0.125000 degrees" ;
> :delta_lon = "0.125000 degrees" ;
> :Nlat = "224 grid_points" ;
> :Nlon = "464 grid_points" ;
> }
>
>
> -------- Original Message --------
> Subject: Re: [rt.rap.ucar.edu <http://rt.rap.ucar.edu> #57358]
MET
> netcdf to grib1 converter yet?
> Date: Tue, 10 Jul 2012 13:14:06 -0600
> From: Paul Oldenburg via RT <met_help at ucar.edu>
> <mailto:met_help at ucar.edu>
> Reply-To: met_help at ucar.edu <mailto:met_help at ucar.edu>
> To: Ellen.Sukovich at noaa.gov <mailto:Ellen.Sukovich at noaa.gov>
> CC: met_help at mailman.ucar.edu
<mailto:met_help at mailman.ucar.edu>
>
>
>
> Ellen,
>
> If your data dude can put it into the format shown below, MET
should be able to read it. I will probably hold off on
> the conversion script unless you would still like me to put it
together. The format is really just a matter of having
> certain attributes present with specific names and values. I
also showed how I regridded (to lat/lon projection) and
> converted a test file included in the MET tarball file from
GRIB to MET NetCDF. If you have any questions about this
> format, please let us know.
>
> Paul
>
>
> [pgoldenb at orval 20120710.sukovich]$ copygb.exe \
> -xg 110 \
>
$MET_BASE/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212 \
> wrfprs_ruc13_12.tm00_G212.grib
> [pgoldenb at orval 20120710.sukovich]$ $MET_BASE/bin/pcp_combine
-add \
> wrfprs_ruc13_12.tm00_G212.grib 12 \
> wrfprs_ruc13_12.tm00_G212.nc
<http://wrfprs_ruc13_12.tm00_G212.nc>
> DEBUG 1: Reading input file: wrfprs_ruc13_12.tm00_G212.grib
> DEBUG 1: Writing output file:wrfprs_ruc13_12.tm00_G212.nc
<http://wrfprs_ruc13_12.tm00_G212.nc>
> [pgoldenb at orval 20120710.sukovich]$ ncdump
-hwrfprs_ruc13_12.tm00_G212.nc <http://wrfprs_ruc13_12.tm00_G212.nc>
> netcdf wrfprs_ruc13_12.tm00_G212 {
> dimensions:
> lat = 224 ;
> lon = 464 ;
> variables:
> float lat(lat, lon) ;
> lat:long_name = "latitude" ;
> lat:units = "degrees_north" ;
> lat:standard_name = "latitude" ;
> float lon(lat, lon) ;
> lon:long_name = "longitude" ;
> lon:units = "degrees_east" ;
> lon:standard_name = "longitude" ;
> float APCP_12(lat, lon) ;
> APCP_12:name = "APCP_12" ;
> APCP_12:long_name = "Total precipitation" ;
> APCP_12:level = "A12" ;
> APCP_12:units = "kg/m^2" ;
> APCP_12:_FillValue = -9999.f ;
> APCP_12:init_time = "20050807_000000" ;
> APCP_12:init_time_ut = 1123372800 ;
> APCP_12:valid_time = "20050807_120000" ;
> APCP_12:valid_time_ut = 1123416000 ;
> APCP_12:accum_time = "120000" ;
> APCP_12:accum_time_sec = 43200 ;
>
> // global attributes:
> :FileOrigins =
"Filewrfprs_ruc13_12.tm00_G212.nc
<http://wrfprs_ruc13_12.tm00_G212.nc> generated 20120710_171301 UTC
on host orval by the
> MET pcp_combine tool" ;
> :MET_version = "V4.0" ;
> :MET_tool = "pcp_combine" ;
> :RunCommand = "Addition: 1 files." ;
> :Projection = "LatLon" ;
> :lat_ll = "25.063000 degrees_north" ;
> :lon_ll = "-124.938000 degrees_east" ;
> :delta_lat = "0.125000 degrees" ;
> :delta_lon = "0.125000 degrees" ;
> :Nlat = "224 grid_points" ;
> :Nlon = "464 grid_points" ;
> }
>
>
> On 07/10/2012 11:01 AM,Ellen.Sukovich at noaa.gov
<mailto:Ellen.Sukovich at noaa.gov> via RT wrote:
> >
> > <URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358
>
> >
> > Hi Paul,
> >
> > Thanks for the quick response! I was afraid the conversion
wasn't going
> > to be readily available. Eventually, I will have many
(many!) files
> > like the one I sent you, however the colleague who is
outputting the
> > data can probably put it into the correct format if he knows
what the
> > MET netcdf format is. If you could show us how to make the
correct MET
> > netcdf format for the file I sent you, we can probably
replicate it for
> > future files.
> >
> > Thanks again for your help!
> > Ellen
> >
> >
> > On 7/10/2012 10:55 AM, Paul Oldenburg via RT wrote:
> >> Ellen,
> >>
> >> To our knowledge, converting from NetCDF to GRIB is an
unsolved problem. I think the easiest route would be to change
> >> the structure of your precip NetCDF so that MET can read it
- to a format like the output of the pcp_combine tool. I
> >> will try to whip up a script to do this for the one file you
sent me. Are you going to need this conversion performed
> >> on more than just this one file? If so, I will try to make
it more user-friendly so you can use it.
> >>
> >> Paul
> >>
> >>
> >> On 07/10/2012 10:34 AM,Ellen.Sukovich at noaa.gov
<mailto:Ellen.Sukovich at noaa.gov> via RT wrote:
> >>> Tue Jul 10 10:34:38 2012: Request 57358 was acted upon.
> >>> Transaction: Ticket created byEllen.Sukovich at noaa.gov
<mailto:Ellen.Sukovich at noaa.gov>
> >>> Queue: met_help
> >>> Subject: MET netcdf to grib1 converter yet?
> >>> Owner: Nobody
> >>> Requestors:Ellen.Sukovich at noaa.gov
<mailto:Ellen.Sukovich at noaa.gov>
> >>> Status: new
> >>> Ticket
<URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
> >>>
> >>>
> >>> Hi MET Help,
> >>>
> >>> In the more recent versions of MET (i.e., v3.1 and v4) is
there a netcdf
> >>> to grib1 converter? I have a netcdf file with
precipitation data (see
> >>> attached) that was outputted from radar software but it is
not the
> >>> netcdf version that MET wants. What is the best way to get
this into
> >>> the netcdf form or grib1 format that MET will read? (Note:
This netcdf
> >>> format is not output from WRF so the CDO conversion is not
applicable
> >>> and my NCL guru here at NOAA doesn't know of an NCL command
that can do
> >>> the conversion.)
> >>>
> >>> Thanks for your time!
> >>> Ellen Sukovich
> >>>
> >>
> >>
> >
> >
>
>
>
>
>
>
>
>
>
>
------------------------------------------------
Subject: MET netcdf to grib1 converter yet?
From: Haonan Chen
Time: Wed Jul 11 23:58:53 2012
Hi Ellen and Paul
How are you doing?
This is Haonan, the guy working with Ellen on the NetCDF format
conversion
problems. I changed the fields according to Paul's comments (they are
very
helpful). However, I still have one question here: In the global
attributes
of your sample file, there was a field like following.
*FileOrigins = "File wrfprs_ruc13_12.tm00_G212.nc generated
20120710_171301
UTC on host orval by the MET pcp_combine tool" ;*
However, I am not really using host orval (a machine?) and the MET
pcp_combine tool even I specified something about MET_tool. Do I have
to
make the FileOrigins exactly the same with your sample file?
I am attaching a example result from my program. I guess you should be
able
to open it. Could you please help us check it? Thanks so much.
Have a good night.
Haonan
On Tue, Jul 10, 2012 at 1:20 PM, Ellen Sukovich
<ellen.sukovich at noaa.gov>wrote:
> Hi Haonan,
>
> Could you put your netcdf file into the format listed below? I am
not
> familiar with netcdf so I don't know if the instructions below make
sense.
> See email below this email.
>
> Ellen
>
> {
> dimensions:
> lat = 224 ;
> lon = 464 ;
> variables:
> float lat(lat, lon) ;
> lat:long_name = "latitude" ;
> lat:units = "degrees_north" ;
> lat:standard_name = "latitude" ;
> float lon(lat, lon) ;
> lon:long_name = "longitude" ;
> lon:units = "degrees_east" ;
> lon:standard_name = "longitude" ;
> float APCP_12(lat, lon) ;
> APCP_12:name = "APCP_12" ;
> APCP_12:long_name = "Total precipitation" ;
> APCP_12:level = "A12" ;
> APCP_12:units = "kg/m^2" ;
> APCP_12:_FillValue = -9999.f ;
> APCP_12:init_time = "20050807_000000" ;
> APCP_12:init_time_ut = 1123372800 ;
> APCP_12:valid_time = "20050807_120000" ;
> APCP_12:valid_time_ut = 1123416000 ;
> APCP_12:accum_time = "120000" ;
> APCP_12:accum_time_sec = 43200 ;
>
> // global attributes:
> :FileOrigins = "File wrfprs_ruc13_12.tm00_G212.nc
generated 20120710_171301 UTC on host orval by the
> MET pcp_combine tool" ;
> :MET_version = "V4.0" ;
> :MET_tool = "pcp_combine" ;
> :RunCommand = "Addition: 1 files." ;
> :Projection = "LatLon" ;
> :lat_ll = "25.063000 degrees_north" ;
> :lon_ll = "-124.938000 degrees_east" ;
> :delta_lat = "0.125000 degrees" ;
> :delta_lon = "0.125000 degrees" ;
> :Nlat = "224 grid_points" ;
> :Nlon = "464 grid_points" ;
> }
>
>
> -------- Original Message -------- Subject: Re: [rt.rap.ucar.edu
#57358]
> MET netcdf to grib1 converter yet? Date: Tue, 10 Jul 2012 13:14:06
-0600 From:
> Paul Oldenburg via RT <met_help at ucar.edu> <met_help at ucar.edu>
Reply-To:
> met_help at ucar.edu To: Ellen.Sukovich at noaa.gov CC:
> met_help at mailman.ucar.edu
>
> Ellen,
>
> If your data dude can put it into the format shown below, MET should
be able to read it. I will probably hold off on
> the conversion script unless you would still like me to put it
together. The format is really just a matter of having
> certain attributes present with specific names and values. I also
showed how I regridded (to lat/lon projection) and
> converted a test file included in the MET tarball file from GRIB to
MET NetCDF. If you have any questions about this
> format, please let us know.
>
> Paul
>
>
> [pgoldenb at orval 20120710.sukovich]$ copygb.exe \
> -xg 110 \
> $MET_BASE/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212 \
> wrfprs_ruc13_12.tm00_G212.grib
> [pgoldenb at orval 20120710.sukovich]$ $MET_BASE/bin/pcp_combine -add \
> wrfprs_ruc13_12.tm00_G212.grib 12 \
> wrfprs_ruc13_12.tm00_G212.nc
> DEBUG 1: Reading input file: wrfprs_ruc13_12.tm00_G212.grib
> DEBUG 1: Writing output file: wrfprs_ruc13_12.tm00_G212.nc
> [pgoldenb at orval 20120710.sukovich]$ ncdump -h
wrfprs_ruc13_12.tm00_G212.nc
> netcdf wrfprs_ruc13_12.tm00_G212 {
> dimensions:
> lat = 224 ;
> lon = 464 ;
> variables:
> float lat(lat, lon) ;
> lat:long_name = "latitude" ;
> lat:units = "degrees_north" ;
> lat:standard_name = "latitude" ;
> float lon(lat, lon) ;
> lon:long_name = "longitude" ;
> lon:units = "degrees_east" ;
> lon:standard_name = "longitude" ;
> float APCP_12(lat, lon) ;
> APCP_12:name = "APCP_12" ;
> APCP_12:long_name = "Total precipitation" ;
> APCP_12:level = "A12" ;
> APCP_12:units = "kg/m^2" ;
> APCP_12:_FillValue = -9999.f ;
> APCP_12:init_time = "20050807_000000" ;
> APCP_12:init_time_ut = 1123372800 ;
> APCP_12:valid_time = "20050807_120000" ;
> APCP_12:valid_time_ut = 1123416000 ;
> APCP_12:accum_time = "120000" ;
> APCP_12:accum_time_sec = 43200 ;
>
> // global attributes:
> :FileOrigins = "File wrfprs_ruc13_12.tm00_G212.nc
generated 20120710_171301 UTC on host orval by the
> MET pcp_combine tool" ;
> :MET_version = "V4.0" ;
> :MET_tool = "pcp_combine" ;
> :RunCommand = "Addition: 1 files." ;
> :Projection = "LatLon" ;
> :lat_ll = "25.063000 degrees_north" ;
> :lon_ll = "-124.938000 degrees_east" ;
> :delta_lat = "0.125000 degrees" ;
> :delta_lon = "0.125000 degrees" ;
> :Nlat = "224 grid_points" ;
> :Nlon = "464 grid_points" ;
> }
>
>
------------------------------------------------
Subject: MET netcdf to grib1 converter yet?
From: Ellen.Sukovich at noaa.gov
Time: Thu Jul 12 07:30:31 2012
---------- Forwarded message ----------
From: Haonan Chen via RT <met_help at ucar.edu>
Date: Wed, Jul 11, 2012 at 11:58 PM
Subject: Fw: [rt.rap.ucar.edu #57358] MET netcdf to grib1 converter
yet?
To: Ellen.Sukovich at noaa.gov
Cc: met_help at mailman.ucar.edu
Hi Ellen and Paul
How are you doing?
This is Haonan, the guy working with Ellen on the NetCDF format
conversion
problems. I changed the fields according to Paul's comments (they are
very
helpful). However, I still have one question here: In the global
attributes
of your sample file, there was a field like following.
*FileOrigins = "File wrfprs_ruc13_12.tm00_G212.nc generated
20120710_171301
UTC on host orval by the MET pcp_combine tool" ;*
However, I am not really using host orval (a machine?) and the MET
pcp_combine tool even I specified something about MET_tool. Do I have
to
make the FileOrigins exactly the same with your sample file?
I am attaching a example result from my program. I guess you should be
able
to open it. Could you please help us check it? Thanks so much.
Have a good night.
Haonan
On Tue, Jul 10, 2012 at 1:20 PM, Ellen Sukovich
<ellen.sukovich at noaa.gov
>wrote:
> Hi Haonan,
>
> Could you put your netcdf file into the format listed below? I am
not
> familiar with netcdf so I don't know if the instructions below make
sense.
> See email below this email.
>
> Ellen
>
> {
> dimensions:
> lat = 224 ;
> lon = 464 ;
> variables:
> float lat(lat, lon) ;
> lat:long_name = "latitude" ;
> lat:units = "degrees_north" ;
> lat:standard_name = "latitude" ;
> float lon(lat, lon) ;
> lon:long_name = "longitude" ;
> lon:units = "degrees_east" ;
> lon:standard_name = "longitude" ;
> float APCP_12(lat, lon) ;
> APCP_12:name = "APCP_12" ;
> APCP_12:long_name = "Total precipitation" ;
> APCP_12:level = "A12" ;
> APCP_12:units = "kg/m^2" ;
> APCP_12:_FillValue = -9999.f ;
> APCP_12:init_time = "20050807_000000" ;
> APCP_12:init_time_ut = 1123372800 ;
> APCP_12:valid_time = "20050807_120000" ;
> APCP_12:valid_time_ut = 1123416000 ;
> APCP_12:accum_time = "120000" ;
> APCP_12:accum_time_sec = 43200 ;
>
> // global attributes:
> :FileOrigins = "File
wrfprs_ruc13_12.tm00_G212.ncgenerated 20120710_171301 UTC on host
orval by the
> MET pcp_combine tool" ;
> :MET_version = "V4.0" ;
> :MET_tool = "pcp_combine" ;
> :RunCommand = "Addition: 1 files." ;
> :Projection = "LatLon" ;
> :lat_ll = "25.063000 degrees_north" ;
> :lon_ll = "-124.938000 degrees_east" ;
> :delta_lat = "0.125000 degrees" ;
> :delta_lon = "0.125000 degrees" ;
> :Nlat = "224 grid_points" ;
> :Nlon = "464 grid_points" ;
> }
>
>
> -------- Original Message -------- Subject: Re: [rt.rap.ucar.edu
#57358]
> MET netcdf to grib1 converter yet? Date: Tue, 10 Jul 2012 13:14:06
-0600
From:
> Paul Oldenburg via RT <met_help at ucar.edu> <met_help at ucar.edu>
Reply-To:
> met_help at ucar.edu To: Ellen.Sukovich at noaa.gov CC:
> met_help at mailman.ucar.edu
>
> Ellen,
>
> If your data dude can put it into the format shown below, MET should
be
able to read it. I will probably hold off on
> the conversion script unless you would still like me to put it
together.
The format is really just a matter of having
> certain attributes present with specific names and values. I also
showed
how I regridded (to lat/lon projection) and
> converted a test file included in the MET tarball file from GRIB to
MET
NetCDF. If you have any questions about this
> format, please let us know.
>
> Paul
>
>
> [pgoldenb at orval 20120710.sukovich]$ copygb.exe \
> -xg 110 \
> $MET_BASE/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212 \
> wrfprs_ruc13_12.tm00_G212.grib
> [pgoldenb at orval 20120710.sukovich]$ $MET_BASE/bin/pcp_combine -add \
> wrfprs_ruc13_12.tm00_G212.grib 12 \
> wrfprs_ruc13_12.tm00_G212.nc
> DEBUG 1: Reading input file: wrfprs_ruc13_12.tm00_G212.grib
> DEBUG 1: Writing output file: wrfprs_ruc13_12.tm00_G212.nc
> [pgoldenb at orval 20120710.sukovich]$ ncdump -h
wrfprs_ruc13_12.tm00_G212.nc
> netcdf wrfprs_ruc13_12.tm00_G212 {
> dimensions:
> lat = 224 ;
> lon = 464 ;
> variables:
> float lat(lat, lon) ;
> lat:long_name = "latitude" ;
> lat:units = "degrees_north" ;
> lat:standard_name = "latitude" ;
> float lon(lat, lon) ;
> lon:long_name = "longitude" ;
> lon:units = "degrees_east" ;
> lon:standard_name = "longitude" ;
> float APCP_12(lat, lon) ;
> APCP_12:name = "APCP_12" ;
> APCP_12:long_name = "Total precipitation" ;
> APCP_12:level = "A12" ;
> APCP_12:units = "kg/m^2" ;
> APCP_12:_FillValue = -9999.f ;
> APCP_12:init_time = "20050807_000000" ;
> APCP_12:init_time_ut = 1123372800 ;
> APCP_12:valid_time = "20050807_120000" ;
> APCP_12:valid_time_ut = 1123416000 ;
> APCP_12:accum_time = "120000" ;
> APCP_12:accum_time_sec = 43200 ;
>
> // global attributes:
> :FileOrigins = "File
wrfprs_ruc13_12.tm00_G212.ncgenerated 20120710_171301 UTC on host
orval by the
> MET pcp_combine tool" ;
> :MET_version = "V4.0" ;
> :MET_tool = "pcp_combine" ;
> :RunCommand = "Addition: 1 files." ;
> :Projection = "LatLon" ;
> :lat_ll = "25.063000 degrees_north" ;
> :lon_ll = "-124.938000 degrees_east" ;
> :delta_lat = "0.125000 degrees" ;
> :delta_lon = "0.125000 degrees" ;
> :Nlat = "224 grid_points" ;
> :Nlon = "464 grid_points" ;
> }
>
>
------------------------------------------------
Subject: MET netcdf to grib1 converter yet?
From: Paul Oldenburg
Time: Thu Jul 12 08:40:48 2012
Ellen & Haonan,
You are getting close. I used the MET utility plot_data_plane to plot
the APCP_12 field in the data file that you sent me:
$ $MET_BASE/bin/plot_data_plane GAGEONLY2012031417z_MET_2.nc plot.ps
'name="APCP_12";level="(*,*)";'
DEBUG 1: Opening data file: GAGEONLY2012031417z_MET_2.nc
DEBUG 1: Creating postscript file: plot.ps
The fact that it ran correctly and generated a plot is a good sign.
However, the plot shows that there are areas of
precip values of -999. The ncview tool shows the same situation. Are
these areas actually supposed to be bad data
(-9999)? If so, changing values -999 to -9999 might fix the problem.
Also, it looks like there might be an indexing
problem or perhaps a regridding problem because the areas where precip
values are normal looks a bit skewed. Maybe
check the regridding process? Please let me know if you have any
questions.
Thanks,
Paul
On 07/11/2012 11:58 PM, Haonan Chen via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>
> Hi Ellen and Paul
>
> How are you doing?
>
> This is Haonan, the guy working with Ellen on the NetCDF format
conversion
> problems. I changed the fields according to Paul's comments (they
are very
> helpful). However, I still have one question here: In the global
attributes
> of your sample file, there was a field like following.
>
> *FileOrigins = "File wrfprs_ruc13_12.tm00_G212.nc generated
20120710_171301
> UTC on host orval by the MET pcp_combine tool" ;*
>
> However, I am not really using host orval (a machine?) and the MET
> pcp_combine tool even I specified something about MET_tool. Do I
have to
> make the FileOrigins exactly the same with your sample file?
>
> I am attaching a example result from my program. I guess you should
be able
> to open it. Could you please help us check it? Thanks so much.
>
> Have a good night.
>
> Haonan
>
> On Tue, Jul 10, 2012 at 1:20 PM, Ellen Sukovich
<ellen.sukovich at noaa.gov>wrote:
>
>> Hi Haonan,
>>
>> Could you put your netcdf file into the format listed below? I am
not
>> familiar with netcdf so I don't know if the instructions below make
sense.
>> See email below this email.
>>
>> Ellen
>>
>> {
>> dimensions:
>> lat = 224 ;
>> lon = 464 ;
>> variables:
>> float lat(lat, lon) ;
>> lat:long_name = "latitude" ;
>> lat:units = "degrees_north" ;
>> lat:standard_name = "latitude" ;
>> float lon(lat, lon) ;
>> lon:long_name = "longitude" ;
>> lon:units = "degrees_east" ;
>> lon:standard_name = "longitude" ;
>> float APCP_12(lat, lon) ;
>> APCP_12:name = "APCP_12" ;
>> APCP_12:long_name = "Total precipitation" ;
>> APCP_12:level = "A12" ;
>> APCP_12:units = "kg/m^2" ;
>> APCP_12:_FillValue = -9999.f ;
>> APCP_12:init_time = "20050807_000000" ;
>> APCP_12:init_time_ut = 1123372800 ;
>> APCP_12:valid_time = "20050807_120000" ;
>> APCP_12:valid_time_ut = 1123416000 ;
>> APCP_12:accum_time = "120000" ;
>> APCP_12:accum_time_sec = 43200 ;
>>
>> // global attributes:
>> :FileOrigins = "File wrfprs_ruc13_12.tm00_G212.nc
generated 20120710_171301 UTC on host orval by the
>> MET pcp_combine tool" ;
>> :MET_version = "V4.0" ;
>> :MET_tool = "pcp_combine" ;
>> :RunCommand = "Addition: 1 files." ;
>> :Projection = "LatLon" ;
>> :lat_ll = "25.063000 degrees_north" ;
>> :lon_ll = "-124.938000 degrees_east" ;
>> :delta_lat = "0.125000 degrees" ;
>> :delta_lon = "0.125000 degrees" ;
>> :Nlat = "224 grid_points" ;
>> :Nlon = "464 grid_points" ;
>> }
>>
>>
>> -------- Original Message -------- Subject: Re: [rt.rap.ucar.edu
#57358]
>> MET netcdf to grib1 converter yet? Date: Tue, 10 Jul 2012 13:14:06
-0600 From:
>> Paul Oldenburg via RT <met_help at ucar.edu> <met_help at ucar.edu>
Reply-To:
>> met_help at ucar.edu To: Ellen.Sukovich at noaa.gov CC:
>> met_help at mailman.ucar.edu
>>
>> Ellen,
>>
>> If your data dude can put it into the format shown below, MET
should be able to read it. I will probably hold off on
>> the conversion script unless you would still like me to put it
together. The format is really just a matter of having
>> certain attributes present with specific names and values. I also
showed how I regridded (to lat/lon projection) and
>> converted a test file included in the MET tarball file from GRIB to
MET NetCDF. If you have any questions about this
>> format, please let us know.
>>
>> Paul
>>
>>
>> [pgoldenb at orval 20120710.sukovich]$ copygb.exe \
>> -xg 110 \
>> $MET_BASE/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212
\
>> wrfprs_ruc13_12.tm00_G212.grib
>> [pgoldenb at orval 20120710.sukovich]$ $MET_BASE/bin/pcp_combine -add
\
>> wrfprs_ruc13_12.tm00_G212.grib 12 \
>> wrfprs_ruc13_12.tm00_G212.nc
>> DEBUG 1: Reading input file: wrfprs_ruc13_12.tm00_G212.grib
>> DEBUG 1: Writing output file: wrfprs_ruc13_12.tm00_G212.nc
>> [pgoldenb at orval 20120710.sukovich]$ ncdump -h
wrfprs_ruc13_12.tm00_G212.nc
>> netcdf wrfprs_ruc13_12.tm00_G212 {
>> dimensions:
>> lat = 224 ;
>> lon = 464 ;
>> variables:
>> float lat(lat, lon) ;
>> lat:long_name = "latitude" ;
>> lat:units = "degrees_north" ;
>> lat:standard_name = "latitude" ;
>> float lon(lat, lon) ;
>> lon:long_name = "longitude" ;
>> lon:units = "degrees_east" ;
>> lon:standard_name = "longitude" ;
>> float APCP_12(lat, lon) ;
>> APCP_12:name = "APCP_12" ;
>> APCP_12:long_name = "Total precipitation" ;
>> APCP_12:level = "A12" ;
>> APCP_12:units = "kg/m^2" ;
>> APCP_12:_FillValue = -9999.f ;
>> APCP_12:init_time = "20050807_000000" ;
>> APCP_12:init_time_ut = 1123372800 ;
>> APCP_12:valid_time = "20050807_120000" ;
>> APCP_12:valid_time_ut = 1123416000 ;
>> APCP_12:accum_time = "120000" ;
>> APCP_12:accum_time_sec = 43200 ;
>>
>> // global attributes:
>> :FileOrigins = "File wrfprs_ruc13_12.tm00_G212.nc
generated 20120710_171301 UTC on host orval by the
>> MET pcp_combine tool" ;
>> :MET_version = "V4.0" ;
>> :MET_tool = "pcp_combine" ;
>> :RunCommand = "Addition: 1 files." ;
>> :Projection = "LatLon" ;
>> :lat_ll = "25.063000 degrees_north" ;
>> :lon_ll = "-124.938000 degrees_east" ;
>> :delta_lat = "0.125000 degrees" ;
>> :delta_lon = "0.125000 degrees" ;
>> :Nlat = "224 grid_points" ;
>> :Nlon = "464 grid_points" ;
>> }
>>
>>
------------------------------------------------
Subject: MET netcdf to grib1 converter yet?
From: Ellen.Sukovich at noaa.gov
Time: Thu Jul 12 09:42:44 2012
On Thu, Jul 12, 2012 at 8:40 AM, Paul Oldenburg via RT
<met_help at ucar.edu>wrote:
> Ellen & Haonan,
>
> You are getting close. I used the MET utility plot_data_plane to
plot the
> APCP_12 field in the data file that you sent me:
>
> $ $MET_BASE/bin/plot_data_plane GAGEONLY2012031417z_MET_2.nc
plot.ps'name="APCP_12";level="(*,*)";'
> DEBUG 1: Opening data file: GAGEONLY2012031417z_MET_2.nc
> DEBUG 1: Creating postscript file: plot.ps
>
> The fact that it ran correctly and generated a plot is a good sign.
> However, the plot shows that there are areas of
> precip values of -999. The ncview tool shows the same situation.
Are
> these areas actually supposed to be bad data
> (-9999)? If so, changing values -999 to -9999 might fix the
problem.
> Also, it looks like there might be an indexing
> problem or perhaps a regridding problem because the areas where
precip
> values are normal looks a bit skewed. Maybe
> check the regridding process? Please let me know if you have any
> questions.
>
> Thanks,
>
> Paul
>
>
> On 07/11/2012 11:58 PM, Haonan Chen via RT wrote:
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
> >
> > Hi Ellen and Paul
> >
> > How are you doing?
> >
> > This is Haonan, the guy working with Ellen on the NetCDF format
> conversion
> > problems. I changed the fields according to Paul's comments (they
are
> very
> > helpful). However, I still have one question here: In the global
> attributes
> > of your sample file, there was a field like following.
> >
> > *FileOrigins = "File wrfprs_ruc13_12.tm00_G212.nc generated
> 20120710_171301
> > UTC on host orval by the MET pcp_combine tool" ;*
> >
> > However, I am not really using host orval (a machine?) and the MET
> > pcp_combine tool even I specified something about MET_tool. Do I
have to
> > make the FileOrigins exactly the same with your sample file?
> >
> > I am attaching a example result from my program. I guess you
should be
> able
> > to open it. Could you please help us check it? Thanks so much.
> >
> > Have a good night.
> >
> > Haonan
> >
> > On Tue, Jul 10, 2012 at 1:20 PM, Ellen Sukovich
<ellen.sukovich at noaa.gov
> >wrote:
> >
> >> Hi Haonan,
> >>
> >> Could you put your netcdf file into the format listed below? I am
not
> >> familiar with netcdf so I don't know if the instructions below
make
> sense.
> >> See email below this email.
> >>
> >> Ellen
> >>
> >> {
> >> dimensions:
> >> lat = 224 ;
> >> lon = 464 ;
> >> variables:
> >> float lat(lat, lon) ;
> >> lat:long_name = "latitude" ;
> >> lat:units = "degrees_north" ;
> >> lat:standard_name = "latitude" ;
> >> float lon(lat, lon) ;
> >> lon:long_name = "longitude" ;
> >> lon:units = "degrees_east" ;
> >> lon:standard_name = "longitude" ;
> >> float APCP_12(lat, lon) ;
> >> APCP_12:name = "APCP_12" ;
> >> APCP_12:long_name = "Total precipitation" ;
> >> APCP_12:level = "A12" ;
> >> APCP_12:units = "kg/m^2" ;
> >> APCP_12:_FillValue = -9999.f ;
> >> APCP_12:init_time = "20050807_000000" ;
> >> APCP_12:init_time_ut = 1123372800 ;
> >> APCP_12:valid_time = "20050807_120000" ;
> >> APCP_12:valid_time_ut = 1123416000 ;
> >> APCP_12:accum_time = "120000" ;
> >> APCP_12:accum_time_sec = 43200 ;
> >>
> >> // global attributes:
> >> :FileOrigins = "File
wrfprs_ruc13_12.tm00_G212.ncgenerated 20120710_171301 UTC on host
orval by the
> >> MET pcp_combine tool" ;
> >> :MET_version = "V4.0" ;
> >> :MET_tool = "pcp_combine" ;
> >> :RunCommand = "Addition: 1 files." ;
> >> :Projection = "LatLon" ;
> >> :lat_ll = "25.063000 degrees_north" ;
> >> :lon_ll = "-124.938000 degrees_east" ;
> >> :delta_lat = "0.125000 degrees" ;
> >> :delta_lon = "0.125000 degrees" ;
> >> :Nlat = "224 grid_points" ;
> >> :Nlon = "464 grid_points" ;
> >> }
> >>
> >>
> >> -------- Original Message -------- Subject: Re:
[rt.rap.ucar.edu#57358]
> >> MET netcdf to grib1 converter yet? Date: Tue, 10 Jul 2012
13:14:06
> -0600 From:
> >> Paul Oldenburg via RT <met_help at ucar.edu> <met_help at ucar.edu>
> Reply-To:
> >> met_help at ucar.edu To: Ellen.Sukovich at noaa.gov CC:
> >> met_help at mailman.ucar.edu
> >>
> >> Ellen,
> >>
> >> If your data dude can put it into the format shown below, MET
should be
> able to read it. I will probably hold off on
> >> the conversion script unless you would still like me to put it
> together. The format is really just a matter of having
> >> certain attributes present with specific names and values. I
also
> showed how I regridded (to lat/lon projection) and
> >> converted a test file included in the MET tarball file from GRIB
to MET
> NetCDF. If you have any questions about this
> >> format, please let us know.
> >>
> >> Paul
> >>
> >>
> >> [pgoldenb at orval 20120710.sukovich]$ copygb.exe \
> >> -xg 110 \
> >>
$MET_BASE/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212 \
> >> wrfprs_ruc13_12.tm00_G212.grib
> >> [pgoldenb at orval 20120710.sukovich]$ $MET_BASE/bin/pcp_combine
-add \
> >> wrfprs_ruc13_12.tm00_G212.grib 12 \
> >> wrfprs_ruc13_12.tm00_G212.nc
> >> DEBUG 1: Reading input file: wrfprs_ruc13_12.tm00_G212.grib
> >> DEBUG 1: Writing output file: wrfprs_ruc13_12.tm00_G212.nc
> >> [pgoldenb at orval 20120710.sukovich]$ ncdump -h
> wrfprs_ruc13_12.tm00_G212.nc
> >> netcdf wrfprs_ruc13_12.tm00_G212 {
> >> dimensions:
> >> lat = 224 ;
> >> lon = 464 ;
> >> variables:
> >> float lat(lat, lon) ;
> >> lat:long_name = "latitude" ;
> >> lat:units = "degrees_north" ;
> >> lat:standard_name = "latitude" ;
> >> float lon(lat, lon) ;
> >> lon:long_name = "longitude" ;
> >> lon:units = "degrees_east" ;
> >> lon:standard_name = "longitude" ;
> >> float APCP_12(lat, lon) ;
> >> APCP_12:name = "APCP_12" ;
> >> APCP_12:long_name = "Total precipitation" ;
> >> APCP_12:level = "A12" ;
> >> APCP_12:units = "kg/m^2" ;
> >> APCP_12:_FillValue = -9999.f ;
> >> APCP_12:init_time = "20050807_000000" ;
> >> APCP_12:init_time_ut = 1123372800 ;
> >> APCP_12:valid_time = "20050807_120000" ;
> >> APCP_12:valid_time_ut = 1123416000 ;
> >> APCP_12:accum_time = "120000" ;
> >> APCP_12:accum_time_sec = 43200 ;
> >>
> >> // global attributes:
> >> :FileOrigins = "File
wrfprs_ruc13_12.tm00_G212.ncgenerated 20120710_171301 UTC on host
orval by the
> >> MET pcp_combine tool" ;
> >> :MET_version = "V4.0" ;
> >> :MET_tool = "pcp_combine" ;
> >> :RunCommand = "Addition: 1 files." ;
> >> :Projection = "LatLon" ;
> >> :lat_ll = "25.063000 degrees_north" ;
> >> :lon_ll = "-124.938000 degrees_east" ;
> >> :delta_lat = "0.125000 degrees" ;
> >> :delta_lon = "0.125000 degrees" ;
> >> :Nlat = "224 grid_points" ;
> >> :Nlon = "464 grid_points" ;
> >> }
> >>
> >>
>
>
>
>
------------------------------------------------
Subject: MET netcdf to grib1 converter yet?
From: Haonan Chen
Time: Thu Jul 12 12:20:13 2012
Hi Paul
Yes. -999 is actually the bad value. And I just changed -999 to -9999.
The
data was originally in HRAP coordinates (a rectangular area), I only
converted the HRAP coordinates to Lat/Lons. So the output image should
be
skewed due to the polar properties of the Earth. I am also attaching a
plot
to show the map. It might be helpful to see the overall shape.
We will regrid the data to a rectangular Lat/Lon area if needed.
Thanks so much, Paul.
Haonan
On Thu, Jul 12, 2012 at 9:42 AM, Ellen Sukovich
<ellen.sukovich at noaa.gov>wrote:
>
>
> On Thu, Jul 12, 2012 at 8:40 AM, Paul Oldenburg via RT
<met_help at ucar.edu>wrote:
>
>> Ellen & Haonan,
>>
>> You are getting close. I used the MET utility plot_data_plane to
plot
>> the APCP_12 field in the data file that you sent me:
>>
>> $ $MET_BASE/bin/plot_data_plane GAGEONLY2012031417z_MET_2.nc
plot.ps'name="APCP_12";level="(*,*)";'
>> DEBUG 1: Opening data file: GAGEONLY2012031417z_MET_2.nc
>> DEBUG 1: Creating postscript file: plot.ps
>>
>> The fact that it ran correctly and generated a plot is a good sign.
>> However, the plot shows that there are areas of
>> precip values of -999. The ncview tool shows the same situation.
Are
>> these areas actually supposed to be bad data
>> (-9999)? If so, changing values -999 to -9999 might fix the
problem.
>> Also, it looks like there might be an indexing
>> problem or perhaps a regridding problem because the areas where
precip
>> values are normal looks a bit skewed. Maybe
>> check the regridding process? Please let me know if you have any
>> questions.
>>
>> Thanks,
>>
>> Paul
>>
>>
>>
>> On 07/11/2012 11:58 PM, Haonan Chen via RT wrote:
>> >
>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>> >
>> > Hi Ellen and Paul
>> >
>> > How are you doing?
>> >
>> > This is Haonan, the guy working with Ellen on the NetCDF format
>> conversion
>> > problems. I changed the fields according to Paul's comments (they
are
>> very
>> > helpful). However, I still have one question here: In the global
>> attributes
>> > of your sample file, there was a field like following.
>> >
>> > *FileOrigins = "File wrfprs_ruc13_12.tm00_G212.nc generated
>> 20120710_171301
>> > UTC on host orval by the MET pcp_combine tool" ;*
>>
>> >
>> > However, I am not really using host orval (a machine?) and the
MET
>> > pcp_combine tool even I specified something about MET_tool. Do I
have to
>> > make the FileOrigins exactly the same with your sample file?
>> >
>> > I am attaching a example result from my program. I guess you
should be
>> able
>> > to open it. Could you please help us check it? Thanks so much.
>> >
>> > Have a good night.
>> >
>> > Haonan
>> >
>> > On Tue, Jul 10, 2012 at 1:20 PM, Ellen Sukovich <
>> ellen.sukovich at noaa.gov>wrote:
>> >
>> >> Hi Haonan,
>> >>
>> >> Could you put your netcdf file into the format listed below? I
am not
>> >> familiar with netcdf so I don't know if the instructions below
make
>> sense.
>> >> See email below this email.
>> >>
>> >> Ellen
>> >>
>> >> {
>> >> dimensions:
>> >> lat = 224 ;
>> >> lon = 464 ;
>> >> variables:
>> >> float lat(lat, lon) ;
>> >> lat:long_name = "latitude" ;
>> >> lat:units = "degrees_north" ;
>> >> lat:standard_name = "latitude" ;
>> >> float lon(lat, lon) ;
>> >> lon:long_name = "longitude" ;
>> >> lon:units = "degrees_east" ;
>> >> lon:standard_name = "longitude" ;
>> >> float APCP_12(lat, lon) ;
>> >> APCP_12:name = "APCP_12" ;
>> >> APCP_12:long_name = "Total precipitation" ;
>> >> APCP_12:level = "A12" ;
>> >> APCP_12:units = "kg/m^2" ;
>> >> APCP_12:_FillValue = -9999.f ;
>> >> APCP_12:init_time = "20050807_000000" ;
>> >> APCP_12:init_time_ut = 1123372800 ;
>> >> APCP_12:valid_time = "20050807_120000" ;
>> >> APCP_12:valid_time_ut = 1123416000 ;
>> >> APCP_12:accum_time = "120000" ;
>> >> APCP_12:accum_time_sec = 43200 ;
>> >>
>> >> // global attributes:
>> >> :FileOrigins = "File
wrfprs_ruc13_12.tm00_G212.ncgenerated 20120710_171301 UTC on host
orval by the
>> >> MET pcp_combine tool" ;
>> >> :MET_version = "V4.0" ;
>> >> :MET_tool = "pcp_combine" ;
>> >> :RunCommand = "Addition: 1 files." ;
>> >> :Projection = "LatLon" ;
>> >> :lat_ll = "25.063000 degrees_north" ;
>> >> :lon_ll = "-124.938000 degrees_east" ;
>> >> :delta_lat = "0.125000 degrees" ;
>> >> :delta_lon = "0.125000 degrees" ;
>> >> :Nlat = "224 grid_points" ;
>> >> :Nlon = "464 grid_points" ;
>> >> }
>> >>
>> >>
>> >> -------- Original Message -------- Subject: Re:
[rt.rap.ucar.edu#57358]
>> >> MET netcdf to grib1 converter yet? Date: Tue, 10 Jul 2012
13:14:06
>> -0600 From:
>> >> Paul Oldenburg via RT <met_help at ucar.edu> <met_help at ucar.edu>
>> Reply-To:
>>
>> >> met_help at ucar.edu To: Ellen.Sukovich at noaa.gov CC:
>> >> met_help at mailman.ucar.edu
>> >>
>> >> Ellen,
>> >>
>> >> If your data dude can put it into the format shown below, MET
should
>> be able to read it. I will probably hold off on
>> >> the conversion script unless you would still like me to put it
>> together. The format is really just a matter of having
>> >> certain attributes present with specific names and values. I
also
>> showed how I regridded (to lat/lon projection) and
>> >> converted a test file included in the MET tarball file from GRIB
to
>> MET NetCDF. If you have any questions about this
>> >> format, please let us know.
>> >>
>> >> Paul
>> >>
>> >>
>> >> [pgoldenb at orval 20120710.sukovich]$ copygb.exe \
>> >> -xg 110 \
>> >>
$MET_BASE/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212 \
>> >> wrfprs_ruc13_12.tm00_G212.grib
>> >> [pgoldenb at orval 20120710.sukovich]$ $MET_BASE/bin/pcp_combine
-add \
>> >> wrfprs_ruc13_12.tm00_G212.grib 12 \
>> >> wrfprs_ruc13_12.tm00_G212.nc
>> >> DEBUG 1: Reading input file: wrfprs_ruc13_12.tm00_G212.grib
>> >> DEBUG 1: Writing output file: wrfprs_ruc13_12.tm00_G212.nc
>> >> [pgoldenb at orval 20120710.sukovich]$ ncdump -h
>> wrfprs_ruc13_12.tm00_G212.nc
>> >> netcdf wrfprs_ruc13_12.tm00_G212 {
>> >> dimensions:
>> >> lat = 224 ;
>> >> lon = 464 ;
>> >> variables:
>> >> float lat(lat, lon) ;
>> >> lat:long_name = "latitude" ;
>> >> lat:units = "degrees_north" ;
>> >> lat:standard_name = "latitude" ;
>> >> float lon(lat, lon) ;
>> >> lon:long_name = "longitude" ;
>> >> lon:units = "degrees_east" ;
>> >> lon:standard_name = "longitude" ;
>> >> float APCP_12(lat, lon) ;
>> >> APCP_12:name = "APCP_12" ;
>> >> APCP_12:long_name = "Total precipitation" ;
>> >> APCP_12:level = "A12" ;
>> >> APCP_12:units = "kg/m^2" ;
>> >> APCP_12:_FillValue = -9999.f ;
>> >> APCP_12:init_time = "20050807_000000" ;
>> >> APCP_12:init_time_ut = 1123372800 ;
>> >> APCP_12:valid_time = "20050807_120000" ;
>> >> APCP_12:valid_time_ut = 1123416000 ;
>> >> APCP_12:accum_time = "120000" ;
>> >> APCP_12:accum_time_sec = 43200 ;
>> >>
>> >> // global attributes:
>> >> :FileOrigins = "File
wrfprs_ruc13_12.tm00_G212.ncgenerated 20120710_171301 UTC on host
orval by the
>> >> MET pcp_combine tool" ;
>> >> :MET_version = "V4.0" ;
>> >> :MET_tool = "pcp_combine" ;
>> >> :RunCommand = "Addition: 1 files." ;
>> >> :Projection = "LatLon" ;
>> >> :lat_ll = "25.063000 degrees_north" ;
>> >> :lon_ll = "-124.938000 degrees_east" ;
>> >> :delta_lat = "0.125000 degrees" ;
>> >> :delta_lon = "0.125000 degrees" ;
>> >> :Nlat = "224 grid_points" ;
>> >> :Nlon = "464 grid_points" ;
>> >> }
>> >>
>> >>
>>
>>
>>
>>
>
------------------------------------------------
Subject: Re: Fw: [rt.rap.ucar.edu #57358] MET netcdf to grib1 converter yet?
From: Paul Oldenburg
Time: Thu Jul 12 12:25:15 2012
Haonan,
I plotted the new file and now the precip values are reasonable (~0-10
mm). It still looks like there is a skewing
problem in the regridding, but hopefully it won't be too hard to fix.
Remember that you can test your MET NetCDF output
using plot_data_plane as I showed in an earlier email. This will show
you how MET has read in the gridded data. I also
use ncview, which is quicker and easier. Please let me know if you
have any questions.
Paul
On 07/12/2012 12:20 PM, Haonan Chen via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>
> Hi Paul
>
> Yes. -999 is actually the bad value. And I just changed -999 to
-9999. The
> data was originally in HRAP coordinates (a rectangular area), I only
> converted the HRAP coordinates to Lat/Lons. So the output image
should be
> skewed due to the polar properties of the Earth. I am also attaching
a plot
> to show the map. It might be helpful to see the overall shape.
> We will regrid the data to a rectangular Lat/Lon area if needed.
>
> Thanks so much, Paul.
>
> Haonan
>
>
> On Thu, Jul 12, 2012 at 9:42 AM, Ellen Sukovich
<ellen.sukovich at noaa.gov>wrote:
>
>>
>>
>> On Thu, Jul 12, 2012 at 8:40 AM, Paul Oldenburg via RT
<met_help at ucar.edu>wrote:
>>
>>> Ellen & Haonan,
>>>
>>> You are getting close. I used the MET utility plot_data_plane to
plot
>>> the APCP_12 field in the data file that you sent me:
>>>
>>> $ $MET_BASE/bin/plot_data_plane GAGEONLY2012031417z_MET_2.nc
plot.ps'name="APCP_12";level="(*,*)";'
>>> DEBUG 1: Opening data file: GAGEONLY2012031417z_MET_2.nc
>>> DEBUG 1: Creating postscript file: plot.ps
>>>
>>> The fact that it ran correctly and generated a plot is a good
sign.
>>> However, the plot shows that there are areas of
>>> precip values of -999. The ncview tool shows the same situation.
Are
>>> these areas actually supposed to be bad data
>>> (-9999)? If so, changing values -999 to -9999 might fix the
problem.
>>> Also, it looks like there might be an indexing
>>> problem or perhaps a regridding problem because the areas where
precip
>>> values are normal looks a bit skewed. Maybe
>>> check the regridding process? Please let me know if you have any
>>> questions.
>>>
>>> Thanks,
>>>
>>> Paul
>>>
>>>
>>>
>>> On 07/11/2012 11:58 PM, Haonan Chen via RT wrote:
>>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>>>>
>>>> Hi Ellen and Paul
>>>>
>>>> How are you doing?
>>>>
>>>> This is Haonan, the guy working with Ellen on the NetCDF format
>>> conversion
>>>> problems. I changed the fields according to Paul's comments (they
are
>>> very
>>>> helpful). However, I still have one question here: In the global
>>> attributes
>>>> of your sample file, there was a field like following.
>>>>
>>>> *FileOrigins = "File wrfprs_ruc13_12.tm00_G212.nc generated
>>> 20120710_171301
>>>> UTC on host orval by the MET pcp_combine tool" ;*
>>>
>>>>
>>>> However, I am not really using host orval (a machine?) and the
MET
>>>> pcp_combine tool even I specified something about MET_tool. Do I
have to
>>>> make the FileOrigins exactly the same with your sample file?
>>>>
>>>> I am attaching a example result from my program. I guess you
should be
>>> able
>>>> to open it. Could you please help us check it? Thanks so much.
>>>>
>>>> Have a good night.
>>>>
>>>> Haonan
>>>>
>>>> On Tue, Jul 10, 2012 at 1:20 PM, Ellen Sukovich <
>>> ellen.sukovich at noaa.gov>wrote:
>>>>
>>>>> Hi Haonan,
>>>>>
>>>>> Could you put your netcdf file into the format listed below? I
am not
>>>>> familiar with netcdf so I don't know if the instructions below
make
>>> sense.
>>>>> See email below this email.
>>>>>
>>>>> Ellen
>>>>>
>>>>> {
>>>>> dimensions:
>>>>> lat = 224 ;
>>>>> lon = 464 ;
>>>>> variables:
>>>>> float lat(lat, lon) ;
>>>>> lat:long_name = "latitude" ;
>>>>> lat:units = "degrees_north" ;
>>>>> lat:standard_name = "latitude" ;
>>>>> float lon(lat, lon) ;
>>>>> lon:long_name = "longitude" ;
>>>>> lon:units = "degrees_east" ;
>>>>> lon:standard_name = "longitude" ;
>>>>> float APCP_12(lat, lon) ;
>>>>> APCP_12:name = "APCP_12" ;
>>>>> APCP_12:long_name = "Total precipitation" ;
>>>>> APCP_12:level = "A12" ;
>>>>> APCP_12:units = "kg/m^2" ;
>>>>> APCP_12:_FillValue = -9999.f ;
>>>>> APCP_12:init_time = "20050807_000000" ;
>>>>> APCP_12:init_time_ut = 1123372800 ;
>>>>> APCP_12:valid_time = "20050807_120000" ;
>>>>> APCP_12:valid_time_ut = 1123416000 ;
>>>>> APCP_12:accum_time = "120000" ;
>>>>> APCP_12:accum_time_sec = 43200 ;
>>>>>
>>>>> // global attributes:
>>>>> :FileOrigins = "File
wrfprs_ruc13_12.tm00_G212.ncgenerated 20120710_171301 UTC on host
orval by the
>>>>> MET pcp_combine tool" ;
>>>>> :MET_version = "V4.0" ;
>>>>> :MET_tool = "pcp_combine" ;
>>>>> :RunCommand = "Addition: 1 files." ;
>>>>> :Projection = "LatLon" ;
>>>>> :lat_ll = "25.063000 degrees_north" ;
>>>>> :lon_ll = "-124.938000 degrees_east" ;
>>>>> :delta_lat = "0.125000 degrees" ;
>>>>> :delta_lon = "0.125000 degrees" ;
>>>>> :Nlat = "224 grid_points" ;
>>>>> :Nlon = "464 grid_points" ;
>>>>> }
>>>>>
>>>>>
>>>>> -------- Original Message -------- Subject: Re:
[rt.rap.ucar.edu#57358]
>>>>> MET netcdf to grib1 converter yet? Date: Tue, 10 Jul 2012
13:14:06
>>> -0600 From:
>>>>> Paul Oldenburg via RT <met_help at ucar.edu> <met_help at ucar.edu>
>>> Reply-To:
>>>
>>>>> met_help at ucar.edu To: Ellen.Sukovich at noaa.gov CC:
>>>>> met_help at mailman.ucar.edu
>>>>>
>>>>> Ellen,
>>>>>
>>>>> If your data dude can put it into the format shown below, MET
should
>>> be able to read it. I will probably hold off on
>>>>> the conversion script unless you would still like me to put it
>>> together. The format is really just a matter of having
>>>>> certain attributes present with specific names and values. I
also
>>> showed how I regridded (to lat/lon projection) and
>>>>> converted a test file included in the MET tarball file from GRIB
to
>>> MET NetCDF. If you have any questions about this
>>>>> format, please let us know.
>>>>>
>>>>> Paul
>>>>>
>>>>>
>>>>> [pgoldenb at orval 20120710.sukovich]$ copygb.exe \
>>>>> -xg 110 \
>>>>>
$MET_BASE/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212 \
>>>>> wrfprs_ruc13_12.tm00_G212.grib
>>>>> [pgoldenb at orval 20120710.sukovich]$ $MET_BASE/bin/pcp_combine
-add \
>>>>> wrfprs_ruc13_12.tm00_G212.grib 12 \
>>>>> wrfprs_ruc13_12.tm00_G212.nc
>>>>> DEBUG 1: Reading input file: wrfprs_ruc13_12.tm00_G212.grib
>>>>> DEBUG 1: Writing output file: wrfprs_ruc13_12.tm00_G212.nc
>>>>> [pgoldenb at orval 20120710.sukovich]$ ncdump -h
>>> wrfprs_ruc13_12.tm00_G212.nc
>>>>> netcdf wrfprs_ruc13_12.tm00_G212 {
>>>>> dimensions:
>>>>> lat = 224 ;
>>>>> lon = 464 ;
>>>>> variables:
>>>>> float lat(lat, lon) ;
>>>>> lat:long_name = "latitude" ;
>>>>> lat:units = "degrees_north" ;
>>>>> lat:standard_name = "latitude" ;
>>>>> float lon(lat, lon) ;
>>>>> lon:long_name = "longitude" ;
>>>>> lon:units = "degrees_east" ;
>>>>> lon:standard_name = "longitude" ;
>>>>> float APCP_12(lat, lon) ;
>>>>> APCP_12:name = "APCP_12" ;
>>>>> APCP_12:long_name = "Total precipitation" ;
>>>>> APCP_12:level = "A12" ;
>>>>> APCP_12:units = "kg/m^2" ;
>>>>> APCP_12:_FillValue = -9999.f ;
>>>>> APCP_12:init_time = "20050807_000000" ;
>>>>> APCP_12:init_time_ut = 1123372800 ;
>>>>> APCP_12:valid_time = "20050807_120000" ;
>>>>> APCP_12:valid_time_ut = 1123416000 ;
>>>>> APCP_12:accum_time = "120000" ;
>>>>> APCP_12:accum_time_sec = 43200 ;
>>>>>
>>>>> // global attributes:
>>>>> :FileOrigins = "File
wrfprs_ruc13_12.tm00_G212.ncgenerated 20120710_171301 UTC on host
orval by the
>>>>> MET pcp_combine tool" ;
>>>>> :MET_version = "V4.0" ;
>>>>> :MET_tool = "pcp_combine" ;
>>>>> :RunCommand = "Addition: 1 files." ;
>>>>> :Projection = "LatLon" ;
>>>>> :lat_ll = "25.063000 degrees_north" ;
>>>>> :lon_ll = "-124.938000 degrees_east" ;
>>>>> :delta_lat = "0.125000 degrees" ;
>>>>> :delta_lon = "0.125000 degrees" ;
>>>>> :Nlat = "224 grid_points" ;
>>>>> :Nlon = "464 grid_points" ;
>>>>> }
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>
------------------------------------------------
Subject: MET netcdf to grib1 converter yet?
From: Ellen.Sukovich at noaa.gov
Time: Thu Jul 12 12:58:42 2012
Hi Paul,
I don't believe Haonan has MET access on his system. He is up at CSU.
Ellen
On Thu, Jul 12, 2012 at 12:25 PM, Paul Oldenburg via RT
<met_help at ucar.edu>wrote:
> Haonan,
>
> I plotted the new file and now the precip values are reasonable (~0-
10
> mm). It still looks like there is a skewing
> problem in the regridding, but hopefully it won't be too hard to
fix.
> Remember that you can test your MET NetCDF output
> using plot_data_plane as I showed in an earlier email. This will
show you
> how MET has read in the gridded data. I also
> use ncview, which is quicker and easier. Please let me know if you
have
> any questions.
>
> Paul
>
>
> On 07/12/2012 12:20 PM, Haonan Chen via RT wrote:
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
> >
> > Hi Paul
> >
> > Yes. -999 is actually the bad value. And I just changed -999 to
-9999.
> The
> > data was originally in HRAP coordinates (a rectangular area), I
only
> > converted the HRAP coordinates to Lat/Lons. So the output image
should be
> > skewed due to the polar properties of the Earth. I am also
attaching a
> plot
> > to show the map. It might be helpful to see the overall shape.
> > We will regrid the data to a rectangular Lat/Lon area if needed.
> >
> > Thanks so much, Paul.
> >
> > Haonan
> >
> >
> > On Thu, Jul 12, 2012 at 9:42 AM, Ellen Sukovich
<ellen.sukovich at noaa.gov
> >wrote:
> >
> >>
> >>
> >> On Thu, Jul 12, 2012 at 8:40 AM, Paul Oldenburg via RT <
> met_help at ucar.edu>wrote:
> >>
> >>> Ellen & Haonan,
> >>>
> >>> You are getting close. I used the MET utility plot_data_plane
to plot
> >>> the APCP_12 field in the data file that you sent me:
> >>>
> >>> $ $MET_BASE/bin/plot_data_plane GAGEONLY2012031417z_MET_2.nc
plot.ps
> 'name="APCP_12";level="(*,*)";'
> >>> DEBUG 1: Opening data file: GAGEONLY2012031417z_MET_2.nc
> >>> DEBUG 1: Creating postscript file: plot.ps
> >>>
> >>> The fact that it ran correctly and generated a plot is a good
sign.
> >>> However, the plot shows that there are areas of
> >>> precip values of -999. The ncview tool shows the same
situation. Are
> >>> these areas actually supposed to be bad data
> >>> (-9999)? If so, changing values -999 to -9999 might fix the
problem.
> >>> Also, it looks like there might be an indexing
> >>> problem or perhaps a regridding problem because the areas where
precip
> >>> values are normal looks a bit skewed. Maybe
> >>> check the regridding process? Please let me know if you have
any
> >>> questions.
> >>>
> >>> Thanks,
> >>>
> >>> Paul
> >>>
> >>>
> >>>
> >>> On 07/11/2012 11:58 PM, Haonan Chen via RT wrote:
> >>>>
> >>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
> >>>>
> >>>> Hi Ellen and Paul
> >>>>
> >>>> How are you doing?
> >>>>
> >>>> This is Haonan, the guy working with Ellen on the NetCDF format
> >>> conversion
> >>>> problems. I changed the fields according to Paul's comments
(they are
> >>> very
> >>>> helpful). However, I still have one question here: In the
global
> >>> attributes
> >>>> of your sample file, there was a field like following.
> >>>>
> >>>> *FileOrigins = "File wrfprs_ruc13_12.tm00_G212.nc generated
> >>> 20120710_171301
> >>>> UTC on host orval by the MET pcp_combine tool" ;*
> >>>
> >>>>
> >>>> However, I am not really using host orval (a machine?) and the
MET
> >>>> pcp_combine tool even I specified something about MET_tool. Do
I have
> to
> >>>> make the FileOrigins exactly the same with your sample file?
> >>>>
> >>>> I am attaching a example result from my program. I guess you
should be
> >>> able
> >>>> to open it. Could you please help us check it? Thanks so much.
> >>>>
> >>>> Have a good night.
> >>>>
> >>>> Haonan
> >>>>
> >>>> On Tue, Jul 10, 2012 at 1:20 PM, Ellen Sukovich <
> >>> ellen.sukovich at noaa.gov>wrote:
> >>>>
> >>>>> Hi Haonan,
> >>>>>
> >>>>> Could you put your netcdf file into the format listed below? I
am not
> >>>>> familiar with netcdf so I don't know if the instructions below
make
> >>> sense.
> >>>>> See email below this email.
> >>>>>
> >>>>> Ellen
> >>>>>
> >>>>> {
> >>>>> dimensions:
> >>>>> lat = 224 ;
> >>>>> lon = 464 ;
> >>>>> variables:
> >>>>> float lat(lat, lon) ;
> >>>>> lat:long_name = "latitude" ;
> >>>>> lat:units = "degrees_north" ;
> >>>>> lat:standard_name = "latitude" ;
> >>>>> float lon(lat, lon) ;
> >>>>> lon:long_name = "longitude" ;
> >>>>> lon:units = "degrees_east" ;
> >>>>> lon:standard_name = "longitude" ;
> >>>>> float APCP_12(lat, lon) ;
> >>>>> APCP_12:name = "APCP_12" ;
> >>>>> APCP_12:long_name = "Total precipitation" ;
> >>>>> APCP_12:level = "A12" ;
> >>>>> APCP_12:units = "kg/m^2" ;
> >>>>> APCP_12:_FillValue = -9999.f ;
> >>>>> APCP_12:init_time = "20050807_000000" ;
> >>>>> APCP_12:init_time_ut = 1123372800 ;
> >>>>> APCP_12:valid_time = "20050807_120000" ;
> >>>>> APCP_12:valid_time_ut = 1123416000 ;
> >>>>> APCP_12:accum_time = "120000" ;
> >>>>> APCP_12:accum_time_sec = 43200 ;
> >>>>>
> >>>>> // global attributes:
> >>>>> :FileOrigins = "File
> wrfprs_ruc13_12.tm00_G212.ncgenerated 20120710_171301 UTC on host
orval by
> the
> >>>>> MET pcp_combine tool" ;
> >>>>> :MET_version = "V4.0" ;
> >>>>> :MET_tool = "pcp_combine" ;
> >>>>> :RunCommand = "Addition: 1 files." ;
> >>>>> :Projection = "LatLon" ;
> >>>>> :lat_ll = "25.063000 degrees_north" ;
> >>>>> :lon_ll = "-124.938000 degrees_east" ;
> >>>>> :delta_lat = "0.125000 degrees" ;
> >>>>> :delta_lon = "0.125000 degrees" ;
> >>>>> :Nlat = "224 grid_points" ;
> >>>>> :Nlon = "464 grid_points" ;
> >>>>> }
> >>>>>
> >>>>>
> >>>>> -------- Original Message -------- Subject: Re: [
> rt.rap.ucar.edu#57358]
> >>>>> MET netcdf to grib1 converter yet? Date: Tue, 10 Jul 2012
13:14:06
> >>> -0600 From:
> >>>>> Paul Oldenburg via RT <met_help at ucar.edu> <met_help at ucar.edu>
> >>> Reply-To:
> >>>
> >>>>> met_help at ucar.edu To: Ellen.Sukovich at noaa.gov CC:
> >>>>> met_help at mailman.ucar.edu
> >>>>>
> >>>>> Ellen,
> >>>>>
> >>>>> If your data dude can put it into the format shown below, MET
should
> >>> be able to read it. I will probably hold off on
> >>>>> the conversion script unless you would still like me to put it
> >>> together. The format is really just a matter of having
> >>>>> certain attributes present with specific names and values. I
also
> >>> showed how I regridded (to lat/lon projection) and
> >>>>> converted a test file included in the MET tarball file from
GRIB to
> >>> MET NetCDF. If you have any questions about this
> >>>>> format, please let us know.
> >>>>>
> >>>>> Paul
> >>>>>
> >>>>>
> >>>>> [pgoldenb at orval 20120710.sukovich]$ copygb.exe \
> >>>>> -xg 110 \
> >>>>>
$MET_BASE/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212
> \
> >>>>> wrfprs_ruc13_12.tm00_G212.grib
> >>>>> [pgoldenb at orval 20120710.sukovich]$ $MET_BASE/bin/pcp_combine
-add \
> >>>>> wrfprs_ruc13_12.tm00_G212.grib 12 \
> >>>>> wrfprs_ruc13_12.tm00_G212.nc
> >>>>> DEBUG 1: Reading input file: wrfprs_ruc13_12.tm00_G212.grib
> >>>>> DEBUG 1: Writing output file: wrfprs_ruc13_12.tm00_G212.nc
> >>>>> [pgoldenb at orval 20120710.sukovich]$ ncdump -h
> >>> wrfprs_ruc13_12.tm00_G212.nc
> >>>>> netcdf wrfprs_ruc13_12.tm00_G212 {
> >>>>> dimensions:
> >>>>> lat = 224 ;
> >>>>> lon = 464 ;
> >>>>> variables:
> >>>>> float lat(lat, lon) ;
> >>>>> lat:long_name = "latitude" ;
> >>>>> lat:units = "degrees_north" ;
> >>>>> lat:standard_name = "latitude" ;
> >>>>> float lon(lat, lon) ;
> >>>>> lon:long_name = "longitude" ;
> >>>>> lon:units = "degrees_east" ;
> >>>>> lon:standard_name = "longitude" ;
> >>>>> float APCP_12(lat, lon) ;
> >>>>> APCP_12:name = "APCP_12" ;
> >>>>> APCP_12:long_name = "Total precipitation" ;
> >>>>> APCP_12:level = "A12" ;
> >>>>> APCP_12:units = "kg/m^2" ;
> >>>>> APCP_12:_FillValue = -9999.f ;
> >>>>> APCP_12:init_time = "20050807_000000" ;
> >>>>> APCP_12:init_time_ut = 1123372800 ;
> >>>>> APCP_12:valid_time = "20050807_120000" ;
> >>>>> APCP_12:valid_time_ut = 1123416000 ;
> >>>>> APCP_12:accum_time = "120000" ;
> >>>>> APCP_12:accum_time_sec = 43200 ;
> >>>>>
> >>>>> // global attributes:
> >>>>> :FileOrigins = "File
> wrfprs_ruc13_12.tm00_G212.ncgenerated 20120710_171301 UTC on host
orval by
> the
> >>>>> MET pcp_combine tool" ;
> >>>>> :MET_version = "V4.0" ;
> >>>>> :MET_tool = "pcp_combine" ;
> >>>>> :RunCommand = "Addition: 1 files." ;
> >>>>> :Projection = "LatLon" ;
> >>>>> :lat_ll = "25.063000 degrees_north" ;
> >>>>> :lon_ll = "-124.938000 degrees_east" ;
> >>>>> :delta_lat = "0.125000 degrees" ;
> >>>>> :delta_lon = "0.125000 degrees" ;
> >>>>> :Nlat = "224 grid_points" ;
> >>>>> :Nlon = "464 grid_points" ;
> >>>>> }
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>>
> >>
>
>
>
>
------------------------------------------------
Subject: Re: Fw: [rt.rap.ucar.edu #57358] MET netcdf to grib1 converter yet?
From: Paul Oldenburg
Time: Thu Jul 12 13:15:12 2012
Ellen & Haonan,
Haonan can download the MET source and build it on a linux system
using the instructions here:
http://www.dtcenter.org/met/users/support/online_tutorial/METv3.1/compilation/index.php
Paul
On 07/12/2012 12:58 PM, Ellen.Sukovich at noaa.gov via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>
> Hi Paul,
>
> I don't believe Haonan has MET access on his system. He is up at
CSU.
>
> Ellen
>
> On Thu, Jul 12, 2012 at 12:25 PM, Paul Oldenburg via RT
> <met_help at ucar.edu>wrote:
>
>> Haonan,
>>
>> I plotted the new file and now the precip values are reasonable
(~0-10
>> mm). It still looks like there is a skewing
>> problem in the regridding, but hopefully it won't be too hard to
fix.
>> Remember that you can test your MET NetCDF output
>> using plot_data_plane as I showed in an earlier email. This will
show you
>> how MET has read in the gridded data. I also
>> use ncview, which is quicker and easier. Please let me know if you
have
>> any questions.
>>
>> Paul
>>
>>
>> On 07/12/2012 12:20 PM, Haonan Chen via RT wrote:
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>>>
>>> Hi Paul
>>>
>>> Yes. -999 is actually the bad value. And I just changed -999 to
-9999.
>> The
>>> data was originally in HRAP coordinates (a rectangular area), I
only
>>> converted the HRAP coordinates to Lat/Lons. So the output image
should be
>>> skewed due to the polar properties of the Earth. I am also
attaching a
>> plot
>>> to show the map. It might be helpful to see the overall shape.
>>> We will regrid the data to a rectangular Lat/Lon area if needed.
>>>
>>> Thanks so much, Paul.
>>>
>>> Haonan
>>>
>>>
>>> On Thu, Jul 12, 2012 at 9:42 AM, Ellen Sukovich
<ellen.sukovich at noaa.gov
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Jul 12, 2012 at 8:40 AM, Paul Oldenburg via RT <
>> met_help at ucar.edu>wrote:
>>>>
>>>>> Ellen & Haonan,
>>>>>
>>>>> You are getting close. I used the MET utility plot_data_plane
to plot
>>>>> the APCP_12 field in the data file that you sent me:
>>>>>
>>>>> $ $MET_BASE/bin/plot_data_plane GAGEONLY2012031417z_MET_2.nc
plot.ps
>> 'name="APCP_12";level="(*,*)";'
>>>>> DEBUG 1: Opening data file: GAGEONLY2012031417z_MET_2.nc
>>>>> DEBUG 1: Creating postscript file: plot.ps
>>>>>
>>>>> The fact that it ran correctly and generated a plot is a good
sign.
>>>>> However, the plot shows that there are areas of
>>>>> precip values of -999. The ncview tool shows the same
situation. Are
>>>>> these areas actually supposed to be bad data
>>>>> (-9999)? If so, changing values -999 to -9999 might fix the
problem.
>>>>> Also, it looks like there might be an indexing
>>>>> problem or perhaps a regridding problem because the areas where
precip
>>>>> values are normal looks a bit skewed. Maybe
>>>>> check the regridding process? Please let me know if you have
any
>>>>> questions.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Paul
>>>>>
>>>>>
>>>>>
>>>>> On 07/11/2012 11:58 PM, Haonan Chen via RT wrote:
>>>>>>
>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>>>>>>
>>>>>> Hi Ellen and Paul
>>>>>>
>>>>>> How are you doing?
>>>>>>
>>>>>> This is Haonan, the guy working with Ellen on the NetCDF format
>>>>> conversion
>>>>>> problems. I changed the fields according to Paul's comments
(they are
>>>>> very
>>>>>> helpful). However, I still have one question here: In the
global
>>>>> attributes
>>>>>> of your sample file, there was a field like following.
>>>>>>
>>>>>> *FileOrigins = "File wrfprs_ruc13_12.tm00_G212.nc generated
>>>>> 20120710_171301
>>>>>> UTC on host orval by the MET pcp_combine tool" ;*
>>>>>
>>>>>>
>>>>>> However, I am not really using host orval (a machine?) and the
MET
>>>>>> pcp_combine tool even I specified something about MET_tool. Do
I have
>> to
>>>>>> make the FileOrigins exactly the same with your sample file?
>>>>>>
>>>>>> I am attaching a example result from my program. I guess you
should be
>>>>> able
>>>>>> to open it. Could you please help us check it? Thanks so much.
>>>>>>
>>>>>> Have a good night.
>>>>>>
>>>>>> Haonan
>>>>>>
>>>>>> On Tue, Jul 10, 2012 at 1:20 PM, Ellen Sukovich <
>>>>> ellen.sukovich at noaa.gov>wrote:
>>>>>>
>>>>>>> Hi Haonan,
>>>>>>>
>>>>>>> Could you put your netcdf file into the format listed below? I
am not
>>>>>>> familiar with netcdf so I don't know if the instructions below
make
>>>>> sense.
>>>>>>> See email below this email.
>>>>>>>
>>>>>>> Ellen
>>>>>>>
>>>>>>> {
>>>>>>> dimensions:
>>>>>>> lat = 224 ;
>>>>>>> lon = 464 ;
>>>>>>> variables:
>>>>>>> float lat(lat, lon) ;
>>>>>>> lat:long_name = "latitude" ;
>>>>>>> lat:units = "degrees_north" ;
>>>>>>> lat:standard_name = "latitude" ;
>>>>>>> float lon(lat, lon) ;
>>>>>>> lon:long_name = "longitude" ;
>>>>>>> lon:units = "degrees_east" ;
>>>>>>> lon:standard_name = "longitude" ;
>>>>>>> float APCP_12(lat, lon) ;
>>>>>>> APCP_12:name = "APCP_12" ;
>>>>>>> APCP_12:long_name = "Total precipitation"
;
>>>>>>> APCP_12:level = "A12" ;
>>>>>>> APCP_12:units = "kg/m^2" ;
>>>>>>> APCP_12:_FillValue = -9999.f ;
>>>>>>> APCP_12:init_time = "20050807_000000" ;
>>>>>>> APCP_12:init_time_ut = 1123372800 ;
>>>>>>> APCP_12:valid_time = "20050807_120000" ;
>>>>>>> APCP_12:valid_time_ut = 1123416000 ;
>>>>>>> APCP_12:accum_time = "120000" ;
>>>>>>> APCP_12:accum_time_sec = 43200 ;
>>>>>>>
>>>>>>> // global attributes:
>>>>>>> :FileOrigins = "File
>> wrfprs_ruc13_12.tm00_G212.ncgenerated 20120710_171301 UTC on host
orval by
>> the
>>>>>>> MET pcp_combine tool" ;
>>>>>>> :MET_version = "V4.0" ;
>>>>>>> :MET_tool = "pcp_combine" ;
>>>>>>> :RunCommand = "Addition: 1 files." ;
>>>>>>> :Projection = "LatLon" ;
>>>>>>> :lat_ll = "25.063000 degrees_north" ;
>>>>>>> :lon_ll = "-124.938000 degrees_east" ;
>>>>>>> :delta_lat = "0.125000 degrees" ;
>>>>>>> :delta_lon = "0.125000 degrees" ;
>>>>>>> :Nlat = "224 grid_points" ;
>>>>>>> :Nlon = "464 grid_points" ;
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> -------- Original Message -------- Subject: Re: [
>> rt.rap.ucar.edu#57358]
>>>>>>> MET netcdf to grib1 converter yet? Date: Tue, 10 Jul 2012
13:14:06
>>>>> -0600 From:
>>>>>>> Paul Oldenburg via RT <met_help at ucar.edu> <met_help at ucar.edu>
>>>>> Reply-To:
>>>>>
>>>>>>> met_help at ucar.edu To: Ellen.Sukovich at noaa.gov CC:
>>>>>>> met_help at mailman.ucar.edu
>>>>>>>
>>>>>>> Ellen,
>>>>>>>
>>>>>>> If your data dude can put it into the format shown below, MET
should
>>>>> be able to read it. I will probably hold off on
>>>>>>> the conversion script unless you would still like me to put it
>>>>> together. The format is really just a matter of having
>>>>>>> certain attributes present with specific names and values. I
also
>>>>> showed how I regridded (to lat/lon projection) and
>>>>>>> converted a test file included in the MET tarball file from
GRIB to
>>>>> MET NetCDF. If you have any questions about this
>>>>>>> format, please let us know.
>>>>>>>
>>>>>>> Paul
>>>>>>>
>>>>>>>
>>>>>>> [pgoldenb at orval 20120710.sukovich]$ copygb.exe \
>>>>>>> -xg 110 \
>>>>>>>
$MET_BASE/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212
>> \
>>>>>>> wrfprs_ruc13_12.tm00_G212.grib
>>>>>>> [pgoldenb at orval 20120710.sukovich]$ $MET_BASE/bin/pcp_combine
-add \
>>>>>>> wrfprs_ruc13_12.tm00_G212.grib 12 \
>>>>>>> wrfprs_ruc13_12.tm00_G212.nc
>>>>>>> DEBUG 1: Reading input file: wrfprs_ruc13_12.tm00_G212.grib
>>>>>>> DEBUG 1: Writing output file: wrfprs_ruc13_12.tm00_G212.nc
>>>>>>> [pgoldenb at orval 20120710.sukovich]$ ncdump -h
>>>>> wrfprs_ruc13_12.tm00_G212.nc
>>>>>>> netcdf wrfprs_ruc13_12.tm00_G212 {
>>>>>>> dimensions:
>>>>>>> lat = 224 ;
>>>>>>> lon = 464 ;
>>>>>>> variables:
>>>>>>> float lat(lat, lon) ;
>>>>>>> lat:long_name = "latitude" ;
>>>>>>> lat:units = "degrees_north" ;
>>>>>>> lat:standard_name = "latitude" ;
>>>>>>> float lon(lat, lon) ;
>>>>>>> lon:long_name = "longitude" ;
>>>>>>> lon:units = "degrees_east" ;
>>>>>>> lon:standard_name = "longitude" ;
>>>>>>> float APCP_12(lat, lon) ;
>>>>>>> APCP_12:name = "APCP_12" ;
>>>>>>> APCP_12:long_name = "Total precipitation"
;
>>>>>>> APCP_12:level = "A12" ;
>>>>>>> APCP_12:units = "kg/m^2" ;
>>>>>>> APCP_12:_FillValue = -9999.f ;
>>>>>>> APCP_12:init_time = "20050807_000000" ;
>>>>>>> APCP_12:init_time_ut = 1123372800 ;
>>>>>>> APCP_12:valid_time = "20050807_120000" ;
>>>>>>> APCP_12:valid_time_ut = 1123416000 ;
>>>>>>> APCP_12:accum_time = "120000" ;
>>>>>>> APCP_12:accum_time_sec = 43200 ;
>>>>>>>
>>>>>>> // global attributes:
>>>>>>> :FileOrigins = "File
>> wrfprs_ruc13_12.tm00_G212.ncgenerated 20120710_171301 UTC on host
orval by
>> the
>>>>>>> MET pcp_combine tool" ;
>>>>>>> :MET_version = "V4.0" ;
>>>>>>> :MET_tool = "pcp_combine" ;
>>>>>>> :RunCommand = "Addition: 1 files." ;
>>>>>>> :Projection = "LatLon" ;
>>>>>>> :lat_ll = "25.063000 degrees_north" ;
>>>>>>> :lon_ll = "-124.938000 degrees_east" ;
>>>>>>> :delta_lat = "0.125000 degrees" ;
>>>>>>> :delta_lon = "0.125000 degrees" ;
>>>>>>> :Nlat = "224 grid_points" ;
>>>>>>> :Nlon = "464 grid_points" ;
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>>
>>
------------------------------------------------
Subject: Re: Fw: [rt.rap.ucar.edu #57358] MET netcdf to grib1 converter yet?
From: Paul Oldenburg
Time: Thu Jul 12 13:28:23 2012
Ellen & Haonan,
Also, as I mentioned in a previous email, the ncview utility that is
packaged with NetCDF also can be used to plot the
data in the NetCDF file.
Paul
On 07/12/2012 01:15 PM, Paul Oldenburg wrote:
> Ellen & Haonan,
>
> Haonan can download the MET source and build it on a linux system
using the instructions here:
>
>
http://www.dtcenter.org/met/users/support/online_tutorial/METv3.1/compilation/index.php
>
> Paul
>
>
> On 07/12/2012 12:58 PM, Ellen.Sukovich at noaa.gov via RT wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>>
>> Hi Paul,
>>
>> I don't believe Haonan has MET access on his system. He is up at
CSU.
>>
>> Ellen
>>
>> On Thu, Jul 12, 2012 at 12:25 PM, Paul Oldenburg via RT
>> <met_help at ucar.edu>wrote:
>>
>>> Haonan,
>>>
>>> I plotted the new file and now the precip values are reasonable
(~0-10
>>> mm). It still looks like there is a skewing
>>> problem in the regridding, but hopefully it won't be too hard to
fix.
>>> Remember that you can test your MET NetCDF output
>>> using plot_data_plane as I showed in an earlier email. This will
show you
>>> how MET has read in the gridded data. I also
>>> use ncview, which is quicker and easier. Please let me know if
you have
>>> any questions.
>>>
>>> Paul
>>>
>>>
>>> On 07/12/2012 12:20 PM, Haonan Chen via RT wrote:
>>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>>>>
>>>> Hi Paul
>>>>
>>>> Yes. -999 is actually the bad value. And I just changed -999 to
-9999.
>>> The
>>>> data was originally in HRAP coordinates (a rectangular area), I
only
>>>> converted the HRAP coordinates to Lat/Lons. So the output image
should be
>>>> skewed due to the polar properties of the Earth. I am also
attaching a
>>> plot
>>>> to show the map. It might be helpful to see the overall shape.
>>>> We will regrid the data to a rectangular Lat/Lon area if needed.
>>>>
>>>> Thanks so much, Paul.
>>>>
>>>> Haonan
>>>>
>>>>
>>>> On Thu, Jul 12, 2012 at 9:42 AM, Ellen Sukovich
<ellen.sukovich at noaa.gov
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Jul 12, 2012 at 8:40 AM, Paul Oldenburg via RT <
>>> met_help at ucar.edu>wrote:
>>>>>
>>>>>> Ellen & Haonan,
>>>>>>
>>>>>> You are getting close. I used the MET utility plot_data_plane
to plot
>>>>>> the APCP_12 field in the data file that you sent me:
>>>>>>
>>>>>> $ $MET_BASE/bin/plot_data_plane GAGEONLY2012031417z_MET_2.nc
plot.ps
>>> 'name="APCP_12";level="(*,*)";'
>>>>>> DEBUG 1: Opening data file: GAGEONLY2012031417z_MET_2.nc
>>>>>> DEBUG 1: Creating postscript file: plot.ps
>>>>>>
>>>>>> The fact that it ran correctly and generated a plot is a good
sign.
>>>>>> However, the plot shows that there are areas of
>>>>>> precip values of -999. The ncview tool shows the same
situation. Are
>>>>>> these areas actually supposed to be bad data
>>>>>> (-9999)? If so, changing values -999 to -9999 might fix the
problem.
>>>>>> Also, it looks like there might be an indexing
>>>>>> problem or perhaps a regridding problem because the areas where
precip
>>>>>> values are normal looks a bit skewed. Maybe
>>>>>> check the regridding process? Please let me know if you have
any
>>>>>> questions.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Paul
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 07/11/2012 11:58 PM, Haonan Chen via RT wrote:
>>>>>>>
>>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358
>
>>>>>>>
>>>>>>> Hi Ellen and Paul
>>>>>>>
>>>>>>> How are you doing?
>>>>>>>
>>>>>>> This is Haonan, the guy working with Ellen on the NetCDF
format
>>>>>> conversion
>>>>>>> problems. I changed the fields according to Paul's comments
(they are
>>>>>> very
>>>>>>> helpful). However, I still have one question here: In the
global
>>>>>> attributes
>>>>>>> of your sample file, there was a field like following.
>>>>>>>
>>>>>>> *FileOrigins = "File wrfprs_ruc13_12.tm00_G212.nc generated
>>>>>> 20120710_171301
>>>>>>> UTC on host orval by the MET pcp_combine tool" ;*
>>>>>>
>>>>>>>
>>>>>>> However, I am not really using host orval (a machine?) and the
MET
>>>>>>> pcp_combine tool even I specified something about MET_tool. Do
I have
>>> to
>>>>>>> make the FileOrigins exactly the same with your sample file?
>>>>>>>
>>>>>>> I am attaching a example result from my program. I guess you
should be
>>>>>> able
>>>>>>> to open it. Could you please help us check it? Thanks so much.
>>>>>>>
>>>>>>> Have a good night.
>>>>>>>
>>>>>>> Haonan
>>>>>>>
>>>>>>> On Tue, Jul 10, 2012 at 1:20 PM, Ellen Sukovich <
>>>>>> ellen.sukovich at noaa.gov>wrote:
>>>>>>>
>>>>>>>> Hi Haonan,
>>>>>>>>
>>>>>>>> Could you put your netcdf file into the format listed below?
I am not
>>>>>>>> familiar with netcdf so I don't know if the instructions
below make
>>>>>> sense.
>>>>>>>> See email below this email.
>>>>>>>>
>>>>>>>> Ellen
>>>>>>>>
>>>>>>>> {
>>>>>>>> dimensions:
>>>>>>>> lat = 224 ;
>>>>>>>> lon = 464 ;
>>>>>>>> variables:
>>>>>>>> float lat(lat, lon) ;
>>>>>>>> lat:long_name = "latitude" ;
>>>>>>>> lat:units = "degrees_north" ;
>>>>>>>> lat:standard_name = "latitude" ;
>>>>>>>> float lon(lat, lon) ;
>>>>>>>> lon:long_name = "longitude" ;
>>>>>>>> lon:units = "degrees_east" ;
>>>>>>>> lon:standard_name = "longitude" ;
>>>>>>>> float APCP_12(lat, lon) ;
>>>>>>>> APCP_12:name = "APCP_12" ;
>>>>>>>> APCP_12:long_name = "Total precipitation"
;
>>>>>>>> APCP_12:level = "A12" ;
>>>>>>>> APCP_12:units = "kg/m^2" ;
>>>>>>>> APCP_12:_FillValue = -9999.f ;
>>>>>>>> APCP_12:init_time = "20050807_000000" ;
>>>>>>>> APCP_12:init_time_ut = 1123372800 ;
>>>>>>>> APCP_12:valid_time = "20050807_120000" ;
>>>>>>>> APCP_12:valid_time_ut = 1123416000 ;
>>>>>>>> APCP_12:accum_time = "120000" ;
>>>>>>>> APCP_12:accum_time_sec = 43200 ;
>>>>>>>>
>>>>>>>> // global attributes:
>>>>>>>> :FileOrigins = "File
>>> wrfprs_ruc13_12.tm00_G212.ncgenerated 20120710_171301 UTC on host
orval by
>>> the
>>>>>>>> MET pcp_combine tool" ;
>>>>>>>> :MET_version = "V4.0" ;
>>>>>>>> :MET_tool = "pcp_combine" ;
>>>>>>>> :RunCommand = "Addition: 1 files." ;
>>>>>>>> :Projection = "LatLon" ;
>>>>>>>> :lat_ll = "25.063000 degrees_north" ;
>>>>>>>> :lon_ll = "-124.938000 degrees_east" ;
>>>>>>>> :delta_lat = "0.125000 degrees" ;
>>>>>>>> :delta_lon = "0.125000 degrees" ;
>>>>>>>> :Nlat = "224 grid_points" ;
>>>>>>>> :Nlon = "464 grid_points" ;
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> -------- Original Message -------- Subject: Re: [
>>> rt.rap.ucar.edu#57358]
>>>>>>>> MET netcdf to grib1 converter yet? Date: Tue, 10 Jul 2012
13:14:06
>>>>>> -0600 From:
>>>>>>>> Paul Oldenburg via RT <met_help at ucar.edu> <met_help at ucar.edu>
>>>>>> Reply-To:
>>>>>>
>>>>>>>> met_help at ucar.edu To: Ellen.Sukovich at noaa.gov CC:
>>>>>>>> met_help at mailman.ucar.edu
>>>>>>>>
>>>>>>>> Ellen,
>>>>>>>>
>>>>>>>> If your data dude can put it into the format shown below, MET
should
>>>>>> be able to read it. I will probably hold off on
>>>>>>>> the conversion script unless you would still like me to put
it
>>>>>> together. The format is really just a matter of having
>>>>>>>> certain attributes present with specific names and values. I
also
>>>>>> showed how I regridded (to lat/lon projection) and
>>>>>>>> converted a test file included in the MET tarball file from
GRIB to
>>>>>> MET NetCDF. If you have any questions about this
>>>>>>>> format, please let us know.
>>>>>>>>
>>>>>>>> Paul
>>>>>>>>
>>>>>>>>
>>>>>>>> [pgoldenb at orval 20120710.sukovich]$ copygb.exe \
>>>>>>>> -xg 110 \
>>>>>>>>
$MET_BASE/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212
>>> \
>>>>>>>> wrfprs_ruc13_12.tm00_G212.grib
>>>>>>>> [pgoldenb at orval 20120710.sukovich]$ $MET_BASE/bin/pcp_combine
-add \
>>>>>>>> wrfprs_ruc13_12.tm00_G212.grib 12 \
>>>>>>>> wrfprs_ruc13_12.tm00_G212.nc
>>>>>>>> DEBUG 1: Reading input file: wrfprs_ruc13_12.tm00_G212.grib
>>>>>>>> DEBUG 1: Writing output file: wrfprs_ruc13_12.tm00_G212.nc
>>>>>>>> [pgoldenb at orval 20120710.sukovich]$ ncdump -h
>>>>>> wrfprs_ruc13_12.tm00_G212.nc
>>>>>>>> netcdf wrfprs_ruc13_12.tm00_G212 {
>>>>>>>> dimensions:
>>>>>>>> lat = 224 ;
>>>>>>>> lon = 464 ;
>>>>>>>> variables:
>>>>>>>> float lat(lat, lon) ;
>>>>>>>> lat:long_name = "latitude" ;
>>>>>>>> lat:units = "degrees_north" ;
>>>>>>>> lat:standard_name = "latitude" ;
>>>>>>>> float lon(lat, lon) ;
>>>>>>>> lon:long_name = "longitude" ;
>>>>>>>> lon:units = "degrees_east" ;
>>>>>>>> lon:standard_name = "longitude" ;
>>>>>>>> float APCP_12(lat, lon) ;
>>>>>>>> APCP_12:name = "APCP_12" ;
>>>>>>>> APCP_12:long_name = "Total precipitation"
;
>>>>>>>> APCP_12:level = "A12" ;
>>>>>>>> APCP_12:units = "kg/m^2" ;
>>>>>>>> APCP_12:_FillValue = -9999.f ;
>>>>>>>> APCP_12:init_time = "20050807_000000" ;
>>>>>>>> APCP_12:init_time_ut = 1123372800 ;
>>>>>>>> APCP_12:valid_time = "20050807_120000" ;
>>>>>>>> APCP_12:valid_time_ut = 1123416000 ;
>>>>>>>> APCP_12:accum_time = "120000" ;
>>>>>>>> APCP_12:accum_time_sec = 43200 ;
>>>>>>>>
>>>>>>>> // global attributes:
>>>>>>>> :FileOrigins = "File
>>> wrfprs_ruc13_12.tm00_G212.ncgenerated 20120710_171301 UTC on host
orval by
>>> the
>>>>>>>> MET pcp_combine tool" ;
>>>>>>>> :MET_version = "V4.0" ;
>>>>>>>> :MET_tool = "pcp_combine" ;
>>>>>>>> :RunCommand = "Addition: 1 files." ;
>>>>>>>> :Projection = "LatLon" ;
>>>>>>>> :lat_ll = "25.063000 degrees_north" ;
>>>>>>>> :lon_ll = "-124.938000 degrees_east" ;
>>>>>>>> :delta_lat = "0.125000 degrees" ;
>>>>>>>> :delta_lon = "0.125000 degrees" ;
>>>>>>>> :Nlat = "224 grid_points" ;
>>>>>>>> :Nlon = "464 grid_points" ;
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>>
>>>
>
>
------------------------------------------------
Subject: MET netcdf to grib1 converter yet?
From: Ellen.Sukovich at noaa.gov
Time: Fri Jul 13 09:00:00 2012
Hi Paul,
I still can't get the MODE to work on Haonan's file (see attached for
file). To test the file I use mode to compare the file to itself:
% mode GAGEONLY2012031417z_MET.nc GAGEONLY2012031417z_MET.nc
RadarQPE.config -outdir .
and I get the following message:
Forecast File: GAGEONLY2012031417z_MET.nc
Observation File: GAGEONLY2012031417z_MET.nc
Match Config File: RadarQPE.config
Merge Config File: RadarQPE.config
NetCDF: Attribute not found
I know the config file works on Stage IV data but is the config file
wrong for this data (see attached)? Note: I am using METv3.0 if that
makes a difference.
Thanks again for all your help!
Ellen
On 7/12/2012 1:28 PM, Paul Oldenburg via RT wrote:
> Ellen & Haonan,
>
> Also, as I mentioned in a previous email, the ncview utility that is
packaged with NetCDF also can be used to plot the
> data in the NetCDF file.
>
> Paul
>
>
> On 07/12/2012 01:15 PM, Paul Oldenburg wrote:
>> Ellen & Haonan,
>>
>> Haonan can download the MET source and build it on a linux system
using the instructions here:
>>
>>
http://www.dtcenter.org/met/users/support/online_tutorial/METv3.1/compilation/index.php
>>
>> Paul
>>
>>
>> On 07/12/2012 12:58 PM, Ellen.Sukovich at noaa.gov via RT wrote:
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>>>
>>> Hi Paul,
>>>
>>> I don't believe Haonan has MET access on his system. He is up at
CSU.
>>>
>>> Ellen
>>>
>>> On Thu, Jul 12, 2012 at 12:25 PM, Paul Oldenburg via RT
>>> <met_help at ucar.edu>wrote:
>>>
>>>> Haonan,
>>>>
>>>> I plotted the new file and now the precip values are reasonable
(~0-10
>>>> mm). It still looks like there is a skewing
>>>> problem in the regridding, but hopefully it won't be too hard to
fix.
>>>> Remember that you can test your MET NetCDF output
>>>> using plot_data_plane as I showed in an earlier email. This will
show you
>>>> how MET has read in the gridded data. I also
>>>> use ncview, which is quicker and easier. Please let me know if
you have
>>>> any questions.
>>>>
>>>> Paul
>>>>
>>>>
>>>> On 07/12/2012 12:20 PM, Haonan Chen via RT wrote:
>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>>>>>
>>>>> Hi Paul
>>>>>
>>>>> Yes. -999 is actually the bad value. And I just changed -999 to
-9999.
>>>> The
>>>>> data was originally in HRAP coordinates (a rectangular area), I
only
>>>>> converted the HRAP coordinates to Lat/Lons. So the output image
should be
>>>>> skewed due to the polar properties of the Earth. I am also
attaching a
>>>> plot
>>>>> to show the map. It might be helpful to see the overall shape.
>>>>> We will regrid the data to a rectangular Lat/Lon area if needed.
>>>>>
>>>>> Thanks so much, Paul.
>>>>>
>>>>> Haonan
>>>>>
>>>>>
>>>>> On Thu, Jul 12, 2012 at 9:42 AM, Ellen Sukovich
<ellen.sukovich at noaa.gov
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> On Thu, Jul 12, 2012 at 8:40 AM, Paul Oldenburg via RT <
>>>> met_help at ucar.edu>wrote:
>>>>>>> Ellen & Haonan,
>>>>>>>
>>>>>>> You are getting close. I used the MET utility plot_data_plane
to plot
>>>>>>> the APCP_12 field in the data file that you sent me:
>>>>>>>
>>>>>>> $ $MET_BASE/bin/plot_data_plane GAGEONLY2012031417z_MET_2.nc
plot.ps
>>>> 'name="APCP_12";level="(*,*)";'
>>>>>>> DEBUG 1: Opening data file: GAGEONLY2012031417z_MET_2.nc
>>>>>>> DEBUG 1: Creating postscript file: plot.ps
>>>>>>>
>>>>>>> The fact that it ran correctly and generated a plot is a good
sign.
>>>>>>> However, the plot shows that there are areas of
>>>>>>> precip values of -999. The ncview tool shows the same
situation. Are
>>>>>>> these areas actually supposed to be bad data
>>>>>>> (-9999)? If so, changing values -999 to -9999 might fix the
problem.
>>>>>>> Also, it looks like there might be an indexing
>>>>>>> problem or perhaps a regridding problem because the areas
where precip
>>>>>>> values are normal looks a bit skewed. Maybe
>>>>>>> check the regridding process? Please let me know if you have
any
>>>>>>> questions.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Paul
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 07/11/2012 11:58 PM, Haonan Chen via RT wrote:
>>>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358
>
>>>>>>>>
>>>>>>>> Hi Ellen and Paul
>>>>>>>>
>>>>>>>> How are you doing?
>>>>>>>>
>>>>>>>> This is Haonan, the guy working with Ellen on the NetCDF
format
>>>>>>> conversion
>>>>>>>> problems. I changed the fields according to Paul's comments
(they are
>>>>>>> very
>>>>>>>> helpful). However, I still have one question here: In the
global
>>>>>>> attributes
>>>>>>>> of your sample file, there was a field like following.
>>>>>>>>
>>>>>>>> *FileOrigins = "File wrfprs_ruc13_12.tm00_G212.nc generated
>>>>>>> 20120710_171301
>>>>>>>> UTC on host orval by the MET pcp_combine tool" ;*
>>>>>>>> However, I am not really using host orval (a machine?) and
the MET
>>>>>>>> pcp_combine tool even I specified something about MET_tool.
Do I have
>>>> to
>>>>>>>> make the FileOrigins exactly the same with your sample file?
>>>>>>>>
>>>>>>>> I am attaching a example result from my program. I guess you
should be
>>>>>>> able
>>>>>>>> to open it. Could you please help us check it? Thanks so
much.
>>>>>>>>
>>>>>>>> Have a good night.
>>>>>>>>
>>>>>>>> Haonan
>>>>>>>>
>>>>>>>> On Tue, Jul 10, 2012 at 1:20 PM, Ellen Sukovich <
>>>>>>> ellen.sukovich at noaa.gov>wrote:
>>>>>>>>> Hi Haonan,
>>>>>>>>>
>>>>>>>>> Could you put your netcdf file into the format listed below?
I am not
>>>>>>>>> familiar with netcdf so I don't know if the instructions
below make
>>>>>>> sense.
>>>>>>>>> See email below this email.
>>>>>>>>>
>>>>>>>>> Ellen
>>>>>>>>>
>>>>>>>>> {
>>>>>>>>> dimensions:
>>>>>>>>> lat = 224 ;
>>>>>>>>> lon = 464 ;
>>>>>>>>> variables:
>>>>>>>>> float lat(lat, lon) ;
>>>>>>>>> lat:long_name = "latitude" ;
>>>>>>>>> lat:units = "degrees_north" ;
>>>>>>>>> lat:standard_name = "latitude" ;
>>>>>>>>> float lon(lat, lon) ;
>>>>>>>>> lon:long_name = "longitude" ;
>>>>>>>>> lon:units = "degrees_east" ;
>>>>>>>>> lon:standard_name = "longitude" ;
>>>>>>>>> float APCP_12(lat, lon) ;
>>>>>>>>> APCP_12:name = "APCP_12" ;
>>>>>>>>> APCP_12:long_name = "Total
precipitation" ;
>>>>>>>>> APCP_12:level = "A12" ;
>>>>>>>>> APCP_12:units = "kg/m^2" ;
>>>>>>>>> APCP_12:_FillValue = -9999.f ;
>>>>>>>>> APCP_12:init_time = "20050807_000000" ;
>>>>>>>>> APCP_12:init_time_ut = 1123372800 ;
>>>>>>>>> APCP_12:valid_time = "20050807_120000"
;
>>>>>>>>> APCP_12:valid_time_ut = 1123416000 ;
>>>>>>>>> APCP_12:accum_time = "120000" ;
>>>>>>>>> APCP_12:accum_time_sec = 43200 ;
>>>>>>>>>
>>>>>>>>> // global attributes:
>>>>>>>>> :FileOrigins = "File
>>>> wrfprs_ruc13_12.tm00_G212.ncgenerated 20120710_171301 UTC on host
orval by
>>>> the
>>>>>>>>> MET pcp_combine tool" ;
>>>>>>>>> :MET_version = "V4.0" ;
>>>>>>>>> :MET_tool = "pcp_combine" ;
>>>>>>>>> :RunCommand = "Addition: 1 files." ;
>>>>>>>>> :Projection = "LatLon" ;
>>>>>>>>> :lat_ll = "25.063000 degrees_north" ;
>>>>>>>>> :lon_ll = "-124.938000 degrees_east" ;
>>>>>>>>> :delta_lat = "0.125000 degrees" ;
>>>>>>>>> :delta_lon = "0.125000 degrees" ;
>>>>>>>>> :Nlat = "224 grid_points" ;
>>>>>>>>> :Nlon = "464 grid_points" ;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -------- Original Message -------- Subject: Re: [
>>>> rt.rap.ucar.edu#57358]
>>>>>>>>> MET netcdf to grib1 converter yet? Date: Tue, 10 Jul 2012
13:14:06
>>>>>>> -0600 From:
>>>>>>>>> Paul Oldenburg via RT <met_help at ucar.edu>
<met_help at ucar.edu>
>>>>>>> Reply-To:
>>>>>>>
>>>>>>>>> met_help at ucar.edu To: Ellen.Sukovich at noaa.gov CC:
>>>>>>>>> met_help at mailman.ucar.edu
>>>>>>>>>
>>>>>>>>> Ellen,
>>>>>>>>>
>>>>>>>>> If your data dude can put it into the format shown below,
MET should
>>>>>>> be able to read it. I will probably hold off on
>>>>>>>>> the conversion script unless you would still like me to put
it
>>>>>>> together. The format is really just a matter of having
>>>>>>>>> certain attributes present with specific names and values.
I also
>>>>>>> showed how I regridded (to lat/lon projection) and
>>>>>>>>> converted a test file included in the MET tarball file from
GRIB to
>>>>>>> MET NetCDF. If you have any questions about this
>>>>>>>>> format, please let us know.
>>>>>>>>>
>>>>>>>>> Paul
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [pgoldenb at orval 20120710.sukovich]$ copygb.exe \
>>>>>>>>> -xg 110 \
>>>>>>>>>
$MET_BASE/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212
>>>> \
>>>>>>>>> wrfprs_ruc13_12.tm00_G212.grib
>>>>>>>>> [pgoldenb at orval 20120710.sukovich]$
$MET_BASE/bin/pcp_combine -add \
>>>>>>>>> wrfprs_ruc13_12.tm00_G212.grib 12 \
>>>>>>>>> wrfprs_ruc13_12.tm00_G212.nc
>>>>>>>>> DEBUG 1: Reading input file: wrfprs_ruc13_12.tm00_G212.grib
>>>>>>>>> DEBUG 1: Writing output file: wrfprs_ruc13_12.tm00_G212.nc
>>>>>>>>> [pgoldenb at orval 20120710.sukovich]$ ncdump -h
>>>>>>> wrfprs_ruc13_12.tm00_G212.nc
>>>>>>>>> netcdf wrfprs_ruc13_12.tm00_G212 {
>>>>>>>>> dimensions:
>>>>>>>>> lat = 224 ;
>>>>>>>>> lon = 464 ;
>>>>>>>>> variables:
>>>>>>>>> float lat(lat, lon) ;
>>>>>>>>> lat:long_name = "latitude" ;
>>>>>>>>> lat:units = "degrees_north" ;
>>>>>>>>> lat:standard_name = "latitude" ;
>>>>>>>>> float lon(lat, lon) ;
>>>>>>>>> lon:long_name = "longitude" ;
>>>>>>>>> lon:units = "degrees_east" ;
>>>>>>>>> lon:standard_name = "longitude" ;
>>>>>>>>> float APCP_12(lat, lon) ;
>>>>>>>>> APCP_12:name = "APCP_12" ;
>>>>>>>>> APCP_12:long_name = "Total
precipitation" ;
>>>>>>>>> APCP_12:level = "A12" ;
>>>>>>>>> APCP_12:units = "kg/m^2" ;
>>>>>>>>> APCP_12:_FillValue = -9999.f ;
>>>>>>>>> APCP_12:init_time = "20050807_000000" ;
>>>>>>>>> APCP_12:init_time_ut = 1123372800 ;
>>>>>>>>> APCP_12:valid_time = "20050807_120000"
;
>>>>>>>>> APCP_12:valid_time_ut = 1123416000 ;
>>>>>>>>> APCP_12:accum_time = "120000" ;
>>>>>>>>> APCP_12:accum_time_sec = 43200 ;
>>>>>>>>>
>>>>>>>>> // global attributes:
>>>>>>>>> :FileOrigins = "File
>>>> wrfprs_ruc13_12.tm00_G212.ncgenerated 20120710_171301 UTC on host
orval by
>>>> the
>>>>>>>>> MET pcp_combine tool" ;
>>>>>>>>> :MET_version = "V4.0" ;
>>>>>>>>> :MET_tool = "pcp_combine" ;
>>>>>>>>> :RunCommand = "Addition: 1 files." ;
>>>>>>>>> :Projection = "LatLon" ;
>>>>>>>>> :lat_ll = "25.063000 degrees_north" ;
>>>>>>>>> :lon_ll = "-124.938000 degrees_east" ;
>>>>>>>>> :delta_lat = "0.125000 degrees" ;
>>>>>>>>> :delta_lon = "0.125000 degrees" ;
>>>>>>>>> :Nlat = "224 grid_points" ;
>>>>>>>>> :Nlon = "464 grid_points" ;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>>
>>
>
>
------------------------------------------------
Subject: MET netcdf to grib1 converter yet?
From: Ellen.Sukovich at noaa.gov
Time: Fri Jul 13 09:00:00 2012
////////////////////////////////////////////////////////////////////////////////
//
// Default WrfMode configuration file
//
////////////////////////////////////////////////////////////////////////////////
//
// Specify a name to designate the model being verified. This name
will be
// written to the first column of the ASCII output generated.
//
model = "QPE";
//
// The nominal grid spacing in kilometers. This value is used to
provide
// default configuration values for distance related parameters below.
//
grid_res = 4.0;
//
// Specify the fields to be used in the verification. The forecast
and
// observation fields may be specified separately.
//
// Each field is specified as a grib code or corresponding grib code
// abbreviation followed by an accumulation or vertical level
indicator.
//
// Each verification field is specified as one of the following:
// GC/ANNN for accumulation interval NNN
// GC/ZNNN for vertical level NNN
// GC/PNNN for pressure level NNN in hPa
// GC/PNNN-NNN for a range of pressure levels in hPa
// GC/LNNN for a generic level type
// GC/RNNN for a specific GRIB record number
// Where GC is the number of or abbreviation for the grib code
// to be verified.
// http://www.nco.ncep.noaa.gov/pmb/docs/on388/table2.html
//
// e.g. fcst_field[] = [ "61/A3", "APCP/A24", "RH/L10" ];
//
fcst_field = "APCP/A12";
obs_field = "APCP/A12";
//
// If the mask_missing_flag is set, the missing data in one field will
// be used to mask the other field as follows:
// (0) Do not apply
// (1) Mask the forecast field with the missing data in the
observation field
// (2) Mask the observation field using the missing data in the
forecast field
// (3) Mask both fields using the missing data in the other field
//
mask_missing_flag = 3;
//
// Specify the name of a single grid to be used in masking the data.
// An empty string indicates that no masking grid should be used.
// The standard NCEP grids are named "GNNN" where NNN indicates the
// three digit grid number.
// http://www.nco.ncep.noaa.gov/pmb/docs/on388/tableb.html
//
mask_grid = "";
//
// Flag to indicate how the mask_grid should be applied:
// (0) Do not apply
// (1) Apply masking grid to the forecast field only
// (2) Apply masking grid to the observation field only
// (3) Apply masking grid to both the forecast and observation fields
//
mask_grid_flag = 0;
//
// Specify a masking regions to be applied.
// An empty list indicates that no additional masks should be used.
// The masking region may be defined in one of 4 ways:
//
// (1) An ASCII file containing a lat/lon polygon.
// Latitude in degrees north and longitude in degrees east.
// By default, the first and last polygon points are connected.
// e.g. "MET_BASE/data/poly/EAST.poly" which consists of n points:
// "poly_name lat1 lon1 lat2 lon2... latn lonn"
//
// (2) The NetCDF output of the gen_poly_mask tool.
//
// (3) A NetCDF data file, followed by the name of the NetCDF variable
// to be used, and optionally, a threshold to be applied to the
field.
// e.g. "sample.nc var_name gt0.00"
//
// (4) A GRIB data file, followed by a description of the field
// to be used, and optionally, a threshold to be applied to the
field.
// e.g. "sample.grb APCP/A3 gt0.00"
//
// Any NetCDF or GRIB file used must have the same grid dimensions as
the
// data being verified.
//
// MET_BASE may be used in the path for the files above.
//
mask_poly = "";
//
// Flag to indicate how the mask_poly should be applied:
// (0) Do not apply
// (1) Apply masking polygon to the forecast field only
// (2) Apply masking polygon to the observation field only
// (3) Apply masking polygon to both the forecast and observation
fields
//
mask_poly_flag = 0;
/////////////////////////////////////////////////////////////////////////
//
// Object definition parameters
//
/////////////////////////////////////////////////////////////////////////
//
// Apply a threshold to the raw fcst and obs fields prior to defining
// objects using the threshold values below. The threshold values are
// specified as "xxT" where T is the threshold value and xx is one of:
// 'lt' for less than, 'le' for less than or equal to,
// 'eq' for equal to, 'ne' for not equal to,
// 'gt' for greater than, and 'ge' for greater than or equal to
//
fcst_raw_thresh = "ge0.0";
obs_raw_thresh = "ge0.0";
//
// Radius (grid squares) for the circular convolution applied to the
raw
// fcst and obs fields.
//
fcst_conv_radius = 5;
obs_conv_radius = 5;
//
// When performing the convolution step on points containing bad data,
// compute a ratio of the number of bad data points to the total
number
// of points in the convolution area. If that ratio is greater than
this
// threshold, set the convolved field value to bad data. Otherwise,
use
// the computed convolution value. Must be between 0 and 1. Setting
// this threshold to 0 will have the effect of masking out bad data
// entirely from the object field.
//
bad_data_thresh = 0.5;
//
// Apply a threshold to the convolved fcst and obs fields to define
// objects using the threshold values below. The threshold values are
// specified as "xxT" where T is the threshold value and xx is one of:
// 'lt' for less than, 'le' for less than or equal to,
// 'eq' for equal to, 'ne' for not equal to,
// 'gt' for greater than, and 'ge' for greater than or equal to
//
fcst_conv_thresh = "ge25.4";
obs_conv_thresh = "ge25.4";
//
// Apply a threshold to the area (as a count of grid squares) of the
// fcst and obs objects using the threshold values below. Discard
// objects which do not meet the area threshold criteria. The
// threshold values are specified as "xxT" where T is the threshold
// value and xx is one of:
// 'lt' for less than, 'le' for less than or equal to,
// 'eq' for equal to, 'ne' for not equal to,
// 'gt' for greater than, and 'ge' for greater than or equal to
//
fcst_area_thresh = "ge0";
obs_area_thresh = "ge0";
//
// Define an intensity percentile for fcst and obs objects. The
// percentile values must be between 0 and 102. Values between
// 0 and 100 indicate the corresponding intensity percentile. A value
// of 101 indicates that the mean of the intensities should be used.
// A value of 102 indicates that the sum of the intensities should be
// used. Apply a threshold to the percentile value chosen for the
fcst
// and obs objects using the threshold values below. Discard objects
// which do not meet the intensity percentile threshold criteria. The
// threshold values are specified as "xxT" where T is the threshold
// value and xx is one of:
// 'lt' for less than, 'le' for less than or equal to,
// 'eq' for equal to, 'ne' for not equal to,
// 'gt' for greater than, and 'ge' for greater than or equal to
//
fcst_inten_perc = 102;
fcst_inten_perc_thresh = "ge0.0";
obs_inten_perc = 102;
obs_inten_perc_thresh = "ge0.0";
//
// Apply a second threshold to the convolved fcst and obs fields to
// assist in the merging process. The original objects defined by the
// fcst/obs_conv_thresh will be merged if they reside in the same
// object defined by the fcst/obs_merge_thresh. The
// fcst/obs_merge_thresh should be chosen to define objects which
// wholly contain the original objects. The threshold values are
// specified as "xxT" where T is the threshold value and xx is one of:
// 'lt' for less than, 'le' for less than or equal to,
// 'eq' for equal to, 'ne' for not equal to,
// 'gt' for greater than, and 'ge' for greater than or equal to
//
// NOTE: The fcst/obs_merge_flags must be used to request this merging
// method.
//
fcst_merge_thresh = "ge10";
obs_merge_thresh = "ge10";
/////////////////////////////////////////////////////////////////////////
//
// Merging/matching instructions
//
/////////////////////////////////////////////////////////////////////////
//
// Flag to indicate how merging will be performed in the forecast
field:
// (0) Perform no merging in the forecast field
// (1) Use the double thresholding merging method only
// (2) Use the fuzzy engine merging method only
// (3) Use both the double thresholding and fuzzy engine merging
methods
//
fcst_merge_flag = 3;
//
// Flag to indicate how merging will be performed in the observation
field:
// (0) Perform no merging in the observation field
// (1) Use the double thresholding merging method only
// (2) Use the fuzzy engine merging method only
// (3) Use both the double thresholding and fuzzy engine merging
methods
//
obs_merge_flag = 3;
//
// Flag to indicate what type of matching between the fcst and obs
// fields is to be performed:
// (0) Perform no matching
// (1) Perform matching allowing additional merging in both fields
// (2) Perform matching allowing additional merging of only fcst
objects
// (3) Perform matching allowing no additional merging
//
match_flag = 1;
//
// The total interest will not be computed for object pairs with
// a centroid distance greater than this threshold (grid squares).
//
max_centroid_dist = 1600/grid_res;
////////////////////////////////////////////////////////////////////////
//
// Fuzzy engine weights:
// The weights need not sum to any particular value but must be
// non-negative. When computing a total interest value, the weights
// are normalized by their sum.
//
////////////////////////////////////////////////////////////////////////
//
// Weight for the distance (grid squares) between centroids
//
centroid_dist_weight = 2.0;
//
// Weight for the minimum distance (grid squares) between objects
//
boundary_dist_weight = 4.0;
//
// Weight for the minimum distance (grid squares) between the convex
// hulls of the objects
//
convex_hull_dist_weight = 1.0;
//
// Weight for the difference in orientation angles (degrees) between
// objects. The difference will be between 0 and 90 degrees.
//
angle_diff_weight = 0.0;
//
// Weight for the ratio of the objects' areas. Area is defined as a
// count of grid squares.
//
area_ratio_weight = 1.0;
//
// Weight for the ratio of the objects' intersection divided by the
// minimum of the areas of the two objects.
//
int_area_ratio_weight = 1.0;
//
// Weight for the ratio of the objects' complexities. Complexity of
an
// object is defined as:
// (Area of Convex Hull - Area of Object)/(Area of Convex Hull)
//
complexity_ratio_weight = 0.0;
//
// Percentile to be used in computing the intensity ratio attribute
// below. Percentile value must be between 0 and 100.
//
intensity_percentile = 50;
//
// Weight for the ratio of the percentile intensities of the raw data
// inside each object.
//
intensity_ratio_weight = 0.0;
////////////////////////////////////////////////////////////////////////
//
// Attribute interest maps:
// The following interest functions are piecewise linear functions
// defined by their significant points. An interest function is
// defined for each of the weights listed above.
//
////////////////////////////////////////////////////////////////////////
centroid_dist_if = {
( 0.0, 1.0 )
( 60.0/grid_res, 1.0 )
( 600.0/grid_res, 0.0 )
};
boundary_dist_if = {
( 0.0, 1.0 )
( 800.0/grid_res, 0.0 )
};
convex_hull_dist_if = {
( 0.0, 1.0 )
( 800.0/grid_res, 0.0 )
};
angle_diff_if = {
( 0.0, 1.0 )
( 30.0, 1.0 )
( 90.0, 0.0 )
};
corner = 0.8;
ratio_if = {
( 0.0, 0.0 )
( corner, 1.0 )
( 1.0, 1.0 )
};
area_ratio_if(x) = ratio_if(x);
int_area_ratio_if = {
( 0.00, 0.00 )
( 0.10, 0.50 )
( 0.25, 1.00 )
( 1.00, 1.00 )
};
complexity_ratio_if(x) = ratio_if(x);
intensity_ratio_if(x) = ratio_if(x);
////////////////////////////////////////////////////////////////////////
//
// Confidence maps:
// Confidence functions are applied to a handful of the attribute
// comparisons to indicate when an attribute comparison is meaningful.
//
////////////////////////////////////////////////////////////////////////
//
// Aspect ratio confidence is applied to the angle difference
attribute.
// An aspect ratio near one indicates the object is nearly circular,
so
// we have lower confidence in it's orientation angle.
//
aspect_ratio_conf(t) = ( (t - 1)^2/(t^2 + 1) )^0.3;
//
// The area ratio confidence is applied to the centroid distance
// attribute. For two objects which are very different in size,
// meaning their area ratio is close to zero, we have lower confidence
// in the importance of the distance between their centroids.
//
area_ratio_conf(t) = t;
////////////////////////////////////////////////////////////////////////
//
// Interest threshold
//
////////////////////////////////////////////////////////////////////////
//
// Apply a total interest threshold to the object pair interest values
// to determine which objects should be merged/matched. Object pairs
// with a total interest greater than or equal to this threshold will
// be matched/merged. Must be between 0 and 1.
//
total_interest_thresh = 0.7;
//
// Print out only the object pair attributes to the statistics file
// when the object pair has an interest value greater than or equal to
// this threshold. Must be between 0 and 1.
//
print_interest_thresh = 0.0;
////////////////////////////////////////////////////////////////////////
//
// Plotting Information
//
////////////////////////////////////////////////////////////////////////
//
// The location of the data directory containing data files used for
// plotting.
//
// MET_BASE may be used in the path for the data directory.
//
met_data_dir = "MET_BASE/data";
//
// Color table files to be used for plotting the raw forecast and
// observation fields. If the values in these color tables range from
// 0 to 1, the colors will be rescaled to match the range of the raw
// data. Otherwise, the values specified in the colortable will be
used.
// Use a value of -9999 to specify a color for the missing data other
// than the default of white.
//
// MET_BASE may be used in the path for the colortable file.
//
fcst_raw_color_table = "MET_BASE/data/colortables/met_default.ctable";
obs_raw_color_table = "MET_BASE/data/colortables/met_default.ctable";
//
// Min and max raw data values to be plotted for the forecast and
// observation fields. If set to non-zero values, the forecast and
// observation raw color tables specified above will be rescaled to
// match the specified range.
//
fcst_raw_plot_min = 0.0;
fcst_raw_plot_max = 110.0;
obs_raw_plot_min = 0.0;
obs_raw_plot_max = 110.0;
//
// The stride length value is used when plotting the colorbar to
// display the entries in the colortable. A value of 1 indicates that
// every colortable value should be plotted, while a value of n (>1),
// indicates that every nth colortable value should be plotted.
//
stride_length = 5;
//
// Color table file to be used for plotting object colors.
//
// MET_BASE may be used in the path for the colortable file.
//
mode_color_table = "MET_BASE/data/colortables/mode_obj.ctable";
//
// Number of grid boxes to fill with bad data values along the edge of
// the field to avoid edge effects.
//
zero_border_size = 1;
//
// If the raw_valid_flag is set, only the region containing valid data
// after the masking is applied will be plotted:
// (0) Plot the entire domain of the data
// (1) Plot only the region containing valid data after masking
//
plot_valid_flag = 1;
//
// If the plot_gcarc_flag is set, polyline edges will be plotted as
// great circle arcs as opposed to straight lines in the grid:
// (0) Plot polylines using straight lines in the grid
// (1) Plot polylines using great circle arcs
//
plot_gcarc_flag = 0;
////////////////////////////////////////////////////////////////////////
//
// Misc
//
////////////////////////////////////////////////////////////////////////
//
// Specify the GRIB Table 2 parameter table version number to be used
// for interpreting GRIB codes.
// http://www.nco.ncep.noaa.gov/pmb/docs/on388/table2.html
//
grib_ptv = 2;
//
// Prefix to be used for the output file names.
//
output_prefix = "f25mm";
//
// Indicate a version number for the contents of this configuration
file.
// The value should generally not be modified.
//
version = "V3.0";
////////////////////////////////////////////////////////////////////////
------------------------------------------------
Subject: MET netcdf to grib1 converter yet?
From: Paul Oldenburg
Time: Fri Jul 13 09:19:52 2012
Ellen,
I apologize, the error message from MODE is not very helpful. The
problem with the file you sent was that it had the
following global attribute value, which confused METv3.0:
:MET_version = "V4.0" ;
In the attached version of the file, I change the value to "V3.0" and
the METv3.0 version of MODE will now run to
completion, but it does not detect any objects. The reason is because
I think the alignment problem still exists in the
gridded precip data. You can see in the attached plot that there
doesn't seem to be any coherent objects to detect. I
think once the alignment problem is fixed, I think then MODE will
work.
Paul
On 07/13/2012 09:00 AM, Ellen.Sukovich at noaa.gov via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>
> Hi Paul,
>
> I still can't get the MODE to work on Haonan's file (see attached
for
> file). To test the file I use mode to compare the file to itself:
> % mode GAGEONLY2012031417z_MET.nc GAGEONLY2012031417z_MET.nc
> RadarQPE.config -outdir .
>
> and I get the following message:
> Forecast File: GAGEONLY2012031417z_MET.nc
> Observation File: GAGEONLY2012031417z_MET.nc
> Match Config File: RadarQPE.config
> Merge Config File: RadarQPE.config
> NetCDF: Attribute not found
>
> I know the config file works on Stage IV data but is the config file
> wrong for this data (see attached)? Note: I am using METv3.0 if
that
> makes a difference.
>
> Thanks again for all your help!
> Ellen
>
>
>
> On 7/12/2012 1:28 PM, Paul Oldenburg via RT wrote:
>> Ellen & Haonan,
>>
>> Also, as I mentioned in a previous email, the ncview utility that
is packaged with NetCDF also can be used to plot the
>> data in the NetCDF file.
>>
>> Paul
>>
>>
>> On 07/12/2012 01:15 PM, Paul Oldenburg wrote:
>>> Ellen & Haonan,
>>>
>>> Haonan can download the MET source and build it on a linux system
using the instructions here:
>>>
>>>
http://www.dtcenter.org/met/users/support/online_tutorial/METv3.1/compilation/index.php
>>>
>>> Paul
>>>
>>>
>>> On 07/12/2012 12:58 PM, Ellen.Sukovich at noaa.gov via RT wrote:
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>>>>
>>>> Hi Paul,
>>>>
>>>> I don't believe Haonan has MET access on his system. He is up at
CSU.
>>>>
>>>> Ellen
>>>>
>>>> On Thu, Jul 12, 2012 at 12:25 PM, Paul Oldenburg via RT
>>>> <met_help at ucar.edu>wrote:
>>>>
>>>>> Haonan,
>>>>>
>>>>> I plotted the new file and now the precip values are reasonable
(~0-10
>>>>> mm). It still looks like there is a skewing
>>>>> problem in the regridding, but hopefully it won't be too hard to
fix.
>>>>> Remember that you can test your MET NetCDF output
>>>>> using plot_data_plane as I showed in an earlier email. This
will show you
>>>>> how MET has read in the gridded data. I also
>>>>> use ncview, which is quicker and easier. Please let me know if
you have
>>>>> any questions.
>>>>>
>>>>> Paul
>>>>>
>>>>>
>>>>> On 07/12/2012 12:20 PM, Haonan Chen via RT wrote:
>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>>>>>>
>>>>>> Hi Paul
>>>>>>
>>>>>> Yes. -999 is actually the bad value. And I just changed -999 to
-9999.
>>>>> The
>>>>>> data was originally in HRAP coordinates (a rectangular area), I
only
>>>>>> converted the HRAP coordinates to Lat/Lons. So the output image
should be
>>>>>> skewed due to the polar properties of the Earth. I am also
attaching a
>>>>> plot
>>>>>> to show the map. It might be helpful to see the overall shape.
>>>>>> We will regrid the data to a rectangular Lat/Lon area if
needed.
>>>>>>
>>>>>> Thanks so much, Paul.
>>>>>>
>>>>>> Haonan
>>>>>>
>>>>>>
>>>>>> On Thu, Jul 12, 2012 at 9:42 AM, Ellen Sukovich
<ellen.sukovich at noaa.gov
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Thu, Jul 12, 2012 at 8:40 AM, Paul Oldenburg via RT <
>>>>> met_help at ucar.edu>wrote:
>>>>>>>> Ellen & Haonan,
>>>>>>>>
>>>>>>>> You are getting close. I used the MET utility
plot_data_plane to plot
>>>>>>>> the APCP_12 field in the data file that you sent me:
>>>>>>>>
>>>>>>>> $ $MET_BASE/bin/plot_data_plane GAGEONLY2012031417z_MET_2.nc
plot.ps
>>>>> 'name="APCP_12";level="(*,*)";'
>>>>>>>> DEBUG 1: Opening data file: GAGEONLY2012031417z_MET_2.nc
>>>>>>>> DEBUG 1: Creating postscript file: plot.ps
>>>>>>>>
>>>>>>>> The fact that it ran correctly and generated a plot is a good
sign.
>>>>>>>> However, the plot shows that there are areas of
>>>>>>>> precip values of -999. The ncview tool shows the same
situation. Are
>>>>>>>> these areas actually supposed to be bad data
>>>>>>>> (-9999)? If so, changing values -999 to -9999 might fix the
problem.
>>>>>>>> Also, it looks like there might be an indexing
>>>>>>>> problem or perhaps a regridding problem because the areas
where precip
>>>>>>>> values are normal looks a bit skewed. Maybe
>>>>>>>> check the regridding process? Please let me know if you have
any
>>>>>>>> questions.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Paul
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 07/11/2012 11:58 PM, Haonan Chen via RT wrote:
>>>>>>>>> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>>>>>>>>>
>>>>>>>>> Hi Ellen and Paul
>>>>>>>>>
>>>>>>>>> How are you doing?
>>>>>>>>>
>>>>>>>>> This is Haonan, the guy working with Ellen on the NetCDF
format
>>>>>>>> conversion
>>>>>>>>> problems. I changed the fields according to Paul's comments
(they are
>>>>>>>> very
>>>>>>>>> helpful). However, I still have one question here: In the
global
>>>>>>>> attributes
>>>>>>>>> of your sample file, there was a field like following.
>>>>>>>>>
>>>>>>>>> *FileOrigins = "File wrfprs_ruc13_12.tm00_G212.nc generated
>>>>>>>> 20120710_171301
>>>>>>>>> UTC on host orval by the MET pcp_combine tool" ;*
>>>>>>>>> However, I am not really using host orval (a machine?) and
the MET
>>>>>>>>> pcp_combine tool even I specified something about MET_tool.
Do I have
>>>>> to
>>>>>>>>> make the FileOrigins exactly the same with your sample file?
>>>>>>>>>
>>>>>>>>> I am attaching a example result from my program. I guess you
should be
>>>>>>>> able
>>>>>>>>> to open it. Could you please help us check it? Thanks so
much.
>>>>>>>>>
>>>>>>>>> Have a good night.
>>>>>>>>>
>>>>>>>>> Haonan
>>>>>>>>>
>>>>>>>>> On Tue, Jul 10, 2012 at 1:20 PM, Ellen Sukovich <
>>>>>>>> ellen.sukovich at noaa.gov>wrote:
>>>>>>>>>> Hi Haonan,
>>>>>>>>>>
>>>>>>>>>> Could you put your netcdf file into the format listed
below? I am not
>>>>>>>>>> familiar with netcdf so I don't know if the instructions
below make
>>>>>>>> sense.
>>>>>>>>>> See email below this email.
>>>>>>>>>>
>>>>>>>>>> Ellen
>>>>>>>>>>
>>>>>>>>>> {
>>>>>>>>>> dimensions:
>>>>>>>>>> lat = 224 ;
>>>>>>>>>> lon = 464 ;
>>>>>>>>>> variables:
>>>>>>>>>> float lat(lat, lon) ;
>>>>>>>>>> lat:long_name = "latitude" ;
>>>>>>>>>> lat:units = "degrees_north" ;
>>>>>>>>>> lat:standard_name = "latitude" ;
>>>>>>>>>> float lon(lat, lon) ;
>>>>>>>>>> lon:long_name = "longitude" ;
>>>>>>>>>> lon:units = "degrees_east" ;
>>>>>>>>>> lon:standard_name = "longitude" ;
>>>>>>>>>> float APCP_12(lat, lon) ;
>>>>>>>>>> APCP_12:name = "APCP_12" ;
>>>>>>>>>> APCP_12:long_name = "Total
precipitation" ;
>>>>>>>>>> APCP_12:level = "A12" ;
>>>>>>>>>> APCP_12:units = "kg/m^2" ;
>>>>>>>>>> APCP_12:_FillValue = -9999.f ;
>>>>>>>>>> APCP_12:init_time = "20050807_000000"
;
>>>>>>>>>> APCP_12:init_time_ut = 1123372800 ;
>>>>>>>>>> APCP_12:valid_time =
"20050807_120000" ;
>>>>>>>>>> APCP_12:valid_time_ut = 1123416000 ;
>>>>>>>>>> APCP_12:accum_time = "120000" ;
>>>>>>>>>> APCP_12:accum_time_sec = 43200 ;
>>>>>>>>>>
>>>>>>>>>> // global attributes:
>>>>>>>>>> :FileOrigins = "File
>>>>> wrfprs_ruc13_12.tm00_G212.ncgenerated 20120710_171301 UTC on
host orval by
>>>>> the
>>>>>>>>>> MET pcp_combine tool" ;
>>>>>>>>>> :MET_version = "V4.0" ;
>>>>>>>>>> :MET_tool = "pcp_combine" ;
>>>>>>>>>> :RunCommand = "Addition: 1 files." ;
>>>>>>>>>> :Projection = "LatLon" ;
>>>>>>>>>> :lat_ll = "25.063000 degrees_north" ;
>>>>>>>>>> :lon_ll = "-124.938000 degrees_east"
;
>>>>>>>>>> :delta_lat = "0.125000 degrees" ;
>>>>>>>>>> :delta_lon = "0.125000 degrees" ;
>>>>>>>>>> :Nlat = "224 grid_points" ;
>>>>>>>>>> :Nlon = "464 grid_points" ;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -------- Original Message -------- Subject: Re: [
>>>>> rt.rap.ucar.edu#57358]
>>>>>>>>>> MET netcdf to grib1 converter yet? Date: Tue, 10 Jul 2012
13:14:06
>>>>>>>> -0600 From:
>>>>>>>>>> Paul Oldenburg via RT <met_help at ucar.edu>
<met_help at ucar.edu>
>>>>>>>> Reply-To:
>>>>>>>>
>>>>>>>>>> met_help at ucar.edu To: Ellen.Sukovich at noaa.gov CC:
>>>>>>>>>> met_help at mailman.ucar.edu
>>>>>>>>>>
>>>>>>>>>> Ellen,
>>>>>>>>>>
>>>>>>>>>> If your data dude can put it into the format shown below,
MET should
>>>>>>>> be able to read it. I will probably hold off on
>>>>>>>>>> the conversion script unless you would still like me to put
it
>>>>>>>> together. The format is really just a matter of having
>>>>>>>>>> certain attributes present with specific names and values.
I also
>>>>>>>> showed how I regridded (to lat/lon projection) and
>>>>>>>>>> converted a test file included in the MET tarball file from
GRIB to
>>>>>>>> MET NetCDF. If you have any questions about this
>>>>>>>>>> format, please let us know.
>>>>>>>>>>
>>>>>>>>>> Paul
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [pgoldenb at orval 20120710.sukovich]$ copygb.exe \
>>>>>>>>>> -xg 110 \
>>>>>>>>>>
$MET_BASE/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212
>>>>> \
>>>>>>>>>> wrfprs_ruc13_12.tm00_G212.grib
>>>>>>>>>> [pgoldenb at orval 20120710.sukovich]$
$MET_BASE/bin/pcp_combine -add \
>>>>>>>>>> wrfprs_ruc13_12.tm00_G212.grib 12 \
>>>>>>>>>> wrfprs_ruc13_12.tm00_G212.nc
>>>>>>>>>> DEBUG 1: Reading input file: wrfprs_ruc13_12.tm00_G212.grib
>>>>>>>>>> DEBUG 1: Writing output file: wrfprs_ruc13_12.tm00_G212.nc
>>>>>>>>>> [pgoldenb at orval 20120710.sukovich]$ ncdump -h
>>>>>>>> wrfprs_ruc13_12.tm00_G212.nc
>>>>>>>>>> netcdf wrfprs_ruc13_12.tm00_G212 {
>>>>>>>>>> dimensions:
>>>>>>>>>> lat = 224 ;
>>>>>>>>>> lon = 464 ;
>>>>>>>>>> variables:
>>>>>>>>>> float lat(lat, lon) ;
>>>>>>>>>> lat:long_name = "latitude" ;
>>>>>>>>>> lat:units = "degrees_north" ;
>>>>>>>>>> lat:standard_name = "latitude" ;
>>>>>>>>>> float lon(lat, lon) ;
>>>>>>>>>> lon:long_name = "longitude" ;
>>>>>>>>>> lon:units = "degrees_east" ;
>>>>>>>>>> lon:standard_name = "longitude" ;
>>>>>>>>>> float APCP_12(lat, lon) ;
>>>>>>>>>> APCP_12:name = "APCP_12" ;
>>>>>>>>>> APCP_12:long_name = "Total
precipitation" ;
>>>>>>>>>> APCP_12:level = "A12" ;
>>>>>>>>>> APCP_12:units = "kg/m^2" ;
>>>>>>>>>> APCP_12:_FillValue = -9999.f ;
>>>>>>>>>> APCP_12:init_time = "20050807_000000"
;
>>>>>>>>>> APCP_12:init_time_ut = 1123372800 ;
>>>>>>>>>> APCP_12:valid_time =
"20050807_120000" ;
>>>>>>>>>> APCP_12:valid_time_ut = 1123416000 ;
>>>>>>>>>> APCP_12:accum_time = "120000" ;
>>>>>>>>>> APCP_12:accum_time_sec = 43200 ;
>>>>>>>>>>
>>>>>>>>>> // global attributes:
>>>>>>>>>> :FileOrigins = "File
>>>>> wrfprs_ruc13_12.tm00_G212.ncgenerated 20120710_171301 UTC on
host orval by
>>>>> the
>>>>>>>>>> MET pcp_combine tool" ;
>>>>>>>>>> :MET_version = "V4.0" ;
>>>>>>>>>> :MET_tool = "pcp_combine" ;
>>>>>>>>>> :RunCommand = "Addition: 1 files." ;
>>>>>>>>>> :Projection = "LatLon" ;
>>>>>>>>>> :lat_ll = "25.063000 degrees_north" ;
>>>>>>>>>> :lon_ll = "-124.938000 degrees_east"
;
>>>>>>>>>> :delta_lat = "0.125000 degrees" ;
>>>>>>>>>> :delta_lon = "0.125000 degrees" ;
>>>>>>>>>> :Nlat = "224 grid_points" ;
>>>>>>>>>> :Nlon = "464 grid_points" ;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>
>>
>
>
------------------------------------------------
Subject: Re: Fw: [rt.rap.ucar.edu #57358] MET netcdf to grib1 converter yet?
From: Ellen.Sukovich at noaa.gov
Time: Fri Jul 13 09:24:36 2012
It works!!! Thank you so much! I think now Haonan and I just need to
figure out the alignment problem.
Thanks so much for all your help!
Ellen
On 7/13/2012 9:19 AM, Paul Oldenburg via RT wrote:
> Ellen,
>
> I apologize, the error message from MODE is not very helpful. The
problem with the file you sent was that it had the
> following global attribute value, which confused METv3.0:
>
> :MET_version = "V4.0" ;
>
> In the attached version of the file, I change the value to "V3.0"
and the METv3.0 version of MODE will now run to
> completion, but it does not detect any objects. The reason is
because I think the alignment problem still exists in the
> gridded precip data. You can see in the attached plot that there
doesn't seem to be any coherent objects to detect. I
> think once the alignment problem is fixed, I think then MODE will
work.
>
> Paul
>
>
> On 07/13/2012 09:00 AM, Ellen.Sukovich at noaa.gov via RT wrote:
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>>
>> Hi Paul,
>>
>> I still can't get the MODE to work on Haonan's file (see attached
for
>> file). To test the file I use mode to compare the file to itself:
>> % mode GAGEONLY2012031417z_MET.nc GAGEONLY2012031417z_MET.nc
>> RadarQPE.config -outdir .
>>
>> and I get the following message:
>> Forecast File: GAGEONLY2012031417z_MET.nc
>> Observation File: GAGEONLY2012031417z_MET.nc
>> Match Config File: RadarQPE.config
>> Merge Config File: RadarQPE.config
>> NetCDF: Attribute not found
>>
>> I know the config file works on Stage IV data but is the config
file
>> wrong for this data (see attached)? Note: I am using METv3.0 if
that
>> makes a difference.
>>
>> Thanks again for all your help!
>> Ellen
>>
>>
>>
>> On 7/12/2012 1:28 PM, Paul Oldenburg via RT wrote:
>>> Ellen & Haonan,
>>>
>>> Also, as I mentioned in a previous email, the ncview utility that
is packaged with NetCDF also can be used to plot the
>>> data in the NetCDF file.
>>>
>>> Paul
>>>
>>>
>>> On 07/12/2012 01:15 PM, Paul Oldenburg wrote:
>>>> Ellen & Haonan,
>>>>
>>>> Haonan can download the MET source and build it on a linux system
using the instructions here:
>>>>
>>>>
http://www.dtcenter.org/met/users/support/online_tutorial/METv3.1/compilation/index.php
>>>>
>>>> Paul
>>>>
>>>>
>>>> On 07/12/2012 12:58 PM, Ellen.Sukovich at noaa.gov via RT wrote:
>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>>>>>
>>>>> Hi Paul,
>>>>>
>>>>> I don't believe Haonan has MET access on his system. He is up at
CSU.
>>>>>
>>>>> Ellen
>>>>>
>>>>> On Thu, Jul 12, 2012 at 12:25 PM, Paul Oldenburg via RT
>>>>> <met_help at ucar.edu>wrote:
>>>>>
>>>>>> Haonan,
>>>>>>
>>>>>> I plotted the new file and now the precip values are reasonable
(~0-10
>>>>>> mm). It still looks like there is a skewing
>>>>>> problem in the regridding, but hopefully it won't be too hard
to fix.
>>>>>> Remember that you can test your MET NetCDF output
>>>>>> using plot_data_plane as I showed in an earlier email. This
will show you
>>>>>> how MET has read in the gridded data. I also
>>>>>> use ncview, which is quicker and easier. Please let me know if
you have
>>>>>> any questions.
>>>>>>
>>>>>> Paul
>>>>>>
>>>>>>
>>>>>> On 07/12/2012 12:20 PM, Haonan Chen via RT wrote:
>>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358
>
>>>>>>>
>>>>>>> Hi Paul
>>>>>>>
>>>>>>> Yes. -999 is actually the bad value. And I just changed -999
to -9999.
>>>>>> The
>>>>>>> data was originally in HRAP coordinates (a rectangular area),
I only
>>>>>>> converted the HRAP coordinates to Lat/Lons. So the output
image should be
>>>>>>> skewed due to the polar properties of the Earth. I am also
attaching a
>>>>>> plot
>>>>>>> to show the map. It might be helpful to see the overall shape.
>>>>>>> We will regrid the data to a rectangular Lat/Lon area if
needed.
>>>>>>>
>>>>>>> Thanks so much, Paul.
>>>>>>>
>>>>>>> Haonan
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jul 12, 2012 at 9:42 AM, Ellen Sukovich
<ellen.sukovich at noaa.gov
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Thu, Jul 12, 2012 at 8:40 AM, Paul Oldenburg via RT <
>>>>>> met_help at ucar.edu>wrote:
>>>>>>>>> Ellen & Haonan,
>>>>>>>>>
>>>>>>>>> You are getting close. I used the MET utility
plot_data_plane to plot
>>>>>>>>> the APCP_12 field in the data file that you sent me:
>>>>>>>>>
>>>>>>>>> $ $MET_BASE/bin/plot_data_plane GAGEONLY2012031417z_MET_2.nc
plot.ps
>>>>>> 'name="APCP_12";level="(*,*)";'
>>>>>>>>> DEBUG 1: Opening data file: GAGEONLY2012031417z_MET_2.nc
>>>>>>>>> DEBUG 1: Creating postscript file: plot.ps
>>>>>>>>>
>>>>>>>>> The fact that it ran correctly and generated a plot is a
good sign.
>>>>>>>>> However, the plot shows that there are areas of
>>>>>>>>> precip values of -999. The ncview tool shows the same
situation. Are
>>>>>>>>> these areas actually supposed to be bad data
>>>>>>>>> (-9999)? If so, changing values -999 to -9999 might fix the
problem.
>>>>>>>>> Also, it looks like there might be an indexing
>>>>>>>>> problem or perhaps a regridding problem because the areas
where precip
>>>>>>>>> values are normal looks a bit skewed. Maybe
>>>>>>>>> check the regridding process? Please let me know if you
have any
>>>>>>>>> questions.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Paul
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 07/11/2012 11:58 PM, Haonan Chen via RT wrote:
>>>>>>>>>> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>>>>>>>>>>
>>>>>>>>>> Hi Ellen and Paul
>>>>>>>>>>
>>>>>>>>>> How are you doing?
>>>>>>>>>>
>>>>>>>>>> This is Haonan, the guy working with Ellen on the NetCDF
format
>>>>>>>>> conversion
>>>>>>>>>> problems. I changed the fields according to Paul's comments
(they are
>>>>>>>>> very
>>>>>>>>>> helpful). However, I still have one question here: In the
global
>>>>>>>>> attributes
>>>>>>>>>> of your sample file, there was a field like following.
>>>>>>>>>>
>>>>>>>>>> *FileOrigins = "File wrfprs_ruc13_12.tm00_G212.nc generated
>>>>>>>>> 20120710_171301
>>>>>>>>>> UTC on host orval by the MET pcp_combine tool" ;*
>>>>>>>>>> However, I am not really using host orval (a machine?) and
the MET
>>>>>>>>>> pcp_combine tool even I specified something about MET_tool.
Do I have
>>>>>> to
>>>>>>>>>> make the FileOrigins exactly the same with your sample
file?
>>>>>>>>>>
>>>>>>>>>> I am attaching a example result from my program. I guess
you should be
>>>>>>>>> able
>>>>>>>>>> to open it. Could you please help us check it? Thanks so
much.
>>>>>>>>>>
>>>>>>>>>> Have a good night.
>>>>>>>>>>
>>>>>>>>>> Haonan
>>>>>>>>>>
>>>>>>>>>> On Tue, Jul 10, 2012 at 1:20 PM, Ellen Sukovich <
>>>>>>>>> ellen.sukovich at noaa.gov>wrote:
>>>>>>>>>>> Hi Haonan,
>>>>>>>>>>>
>>>>>>>>>>> Could you put your netcdf file into the format listed
below? I am not
>>>>>>>>>>> familiar with netcdf so I don't know if the instructions
below make
>>>>>>>>> sense.
>>>>>>>>>>> See email below this email.
>>>>>>>>>>>
>>>>>>>>>>> Ellen
>>>>>>>>>>>
>>>>>>>>>>> {
>>>>>>>>>>> dimensions:
>>>>>>>>>>> lat = 224 ;
>>>>>>>>>>> lon = 464 ;
>>>>>>>>>>> variables:
>>>>>>>>>>> float lat(lat, lon) ;
>>>>>>>>>>> lat:long_name = "latitude" ;
>>>>>>>>>>> lat:units = "degrees_north" ;
>>>>>>>>>>> lat:standard_name = "latitude" ;
>>>>>>>>>>> float lon(lat, lon) ;
>>>>>>>>>>> lon:long_name = "longitude" ;
>>>>>>>>>>> lon:units = "degrees_east" ;
>>>>>>>>>>> lon:standard_name = "longitude" ;
>>>>>>>>>>> float APCP_12(lat, lon) ;
>>>>>>>>>>> APCP_12:name = "APCP_12" ;
>>>>>>>>>>> APCP_12:long_name = "Total
precipitation" ;
>>>>>>>>>>> APCP_12:level = "A12" ;
>>>>>>>>>>> APCP_12:units = "kg/m^2" ;
>>>>>>>>>>> APCP_12:_FillValue = -9999.f ;
>>>>>>>>>>> APCP_12:init_time =
"20050807_000000" ;
>>>>>>>>>>> APCP_12:init_time_ut = 1123372800 ;
>>>>>>>>>>> APCP_12:valid_time =
"20050807_120000" ;
>>>>>>>>>>> APCP_12:valid_time_ut = 1123416000
;
>>>>>>>>>>> APCP_12:accum_time = "120000" ;
>>>>>>>>>>> APCP_12:accum_time_sec = 43200 ;
>>>>>>>>>>>
>>>>>>>>>>> // global attributes:
>>>>>>>>>>> :FileOrigins = "File
>>>>>> wrfprs_ruc13_12.tm00_G212.ncgenerated 20120710_171301 UTC on
host orval by
>>>>>> the
>>>>>>>>>>> MET pcp_combine tool" ;
>>>>>>>>>>> :MET_version = "V4.0" ;
>>>>>>>>>>> :MET_tool = "pcp_combine" ;
>>>>>>>>>>> :RunCommand = "Addition: 1 files."
;
>>>>>>>>>>> :Projection = "LatLon" ;
>>>>>>>>>>> :lat_ll = "25.063000 degrees_north"
;
>>>>>>>>>>> :lon_ll = "-124.938000
degrees_east" ;
>>>>>>>>>>> :delta_lat = "0.125000 degrees" ;
>>>>>>>>>>> :delta_lon = "0.125000 degrees" ;
>>>>>>>>>>> :Nlat = "224 grid_points" ;
>>>>>>>>>>> :Nlon = "464 grid_points" ;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -------- Original Message -------- Subject: Re: [
>>>>>> rt.rap.ucar.edu#57358]
>>>>>>>>>>> MET netcdf to grib1 converter yet? Date: Tue, 10 Jul 2012
13:14:06
>>>>>>>>> -0600 From:
>>>>>>>>>>> Paul Oldenburg via RT <met_help at ucar.edu>
<met_help at ucar.edu>
>>>>>>>>> Reply-To:
>>>>>>>>>
>>>>>>>>>>> met_help at ucar.edu To: Ellen.Sukovich at noaa.gov CC:
>>>>>>>>>>> met_help at mailman.ucar.edu
>>>>>>>>>>>
>>>>>>>>>>> Ellen,
>>>>>>>>>>>
>>>>>>>>>>> If your data dude can put it into the format shown below,
MET should
>>>>>>>>> be able to read it. I will probably hold off on
>>>>>>>>>>> the conversion script unless you would still like me to
put it
>>>>>>>>> together. The format is really just a matter of having
>>>>>>>>>>> certain attributes present with specific names and values.
I also
>>>>>>>>> showed how I regridded (to lat/lon projection) and
>>>>>>>>>>> converted a test file included in the MET tarball file
from GRIB to
>>>>>>>>> MET NetCDF. If you have any questions about this
>>>>>>>>>>> format, please let us know.
>>>>>>>>>>>
>>>>>>>>>>> Paul
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> [pgoldenb at orval 20120710.sukovich]$ copygb.exe \
>>>>>>>>>>> -xg 110 \
>>>>>>>>>>>
$MET_BASE/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212
>>>>>> \
>>>>>>>>>>> wrfprs_ruc13_12.tm00_G212.grib
>>>>>>>>>>> [pgoldenb at orval 20120710.sukovich]$
$MET_BASE/bin/pcp_combine -add \
>>>>>>>>>>> wrfprs_ruc13_12.tm00_G212.grib 12 \
>>>>>>>>>>> wrfprs_ruc13_12.tm00_G212.nc
>>>>>>>>>>> DEBUG 1: Reading input file:
wrfprs_ruc13_12.tm00_G212.grib
>>>>>>>>>>> DEBUG 1: Writing output file: wrfprs_ruc13_12.tm00_G212.nc
>>>>>>>>>>> [pgoldenb at orval 20120710.sukovich]$ ncdump -h
>>>>>>>>> wrfprs_ruc13_12.tm00_G212.nc
>>>>>>>>>>> netcdf wrfprs_ruc13_12.tm00_G212 {
>>>>>>>>>>> dimensions:
>>>>>>>>>>> lat = 224 ;
>>>>>>>>>>> lon = 464 ;
>>>>>>>>>>> variables:
>>>>>>>>>>> float lat(lat, lon) ;
>>>>>>>>>>> lat:long_name = "latitude" ;
>>>>>>>>>>> lat:units = "degrees_north" ;
>>>>>>>>>>> lat:standard_name = "latitude" ;
>>>>>>>>>>> float lon(lat, lon) ;
>>>>>>>>>>> lon:long_name = "longitude" ;
>>>>>>>>>>> lon:units = "degrees_east" ;
>>>>>>>>>>> lon:standard_name = "longitude" ;
>>>>>>>>>>> float APCP_12(lat, lon) ;
>>>>>>>>>>> APCP_12:name = "APCP_12" ;
>>>>>>>>>>> APCP_12:long_name = "Total
precipitation" ;
>>>>>>>>>>> APCP_12:level = "A12" ;
>>>>>>>>>>> APCP_12:units = "kg/m^2" ;
>>>>>>>>>>> APCP_12:_FillValue = -9999.f ;
>>>>>>>>>>> APCP_12:init_time =
"20050807_000000" ;
>>>>>>>>>>> APCP_12:init_time_ut = 1123372800 ;
>>>>>>>>>>> APCP_12:valid_time =
"20050807_120000" ;
>>>>>>>>>>> APCP_12:valid_time_ut = 1123416000
;
>>>>>>>>>>> APCP_12:accum_time = "120000" ;
>>>>>>>>>>> APCP_12:accum_time_sec = 43200 ;
>>>>>>>>>>>
>>>>>>>>>>> // global attributes:
>>>>>>>>>>> :FileOrigins = "File
>>>>>> wrfprs_ruc13_12.tm00_G212.ncgenerated 20120710_171301 UTC on
host orval by
>>>>>> the
>>>>>>>>>>> MET pcp_combine tool" ;
>>>>>>>>>>> :MET_version = "V4.0" ;
>>>>>>>>>>> :MET_tool = "pcp_combine" ;
>>>>>>>>>>> :RunCommand = "Addition: 1 files."
;
>>>>>>>>>>> :Projection = "LatLon" ;
>>>>>>>>>>> :lat_ll = "25.063000 degrees_north"
;
>>>>>>>>>>> :lon_ll = "-124.938000
degrees_east" ;
>>>>>>>>>>> :delta_lat = "0.125000 degrees" ;
>>>>>>>>>>> :delta_lon = "0.125000 degrees" ;
>>>>>>>>>>> :Nlat = "224 grid_points" ;
>>>>>>>>>>> :Nlon = "464 grid_points" ;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>
>>>
>>
>
>
------------------------------------------------
Subject: MET netcdf to grib1 converter yet?
From: Ellen.Sukovich at noaa.gov
Time: Tue Jul 24 13:41:40 2012
Hi Paul,
Unfortunately we are still at a loss as to how to get our file read
into
MET. While we thought we were able to get the file to be read into
MODE, the data looked incorrect. Haonan and I are out of ideas. Back
on 10 July you mentioned that you could try to create a script to
change
the structure of the precip NetCDF so that MET could read it. Could
you
see if this is possible? We will probably need this conversion to be
applied to more than one file.
I am including the original file with this email (plus a file for the
next hour just in case).
Thank you so much for your help,
Ellen
On 7/10/2012 10:55 AM, Paul Oldenburg via RT wrote:
> Ellen,
>
> To our knowledge, converting from NetCDF to GRIB is an unsolved
problem. I think the easiest route would be to change
> the structure of your precip NetCDF so that MET can read it - to a
format like the output of the pcp_combine tool. I
> will try to whip up a script to do this for the one file you sent
me. Are you going to need this conversion performed
> on more than just this one file? If so, I will try to make it more
user-friendly so you can use it.
>
> Paul
>
>
> On 07/10/2012 10:34 AM, Ellen.Sukovich at noaa.gov via RT wrote:
>> Tue Jul 10 10:34:38 2012: Request 57358 was acted upon.
>> Transaction: Ticket created by Ellen.Sukovich at noaa.gov
>> Queue: met_help
>> Subject: MET netcdf to grib1 converter yet?
>> Owner: Nobody
>> Requestors: Ellen.Sukovich at noaa.gov
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>>
>>
>> Hi MET Help,
>>
>> In the more recent versions of MET (i.e., v3.1 and v4) is there a
netcdf
>> to grib1 converter? I have a netcdf file with precipitation data
(see
>> attached) that was outputted from radar software but it is not the
>> netcdf version that MET wants. What is the best way to get this
into
>> the netcdf form or grib1 format that MET will read? (Note: This
netcdf
>> format is not output from WRF so the CDO conversion is not
applicable
>> and my NCL guru here at NOAA doesn't know of an NCL command that
can do
>> the conversion.)
>>
>> Thanks for your time!
>> Ellen Sukovich
>>
>
>
------------------------------------------------
Subject: MET netcdf to grib1 converter yet?
From: Paul Oldenburg
Time: Tue Jul 24 14:24:37 2012
Ellen,
I started looking at how the precip data that you sent me is stored,
and what I found is a bit puzzling to me. For
example, the plot lat_image shows a color-scaled image of the Lat
dimension variable. One would expect the colors in
this image to change continuously and smoothly, indicating that the
latitude changes smoothly from top to bottom (or
upper-right to lower left, etc.). Instead, there is an irregular
patter to the values, as you can see. Then, I plotted
just the first row of latitude values, shown in lat_row_plot, and the
irregular pattern for just this row becomes more
evident.
So, long story short, it's no surprise that the MET-readable data that
Haonan generated before has an alignment problem.
I think your underlying observation data source may also have an
alignment problem. Can you talk to the people who
generate this precip data and ask them about why their Lat/Lon
coordinates are so irregular? If we can figure out how
to interpret or fix this pattern, I or Haonan can probably figure a
way to build a converter so that MET can read it.
Please let me know if you have any other questions for me.
Paul
On 07/24/2012 01:41 PM, Ellen.Sukovich at noaa.gov via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>
> Hi Paul,
>
> Unfortunately we are still at a loss as to how to get our file read
into
> MET. While we thought we were able to get the file to be read into
> MODE, the data looked incorrect. Haonan and I are out of ideas.
Back
> on 10 July you mentioned that you could try to create a script to
change
> the structure of the precip NetCDF so that MET could read it. Could
you
> see if this is possible? We will probably need this conversion to
be
> applied to more than one file.
>
> I am including the original file with this email (plus a file for
the
> next hour just in case).
>
> Thank you so much for your help,
> Ellen
>
>
> On 7/10/2012 10:55 AM, Paul Oldenburg via RT wrote:
>> Ellen,
>>
>> To our knowledge, converting from NetCDF to GRIB is an unsolved
problem. I think the easiest route would be to change
>> the structure of your precip NetCDF so that MET can read it - to a
format like the output of the pcp_combine tool. I
>> will try to whip up a script to do this for the one file you sent
me. Are you going to need this conversion performed
>> on more than just this one file? If so, I will try to make it more
user-friendly so you can use it.
>>
>> Paul
>>
>>
>> On 07/10/2012 10:34 AM, Ellen.Sukovich at noaa.gov via RT wrote:
>>> Tue Jul 10 10:34:38 2012: Request 57358 was acted upon.
>>> Transaction: Ticket created by Ellen.Sukovich at noaa.gov
>>> Queue: met_help
>>> Subject: MET netcdf to grib1 converter yet?
>>> Owner: Nobody
>>> Requestors: Ellen.Sukovich at noaa.gov
>>> Status: new
>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>>>
>>>
>>> Hi MET Help,
>>>
>>> In the more recent versions of MET (i.e., v3.1 and v4) is there a
netcdf
>>> to grib1 converter? I have a netcdf file with precipitation data
(see
>>> attached) that was outputted from radar software but it is not the
>>> netcdf version that MET wants. What is the best way to get this
into
>>> the netcdf form or grib1 format that MET will read? (Note: This
netcdf
>>> format is not output from WRF so the CDO conversion is not
applicable
>>> and my NCL guru here at NOAA doesn't know of an NCL command that
can do
>>> the conversion.)
>>>
>>> Thanks for your time!
>>> Ellen Sukovich
>>>
>>
>>
>
>
------------------------------------------------
Subject: MET netcdf to grib1 converter yet?
From: Paul Oldenburg
Time: Wed Jul 25 13:24:08 2012
Ellen,
I wrote a script that borrows heavily from the trmm2nc.R script that
John wrote to convert the precip files you sent.
To be clear: I made many dubious assumptions when converting the
lat/lon information. I tested the attached NetCDF
files in MODE (METv4.0) and it worked as expected. I visually
compared the 17z plot to the one that Haonan sent a
couple weeks ago, and they looked similar, but not the same. Can you
tell me how that plot was made?
If you think that the attached test data is good enough for your
purposes, I can clean up the conversion script that I
wrote and send it over to you for your use. I still think it would be
best to find out how the lat/lon coordinates are
calculated, and figure out what projection the data is on. Otherwise,
it will be difficult to correctly interpret the
locations of the precip values in the gridded data.
Please let me know if you have any questions.
Paul
On 07/24/2012 02:24 PM, Paul Oldenburg wrote:
> Ellen,
>
> I started looking at how the precip data that you sent me is stored,
and what I found is a bit puzzling to me. For
> example, the plot lat_image shows a color-scaled image of the Lat
dimension variable. One would expect the colors in
> this image to change continuously and smoothly, indicating that the
latitude changes smoothly from top to bottom (or
> upper-right to lower left, etc.). Instead, there is an irregular
patter to the values, as you can see. Then, I plotted
> just the first row of latitude values, shown in lat_row_plot, and
the irregular pattern for just this row becomes more
> evident.
>
> So, long story short, it's no surprise that the MET-readable data
that Haonan generated before has an alignment problem.
> I think your underlying observation data source may also have an
alignment problem. Can you talk to the people who
> generate this precip data and ask them about why their Lat/Lon
coordinates are so irregular? If we can figure out how
> to interpret or fix this pattern, I or Haonan can probably figure a
way to build a converter so that MET can read it.
>
> Please let me know if you have any other questions for me.
>
> Paul
>
>
> On 07/24/2012 01:41 PM, Ellen.Sukovich at noaa.gov via RT wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>>
>> Hi Paul,
>>
>> Unfortunately we are still at a loss as to how to get our file read
into
>> MET. While we thought we were able to get the file to be read into
>> MODE, the data looked incorrect. Haonan and I are out of ideas.
Back
>> on 10 July you mentioned that you could try to create a script to
change
>> the structure of the precip NetCDF so that MET could read it. Could
you
>> see if this is possible? We will probably need this conversion to
be
>> applied to more than one file.
>>
>> I am including the original file with this email (plus a file for
the
>> next hour just in case).
>>
>> Thank you so much for your help,
>> Ellen
>>
>>
>> On 7/10/2012 10:55 AM, Paul Oldenburg via RT wrote:
>>> Ellen,
>>>
>>> To our knowledge, converting from NetCDF to GRIB is an unsolved
problem. I think the easiest route would be to change
>>> the structure of your precip NetCDF so that MET can read it - to a
format like the output of the pcp_combine tool. I
>>> will try to whip up a script to do this for the one file you sent
me. Are you going to need this conversion performed
>>> on more than just this one file? If so, I will try to make it
more user-friendly so you can use it.
>>>
>>> Paul
>>>
>>>
>>> On 07/10/2012 10:34 AM, Ellen.Sukovich at noaa.gov via RT wrote:
>>>> Tue Jul 10 10:34:38 2012: Request 57358 was acted upon.
>>>> Transaction: Ticket created by Ellen.Sukovich at noaa.gov
>>>> Queue: met_help
>>>> Subject: MET netcdf to grib1 converter yet?
>>>> Owner: Nobody
>>>> Requestors: Ellen.Sukovich at noaa.gov
>>>> Status: new
>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>>>>
>>>>
>>>> Hi MET Help,
>>>>
>>>> In the more recent versions of MET (i.e., v3.1 and v4) is there a
netcdf
>>>> to grib1 converter? I have a netcdf file with precipitation data
(see
>>>> attached) that was outputted from radar software but it is not
the
>>>> netcdf version that MET wants. What is the best way to get this
into
>>>> the netcdf form or grib1 format that MET will read? (Note: This
netcdf
>>>> format is not output from WRF so the CDO conversion is not
applicable
>>>> and my NCL guru here at NOAA doesn't know of an NCL command that
can do
>>>> the conversion.)
>>>>
>>>> Thanks for your time!
>>>> Ellen Sukovich
>>>>
>>>
>>>
>>
>>
>
------------------------------------------------
Subject: MET netcdf to grib1 converter yet?
From: Haonan Chen
Time: Wed Jul 25 16:49:10 2012
Hi Ellen
The plots Paul sent look fine for me. The plots I sent a couple weeks
ago
for a sample file were generated from a brief Matlab program. The
sample
file was created by the MTR MPE program. As you know, all the files
generated from MPE were in HRAP coordinates. To use the lat/lon
coordinates
for making plots, I was using a program to convert the HRAP
coordinates to
lat/lon coordinates. Before using this coordinate conversion program,
we
need to use read_xmrg2 (under /home/hchen/bin on radarqpe) to read the
files generated from MPE or some other programs.
Here I am attaching again the original plots in HRAP coordinates and
corresponding one in lat/lon. There looks to be a shift in
coordinates. But
it is Ok because of the properties of HRAP and Lat/Lon. The projection
program from HRAP to Lat/Lon is also attached here. It can actually be
regarded as a point-to-point conversion program. That means, the
program
will convert the HRAP to Lat/Lon one point by one point as specified.
I am still looking into the file Paul sent to make a better
explanation on
what I did before.
Thanks so much.
Haonan
On Wed, Jul 25, 2012 at 2:18 PM, Ellen Sukovich
<ellen.sukovich at noaa.gov>wrote:
> Hi Haonan,
>
> This is what Paul (from DTC) sent me today. What are your thoughts?
If
> you could respond to both me and Paul (Paul Oldenburg via RT
> <met_help at ucar.edu> <met_help at ucar.edu>) that would be great!
>
> Thanks,
> Ellen
>
>
> -------- Original Message -------- Subject: Re: [rt.rap.ucar.edu
#57358]
> MET netcdf to grib1 converter yet? Date: Wed, 25 Jul 2012 13:24:09
-0600 From:
> Paul Oldenburg via RT <met_help at ucar.edu> <met_help at ucar.edu>
Reply-To:
> met_help at ucar.edu To: Ellen.Sukovich at noaa.gov CC:
> met_help at mailman.ucar.edu
>
> Ellen,
>
> I wrote a script that borrows heavily from the trmm2nc.R script that
John wrote to convert the precip files you sent.
> To be clear: I made many dubious assumptions when converting the
lat/lon information. I tested the attached NetCDF
> files in MODE (METv4.0) and it worked as expected. I visually
compared the 17z plot to the one that Haonan sent a
> couple weeks ago, and they looked similar, but not the same. Can
you tell me how that plot was made?
>
> If you think that the attached test data is good enough for your
purposes, I can clean up the conversion script that I
> wrote and send it over to you for your use. I still think it would
be best to find out how the lat/lon coordinates are
> calculated, and figure out what projection the data is on.
Otherwise, it will be difficult to correctly interpret the
> locations of the precip values in the gridded data.
>
> Please let me know if you have any questions.
>
> Paul
>
>
> On 07/24/2012 02:24 PM, Paul Oldenburg wrote:
> > Ellen,
> >
> > I started looking at how the precip data that you sent me is
stored, and what I found is a bit puzzling to me. For
> > example, the plot lat_image shows a color-scaled image of the Lat
dimension variable. One would expect the colors in
> > this image to change continuously and smoothly, indicating that
the latitude changes smoothly from top to bottom (or
> > upper-right to lower left, etc.). Instead, there is an irregular
patter to the values, as you can see. Then, I plotted
> > just the first row of latitude values, shown in lat_row_plot, and
the irregular pattern for just this row becomes more
> > evident.
> >
> > So, long story short, it's no surprise that the MET-readable data
that Haonan generated before has an alignment problem.
> > I think your underlying observation data source may also have an
alignment problem. Can you talk to the people who
> > generate this precip data and ask them about why their Lat/Lon
coordinates are so irregular? If we can figure out how
> > to interpret or fix this pattern, I or Haonan can probably figure
a way to build a converter so that MET can read it.
> >
> > Please let me know if you have any other questions for me.
> >
> > Paul
> >
> >
> > On 07/24/2012 01:41 PM, Ellen.Sukovich at noaa.gov via RT wrote:
> >>
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
> >>
> >> Hi Paul,
> >>
> >> Unfortunately we are still at a loss as to how to get our file
read into
> >> MET. While we thought we were able to get the file to be read
into
> >> MODE, the data looked incorrect. Haonan and I are out of ideas.
Back
> >> on 10 July you mentioned that you could try to create a script to
change
> >> the structure of the precip NetCDF so that MET could read it.
Could you
> >> see if this is possible? We will probably need this conversion
to be
> >> applied to more than one file.
> >>
> >> I am including the original file with this email (plus a file for
the
> >> next hour just in case).
> >>
> >> Thank you so much for your help,
> >> Ellen
> >>
> >>
> >> On 7/10/2012 10:55 AM, Paul Oldenburg via RT wrote:
> >>> Ellen,
> >>>
> >>> To our knowledge, converting from NetCDF to GRIB is an unsolved
problem. I think the easiest route would be to change
> >>> the structure of your precip NetCDF so that MET can read it - to
a format like the output of the pcp_combine tool. I
> >>> will try to whip up a script to do this for the one file you
sent me. Are you going to need this conversion performed
> >>> on more than just this one file? If so, I will try to make it
more user-friendly so you can use it.
> >>>
> >>> Paul
> >>>
> >>>
> >>> On 07/10/2012 10:34 AM, Ellen.Sukovich at noaa.gov via RT wrote:
> >>>> Tue Jul 10 10:34:38 2012: Request 57358 was acted upon.
> >>>> Transaction: Ticket created by Ellen.Sukovich at noaa.gov
>
> >>>> Queue: met_help
> >>>> Subject: MET netcdf to grib1 converter yet?
> >>>> Owner: Nobody
> >>>> Requestors: Ellen.Sukovich at noaa.gov
> >>>> Status: new
> >>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
> >>>>
> >>>>
> >>>> Hi MET Help,
> >>>>
> >>>> In the more recent versions of MET (i.e., v3.1 and v4) is there
a netcdf
> >>>> to grib1 converter? I have a netcdf file with precipitation
data (see
> >>>> attached) that was outputted from radar software but it is not
the
> >>>> netcdf version that MET wants. What is the best way to get
this into
> >>>> the netcdf form or grib1 format that MET will read? (Note: This
netcdf
> >>>> format is not output from WRF so the CDO conversion is not
applicable
> >>>> and my NCL guru here at NOAA doesn't know of an NCL command
that can do
> >>>> the conversion.)
> >>>>
> >>>> Thanks for your time!
> >>>> Ellen Sukovich
> >>>>
> >>>
> >>>
> >>
> >>
> >
>
>
>
>
>
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #57358] MET netcdf to grib1 converter yet?
From: Paul Oldenburg
Time: Thu Aug 23 07:49:50 2012
Ellen,
I'm going to resolve this met_help ticket in our system. I think that
this issue has moved away from being a met_help
situation and has become something more like a data-processing
problem. You can still feel free to send me information
and questions about the precip conversion script, of course, but
please don't reply to this message - otherwise our
system will re-open the ticket.
Thanks,
Paul
On 07/25/2012 04:49 PM, Haonan Chen via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>
> Hi Ellen
>
> The plots Paul sent look fine for me. The plots I sent a couple
weeks ago
> for a sample file were generated from a brief Matlab program. The
sample
> file was created by the MTR MPE program. As you know, all the files
> generated from MPE were in HRAP coordinates. To use the lat/lon
coordinates
> for making plots, I was using a program to convert the HRAP
coordinates to
> lat/lon coordinates. Before using this coordinate conversion
program, we
> need to use read_xmrg2 (under /home/hchen/bin on radarqpe) to read
the
> files generated from MPE or some other programs.
>
> Here I am attaching again the original plots in HRAP coordinates and
> corresponding one in lat/lon. There looks to be a shift in
coordinates. But
> it is Ok because of the properties of HRAP and Lat/Lon. The
projection
> program from HRAP to Lat/Lon is also attached here. It can actually
be
> regarded as a point-to-point conversion program. That means, the
program
> will convert the HRAP to Lat/Lon one point by one point as
specified.
>
> I am still looking into the file Paul sent to make a better
explanation on
> what I did before.
>
> Thanks so much.
>
> Haonan
>
> On Wed, Jul 25, 2012 at 2:18 PM, Ellen Sukovich
<ellen.sukovich at noaa.gov>wrote:
>
>> Hi Haonan,
>>
>> This is what Paul (from DTC) sent me today. What are your thoughts?
If
>> you could respond to both me and Paul (Paul Oldenburg via RT
>> <met_help at ucar.edu> <met_help at ucar.edu>) that would be great!
>>
>> Thanks,
>> Ellen
>>
>>
>> -------- Original Message -------- Subject: Re: [rt.rap.ucar.edu
#57358]
>> MET netcdf to grib1 converter yet? Date: Wed, 25 Jul 2012 13:24:09
-0600 From:
>> Paul Oldenburg via RT <met_help at ucar.edu> <met_help at ucar.edu>
Reply-To:
>> met_help at ucar.edu To: Ellen.Sukovich at noaa.gov CC:
>> met_help at mailman.ucar.edu
>>
>> Ellen,
>>
>> I wrote a script that borrows heavily from the trmm2nc.R script
that John wrote to convert the precip files you sent.
>> To be clear: I made many dubious assumptions when converting the
lat/lon information. I tested the attached NetCDF
>> files in MODE (METv4.0) and it worked as expected. I visually
compared the 17z plot to the one that Haonan sent a
>> couple weeks ago, and they looked similar, but not the same. Can
you tell me how that plot was made?
>>
>> If you think that the attached test data is good enough for your
purposes, I can clean up the conversion script that I
>> wrote and send it over to you for your use. I still think it would
be best to find out how the lat/lon coordinates are
>> calculated, and figure out what projection the data is on.
Otherwise, it will be difficult to correctly interpret the
>> locations of the precip values in the gridded data.
>>
>> Please let me know if you have any questions.
>>
>> Paul
>>
>>
>> On 07/24/2012 02:24 PM, Paul Oldenburg wrote:
>>> Ellen,
>>>
>>> I started looking at how the precip data that you sent me is
stored, and what I found is a bit puzzling to me. For
>>> example, the plot lat_image shows a color-scaled image of the Lat
dimension variable. One would expect the colors in
>>> this image to change continuously and smoothly, indicating that
the latitude changes smoothly from top to bottom (or
>>> upper-right to lower left, etc.). Instead, there is an irregular
patter to the values, as you can see. Then, I plotted
>>> just the first row of latitude values, shown in lat_row_plot, and
the irregular pattern for just this row becomes more
>>> evident.
>>>
>>> So, long story short, it's no surprise that the MET-readable data
that Haonan generated before has an alignment problem.
>>> I think your underlying observation data source may also have
an alignment problem. Can you talk to the people who
>>> generate this precip data and ask them about why their Lat/Lon
coordinates are so irregular? If we can figure out how
>>> to interpret or fix this pattern, I or Haonan can probably figure
a way to build a converter so that MET can read it.
>>>
>>> Please let me know if you have any other questions for me.
>>>
>>> Paul
>>>
>>>
>>> On 07/24/2012 01:41 PM, Ellen.Sukovich at noaa.gov via RT wrote:
>>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>>>>
>>>> Hi Paul,
>>>>
>>>> Unfortunately we are still at a loss as to how to get our file
read into
>>>> MET. While we thought we were able to get the file to be read
into
>>>> MODE, the data looked incorrect. Haonan and I are out of ideas.
Back
>>>> on 10 July you mentioned that you could try to create a script to
change
>>>> the structure of the precip NetCDF so that MET could read it.
Could you
>>>> see if this is possible? We will probably need this conversion
to be
>>>> applied to more than one file.
>>>>
>>>> I am including the original file with this email (plus a file for
the
>>>> next hour just in case).
>>>>
>>>> Thank you so much for your help,
>>>> Ellen
>>>>
>>>>
>>>> On 7/10/2012 10:55 AM, Paul Oldenburg via RT wrote:
>>>>> Ellen,
>>>>>
>>>>> To our knowledge, converting from NetCDF to GRIB is an unsolved
problem. I think the easiest route would be to change
>>>>> the structure of your precip NetCDF so that MET can read it - to
a format like the output of the pcp_combine tool. I
>>>>> will try to whip up a script to do this for the one file you
sent me. Are you going to need this conversion performed
>>>>> on more than just this one file? If so, I will try to make it
more user-friendly so you can use it.
>>>>>
>>>>> Paul
>>>>>
>>>>>
>>>>> On 07/10/2012 10:34 AM, Ellen.Sukovich at noaa.gov via RT wrote:
>>>>>> Tue Jul 10 10:34:38 2012: Request 57358 was acted upon.
>>>>>> Transaction: Ticket created by Ellen.Sukovich at noaa.gov
>>
>>>>>> Queue: met_help
>>>>>> Subject: MET netcdf to grib1 converter yet?
>>>>>> Owner: Nobody
>>>>>> Requestors: Ellen.Sukovich at noaa.gov
>>>>>> Status: new
>>>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=57358 >
>>>>>>
>>>>>>
>>>>>> Hi MET Help,
>>>>>>
>>>>>> In the more recent versions of MET (i.e., v3.1 and v4) is there
a netcdf
>>>>>> to grib1 converter? I have a netcdf file with precipitation
data (see
>>>>>> attached) that was outputted from radar software but it is not
the
>>>>>> netcdf version that MET wants. What is the best way to get
this into
>>>>>> the netcdf form or grib1 format that MET will read? (Note: This
netcdf
>>>>>> format is not output from WRF so the CDO conversion is not
applicable
>>>>>> and my NCL guru here at NOAA doesn't know of an NCL command
that can do
>>>>>> the conversion.)
>>>>>>
>>>>>> Thanks for your time!
>>>>>> Ellen Sukovich
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>
------------------------------------------------
More information about the Met_help
mailing list