Tom, After our meeting in Boulder last week, Owen is reviving the issue of getting specific humidity data out of some grib files we obtained from the NCAR mass store. He drafted a note to you, which I just read. I am appending it to you along with a response to Owen reminding him of a few other things you need to know. I have asked him to take the lead in sorting out this issue. Thanks. Jennie ----------- Owen First of all, yes, the gribdec.k is a piece of stand-alone software that was written by Chad Johnson at Wisconsin, SSEC. We retrieved the source code for this, and I set up the compilation with some assistance/direction from Tom. I had looked at gribdec.pgm, however, I do not think this is where the coding changes will get made. This program makes several calls to other McIDAS routines, some of which are part of the regular unidata distribution and/or libraries. I had looked at the code back in December/January, before the AMS (before the sky fell), and discussed it a little with Tom in Long Beach. If we need to change a base routine, it will be important to move its source (and change its name) to a local file, like gribdec.pgm. We want to make sure that any change we make to correctly read the files from NCAR does not mess up our ability to read other grib data, eg., the grib data we have occasionally retrieved from Dolores Kneissling at COMET (for NARE and TOPSE). What Tom needs is the following: a)the login password for user mccode on windfall (even I don't know this at the moment), and an example of two grib files, give him one grib-file that decodes just fine, then give him an example of a grib-file that does not correctly decode the specific humidity (one of the NCAR GCIP grib files) b) provide him with the syntax for running mccode (eg., specifying a root-grid number results in the construction of a grid-file based on juliandate). c) show him what redirections you are using to access the grib-file (unless you have made it available locally), recall, mccodes redirections control where the grib files are read from and where the grid files get written. Finally, this is not standard Unidata software, so, if Tom doesn't have the opportunity to help, we have to respect that! Good luck, Jennie ------------------------------------------------------- On Apr 26, 19:00, Owen Cooper wrote: > Subject: gribdec.k question > > Jennie, > I was just going to send theis e-mail to Tom Yoksas about the problem we > are having with gribdec.k decoding the spec. humidity gribs. But before I > send it I should first find out if we have the source code and take a look > at it. > Do we have it or do we only have the binary? > Thanks > Owen > > > Hi Tom, > A while back Jennie may have mentioned to you that we have been using a > piece of code called gribdec.k to decode NCAR Eta grib files (this isn't > standard Undiata code and may have been written by someone at Wisconsin). > > It's been working fine except for when it decodes specific humditity. It > is expecting spec. humidity in units of kg/kg but the grib files report > the data as g/kg. So spec. hum. of 10g/kg in the grib gets decoded to .01 > kg/kg in the grid. I wish I could just scale everything by a factor of > 1000 to fix the problem but gribdec.k only decodes down to two decimal > places. So anything below 10 g/kg in the grib file gets decoded as zero > in the grid. > > How would I go about editing the gribdec.k program so I can change the > units? Would I need the source code and then have to recompile ? > > > Owen Cooper > Department of Environmental Sciences > Clark Hall > University of Virginia > Charlottesville, VA 22903 > address@hidden > (804) 924-4237 > > -- End of excerpt from Owen Cooper <address@hidden> From: Unidata User Support <address@hidden> Date: Wed, 03 Mar 2000 12:00:00 -0700 (MST) Owen and I met in my office in an attempt to: o demonstrate the problem gribdec.k was having in decoding grib files UVa obtained from NCAR o we found that we could modify the McIDAS-XCD grib decoder grib configuration files, gbtbpds001.2vx (x= 1, 2, 3) and get correct values Discussion: The problem in the decoding was that the specific humidity was being unpacked into values that were 1000 times too small (e.g. .01 GPKG instead of 10 GPKG). We found that we could change the scale factor value in gbtbpds001.2vx from 2 to 5 and get the correct order of magnitude for the specific humidity grids. Here is an example line: Original line: 051 | Specific humidity | SHUM | kg/kg | GPKG | 2 Changed to: 051 | Specific humidity | SHUM | kg/kg | GPKG | 5 This makes sense in that the scale difference between the original units of specific humidity (kg/kg) and the stored unit (GPGK == g/kg) is 1000. >From address@hidden Thu May 4 11:24:56 2000 >Subject: 20000503: multiple boot on a laptop and gribdec.k Thanks Tom. This is good news, in a casual conversation Tony said he thought there were problems with running Linux on a laptop, but I didn't have any chance to dig around for info yet. Glad to know it possible anyway (taking into account your cautionary note). MANY thanks for helping Owen out with the gribdec.k program. He was ecstatic. We owe you big time for all your help. I know that gribdec.k isn't standard code, but, if we ever want to push the idea of longer term archives being available, its software like this that makes the archives really accessible to Unidata users.
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.