This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Paul, Sorry for the silence... it has been quite busy here lately! re: environment created by 'mcenv' > I understand this. The problem is that it does not happen *every* time. > > This is the important part of the kickoff script that establishes mcenv: > > mcenv -f 2@600x800 -g 16 << EOF > /home/scripts/mcidas2/radarcomps/remaprad.pl > /home/scripts/mcidas2/radarcomps/createradarcomps.pl > exit > > So you see, the graphics switch is set to 16. Yup, this looks good. Is there any part of your Perl scripts (assuming that the .pl suffix is indicating a Perl script) that creates a new shell? re: > I am wondering if the environments are getting confused? Perhaps, but each environment should have its own private copy of User Common. If User Common were shared, then things being done in one script could well affect things done in the other script. But, given that the scripts are run sequentially, it is hard for me to understand how this interference could happen. re: some McIDAS commands fork off additional commands that can run after the parent command has exited. The command that does this the most obviously is IMGDISP where the actions run from the REFRESH= keyword are spun off asynchronously. > Ah ha....I will try this to see if things change. Nope...still have > problems.The same ones. I have (apparently random) the errors concerning > the lack of image and the WWDISP errors. > > BTW I had this in the batch file:: > :CONTINUE > MAP H 14 GRA=1 IMA=1 > FRMLABEL IMA=1 "NEXRAD 1KM MOSAIC (DAY) (HHMM) > BAR COLOR=16 SU=MYBREF GRA=1 > ZA 6 7 C GRA=1 POS=8 700 "NEXLAB-College of DuPage > ZA 6 12 L GRA=1 POS=5 789 "$T > > OS "sleep .2s > FRMSAVE 1 /home/apache/climate/sirvatka/rad/%4.rad.gif OK. I don't think that any of the above commands do things asynchronously. And, I think that using 'sleep' run from an OS command should work the same way as WAIT. But, just to be sure, you could try using WAIT directly and waiting more than a fraction of a second. re: > WWDISP NAV=C WID=1 COL=5 6 5 6 12 12 1 7 7 9 16 PLO=NBOX WLI=YES > OS "sleep .2s > FRMSAVE 1 /home/apache/climate/sirvatka/rad/%4-ww.gif > > EG 1 > BAR COLOR=16 SU=MYBREF GRA=1 > OS "sleep .2s > FRMSAVE 1 /home/apache/climate/sirvatka/rad/overlays/%4-ww.gif > K > OS "sleep .2s > EG 1 LEV=16 > WWDISP NAV=C WID=1 COL=5 6 5 6 12 12 1 7 7 9 16 PLO=NBOX WLI=YES > OS "sleep .2s > FRMSAVE 1 /home/apache/climate/sirvatka/rad/overlays/%4-ww2.gif > K > OS "sleep .2s re: > Notice I used OS "sleep instead. Yup, I noticed. What happens if you increase the sleep from 0.2 to 1 or 2 seconds? re: > Quite baffled Me too. The typical problem encountered is when a command that spawns off other commands exits before the spawned commands are finished. This can result in unexpected results that sound a lot like yours. One that I ran into early on was a FRMSAVE being executed before the actions in an IMGDISP REFRESH= keyword sequence were finished. That is why I moved all of my MAP, BAR, etc. executions to after the IMGDISP in my scripts. I also added a WAIT before each FRMSAVE just to make sure that the previous action(s) had completed before capturing the results. Cheers, Tom -- **************************************************************************** Unidata User Support UCAR Unidata Program (303) 497-8642 P.O. Box 3000 address@hidden Boulder, CO 80307 ---------------------------------------------------------------------------- Unidata HomePage http://www.unidata.ucar.edu **************************************************************************** Ticket Details =================== Ticket ID: GYT-719991 Department: Support McIDAS Priority: Normal Status: Closed