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

20021119: Corrupt ROUTE.SYS and ROUTE PostProcess BATCH files (cont.)

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20021119: Corrupt ROUTE.SYS and ROUTE PostProcess BATCH files (cont.)
  • Date: Tue, 19 Nov 2002 18:21:47 -0700
>From: Angel Li <address@hidden>
>Organization: U Miami/RSMAS
>Keywords: 200211150406.gAF46PL16731 McIDAS ROUTE.SYS

Angel,

It just dawned on me that part of what you are doing in your PostProcess
BATCH files is drawing a front on top of composite images.  This will
still be broken as XCD decoding is not working.  This means that we will
have to address the XCD decoding issues before everything is working
like it used to be.

Tom

------- Forwarded Message

>To: Angel Li <address@hidden>
>cc: address@hidden
>From: Unidata Support <address@hidden>
>Subject: 20021119: Corrupt ROUTE.SYS and ROUTE PostProcess BATCH files (cont.) 
>Organization: UCAR/Unidata

>From: Angel Li <address@hidden>
>Organization: U Miami/RSMAS
>Keywords: 200211150406.gAF46PL16731 McIDAS ROUTE.SYS

Angel,

re: making changes on sapodilla

>Go ahead, I'll deal with any consequences after the fact. We have some 
>scripts that use IMGCOPY to get data from Wisconsin but they are pretty 
>much localized.

After I saw this message, I decided to take a hard look at the other
scripts you are running.  They appear to be dependent on McIDAS environment
variable definitions that you put in ~ldm/.cshrc -- I was not expecting
this since I recommend to not do things this way.

The more I looked, the more worried I got that I would severely break
stuff while making changes on your machine.  So, I dug in and found out
why your present setup is not working.  What I found was:

o you are running McIDAS PostProcess BATCH scripts from ~ldm/decoders/batch.k
  as expected, but this copy of batch.k has been setup so that the McIDAS
  workdata directory (MCDATA) is /ldm/mcidas/data.  I recommend that
  sites use the McIDAS installation 'workdata' directory for this:

  MCDATA=/mcidas/workdata

o the set of REDIRECTions defined in /ldm/mcidas/data/LWPATH.NAM left out
  the location of ROUTE.SYS.  No PostProcess BATCH files
  were getting executed upon decode of imagery since the decoder (pnga2area)
  didn't know it was supposed to run PostProcess BATCH files.

  After I added the location of ROUTE.SYS to /ldm/mcidas/data/LWPATH.NAM,
  the PostProcess BATCH files began working: the composite AREAs are
  showing up in /ldm/data/mcidasd, and GIF (tm) files are once again
  being created.

o apparently, up until a few days ago, you had McIDAS-XCD decoders creating
  output in /ldm/data/mcidas.  These decoders are still running, but they
  are not now producing any output.

The net affect of the changes I made this evening were small:

o modify LWPATH.NAM in /ldm/mcidas/data   <- to include location of ROUTE.SYS

o modify LWPATH.NAM in /mcidas/workdata   <- to have entries for all AREA
                                             files decoded from the MCIDAS
                                             feed and created by ROUTE
                                             PostProcesses

o delete old XCD-related files in /ldm/mcidas/data <- these were not being
                                             updated or used, so they could go

Questions:

o do you want McIDAS-XCD decoders to work

o would you be against combining the contents of the /ldm/data/mcidasd
  and /ldm/mcidas/data directories

o would you be against my changing the setup that runs the decoding and
  PostProcess BATCH files to use setups in the 'mcidas' account instead
  of using setups in the 'ldm' account

o would you be opposed to moving the scripts being used to IMGCOPY
  imagery from SSEC to the 'mcidas' account.  Is there any reason that
  these scripts are being run from the 'ldm' account and not the
  'mcidas' account?  It would be cleaner to move them to the 'mcidas'
  account totally.

If given free reign, yy goal would be to clean up the 'ldm' account by
removing all McIDAS definitions in it.  I find that it is easier to
keep all McIDAS-related activities isolated in the 'mcidas' account.

In order to really clean-up the 'ldm' account, I would need to fully
understand the scripts that IMGCOPY image data from SSEC and, most
likely, modify all of them, or a top level one if they are all run from
a main script (there does appear to be such a main script:
/s3/ldm/wallops/upd-all).  If I were to move the IMGCOPY scripts
to the 'mcidas' account, I would need to do this in conjunction with
you.

Tom


------- End of Forwarded Message