20000612: Help converting non-ADDE script

>From: Angel Li <address@hidden>
>Organization: RSMAS/University of Miami
>Keywords: 200006061956.e56JuLT23087 McIDAS-X ADDE cron mcbatch.sh mcrun.sh

Angel,

>I use the two attached McIDAS batch files to generate graphics for the
>web but after switching over to the XCD decoders the displayed image is
>wrong

Can you tell me how the image is wrong?  I suspect, after reading your
attached BATCH files, that the image compositing is not working as it
was; true?

Starting to use XCD should not, in of itself, have caused things to
break (XCD decoders do nothing withe imagery in the Unidata-Wisconsin
datastream).  I suspect that the routing table ROUTE.SYS, that is used
to determine the names of the decoded images and the PostProcess BATCH
file to run upon successful ingest/decode of the images has been either
altered or replaced.

-- quick check --

o start a McIDAS-X session as the user 'mcidas'
o see which copy of ROUTE.SYS your session will find:

  DMAP ROUTE.SYS

o if ROUTE.SYS is not found, or if the copy found is not the one
  in the directory into which lwtoa3 decodes files, then add a
  REDIRECTion for ROUTE.SYS:

  REDIRECT ADD ROUTE.SYS "directory_where_lwtoa3_decodes_UW_imagery

o after you can/are pointing to the correct copy of ROUTE.SYS,
  do a listing of its contents:

  ROUTE LIST

  From this listing you will see the name(s) of PostProcess BATCH files
  that will be run upon receipt of UW datastream image products.
  If this file has not been changed, then you should see that IR8.BAT
  should still be run upon receipt of GOES-East IR images (product
  code UI.

  From this listing, make sure that the topographic composite imagery
  entries (N1-N8) have not been SUSpended (suspended entries in the
  table will have an 's' in the 'S' column).  If they have been
  suspended, then the composite products are no longer being generated.
  This would explain how the images you are using for your web page
  are "wrong" (they would be old and never change)

>but the fronts and other graphics are correct.

From the listing of the BATCH files you are using, the FRNTDISP invocation
is being told to use the currently available front for the plot.  The
fact that this works tells me that the XCD ingestion of frontal data
is working as it should.

>Is it just a matter
>of using "IMGDISP RTIMAGES/GE-IR.0" to load the current GOES IR image?

IMGDISP RTIMAGES/GE-IR.0 is equivalent to IMGDISP RTIMAGES/GE-IR.  The
default for IMGDISP is the display of the most current image of a dataset.

As long as the script you are running has access to the dataset definition
information (which it should if the Bourne shell script, batch.k is
setup correctly (it should be since things were working)), things should
work as they did before.

>Did the #SYS values change when I switched to the XCD scheme?

No, no SYSKEY.TAB entries get changed by running XCD.  A comment: the ADDE
commands/way of doing things moves away from use of SYSKEY.TAB entries
since one of the objectives of ADDE is the move away from thinking
about specific files.  The SYSKEY.TAB entries we put to use were a way
of storing information about what data is currently available.  That
is only possible when the files are local.  Since ADDE allows one to point
at other servers at will, the notion about what current data is becomes
server-specific.

Here is a quick take on how I would ADDEize the BATCH files you included:

old IR8.BAT:

NORTMAPR 9016 %2 9993 N1 L 0 9016 ECHO=N
GU REST GRAPHIC 1
DF #SYS(2127) 1 EC 32 82 SF=NO EU=TOPOSAT
BAR 1 SU=IRTOPO
FRMLABEL C IMA=1 LEV=254 0 "GOES-8 IR/TOPOGRAPHY COMPOSITE (DAY) (JDAY) (HHMM) -
 UNIDATA
LA %2 %2 DEV=F GOES8IR.WHR R
SVGIF 1 GOES8IR.GIF
FRONT GRA=1
SVGIF 1 G8FRONT.GIF
OS "/bin/Mail -s GOES8-IR wobb </dev/null >/dev/null

The NORTMAPR invocation combines the "cloudy" (brightness >= 140) portion of
the IR image and combines it with topography.  I have not ADDEized NORTMAPR
yet, so this line will have to stand.

Here is what I would do to the rest of the BATCH file:

new IR8.BAT:

SF 1
GU REST GRAPHIC 1
NORTMAPR 9016 %2 9993 N1 L 0 9016 ECHO=N
IMGDISP RTIMAGES/GE-IRTOPO 1 LATLON=32 82 EU=TOPOSAT
BAR 1 SU=IRTOPO
FRMLABEL C IMA=1 LEV=254 0 "GOES-8 IR/TOPOGRAPHY COMPOSITE (DAY) (JDAY) (HHMM) 
- UNIDATA
IMGLIST RTIMAGES/GE-IR DEV=F GOES8IR.WHR R
FRMSAVE 1 GOES8IR.GIF
FRONT OLAY FRAME
FRMSAVE 1 G8FRONT.GIF


Here are the reason for the changes:

o use ADDE IMG* commands instead of non-ADDE DF and LA
o use FRMSAVE command instead of SVGIF which is going away in 7.7
  (FRMSAVE is being updated to add new output forms; in 7.7, for
  example, one can save to GIF, PPM, BMP, JPEG, PS, and CPS)


The same kind of changes are applicable to VIS8.BAT:

old VIS8.BAT

NORTMAPR 9016 %2 9993 N2 NONE 0 9016 MAPAREA=9971 DEV=NNN
GOESCOMP NONE %2 9987 C CV N8 SCRAREA=9978 9979 MAP=YES 9019 9971 DEV=NNN
GU REST GRAPHIC 1
DF #SYS(2130) 1 EC 32 82 SF=NO EU=TOPOSAT
LA #SYS(2130) #SYS(2130) DEV=F GOES8VIS.WHR R
FRONT GRA=1
SVGIF 1 G8VIS.GIF
OS "/bin/Mail -s GOES8-VIS wobb </dev/null >/dev/null


new VIS8.BAT:

SF 1
GU REST GRAPHICS
NORTMAPR 9016 %2 9993 N2 NONE 0 9016 MAPAREA=9971 DEV=NNN
GOESCOMP NONE %2 9987 C CV N8 SCRAREA=9978 9979 MAP=YES 9019 9971 DEV=NNN
IMGDISP RTIMAGES/GE-VISTOPO 1 LATLON=32 82 EU=TOPOSAT
IMGLIST RTIMAGES/GE-VISTOPO DEV=F GOES8VIS.WHR R
FRONT OLAY FRAME
FRMSAVE 1 G8VIS.GIF
OS "/bin/Mail -s GOES8-VIS wobb </dev/null >/dev/null

>Thanks,

I feel pretty confident that the reason that IR/Topography and VIS/Topography
images that the BATCH files are trying to use are not being created
by something simple like the routing table that the McIDAS-X sessions
point to is not the same one being updated by the lwtoa3 decoder, or the
routing table is altered or munged.

Please let me know if I am off the mark in the above.

>Angel

Tom

>From address@hidden Tue Jun 13 10:03:57 2000

Angel,

re: what about the images was wrong
>The satellite data was out of date.

OK.

>DMAP ROUTE.SYS now points to the directory where the AREA files
>are supposed to be generated but no new AREA files are being
>created and ROUTEPP.LOG stopped updating around midnight last night.
>
>Could you log on to my system and take a quick look?

Sure.  Give me the logins as 'mcidas'and 'ldm' and I will see what is going
on.

>Thanks,

No problem.

Tom