Re: [Fwd: New Client Reply - [IDV !XNA-384239]: IDV - Data from MM5 netCDF to IDV supported netCDF]

  • To: John Caron <caron@xxxxxxxxxxxxxxxx>
  • Subject: Re: [Fwd: New Client Reply - [IDV !XNA-384239]: IDV - Data from MM5 netCDF to IDV supported netCDF]
  • From: Don Murray <dmurray@xxxxxxxxxxxxxxxx>
  • Date: Fri, 07 Jul 2006 09:48:54 -0600
Thanks, John.  I'll pass that along.


John Caron wrote:
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.

Don Murray wrote:
Any suggestions on this or is it more trouble than it's


-------- Original Message --------
Subject: New Client Reply - [IDV !XNA-384239]: IDV - Data from MM5 netCDF to IDV supported netCDF
Date: Wed, 05 Jul 2006 15:03:55 -0600
From: Mark McLain <support-idv@xxxxxxxxxxxxxxxx>
Reply-To: support-idv@xxxxxxxxxxxxxxxx
Organization: UCAR/Unidata
To: dmurray@xxxxxxxxxxxxxxxx

New Client Reply: IDV - Data from MM5 netCDF to IDV supported netCDF


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

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


From: Unidata IDV Support <support-idv@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: Wed Jul 05 13:55:44 CDT 2006
To: rantir@xxxxxxxxxxx
Cc: support-idv@xxxxxxxxxxxxxxxxxxxxxxxx
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" />

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:

 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

Don Murray                               UCAR Unidata Program
dmurray@xxxxxxxxxxxxxxxx                        P.O. Box 3000
(303) 497-8628                              Boulder, CO 80307

  • 2006 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-java archives: