>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
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.