[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20020724: McIDAS-X & XCD (cont.)



>From: "Fingerhut, William A" <address@hidden>
>Organization: Lyndon State
>Keywords: 200207191535.g6JFZa920941 McIDAS-X XCD REDIRECT

Bill,

>Steven knows and approves of your logging in.

OK, I logged on right after reading this message.

I immediately reviewed environment variable settings (e.g., MCPATH,
etc.), REDIRECTions, etc.  All looked OK.

I did all of this -- as always should be done -- from the
~mcidas/workdata.  The key point is when configuring McIDAS, always
run commands while residing in the $MCDATA directory.  This goes for
'mcidas' as well as ordinary users.

While checking out things, I did the following:

<as 'ldm'>
ldmadmin stop

<as 'mcidas'>
cd /var/data/ldm/mcidas/xcd
rm *.R* *.IDT
cd /home/mcidas/workdata
tl.k                     <- to verify XCDDATA setting which was correct
rm ../data/SKEDFILE      <- these should be in ~mcidas/workdata
rm ../data/STRTABLE                       "
rm -f core.*             <- core files from ingetext.k and ingebin.k (!?)

Then, I started looking around.  I found the following:

1) you have your system setup to save XCD-decoded files in 
   /var/data/ldm/mcidas/xcd and ldm-mcidas-decoded files in
   /var/data/ldm/mcidas/xdata.  As far as the software goes, there is
   no reason to keep these sets of files separated from each other.
   In fact, I now recommend to write all data files to a single
   directory as it eliminates a configuration step that I will get
   to next.

   Both the ldm-mcidas and XCD decoders are setup to read/write items
   from the files ROUTE.SYS and SYSKEY.TAB.  For point source file
   decoding, they both use information from the file SCHEMA.  I found
   that you had one copy of SCHEMA in /var/data/ldm/mcidas/xcd and
   a different one (the most current one) in /var/data/ldm/mcidas/xdata.
   Since the copy of SCHEMA that both decoders should be using is
   the most current one, I did the following:

   cd /var/data/ldm/mcidas/xdata
   rm ../xcd/SCHEMA
   ln SCHEMA ../xcd

   Since both decoders want to read/write ROUTE.SYS and SYSKEY.TAB,
   I did the following:

   <still in /var/data/ldm/mcidas/xdata>
   ln ROUTE.SYS ../xcd
   rm ../xcd/SYSKEY.TAB                 <- this was different from the on in .
   ln SYSKEY.TAB ../xcd

   Now, both directories are using the same set of SCHEMA, ROUTE.SYS, and
   SYSKEY.TAB

2) I noticed that the majority of the XCD-produced MD files (surface, upper
   air, synoptic, etc.) were bad.  Their file sizes were:

ls -alt MDXX*
-rw-rw-r--    1 ldm      udata     4989748 Jul 24 16:16 MDXX0035
-rw-rw-r--    1 ldm      udata     4149660 Jul 24 16:16 MDXX0065
-rw-rw-r--    1 ldm      udata     5078740 Jul 24 15:43 MDXX0034
-rw-rw-r--    1 ldm      udata        6656 Jul 24 02:38 MDXX0045
-rw-rw-r--    1 ldm      udata     5979224 Jul 24 01:08 MDXX0064
-rw-rw-r--    1 ldm      udata     4987048 Jul 23 23:59 MDXX0033
-rw-rw-r--    1 ldm      udata        6656 Jul 23 23:47 MDXX0005
-rw-rw-r--    1 ldm      udata        6656 Jul 23 23:17 MDXX0015
-rw-rw-r--    1 ldm      udata        6656 Jul 23 23:17 MDXX0025
-rw-rw-r--    1 ldm      udata        6656 Jul 23 23:14 MDXX0055
-rw-rw-r--    1 ldm      udata        6656 Jul 23 14:46 MDXX0044
-rw-rw-r--    1 ldm      udata        6656 Jul 23 12:23 MDXX0014
-rw-rw-r--    1 ldm      udata        6656 Jul 23 12:23 MDXX0024
-rw-rw-r--    1 ldm      udata        6656 Jul 23 12:20 MDXX0004
-rw-rw-r--    1 ldm      udata        6656 Jul 23 12:20 MDXX0054
-rw-rw-r--    1 ldm      udata     4671164 Jul 22 18:14 MDXX0063

   You can see from this partial, edited listing that a number of the
   files have a size of 6656.  This indicates that they were created
   incorrectly.  I deleted all of the XCD-created MD files (while the
   LDM was turned off), so they could get recreated correctly.


