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

19991003: Installing McIDAS and LDM on Irix 6.5

>From: Erick Lorenz (address@hidden) <address@hidden>
>Organization: UC Davis
>Keywords: 199910011836.MAA28054 McIDAS-X DEX OSF/1 4.0F Tcl


>I have just installed McIDAS, McIDAS-XCD, LDM, & LDM-McIDAS on
>a SGI Origin 200 running Irix 6.5.

Sounds good.

>The McIDAS passes its tests.


>The LDM seems to be receiving McIDAS files from typhoon.atmos.ucla.edu
>according to ldmadmin watch.

OK.  The McIDAS files are the ones in the Unidata-Wisconsin datastream.
The data to be decoded by McIDAS-XCD come in the DDPLUS|IDS and
HRS datastreams.  You will have to remember to request these be fed
to your machine in addition to the MCIDAS feed.

>When I ran ldmadmin start it hung

At this point, I would kill all of the LDM processes (try running
'ldmadmin stop', but kill ones by hand if necessary) and
make sure that  ~ldm/ldmd.pid gets deleted.  If the problem persists,
I will need to get Robb Kambic in on the discussion.

>so I control-C'ed out of it but a ps-ef
>shows the following processes:
>ldm  87859 91940  0 14:59:59 ? 0:00 DMSYN
>ldm  91495 91916  0 14:59:59 ? 0:00 ingetext.k DDS
>ldm  91523 91940  0 14:59:59 ? 0:00 DMRAOB
>ldm  91724 91896  0 14:59:57 ? 0:00 pqexpire
>ldm  91756 91896  0 14:59:57 ? 0:00 pqbinstats
>ldm  91813 91914  0 14:59:59 ? 0:00 ingebin.k HRS
>ldm  91836 91896  0 14:59:57 ? 0:00 pqact
>ldm  91891 91896  0 14:59:57 ? 0:01 rpc.ldmd -q /usr/
>                             local/ldm/data/ldm.pq /usr/local/ldm/etc/ldmd.con
> f
>ldm  91896     1  0 14:59:57 ? 0:00 rpc.ldmd -q /usr/
>                             local/ldm/data/ldm.pq /usr/loc l/ldm/etc/ldmd.con
> f
>ldm  91914 91836  0 14:59:58 ? 0:00 ingebin.k HRS
>ldm  91915 91896  0 14:59:57 ? 0:00 startxcd.k
>ldm  91916 91836  0 14:59:58 ? 0:00 ingetext.k DDS
>ldm  91940 91915  0 14:59:59 ? 0:00 startxcd.k
>ldm  91944 91940  0 14:59:59 ? 0:00 DMSFC
>ldm  91956 91940  0 14:59:59 ? 0:00 DMMISC
>ldm  88385 91961  0 15:00:45 pts/4   0:01 /usr/local/ldm/bin/
>                               pqutil -f ANY -w /usr/local/ldm/data/ldm.pq

OK, this shows that:

o you correctly put the 'exec xcd_run MONITOR' line in ~ldm/etc/ldmd.conf

o the environment settings in the copy of xcd_run that is being run
  most likely has the correct settings for environment variables

>But no data files are accumlating in the directories set aside for them
>       /home/data/mcidas
>       /home/data/xcd
>I suspect that I have missed a key configuration step.

Did you:

o stop the LDM

<login as 'mcidas'>

o verify that 'mcidas's MCDATA, MCPATH, and MCGUI environment variables
  are set correctly

o copy SCHEMA to the XCD output directory and link this copy
  to the MCIDAS output directory (you wouldn't have to do this if
  those directories were the same).  This appears to be
  /home/data/xcd on your system:

  cd data
  cp SCHEMA /home/data/xcd
  cd /home/data/xcd
  ln SCHEMA /home/data/mcidas

o setup REDIRECTions

  cd data
  <edit LOCAL.NAM and setup directories to match your installation
    For this, I recommend that you combine /home/data/mcidas and
    /home/data/xcd, but this is not a big deal>

o cd ~/workdata

o start a McIDAS-X session and:

  TE XCDDATA "/home/data/xcd

  Make sure that you now have several .RAP files in /home/data/xcd.
  If you don't, it probably means that /home/data/xcd was not writable
  by the user 'mcidas'.  If it wasn't, rerun the XCDDEC.BAT BATCH
  file as listed above.

As soon as:

o the LDM is requesting the DDPLUS|IDS and HRS data

o and XCDDEC.BAT has been successfully run as 'mcidas' (proving that
  the REDIRECTions in LOCAL.NAM are correct)

you should start seeing LOTS of files being created by XCD decoders.

>For one thing I am not sure what I should be putting in pqact.conf
>and ldmd.conf.
>In ldmd.conf I have the line
>request MCIDAS ".*" typhoon.atmos.ucla.edu 

If this is the only request line, then all you will be getting is
AREA files.  From the inclusion below, these will be going into
the /home/data/mcidas directory.  You probably want this machine to
get all of the data, so you need to modify your request line to be:

request UNIDATA|FSL2 ".*" typhoon.atmos.ucla.edu

>Because I only want to receive the McIDAS AREA and Gridded data
>on this machine.  Is that correct?

If you only want to receive MCIDAS files, then your original request
line is correct.  The Unidata-Wisconsin feed no longer has GRID files
in it, so this will not get you any gridded data.  To get gridded
data, you will need to request the HRS feed (a part of the UNIDATA
pattern above) and decode the HRS products into McIDAS GRID files
using XCD.

>In pqact.conf I have:
># Entries for XCD decoders
>DDPLUS|IDS      ^.*     PIPE
>        xcd_run DDS
>HRS     ^.*     PIPE
>        xcd_run HRS
>####           Unidata-Wisconsin channel image (AREA) files
>        PIPE    -close
>        lwtoa3 -d /home/data/mcidas -v -l /usr/local/ldm/logs/mcidas.log -xv

The entry for XCD decoders is correct, but it won't do anything until
you get DDPLUS, IDS, and HRS data.  You have to request to be fed this
data in ldmd.conf.

>I put in DDPLUS|IDS and HRS because the guide said to and the MCIDAS
>LWTOA3 because that one is working on our obsolete system.  I couldn't
>find any other examples to follow.  I do want to get the data that
>used to come in GUNRV2, LWFILE, LWTMD2.

That data was removed from the Unidata-Wisconsin datastream on
July 1 of this year.  The only way to get conventional (e.g. MDXX)
and gridded (e.g. GRID) data is by running XCD.

>If you can't find anything obvious in what I have described, can
>I arrainge for a phone conference in the near furture or perhaps
>I could give you a password to ATM12 to inspect what I have done.

The access to the machine will be helpful.  I will be back in the office
tomorrow afternoon and will try to help you out.


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.