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