>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
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.