>From: Christian Page <address@hidden> >Organization: Universite du Quebec a Montreal >Keywords: 200106070835.f578Zop28356 McIDAS ADDE servers Christian, >Is it a significant overload for the machines to serve data through ADDE? I >wouldn't want to overload servers just by some ADDE queries. The load will, of course, depend on how many accesses there are. The ADDE access to data is virtually the same as access by routines from a local McIDAS session to LOCAL-DATA. >From address@hidden Mon Jun 11 01:38:10 2001 re: MSFC 10-bit imagery >Is it possible to resample these images with McIDAS so that they could be read >by GEMPAK? Yes. One would IMGCOPY from the original dataset to a desitnation dataset. In the copy process, one chan convert 10-bit oversampled data to 8-bit oversampled or blown-down images. re: serving the data to the Unidata community with ADDE >Would it be possible also to reroute them with IDD? Yes. Since the LDM simply moves products around, you can setup your LDM to move files FTPed from a remote site. >I am mainly interested in >METEOSAT, so I could setup my ADDE server here. The ADDE remote server would only have to be setup on the machine that would be used to serve data to remote machines. Any of your (or other) clients could then access the server. >Since I just installed McIDAS >and that I am just learning it now, I will set that up as soon as I can. OK. >How much load/bandwidth is it to serve data through ADDE? Since ADDE can compress data on the fly while serving it, the load would be less than for the original FTP. Also, one of the attractive features of ADDE image access is loading of the section that the client user wants. This is typically less than the entire image, so this cuts down on the amount in the transfer also. >From address@hidden Mon Jun 11 07:50:32 2001 >I have trouble setting up McIDAS access to some new datasets. I want >these files to be accessed as LOCAL-DATA for local users on the same >machine, and through ADDE for remote users. I would recommend that all non-'mcidas' users access the data through the remote interface, even if they are all running on the same machine. The reason for this is that it limits the setup/configuration for the datasets to one account: 'mcidas'. More on this below. >I have setup the mcidas and >users account, but I can only see the dataset in the mcidas account. >I want to serve these files: >3 [/io/ldm/data/mcidas] (mcidas): ll >total 74112 >-rw-rw-r-- 1 ldm meteo 6321008 Jun 11 05:10 ME7-200106110000.ir1.ara >-rw-rw-r-- 1 ldm meteo 6321008 Jun 11 05:09 ME7-200106110600.ir1.ara >-rw-rw-r-- 1 ldm meteo 6321008 Jun 11 05:09 ME7-200106110600.ir2.ara >-rw-rw-r-- 1 ldm meteo 6321008 Jun 11 05:09 ME7-200106110600.vis.ara >-rw-r--r-- 1 ldm meteo 6321008 Jun 11 08:55 ME7-200106111200.ir1.ara >-rw-r--r-- 1 ldm meteo 6321008 Jun 11 08:55 ME7-200106111200.vis.ara >I have setup the mcidas account like this: >-- >LOCAL.NAM has not been modified OK, good. It does not need to be. >-- >LSSERVE.BAT has been edited to add: >REM >REM METEOSAT-7 >REM >DSSERVE ADD ME7/IR1 AREA TYPE=IMAGE DIRFILE=/io/ldm/data/mcidas/ME7*.ir1.ara >"METEOSAT-7 IR1 >DSSERVE ADD ME7/IR2 AREA TYPE=IMAGE DIRFILE=/io/ldm/data/mcidas/ME7*.ir2.ara >"METEOSAT-7 IR2 >DSSERVE ADD ME7/VIS AREA TYPE=IMAGE DIRFILE=/io/ldm/data/mcidas/ME7*.vis.ara >"METEOSAT-7 VIS Looks good. >-- >I added this line to LOCDATA.BAT > >DATALOC ADD ME7 LOCAL-DATA OK. This was not really needed since the default location for a dataset is LOCAL-DATA. >-- >In McIDAS: I typed: > >REDIRECT REST LOCAL.NAM >REDIRECT MAKE >BATCH "LSSERVE.BAT >BATCH "LOCDATA.BAT Looks good. >-- >The file ~mcidas/data/ADDESITE.TXT >was properly updated since MCTABLE_WRITE was set correctly. Good. >-- >In the user account, I did: > >REDIRECT REST LOCAL.NAM >REDIRECT MAKE > >-- >I modified MYDATA.BAT in ~mcidas/data to add: >DATALOC ADD ME7 LOCAL-DATA > >-- >In the user account, I did then: >BATCH "MYDATA.BAT OK, but this does not define the dataset for the local user. What I mean by this is that there is no information in the user's account to tell McIDAS the mapping between the dataset group/descriptor and the set of files that comprise the set. You did this in the setup for the user 'mcidas' by running BATCH LSSERVE.BAT. Since you did not do this for the user you are setting up, the information needed for the user's account does not exist. I recommend setting up the remote server access to the datasets so that client users do not have to deal with setting up the datasets. When going through the remote server, the user's job is as easy as doing a DATALOC: DATALOC ADD ME7 full_server_or_IP_address To me, this is much easier for the casual user of McIDAS. The setup of the remote server is very easy especially for sites _not_ running NIS/NIS+. The McIDAS side of the setup is done in the 'mcidas' account by virtue of setting up 'mcidas' to be able to access the data. .mcenv has to be created in ~mcidas and mcinet7.7.sh has to be run as root. This setup should take no more than 10 minutes. >------------------------------ >After all that, if I try to display the data in the mcidas account, it >works fine. If I try it in the user account, I get that the directory >server was unable to find the files. > >Any hint? Since there is no setup for the dataset/file relationship in the user's account, there can be no way for the user's account to know how to do this mapping. The information written into the ~mcidas/data/ADDESITE.TXT file are only for dataset location information. To get going you could run BATCH LSSERVE.BAT in each user's account, but it would be much easier to setup the ADDE remote server access once. You could then setup the DATALOC in the 'mcidas' account and all users would automatically have the setup by virtue of their MCTABLE_READ being setup to access the ~mcidas/data/ADDESITE.TXT file. Please let me know if you need assistance. 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.