[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20000314: McIDAS Defaults and Eta GRIDS from GRIB

Hey Tom,

(Don said you were returning Wednesday, so I assume you might see
this).  Welcome back.  Hope you and Cathy had an excellent vacation in
Australia!  I look forward to hearing about it sometime.

You might recall before you left that I had pulled over Chad Johnson's
stand_alone grib decoder, gribdec.pgm.  After working out the glitches
of getting the mcidas environment right (eg., redirections) we have
been using the decoder a lot (with great ease I might add!).  We have
read grib files of eta fields that we got from SSEC (Chris Schmidt, a
student of Paul Menzels that we are working with to compare GOES Total
Ozone with Altered Water Vapor, PV, etc.), no problem.  We have also
read grids that I retrieved (bought actually) from the NCAR archive,
they were saved as part of a GCIP archive.  They are superior files,
since they have 25mb resolution near the tropopause, and we can get
better estimates of potential vorticity.

Generally, we have been able to verify that we decode things without
any problems, the results look reasonable (eg., fields like surface
pressure and 500mb heights look fine).  We have also derived some
quantities (eg., potential vorticity) and the features in resulting
fields match remotely sensed features (eg., troughs and streamers
readily visible in water vapor images).  I note all this to indicate
that I am pretty convinced we are generally reading the grids without
problems.  (Note there are never no error messages generated using the
decoder, and running at various debug levels, all the output looks

The hitch is that these NCAR grids are reporting specific humidity,
this is where we have a problem.  We are getting grids that have values
ranging from 0 to 0.02, with only 1 significant figure (for the months
of April and September, over the grid 212 eta model domain).  At first
we thought there might have been a problem in the NCAR archive itself,
but we asked Chi Fan at NCAR to decode a grib file (they have their
own, non-mcidas grib-decoding software they make available).  He did
so, and sent us the info on a sample grid.  We compared it with what we
have, and I am pretty sure that the problem is one of scale (or
units).  They are decoding specific humidity in their grids in units of
kg/kg, so they get min/ max numbers for 700mb which are: 0 => 0.0078
(or 0 to 7.8 gm/kg; seems reasonable)

> Here is Chi-Fan's output for specific humnidity at 700 mb for 00 UTC April 1, 
> 1996:
> wgrib 96040100.AWIP3D00.tm00 -V -d 86
> rec 86:1753106:date 1996040100 SPFH kpds5=51 kpds6=100 kpds7=700 
> levels=(2,188)
> grid=212 700 mb anl:
>   SPFH=Specific humidity [kg/kg]
>   timerange 0 P1 0 P2 0 TimeU 1  nx 185 ny 129 GDS grid 3 num_in_ave 0 
> missing 0
>   center 7 subcenter 0 process 89 Table 2
>   Lambert Conf: Lat1 12.190000 Lon1 -133.459000 Lov -95.000000
>       Latin1 25.000000 Latin2 25.000000 LatSP 0.000000 LonSP 0.000000
>       North Pole (185 x 129) Dx 40.635000 Dy 40.635000 scan 64 mode 8
>   min/max data 0 0.0078  num bits 7  BDS_Ref 0  DecScale 4 BinScale 0

We on the other had are decoding values for this date/time that range
from 0=>0  :-(  and most notably, we are decoding units of grams/kilogram.

Here is U.Va.'s output:

> Statistics of
> Parameter: SHUM
> Units: GPKG
> Level of data: 700  MB
> Time of data:      0 UTC
> Day of data:   1996092
> Data came from: ETA
> 0-hour forecast
> Dataset: AEROCE96/ETA_NCAR
> Minimum:   0.0000000E+00 first occurred at [row,col]: [    1,    1]
>                                          [lat,lon]: [  54.84, 153.09]
>                                           and 23864 times thereafter
> Maximum:   0.0000000E+00 first occurred at [row,col]: [    1,    1]
>                                          [lat,lon]: [  54.84, 153.09]
>                                           and 23864 times thereafter
> Mean:   0.0000000E+00
> SD  :   0.0000000E+00
> Number of points analyzed:  23865
> Number of points missing:       0
> Row range:     1 to   129
> Col range:     1 to   185
> GRDINFO Done, Number of grids statistically analyzed=1
> GRDINFO - done
> Dataset position 10     Directory Title= NCAR ETA GRIDS
> PAR    LEVEL       DAY        TIME    SRC FHOUR     FDAY       FTIME  GRID  
> ---- --------- ------------ -------- ---- ----- ------------ -------- ----- 
> ----
> SHUM  700 MB   01 APR 96092 00:00:00  ETA     0 01 APR 96092 00:00:00    84 
> Total pts= 23865 Num rows= 129  Num columns= 185    received:  1999319 202726Z
> Specific humidity
> GRIB ID numbers: Geographic =212; PAR = 51; Model ID = 89; Level type =100
> Units of gridded variable are GPKG Scale of variable is:   2
> Lambert Conformal Tangent Cone Projection
> Row num of pole= -226.67  Col num of pole=  105.00  Col spacing (m)= 40635.0
> Standard Latitudes=   25.00     25.00   Standard Longitude=   95.00
> Number of grids listed = 1
> GRDLIST - done

Here are the thoughts that have occurred to me:

a) The decoder might be working fine, but maybe McIDAS is truncating
the grids, because it automatically assumes that specific humidity is
in units of gm/kg (which would actually be 1000x the numbers in the
grid).  (We did try the simple, obvious test of multiplying the grids
by 1000, but then our values were discretely 0, 10 and 20.

b) The decoder is reading the units wrong and truncating 
   the grids.

Do grib files encode units or is this being assumed by the decoder?

Does this trigger any light-bulbs in your head on what might be going

I know this is outside of the standard distribution, (and therefore
support)....but, I thought you might have some insight into this or
some suggestions for action.  Believe me, its not an "academic"
question.  Owen is using these grids in his dissertation proposal
(defending November 30).  And since specific humidity is the only
moisture variable reported in the NCAR GCIP formatted grids, its all we
have for looking at the modelled moisture features. (This is one of the
validation efforts Tony has been undertaking with the altered water
vapor work, which he will present at the AMS).

I'm sure you're swamped with a full desk on your return, so I hate to
bug you, but isn't it good to know your expertise is appreciated? Glad
you're back.

Thanks, as always.


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.