20000330: NIDS and NOWrad setup (cont.)

>From: "Karli Lopez (McIDAS)" <address@hidden>
>Organization: University of Puerto Rico
>Keywords: 200002010754.AAA03412 NIDS ADDE server configuration NIDS.CFG execl 
>compress

Karli,

>I attempted to make the changes you outlined however the configuration
>still does not work: I don't see the new images reflected in the
>route.k table (which I know we ARE getting)

If you FILE products using the LDM, there is no updating of the routing
table.  Only products processed by ldm-mcidas decoders like nids2area
will update the McIDAS routing table, ROUTE.SYS.

>and when I go under McIDAS
>and display them I still get the error: 'No NIDS images found in
>dataset RTNIDS/BREF1' for Base reflectivity tilt1, etc. (with the
>command "BKGRUN {imagloop.gui NIDS RTNIDS/BREF1 11 11 FIX
>...." that command is not part of MCGUI is it?)

This says that either the products are not getting filed, or that the
NIDS ADDE server setup is not correct.

>Here is the complete configuration file pqact.conf,  note that the old
>configuration was commented out, and the new one has what I beleive to
>be the correct paths:

(I have deleted all lines that do not relate to the NIDS issue.)

>------------------------------------------------------------------------------
>##
># $Id: pqact.conf,v 1.6 1995/04/05 21:37:54 mitch Exp $

>#
>####                      WSI NIDS radar data products
>#

# ADDE UPDATE TO pqact for NIDS products:
WSI     
^NEX/(.*)/(.*)/([1-2][0-9])([0-9][0-9])([0-1][0-9])([0-3][0-9])([0-2][0-9])([0-6][0-9])
        FILE    /unidata/ldm/data/mcidasd/\1/\2/\2_\3\4\5\6_\7\8

From this pqact.conf action, assuming that the syntax of the entry is
correct (i.e. there are tabs where there should be and the WSI line is
a single line), then you should be able do do a listing of the
/unidata/ldm/data/mcidasd directory and see subdirectores related to
NIDS products:

ls /unidata/ldm/data/mcidasd

>out directory structure saves the radar images in:
>/user2/unidata/data/mcidasd/JUA

So is the entry you sent above correct?  /unidata/ldm must be a link to
/usr2/unidata or visa-versa.

