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