>From: "Loftus, Maryellen E." <address@hidden> >Organization: TASC >Keywords: 200002012140.OAA27802 Unidata McIDAS-X MCGUI Maryellen, Sorry I didn't answer your original query, but I did not have the time to spend on a decent answer, so I put it off. >We have successfully installed and can access unidata mcidas and ssec >mcidas versions. We defined two .cshrc files for user mcidas: .cshrc_unidata >and .cshrc_ssec. OK, sounds good. >Each user acct must have two data streams /home/username/uni760 and >/home/username/mcidas with the standard subdirs: data, bin and src and two >independent .mcidasrc files: >.mcidasrc_unidata and .mcidasrc_ssec. I wrote two scripts located in >/usr/local/bin, Smcidas >and Umcidas that a user will run depending on which mcidas version they wish >to access. For >example, a user logs on and types Smcidas to run the SSEC version of McIDAS. > > Smcidas: > > #!/bin/csh -f > source /home/mcidas/.cshrc_ssec > cp $HOME/.mcidasrc_ssec $HOME/.mcidasrc > rehash > mcidas OK. There was another way that this could be done. One can specify the name of the resource file to use on McIDAS startup (typically .mcidasrc) on the McIDAS invocation line. Also, the Unidata McIDAS distribution has the shell startup script 'mcidas' renamed to 'mcidasx'. My version of 'mcidas' checks to see if 'config' has been set on the command line (e.g., 'mcidas config'); if it has, a GUI will be popped up that reads ~/.mcidasrc and presents the ability to change certain options. My version of 'mcidas', however, does not allow one to specify a different McIDAS resource file on the command line. >This script sources user mcidas' version specific .cshrc file, .cshrc_ssec; >copies the users' .mcidasrc_ssec file to .mcidasrc in their local dir >(/home/username); rehashes; and starts mcidas. Similary, Umcidas >successfully starts the Unidata mcidas version. OK, sounds good. Does it pass command line arguments to the shell script that it will run to start McIDAS? The question is the following: does 'Umcidas config' result in 'mcidas config' being run? >When setting up the Unidata mcidas as user mcidas, we did not modify >LOCAL.NAM, LSSERVE.BAT or LOCDATA.BAT since we have our own ingestor and >will not be accessing data via the LDM. The idea behind LOCAL.NAM is it serves as a template that a site can modify to match their own setup. >However, this does lead to the >question of setting up the Unidata GUI to "know" where to look for satellite >data, model grids, point data, etc. Right. The MCGUI, not having been ADDEized past a certain point, must be able to find actual McIDAS data files (e.g. AREA, GRID, etc.). The MCGUI also uses SYSKEY.TAB entries to find out what the currently avilable data are. The definitions for which SYSKEY.TAB entries are used is setout in SYSKEY.DOC, a file that is installed in the data subdirectory. Here are some examples from SYSKEY.DOC: 2001 I XXX " UNIDATA: CURRENT ISFC MD FILE NUMBER 2002 I XXX " UNIDATA: CURRENT ISFC HOUR 2003 I XXX " UNIDATA: CURRENT ISFC DAY 2004 I XXX " UNIDATA: CURRENT SYN MD FILE NUMBER 2005 I XXX " UNIDATA: CURRENT SYN HOUR 2006 I XXX " UNIDATA: CURRENT SYN DAY 2007 I XXX " UNIDATA: CURRENT ISHP MD FILE NUMBER 2008 I XXX " UNIDATA: CURRENT ISHP HOUR 2009 I XXX " UNIDATA: CURRENT ISHP DAY 2011 I XXX " UNIDATA: CURRENT IRAB MD FILE NUMBER 2012 I XXX " UNIDATA: CURRENT IRAB HOUR 2013 I XXX " UNIDATA: CURRENT IRAB DAY 2021 I XXX " UNIDATA: CURRENT IRSG MD FILE NUMBER 2022 I XXX " UNIDATA: CURRENT IRSG HOUR 2023 I XXX " UNIDATA: CURRENT IRSG DAY So, to use the MCGUI in your setup, you will have to stuff appropriate values into SYSKEY.TAB locations so that the MCGUI can use them. This means that you will have to have a REDIRECTion for every user that is trying to use the MCGUI to the copy of SYSKEY.TAB that is being stuffed with values. In the Unidata community, this file gets updated by ldm-mcidas and XCD decoders. ldm-mcidas decoders are decoding imagery from a specially prepared broadcast of imagery from SSEC (under contract) and things like NLDN lightning and FSL wind profiler data. Presumably, you are still using the realtime MDXX file numbers for data sets. This would mean, for instance, that ISFC data (SAO/METAR) would go into MD files MDXX0001 - MDXX0010 inclusive; SYN data would go into MD files MDXX, etc. The scheme for use of triplets of SYSKEY.TAB numbers is as follows: MDXX files -> file#, HH, DAY AREA -> beg cyl, end cyl, cur. cyl GRID -> file#, HH, DAY For ISFC data, this might look like: sysval.k LIST 2001 2003 SYSKEY Word Value ----------- ----------- 2001 = 2 2002 = 22 2003 = 2000032 sysval.k: Done For GOES-8 VIS imagery, this would look like: sysval.k LIST 2146 2148 SYSKEY Word Value ----------- ----------- 2146 = 140 2147 = 149 2148 = 145 sysval.k: Done etc. The full list of SYSKEY.TAB entries used by the Unidata McIDAS MCGUI and Fkey menu systems is presented in the file PRODUCT.DAT. This file gets installed in the data subdirectory. It looks like: McIDAS Product Codes and System Key Table entries used for Menu System -------+--------+------------------------------------+--------------------- Code Type Description SYSKEY.TAB words used -------+--------+------------------------------------+--------------------- CI AREA GOES-8/9 Infrared Composite 2161 2162 2163 CV AREA GOES-8/9 Visible Composite 2164 2165 2166 CW AREA GOES-8/9 Water Vapor Composite 2167 2168 2169 LD MD NLDN Lightning 2051 2052 2053 MA MD Hourly surface MD 2001 2002 2003 N1 AREA GOES-8 IR/Topography composite 2125 2126 2127 N2 AREA GOES-8 VIS/Topography composite 2128 2129 2130 N3 AREA GOES-9 IR/Topography composite 2131 2132 2133 N4 AREA GOES-9 VIS/Topography composite 2134 2135 2136 ... From this abbreviated list, you can see that the SYSKEY.TAB entries needed for ISFC data are 2001, 2002, and 2003. The other thing about MCGUI is that the realtime MD files used are assumed to follow the "standard" McIDAS setup: SCHEMA MD #s SYSKEY.TAB entries Meaning ---------+---------+-------------------+------------------------------- ISFC 1 - 10 2001 2002 2003 Surface data IRAB 11 - 20 2011 2012 2013 Mandatory level upper air data IRSG 21 - 30 2021 2022 2023 Significant level upper air data ISHP 31 - 40 2007 2008 2009 Ship/buoy data FO14 41 - 50 2037 2038 2039 FOUS14 data SYN 51 - 60 2004 2005 2006 Synoptic data PIRP 61 - 70 2061 2062 2063 Airep/pirep data NLDN 71 - 80 2051 2052 2053 NLDN lightning WPRO 81 - 90 2041 2042 2043 FSL hourly summary wind profiler data WPR6 91 - 100 2044 2045 2046 FSL 6-minute wind profiler data >We already have defined datasets to >access the data on the ingestors. For example, to look at the latest GOES 8 >image, we access EAST/CONUS.-1. Right, but the Unidata MCGUI is not ADDEized for looking at imagery. The Fkey menu is, but it is not flexible. What I mean by this is that we use RTIMAGES as the group for imagery, and have descriptors like GE-VIS for GOES-East VIS, GW-IR for GOES-West 10.7 um IR, etc. >How would I go about configuring the GUI to access our local datasets? You would have to be able to access the McIDAS data files directly, and you would have to stuff appropriate values into SYSKEY.TAB so the menu would know which files to look at. For instance, if your GOES-East 10.7 um images are stored in AREA files 1000 - 1030, then you should stuff 1000 into SYSKEY.TAB location 2143, 1030 into location 2144, and, if you knew which file was the current one, its number into 2145. It turns out, however, that the MCGUI doesn't need the current image cylinder number since the routine that is being used to put up the loop (ALOOP, a Unidata addition to McIDAS), figures that out by itself. >Thanks for any help you can provide. I must explain that the reason that I have not ADDEized my GUI is that ADDE is not done. My users have for years been able to do things in McIDAS that newer ADDE routines still can't. One example of this is plot TADV from surface observations; another is plot cross sections though observational upper air data or GRIDs. When these areas are finished by SSEC, I will be rapidly converting my MCGUI to fully support ADDE access to data. Until then, I will keep supporting non-ADDE routines and non-ADDE ways of accessing data. Please let me know if I can help out in getting the MCGUI to function in your enviornment. The easiest way for this to happen would be to give me a login on one of your machines, but I can understand why you might be hesitant about this approach. >Mary Ellen Loftus >TASC -- MTS >4801 Stonecroft Blvd >Chantilly, VA 20151 >703-633-8300 x4022 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.