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

Re: 19990519: gdplot (fwd)


---------- Forwarded message ----------
Date: Wed, 19 May 1999 16:50:18 -0700
From: Steven L. Mullen <address@hidden>
To: Steve Chiswell <address@hidden>
Subject: Re: 19990519: gdplot

Chiz,

    You're the man. Installing the patch
seemed to cure the problem!

    Thanks again.

Steve

Steve Chiswell wrote:

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

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