>From: "Jennie L. Moody" <address@hidden> >Organization: UVa >Keywords: 200004270006.e3R06rG00226 McIDAS-X -XCD gribdec.k gbtbpds001.2vx Owen and Jennie, I have had a go round with Chad Johnson of SSEC about the modifications that Owen and I made to the gbtbpds001.2vx files being used by gribdec.k in the conversion of Specific Humidity (SHUM) grib messages you got from NCAR to McIDAS GRID files. I asked Chad whether he thought that changing the scale factors in gbtbpds001.2vx was the correct way to "solve" the decoding problem. He said that he did _not_ think so. Instead, he ventured that the unit of the grid stored in the McIDAS GRID file should be KGKG instead of GPKG. Chad also asked if 2 digits of precision was enough in the SHUM values to which I said no (following Owen's recommendations). Chad's comments indicated that the scale factor number in gbtbpds001.2vx should be the precision of the values decoded from the grib messages and stored in McIDAS GRID files. This follows my original thinking. What it does not explain, however, is how increasing this number from 2 to 5 changed the values of the field by a factor of 1000. In order to get to the bottom of what is _really_ going on, I promised Chad that I would run a couple of more tests on the data that you are looking at. The easiest way for me to do this is to get the mccode login and be reminded of the location of the input grib and output GRID files. Can you provide me these? What I will do is: o change the scale factor in gbtbpds001.2vx back to 2 o change the output unit to KGKG o verify that the decoded values look correct I will then experiment (again) with changing the scale factor and see if it can be made to simply change the precision of the values being decoded, and report my findings back to Chad. Thanks in advance for the access information... By the way, on the "bad news" front: Chad is leaving SSEC for greener pastures at the end of this month. This leaves a _big_ hole in their XCD development/support group (which was Chad) and in things related to the LDM (like the IDD ingection of NOAAPORT TG (conventional and model output) data AND the Unidata-Wisconsin datastream products). You probably saw the SSEC job announcement that we forwarded to our community last week. This is for Chad's replacement. 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.