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
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
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
what I am computing in gddiag in the step prior to calling GDVINT).
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!