20040506: Compile McIDAS-X 2003 (cont.)

>From: Eirh-Yu Hsie <address@hidden>
>Organization: CU/CIRES
>Keywords: 200405061548.i46Fm1tK006094 McIDAS 2003 build

Hi Hsie,

>I also find out there is a new filing scheme under 2003 version (in 
>/home/mcidas/data/DSSERVE.BAT).  The old AREA file for GOES WEST IR is no
>longer store under AREAxxxx file:
>
>old:
>DSSERVE ADD RTIMAGES/GW-IR        AREA  130  139 "GOES-West Western US IR
>
>new:
>DSSERVE ADD RTIMAGES/GW-IR        AREA  TYPE=IMAGE 
>DIRFILE=/data/ldm/gempak/images/sat/GOES-10/4km/IR/IR_*     "GOES-West Western 
>US IR
>
>Am I correct?

Either way works:

- the 'old' method is setup for files that follow the
  AREAnnnn naming convention

- the 'new' method is for files that may be named with something more
  descriptive, like IR_20040506_1215, etc.

Since most Unidata McIDAS sites also use GEMPAK, and since GEMPAK GUIs
need files to be stored in a hierarchical director structure with file
names that contain information like date and time, it may be convenient
to configure ADDE to use the storage structure that GEMPAK needs.  The
DIRFILE= keyword on DSSERVE allows this in a nice way.  The other thing
that is very nice about doing things the 'new' way is that you do not
have to have file REDIRECTions setup to locate the files.  The DIRFILE=
keyword takes care of this since its value is a regular expression that
will locate the file(s).  Also, it is now easy to verify the
configuration by cutting and pasting the value of DIRFILE onto an 'ls'
invocation:

ls /data/ldm/gempak/images/sat/GOES-10/4km/IR/IR_*

The only drawback with the new method is in the creation of products
by LDM pqact.conf initiated decoding of images.  The ROUTE PostProcess
BATCH scheme only knows about images with the old AREAnnnn names.
Many sites decode Unidata-Wisconsin imagery into both the old
McIDAS structure (into ~ldm/data/mcidas as AREAnnnn) and new GEMPAK
structure (into ~ldm/data/gempak/images/sat/...).  Since the namespace
for the old way of doing things controls the number of images stored,
they never need scouring.

Filing images hierarchically, on the other hand, requires
that you setup a data scouring process to keep the number of files
down to a reasonable list.  If you don't, your disk will eventually
fill and things will come t to a crashing halt.  We make
several script available that can be configured and used to 'prune'
images stored in GEMPAK hierarchies.  You can find those scripts
in the pub/ldm/scour directory of anonymous FTP on our FTP server,
ftp.unidata.ucar.edu

Cheers,

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.