20000216: McIDAS ADDE questions

>From: address@hidden
>Organization: University of Kansas
>Keywords: 200002161634.JAA00534 McIDAS-X ADDE

Donna,

>We have not previously used the ADDE server.  We have been converting
>all our NIDS data to McIdas AREA files.  I gather that the main
>purpose of the ADDE is that we could use the native WSI product
>and would not have to waste disk space with the AREA files.  Is
>that the main idea?

No, not at all.  ADDE gives McIDAS users transparent access to named
datasets that are accessible either locally or over TCP/IP ethernet.

As an example of the power of ADDE, try the following:

<login and start a McIDAS-X session>
DATALOC LIST
DATALOC ADD RTIMAGES ADDE.UNIDATA.UCAR.EDU
DSINFO IMAGE RTIMAGES
IMGLIST RTIMAGES/GW-IR.ALL
IMGDISP RTIMAGES/GW-IR LATLON=40 95 REFRESH='EG;MAP X 5 COUNTY=ALL ST=KS;MAP H 
1 WID=2' MAG=2

This sequence:

o asks for where the session will look for defined datasets
o tells McIDAS to look for elements of the RTIMAGES on the Unidata ADDE
  server, ADDE.UNIDATA.UCAR.EDU (not an operational machine)
o interrogates the server on ADDE.UNIDATA.UCAR.EDU and asks for the 
  elements of the dataset that are of type IMAGE
o asks for a listing of all images in the RTIMAGES/GW-IR dataset/group
o loads the latest image from the RTIMAGES/GW-IR dataset/group into
  the current frame centered on 40N 95W blown up by a factor of 2
  and overlaid with maps that include county outlines for Kansas

After trying this, please do the following:

DATALOC ADD RTIMAGES LOCAL-DATA

or if the initial DATALOC LIST specified a machine name for RTIMAGES

DATALOC ADD RTIMAGES <whatever the machine specifed above was>

ADDE will allow McIDAS users to act as each other's realtime data backup
sites.  If your LDM was down so you didn't get any imagery (or point
source, grid, or textual data), a cooperating site will allow you to
point at their machine and access the data off of it until you are back
up.  The ADDE used in this way is a nice compliment to the LDM push
method of data distribution.

>I have noticed under our present system that
>displaying NIDS data with the Unidata McIdas Menu is VERY slow.

This is a little suprising.  The way you say this seems to indicate that
displaying the NIDS data is slower than displaying other imagery data.
Is this the case?  If so, then there is some sort of a setup problem
on your system(s).

>Is that because we are not using ADDE and to speed it up we would
>need to use ADDE?  Or does it point to some other problem?

I would say that it points to something else.

As you discerned correctly in your original surmise, use of ADDE access
to NIDS data will allow you to stop converting the imagery into McIDAS
AREA format upon its receipt.  The structure of my NIDS and NOWrad (tm)
ADDE servers allows sites using both GEMPAK and McIDAS to store the
data in the directory structure most useful to GEMPAK/GARP/NMAP.  The
ADDE servers know how to access the data in their native format and
provide the data back to McIDAS ADDE applications as if it came from
AREA files.

The setup for the NIDS and NOWrad ADDE servers is described in:

Configuring Unidata NIDS and NOWrad ADDE Servers
http://www.unidata.ucar.edu/packages/mcidas/mcx/config_upcadde.html

Please let me know if I can help you get setup to start using the ADDE
for what it is intended.

Tom Yoksas