NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
>From: "Luis A. Lopez" <address@hidden> >Organization: UPRM >Keywords: 200406051652.i55Gq9tK024330 McIDAS NEXRAD Hi Luis, > Can I put all this commands in the mcidas scirpt (mymcrun.sh) so I can >get the information automatically??, Yes. Right off, I can not think of any McIDAS command that can not be put into a shell script and run from cron. As we have talked about in previous emails, the important thing when doing this is to make sure that the environment variables used by McIDAS are properly set. The environment variales that need to be set are called out in the mcrun.sh and mcbatch.sh example scripts: MCHOME - to locate the HOME directory of the user 'mcidas' MCDATA - the directory the script will be CDed to MCPATH - the colon separated list of directories used by - McIDAS routines to locate ancillary data - files (enhancements, color tables, map databases,etc. MCTABLE_READ - a semi-colon separated list of fully qualified pathnames for files that contain information on which ADDE server to contact for which dataset MCTABLE_WRITE - a single fully qualified pathname for a file that contains information on which ADDE server to contact for which dataset PATH - the ~mcidas/bin directory must be part of your PATH in order to find McIDAS executables LD_LIBRARY_PATH - may be needed in certain circumstances, but is generally not needed It seems that MCTABLE_READ and MCTABLE_WRITE are usually the hardest of the needed environment variables to understand. Since the table(s) that specify the ADDE server to contact for specified datasets are maintained by a program, DATALOC, a formalism was developed to specify which file is to be written by DATALOC and which files could be read by McIDAS applications. The reason that there are more than one file to be read is a convenience that allows the McIDAS "super user" 'mcidas' to setup pointing at datasets (this is known as maintaining the client routing table in McIDAS) that can be used by all users at a site. The other files that can be read would be ones that the user sets up for him/herself. MCTABLE_READ is most typically defined as: MCTABLE_READ=${MCTABLE_WRITE};~/mcidas/data/MCTABLE.TXT for all users except 'mcidas'. For 'mcidas', MCTABLE_READ is most typically defined as: MCTABLE_READ=${MCTABLE_WRITE};~workdata/MCTABLE.TXT In the case for the user 'mcidas', this presents a 'gotcha' because MCTABLE_WRITE is typically defined as: MCTABLE_WRITE=/home/mcidas/data/ADDESITE.TXT The 'gotcha' is that the user 'mcidas' runs DATALOC commands that change ~/data/ADDESITE.TXT, but all client routing information contained in ~/workdata/MCTABLE.TXT are used in preference to the information in ~/data/ADDESITE.TXT. The reason that this was setup this way was based on the assumption that the user 'mcidas' should be a McIDAS power user and so realize the dilemma and modify her/his MCTABLE.TXT using an editor if s/he wants to customize the dataset pointing environment for her/himself. Since ~mcidas/data must be included in each McIDAS users MCPATH (requirement!), each user can take advantage of client routing setups made by the user 'mcidas'. I apologize for the long discourse above, but you are getting to the point where you really must understand some of the complexities of McIDAS in order to use it fully, and you have never attended a training workshop where these concepts are taught in detail. >if no, how I can ingest the >NEXRAD datafeed to get this data??. Thank you. You can access the NEXRAD level II data through the ADDE dataset RTNEXRAD. The MCGUI interface to Unidata McIDAS contains a widget that allows you to easily specify who you are asking for the RTNEXRAD data from: - click on the MCGUI button that has two computer monitors stacked on top of each other (just to the right of the button with the red Z) - click on IMAGE - locate the dataset RTNEXRAD and click on the dropdown button in that slot What you will see is a list of cooperating community ADDE data servers that you can get the RTNEXRAD data from. Select any of these except LOCAL-DATA (you would need to be ingesting the data through the LDM and have setup an ADDE dataset to get the data through LOCAL-DATA). After you exit the widget through the Update and Exit button, the client routing table defined in MCTABLE_WRITE will be updated with the name/IP of the server you have selected to get RTNEXRAD data from. By virtue of MCTABLE_WRITE having been defined as /home/mcidas/data/ADDESITE.TXT (I assume you are running things as 'mcidas'), it will be updated. From that point on until you change the pointing for RTNEXRAD data, you will go to that ADDE server for RTNEXRAD data. If the server is up and has been receiving the NEXRAD Level III products, you will get the data you want/need. If the server is not up or has not been ingesting the data, you will need to change who you are pointing at to get the data. Alternately, you can run the LDM and ingest the NEXRAD Level III products. If you do this, you will need to setup an ADDE dataset in the 'mcidas' account on your ingesting machine. After doing this, you can look at the data you received through the LDM/IDD. The nice thing about this is that you can look locally, or, if your LDM was down, etc., you can point to another server in the community for the data. When we first started talking about setting up UPRM, we talked about setting up the LDM. Since I don't see a machine from the UPRM domain reporting real time statistics back to us, I am assuming that you are not running your LDM anymmore. This is OK, but it means that you must look for datasets from remote sites. Please let me know if my overly long reply missed the mark on what you are asking. Cheers, Tom -- NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publically 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.