A couple of issues with 5.9.4

• To: <gembud@xxxxxxxxxxxxxxxx>
• Subject: A couple of issues with 5.9.4
• From: "David Gold" <dr_david_gold@xxxxxxxxxxxxx>
• Date: Fri, 17 Nov 2006 17:52:38 -0600

Dear Gembuds,

I've encountered a couple of problems that didn't occur under Gempak 5.9.1
and I'm wondering whether anybody has encountered these same issues. A
search of the archives didn't really address either so I thought I'd throw
this out there.



Problem 1: Under Garp when I try to import objectively analyzed surface
fields, I get a weird error: "yyyymmddhhmm2time: Can't convert string 19 to
tm structure". When I look under Model Plan Projection-->Available Times and
select "SURFACE" from the product drop-down menu (I added a SURFACE entry in
the modellabels and the corresponding file suffix in modelkeys
(Garp_defaults), of course), all I see is a vertical list of left-justified
"19" 's. If I try selecting a satellite image or short loop with time
matching (closest), the available times box is populated with "No Match". I
had no problem at all displaying these fields in GARP under 5.9.1. I ran
Garp from the command line using "garp -verbose 2 -memcheck" and it revealed
some very strange goings-ons:



gdfile = /home/gempak/ldm/data/gempak/model/2006111722_sfcanal.gem
 gdatim = 19
 glevel = 500
 gvcord = hght
 gfunc = TMPC
 nfunc = 1
 cint = 5/ /
 line = 6/-2/2/2
 scale = 0
 hilo
 hlsym = 2;1.5//21;/;/hw ;
 clrbar = ///.96;/;/
 title = 6/1/ WED Dec 31 1969 2359 SURFACE (TMPC ) Temperature (C)
 contur = /
 skip = 0/1;1
 fint = 5/ /
 fline = 0;30-15;15;15;15;15;15
 ctype = C
 text = 1.3/21/1/hw
 frame = 1
 ititle = 1
 verbose = 2
 iperr = 0
Segmentation fault


But when I do a gdinfo on the oa grid file (yyyymmddhh_sfcanal.gem) it shows
the date correctly parsed out. GDPLOT2 plots the field correctly with no
problems. What is going on? What is Garp choking on?



Problem 2: GDVINT is croaking on an error "Excessive number of parameters.
Parameter CICE      skipped."

The other parameters listed (besides CICE) are MCNV and PVOR (the latter is

Again, this behavior was not present under 5.9.1. Could this problem (and
the first one) be rooted in some weirdness with the change in library calls?



I'd appreciate any help!



David Gold