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

20040616: Mcidas question (cont.)



>From: "Luis A. Lopez" <address@hidden>
>Organization: UPRM
>Keywords: 200406051652.i55Gq9tK024330 McIDAS NEXRAD

Hi Luis,

>    Can I put all this commands in the mcidas scirpt (mymcrun.sh) so I can
>get the information automatically??,

Yes. Right off, I can not think of any McIDAS command that can
not be put into a shell script and run from cron.  As we have talked
about in previous emails, the important thing when doing this
is to make sure that the environment variables used by McIDAS
are properly set.  The environment variales that need to be
set are called out in the mcrun.sh and mcbatch.sh example scripts:

MCHOME          - to locate the HOME directory of the user 'mcidas'
MCDATA          - the directory the script will be CDed to
MCPATH          - the colon separated list of directories used by
                - McIDAS routines to locate ancillary data
                - files (enhancements, color tables, map databases,etc.
MCTABLE_READ    - a semi-colon separated list of fully qualified
                  pathnames for files that contain information
                  on which ADDE server to contact for which dataset
MCTABLE_WRITE   - a single fully qualified pathname for a file
                  that contains information on which ADDE server to
                  contact for which dataset
PATH            - the ~mcidas/bin directory must be part of your PATH
                  in order to find McIDAS executables
LD_LIBRARY_PATH - may be needed in certain circumstances, but is generally
                  not needed

It seems that MCTABLE_READ and MCTABLE_WRITE are usually the hardest of
the needed environment variables to understand.  Since the table(s)
that specify the ADDE server to contact for specified datasets are
maintained by a program, DATALOC, a formalism was developed to specify
which file is to be written by DATALOC and which files could be read by
McIDAS applications.  The reason that there are more than one file to
be read is a convenience that allows the McIDAS "super user" 'mcidas'
to setup pointing at datasets (this is known as maintaining the client
routing table in McIDAS) that can be used by all users at a site.  The
other files that can be read would be ones that the user sets up for
him/herself.  MCTABLE_READ is most typically defined as:

MCTABLE_READ=${MCTABLE_WRITE};~/mcidas/data/MCTABLE.TXT

for all users except 'mcidas'.  For 'mcidas', MCTABLE_READ is most
typically defined as:

MCTABLE_READ=${MCTABLE_WRITE};~workdata/MCTABLE.TXT

In the case for the user 'mcidas', this presents a 'gotcha' because
MCTABLE_WRITE is typically defined as:

MCTABLE_WRITE=/home/mcidas/data/ADDESITE.TXT

The 'gotcha' is that the user 'mcidas' runs DATALOC commands that
change ~/data/ADDESITE.TXT, but all client routing information
contained in ~/workdata/MCTABLE.TXT are used in preference to the
information in ~/data/ADDESITE.TXT.  The reason that this was setup
this way was based on the assumption that the user 'mcidas' should be a
McIDAS power user and so realize the dilemma and modify her/his
MCTABLE.TXT using an editor if s/he wants to customize the dataset
pointing environment for her/himself.  Since ~mcidas/data must be
included in each McIDAS users MCPATH (requirement!), each user can take
advantage of client routing setups made by the user 'mcidas'.

I apologize for the long discourse above, but you are getting to
the point where you really must understand some of the complexities
of McIDAS in order to use it fully, and you have never attended
a training workshop where these concepts are taught in detail.

>if no, how I can ingest the
>NEXRAD datafeed to get this data??.  Thank you.

You can access the NEXRAD level II data through the ADDE dataset
RTNEXRAD.  The MCGUI interface to Unidata McIDAS contains a widget
that allows you to easily specify who you are asking for the
RTNEXRAD data from:

- click on the MCGUI button that has two computer monitors
  stacked on top of each other (just to the right of the
  button with the red Z)

- click on IMAGE

- locate the dataset RTNEXRAD and click on the dropdown button
  in that slot

What you will see is a list of cooperating community ADDE data servers
that you can get the RTNEXRAD data from.  Select any of these except
LOCAL-DATA (you would need to be ingesting the data through the LDM and
have setup an ADDE dataset to get the data through LOCAL-DATA).  After
you exit the widget through the Update and Exit button, the client
routing table defined in MCTABLE_WRITE will be updated with the name/IP
of the server you have selected to get RTNEXRAD data from.  By virtue
of MCTABLE_WRITE having been defined as /home/mcidas/data/ADDESITE.TXT
(I assume you are running things as 'mcidas'), it will be updated.
From that point on until you change the pointing for RTNEXRAD data, you
will go to that ADDE server for RTNEXRAD data.  If the server is up and
has been receiving the NEXRAD Level III products, you will get the data
you want/need.  If the server is not up or has not been ingesting the
data, you will need to change who you are pointing at to get the data.

Alternately, you can run the LDM and ingest the NEXRAD Level III
products.  If you do this, you will need to setup an ADDE dataset in
the 'mcidas' account on your ingesting machine.  After doing this, you
can look at the data you received through the LDM/IDD.  The nice thing
about this is that you can look locally, or, if your LDM was down,
etc., you can point to another server in the community for the data.

When we first started talking about setting up UPRM, we talked about
setting up the LDM.  Since I don't see a machine from the UPRM
domain reporting real time statistics back to us, I am assuming
that you are not running your LDM anymmore.  This is OK, but it
means that you must look for datasets from remote sites.

Please let me know if my overly long reply missed the mark on
what you are asking.

Cheers,

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically 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.