>From: "Jennie L. Moody" <address@hidden> >Organization: UVa >Keywords: 200004270006.e3R06rG00226 McIDAS-X -XCD gribdec.k gbtbpds001.2vx Owen and Jennie, Here is some closure on the gribdec.k decode of SHUM values from NCAR grib messages: >From address@hidden Wed May 10 15:47:17 2000 >Subject: Re: 20000508: XCD decoding of specific humidity from NCAR grib files >(cont.) >Tom, >Yep....your right. In Mcmkmcgrid.c, the scale factor in the grid header >is always set to 2. Yet...each grid point is scaled by the factor >defined in gbtbpds001.2vx. My first reaction was 'this is unbelievably >wrong'. If one is going to scale the grid point by one factor one >should store that scale factor in the McIDAS grid header. >Right?...Wrong. If you look at the gbtbpds001.2vx files, you will >notice that most of the scale values are set to '2'. But if you look at >the pressure fields and the absolute vorticity fields, these are set >differently. Let's focus on the pressure field. The unit as stored in >the McIDAS grid file is millibars and the scale factor is set to 0 - no >scaling. This seems odd, but if you look at Office Note 388, this >parameter is stored in the GRIB file as 'Pa'. This effectively presents >the raw GRIB value, which is in 'Pa' as 'hPa'. 'hPa' is equal to 'MB' >and 'MB' is the unit stored in the McIDAS grid header. The raw 'Pa' >value is not scaled in the grid file, but the client divides the value >by 100 (scale factor 2) to get MB. Yuck!!! >I would love to store the values in the McIDAS grid files in their >original units, then scale them appropriately to save the precision >necessary. Unfortunately nothing is ever that easy in McIDAS. For >example, if I stored the pressure field in 'Pa', this would require >everybody to add the UNIT=MB clause to every GRDDISP pressure field >request to plot MB. Otherwise they would see pressure contour lines >like 100400 Pa rather than 1004 hPa or MB. >> The only reason that leaving the output unit as GPKG and changing the >> scale factor from 2 to 5 (i.e,, 10**2 to 10**5) worked for us is that >> we were exploiting an apparent bug in dmgrid.k/gribdec.k that does not >> write the gbtbpds001.2vx scale factor to the output grid header. >Based on the above observation I don't think we have no choice. It >looks like the decoder was designed this way. I retract my previous >suggestion and suggest you keep the unit as GPKG and change the scale >factor from 2 to 5. At the time, I didn't realize the decoder always >stored a scale factor of 2 in the grid header, and apparently for a >reason. >I may not have explained myself very well. If you are confused, give me >a call. >-Chad So, it looks like Owen and I did the exact right thing given the design of the McIDAS grib decoder (gribdec.k and dmgrid.k run the same code so they are equivalent). I would say, however, that the decoder needs to be modified so that the number of significant digits can be specified independently in the gbtbpds001.2vx files. I am afraid that this has no chance of being even considered given that Chad is leaving SSEC at the end of the month. Just thought that you would want to know... Tom
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.