Eric,
My understanding is that each shell process id ($$ in CSH) has an
individual message queue that GEMPAK uses. If you fire up multiple
jobs from the same xterm window, then gpend would kill them. But, if
you are running scripts (CSH, Bourne or otherwise), then each has its
own individual shell, and its own individual message queue.
Therefore, gpend will only affect those graphics started by that
script.
Others can correct any errors I have in understanding, but I can
assure you that adding gpend to the very end of scripts is a good
idea. Note, if you can get away with using the "_gf" or "_nc"
versions of GEMPAK programs, they do not use the message queues and
gpend is not needed. Gpend can be a little slow when you're doing
thousands of things, and it's nice to skip that when you can do so
safely.
Cheers,
David
--
David Ovens e-mail: ovens@xxxxxxxxxxxxxxxxxxxx
Research Meteorologist phone: (206) 685-8108
Dept of Atm. Sciences plan: Real-time MM5 forecasting for the
Box 351640 Pacific Northwest
University of Washington http://www.atmos.washington.edu/mm5rt
Seattle, WA 98195 Weather Graphics and Loops
http://www.atmos.washington.edu/~ovens/loops
On Fri, Nov 12, 2010 at 05:01:23PM -0600, Eric Nelson wrote:
>
> Kind of a basic question, but one that I haven't found an answer for.
> What I've read lead me to believe that good gempak scripting practice
> entails a gpend at the end of your gempak scripts. On a system that
> running mutliple scripts for data on different time scales (i.e. models,
> satellite, surface plots, etc) will a gpend at the end of a satellite
> script kill the model graphics that might be running at the same time?
> How do you manage the graphics queues in a way where once script isn't
> killing the queue for another?
>
> -Eric
>
> --
> Eric Nelson - Weather Data Manager
>
> College of Dupage Meteorology Dept.
> http://weather.cod.edu
> enelson@xxxxxxxxxxxxxxx
>
> _______________________________________________
> gembud mailing list
> gembud@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/