>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.
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly 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.