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

20030321: setting up a new McIDAS machine at St. Cloud State

>From: "Anderson, Alan C. " <address@hidden>
>Organization: St. Cloud State
>Keywords: 200303181640.h2IGeXB2004042 McIDAS-X install configure

Hi Alan,

>Yes, waldo's clock is set to run GMT.   Not sure if that is 
>a disadvantage,

No, but it is not how most folks set their clocks.

>I think I made this choice since all the 
>met products are in GMT and thought it might avoid confusion
>when questions of time arose.

Makes sense.

>Regarding the new terminal,  after our last exchange about 
>the testing phase (disregard the failure to draw a map over 
>the topo image),  I did the install.
>Seemed to go ok,  lots of screens with  "installing ....,but
>when it finished the last line was :
>       fatal error: don't know how to make target 'mcxall'

I have never gotten this error.  What was the exact 'make' invocation
you used?

>Not sure what this means,  but:
>MCIDAS  started ok.  I  just typed mcidas,  saw that it 
>started, and then did an exit.  Did not try and run any 


>Went on and installed the MCIDAS2002 ADDE server as per web 
>directions.   I am currently working on 'configuring the mcidas
>user account'.  
>Will work a bit more on that today.  What is your interpretation
>of the install message  listed above.  

It is hard to tell not knowing the exact make invocation you used.

>From address@hidden Fri Mar 21 12:22:52 2003

>Some more notes regarding MCIDAS install on new terminal (cyclone)

>As noted in my earlier message of this morning, I continued with the
>configuration directions for the user mcidas.   No problems here.
>I decided to use a copy of waldo's LOCDATA.BAT file to save time.
>I know I need to use the more complete version of this that came
>with the distrib.  as it recognizes some new datasets.


>Will edit
>this a bit later.  Remaining steps all ran with no error messages.

>Also, to back up one or two steps,  when I created LOCAL.NAM,  I left
>it as it was sent.   i.e.  most files to /var/data/mcidas,  but the XCD
>stuff to /var/data/xcd.   This is different from waldo, but seems a minor
>difference.  It will just separate the data types into different

You are correct, it is a minor difference.  The only reason this file
specifies two different directories is historic.  Some time ago, before
we started distributing McIDAS-XCD, McIDAS users got their MDXX and
GRID files through the Unidata-Wisconsin broadcast.  When XCD was first
released, there was a potential conflict between the MD and GRID files
in the broadcast and the ones that would be created by XCD.  It was for
this reason that I separated the XCD created files into a separate
directory.  Since there are no longer any broadcast MDXX or GRID files,
it makes more sense to keep all McIDAS files in a single directory like

>Our students all use MCIDAS with a generic user name,  so I created
>this account on cyclone as well,  even though students will not use
>this terminal.    The configuration tasks went smoothly,  I have set
>everything as listed on the MCIDAS web page (e.g. home directories,

>When I got to the part of the config. tasks for a user,  and ran the
>command Batch "LSSERVE.Bat,  it seemed to run ok,  finished with DSSERVE:done
>then a line
>String not found XCDDATA
>Batch: Batch job abandon   /home/mcidas/data

Two things here.  The entries in LSSERVE.BAT create the definitions for
datasets by specifying the association between the ADDE dataset name
(group/descriptor) and the files that compose that dataset.  If a site
has a machine setup so that users can access its McIDAS datasets
thourgh the remote ADDE server, then all they have to do is specify
where to look for the datasets, not what composes them.  It is _much_
easier to have simple user accounts "point" at a remote ADDE server
than to have to have access to the data files that compose the datasets
AND define the association between a dataset name and the files that it
contains.  It is for this reason that I recommend that everyone setup a
remote ADDE server on the machine that runs the LDM and XCD decoders.
By doing this, all users other than 'mcidas' only have to specify
DATALOCs to access the data.

As far as the string XCDDATA, it is used in LSSERVE.BAT (a modifiable
clone of the DSSERVE.BAT file in the distribution) to specify the
location of the TEXT files produced by XCD (the TEXT files are
the *.IDX, *.XCD, *.RAP, and *.RAT files).  This is one more reason
to setup the ADDE remote server: if the average user simply has
to specify access to a dataset as something as simple as:

DATALOC ADD RTIMAGES cyclone.stcloudstate.edu
DATALOC ADD RTPTSRC  cyclone.stcloudstate.edu
DATALOC ADD RTWXTEXT cyclone.stcloudstate.edu

things are a lot easier for them.  Plus, if you setup the 'mcidas'
account according to recommendations in the online docuemntation,
and setup the user accounts definition for MCTABLE_READ, then
the average user doesn't have to do anything at all.  The reason?
MCTABLE_READ specifies a semicolon list of fully qualified names
of DATALOC files to use when looking for datasets.  One of the
tasks assigned to 'mcidas' for McIDAS setup is the creation of
the file ADDESITE.TXT which contains a list of DATALOCs.  This
file is specified as the second file name in each user's MCTABLE_READ
so that it will be searched if they havn't created their own file
of DATALOCations.  For instance:


says to McIDAS routines to firsyt look in /home/mcidas/workdata/MCTABLE.TXT
to find out which remote ADDE server to contact for any ADDE dataset
access.  If this file does not contain the location for the dataset
specified, then /home/mcidas/data/ADDESITE.TXT is searched.  So,
'mcidas' creating /home/mcidas/data/ADDESITE.TXT will setup each
user's access to McIDAS datasets as long as the setup in the 'mcidas'
account was done correctly.

>I recall that when configuring the user mcidas account,  I needed to run
>the command  TE  XCDATTA   "directory for XCD data files
>I had done that,  wonder whether it needs to be done for all users?

Please see above.

>I did not do this as user student,  will wait for your reply.

Please let me know if the outline above doesn't answer your questions
about the need for setting up dataset definitions for each non-mcidas

>After reaching this point,  I was able to start MCIDAS and create an IR
>image, also a temp. plot.  so it seems to work.

Very good.

>Any comments or suggestions ?

Looks like you are doing fine.  Please let me know if the discussion
above was not clear enough.


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.