20000823: Current Setup at University of Puerto Rico (cont.)

>From: McIDAS <address@hidden>
>Organization: University of Puerto Rico
>Keywords: 200008111642.e7BGgYN02913 McIDAS-X scripting

Karli,

re: But, you should still try to get someone to check out your networking
problems

>Apparently we will have someone look at our setup and our needs sometime
>tommorrow!

Excellent.  I hope that the news will be good.

re: receiving NIDS data
>Good! And our routing table and correspoding files confirm this,

I should point out that when the conversion of the NIDS products into
McIDAS AREAs is turned off, the routing table listings for the NIDS
products will no longer be updated.

>however
>I still can't see them through McIDAS!  The f-key menu give sthe same
>error while the command you gave me returns the following error (Ihad to
>substitute STA=JUA for it's LATLON coords):
>---------------------------------------------------------------
>IMGDISP RTNIDS/BREF LATLON=18:00 67:00 EU=BREF REFRESH='EG;MAP H'
>IMGDISP: Image data server unable to resolve this dataset: RTNIDS/BREF
>IMGDISP: done

Hmm... The command should be:

IMGDISP RTNIDS/BREF1 LATLON=18:00 67:00 EU=BREF REFRESH='EG;MAP H'

BREF1, not BREF

To see what groups are available in your dataset, you use DSINFO:

DSINFO 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

The 'Name' is the group name in the dataset.  So, you can substitute
in any of these into the above command and see the results.  For example,

IMGDISP RTNIDS/VEL1 LATLON=18:00 67:00 EU=VEL REFRESH='EG;MAP H'

Now, let's get back to your comment that you had to substitute the
LATLON for STA for JUA.

I just tried the following from the 'mcidas' account on breeze, and it
returned a blank:

mcidas@breeze 9% msl.k JUA
 IDN   ID    STATION NAME         DATA TYPES       ST CO  LAT    LON     ELEV
msl.k: DONE

This tells me that your MASTERID.DAT file did not contain information for
JUA.  Aha!  I am using Version 7.7 here at Unidata (as I prepare it
for release), and even 7.7's IDMSL does not have JUA defined.  The new
station database in 7.7, on the other hand does have it defined.  This
is the problem after all!  Until I can release 7.7 and you have had
a chance to download and install it, you will have to do loads using
one of the other stations on the island.  Here is how to find this out:

MSL CO=PU
 IDN   ID    STATION NAME         DATA TYPES       ST CO  LAT    LON     ELEV
785140 TJBQ  AQUADILLA/BORINQUEN       T  A           PU  18:30N 067:08W 72
785145 TJMZ  MAYAGUEZ/EUGENIO          T  A           PU  18:16N 067:09W 9
785203 TJPS  PONCE/MERCEDITA           T  A           PU  18:01N 066:34W 9
785260       SAN JUAN INTL ARPT  IMN    RPA           PU  18:26N 066:00W 19
785263 TJSJ  LUIS MUNOZ MARIN        F T  A D         PU  18:27N 066:00W 3
785350 TJNR  ROOSEVELT ROADS NAS IM    T  A           PU  18:15N 065:38W 12
785205 X69   PLAYA PORT PONCE                         PU  17:58N 066:37W 3
785263 SJU   LUIS MUNOZ MARIN               D         PU  18:27N 066:00W 3
785355 X93   CAPE SAN JUAN(CGLS)                      PU  18:23N 065:37W 22
785356 X92   POINT TUNA (CGLS)                        PU  17:59N 065:53W 22
msl.k: DONE

So, the following should work:

IMGDISP RTNIDS/BREF1 STA=TJSJ EU=BREF REFRESH='EG;MAP H'

>---------------------------------------------------------------
>and RTNIDS is reading from the right place:
>---------------------------------------------------------------
>DATALOC LIST
>        
>Group Name                    Server IP Address
>------------------------------------------------------------                
>BLIZZARD                      ADDE.UNIDATA.UCAR.EDU
>MYDATA                        <LOCAL-DATA>
>PLANET                        <LOCAL-DATA>
>RTGINI                        ADDE.UCAR.EDU
>RTGRIDS                       BREEZE.UPRM.EDU
>RTIMAGES                      BREEZE.UPRM.EDU
>RTNIDS                        BREEZE.UPRM.EDU
>RTPTSRC                       BREEZE.UPRM.EDU
>RTWXTEXT                      BREEZE.UPRM.EDU
>TOPO                          <LOCAL-DATA>
>                                                                              
>        
><LOCAL-DATA> indicates that data will be accessed from the local data
>directory.     
>DATALOC -- done

OK.

>---------------------------------------------------------------
> so that means I still can't access the data Subset.

Please retry the commands above.

re: I further propose to turn off converting of the NIDS products to McIDAS
AREA files

>Ok... and by doing this the only system that's affected by this is the
>MCGUI graphical interface, right?

Three things:

o the MCGUI
o you being able to run commands like DF, and ALOOP from the command
  line.  DF and ALOOP (there are others) are non-ADDE commands that
  are going away _soon_.  There replacement is IMGDISP, so you might
  as well get comfortable with using it.
o the routing table will no longer be updated.  To see what images
  you have, you will have to run IMGLIST:

  IMGLIST RTNIDS/BREF1.ALL

>I have a question then: what does the
>MCGUI environment variable points to then?

This environment variable is really misnamed (my fault, I should have
named it MCBIN).  It should be set to point to the 'bin' directory of
the user account under which McIDAS-X is installed (e.g.,
~mcidas/bin).

>I just found out I could do
>shell scripts that used ADDE without it and was curious.

Right.  The only real environment variables that the McIDAS code is
concerned about are MCPATH, MCTABLE_READ, and MCTABLE_WRITE.  I have
users define MCDATA to reinforce the concept that this should be the
first directory in MCPATH:

<user that is NOT 'mcidas'>

MCHOME=/unidata/mcidas
MCDATA=$HOME/mcidas/data
MCPATH=${MCDATA}:$MCHOME/data:$MCHOME/help

<user 'mcidas'>

MCHOME=/unidata/mcidas
MCDATA=$MCHOME/workdata
MCPATH=${MCDATA}:$MCHOME/data:$MCHOME/help

re: SANU is actually in South America

>Oh that explains it.  I see more or less now where SANU could be.

OK.

re: FRNTDISP working one day and not the next

>Oh I see ... it works fine now.. I guess that's yet another victim of
>the bandwidth gnomes... pity.

Exactly, it is a pity.  It seems to me that Puerto Rico should have
much better network connectivity that it appears to.  The other day,
our traceroutes showed that packets got to the island pretty quickly
and then really slowed down.  Today, the picture is not as clear:

%traceroute breeze.uprm.edu
trying to get source for breeze.uprm.edu
source should be 128.117.140.80
traceroute to breeze.uprm.edu (136.145.165.17) from 128.117.140.80 
(128.117.140.80), 30 hops max
outgoing MTU = 1500
 1  flr-n140 (128.117.140.254)  23 ms  2 ms  6 ms
 2  vbnsr-n2.ucar.edu (128.117.2.252)  4 ms  3 ms  3 ms
 3  internetr-n243-104.ucar.edu (128.117.243.106)  3 ms  3 ms  3 ms
 4  frgp-gw-1.ucar.edu (128.117.243.114)  5 ms  4 ms  4 ms
 5  den-edge-10.inet.qwest.net (208.46.94.73)  7 ms  5 ms  5 ms
 6  den-core-02.inet.qwest.net (205.171.16.173)  27 ms  10 ms  7 ms
 7  p5-2.crtntx1-cr8.bbnplanet.net (4.24.117.65)  32 ms  32 ms  29 ms
 8  p5-3.crtntx1-ba2.bbnplanet.net (4.24.8.197)  28 ms  26 ms  30 ms
 9  p5-0.crtntx1-ba1.bbnplanet.net (4.24.4.241)  32 ms  27 ms  28 ms
10  50.ATM3-0.BR2.DFW9.ALTER.NET (137.39.23.245)  34 ms  33 ms  27 ms
11  151.at-6-0-0.XR2.DFW9.ALTER.NET (152.63.99.222)  36 ms  29 ms  28 ms
12  184.at-2-1-0.TR2.DFW9.ALTER.NET (152.63.98.54)  71 ms  65 ms  65 ms
13  128.at-5-1-0.TR2.ATL5.ALTER.NET (152.63.0.221)  93 ms  101 ms  89 ms
14  296.ATM6-0.XR2.ATL1.ALTER.NET (152.63.81.37)  98 ms  88 ms  92 ms
15  194.ATM5-0-0.HR1.MIA1.ALTER.NET (152.63.82.109)  113 ms  103 ms  107 ms
16  * Hssi9-1-0.GW1.SJU1.ALTER.NET (137.39.30.54)  4916 ms *
17  spiderlink-sju-gw2.customer.alter.net (157.130.77.58)  5327 ms *  5048 ms
18  * * *
19  upr-T1-1.centix.net (208.234.33.126)  5104 ms *  5017 ms
20  * * *
21  136.145.249.2 (136.145.249.2)  5037 ms * *
22  136.145.165.17 (136.145.165.17)  4945 ms *  5152 ms

5 seconds for a packet to get somewhere is outrageous!  We get _much_
better connectivity to Australia and Antarctica!!

re: Fkey menu default for surface plts is 12
>I think I know now what it is - Frame 12 is the default frame for these
>types of plots, however the configuration I had it on did not have a
>frame 12...The rest of my banter was my typical freaking out...

Aha!  The menu and MCGUI are really setup to run in sessions that have
at least 17 frames.

re: This is saying that the TOPO dataset is not setup for your session.
Who were you running the session as?

>I'm running it as webmaker, an account used for developing the web page.

OK, this is useful information for me.

>It's only limitation is that of the frame numbers, everything else
>'should' be the same - that is to the extent of which it was properly
>configured. In it's DATALOC LISTing, TOPO is defined by: 
>TOPO                         <LOCAL-DATA> 

OK.  Since TOPO is listed as being local data, then you have to define
what TOPO is to your session.  This involves two things:

o defining the groups in TOPO
o making sure that your session can find the data files that comprise
  the groups that you define

To see if the groups are already defined, run:

DSSERVE LIST TOPO

If the listing is blank, then the groups have not yet been defined.
To define the groups, you can either run 'BATCH LSSERVE.BAT' after
defining XCDDATA in your session:

<run the following from the Command window of your McIDAS-X session>

DMAP LSSERVE.BAT

This should show that it is located in /unidata/mcidas/data.
LSSERVE.BAT is a copy of DSSERVE.BAT that sites should have created
during the McIDAS-X installation process.  It contains the DSSERVE
commands to be run to setup various datasets.  In order to run
completely, XCDDATA has to be defined as it is used in the BATCH file.
On your system, XCDDATA is defined as:

TE XCDATA "/unidata/mcidas/xcddata

BATCH for LSSERVE.BAT is then run as:

BATCH LSSERVE.BAT

This will define all of the datasets that are already defined in the
'mcidas' account.  In particular, it will define TOPO.

Next, you have to make sure that your session can find the data files
that makeup the datasets you just defined.  Let's do TOPO as
an example.

The definition for TOPO is:

<I am doing this listing from the 'mcidas' account on breeze>

mcidas@breeze 8% dsserve.k LIST TOPO

Group/Descriptor         Type  Format & Range     RT Comment
------------------------ ----- ------------------ -- --------------------
TOPO/ALL                 IMAGE AREA 9000-9019        Global (Mercator)
TOPO/CONF                IMAGE AREA 9011-9011        North America (Conformal)
TOPO/GLOB                IMAGE AREA 9000-9000        Global (Mercator)
TOPO/GOES8               IMAGE AREA 9016-9016        GOES-8 (75W)
TOPO/GOES9               IMAGE AREA 9017-9017        GOES-9 (135W)
TOPO/MDR                 IMAGE AREA 9018-9018        US Radar projection
TOPO/MERC                IMAGE AREA 9010-9010        North America (Mercator)
TOPO/MOLL                IMAGE AREA 9015-9015        Global (Mollweide)
TOPO/NPOLE               IMAGE AREA 9014-9014        Northern Hemisphere
TOPO/QUAD                IMAGE AREA 9019-9019        NW Quadrasphere
TOPO/SPOLE               IMAGE AREA 9013-9013        Southern Hemisphere
TOPO/WHEMI               IMAGE AREA 9012-9012        Western Hemisphere
dsserve.k: done


You can see that TOPO/CONF is defined to be an IMAGE of type AREA in the
AREA file number range 9011-9011.  Therefore, TOPO/CONF is nothing
other than the file AREA9011.  Your session has to be able to find this
file in order to do something with it:

DMAP AREA9011

If this works, the following should also now work:

IMGDISP TOPO/CONF MAG=-4 EU=TOPO

> DATALOC ADD RTNIDS breeze.uprm.edu
> IMGDISP RTNIDS/BREF STA=JUA EU=BREF REFRESH='EG;MAP H'
>So why am I the unlucky sap to whom it doesn't work?

You are the unlucky sap since you are getting help from me!  I am the
one that left off the '1' on the 'BREF1' in the example.  I really do
apologize for not running the command and cutting and pasting it into
my replies.  I have done so above.

So, again, the command to run is:

IMGDISP RTNIDS/BREF1 STA=TJSJ EU=BREF REFRESH='EG;MAP H'

re: o the IP number of the server machine changes

>I'm a little confused by this comment. Do you mean that even if I list a
>server's domain name, if its IP changes I must define the dataset again?

Yes, for the following reason.  When you define a DATALOC for a dataset
using a name rather than an IP address, McIDAS will do a name lookup to
get the IP address and save it in the file specified in your
MCTABLE_WRITE environment variable (this is
/unidata/mcidas/data/ADDESITE.TXT for the user 'mcidas' on your
system).  When it goes to access the remote server, it simply uses the
"cached" IP address for the connection.  If the remote server's IP
address changes, the IP address used will no longer be correct.
Rerunning the exact same DATALOC command will, however, force a
reevaluation of what the IP address for the server really is and store
the new IP address in the file pointed to by your MCTABLE_WRITE.

>Thank you for all your help.

I really am sorry for the misquoting of command lines.  I will try
to not make this mistake again.

Let's home that your network people can get to the heart of the very
slow connections you are seeing.

Tom