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

20040506: McIDAS v2003 build on RedHat 8.0 Linux (cont.)

>From: Eirh-Yu Hsie <address@hidden>
>Organization: Aeronomy Laboratory/NOAA
>Keywords: 200405062128.i46LS7tK012251 McIDAS ADDE setup

Hi Hsie,

>I open port 112 on my open ADDE server (stratus - a SUN sparc station) 
>which is still running v2002.  I switched my linux server (rainbow, a 
>internal ADDE server) from v2002 to v2003.  But I do not feel 
>comfortable with.  If you can, please login rainbow and take a look at 
>it.  Seem to me that the AREA files is not filed correctly (specify in 
>/home/mcidas/linux/workdata/LSSERVE.BAT).  After I feel comfortable with 
>the Linux server, I will switch the SUN Solaris server to v2003.

I guess my notes yesterday were misleading.  The setup needed for
decoding data is a little more complicated than the setup that is
needed for serving that same data through ADDE.  In particular, the
McIDAS-XCD decoders need to be told where to create their output.  This
is done through a set of REDIRECT definitions in the 'mcidas' account.

Since I misled you into believing that the REDIRECTs were not necessary
at all, you ended up having a number of AREA0*, GRID6*, GRID00*,
GRID01*, and MDXX0* files written to /home/mcidas/linux2003/workdata.
The reason they were being written there is that this directory, which
is also accessible as $MCHOME/workdata where MCHOME=/home/mcidas/linux,
is the first writable directory in the MCPATH that is defined in
/home/ldm/decoders/bin/xcd_run.

To correct my not quite full explanation of how things should be setup
to support XCD and ADDE, I did the following:

<as 'mcidas' on rainbow>
cd /home/mcidas/linux/data
cp EXAMPLE.NAM LOCAL.NAM
<edit LOCAL.NAM and set locations for files as /home/mcidas/savedata>
cd /home/mcidas/linux/workdata
redirect.k REST LOCAL.NAM

This sets up the full set of REDIRECTions that are needed for the
XCD decoders.  In order to insure that the new settings are the ones
used by the XCD decoders running under the 'ldm' account, I also
did the following after making the changes above:

<as 'ldm'>
ldmadmin stop
ldmadmin start

Next, on to looking at the ADDE setup on rainbow.

Observations:

- the DIRFILE= pathname regular expression for the CIMSS images uses
  the directory:

  /export/data6/sat/mcidas/sat/SOUNDER

  and its subdirectories.  I do not see this directory structure:

% ls /export/data6/sat/mcidas
ALLOC.WWW  ANTARCTIC  GOES-10  GOES-12  MDR  MOLLWEIDE  NEXRCOMP  RESOLV.SRV  
comp

  Also, the pathname regular expression for the CIMSS/OZONE images is
  different from the others in the set and it does not point to 
  existing images.  To check your entries, I used the pathname specified
  in the DIRFILE= keywords with 'ls'.  A couple of examples:

% ls /export/data6/sat/mcidas/SOUNDER/*/CTP/CTP_*
ls: No match.

% ls /export/data6/sat/mcidas/SOUNDE/*/LI/LI_*
ls: No match.

  Given that there is no /export/data6/sat/mcidas/sat/SOUNDER directory,
  the ADDE serving of the CIMSS images fails.

- the LSSERVE.BAT setup for the NEXRCOMP sets of images 1KN0R-NAT, 2KN1P-NAT,
  4KN1P-NAT, 1KN0R-FLT, 6KN0R-NAT, and 10KRCM-NAT images do point to existing
  images, so ADDE serving of them should be OK

- the LSSERVE.BAT setup for RTIMAGES sets of images work for some descriptors
  but not for others

  Sets that work include: ANTARCTIC, GE-VIS, GE-39, GE-WV, GE-IR, GE-CO2,
                          GW-VIS, GW-39, GW-WV, GW-IR, GW-12, MDR, and
                          MOLL-IR

  Sets that do not work:  EDFLOATER-I, EDFLOATER-II, RESFLOATER, MOLL-WV

  The RESFLOATER is not being broadcast, so its failure is expected, but
  the others are not.  The failures for the Floater images is undoubtedly
  due to the lack of a correct LDM pqact.conf entry.

