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

Re: 19991004: Gempak problem - no map backgrounds

Greg,

Often when I have lots of scripts to run, I make each of them create
their own temporary working directory using the process number, eg:

cd $GEMDATA/tmp
set WORK=ruc_gdplot.$$
mkdir $WORK
cd $WORK

.....

rm -f *
cd ..
rmdir $WORK



Its possible that multiple scripts could have stomped on the running .nts
files. Since you explicitely set $MAPFIL in your script, I would have
thought that this would have worked.

Steve Chiswell
Unidata User Support



On Mon, 4 Oct 1999, Greg Stossmeister wrote:

> Steve,
> 
>    Everything you mention checks out. This is a script that has run fine
> for several weeks and then suddenly stopped producing the backgrounds.
> The same script ran fine and produced the backgrounds when I cd'ed to
> another directory (other than the one the script is in) just a minute
> ago. I swear though that I have deleted the last.nts and gemglb.nts and
> that didn't seem to fix it. 
> 
>    One other thing - I have a bunch of these scripts producing model
> plots of different levels  - all in the same directory. My scripts each
> cd to that directory before running. Do you think this is an interaction
> problem between scripts? What can I do to clean the slate for gempak?
> 
> Thanks,
>    Greg
> 
> Steve Chiswell wrote:
> > 
> > Greg,
> > 
> > In addition to $MAPFIL, you also have:
> > [IP -7]  AREA is an unrecognized parameter
> > 
> > Your $GEMPAKHOME directory has the pdf and parm subdirectories
> > which must be readable, and after sourcing your Gemenviron, the
> > $GEMPDF variable must be pointing you the proper location.
> > Check the gdplot.pdf file and make sure it isn't corrupted.
> > Also check to make sure your GEMMAPS directory is readable and has the
> > hipowo.gsf file in it.
> > 
> > Does the gdplot work ok when run interactively?
> > Check to make sure you don't inadvertantly have something strange in
> > your work directory, and make sure the gemglb.nts and last.nts files
> > in that directory are writable and aren't corrupted.
> > 
> > Steve Chiswell
> > Unidata User Support
> >
>