20010220: Calculating moisture flux divergence (cont.)

>From: "Paul L. Sirvatka" <address@hidden>
>Organization: College of DuPage
>Keywords: 200102162013.f1GKD9L01250 McIDAS-X SFCCON GRDDISP

Paul,

>I found that eveything crashes when I plot on graphic frame 1. When I
>switched everything to 6 is worked fine.  

Everything?  Even simple plots:

SFCPLOT T SURFACEMAP LATEST

Does this happen immediately after starting up, or does it happen when
some other routine goes south?

Also, if you have had one or more crashes with McIDAS it might be the
case that there is an unwanted file being found from your MCPATH.  Here
is how to check this out:

First, what account are you running from?

EXIT your McIDAS session
cd $MCDATA
dmap.k Frame
dmap.k \*.00\*

The DMAP invocations (dmap.k) should find those files _only_ in
a subdirectory of your ~/.mctmp directory.  If files found by the dmap.k
invocations are located in directories other than ~/.mctmp, then they
must be removed before you restart your session.

This may all sound a little mysterious, but the idea is the following:

The information for each frame is stored in a file named FrameN.M (where
N and M are numbers).  In order to be able to save information about
what is in a frame (like the navigation and colors used so far to
plot), these files must be writable by whoever is running the McIDAS
session.  If the user 'mcidas' has had a particularly bad session abort
sometime in the past, there is a chance that a FrameN.M file could be
created _incorrectly_ in the ~mcidas/data or ~mcidas/help directory.
In this case, if you are running your session as some other user,
you will not be able to write to this file, and things like trying
to draw maps on images loaded into a frame for which there is an
unintended FrameN.M file will fail.

>Could it have something to do with the frame I am currently on?

It shouldn't.

>It seemed
>that other times I would lose the window when I tried to SF to it during a
>batch file.

This really feels like the problem I am trying to describe above.

>Just a thought.

Please let me know:

o what account you are running your McIDAS session from
o the results of the dmap.k invocations listed above.

Tom

>From address@hidden Tue Feb 20 17:03:46 2001

Under further review...it seems not to want me to be on the frame that it
is trying to plot on. When I stay off it, everything is fine.

BTW We run some (close to the lastest?) version of redhat.

Paul

>From address@hidden Tue Feb 20 15:47:47 2001
>Subject: Re: 20010220: Calculating moisture flux divergence (cont.)

OK Here is another example that causes the image to croak and it fails to
run. It bombs with the invocation to contour theta-e

IGU DEL 21
ERASE I 1 10
GU REST SURFACE 1 10

REM Now, let's start making some maps!

REM Mixing ratio flux divergence on 4

SFCCON MIX SURFACEMAP LATEST OUT=SAVE MYDATA/GRIDS.21
SFCCON STREAML SURFACEMAP LATEST OUT=SAVE MYDATA/GRIDS.21
GRDDISP MYDATA/GRIDS.21 4 MAP=SURFACEMAP G1='PARAM MIX' G2='PARAM U'
G3='PARAM V' NEWPAR=MDVG GKGS SFC
MATH='((G1*(DDX(G2)+DDY(G3))+G2*DDX(G1)+G3*DDY(G1))*36000)' CINT=5
DASH=POS FORMAT=F4

REM Streamlines on 1
SFCCON STREAML SURFACEMAP LATEST GRA=1 CINT=3 COLOR=2

REM Theta-e on 1
SFCCON THAE OLAY LATEST GRA=1 COLOR=3 CINT=5 UNIT=K DASH=ALL

REM Dew points on 2
SFCCON TD SURFACEMAP LATEST GRA=2 UNIT=F CINT=5 COLOR=2

more deleted....

Definitely it says that it is a floating point error.

Hope this helps.

Paul

>From address@hidden Tue Feb 20 17:20:27 2001
>Subject: Re: 20010220: Calculating moisture flux divergence (cont.) 

On Tue, 20 Feb 2001, Unidata Support wrote:

> Everything?  Even simple plots:
> 
> SFCPLOT T SURFACEMAP LATEST

I did SFCCON T USA LATEST 

and it crashed when I was on the frame.

> 
> Does this happen immediately after starting up, or does it happen when
> some other routine goes south?

Hmmmm....

Well it seems ok now. I do not know when it dies.

I am running these things as McIDAS. Now sometimes other batch files run
off the cron tab get kicked off.

> 
> Also, if you have had one or more crashes with McIDAS it might be the
> case that there is an unwanted file being found from your MCPATH.  Here
> is how to check this out:
> 
> First, what account are you running from?
> 

MCIDAS

> EXIT your McIDAS session
> cd $MCDATA
> dmap.k Frame
> dmap.k \*.00\*
> 
> The DMAP invocations (dmap.k) should find those files _only_ in
> a subdirectory of your ~/.mctmp directory.  If files found by the dmap.k
> invocations are located in directories other than ~/.mctmp, then they
> must be removed before you restart your session.
> 

Here is one I got...

-rw-      7656 Jan 30 02:06 SNDSAVE.004  /home/mcidas/workdata

> This may all sound a little mysterious, but the idea is the following:
> 
> 
> o what account you are running your McIDAS session from
> o the results of the dmap.k invocations listed above.

I hope this helps a bit. Also...when I do a PID, I find that the GRDDISP
takes up 99+% of the CPU.

Paul


-- 
******************************************************************************
* Paul L. Sirvatka          | Office: (630) 942-2118; Lab: (630) 942-2590    *
* Professor of Meteorology  | COD Weather Lab: (630)-858-0032                * 
* College of DuPage         | Address: 425 22nd St.  Glen Ellyn, IL 60137    *
******************************************************************************