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