>From: Jim Heimbach <address@hidden> >Organization: UNCA >Keywords: 199905141945.NAA27523 McIDAS-X ADDE Jim, > Things are progressing with the installation of McIDAS-X on >a linux box (running Slackware's flavor). I am having trouble >with squaring away f2c, but I think that will be solved shortly. What exactly do you mean by "squaring away f2c"? Is it not bundled with Slackware Linux? >My question is, what is ADDE? I prowled around the e-mail archives >and the web pages, and remain clueless. From what little I find, >it appears that this will be replacing McIDAS-X ? Anyway, >could you explain what ADDE is and if I should install it whatever >it is? ADDE stands for Abstract Data Distribution Environment. It is the method by which McIDAS applications request data from one or more servers. ADDE _is_ McIDAS-X; it is not separate. What is going on is that old McIDAS applications are being replaced by newer ADDE applications. This has been going on since the introduction of McIDAS-X Version 7.0. The Unidata distribution of McIDAS-X still contains a number of the non-ADDE routines that have already been sunsetted (i.e. support dropped for) by SSEC. In the ADDE way of doing things, one requests data from data sets. The end user does not have to remember the arcane naming convention that McIDAS uses for files. Here is a very quick comparison between an old way of doing things and an ADDE way of doing things: non-ADDE load of a GOES-West IR image centered on 30 N and 130 W: DF 130 1 EC 30 130 -2 EU=IMAGE SF=YES ADDE load of the same image which can be found in the dataset RTIMAGES/GW-IR: IMGDISP RTIMAGES/GW-IR 1 LATLON=30 130 MAG=-2 EU=IMAGE SF=YES So, you may ask how/why this paradigm shift is beneficial to the user: o first, the user does not have to know that GOES-West IR imagery is stored AREA files 130-139 (for example); s/he only has to know that there is a dataset named RTIMAGES that has a member called GW-IR that contains GOES-West IR images. o the ADDE invocation as listed above automatically chooses the latest of the set of GOES-West IR images; in the non-ADDE example, you would have to look at a listing of the images to find out which AREA file contained the latest image (or you would have to use ALOOP which does the work for you) o the RTIMAGES dataset does _not_ have to exist on your machine or on any machine on your local area network The last item is the big win item. One can "point" at another user's machine (that s/he is allowed to point at) and get data loaded from the remote machine. For instance, I can sit here in Boulder and "point" to a machine at UVa and load imagery: DATALOC ADD RTIMAGES windfall.evsc.virginia.edu DSINFO IMAGE RTIMAGES IMGLIST RTIMAGES/GW-IR.ALL IMGDISP RTIMAGES/GW-IR 1 LATLON=30 130 MAG=-2 EU=IMAGE SF=YES The DATALOC command tells McIDAS that when a user tries to access the RTIMAGES dataset it actually lives on a machine named windfall.evsc.virginia.edu. If that machine is running the ADDE Remote Server (something that you should setup; the information is in the online documentation), and if your machine is enabled to request the data (raw remote ADDE installations prevent nobody from asking for data), then when a request is made, the information comes from the remote machine. The DSINFO command asks the question of what data of type IMAGE are included in the RTIMAGES dataset. From the output of DSINFO, you will see what kinds of products are available. If the remote machine is setup as per Unidata instructions, you will find images of type GW-IR. The IMGLIST command (the ADDE parallel for the LA command) will then list information about the images in the remote dataset. The IMGDISP command then says to display the latest image in the RTIMAGES dataset in frame #1. The very cool thing about this is that you can get data from other sites when you machine missed files. This is what I call a distributed, ad hoc, short term data archive facility. Cooperating users can act as a safety net for each other in a transparent manner. At the present time, there are over 15 sites running remote ADDE servers that one could get data from. Etiquette demands, of course, that sites request access to other users machines _before_ "pointing" to them for data. To get more of a flavor of the difference between ADDE routines and old, non-ADDE routines, please look through our online Learning Guide: http://www.unidata.ucar.edu/packages/mcidas/mclearn/learn_guide.html By the way, we are holding a McIDAS training workshop at the end of July/ beginning of August :-) Talk to you later... 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.