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

[GEMPAK #ZTW-190355]: A couple of 5.9.4 questions



David,

See 2 items embedded in test below.

Steve Chiswell
Unidata User Support


> Steve,
> 
> 
> 
> I never thanked you for correcting my regex for the GFS ensemble products.
> I've since deduced that my internet feed is a bit under-provisioned to
> receive the entire conduit feed.
> 
> 
> 
> Anyway, I posted to gembud on Friday but I haven't heard any feedback yet
> and I'd like to at least get pointed in the right direction so I thought I'd
> send this e-mail directly to support. I built Gempak 5.9.4 from source on a
> Linux box (RHEL WS 4.0). For the most part everything seems to work as it
> did under 5.9.1, save for two issues:
> 
> 
> 
> 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:

A string array is getting overrun. This has always been occuring, but the
C wrapper to the fortran routine now causes an error. I have reposted the
distribution with a fix.


> 
> 
> 
> 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. Furthermore, GDPLOT2 plots the field
> correctly with no problems (save for the bad data over the Mexican plateau).
> I've traced the error message back to timeutil.c but since the time shows
> correctly in both gdinfo and gdplot2, I'm not sure why Garp is having
> issues. One more piece of information (don't know whether it is significant
> or not): after running command line garp, I see the following lines right
> off the bat:
> 
> init_clock: Clock is   ticking
> 
> init_clock: Bad time string Undefined value
> 
> 
> 
> 
> 
> Problem 2: In performing an interpolation to isentropic surfaces, GDVINT is
> producing an error message "Excessive number of parameters. Parameter CICE
> skipped."
> 
> The other parameters listed (besides CICE) are MCNV and PVOR (the latter is
> what I compute and add to the original grid file in GDDIAG in the step prior
> to calling GDVINT).
> 
> 
> 
> Again, this behavior was not present under 5.9.1. Any clues on where to
> start debugging these issues would be appreciated. I am not adverse to
> changing routines and then re-compiling/installing portions (or all) of the
> distro.


I increase the sizes of the number of parameters/levels in gdvint from the 
default
values that come from NCEP. You downloaded the release before I posted the final
version and I hadn't updated that size to match previous distributions yet.
It was updated prior to the Nov 19th release announcement and will be
there in the repost for the Garp problem you mentioned above.



Steve Chiswell
Unidata User SUpport







> 
> 
> 
> Thanks again,
> 
> 
> 
> David Gold
> 
> 
> 
> 
> 
> 
> 
> 
> 


Ticket Details
===================
Ticket ID: ZTW-190355
Department: Support GEMPAK
Priority: Normal
Status: Closed