NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Steve, The time range seems to work for me in gdplot from a gdstat avehght field on my Irix machine, but I know I made a fix to gdplot back in January to fix a string length problem in the time variable. It could be that your aix is just nice enough to get away with that bug. Look in your $GEMPAKHOME/src/programs/gd/gdplot directory and see if you have an update to gdbtim.f after Jan 28 this year. I posted my gdplot directory which you can use to update and recompile/link your gdplot and give it a try. You can download this from ~gbuddy/nawips-5.4/patches/gdplot.tar.Z and untar from the $NAWIPS directory - it will unpack into the gempak5.4/src/programs/gd/gdplot. Rebuild gdplot with: cd $GEMPAKHOME/src/programs/gd/gdplot make clean make make install make clean If you already have the gdbtim.f update, then maybe you could ftp your grid file to ~gbuddy/incoming and I'll try to duplicate your problem. If you ever make any changes to array sizes in gemprm, then you have to recompile the complete gemlib since the common block sizes are defined there. I just mention that incase you just recompiled programs without building the new libraries- since common block offsets would be totally off the wall. I don't think thats a problem here... but worth mentioning. Steve On Tue, 18 May 1999, Steven L. Mullen wrote: > > > Steve Chiswell wrote: > > > Steve, > > > > Polcomm just ended so I'm catching up on email. > > > > Can you send me your gdplot parameters so > > I can see what is going on? > > GDFILE ../gdstat_mean.gem > GDATTIM 981101/0000f000:990331/1200f000 > GLEVEL 0 > GVCORD none > PANEL 0 > SKIP /-4;4 > SCALE 0 > GFUNC avepmsl > CTYPE c > CONTUR 0 > CINT 4 > LINE 1/1/1/1!1/5/1/1 > FINT > FLINE > HILO !!1/H#;L#//0;0 > HLSYM 1.5;1.5/2/1/2/hw > CLRBAR y > GVECT > WIND > REFVEC 5 > TITLE 1 > TEXT 1/1/1/hw > CLEAR y > GAREA 12.19;-133.46;57.29;-49.38 > PROJ lcc/25;-95;25 > MAP 10/1/5 > LATLON 10/1/.5/1/10;10 > DEVICE xw > STNPLT > SATFIL > RADFIL > LUTFIL > > > > > > > I'll create a gdstat grid with a time range gdattim=time1:time2. > > Are you running more than one display grid in gdplot or just > > gfunc=avepmsl? > > Just one > > > I'm just trying to figure out if the gdattim > > is being inherited by a gvect or other gfunc function (separated with > > the ! character if you can see the grid ok with gdlist (and presumably > > then gdcntr). The time parsing should be taken from the gdcntr > > code but since gdplot is just a combination of gdwind and gdcntr > > which can handle multiple gfunc/gvect fields, it could be a > > small bug in how a looping time range is taken. > > I must confess that I wonder if I screwed something up > during the make/install process when I had to change > LLMXLV=1000 from 200 in GEMPRM.PRM in > order to get gdstat to process more than 200 times. > I already had changed LLMXGT=1000 to increase > the number of frames that gdplot could loop > to above the default value of 30. > > Thanks for your help...again, > Steve > > > > > > > Chiz > > > > On Tue, 18 May 1999, Steven L. Mullen wrote: > > > > > Steve, > > > > > > I am having problems with gdplot with > > > gdattim set to two time levels, as with > > > gfunc=avepmsl grids from gdstat. > > > > > > When I do a gdlist, the routine shows > > > the grid file with the expected attributes. > > > Ditto when I access the grid in gddiag, things > > > go smoothly. But when I try to plot the grid > > > in gdplot, I get segmentation fault (core dumped). > > > However, when I run an attecedent gddiag job > > > to change the time attributes for the grid > > > to just one level, then use gdplot plot > > > on the single time level grid, she plots fine > > > in gdplot. Is there something generic about > > > gdplot on SGI that causes this behavior, > > > or (most likely) something flaky about > > > our implementation? > > > > > > Any clues on where to start to > > > our investigation would be appreciated. > > > > > > Steve > > > > > > P.S. On a diffferent note, the > > > help that you give me with my > > > script a couple of months ago > > > lead me stop a bad programming > > > practice of mine. That is: a script > > > calling a script which called a > > > third script where an environmental > > > variable used by the top script > > > was changed! That lead to a > > > gempak routine bombing with > > > a particular diagnostic not > > > closely related to the underlying > > > problem. Another example of why > > > I am a scientist, and not a computer > > > programmer! > > > > > > > > > > > > -- > > > ------------------------------------------------------- > > > {} Steven L. Mullen > > > {} {} Dept. of Atmospheric Sciences > > > {} {} {} University of Arizona > > > {} {} {} 1118 E. 4th St. > > > {}{}{} PO Box 210081 > > > {} Tucson, Arizona 85721-0081 > > > {} Tel:(520) 621-6842 > > > {} Fax:(520) 621-6833 > > > {} Email: address@hidden > > > ------------------------------------------------------- > > > > > > > > > > > -- > ------------------------------------------------------- > {} Steven L. Mullen > {} {} Dept. of Atmospheric Sciences > {} {} {} University of Arizona > {} {} {} 1118 E. 4th St. > {}{}{} PO Box 210081 > {} Tucson, Arizona 85721-0081 > {} Tel:(520) 621-6842 > {} Fax:(520) 621-6833 > {} Email: address@hidden > ------------------------------------------------------- > > >