20000208: McIDAS problems & NLDNDISP command (cont.)

>From: Michael Voss <address@hidden>
>Organization: SJSU
>Keywords: 200001181849.LAA08980 McIDAS-X ROUTE PP BATCH syslogd crontab LDM

Mike,

re: typo in ~mcidas/.tcshrc
>That's beyond embarrassing, it's just plain lame!(thanks for being patient)

No problem.

>We may finally be configured correctly, and believe it or not I have
>made some progress up the learning curve.

Super.  Now why doesn't the email simply end here :-)

>I have one interesting problem that you might like to check out. This
>problem occurs when plotting NLDN data from the Menu, but it is rather
>difficult to describe. Suppose I have an imagery loop loaded and then I
>go to overlay some NLDN data on there, i.e. SF3-F3-F4.

OK, I am with you.  You want to overlay all flashes for the specified
time interval using the time of the image loaded in a frame in a loop
as the center point.

>The NLDN data
>plots and no errors are given and yet what happens is a rectangular
>portion of the image which contains the label is written over and the
>lightning strikes in that rectangle are accumulated. It's like it takes
>the first image from that rectangular area and then plots the new data
>in there without updating the image. I'm not sure how else to describe
>this without you actually seeing it. This does occur for the mcidas
>user or any regular user.

I just setup a test of this from my system at home to see what you were
describing, and I think that I see the same thing!  Funny, we never ran
into this before.  The problem must bin in NLDNDISP or something it
calls since erasing the graphics from the frames returns the imagery to
looking normal.

If your loop is in frames 1 - 10; try running the following after doing
the lightning overlay steps from the menu:

EG 1 10 LEV=3

Do the images in your frames go back to looking correct?  They do on
my system.

>One of these times I'll find something that is actually useful to you
>and not a result of my lameness  :)

This is useful!  And perplexing!!  I will have to dive into code to
figure out what is happening here.

>As always your help is appreciated,

Sorry for the problems...

Tom

>From address@hidden  Wed Feb  9 12:33:50 2000
>If your loop is in frames 1 - 10; try running the following after doing
>the lightning overlay steps from the menu:
>
>EG 1 10 LEV=3
>
>Do the images in your frames go back to looking correct?  They do on
>my system.

Yup!

>This is useful!  And perplexing!!  I will have to dive into code to
>figure out what is happening here.

a miracle, glad to be of service and good luck to you,

Mike

>From address@hidden  Wed Feb  9 19:53:52 2000

Mike,

I made a fix to nldndisp.pgm that should fix the problem you were seeing
overlaying lightning data on top of a loop of satellite images (a one
line addition, no less).  I implemented this modification on your system
after testing it out on my machine at home:

<login as 'mcidas'>
cd mcidas7.6/src
ftp ftp.unidata.ucar.edu
  <user>
  <pass>
  cd mcidas7.6/src           <- I grabbed it from my development directory
  get nldndisp.pgm
  quit
make nldndisp.k
ls -l nldndisp.k ~/bin/nldndisp.k  <- to verify that the newly created copy
                                      overwrite the one linked to the bin
                                      directory
  
Please exercise the lightning plotting overlays and let me know if you
continue to see problems.

Tom

>From address@hidden  Thu Feb 10 11:32:25 2000

Mike,

re: exercise modified NLDNDISP routine
>
>The lightning plotting overlays work fine now for the standard loop defined in
>  the UNIDATA.MNU. Thanks!

Why, oh why couldn't your email end right here :-(

>However :), for the special loops I defined in my LOCAL2.MNU file the NLDNDISP
>seems to have a problem with the dates/times of the frames. Todays date is
>2000041 but the program sees something else:
>
>NLDNDISP:
>NLDNDISP: Invalid Reference day.
>NLDNDISP: 4th positional argument exceeds system limits --> 100041
>NLDNDISP: Must be valid day within range 1072693248 thru 1081528320.
>NLDNDISP:

This is very odd.

>WAIT!!! I updated my entries to the ones you suggested, i.e., like:
>
>      GOES-8 Eastern Infrared
>F  2 "EG 1 25;SF #?VFRMS;IMGDISP RTIMAGES/GE-IR ALL=1 25
>+ " LATLON=32 82 MAG=-2 EU=IMAGE SF=YES REFRESH='MAP H GRA=(GRA);
>+ " BAR GRA=(GRA) ORI=#?BAR NO SU=IRTEMP';
>+ " RUN 1 25 #?DWELL CL=Y FILE=LBDR.MCB;TERM L ON

As an aside, I would modify this a little.  Presumably ?VFRMS is defined
to be '1 10'; true?  Since you hard code the range of frames for the IMGDISP
ALL= keyword and for the RUN invocation, I would hardcode the SF invocation.
Alternatively, I would define a new string that specifies the longer
loop sequence.  Say:

TE ?LVFRMS "1 25
      GOES-West Western Infrared
F  2 "EG 1 25;SF #?LVFRMS;IMGDISP RTIMAGES/GE-IR ALL=#?LVFRMS
+ " LATLON=32 82 MAG=-2 EU=IMAGE SF=YES REFRESH='MAP H GRA=(GRA);
+ " BAR GRA=(GRA) ORI=#?BAR NO SU=IRTEMP';
+ " RUN #?LVFRMS #?DWELL CL=Y FILE=LBDR.MCB;TERM L ON

This is not a big deal, however.

>instead of:
>
>      GOES-9 Western Infrared
>F  5 "EG 1 25;ALOOP #SYS(2113) #SYS(2114) 1 25 EC 32 130  -2 DWELL=2 7
>+ " MAP=YES H 9002 EU=IMAGE SU=IRTEMP LIMIT=32 BAR=#?BAR NO SF=YES

OK, the point is switching from loading with ALOOP to loading with IMGDISP.

>While the second entry above works fine for looping just the images, it does
>not for overlaying stuff. Now the NLDNDISP overlays fine on the 25 image loop 
>defined by the first entry above.

This makes sense.  If the loops in UNIDATA.MNU work, then doing the
same thing with less/more frames should work in your menu.  The
difference is appaently caused by the format for the DAY that DF uses
when updating the frame directory.  This is undoubtedly related to the
change in the DAY format change from YYDDD to YYYDDD at the beginning
of the year.  It just goes to show that one is obliged to start using
newer ADDE commands to do things in McIDAS.  This is especially true in
light of the Sunset list presented in:

http://www.unidata.ucar.edu/packages/mcidas/mcx/sunset.html

>thanks again,

Later...

Tom