- the setup in LSSERVE.BAT for the products that are created by ROUTE
  PostProcess BATCH files, GEW-WV, GEW-IR, GEW-VIS, GE-IRTOPO,
  GE-VISTOPO, GW-IRTOPO, GW-VISTOPO, MDRTOPO, MOLL-IRTOPO, GEW-IRTOPO,
  GEW-VISTOPO, should all work now that file REDIRECTions have been
  setup so that the files can be located in /home/mcidas/savedata

- the LSSERVE setup for NEXRAD Level III imagery is fine, but the
  setup of the configuration file, /home/mcidas/linux/workdata/LNEXRAD.CFG
  is not quite correct:

DIRMASK=/wrk/data6/nexrad/\ID/\TYPE
FILEMASK=\TYPE_*.\ID
IPMASK=*

  The directory portion of the pathname regular expression (DIRMASK) is
  OK, but the file name portion of the regular expression is not.
  The files are named things like:  N0R_20040507_0845, so the
  correct FILEMASK value would be:

  FILEMASK=\TYPE_*

  I changed this for you in LNEXRAD.CFG, and the serving of the Level III
  imagery now works.

- the LSSERVE.BAT entries for RTPTSRC descripts work since the REDIRECTion
  definitions

- LSSERVE.BAT entries for RTWXTEXT work

- LSSERVE.BAT entries for TOPO work

- LSSERVE.BAT entries for MYDATA work

>Thank very much for your help.

No worries.

>From address@hidden  Thu May  6 16:37:06 2004

>For your information, the follow steps were done on rainbow:
>
>% cp ~mcidas/mcidas2003/data/SCHEMA ~mcidas/savedata/.
>% chmod 664 ~mcidas/savedata/SCHEMA

Good.

>"RUN" mcidas and enter the following commands:
>
>BATCH SCHEMA.BAT

OK.  But since there was no REDIRECTion for SCHEMA in scope when you ran
this, the update commands did not have any effect.  I reran this to
make sure that SCHEMA was updated.

>BATCH DROUTE.BAT
>  (make sure all the products needed are released:
>    ROUTE REL U7 U8 UD UE)

You could have used the copy of ROUTE.SYS that is included in the
distribution, but this doesn't hurt.

>TE XCDDATA "/home/mcidas/savedata
>BATCH "XCD.BAT
>BATCH "XCDDEC.BAT

Good.

>CIRCUIT LIST
>DECINFO
>DECINFO SET  DMGRID ACTIVE

Very good.

>cp ~/linux/data/DSSERVE.BAT ~/linux/data/LSSERVE.BAT
>   (modify LSSERVE.BAT to reflect the correct directory)

Some entries are incorrect.

>cp ~/linux/workdata/NNEXRAD.CFG ~/linux/workdata/LNEXRAD.CFG
>   (modify LNEXRAD.CFG to reflect the correct directory)

The FILEMASK= value was incorrect (see above).

>BATCH LSSERVE.BAT
>cd ~/linux/workdata
>mv LWPATH.NAM LWPATH.NAM.orig
>cp /home/mcidas/linux2002/workdata/LWPATH.NAM .

So, the set of REDIRECTions defined for your v2002 installation were
incomplete as well.

>If I miss something, please let me know.

You didn't miss any steps except where I misled you.  It would be great
if the XCD decoders could be updated to not have told where to write
their output.  This could have been done by specifying the
/home/mcidas/savedata directory as the first directory in the MCPATH
that is defined in /home/ldm/decoders/bin/xcd_run.  In your case, the
definitions in xcd_run would become:

MCHOME=/home/mcidas/linux
MCDATA=$MCHOME/workdata
MCLOG=/home/ldm/logs/XCD_START.LOG
MCPATH=/home/mcidas/savedata:${MCDATA}:$MCHOME/data:$MCHOME/help

I would not, however, change MCDATA!

One last observation and question:

A number of the ADDE dataset definitions in LSSERVE.BAT reference files
that are being written to diretories by an LDM running on a different
machine.  Given that you are running an LDM on rainbow, this means
that you are serving data that was not produced by the machine that
the server is running on.  This is not a problem, but I just wanted
to make sure that you realize that the setup is non-standard.

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.