[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20010611: MCIDAS ADDE server access (cont.)



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