[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
20000823: Current Setup at University of Puerto Rico (cont.)
- Subject: 20000823: Current Setup at University of Puerto Rico (cont.)
- Date: Wed, 23 Aug 2000 17:28:11 -0600
>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
