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

20000427: gribdec.k not properly decoding specific humidty in NCAR grib files


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.



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

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,


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


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.