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

19990519: gdplot

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
> -------------------------------------------------------
> 
> 
>