Continuing on:

<still as 'mcidas'>

batch.k XCD.BAT          <- this and the next step came after 1) and 2)
batch.k XCDDEC.BAT          below
After making the above changes, I restarted the LDM:

<as 'ldm'>
ldmadmin start

Now, as new MD files are coming in and being decoded, they look
properly sized:

ls -alt MDXX* 
-rw-rw-r--    1 ldm      udata    32688636 Jul 24 16:34 MDXX0005
-rw-rw-r--    1 ldm      udata     4552888 Jul 24 16:34 MDXX0035
-rw-rw-r--    1 ldm      udata     6460512 Jul 24 16:34 MDXX0055
-rw-rw-r--    1 ldm      udata     4155336 Jul 24 16:34 MDXX0065
-rw-rw-r--    1 ldm      udata     3526680 Jul 24 16:29 MDXX0015
-rw-rw-r--    1 ldm      udata       16640 Jul 24 16:22 MDXX0025

The munged MD files was _probably_ the sticking point for the creation
of the *.RAT files.  If the decoder can't correctly write to the output
MD file, the rapid access files don't get updated.  In fact, as I write
this I note that *.RAT files are now being produced/updated.  Yahoo!

Another problem I just saw is that the McIDAS-XCD output directory is
apparently being scoured by LDM's scour utility.  This is not advised
since scour can delete files that are open for writing by XCD routines.
I strongly recommend that the LDM scour of this directory be stopped.
In fact, I stopped it by editing ~ldm/etc/scour.conf and commenting
out ALL lines that scoured things in subdirectories of /var/data/ldm/mcidas.
Since there is already a cron entry for running the McIDAS scour routine,
mcscour.sh, your system should be in no danger of filling the disk.

While I was on foxfire, I took the liberty of doing a couple of
other things:

1) upgraded McIDAS-X to addendum 7.806; this was not necessary to get
   the decoding working, but, what the hey!

2) updated ~ldm/decoders/xcd_run with a needed patch (after making changes
   to xcd_run, I stopped and restarted the LDM)

3) deleted all FSUS* files from /var/data/ldm/mcidas/xdata (these were not
   getting scoured)

4) commented out the ~ldm/etc/pqact.conf entries for filing front analysis
   and forecast files (ASUS* and FSUS*).  McIDAS no longer uses these
   files; it reads the frontal information from the XCD-produced text
   spool files (/var/data/ldm/mcidas/xcd/*.XCD)

As I close, I think that everything is running correctly.  Please let
me know if you see anything amiss.

Tom

>From address@hidden Wed Jul 24 11:53:24 2002

Tom,

I sure feel much better now. Thanks so much.

This was getting quite frustrating, since I invested a lot of time and
didn't see anything wrong. Live and learn, I guess.

Thanks again, Bill

< Bill Fingerhut, Professor           PHONE: 802-626-6257 >
< Meteorology Dept                    FAX:   802-626-9770 >
< Lyndon State College                                    >
< Lyndonville, Vt 05851                                   >
<                                                         >
< EMAIL:     address@hidden                >
<            address@hidden                  >
< WWW:       http://apollo.lsc.vsc.edu/                   >
<                                                         >
< disclaimer: I know nothing - I only work here.          >


pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy