[Met_help] [rt.rap.ucar.edu #44337] History for MODE
RAL HelpDesk {for John Halley Gotway}
met_help at ucar.edu
Wed Feb 23 14:41:11 MST 2011
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
I wish to run MODE using a data set that did not come from a model (it came
from observations) and one that does not have a constant grid spacing
value. Is that even possible with MODE?
Jeff Duda
--
Jeff Duda
Iowa State University
Meteorology Graduate Student
3134 Agronomy Hall
www.meteor.iastate.edu/~jdduda
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #44337] MODE
From: John Halley Gotway
Time: Fri Feb 11 13:20:36 2011
Jeff,
MODE can only handle data that's on a regularly spaced grid. For GRIB
files, it reads the grid definition from the grid description section
(GDS) or each GRIB record. For NetCDF files, like the
output of the PCP-Combine tool, it reads the grid definition from a
special set of global attributes. If you have a gridded dataset and
would like to use it in MODE, it'd need to be regularly spaced,
and it'd probably be easiest to write it as a NetCDF file making it
look like the output of the PCP-Combine tool.
Hope that helps.
John
On 02/11/2011 12:56 PM, RAL HelpDesk {for jdduda at iastate.edu} wrote:
> I wish to run MODE using a data set that did not come from a model
(it came
------------------------------------------------
Subject: MODE
From: jdduda at iastate.edu
Time: Fri Feb 11 13:25:45 2011
I should specify: the grid resolution is 0.01 deg lat by 0.01 deg lon.
So
it is regularly spaced in some sense, but not in terms of Euclidean
distance. Does that make a difference?
Jeff
On Fri, Feb 11, 2011 at 2:20 PM, RAL HelpDesk {for John Halley Gotway}
<
met_help at ucar.edu> wrote:
> Jeff,
>
> MODE can only handle data that's on a regularly spaced grid. For
GRIB
> files, it reads the grid definition from the grid description
section (GDS)
> or each GRIB record. For NetCDF files, like the
> output of the PCP-Combine tool, it reads the grid definition from a
special
> set of global attributes. If you have a gridded dataset and would
like to
> use it in MODE, it'd need to be regularly spaced,
> and it'd probably be easiest to write it as a NetCDF file making it
look
> like the output of the PCP-Combine tool.
>
> Hope that helps.
>
> John
>
> On 02/11/2011 12:56 PM, RAL HelpDesk {for jdduda at iastate.edu} wrote:
> > I wish to run MODE using a data set that did not come from a model
(it
> came
>
>
--
Jeff Duda
Iowa State University
Meteorology Graduate Student
3134 Agronomy Hall
www.meteor.iastate.edu/~jdduda
------------------------------------------------
Subject: MODE
From: John Halley Gotway
Time: Fri Feb 11 13:57:49 2011
Jeff,
That's fine actually. That's a lat/lon projection, or more correctly
Plate Carree. That's one of the projection types that MET can read.
Now the issue comes down getting it into a data format that
MET can read. As I mentioned, using NetCDF would probably be easiest.
I took a GRIB file that's defined over CONUS and regridded it to a
Lat/Lon grid over the Great Lakes. Then I ran it through
PCP-Combine to get a NetCDF version of that file. Here are the
commands I used:
cp METv3.0/data/sample_fcst/2005080700/wrfprs_ruc13_18.tm00_G212
lambert_conf.grib
copygb -xg"255 0 327 235 40908 -92200 128 49100 -75900 50 35 64"
lambert_conf.grib lat_lon.grib
METv3.0/bin/pcp_combine -add lat_lon.grib 03 lat_lon.nc
I've attached the resulting NetCDF file. If you do "ncdump -h" on it,
you'll see the header. Here's the relevant info for you...
In the global attributes, the following things must be defined. These
specify the grid on which your data is defined. You'll need to fill
in the values that define your grid:
:MET_version = "V3.0" ;
:Projection = "LatLon" ;
:lat_ll = "40.908000 degrees_north" ;
:lon_ll = "-92.200000 degrees_east" ;
:delta_lat = "0.035000 degrees" ;
:delta_lon = "0.050000 degrees" ;
:Nlat = "235 grid_points" ;
:Nlon = "327 grid_points" ;
In the dimensions section, you need to define dimensions named "lat"
and "lon":
lat = 235 ;
lon = 327 ;
In the variables section, you can name the variable whatever you'd
like, but it should be indexed by the lat and lon dimensions. Note,
you do NOT need to define the lat(lat,lon) and lon(lat,lon)
variables since MET doesn't actually use them:
float APCP_03(lat, lon) ;
APCP_03:level = "A3" ;
APCP_03:units = "kg/m^2" ;
APCP_03:_FillValue = -9999.f ;
APCP_03:init_time_ut = 1123372800 ;
APCP_03:valid_time_ut = 1123437600 ;
APCP_03:accum_time_sec = 10800 ;
As for the variable attributes listed above, I've only retained the
ones that MET actually reads. The rest you see in your ncdump output
can be omitted if you'd like.
Just let me know if you get stuck.
John
On 02/11/2011 01:25 PM, RAL HelpDesk {for jdduda at iastate.edu} wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=44337 >
>
> I should specify: the grid resolution is 0.01 deg lat by 0.01 deg
lon. So
> it is regularly spaced in some sense, but not in terms of Euclidean
> distance. Does that make a difference?
>
> Jeff
>
> On Fri, Feb 11, 2011 at 2:20 PM, RAL HelpDesk {for John Halley
Gotway} <
> met_help at ucar.edu> wrote:
>
>> Jeff,
>>
>> MODE can only handle data that's on a regularly spaced grid. For
GRIB
>> files, it reads the grid definition from the grid description
section (GDS)
>> or each GRIB record. For NetCDF files, like the
>> output of the PCP-Combine tool, it reads the grid definition from a
special
>> set of global attributes. If you have a gridded dataset and would
like to
>> use it in MODE, it'd need to be regularly spaced,
>> and it'd probably be easiest to write it as a NetCDF file making it
look
>> like the output of the PCP-Combine tool.
>>
>> Hope that helps.
>>
>> John
>>
>> On 02/11/2011 12:56 PM, RAL HelpDesk {for jdduda at iastate.edu}
wrote:
>>> I wish to run MODE using a data set that did not come from a model
(it
>> came
>>
>>
>
>
------------------------------------------------
Subject: MODE
From: jdduda at iastate.edu
Time: Fri Feb 11 14:02:58 2011
John,
I've attached the ncdump output from my files (which are already in
netCDF
format). The only reason I know the grid spacing is from the
documentation
on this data, not from the ncdump. I suppose I still need to run it
through
copygb in order to get it into a "nicer" format though, right?
Jeff
On Fri, Feb 11, 2011 at 2:57 PM, RAL HelpDesk {for John Halley Gotway}
<
met_help at ucar.edu> wrote:
> Jeff,
>
> That's fine actually. That's a lat/lon projection, or more
correctly Plate
> Carree. That's one of the projection types that MET can read. Now
the
> issue comes down getting it into a data format that
> MET can read. As I mentioned, using NetCDF would probably be
easiest. I
> took a GRIB file that's defined over CONUS and regridded it to a
Lat/Lon
> grid over the Great Lakes. Then I ran it through
> PCP-Combine to get a NetCDF version of that file. Here are the
commands I
> used:
>
> cp METv3.0/data/sample_fcst/2005080700/wrfprs_ruc13_18.tm00_G212
> lambert_conf.grib
> copygb -xg"255 0 327 235 40908 -92200 128 49100 -75900 50 35 64"
> lambert_conf.grib lat_lon.grib
> METv3.0/bin/pcp_combine -add lat_lon.grib 03 lat_lon.nc
>
> I've attached the resulting NetCDF file. If you do "ncdump -h" on
it,
> you'll see the header. Here's the relevant info for you...
>
> In the global attributes, the following things must be defined.
These
> specify the grid on which your data is defined. You'll need to fill
in the
> values that define your grid:
> :MET_version = "V3.0" ;
> :Projection = "LatLon" ;
> :lat_ll = "40.908000 degrees_north" ;
> :lon_ll = "-92.200000 degrees_east" ;
> :delta_lat = "0.035000 degrees" ;
> :delta_lon = "0.050000 degrees" ;
> :Nlat = "235 grid_points" ;
> :Nlon = "327 grid_points" ;
>
> In the dimensions section, you need to define dimensions named "lat"
and
> "lon":
> lat = 235 ;
> lon = 327 ;
>
> In the variables section, you can name the variable whatever you'd
like,
> but it should be indexed by the lat and lon dimensions. Note, you
do NOT
> need to define the lat(lat,lon) and lon(lat,lon)
> variables since MET doesn't actually use them:
> float APCP_03(lat, lon) ;
> APCP_03:level = "A3" ;
> APCP_03:units = "kg/m^2" ;
> APCP_03:_FillValue = -9999.f ;
> APCP_03:init_time_ut = 1123372800 ;
> APCP_03:valid_time_ut = 1123437600 ;
> APCP_03:accum_time_sec = 10800 ;
>
> As for the variable attributes listed above, I've only retained the
ones
> that MET actually reads. The rest you see in your ncdump output can
be
> omitted if you'd like.
>
> Just let me know if you get stuck.
>
> John
>
>
> On 02/11/2011 01:25 PM, RAL HelpDesk {for jdduda at iastate.edu} wrote:
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=44337 >
> >
> > I should specify: the grid resolution is 0.01 deg lat by 0.01 deg
lon.
> So
> > it is regularly spaced in some sense, but not in terms of
Euclidean
> > distance. Does that make a difference?
> >
> > Jeff
> >
> > On Fri, Feb 11, 2011 at 2:20 PM, RAL HelpDesk {for John Halley
Gotway} <
> > met_help at ucar.edu> wrote:
> >
> >> Jeff,
> >>
> >> MODE can only handle data that's on a regularly spaced grid. For
GRIB
> >> files, it reads the grid definition from the grid description
section
> (GDS)
> >> or each GRIB record. For NetCDF files, like the
> >> output of the PCP-Combine tool, it reads the grid definition from
a
> special
> >> set of global attributes. If you have a gridded dataset and
would like
> to
> >> use it in MODE, it'd need to be regularly spaced,
> >> and it'd probably be easiest to write it as a NetCDF file making
it look
> >> like the output of the PCP-Combine tool.
> >>
> >> Hope that helps.
> >>
> >> John
> >>
> >> On 02/11/2011 12:56 PM, RAL HelpDesk {for jdduda at iastate.edu}
wrote:
> >>> I wish to run MODE using a data set that did not come from a
model (it
> >> came
> >>
> >>
> >
> >
>
>
--
Jeff Duda
Iowa State University
Meteorology Graduate Student
3134 Agronomy Hall
www.meteor.iastate.edu/~jdduda
------------------------------------------------
Subject: MODE
From: jdduda at iastate.edu
Time: Fri Feb 11 14:02:58 2011
netcdf \20100730-110000 {
dimensions:
Lat = 1501 ;
Lon = 2001 ;
variables:
short cref(Lat, Lon) ;
cref:Units = "dBZ" ;
cref:TypeName = "cref" ;
cref:MissingData = -999.f ;
cref:Scale = 10.f ;
cref:attributes = ;
short hgt_cref(Lat, Lon) ;
hgt_cref:Units = "kmMSL" ;
hgt_cref:TypeName = "hgt_cref" ;
hgt_cref:MissingData = -1.f ;
hgt_cref:Scale = 1000.f ;
hgt_cref:attributes = ;
short etp18(Lat, Lon) ;
etp18:Units = "kmMSL" ;
etp18:TypeName = "etp18" ;
etp18:MissingData = -1.f ;
etp18:Scale = 1000.f ;
etp18:attributes = ;
short shi(Lat, Lon) ;
shi:Units = " " ;
shi:TypeName = "shi" ;
shi:MissingData = -999.f ;
shi:Scale = 10.f ;
shi:attributes = ;
short posh(Lat, Lon) ;
posh:Units = "% " ;
posh:TypeName = "posh" ;
posh:MissingData = -999.f ;
posh:Scale = 10.f ;
posh:attributes = ;
short mehs(Lat, Lon) ;
mehs:Units = "mm" ;
mehs:TypeName = "mehs" ;
mehs:MissingData = -999.f ;
mehs:Scale = 10.f ;
mehs:attributes = ;
short hsr(Lat, Lon) ;
hsr:Units = "dBZ" ;
hsr:TypeName = "hsr" ;
hsr:MissingData = -999.f ;
hsr:Scale = 10.f ;
hsr:attributes = ;
short hsrh(Lat, Lon) ;
hsrh:Units = "kmAGL" ;
hsrh:TypeName = "hsrh" ;
hsrh:MissingData = -1.f ;
hsrh:Scale = 1000.f ;
hsrh:attributes = ;
short lcref(Lat, Lon) ;
lcref:Units = "dBZ" ;
lcref:TypeName = "lcref" ;
lcref:MissingData = -999.f ;
lcref:Scale = 10.f ;
lcref:attributes = ;
short hgt_lcref(Lat, Lon) ;
hgt_lcref:Units = "kmMSL" ;
hgt_lcref:TypeName = "hgt_lcref" ;
hgt_lcref:MissingData = -1.f ;
hgt_lcref:Scale = 1000.f ;
hgt_lcref:attributes = ;
short vil(Lat, Lon) ;
vil:Units = "kg/m2" ;
vil:TypeName = "vil" ;
vil:MissingData = -999.f ;
vil:Scale = 10.f ;
vil:attributes = ;
short vilD(Lat, Lon) ;
vilD:Units = "g/m3" ;
vilD:TypeName = "vilD" ;
vilD:MissingData = -999.f ;
vilD:Scale = 10.f ;
vilD:attributes = ;
short pcp_flag(Lat, Lon) ;
pcp_flag:Units = "flag" ;
pcp_flag:TypeName = "pcp_flag" ;
pcp_flag:MissingData = -999.f ;
pcp_flag:attributes = ;
short pcp_type(Lat, Lon) ;
pcp_type:Units = "flag" ;
pcp_type:TypeName = "pcp_type" ;
pcp_type:MissingData = -999.f ;
pcp_type:attributes = ;
// global attributes:
:DataType = "LatLonGrid" ;
:Time = 1280487600 ;
:FractionalTime = 0.f ;
:RangeFolded = -99901.f ;
:Latitude = 55.f ;
:Longitude = -110.f ;
:Height = 0.f ;
:LatGridSpacing = 0.01f ;
:LonGridSpacing = 0.01f ;
}
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #44337] MODE
From: John Halley Gotway
Time: Fri Feb 11 14:22:33 2011
Jeff,
No, you do not need to run it through copygb. In fact, copygb only
handles GRIB files. It does not read NetCDF files. What you'll need
to do is write a script to massage your data files to add all
the variables/dimensions/attributes it's looking for. Just look at
the example info I sent, and modify one of your NetCDF files to make
it so that MET can read it.
John
On 02/11/2011 02:02 PM, RAL HelpDesk {for jdduda at iastate.edu} wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=44337 >
>
> netcdf \20100730-110000 {
> dimensions:
> Lat = 1501 ;
> Lon = 2001 ;
> variables:
> short cref(Lat, Lon) ;
> cref:Units = "dBZ" ;
> cref:TypeName = "cref" ;
> cref:MissingData = -999.f ;
> cref:Scale = 10.f ;
> cref:attributes = ;
> short hgt_cref(Lat, Lon) ;
> hgt_cref:Units = "kmMSL" ;
> hgt_cref:TypeName = "hgt_cref" ;
> hgt_cref:MissingData = -1.f ;
> hgt_cref:Scale = 1000.f ;
> hgt_cref:attributes = ;
> short etp18(Lat, Lon) ;
> etp18:Units = "kmMSL" ;
> etp18:TypeName = "etp18" ;
> etp18:MissingData = -1.f ;
> etp18:Scale = 1000.f ;
> etp18:attributes = ;
> short shi(Lat, Lon) ;
> shi:Units = " " ;
> shi:TypeName = "shi" ;
> shi:MissingData = -999.f ;
> shi:Scale = 10.f ;
> shi:attributes = ;
> short posh(Lat, Lon) ;
> posh:Units = "% " ;
> posh:TypeName = "posh" ;
> posh:MissingData = -999.f ;
> posh:Scale = 10.f ;
> posh:attributes = ;
> short mehs(Lat, Lon) ;
> mehs:Units = "mm" ;
> mehs:TypeName = "mehs" ;
> mehs:MissingData = -999.f ;
> mehs:Scale = 10.f ;
> mehs:attributes = ;
> short hsr(Lat, Lon) ;
> hsr:Units = "dBZ" ;
> hsr:TypeName = "hsr" ;
> hsr:MissingData = -999.f ;
> hsr:Scale = 10.f ;
> hsr:attributes = ;
> short hsrh(Lat, Lon) ;
> hsrh:Units = "kmAGL" ;
> hsrh:TypeName = "hsrh" ;
> hsrh:MissingData = -1.f ;
> hsrh:Scale = 1000.f ;
> hsrh:attributes = ;
> short lcref(Lat, Lon) ;
> lcref:Units = "dBZ" ;
> lcref:TypeName = "lcref" ;
> lcref:MissingData = -999.f ;
> lcref:Scale = 10.f ;
> lcref:attributes = ;
> short hgt_lcref(Lat, Lon) ;
> hgt_lcref:Units = "kmMSL" ;
> hgt_lcref:TypeName = "hgt_lcref" ;
> hgt_lcref:MissingData = -1.f ;
> hgt_lcref:Scale = 1000.f ;
> hgt_lcref:attributes = ;
> short vil(Lat, Lon) ;
> vil:Units = "kg/m2" ;
> vil:TypeName = "vil" ;
> vil:MissingData = -999.f ;
> vil:Scale = 10.f ;
> vil:attributes = ;
> short vilD(Lat, Lon) ;
> vilD:Units = "g/m3" ;
> vilD:TypeName = "vilD" ;
> vilD:MissingData = -999.f ;
> vilD:Scale = 10.f ;
> vilD:attributes = ;
> short pcp_flag(Lat, Lon) ;
> pcp_flag:Units = "flag" ;
> pcp_flag:TypeName = "pcp_flag" ;
> pcp_flag:MissingData = -999.f ;
> pcp_flag:attributes = ;
> short pcp_type(Lat, Lon) ;
> pcp_type:Units = "flag" ;
> pcp_type:TypeName = "pcp_type" ;
> pcp_type:MissingData = -999.f ;
> pcp_type:attributes = ;
>
> // global attributes:
> :DataType = "LatLonGrid" ;
> :Time = 1280487600 ;
> :FractionalTime = 0.f ;
> :RangeFolded = -99901.f ;
> :Latitude = 55.f ;
> :Longitude = -110.f ;
> :Height = 0.f ;
> :LatGridSpacing = 0.01f ;
> :LonGridSpacing = 0.01f ;
> }
>
>
>
>
> John,
> I've attached the ncdump output from my files (which are already in
netCDF
> format). The only reason I know the grid spacing is from the
documentation
> on this data, not from the ncdump. I suppose I still need to run it
through
> copygb in order to get it into a "nicer" format though, right?
>
> Jeff
>
> On Fri, Feb 11, 2011 at 2:57 PM, RAL HelpDesk {for John Halley
Gotway} <
> met_help at ucar.edu> wrote:
>
>> Jeff,
>>
>> That's fine actually. That's a lat/lon projection, or more
correctly Plate
>> Carree. That's one of the projection types that MET can read. Now
the
>> issue comes down getting it into a data format that
>> MET can read. As I mentioned, using NetCDF would probably be
easiest. I
>> took a GRIB file that's defined over CONUS and regridded it to a
Lat/Lon
>> grid over the Great Lakes. Then I ran it through
>> PCP-Combine to get a NetCDF version of that file. Here are the
commands I
>> used:
>>
>> cp METv3.0/data/sample_fcst/2005080700/wrfprs_ruc13_18.tm00_G212
>> lambert_conf.grib
>> copygb -xg"255 0 327 235 40908 -92200 128 49100 -75900 50 35 64"
>> lambert_conf.grib lat_lon.grib
>> METv3.0/bin/pcp_combine -add lat_lon.grib 03 lat_lon.nc
>>
>> I've attached the resulting NetCDF file. If you do "ncdump -h" on
it,
>> you'll see the header. Here's the relevant info for you...
>>
>> In the global attributes, the following things must be defined.
These
>> specify the grid on which your data is defined. You'll need to
fill in the
>> values that define your grid:
>> :MET_version = "V3.0" ;
>> :Projection = "LatLon" ;
>> :lat_ll = "40.908000 degrees_north" ;
>> :lon_ll = "-92.200000 degrees_east" ;
>> :delta_lat = "0.035000 degrees" ;
>> :delta_lon = "0.050000 degrees" ;
>> :Nlat = "235 grid_points" ;
>> :Nlon = "327 grid_points" ;
>>
>> In the dimensions section, you need to define dimensions named
"lat" and
>> "lon":
>> lat = 235 ;
>> lon = 327 ;
>>
>> In the variables section, you can name the variable whatever you'd
like,
>> but it should be indexed by the lat and lon dimensions. Note, you
do NOT
>> need to define the lat(lat,lon) and lon(lat,lon)
>> variables since MET doesn't actually use them:
>> float APCP_03(lat, lon) ;
>> APCP_03:level = "A3" ;
>> APCP_03:units = "kg/m^2" ;
>> APCP_03:_FillValue = -9999.f ;
>> APCP_03:init_time_ut = 1123372800 ;
>> APCP_03:valid_time_ut = 1123437600 ;
>> APCP_03:accum_time_sec = 10800 ;
>>
>> As for the variable attributes listed above, I've only retained the
ones
>> that MET actually reads. The rest you see in your ncdump output
can be
>> omitted if you'd like.
>>
>> Just let me know if you get stuck.
>>
>> John
>>
>>
>> On 02/11/2011 01:25 PM, RAL HelpDesk {for jdduda at iastate.edu}
wrote:
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=44337 >
>>>
>>> I should specify: the grid resolution is 0.01 deg lat by 0.01 deg
lon.
>> So
>>> it is regularly spaced in some sense, but not in terms of
Euclidean
>>> distance. Does that make a difference?
>>>
>>> Jeff
>>>
>>> On Fri, Feb 11, 2011 at 2:20 PM, RAL HelpDesk {for John Halley
Gotway} <
>>> met_help at ucar.edu> wrote:
>>>
>>>> Jeff,
>>>>
>>>> MODE can only handle data that's on a regularly spaced grid. For
GRIB
>>>> files, it reads the grid definition from the grid description
section
>> (GDS)
>>>> or each GRIB record. For NetCDF files, like the
>>>> output of the PCP-Combine tool, it reads the grid definition from
a
>> special
>>>> set of global attributes. If you have a gridded dataset and
would like
>> to
>>>> use it in MODE, it'd need to be regularly spaced,
>>>> and it'd probably be easiest to write it as a NetCDF file making
it look
>>>> like the output of the PCP-Combine tool.
>>>>
>>>> Hope that helps.
>>>>
>>>> John
>>>>
>>>> On 02/11/2011 12:56 PM, RAL HelpDesk {for jdduda at iastate.edu}
wrote:
>>>>> I wish to run MODE using a data set that did not come from a
model (it
>>>> came
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
>
> John,
> I've attached the ncdump output from my files (which are already in
netCDF
> format). The only reason I know the grid spacing is from the
documentation on
> this data, not from the ncdump. I suppose I still need to run it
through copygb
> in order to get it into a "nicer" format though, right?
>
> Jeff
>
> On Fri, Feb 11, 2011 at 2:57 PM, RAL HelpDesk {for John Halley
Gotway}
> <met_help at ucar.edu <mailto:met_help at ucar.edu>> wrote:
>
> Jeff,
>
> That's fine actually. That's a lat/lon projection, or more
correctly Plate
> Carree. That's one of the projection types that MET can read.
Now the
> issue comes down getting it into a data format that
> MET can read. As I mentioned, using NetCDF would probably be
easiest. I
> took a GRIB file that's defined over CONUS and regridded it to a
Lat/Lon
> grid over the Great Lakes. Then I ran it through
> PCP-Combine to get a NetCDF version of that file. Here are the
commands I used:
>
> cp METv3.0/data/sample_fcst/2005080700/wrfprs_ruc13_18.tm00_G212
> lambert_conf.grib
> copygb -xg"255 0 327 235 40908 -92200 128 49100 -75900 50 35 64"
> lambert_conf.grib lat_lon.grib
> METv3.0/bin/pcp_combine -add lat_lon.grib 03 lat_lon.nc
<http://lat_lon.nc>
>
> I've attached the resulting NetCDF file. If you do "ncdump -h"
on it,
> you'll see the header. Here's the relevant info for you...
>
> In the global attributes, the following things must be defined.
These
> specify the grid on which your data is defined. You'll need to
fill in the
> values that define your grid:
> :MET_version = "V3.0" ;
> :Projection = "LatLon" ;
> :lat_ll = "40.908000 degrees_north" ;
> :lon_ll = "-92.200000 degrees_east" ;
> :delta_lat = "0.035000 degrees" ;
> :delta_lon = "0.050000 degrees" ;
> :Nlat = "235 grid_points" ;
> :Nlon = "327 grid_points" ;
>
> In the dimensions section, you need to define dimensions named
"lat" and "lon":
> lat = 235 ;
> lon = 327 ;
>
> In the variables section, you can name the variable whatever
you'd like, but
> it should be indexed by the lat and lon dimensions. Note, you
do NOT need
> to define the lat(lat,lon) and lon(lat,lon)
> variables since MET doesn't actually use them:
> float APCP_03(lat, lon) ;
> APCP_03:level = "A3" ;
> APCP_03:units = "kg/m^2" ;
> APCP_03:_FillValue = -9999.f ;
> APCP_03:init_time_ut = 1123372800 ;
> APCP_03:valid_time_ut = 1123437600 ;
> APCP_03:accum_time_sec = 10800 ;
>
> As for the variable attributes listed above, I've only retained
the ones
> that MET actually reads. The rest you see in your ncdump output
can be
> omitted if you'd like.
>
> Just let me know if you get stuck.
>
> John
>
>
> On 02/11/2011 01:25 PM, RAL HelpDesk {for jdduda at iastate.edu
> <mailto:jdduda at iastate.edu>} wrote:
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=44337
>
> >
> > I should specify: the grid resolution is 0.01 deg lat by 0.01
deg lon. So
> > it is regularly spaced in some sense, but not in terms of
Euclidean
> > distance. Does that make a difference?
> >
> > Jeff
> >
> > On Fri, Feb 11, 2011 at 2:20 PM, RAL HelpDesk {for John
Halley Gotway} <
> > met_help at ucar.edu <mailto:met_help at ucar.edu>> wrote:
> >
> >> Jeff,
> >>
> >> MODE can only handle data that's on a regularly spaced grid.
For GRIB
> >> files, it reads the grid definition from the grid
description section (GDS)
> >> or each GRIB record. For NetCDF files, like the
> >> output of the PCP-Combine tool, it reads the grid definition
from a special
> >> set of global attributes. If you have a gridded dataset and
would like to
> >> use it in MODE, it'd need to be regularly spaced,
> >> and it'd probably be easiest to write it as a NetCDF file
making it look
> >> like the output of the PCP-Combine tool.
> >>
> >> Hope that helps.
> >>
> >> John
> >>
> >> On 02/11/2011 12:56 PM, RAL HelpDesk {for jdduda at iastate.edu
> <mailto:jdduda at iastate.edu>} wrote:
> >>> I wish to run MODE using a data set that did not come from
a model (it
> >> came
> >>
> >>
> >
> >
>
>
>
>
> --
> Jeff Duda
> Iowa State University
> Meteorology Graduate Student
> 3134 Agronomy Hall
> www.meteor.iastate.edu/~jdduda
<http://www.meteor.iastate.edu/~jdduda>
------------------------------------------------
Subject: MODE
From: jdduda at iastate.edu
Time: Fri Feb 11 14:42:39 2011
I'm afraid I don't understand. Doesn't my netcdf file already have
that
information in it? That's what the
DataType = "LatLonGrid"
Latitude = 55.f ;
Longitude = -110.f ;
LatGridSpacing = 0.01f ; and
LonGridSpacing = 0.01f ;
items mean in my ncdump output, right?
Jeff
On Fri, Feb 11, 2011 at 3:22 PM, RAL HelpDesk {for John Halley Gotway}
<
met_help at ucar.edu> wrote:
> Jeff,
>
> No, you do not need to run it through copygb. In fact, copygb only
handles
> GRIB files. It does not read NetCDF files. What you'll need to do
is write
> a script to massage your data files to add all
> the variables/dimensions/attributes it's looking for. Just look at
the
> example info I sent, and modify one of your NetCDF files to make it
so that
> MET can read it.
>
> John
>
> On 02/11/2011 02:02 PM, RAL HelpDesk {for jdduda at iastate.edu} wrote:
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=44337 >
> >
> > netcdf \20100730-110000 {
> > dimensions:
> > Lat = 1501 ;
> > Lon = 2001 ;
> > variables:
> > short cref(Lat, Lon) ;
> > cref:Units = "dBZ" ;
> > cref:TypeName = "cref" ;
> > cref:MissingData = -999.f ;
> > cref:Scale = 10.f ;
> > cref:attributes = ;
> > short hgt_cref(Lat, Lon) ;
> > hgt_cref:Units = "kmMSL" ;
> > hgt_cref:TypeName = "hgt_cref" ;
> > hgt_cref:MissingData = -1.f ;
> > hgt_cref:Scale = 1000.f ;
> > hgt_cref:attributes = ;
> > short etp18(Lat, Lon) ;
> > etp18:Units = "kmMSL" ;
> > etp18:TypeName = "etp18" ;
> > etp18:MissingData = -1.f ;
> > etp18:Scale = 1000.f ;
> > etp18:attributes = ;
> > short shi(Lat, Lon) ;
> > shi:Units = " " ;
> > shi:TypeName = "shi" ;
> > shi:MissingData = -999.f ;
> > shi:Scale = 10.f ;
> > shi:attributes = ;
> > short posh(Lat, Lon) ;
> > posh:Units = "% " ;
> > posh:TypeName = "posh" ;
> > posh:MissingData = -999.f ;
> > posh:Scale = 10.f ;
> > posh:attributes = ;
> > short mehs(Lat, Lon) ;
> > mehs:Units = "mm" ;
> > mehs:TypeName = "mehs" ;
> > mehs:MissingData = -999.f ;
> > mehs:Scale = 10.f ;
> > mehs:attributes = ;
> > short hsr(Lat, Lon) ;
> > hsr:Units = "dBZ" ;
> > hsr:TypeName = "hsr" ;
> > hsr:MissingData = -999.f ;
> > hsr:Scale = 10.f ;
> > hsr:attributes = ;
> > short hsrh(Lat, Lon) ;
> > hsrh:Units = "kmAGL" ;
> > hsrh:TypeName = "hsrh" ;
> > hsrh:MissingData = -1.f ;
> > hsrh:Scale = 1000.f ;
> > hsrh:attributes = ;
> > short lcref(Lat, Lon) ;
> > lcref:Units = "dBZ" ;
> > lcref:TypeName = "lcref" ;
> > lcref:MissingData = -999.f ;
> > lcref:Scale = 10.f ;
> > lcref:attributes = ;
> > short hgt_lcref(Lat, Lon) ;
> > hgt_lcref:Units = "kmMSL" ;
> > hgt_lcref:TypeName = "hgt_lcref" ;
> > hgt_lcref:MissingData = -1.f ;
> > hgt_lcref:Scale = 1000.f ;
> > hgt_lcref:attributes = ;
> > short vil(Lat, Lon) ;
> > vil:Units = "kg/m2" ;
> > vil:TypeName = "vil" ;
> > vil:MissingData = -999.f ;
> > vil:Scale = 10.f ;
> > vil:attributes = ;
> > short vilD(Lat, Lon) ;
> > vilD:Units = "g/m3" ;
> > vilD:TypeName = "vilD" ;
> > vilD:MissingData = -999.f ;
> > vilD:Scale = 10.f ;
> > vilD:attributes = ;
> > short pcp_flag(Lat, Lon) ;
> > pcp_flag:Units = "flag" ;
> > pcp_flag:TypeName = "pcp_flag" ;
> > pcp_flag:MissingData = -999.f ;
> > pcp_flag:attributes = ;
> > short pcp_type(Lat, Lon) ;
> > pcp_type:Units = "flag" ;
> > pcp_type:TypeName = "pcp_type" ;
> > pcp_type:MissingData = -999.f ;
> > pcp_type:attributes = ;
> >
> > // global attributes:
> > :DataType = "LatLonGrid" ;
> > :Time = 1280487600 ;
> > :FractionalTime = 0.f ;
> > :RangeFolded = -99901.f ;
> > :Latitude = 55.f ;
> > :Longitude = -110.f ;
> > :Height = 0.f ;
> > :LatGridSpacing = 0.01f ;
> > :LonGridSpacing = 0.01f ;
> > }
> >
> >
> >
> >
> > John,
> > I've attached the ncdump output from my files (which are already
in
> netCDF
> > format). The only reason I know the grid spacing is from the
> documentation
> > on this data, not from the ncdump. I suppose I still need to run
it
> through
> > copygb in order to get it into a "nicer" format though, right?
> >
> > Jeff
> >
> > On Fri, Feb 11, 2011 at 2:57 PM, RAL HelpDesk {for John Halley
Gotway} <
> > met_help at ucar.edu> wrote:
> >
> >> Jeff,
> >>
> >> That's fine actually. That's a lat/lon projection, or more
correctly
> Plate
> >> Carree. That's one of the projection types that MET can read.
Now the
> >> issue comes down getting it into a data format that
> >> MET can read. As I mentioned, using NetCDF would probably be
easiest.
> I
> >> took a GRIB file that's defined over CONUS and regridded it to a
Lat/Lon
> >> grid over the Great Lakes. Then I ran it through
> >> PCP-Combine to get a NetCDF version of that file. Here are the
commands
> I
> >> used:
> >>
> >> cp METv3.0/data/sample_fcst/2005080700/wrfprs_ruc13_18.tm00_G212
> >> lambert_conf.grib
> >> copygb -xg"255 0 327 235 40908 -92200 128 49100 -75900 50 35 64"
> >> lambert_conf.grib lat_lon.grib
> >> METv3.0/bin/pcp_combine -add lat_lon.grib 03 lat_lon.nc
> >>
> >> I've attached the resulting NetCDF file. If you do "ncdump -h"
on it,
> >> you'll see the header. Here's the relevant info for you...
> >>
> >> In the global attributes, the following things must be defined.
These
> >> specify the grid on which your data is defined. You'll need to
fill in
> the
> >> values that define your grid:
> >> :MET_version = "V3.0" ;
> >> :Projection = "LatLon" ;
> >> :lat_ll = "40.908000 degrees_north" ;
> >> :lon_ll = "-92.200000 degrees_east" ;
> >> :delta_lat = "0.035000 degrees" ;
> >> :delta_lon = "0.050000 degrees" ;
> >> :Nlat = "235 grid_points" ;
> >> :Nlon = "327 grid_points" ;
> >>
> >> In the dimensions section, you need to define dimensions named
"lat" and
> >> "lon":
> >> lat = 235 ;
> >> lon = 327 ;
> >>
> >> In the variables section, you can name the variable whatever
you'd like,
> >> but it should be indexed by the lat and lon dimensions. Note,
you do
> NOT
> >> need to define the lat(lat,lon) and lon(lat,lon)
> >> variables since MET doesn't actually use them:
> >> float APCP_03(lat, lon) ;
> >> APCP_03:level = "A3" ;
> >> APCP_03:units = "kg/m^2" ;
> >> APCP_03:_FillValue = -9999.f ;
> >> APCP_03:init_time_ut = 1123372800 ;
> >> APCP_03:valid_time_ut = 1123437600 ;
> >> APCP_03:accum_time_sec = 10800 ;
> >>
> >> As for the variable attributes listed above, I've only retained
the ones
> >> that MET actually reads. The rest you see in your ncdump output
can be
> >> omitted if you'd like.
> >>
> >> Just let me know if you get stuck.
> >>
> >> John
> >>
> >>
> >> On 02/11/2011 01:25 PM, RAL HelpDesk {for jdduda at iastate.edu}
wrote:
> >>>
> >>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=44337 >
> >>>
> >>> I should specify: the grid resolution is 0.01 deg lat by 0.01
deg lon.
> >> So
> >>> it is regularly spaced in some sense, but not in terms of
Euclidean
> >>> distance. Does that make a difference?
> >>>
> >>> Jeff
> >>>
> >>> On Fri, Feb 11, 2011 at 2:20 PM, RAL HelpDesk {for John Halley
Gotway}
> <
> >>> met_help at ucar.edu> wrote:
> >>>
> >>>> Jeff,
> >>>>
> >>>> MODE can only handle data that's on a regularly spaced grid.
For GRIB
> >>>> files, it reads the grid definition from the grid description
section
> >> (GDS)
> >>>> or each GRIB record. For NetCDF files, like the
> >>>> output of the PCP-Combine tool, it reads the grid definition
from a
> >> special
> >>>> set of global attributes. If you have a gridded dataset and
would
> like
> >> to
> >>>> use it in MODE, it'd need to be regularly spaced,
> >>>> and it'd probably be easiest to write it as a NetCDF file
making it
> look
> >>>> like the output of the PCP-Combine tool.
> >>>>
> >>>> Hope that helps.
> >>>>
> >>>> John
> >>>>
> >>>> On 02/11/2011 12:56 PM, RAL HelpDesk {for jdduda at iastate.edu}
wrote:
> >>>>> I wish to run MODE using a data set that did not come from a
model
> (it
> >>>> came
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
> >
> > John,
> > I've attached the ncdump output from my files (which are already
in
> netCDF
> > format). The only reason I know the grid spacing is from the
> documentation on
> > this data, not from the ncdump. I suppose I still need to run it
through
> copygb
> > in order to get it into a "nicer" format though, right?
> >
> > Jeff
> >
> > On Fri, Feb 11, 2011 at 2:57 PM, RAL HelpDesk {for John Halley
Gotway}
> > <met_help at ucar.edu <mailto:met_help at ucar.edu>> wrote:
> >
> > Jeff,
> >
> > That's fine actually. That's a lat/lon projection, or more
correctly
> Plate
> > Carree. That's one of the projection types that MET can read.
Now
> the
> > issue comes down getting it into a data format that
> > MET can read. As I mentioned, using NetCDF would probably be
> easiest. I
> > took a GRIB file that's defined over CONUS and regridded it to
a
> Lat/Lon
> > grid over the Great Lakes. Then I ran it through
> > PCP-Combine to get a NetCDF version of that file. Here are
the
> commands I used:
> >
> > cp
METv3.0/data/sample_fcst/2005080700/wrfprs_ruc13_18.tm00_G212
> > lambert_conf.grib
> > copygb -xg"255 0 327 235 40908 -92200 128 49100 -75900 50 35
64"
> > lambert_conf.grib lat_lon.grib
> > METv3.0/bin/pcp_combine -add lat_lon.grib 03 lat_lon.nc <
> http://lat_lon.nc>
> >
> > I've attached the resulting NetCDF file. If you do "ncdump
-h" on
> it,
> > you'll see the header. Here's the relevant info for you...
> >
> > In the global attributes, the following things must be
defined.
> These
> > specify the grid on which your data is defined. You'll need
to fill
> in the
> > values that define your grid:
> > :MET_version = "V3.0" ;
> > :Projection = "LatLon" ;
> > :lat_ll = "40.908000 degrees_north" ;
> > :lon_ll = "-92.200000 degrees_east" ;
> > :delta_lat = "0.035000 degrees" ;
> > :delta_lon = "0.050000 degrees" ;
> > :Nlat = "235 grid_points" ;
> > :Nlon = "327 grid_points" ;
> >
> > In the dimensions section, you need to define dimensions named
"lat"
> and "lon":
> > lat = 235 ;
> > lon = 327 ;
> >
> > In the variables section, you can name the variable whatever
you'd
> like, but
> > it should be indexed by the lat and lon dimensions. Note, you
do NOT
> need
> > to define the lat(lat,lon) and lon(lat,lon)
> > variables since MET doesn't actually use them:
> > float APCP_03(lat, lon) ;
> > APCP_03:level = "A3" ;
> > APCP_03:units = "kg/m^2" ;
> > APCP_03:_FillValue = -9999.f ;
> > APCP_03:init_time_ut = 1123372800 ;
> > APCP_03:valid_time_ut = 1123437600 ;
> > APCP_03:accum_time_sec = 10800 ;
> >
> > As for the variable attributes listed above, I've only
retained the
> ones
> > that MET actually reads. The rest you see in your ncdump
output can
> be
> > omitted if you'd like.
> >
> > Just let me know if you get stuck.
> >
> > John
> >
> >
> > On 02/11/2011 01:25 PM, RAL HelpDesk {for jdduda at iastate.edu
> > <mailto:jdduda at iastate.edu>} wrote:
> > >
> > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=44337 >
> > >
> > > I should specify: the grid resolution is 0.01 deg lat by
0.01 deg
> lon. So
> > > it is regularly spaced in some sense, but not in terms of
> Euclidean
> > > distance. Does that make a difference?
> > >
> > > Jeff
> > >
> > > On Fri, Feb 11, 2011 at 2:20 PM, RAL HelpDesk {for John
Halley
> Gotway} <
> > > met_help at ucar.edu <mailto:met_help at ucar.edu>> wrote:
> > >
> > >> Jeff,
> > >>
> > >> MODE can only handle data that's on a regularly spaced
grid. For
> GRIB
> > >> files, it reads the grid definition from the grid
description
> section (GDS)
> > >> or each GRIB record. For NetCDF files, like the
> > >> output of the PCP-Combine tool, it reads the grid
definition from
> a special
> > >> set of global attributes. If you have a gridded dataset
and
> would like to
> > >> use it in MODE, it'd need to be regularly spaced,
> > >> and it'd probably be easiest to write it as a NetCDF file
making
> it look
> > >> like the output of the PCP-Combine tool.
> > >>
> > >> Hope that helps.
> > >>
> > >> John
> > >>
> > >> On 02/11/2011 12:56 PM, RAL HelpDesk {for
jdduda at iastate.edu
> > <mailto:jdduda at iastate.edu>} wrote:
> > >>> I wish to run MODE using a data set that did not come
from a
> model (it
> > >> came
> > >>
> > >>
> > >
> > >
> >
> >
> >
> >
> > --
> > Jeff Duda
> > Iowa State University
> > Meteorology Graduate Student
> > 3134 Agronomy Hall
> > www.meteor.iastate.edu/~jdduda
<http://www.meteor.iastate.edu/%7Ejdduda><
> http://www.meteor.iastate.edu/~jdduda>
>
>
--
Jeff Duda
Iowa State University
Meteorology Graduate Student
3134 Agronomy Hall
www.meteor.iastate.edu/~jdduda
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #44337] MODE
From: John Halley Gotway
Time: Fri Feb 11 14:53:18 2011
Jeff,
Here are the discrepancies I see. Listed on the left is what you have
and listed on the right it what MET is looking to read.
Global Attributes:
missing <---> MET_version = "V3.0"
DataType = "LatLonGrid" <---> Projection = "LatLon"
Latitude = 55.f ; <---> lat_ll = "55.0" (note, this is actually
a string)
Longitude = -110.f ; <---> lon_ll = "-100.0" (again, a string)
LatGridSpacing = 0.01f ; <---> delta_lat = "0.01" (string)
LonGridSpacing = 0.01f ; <---> delta_lon = "0.01" (string)
missing <---> Nlat = "1501"
missing <---> Nlon = "2001"
Dimensions:
Lat = 1501 <---> lat=1501
Lon = 2001 <---> lon=2001
Variable attributes:
missing <---> level = "SFC"
Units = "dBZ" ; <---> units = "dBZ"
MissingData = -999.f ; <---> _FillValue = -9999.f
missing <---> init_time_ut = 1123372800 (in unixtime)
missing <---> valid_time_ut = 1123437600 (in
unixtime)
missing <---> accum_time_sec = 0 (in seconds)
Unfortunately, in order for MET to read/understand your file, all of
these things must be named exactly as specified - even down to
capitalization. Otherwise, you'll get a NetCDF error when MET tries
to read them. We're planning to enhance our support for NetCDF in
future versions of MET to parse CF-compliant NetCDF files, but we're
not there yet. As of now, if you want to read custom data into
MET, it must be formatted in a very specific way.
Thanks,
John
On 02/11/2011 02:42 PM, RAL HelpDesk {for jdduda at iastate.edu} wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=44337 >
>
> I'm afraid I don't understand. Doesn't my netcdf file already have
that
> information in it? That's what the
>
> DataType = "LatLonGrid"
> Latitude = 55.f ;
> Longitude = -110.f ;
> LatGridSpacing = 0.01f ; and
> LonGridSpacing = 0.01f ;
>
> items mean in my ncdump output, right?
>
> Jeff
>
> On Fri, Feb 11, 2011 at 3:22 PM, RAL HelpDesk {for John Halley
Gotway} <
> met_help at ucar.edu> wrote:
>
>> Jeff,
>>
>> No, you do not need to run it through copygb. In fact, copygb only
handles
>> GRIB files. It does not read NetCDF files. What you'll need to do
is write
>> a script to massage your data files to add all
>> the variables/dimensions/attributes it's looking for. Just look at
the
>> example info I sent, and modify one of your NetCDF files to make it
so that
>> MET can read it.
>>
>> John
>>
>> On 02/11/2011 02:02 PM, RAL HelpDesk {for jdduda at iastate.edu}
wrote:
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=44337 >
>>>
>>> netcdf \20100730-110000 {
>>> dimensions:
>>> Lat = 1501 ;
>>> Lon = 2001 ;
>>> variables:
>>> short cref(Lat, Lon) ;
>>> cref:Units = "dBZ" ;
>>> cref:TypeName = "cref" ;
>>> cref:MissingData = -999.f ;
>>> cref:Scale = 10.f ;
>>> cref:attributes = ;
>>> short hgt_cref(Lat, Lon) ;
>>> hgt_cref:Units = "kmMSL" ;
>>> hgt_cref:TypeName = "hgt_cref" ;
>>> hgt_cref:MissingData = -1.f ;
>>> hgt_cref:Scale = 1000.f ;
>>> hgt_cref:attributes = ;
>>> short etp18(Lat, Lon) ;
>>> etp18:Units = "kmMSL" ;
>>> etp18:TypeName = "etp18" ;
>>> etp18:MissingData = -1.f ;
>>> etp18:Scale = 1000.f ;
>>> etp18:attributes = ;
>>> short shi(Lat, Lon) ;
>>> shi:Units = " " ;
>>> shi:TypeName = "shi" ;
>>> shi:MissingData = -999.f ;
>>> shi:Scale = 10.f ;
>>> shi:attributes = ;
>>> short posh(Lat, Lon) ;
>>> posh:Units = "% " ;
>>> posh:TypeName = "posh" ;
>>> posh:MissingData = -999.f ;
>>> posh:Scale = 10.f ;
>>> posh:attributes = ;
>>> short mehs(Lat, Lon) ;
>>> mehs:Units = "mm" ;
>>> mehs:TypeName = "mehs" ;
>>> mehs:MissingData = -999.f ;
>>> mehs:Scale = 10.f ;
>>> mehs:attributes = ;
>>> short hsr(Lat, Lon) ;
>>> hsr:Units = "dBZ" ;
>>> hsr:TypeName = "hsr" ;
>>> hsr:MissingData = -999.f ;
>>> hsr:Scale = 10.f ;
>>> hsr:attributes = ;
>>> short hsrh(Lat, Lon) ;
>>> hsrh:Units = "kmAGL" ;
>>> hsrh:TypeName = "hsrh" ;
>>> hsrh:MissingData = -1.f ;
>>> hsrh:Scale = 1000.f ;
>>> hsrh:attributes = ;
>>> short lcref(Lat, Lon) ;
>>> lcref:Units = "dBZ" ;
>>> lcref:TypeName = "lcref" ;
>>> lcref:MissingData = -999.f ;
>>> lcref:Scale = 10.f ;
>>> lcref:attributes = ;
>>> short hgt_lcref(Lat, Lon) ;
>>> hgt_lcref:Units = "kmMSL" ;
>>> hgt_lcref:TypeName = "hgt_lcref" ;
>>> hgt_lcref:MissingData = -1.f ;
>>> hgt_lcref:Scale = 1000.f ;
>>> hgt_lcref:attributes = ;
>>> short vil(Lat, Lon) ;
>>> vil:Units = "kg/m2" ;
>>> vil:TypeName = "vil" ;
>>> vil:MissingData = -999.f ;
>>> vil:Scale = 10.f ;
>>> vil:attributes = ;
>>> short vilD(Lat, Lon) ;
>>> vilD:Units = "g/m3" ;
>>> vilD:TypeName = "vilD" ;
>>> vilD:MissingData = -999.f ;
>>> vilD:Scale = 10.f ;
>>> vilD:attributes = ;
>>> short pcp_flag(Lat, Lon) ;
>>> pcp_flag:Units = "flag" ;
>>> pcp_flag:TypeName = "pcp_flag" ;
>>> pcp_flag:MissingData = -999.f ;
>>> pcp_flag:attributes = ;
>>> short pcp_type(Lat, Lon) ;
>>> pcp_type:Units = "flag" ;
>>> pcp_type:TypeName = "pcp_type" ;
>>> pcp_type:MissingData = -999.f ;
>>> pcp_type:attributes = ;
>>>
>>> // global attributes:
>>> :DataType = "LatLonGrid" ;
>>> :Time = 1280487600 ;
>>> :FractionalTime = 0.f ;
>>> :RangeFolded = -99901.f ;
>>> :Latitude = 55.f ;
>>> :Longitude = -110.f ;
>>> :Height = 0.f ;
>>> :LatGridSpacing = 0.01f ;
>>> :LonGridSpacing = 0.01f ;
>>> }
>>>
>>>
>>>
>>>
>>> John,
>>> I've attached the ncdump output from my files (which are already
in
>> netCDF
>>> format). The only reason I know the grid spacing is from the
>> documentation
>>> on this data, not from the ncdump. I suppose I still need to run
it
>> through
>>> copygb in order to get it into a "nicer" format though, right?
>>>
>>> Jeff
>>>
>>> On Fri, Feb 11, 2011 at 2:57 PM, RAL HelpDesk {for John Halley
Gotway} <
>>> met_help at ucar.edu> wrote:
>>>
>>>> Jeff,
>>>>
>>>> That's fine actually. That's a lat/lon projection, or more
correctly
>> Plate
>>>> Carree. That's one of the projection types that MET can read.
Now the
>>>> issue comes down getting it into a data format that
>>>> MET can read. As I mentioned, using NetCDF would probably be
easiest.
>> I
>>>> took a GRIB file that's defined over CONUS and regridded it to a
Lat/Lon
>>>> grid over the Great Lakes. Then I ran it through
>>>> PCP-Combine to get a NetCDF version of that file. Here are the
commands
>> I
>>>> used:
>>>>
>>>> cp METv3.0/data/sample_fcst/2005080700/wrfprs_ruc13_18.tm00_G212
>>>> lambert_conf.grib
>>>> copygb -xg"255 0 327 235 40908 -92200 128 49100 -75900 50 35 64"
>>>> lambert_conf.grib lat_lon.grib
>>>> METv3.0/bin/pcp_combine -add lat_lon.grib 03 lat_lon.nc
>>>>
>>>> I've attached the resulting NetCDF file. If you do "ncdump -h"
on it,
>>>> you'll see the header. Here's the relevant info for you...
>>>>
>>>> In the global attributes, the following things must be defined.
These
>>>> specify the grid on which your data is defined. You'll need to
fill in
>> the
>>>> values that define your grid:
>>>> :MET_version = "V3.0" ;
>>>> :Projection = "LatLon" ;
>>>> :lat_ll = "40.908000 degrees_north" ;
>>>> :lon_ll = "-92.200000 degrees_east" ;
>>>> :delta_lat = "0.035000 degrees" ;
>>>> :delta_lon = "0.050000 degrees" ;
>>>> :Nlat = "235 grid_points" ;
>>>> :Nlon = "327 grid_points" ;
>>>>
>>>> In the dimensions section, you need to define dimensions named
"lat" and
>>>> "lon":
>>>> lat = 235 ;
>>>> lon = 327 ;
>>>>
>>>> In the variables section, you can name the variable whatever
you'd like,
>>>> but it should be indexed by the lat and lon dimensions. Note,
you do
>> NOT
>>>> need to define the lat(lat,lon) and lon(lat,lon)
>>>> variables since MET doesn't actually use them:
>>>> float APCP_03(lat, lon) ;
>>>> APCP_03:level = "A3" ;
>>>> APCP_03:units = "kg/m^2" ;
>>>> APCP_03:_FillValue = -9999.f ;
>>>> APCP_03:init_time_ut = 1123372800 ;
>>>> APCP_03:valid_time_ut = 1123437600 ;
>>>> APCP_03:accum_time_sec = 10800 ;
>>>>
>>>> As for the variable attributes listed above, I've only retained
the ones
>>>> that MET actually reads. The rest you see in your ncdump output
can be
>>>> omitted if you'd like.
>>>>
>>>> Just let me know if you get stuck.
>>>>
>>>> John
>>>>
>>>>
>>>> On 02/11/2011 01:25 PM, RAL HelpDesk {for jdduda at iastate.edu}
wrote:
>>>>>
>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=44337 >
>>>>>
>>>>> I should specify: the grid resolution is 0.01 deg lat by 0.01
deg lon.
>>>> So
>>>>> it is regularly spaced in some sense, but not in terms of
Euclidean
>>>>> distance. Does that make a difference?
>>>>>
>>>>> Jeff
>>>>>
>>>>> On Fri, Feb 11, 2011 at 2:20 PM, RAL HelpDesk {for John Halley
Gotway}
>> <
>>>>> met_help at ucar.edu> wrote:
>>>>>
>>>>>> Jeff,
>>>>>>
>>>>>> MODE can only handle data that's on a regularly spaced grid.
For GRIB
>>>>>> files, it reads the grid definition from the grid description
section
>>>> (GDS)
>>>>>> or each GRIB record. For NetCDF files, like the
>>>>>> output of the PCP-Combine tool, it reads the grid definition
from a
>>>> special
>>>>>> set of global attributes. If you have a gridded dataset and
would
>> like
>>>> to
>>>>>> use it in MODE, it'd need to be regularly spaced,
>>>>>> and it'd probably be easiest to write it as a NetCDF file
making it
>> look
>>>>>> like the output of the PCP-Combine tool.
>>>>>>
>>>>>> Hope that helps.
>>>>>>
>>>>>> John
>>>>>>
>>>>>> On 02/11/2011 12:56 PM, RAL HelpDesk {for jdduda at iastate.edu}
wrote:
>>>>>>> I wish to run MODE using a data set that did not come from a
model
>> (it
>>>>>> came
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> John,
>>> I've attached the ncdump output from my files (which are already
in
>> netCDF
>>> format). The only reason I know the grid spacing is from the
>> documentation on
>>> this data, not from the ncdump. I suppose I still need to run it
through
>> copygb
>>> in order to get it into a "nicer" format though, right?
>>>
>>> Jeff
>>>
>>> On Fri, Feb 11, 2011 at 2:57 PM, RAL HelpDesk {for John Halley
Gotway}
>>> <met_help at ucar.edu <mailto:met_help at ucar.edu>> wrote:
>>>
>>> Jeff,
>>>
>>> That's fine actually. That's a lat/lon projection, or more
correctly
>> Plate
>>> Carree. That's one of the projection types that MET can read.
Now
>> the
>>> issue comes down getting it into a data format that
>>> MET can read. As I mentioned, using NetCDF would probably be
>> easiest. I
>>> took a GRIB file that's defined over CONUS and regridded it to
a
>> Lat/Lon
>>> grid over the Great Lakes. Then I ran it through
>>> PCP-Combine to get a NetCDF version of that file. Here are
the
>> commands I used:
>>>
>>> cp
METv3.0/data/sample_fcst/2005080700/wrfprs_ruc13_18.tm00_G212
>>> lambert_conf.grib
>>> copygb -xg"255 0 327 235 40908 -92200 128 49100 -75900 50 35
64"
>>> lambert_conf.grib lat_lon.grib
>>> METv3.0/bin/pcp_combine -add lat_lon.grib 03 lat_lon.nc <
>> http://lat_lon.nc>
>>>
>>> I've attached the resulting NetCDF file. If you do "ncdump
-h" on
>> it,
>>> you'll see the header. Here's the relevant info for you...
>>>
>>> In the global attributes, the following things must be
defined.
>> These
>>> specify the grid on which your data is defined. You'll need
to fill
>> in the
>>> values that define your grid:
>>> :MET_version = "V3.0" ;
>>> :Projection = "LatLon" ;
>>> :lat_ll = "40.908000 degrees_north" ;
>>> :lon_ll = "-92.200000 degrees_east" ;
>>> :delta_lat = "0.035000 degrees" ;
>>> :delta_lon = "0.050000 degrees" ;
>>> :Nlat = "235 grid_points" ;
>>> :Nlon = "327 grid_points" ;
>>>
>>> In the dimensions section, you need to define dimensions named
"lat"
>> and "lon":
>>> lat = 235 ;
>>> lon = 327 ;
>>>
>>> In the variables section, you can name the variable whatever
you'd
>> like, but
>>> it should be indexed by the lat and lon dimensions. Note, you
do NOT
>> need
>>> to define the lat(lat,lon) and lon(lat,lon)
>>> variables since MET doesn't actually use them:
>>> float APCP_03(lat, lon) ;
>>> APCP_03:level = "A3" ;
>>> APCP_03:units = "kg/m^2" ;
>>> APCP_03:_FillValue = -9999.f ;
>>> APCP_03:init_time_ut = 1123372800 ;
>>> APCP_03:valid_time_ut = 1123437600 ;
>>> APCP_03:accum_time_sec = 10800 ;
>>>
>>> As for the variable attributes listed above, I've only
retained the
>> ones
>>> that MET actually reads. The rest you see in your ncdump
output can
>> be
>>> omitted if you'd like.
>>>
>>> Just let me know if you get stuck.
>>>
>>> John
>>>
>>>
>>> On 02/11/2011 01:25 PM, RAL HelpDesk {for jdduda at iastate.edu
>>> <mailto:jdduda at iastate.edu>} wrote:
>>> >
>>> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=44337 >
>>> >
>>> > I should specify: the grid resolution is 0.01 deg lat by
0.01 deg
>> lon. So
>>> > it is regularly spaced in some sense, but not in terms of
>> Euclidean
>>> > distance. Does that make a difference?
>>> >
>>> > Jeff
>>> >
>>> > On Fri, Feb 11, 2011 at 2:20 PM, RAL HelpDesk {for John
Halley
>> Gotway} <
>>> > met_help at ucar.edu <mailto:met_help at ucar.edu>> wrote:
>>> >
>>> >> Jeff,
>>> >>
>>> >> MODE can only handle data that's on a regularly spaced
grid. For
>> GRIB
>>> >> files, it reads the grid definition from the grid
description
>> section (GDS)
>>> >> or each GRIB record. For NetCDF files, like the
>>> >> output of the PCP-Combine tool, it reads the grid
definition from
>> a special
>>> >> set of global attributes. If you have a gridded dataset
and
>> would like to
>>> >> use it in MODE, it'd need to be regularly spaced,
>>> >> and it'd probably be easiest to write it as a NetCDF file
making
>> it look
>>> >> like the output of the PCP-Combine tool.
>>> >>
>>> >> Hope that helps.
>>> >>
>>> >> John
>>> >>
>>> >> On 02/11/2011 12:56 PM, RAL HelpDesk {for
jdduda at iastate.edu
>>> <mailto:jdduda at iastate.edu>} wrote:
>>> >>> I wish to run MODE using a data set that did not come
from a
>> model (it
>>> >> came
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>>
>>>
>>> --
>>> Jeff Duda
>>> Iowa State University
>>> Meteorology Graduate Student
>>> 3134 Agronomy Hall
>>> www.meteor.iastate.edu/~jdduda
<http://www.meteor.iastate.edu/%7Ejdduda><
>> http://www.meteor.iastate.edu/~jdduda>
>>
>>
>
>
------------------------------------------------
Subject: MODE
From: jdduda at iastate.edu
Time: Fri Feb 11 17:01:26 2011
Thanks, John. One more thing: the data is flipped in the meridional
direction so that when I try to view the file in ncview, the data is
upside-down. That is to say, the lower left corner of the data is not
55 N
lat, -110 W lon. Rather, it is 40 N lat, -110 W lon. Can I take care
of
that here or does this result in more serious issues?
Jeff
On Fri, Feb 11, 2011 at 3:53 PM, RAL HelpDesk {for John Halley Gotway}
<
met_help at ucar.edu> wrote:
> Jeff,
>
> Here are the discrepancies I see. Listed on the left is what you
have and
> listed on the right it what MET is looking to read.
>
> Global Attributes:
> missing <---> MET_version = "V3.0"
> DataType = "LatLonGrid" <---> Projection = "LatLon"
> Latitude = 55.f ; <---> lat_ll = "55.0" (note, this is
actually a
> string)
> Longitude = -110.f ; <---> lon_ll = "-100.0" (again, a string)
> LatGridSpacing = 0.01f ; <---> delta_lat = "0.01" (string)
> LonGridSpacing = 0.01f ; <---> delta_lon = "0.01" (string)
> missing <---> Nlat = "1501"
> missing <---> Nlon = "2001"
>
> Dimensions:
> Lat = 1501 <---> lat=1501
> Lon = 2001 <---> lon=2001
>
> Variable attributes:
> missing <---> level = "SFC"
> Units = "dBZ" ; <---> units = "dBZ"
> MissingData = -999.f ; <---> _FillValue = -9999.f
> missing <---> init_time_ut = 1123372800 (in
unixtime)
> missing <---> valid_time_ut = 1123437600 (in
unixtime)
> missing <---> accum_time_sec = 0 (in seconds)
>
> Unfortunately, in order for MET to read/understand your file, all of
these
> things must be named exactly as specified - even down to
capitalization.
> Otherwise, you'll get a NetCDF error when MET tries
> to read them. We're planning to enhance our support for NetCDF in
future
> versions of MET to parse CF-compliant NetCDF files, but we're not
there yet.
> As of now, if you want to read custom data into
> MET, it must be formatted in a very specific way.
>
> Thanks,
> John
>
>
> On 02/11/2011 02:42 PM, RAL HelpDesk {for jdduda at iastate.edu} wrote:
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=44337 >
> >
> > I'm afraid I don't understand. Doesn't my netcdf file already
have that
> > information in it? That's what the
> >
> > DataType = "LatLonGrid"
> > Latitude = 55.f ;
> > Longitude = -110.f ;
> > LatGridSpacing = 0.01f ; and
> > LonGridSpacing = 0.01f ;
> >
> > items mean in my ncdump output, right?
> >
> > Jeff
> >
> > On Fri, Feb 11, 2011 at 3:22 PM, RAL HelpDesk {for John Halley
Gotway} <
> > met_help at ucar.edu> wrote:
> >
> >> Jeff,
> >>
> >> No, you do not need to run it through copygb. In fact, copygb
only
> handles
> >> GRIB files. It does not read NetCDF files. What you'll need to
do is
> write
> >> a script to massage your data files to add all
> >> the variables/dimensions/attributes it's looking for. Just look
at the
> >> example info I sent, and modify one of your NetCDF files to make
it so
> that
> >> MET can read it.
> >>
> >> John
> >>
> >> On 02/11/2011 02:02 PM, RAL HelpDesk {for jdduda at iastate.edu}
wrote:
> >>>
> >>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=44337 >
> >>>
> >>> netcdf \20100730-110000 {
> >>> dimensions:
> >>> Lat = 1501 ;
> >>> Lon = 2001 ;
> >>> variables:
> >>> short cref(Lat, Lon) ;
> >>> cref:Units = "dBZ" ;
> >>> cref:TypeName = "cref" ;
> >>> cref:MissingData = -999.f ;
> >>> cref:Scale = 10.f ;
> >>> cref:attributes = ;
> >>> short hgt_cref(Lat, Lon) ;
> >>> hgt_cref:Units = "kmMSL" ;
> >>> hgt_cref:TypeName = "hgt_cref" ;
> >>> hgt_cref:MissingData = -1.f ;
> >>> hgt_cref:Scale = 1000.f ;
> >>> hgt_cref:attributes = ;
> >>> short etp18(Lat, Lon) ;
> >>> etp18:Units = "kmMSL" ;
> >>> etp18:TypeName = "etp18" ;
> >>> etp18:MissingData = -1.f ;
> >>> etp18:Scale = 1000.f ;
> >>> etp18:attributes = ;
> >>> short shi(Lat, Lon) ;
> >>> shi:Units = " " ;
> >>> shi:TypeName = "shi" ;
> >>> shi:MissingData = -999.f ;
> >>> shi:Scale = 10.f ;
> >>> shi:attributes = ;
> >>> short posh(Lat, Lon) ;
> >>> posh:Units = "% " ;
> >>> posh:TypeName = "posh" ;
> >>> posh:MissingData = -999.f ;
> >>> posh:Scale = 10.f ;
> >>> posh:attributes = ;
> >>> short mehs(Lat, Lon) ;
> >>> mehs:Units = "mm" ;
> >>> mehs:TypeName = "mehs" ;
> >>> mehs:MissingData = -999.f ;
> >>> mehs:Scale = 10.f ;
> >>> mehs:attributes = ;
> >>> short hsr(Lat, Lon) ;
> >>> hsr:Units = "dBZ" ;
> >>> hsr:TypeName = "hsr" ;
> >>> hsr:MissingData = -999.f ;
> >>> hsr:Scale = 10.f ;
> >>> hsr:attributes = ;
> >>> short hsrh(Lat, Lon) ;
> >>> hsrh:Units = "kmAGL" ;
> >>> hsrh:TypeName = "hsrh" ;
> >>> hsrh:MissingData = -1.f ;
> >>> hsrh:Scale = 1000.f ;
> >>> hsrh:attributes = ;
> >>> short lcref(Lat, Lon) ;
> >>> lcref:Units = "dBZ" ;
> >>> lcref:TypeName = "lcref" ;
> >>> lcref:MissingData = -999.f ;
> >>> lcref:Scale = 10.f ;
> >>> lcref:attributes = ;
> >>> short hgt_lcref(Lat, Lon) ;
> >>> hgt_lcref:Units = "kmMSL" ;
> >>> hgt_lcref:TypeName = "hgt_lcref" ;
> >>> hgt_lcref:MissingData = -1.f ;
> >>> hgt_lcref:Scale = 1000.f ;
> >>> hgt_lcref:attributes = ;
> >>> short vil(Lat, Lon) ;
> >>> vil:Units = "kg/m2" ;
> >>> vil:TypeName = "vil" ;
> >>> vil:MissingData = -999.f ;
> >>> vil:Scale = 10.f ;
> >>> vil:attributes = ;
> >>> short vilD(Lat, Lon) ;
> >>> vilD:Units = "g/m3" ;
> >>> vilD:TypeName = "vilD" ;
> >>> vilD:MissingData = -999.f ;
> >>> vilD:Scale = 10.f ;
> >>> vilD:attributes = ;
> >>> short pcp_flag(Lat, Lon) ;
> >>> pcp_flag:Units = "flag" ;
> >>> pcp_flag:TypeName = "pcp_flag" ;
> >>> pcp_flag:MissingData = -999.f ;
> >>> pcp_flag:attributes = ;
> >>> short pcp_type(Lat, Lon) ;
> >>> pcp_type:Units = "flag" ;
> >>> pcp_type:TypeName = "pcp_type" ;
> >>> pcp_type:MissingData = -999.f ;
> >>> pcp_type:attributes = ;
> >>>
> >>> // global attributes:
> >>> :DataType = "LatLonGrid" ;
> >>> :Time = 1280487600 ;
> >>> :FractionalTime = 0.f ;
> >>> :RangeFolded = -99901.f ;
> >>> :Latitude = 55.f ;
> >>> :Longitude = -110.f ;
> >>> :Height = 0.f ;
> >>> :LatGridSpacing = 0.01f ;
> >>> :LonGridSpacing = 0.01f ;
> >>> }
> >>>
> >>>
> >>>
> >>>
> >>> John,
> >>> I've attached the ncdump output from my files (which are already
in
> >> netCDF
> >>> format). The only reason I know the grid spacing is from the
> >> documentation
> >>> on this data, not from the ncdump. I suppose I still need to
run it
> >> through
> >>> copygb in order to get it into a "nicer" format though, right?
> >>>
> >>> Jeff
> >>>
> >>> On Fri, Feb 11, 2011 at 2:57 PM, RAL HelpDesk {for John Halley
Gotway}
> <
> >>> met_help at ucar.edu> wrote:
> >>>
> >>>> Jeff,
> >>>>
> >>>> That's fine actually. That's a lat/lon projection, or more
correctly
> >> Plate
> >>>> Carree. That's one of the projection types that MET can read.
Now
> the
> >>>> issue comes down getting it into a data format that
> >>>> MET can read. As I mentioned, using NetCDF would probably be
easiest.
> >> I
> >>>> took a GRIB file that's defined over CONUS and regridded it to
a
> Lat/Lon
> >>>> grid over the Great Lakes. Then I ran it through
> >>>> PCP-Combine to get a NetCDF version of that file. Here are the
> commands
> >> I
> >>>> used:
> >>>>
> >>>> cp
METv3.0/data/sample_fcst/2005080700/wrfprs_ruc13_18.tm00_G212
> >>>> lambert_conf.grib
> >>>> copygb -xg"255 0 327 235 40908 -92200 128 49100 -75900 50 35
64"
> >>>> lambert_conf.grib lat_lon.grib
> >>>> METv3.0/bin/pcp_combine -add lat_lon.grib 03 lat_lon.nc
> >>>>
> >>>> I've attached the resulting NetCDF file. If you do "ncdump -h"
on it,
> >>>> you'll see the header. Here's the relevant info for you...
> >>>>
> >>>> In the global attributes, the following things must be defined.
These
> >>>> specify the grid on which your data is defined. You'll need to
fill
> in
> >> the
> >>>> values that define your grid:
> >>>> :MET_version = "V3.0" ;
> >>>> :Projection = "LatLon" ;
> >>>> :lat_ll = "40.908000 degrees_north" ;
> >>>> :lon_ll = "-92.200000 degrees_east" ;
> >>>> :delta_lat = "0.035000 degrees" ;
> >>>> :delta_lon = "0.050000 degrees" ;
> >>>> :Nlat = "235 grid_points" ;
> >>>> :Nlon = "327 grid_points" ;
> >>>>
> >>>> In the dimensions section, you need to define dimensions named
"lat"
> and
> >>>> "lon":
> >>>> lat = 235 ;
> >>>> lon = 327 ;
> >>>>
> >>>> In the variables section, you can name the variable whatever
you'd
> like,
> >>>> but it should be indexed by the lat and lon dimensions. Note,
you do
> >> NOT
> >>>> need to define the lat(lat,lon) and lon(lat,lon)
> >>>> variables since MET doesn't actually use them:
> >>>> float APCP_03(lat, lon) ;
> >>>> APCP_03:level = "A3" ;
> >>>> APCP_03:units = "kg/m^2" ;
> >>>> APCP_03:_FillValue = -9999.f ;
> >>>> APCP_03:init_time_ut = 1123372800 ;
> >>>> APCP_03:valid_time_ut = 1123437600 ;
> >>>> APCP_03:accum_time_sec = 10800 ;
> >>>>
> >>>> As for the variable attributes listed above, I've only retained
the
> ones
> >>>> that MET actually reads. The rest you see in your ncdump
output can
> be
> >>>> omitted if you'd like.
> >>>>
> >>>> Just let me know if you get stuck.
> >>>>
> >>>> John
> >>>>
> >>>>
> >>>> On 02/11/2011 01:25 PM, RAL HelpDesk {for jdduda at iastate.edu}
wrote:
> >>>>>
> >>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=44337
>
> >>>>>
> >>>>> I should specify: the grid resolution is 0.01 deg lat by 0.01
deg
> lon.
> >>>> So
> >>>>> it is regularly spaced in some sense, but not in terms of
Euclidean
> >>>>> distance. Does that make a difference?
> >>>>>
> >>>>> Jeff
> >>>>>
> >>>>> On Fri, Feb 11, 2011 at 2:20 PM, RAL HelpDesk {for John Halley
> Gotway}
> >> <
> >>>>> met_help at ucar.edu> wrote:
> >>>>>
> >>>>>> Jeff,
> >>>>>>
> >>>>>> MODE can only handle data that's on a regularly spaced grid.
For
> GRIB
> >>>>>> files, it reads the grid definition from the grid description
> section
> >>>> (GDS)
> >>>>>> or each GRIB record. For NetCDF files, like the
> >>>>>> output of the PCP-Combine tool, it reads the grid definition
from a
> >>>> special
> >>>>>> set of global attributes. If you have a gridded dataset and
would
> >> like
> >>>> to
> >>>>>> use it in MODE, it'd need to be regularly spaced,
> >>>>>> and it'd probably be easiest to write it as a NetCDF file
making it
> >> look
> >>>>>> like the output of the PCP-Combine tool.
> >>>>>>
> >>>>>> Hope that helps.
> >>>>>>
> >>>>>> John
> >>>>>>
> >>>>>> On 02/11/2011 12:56 PM, RAL HelpDesk {for jdduda at iastate.edu}
> wrote:
> >>>>>>> I wish to run MODE using a data set that did not come from a
model
> >> (it
> >>>>>> came
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>> John,
> >>> I've attached the ncdump output from my files (which are already
in
> >> netCDF
> >>> format). The only reason I know the grid spacing is from the
> >> documentation on
> >>> this data, not from the ncdump. I suppose I still need to run
it
> through
> >> copygb
> >>> in order to get it into a "nicer" format though, right?
> >>>
> >>> Jeff
> >>>
> >>> On Fri, Feb 11, 2011 at 2:57 PM, RAL HelpDesk {for John Halley
Gotway}
> >>> <met_help at ucar.edu <mailto:met_help at ucar.edu>> wrote:
> >>>
> >>> Jeff,
> >>>
> >>> That's fine actually. That's a lat/lon projection, or more
> correctly
> >> Plate
> >>> Carree. That's one of the projection types that MET can
read. Now
> >> the
> >>> issue comes down getting it into a data format that
> >>> MET can read. As I mentioned, using NetCDF would probably
be
> >> easiest. I
> >>> took a GRIB file that's defined over CONUS and regridded it
to a
> >> Lat/Lon
> >>> grid over the Great Lakes. Then I ran it through
> >>> PCP-Combine to get a NetCDF version of that file. Here are
the
> >> commands I used:
> >>>
> >>> cp
METv3.0/data/sample_fcst/2005080700/wrfprs_ruc13_18.tm00_G212
> >>> lambert_conf.grib
> >>> copygb -xg"255 0 327 235 40908 -92200 128 49100 -75900 50 35
64"
> >>> lambert_conf.grib lat_lon.grib
> >>> METv3.0/bin/pcp_combine -add lat_lon.grib 03 lat_lon.nc <
> >> http://lat_lon.nc>
> >>>
> >>> I've attached the resulting NetCDF file. If you do "ncdump
-h" on
> >> it,
> >>> you'll see the header. Here's the relevant info for you...
> >>>
> >>> In the global attributes, the following things must be
defined.
> >> These
> >>> specify the grid on which your data is defined. You'll need
to
> fill
> >> in the
> >>> values that define your grid:
> >>> :MET_version = "V3.0" ;
> >>> :Projection = "LatLon" ;
> >>> :lat_ll = "40.908000 degrees_north" ;
> >>> :lon_ll = "-92.200000 degrees_east" ;
> >>> :delta_lat = "0.035000 degrees" ;
> >>> :delta_lon = "0.050000 degrees" ;
> >>> :Nlat = "235 grid_points" ;
> >>> :Nlon = "327 grid_points" ;
> >>>
> >>> In the dimensions section, you need to define dimensions
named
> "lat"
> >> and "lon":
> >>> lat = 235 ;
> >>> lon = 327 ;
> >>>
> >>> In the variables section, you can name the variable whatever
you'd
> >> like, but
> >>> it should be indexed by the lat and lon dimensions. Note,
you do
> NOT
> >> need
> >>> to define the lat(lat,lon) and lon(lat,lon)
> >>> variables since MET doesn't actually use them:
> >>> float APCP_03(lat, lon) ;
> >>> APCP_03:level = "A3" ;
> >>> APCP_03:units = "kg/m^2" ;
> >>> APCP_03:_FillValue = -9999.f ;
> >>> APCP_03:init_time_ut = 1123372800 ;
> >>> APCP_03:valid_time_ut = 1123437600 ;
> >>> APCP_03:accum_time_sec = 10800 ;
> >>>
> >>> As for the variable attributes listed above, I've only
retained the
> >> ones
> >>> that MET actually reads. The rest you see in your ncdump
output
> can
> >> be
> >>> omitted if you'd like.
> >>>
> >>> Just let me know if you get stuck.
> >>>
> >>> John
> >>>
> >>>
> >>> On 02/11/2011 01:25 PM, RAL HelpDesk {for jdduda at iastate.edu
> >>> <mailto:jdduda at iastate.edu>} wrote:
> >>> >
> >>> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=44337 >
> >>> >
> >>> > I should specify: the grid resolution is 0.01 deg lat by
0.01
> deg
> >> lon. So
> >>> > it is regularly spaced in some sense, but not in terms of
> >> Euclidean
> >>> > distance. Does that make a difference?
> >>> >
> >>> > Jeff
> >>> >
> >>> > On Fri, Feb 11, 2011 at 2:20 PM, RAL HelpDesk {for John
Halley
> >> Gotway} <
> >>> > met_help at ucar.edu <mailto:met_help at ucar.edu>> wrote:
> >>> >
> >>> >> Jeff,
> >>> >>
> >>> >> MODE can only handle data that's on a regularly spaced
grid.
> For
> >> GRIB
> >>> >> files, it reads the grid definition from the grid
description
> >> section (GDS)
> >>> >> or each GRIB record. For NetCDF files, like the
> >>> >> output of the PCP-Combine tool, it reads the grid
definition
> from
> >> a special
> >>> >> set of global attributes. If you have a gridded dataset
and
> >> would like to
> >>> >> use it in MODE, it'd need to be regularly spaced,
> >>> >> and it'd probably be easiest to write it as a NetCDF
file
> making
> >> it look
> >>> >> like the output of the PCP-Combine tool.
> >>> >>
> >>> >> Hope that helps.
> >>> >>
> >>> >> John
> >>> >>
> >>> >> On 02/11/2011 12:56 PM, RAL HelpDesk {for
jdduda at iastate.edu
> >>> <mailto:jdduda at iastate.edu>} wrote:
> >>> >>> I wish to run MODE using a data set that did not come
from a
> >> model (it
> >>> >> came
> >>> >>
> >>> >>
> >>> >
> >>> >
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Jeff Duda
> >>> Iowa State University
> >>> Meteorology Graduate Student
> >>> 3134 Agronomy Hall
> >>>
www.meteor.iastate.edu/~jdduda<http://www.meteor.iastate.edu/%7Ejdduda><
> http://www.meteor.iastate.edu/%7Ejdduda><
> >> http://www.meteor.iastate.edu/~jdduda>
> >>
> >>
> >
> >
>
>
--
Jeff Duda
Iowa State University
Meteorology Graduate Student
3134 Agronomy Hall
www.meteor.iastate.edu/~jdduda
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #44337] MODE
From: John Halley Gotway
Time: Fri Feb 11 18:36:46 2011
Jeff,
First, I'd suggest running the data through MODE and looking at the
resulting plot. That'll tell you how MET is reading the data from
that
file. I'm guessing it'll be the same result as from ncview, but it'd
be
good just to make sure.
If the data really is flipped, that's a more serious issue that you'll
need to address in the creation of the data file itself. If you have
control over the creation of this file, I'd suggest correcting it. If
not, you could write some sort of script to correct the problem.
But unfortunately, there aren't any easy tricks in the modification of
the
NetCDF file that'll correct this.
John
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=44337 >
>
> Thanks, John. One more thing: the data is flipped in the meridional
> direction so that when I try to view the file in ncview, the data is
> upside-down. That is to say, the lower left corner of the data is
not 55
> N
> lat, -110 W lon. Rather, it is 40 N lat, -110 W lon. Can I take
care of
> that here or does this result in more serious issues?
>
> Jeff
>
> On Fri, Feb 11, 2011 at 3:53 PM, RAL HelpDesk {for John Halley
Gotway} <
> met_help at ucar.edu> wrote:
>
>> Jeff,
>>
>> Here are the discrepancies I see. Listed on the left is what you
have
>> and
>> listed on the right it what MET is looking to read.
>>
>> Global Attributes:
>> missing <---> MET_version = "V3.0"
>> DataType = "LatLonGrid" <---> Projection = "LatLon"
>> Latitude = 55.f ; <---> lat_ll = "55.0" (note, this is
actually a
>> string)
>> Longitude = -110.f ; <---> lon_ll = "-100.0" (again, a string)
>> LatGridSpacing = 0.01f ; <---> delta_lat = "0.01" (string)
>> LonGridSpacing = 0.01f ; <---> delta_lon = "0.01" (string)
>> missing <---> Nlat = "1501"
>> missing <---> Nlon = "2001"
>>
>> Dimensions:
>> Lat = 1501 <---> lat=1501
>> Lon = 2001 <---> lon=2001
>>
>> Variable attributes:
>> missing <---> level = "SFC"
>> Units = "dBZ" ; <---> units = "dBZ"
>> MissingData = -999.f ; <---> _FillValue = -9999.f
>> missing <---> init_time_ut = 1123372800 (in
unixtime)
>> missing <---> valid_time_ut = 1123437600 (in
unixtime)
>> missing <---> accum_time_sec = 0 (in seconds)
>>
>> Unfortunately, in order for MET to read/understand your file, all
of
>> these
>> things must be named exactly as specified - even down to
capitalization.
>> Otherwise, you'll get a NetCDF error when MET tries
>> to read them. We're planning to enhance our support for NetCDF in
>> future
>> versions of MET to parse CF-compliant NetCDF files, but we're not
there
>> yet.
>> As of now, if you want to read custom data into
>> MET, it must be formatted in a very specific way.
>>
>> Thanks,
>> John
>>
>>
>> On 02/11/2011 02:42 PM, RAL HelpDesk {for jdduda at iastate.edu}
wrote:
>> >
>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=44337 >
>> >
>> > I'm afraid I don't understand. Doesn't my netcdf file already
have
>> that
>> > information in it? That's what the
>> >
>> > DataType = "LatLonGrid"
>> > Latitude = 55.f ;
>> > Longitude = -110.f ;
>> > LatGridSpacing = 0.01f ; and
>> > LonGridSpacing = 0.01f ;
>> >
>> > items mean in my ncdump output, right?
>> >
>> > Jeff
>> >
>> > On Fri, Feb 11, 2011 at 3:22 PM, RAL HelpDesk {for John Halley
Gotway}
>> <
>> > met_help at ucar.edu> wrote:
>> >
>> >> Jeff,
>> >>
>> >> No, you do not need to run it through copygb. In fact, copygb
only
>> handles
>> >> GRIB files. It does not read NetCDF files. What you'll need to
do
>> is
>> write
>> >> a script to massage your data files to add all
>> >> the variables/dimensions/attributes it's looking for. Just look
at
>> the
>> >> example info I sent, and modify one of your NetCDF files to make
it
>> so
>> that
>> >> MET can read it.
>> >>
>> >> John
>> >>
>> >> On 02/11/2011 02:02 PM, RAL HelpDesk {for jdduda at iastate.edu}
wrote:
>> >>>
>> >>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=44337 >
>> >>>
>> >>> netcdf \20100730-110000 {
>> >>> dimensions:
>> >>> Lat = 1501 ;
>> >>> Lon = 2001 ;
>> >>> variables:
>> >>> short cref(Lat, Lon) ;
>> >>> cref:Units = "dBZ" ;
>> >>> cref:TypeName = "cref" ;
>> >>> cref:MissingData = -999.f ;
>> >>> cref:Scale = 10.f ;
>> >>> cref:attributes = ;
>> >>> short hgt_cref(Lat, Lon) ;
>> >>> hgt_cref:Units = "kmMSL" ;
>> >>> hgt_cref:TypeName = "hgt_cref" ;
>> >>> hgt_cref:MissingData = -1.f ;
>> >>> hgt_cref:Scale = 1000.f ;
>> >>> hgt_cref:attributes = ;
>> >>> short etp18(Lat, Lon) ;
>> >>> etp18:Units = "kmMSL" ;
>> >>> etp18:TypeName = "etp18" ;
>> >>> etp18:MissingData = -1.f ;
>> >>> etp18:Scale = 1000.f ;
>> >>> etp18:attributes = ;
>> >>> short shi(Lat, Lon) ;
>> >>> shi:Units = " " ;
>> >>> shi:TypeName = "shi" ;
>> >>> shi:MissingData = -999.f ;
>> >>> shi:Scale = 10.f ;
>> >>> shi:attributes = ;
>> >>> short posh(Lat, Lon) ;
>> >>> posh:Units = "% " ;
>> >>> posh:TypeName = "posh" ;
>> >>> posh:MissingData = -999.f ;
>> >>> posh:Scale = 10.f ;
>> >>> posh:attributes = ;
>> >>> short mehs(Lat, Lon) ;
>> >>> mehs:Units = "mm" ;
>> >>> mehs:TypeName = "mehs" ;
>> >>> mehs:MissingData = -999.f ;
>> >>> mehs:Scale = 10.f ;
>> >>> mehs:attributes = ;
>> >>> short hsr(Lat, Lon) ;
>> >>> hsr:Units = "dBZ" ;
>> >>> hsr:TypeName = "hsr" ;
>> >>> hsr:MissingData = -999.f ;
>> >>> hsr:Scale = 10.f ;
>> >>> hsr:attributes = ;
>> >>> short hsrh(Lat, Lon) ;
>> >>> hsrh:Units = "kmAGL" ;
>> >>> hsrh:TypeName = "hsrh" ;
>> >>> hsrh:MissingData = -1.f ;
>> >>> hsrh:Scale = 1000.f ;
>> >>> hsrh:attributes = ;
>> >>> short lcref(Lat, Lon) ;
>> >>> lcref:Units = "dBZ" ;
>> >>> lcref:TypeName = "lcref" ;
>> >>> lcref:MissingData = -999.f ;
>> >>> lcref:Scale = 10.f ;
>> >>> lcref:attributes = ;
>> >>> short hgt_lcref(Lat, Lon) ;
>> >>> hgt_lcref:Units = "kmMSL" ;
>> >>> hgt_lcref:TypeName = "hgt_lcref" ;
>> >>> hgt_lcref:MissingData = -1.f ;
>> >>> hgt_lcref:Scale = 1000.f ;
>> >>> hgt_lcref:attributes = ;
>> >>> short vil(Lat, Lon) ;
>> >>> vil:Units = "kg/m2" ;
>> >>> vil:TypeName = "vil" ;
>> >>> vil:MissingData = -999.f ;
>> >>> vil:Scale = 10.f ;
>> >>> vil:attributes = ;
>> >>> short vilD(Lat, Lon) ;
>> >>> vilD:Units = "g/m3" ;
>> >>> vilD:TypeName = "vilD" ;
>> >>> vilD:MissingData = -999.f ;
>> >>> vilD:Scale = 10.f ;
>> >>> vilD:attributes = ;
>> >>> short pcp_flag(Lat, Lon) ;
>> >>> pcp_flag:Units = "flag" ;
>> >>> pcp_flag:TypeName = "pcp_flag" ;
>> >>> pcp_flag:MissingData = -999.f ;
>> >>> pcp_flag:attributes = ;
>> >>> short pcp_type(Lat, Lon) ;
>> >>> pcp_type:Units = "flag" ;
>> >>> pcp_type:TypeName = "pcp_type" ;
>> >>> pcp_type:MissingData = -999.f ;
>> >>> pcp_type:attributes = ;
>> >>>
>> >>> // global attributes:
>> >>> :DataType = "LatLonGrid" ;
>> >>> :Time = 1280487600 ;
>> >>> :FractionalTime = 0.f ;
>> >>> :RangeFolded = -99901.f ;
>> >>> :Latitude = 55.f ;
>> >>> :Longitude = -110.f ;
>> >>> :Height = 0.f ;
>> >>> :LatGridSpacing = 0.01f ;
>> >>> :LonGridSpacing = 0.01f ;
>> >>> }
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> John,
>> >>> I've attached the ncdump output from my files (which are
already in
>> >> netCDF
>> >>> format). The only reason I know the grid spacing is from the
>> >> documentation
>> >>> on this data, not from the ncdump. I suppose I still need to
run it
>> >> through
>> >>> copygb in order to get it into a "nicer" format though, right?
>> >>>
>> >>> Jeff
>> >>>
>> >>> On Fri, Feb 11, 2011 at 2:57 PM, RAL HelpDesk {for John Halley
>> Gotway}
>> <
>> >>> met_help at ucar.edu> wrote:
>> >>>
>> >>>> Jeff,
>> >>>>
>> >>>> That's fine actually. That's a lat/lon projection, or more
>> correctly
>> >> Plate
>> >>>> Carree. That's one of the projection types that MET can read.
Now
>> the
>> >>>> issue comes down getting it into a data format that
>> >>>> MET can read. As I mentioned, using NetCDF would probably be
>> easiest.
>> >> I
>> >>>> took a GRIB file that's defined over CONUS and regridded it to
a
>> Lat/Lon
>> >>>> grid over the Great Lakes. Then I ran it through
>> >>>> PCP-Combine to get a NetCDF version of that file. Here are
the
>> commands
>> >> I
>> >>>> used:
>> >>>>
>> >>>> cp
METv3.0/data/sample_fcst/2005080700/wrfprs_ruc13_18.tm00_G212
>> >>>> lambert_conf.grib
>> >>>> copygb -xg"255 0 327 235 40908 -92200 128 49100 -75900 50 35
64"
>> >>>> lambert_conf.grib lat_lon.grib
>> >>>> METv3.0/bin/pcp_combine -add lat_lon.grib 03 lat_lon.nc
>> >>>>
>> >>>> I've attached the resulting NetCDF file. If you do "ncdump
-h" on
>> it,
>> >>>> you'll see the header. Here's the relevant info for you...
>> >>>>
>> >>>> In the global attributes, the following things must be
defined.
>> These
>> >>>> specify the grid on which your data is defined. You'll need
to
>> fill
>> in
>> >> the
>> >>>> values that define your grid:
>> >>>> :MET_version = "V3.0" ;
>> >>>> :Projection = "LatLon" ;
>> >>>> :lat_ll = "40.908000 degrees_north" ;
>> >>>> :lon_ll = "-92.200000 degrees_east" ;
>> >>>> :delta_lat = "0.035000 degrees" ;
>> >>>> :delta_lon = "0.050000 degrees" ;
>> >>>> :Nlat = "235 grid_points" ;
>> >>>> :Nlon = "327 grid_points" ;
>> >>>>
>> >>>> In the dimensions section, you need to define dimensions named
>> "lat"
>> and
>> >>>> "lon":
>> >>>> lat = 235 ;
>> >>>> lon = 327 ;
>> >>>>
>> >>>> In the variables section, you can name the variable whatever
you'd
>> like,
>> >>>> but it should be indexed by the lat and lon dimensions. Note,
you
>> do
>> >> NOT
>> >>>> need to define the lat(lat,lon) and lon(lat,lon)
>> >>>> variables since MET doesn't actually use them:
>> >>>> float APCP_03(lat, lon) ;
>> >>>> APCP_03:level = "A3" ;
>> >>>> APCP_03:units = "kg/m^2" ;
>> >>>> APCP_03:_FillValue = -9999.f ;
>> >>>> APCP_03:init_time_ut = 1123372800 ;
>> >>>> APCP_03:valid_time_ut = 1123437600 ;
>> >>>> APCP_03:accum_time_sec = 10800 ;
>> >>>>
>> >>>> As for the variable attributes listed above, I've only
retained the
>> ones
>> >>>> that MET actually reads. The rest you see in your ncdump
output
>> can
>> be
>> >>>> omitted if you'd like.
>> >>>>
>> >>>> Just let me know if you get stuck.
>> >>>>
>> >>>> John
>> >>>>
>> >>>>
>> >>>> On 02/11/2011 01:25 PM, RAL HelpDesk {for jdduda at iastate.edu}
>> wrote:
>> >>>>>
>> >>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=44337
>
>> >>>>>
>> >>>>> I should specify: the grid resolution is 0.01 deg lat by 0.01
deg
>> lon.
>> >>>> So
>> >>>>> it is regularly spaced in some sense, but not in terms of
>> Euclidean
>> >>>>> distance. Does that make a difference?
>> >>>>>
>> >>>>> Jeff
>> >>>>>
>> >>>>> On Fri, Feb 11, 2011 at 2:20 PM, RAL HelpDesk {for John
Halley
>> Gotway}
>> >> <
>> >>>>> met_help at ucar.edu> wrote:
>> >>>>>
>> >>>>>> Jeff,
>> >>>>>>
>> >>>>>> MODE can only handle data that's on a regularly spaced grid.
For
>> GRIB
>> >>>>>> files, it reads the grid definition from the grid
description
>> section
>> >>>> (GDS)
>> >>>>>> or each GRIB record. For NetCDF files, like the
>> >>>>>> output of the PCP-Combine tool, it reads the grid definition
from
>> a
>> >>>> special
>> >>>>>> set of global attributes. If you have a gridded dataset and
>> would
>> >> like
>> >>>> to
>> >>>>>> use it in MODE, it'd need to be regularly spaced,
>> >>>>>> and it'd probably be easiest to write it as a NetCDF file
making
>> it
>> >> look
>> >>>>>> like the output of the PCP-Combine tool.
>> >>>>>>
>> >>>>>> Hope that helps.
>> >>>>>>
>> >>>>>> John
>> >>>>>>
>> >>>>>> On 02/11/2011 12:56 PM, RAL HelpDesk {for
jdduda at iastate.edu}
>> wrote:
>> >>>>>>> I wish to run MODE using a data set that did not come from
a
>> model
>> >> (it
>> >>>>>> came
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> John,
>> >>> I've attached the ncdump output from my files (which are
already in
>> >> netCDF
>> >>> format). The only reason I know the grid spacing is from the
>> >> documentation on
>> >>> this data, not from the ncdump. I suppose I still need to run
it
>> through
>> >> copygb
>> >>> in order to get it into a "nicer" format though, right?
>> >>>
>> >>> Jeff
>> >>>
>> >>> On Fri, Feb 11, 2011 at 2:57 PM, RAL HelpDesk {for John Halley
>> Gotway}
>> >>> <met_help at ucar.edu <mailto:met_help at ucar.edu>> wrote:
>> >>>
>> >>> Jeff,
>> >>>
>> >>> That's fine actually. That's a lat/lon projection, or more
>> correctly
>> >> Plate
>> >>> Carree. That's one of the projection types that MET can
read.
>> Now
>> >> the
>> >>> issue comes down getting it into a data format that
>> >>> MET can read. As I mentioned, using NetCDF would probably
be
>> >> easiest. I
>> >>> took a GRIB file that's defined over CONUS and regridded it
to a
>> >> Lat/Lon
>> >>> grid over the Great Lakes. Then I ran it through
>> >>> PCP-Combine to get a NetCDF version of that file. Here are
the
>> >> commands I used:
>> >>>
>> >>> cp
METv3.0/data/sample_fcst/2005080700/wrfprs_ruc13_18.tm00_G212
>> >>> lambert_conf.grib
>> >>> copygb -xg"255 0 327 235 40908 -92200 128 49100 -75900 50
35 64"
>> >>> lambert_conf.grib lat_lon.grib
>> >>> METv3.0/bin/pcp_combine -add lat_lon.grib 03 lat_lon.nc <
>> >> http://lat_lon.nc>
>> >>>
>> >>> I've attached the resulting NetCDF file. If you do "ncdump
-h"
>> on
>> >> it,
>> >>> you'll see the header. Here's the relevant info for you...
>> >>>
>> >>> In the global attributes, the following things must be
defined.
>> >> These
>> >>> specify the grid on which your data is defined. You'll
need to
>> fill
>> >> in the
>> >>> values that define your grid:
>> >>> :MET_version = "V3.0" ;
>> >>> :Projection = "LatLon" ;
>> >>> :lat_ll = "40.908000 degrees_north" ;
>> >>> :lon_ll = "-92.200000 degrees_east" ;
>> >>> :delta_lat = "0.035000 degrees" ;
>> >>> :delta_lon = "0.050000 degrees" ;
>> >>> :Nlat = "235 grid_points" ;
>> >>> :Nlon = "327 grid_points" ;
>> >>>
>> >>> In the dimensions section, you need to define dimensions
named
>> "lat"
>> >> and "lon":
>> >>> lat = 235 ;
>> >>> lon = 327 ;
>> >>>
>> >>> In the variables section, you can name the variable
whatever
>> you'd
>> >> like, but
>> >>> it should be indexed by the lat and lon dimensions. Note,
you
>> do
>> NOT
>> >> need
>> >>> to define the lat(lat,lon) and lon(lat,lon)
>> >>> variables since MET doesn't actually use them:
>> >>> float APCP_03(lat, lon) ;
>> >>> APCP_03:level = "A3" ;
>> >>> APCP_03:units = "kg/m^2" ;
>> >>> APCP_03:_FillValue = -9999.f ;
>> >>> APCP_03:init_time_ut = 1123372800 ;
>> >>> APCP_03:valid_time_ut = 1123437600 ;
>> >>> APCP_03:accum_time_sec = 10800 ;
>> >>>
>> >>> As for the variable attributes listed above, I've only
retained
>> the
>> >> ones
>> >>> that MET actually reads. The rest you see in your ncdump
output
>> can
>> >> be
>> >>> omitted if you'd like.
>> >>>
>> >>> Just let me know if you get stuck.
>> >>>
>> >>> John
>> >>>
>> >>>
>> >>> On 02/11/2011 01:25 PM, RAL HelpDesk {for
jdduda at iastate.edu
>> >>> <mailto:jdduda at iastate.edu>} wrote:
>> >>> >
>> >>> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=44337
>> >
>> >>> >
>> >>> > I should specify: the grid resolution is 0.01 deg lat by
0.01
>> deg
>> >> lon. So
>> >>> > it is regularly spaced in some sense, but not in terms
of
>> >> Euclidean
>> >>> > distance. Does that make a difference?
>> >>> >
>> >>> > Jeff
>> >>> >
>> >>> > On Fri, Feb 11, 2011 at 2:20 PM, RAL HelpDesk {for John
>> Halley
>> >> Gotway} <
>> >>> > met_help at ucar.edu <mailto:met_help at ucar.edu>> wrote:
>> >>> >
>> >>> >> Jeff,
>> >>> >>
>> >>> >> MODE can only handle data that's on a regularly spaced
grid.
>> For
>> >> GRIB
>> >>> >> files, it reads the grid definition from the grid
>> description
>> >> section (GDS)
>> >>> >> or each GRIB record. For NetCDF files, like the
>> >>> >> output of the PCP-Combine tool, it reads the grid
definition
>> from
>> >> a special
>> >>> >> set of global attributes. If you have a gridded
dataset and
>> >> would like to
>> >>> >> use it in MODE, it'd need to be regularly spaced,
>> >>> >> and it'd probably be easiest to write it as a NetCDF
file
>> making
>> >> it look
>> >>> >> like the output of the PCP-Combine tool.
>> >>> >>
>> >>> >> Hope that helps.
>> >>> >>
>> >>> >> John
>> >>> >>
>> >>> >> On 02/11/2011 12:56 PM, RAL HelpDesk {for
jdduda at iastate.edu
>> >>> <mailto:jdduda at iastate.edu>} wrote:
>> >>> >>> I wish to run MODE using a data set that did not come
from
>> a
>> >> model (it
>> >>> >> came
>> >>> >>
>> >>> >>
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Jeff Duda
>> >>> Iowa State University
>> >>> Meteorology Graduate Student
>> >>> 3134 Agronomy Hall
>> >>>
www.meteor.iastate.edu/~jdduda<http://www.meteor.iastate.edu/%7Ejdduda><
>> http://www.meteor.iastate.edu/%7Ejdduda><
>> >> http://www.meteor.iastate.edu/~jdduda>
>> >>
>> >>
>> >
>> >
>>
>>
>
>
> --
> Jeff Duda
> Iowa State University
> Meteorology Graduate Student
> 3134 Agronomy Hall
> www.meteor.iastate.edu/~jdduda
>
------------------------------------------------
More information about the Met_help
mailing list