[IDV #XNA-384239]: IDV - Data from MM5 netCDF to IDV supported netCDF

Hi Mark-

> About the MM5 netCDF files: I personally do not have any control over how 
> they are generated; the MM5 files are given to us in the netCDF format using 
> the NUWG convention. However, the issues you found with our MM5 data files 
> are being addressed. We really appreciate all of your assistance

No problem.

> Is there any way how I could use NcML to change our NUWG netCDF convention 
> files to CF netCDF convention files?

According to our expert:

"The problem is that the NUWG x,y coordinates are not in coordinate variables, 
as required by CF. SO yuo cant write a generic ncml file to do the conversion.

You could, however, write a program that would do that."

So in the end, it would be best to have the program that converts MM5
to netCDF to do this.

Don Murray


> >From: Unidata IDV Support <address@hidden>
> >Date: Wed Jul 05 13:55:44 CDT 2006
> >To: address@hidden
> >Cc: address@hidden
> >Subject: [IDV #XNA-384239]: IDV - Data from MM5 netCDF to IDV supported 
> >netCDF
> 
> >Hi Mark-
> >
> >> More information on our MM5 system:
> >> MM5 is part of the weather portion of the RSA program being delivered to 
> >> the Eastern and Western Ranges.  Lockheed Martin is the prime contractor.
> >
> >Thanks for the file.  I've attached the NCML that lets you read in
> >the fua file to the IDV.  There are two basic problems with the
> >fsf and fua files that cause the IDV problems:
> >
> >- the missing grid_type_code variable.  I've sent a note to FSL asking
> >for valid entries for grid_type and we will try to code something into
> >a future release that will look for that if grid_type_code is missing.
> >For now, we just add in the grid_type_code in the NCML file.
> >
> >- the vertical dimension for each variable is defined as z, but in
> >reality it should be level.  The attached NCML file renames the level
> >variable to z.  This does not work for the fsf file because level is
> >defined with units of pascals and a value of 0.  Since the IDV is a
> >3D application, 0 Pa is high up in the vertical and gets clipped using
> >the default vertical scaling (shows as a blank display).  For now, you
> >can either use the previous NCML file I sent, or change the definition
> >of variable z to be:
> >
> >  <variable name="z" orgName="level" type="int">
> >    <attribute name="units" type="String" value="m" />
> >  </variable>
> >
> >so it will just put it at 0 m.
> >
> >Other issues with these files:
> >
> >- the valid_range attribute for some variables is not correct.  For example,
> >the p and slp variables in the fsf file do not plot because they
> >have a valid_range attribute, but the values are beyond the valid ranges.
> >For example, slp is:
> >
> >        float slp(record, z, y, x) ;
> >                slp:_FillValue = 1.e+037f ;
> >                slp:long_name = "MSL Pressure          " ;
> >                slp:units = "pascals" ;
> >                slp:valid_range = 0.f, 100000.f ;
> >                slp:LAPS_var = "SLP" ;
> >                slp:lvl_coord = "MSL" ;
> >                slp:LAPS_units = "PA" ;
> >
> >with values:
> >
> > slp =
> >  102247.1, 102246.5, 102245.3, 102244.1, 102242.8, 102241.6, 102240.4,
> >    102239.3, 102238.2, 102237.3, 102236.4, 102235.5, 102234.6, 102233.7,
> >    102232.7, 102231.7, 102230.8, 102229.7, 102228.7, 102227.6, 102226.6,
> >    102225.6, 102224.5, 102223.3, 102222.1, 102220.8, 102219.4, 102218,
> >    102216.3, 102214.4, 102212.4, 102210.3, 102208.2, 102206.2, 102204.2,
> >    102202.3, 102200.6, 102199, 102197.5, 102196.1, 102194.6, 102192.9,
> >    102191.1, 102189.1, 102187.1, 102184.9, 102182.7, 102180.5, 102178.2,
> >    102175.9, 102173.5, 102171.2, 102168.9, 102166.4, 102163.9, 102161.4,
> >    102158.9, 102156.4, 102153.9, 102151.4, 102148.8, 102146, 102143.1,
> >    102140, 102136.8, 102133.4, 102129.8, 102126, 102122, 102118, 
> > 102113.9,.....
> >
> >which are all outside the max range defined as 100000.  If you plot surface
> >pressure (psf), you'll see that part of the data is missing because
> >some lies in the range and some outside.  This may be a problem for
> >other variables so make sure your valid range matches the range of
> >your data.
> >
> >- some units are not correct (e.g. meters for rh in the fsf file)
> >
> >- it would be better to not have a z dimension for the 2D variables
> >or to have it defined properly.
> >
> >How much control do you have over the generation of these netCDF files?
> >Is it a home grown program to convert MM5 to netCDF?  Since NUWG has
> >vague definitions for some things and has not been updated since 1995,
> >I would suggest using a different convention like CF if possible.  If
> >that's not possible, it would be beneficial to correct the issues
> >identified above.  netCDF is a self-describing format and thus is
> >only as good as the metadata it contains.
> >
> >Let me know if you have other questions.
> >
> >Don Murray
> >
> >Ticket Details
> >===================
> >Ticket ID: XNA-384239
> >Department: Support IDV
> >Priority: High
> >Status: Open
> 
> 


Ticket Details
===================
Ticket ID: XNA-384239
Department: Support IDV
Priority: High
Status: Open