>From: Angel Li <address@hidden> >Organization: RSMAS/University of Miami >Keywords: 200006061956.e56JuLT23087 McIDAS-X ADDE cron mcbatch.sh mcrun.sh Angel. re: snooping around >I'm going to be running around in and out >of my office all day. I'll try and get back to you if you have any >questions. Do whatever you think is necessary. > >Thanks a bunch, Well, I logged in and started poking around right after receiving the access information. I really didn't do much of anything, but things are apparently working. Here is what I did and some observations: o I noticed that you have the MCDATA directory set to be /s1/ldm/mcidas/data in a wide variety of scripts used by the LDM and cron-scheduled scripts (e.g., xcd_run, batch.k, areapack, dsinfo, etc.) o You have McIDAS environment variables defined in your LDM environmental files, ~ldm/.bashrc and ~ldm/.cshrc. o I notice that you updated your routing table entries for the UW image products to switch to use of the GE-IR.BAT, GE-VIS.BAT, etc BATCH files. I was happy to see this since the 7.7 McIDAS release will not have the IR8.BAT, VIS8.BAT, etc BATCH files included. The recommendations in the Unidata online McIDAS web pages recommend against defining McIDAS "stuff" (McIDAS environment variables MCDATA, MCPATH, etc.) in the LDM environment. One of the main reasons for this is to keep the LDM account "clean" and to help keep the user from shooting him/her self in the foot (McIDAS and the LDM are both complex; it is hard sometimes to keep LDM stuff isolated from McIDAS stuff so that they don't intefere with each other ). It appears, however, that your setup has covered all of the potential pitfalls in doing so. For this reason I will not recommend redoing your setup to strictly follow the online docs. In a previous email concerning ADDEizing your route PP BATCH files, I failed to recommend changing from use of FRONT (which needs to have the frontal information stored in ASUS1* files which can be found through McIDAS REDIRECTions) to FRNTDISP (the ADDE replacement). Since you are now running XCD, your system has the front information available in a way that is easily accessed by ADDE. I took the liberty of editing ~mcidas/data/GE-IR.BAT, etc. and changing 'FRONT OLAY FRAME' to 'FRNTDISP OLAY FRAME'. This is all that is needed to ADDEize. In order to setup the McIDAS account to be able to look at the data being ingested by the LDM, I: o logged in as 'mcidas' o defined McIDAS environment variables in both .cshrc and .bashrc o I copied a number of files from ~ldm/mcidas/data to ~mcidas/workdata: cd workdata cp ~ldm/mcidas/data/LWPATH.NAM . cp ~ldm/mcidas/data/RESOLV.SRV . cp ~ldm/mcidas/data/STRTABLE . I could then crank up a McIDAS session as 'mcidas' and exercise the code and look for potential problems. Since the 'ldm' account has McIDAS environment stuff defined for it, I also ran a McIDAS-X session as 'ldm'. One problem: I found a copy the file Frame1.0 in the ~mcidas/help directory. Files named FrameN.M should be created on a session-by-session basis in subdirectories of the hidden .mctmp directory. There is one file for each frame defined in the user's session. The existence of Frame1.0 (McIDAS frame 1 information (e.g., navigation, etc.)) somewhere other than ~user/.mctmp/nnnnn indicates that something went wrong at some time. The problem with FrameN.M showing up in a directory in the user's MCPATH set of directories is that it will be used instead of the copy created for the current session in ~user/.mctmp/nnnnn. This can cause problems exactly like the one you were seeing (wrong image information for a frame that has an image displayed in it), and it can lead to concurrently running sessions stepping on one another. The latter situation is especially bad for the mini-sessions that get kicked off by ROUTE PostProcess BATCH invocations. I deleted ~mcidas/help/*.0* (there was only Frame1.0), so potential clashes should go away. Right now, I am waiting for new UW image products to come in so I can verify that the ROUTE PostProcess BATCH invocations are working correctly. I can execute the commands in the BATCH files "by hand" from a McIDAS-X session run as the user 'ldm', so I think everything should be OK, but... 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.