>(such as /user2/unidata/data/mcidasd/JUA/BREF1 for base reflect.

OK, if this is the case, and if there are files in this directory,
then this is enough information to setup NIDS.CFG.

>1)where JUA is the radar dataset for San Juan, PR, and under it are the
>BREF1... PRE1S...  subdirectories but that would've been taken care by
>the /\ID/\TYPE entry in the NIDS.CFG file?
>
>------------------------------------------------------------------------------
>
>DIRMASK=/unidata/ldm/data/mcidasd/\ID/\TYPE/*
>FILEMASK=\TYPE_*
>IPMASK=*
>
>------------------------------------------------------------------------------

Yes, the above entries should find the files if /unidata/ldm is,
in fact, /usr2/unidata.

>I have checked and the files are named for example:
>BREF1_20000330_2205
>
>for example, so the FILEMASK should not be a problem

Right.

I just tried to point at your ADDE server to see if I could list
out any NIDS information.  Here is what I did and what I saw:

DATALOC ADD RTNIDS breeze.uprm.edu
dsinfo.k IMAGE RTNIDS

        Dataset Names of Type: IMAGE in Group: RTNIDS

Name         NumPos   Content
------------ ------   --------------------------------------
BREF1         9999    Base Reflectivity Tilt 1
BREF2         9999    Base Reflectivity Tilt 1
BREF3         9999    Base Reflectivity Tilt 1
BREF4         9999    Base Reflectivity Tilt 1
BRLR1         9999    248 nm Base Reflectifity
CREF          9999    Composite Reflectivity
CREF16        9999    Composite Reflectivity - 16 Level
CREF8         9999    Composite Reflectivity - 8 Level
LREF1         9999    Layer Reflect SFC-24 K ft
LREF2         9999    Layer Reflect 24-33 K ft
LREF3         9999    Layer Reflect 33-60 K ft
PRE1S         9999    1-hour Surface Rainfall
PRE1X         9999    1-hour Surface Rainfall
PRE3S         9999    3-hour Surface Rainfall
PRE3X         9999    3-hour Surface Rainfall
PRETS         9999    Storm Total Rainfall
PRETX         9999    Storm Total Rainfall
SRMV1         9999    Storm-Rel Mean Vel Tilt 1
SRMV2         9999    Storm-Rel Mean Vel Tilt 2
TOPS          9999    Echo Tops
VEL1          9999    Radial Velocity Tilt 1
VEL2          9999    Radial Velocity Tilt 2
VEL3          9999    Radial Velocity Tilt 3
VEL4          9999    Radial Velocity Tilt 4
VIL           9999    Vertical Liquid H2O

DSINFO -- done

This says that the datasets are defined.  Good, this is the first step
in the battle.

imglist.k RTNIDS/BREF1 ID=LIST
Image file directory listing for:RTNIDS/BREF1
imglist.k: error opening configuration file
imglist.k: done

This says that the server can't, for some reason, open the NIDS
configuration file.  The entries defining the datasets get saved in the
file RESOLV.SRV which should be in the ~mcidas/workdata directory.  The
environment configuration file for the ADDE remote server is
~mcidas/.mcenv.  This file should define MCDATA to be the
~mcidas/workdata directory.  Assuming that this is
/home/mcidas/workdata, the entry would look like:

MCDATA=/home/mcidas/workdata

If the home directory for your 'mcidas' user is different from
/home/mcidas, substitute it for /home/mcidas in the MCDATA and other
definitions:

MCPATH=${MCDATA}:/home/mcidas/data:/home/mcidas/help
MCGUI=/home/mcidas/bin
PATH=$MCGUI:$PATH
LD_LIBRARY_PATH=...
export MCDATA MCPATH MCGUI PATH LD_LIBRARY_PATH
cd $MCDATA
etc.

The entries in RESOLV.SRV for elements of the RTNIDS dataset should
have definitions for where the NIDS configuration file is to be found
that look like:

N1=RTNIDS,N2=BREF1,TYPE=IMAGE,RT=N,K=NIDS,R1=1,R2=9999,Q=NIDS.CFG,C=Base Reflect
ivity Tilt 1,

The portion of this line that is important is Q=NIDS.CFG.  The fact
that this is a simple file name and not a fully qualified path means
that the server will look for NIDS.CFG in the directory that is its
current working directory.  The 'cd $MCDATA' line in .mcenv insures
that this is the /home/mcidas/workdata directory.  If this is all
correct for your system, it must mean that NIDS.CFG is not readable by
the ADDE remote server which runs as the user 'mcadde'.

If you give me a login to  your machine as 'mcida', I would be happy to
check to see what is wrong; fix it; and report back to you what I did.

>Also:

re: your ADDE setup not being able to find compress.

>We have those on /usr/bsd/compress which should be in the search path you
>specified below, however when I try to set the 'MCCOMPRESS' environment
>variable, i get an error related to the command (I beleive it stated that
>it couldn't find the compress command).

Right.  That was my impression when I had MCCOMPRESS set and tried to
list out images from your RTIMAGES data set.

>We have no /usr/ucb directory though one could be created if necessary.
>Compress is also found in /usr/bsd

The McIDAS routine doing the 'execl;' of 'compress' tries the following 
fully qualified names in order:

/bin/compress
/usr/ucb/compress
/usr/bin/compress
/usr/bsd/compress

The code in mcserv.cp tries to 'execl' compress in /bin; if that
doesn't work, it tries /usr/ucb; if that doesn't work it then tries
/usr/bin; if that doesn't work it tries /usr/bsd.  Since you say that
compress is located in /usr/bsd on your system, this should work.  The
only thing I can think of is that there is a bad compress in one of the
directories before /usr/bsd, or the copy in /usr/bsd is bad.

Please verify that the version of compress and uncompress in /usr/bsd
are OK and can be executed by your 'mcadde' user.

re: who to contact when your upstream site refuses to feed you

>I'm sorry I should've thought of that first!

Going right to the source should get you going faster than having to
wait for us to respond to your email.

>Thanks for the links to their list of email addresses...

You are welcome.

>As for the request lines, I was talking about some request lines that Robb
>Kambic gave to me to lighten our data load, that way we don't eat up as much
>bandwidth.

OK.

>But I think I  know now what needs to be done.

OK, good.

>Thank you for all of your help.

No problem.

Tom