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

20011117: McIDAS vis-a-via Solaris 7/8 (cont.)



>From: "James R. Frysinger" <address@hidden>
>Organization: College of Charleston
>Keywords: 200111061842.fA6Igt112242 McIDAS platfomrs

Jim,

re: ports 500 and 503

>       OK. I'll send a follow-up and let them know that they are indeed 
>blocking out those ports and that they need to open them for ADDE.

I saw your second note to your network guys.

re: data discovery

>       As I recall from a DODS workshop I attended here in Charleston about a 
>year ago, that's one of the things that DODS is supposed to help with.

Part of the THREDDS project is aimed at data discovery in DODS better
also.

re: /home/mcidas/data should be /export/home/mcidas/data

>       Dangit. When I had gone through, replacing /var/data with 
>/export/home/mcdata I got carried away. For AREA900* and AREA901* I had 
>replaced /home/mcidas/data with /export/home/mcdata also, instead of 
>replacing it with /export/home/mcidas/data. Likewise for the AREA8*, 
>GRID8*, and MDXX8* tutorials. Those now read:
>
>   AREA900*    /export/home/mcidas/data
>   AREA901*    /export/home/mcidas/data
>
>   AREA8*      /export/home/mcidas/data/tutorial
>   GRID8*      /export/home/mcidas/data/tutorial
>   MDXX8*      /export/home/mcidas/data/tutorial"
>
>leaving all the others as /export/home/mcdata

Execllent!

re: rerun REDIRECT REST LOCAL.NAM

>       Yes, that directory now contains AREAs 9000 and 9010-9019 as well as 
>9982, 9983, and 9995. No complaints observed.

This is now as it should be.

>Proceded on with 
>repeating the guidance in "Configuring the mcidas Account".
>
>       BTW, this time I opened mcidas from home by ssh'ing into 
>address@hidden. Two things became apparent (other than the 
>sludginess of operating remotely, even via my cable modem at home). The 
>first thing I noticed was that when mcidas opened, remotely displayed 
>on my screen here at home, the output log stated (according to my 
>hand-scribbled notes):
>   SKED SKEDFILE
>   Scheduler starting on file SKEDFILE

This is OK.

>   mcimage: Number of graphic colors plus image colors cannot be more 
>than 62.
>   mcimage: Attempting to guess a good value.
>   mcimage: Using slow processing for Z-16 images.

You are evidentally running youe X server in 16-bit mode.

>For info: I'm running a 500 MHz Dell XPS-T500 with 620 MiB of RAM here 
>at home. I have an NVIDIA graphics card that's pretty powerful, too.

What OS?  If Linux, I would recommend running in 24-bit mode.  That
is how I run at home.

>       The other thing that became apparent is that TE XCDDATA 
>"/export/home/mcdata did not work from the mcidas command line as it 
>did before. This time I got
>   2ND positional argument is too big --> /export/home/mcidata
>   Must be character string of no more than 12 chars.
>   XCDDATA := /export/home

This is pretty much saying that the quote (double quote) was omitted.

>At this point, I EXITed mcidas, went to ---/workdata and did
>   te.k XCDDATA \"/export/home/mcdata
>and got
>   XCDDATA := /export/home/mcidas

Are you sure?  You told McIDAS to set XCDDATA to /export/home/mcdata
and it said it set it to /export/home/mcidas?  If yes, stop right
there until we can find out why this totally unexpected thing happened.

>Then I opened mcidas again and resumed the configuration.

All bets are off if XCDDATA is really /export/home/mcidas!!!!!
Hopefully, XCDDATA really is /export/home/mcdata.

re: IMGDISP TOPO/CONF 1 EU=TOPO MAG=-2 LATLON=42 100 SF=YES

>       Hmmmm. Discovered a BOB problem... Blind Old Bat. Works fine when 
>given the right commands now!

Good.

re: DATALOC ADD TOPO
>
>       This problem remains.

Not good.

>Yep, that'st another thing I noticed. A few 
>steps earlier, after your catch on my typo, I saw some topographic 
>images of North America on the image screen and even played around by 
>opening TOPO/WHEMI with LATLON=0 100. Neato!

OK.

>My TOPO/ALL listing shows 
>the number 20 on the mcidas output and a dozen or so TOPO categories 
>are listed below that line, including WHEMI.

It should look like:

IMGLIST TOPO/ALL

should show:

IMGLIST TOPO/ALL
Image file directory listing for:TOPO/ALL
 Pos Satellite/         Date       Time      Center   Band(s)
     sensor                                 Lat  Lon
 --- -------------  ------------  --------  ---- ---- ------------
   1  TOPOGRAPHY     1 JAN 96001  00:00:00     0    0 1
IMGLIST: done


IMGLIST TOPO/ALL.ALL

should show:

Image file directory listing for:TOPO/ALL
 Pos Satellite/         Date       Time      Center   Band(s)
     sensor                                 Lat  Lon
 --- -------------  ------------  --------  ---- ---- ------------
   1  TOPOGRAPHY     1 JAN 96001  00:00:00     0    0 1
  11  TOPOGRAPHY     1 JAN 96001  00:00:00    40  105 1
  12  TOPOGRAPHY     1 JAN 96001  00:00:00    45  105 1
  13  TOPOGRAPHY     1 JAN 96001  00:00:00     0  100 1
  14  TOPOGRAPHY     1 JAN 96001  00:00:00   -90  105 1
  15  TOPOGRAPHY     1 JAN 96001  00:00:00    90  105 1
  16  TOPOGRAPHY     1 JAN 96001  00:00:00     0    0 1
  17  TOPOGRAPHY     1 JAN 96001  00:00:00    23   71 1
  18  TOPOGRAPHY     1 JAN 96001  00:00:00    25  138 1
  19  TOPOGRAPHY     1 JAN 96001  00:00:00    40   98 1
  20  TOPOGRAPHY     1 JAN 96001  00:00:00    26  100 1
IMGLIST: done

>       I checked /export/mcidas/data and I have the following TOPO* files
>TOPO.ET        TOPOADDE.BAT   TOPOMDR.ET     TOPOSAT.ET
>TOPO.ST        TOPOIR.ST      TOPOMDR.ST     TOPOVIS.ST
>and they are not null files.

These are enhancements and stretch tables for topographic imagery.  The
TOPO ADDE dataset is the set of images in AREA files: AREA9000,
AREA9011-AREA9019.

re: user SHELL additions are available from web page

>> http://www.unidata.ucar.edu/packages/mcidas/780/mcx/config_users.html

>       Embarassing. I was working from a laser printout of the page of 
>directions and hadn't noted that those two lines for user_env.csh and 
>user_env.sh were hyperlinked.

Hardcopy!?  How 19th century ;-)

>Those don't lead back to exactly the link 
>you provided above, but they match the listings shown on the page of 
>directions.

Hmm...

re: CDE mods are for Fkey menu use only
>
>       Great! I personally dislike unique sets of F-key commands. Every 
>program tends to invent its own version and hopping from one program to 
>another makes it hard to remember the non-standard ones.

I'm with you.  The MCGUI is in its infancy; it will get more functional
as time goes on.

>I'm looking 
>forward to doing the GUI version of mcidas and I think that will make 
>it easier to train my colleagues, who will be even less practiced at 
>using it than I will.

Right.  I agree.

re: 'mcadde' is in the same group as 'mcidas' and has the same HOME directory

>       Dangit again. BOB missed that part in the directions about those two 
>accounts having the same home page. Went to /etc/passwd as su and 
>changed the home page then removed /export/home/mcadde directory.

Good.

>       I'm guessing that while we're waiting for our administrative computing 
>department to open those ports, I can start downloading and looking at 
>the installation directories for some of the other programs. Meanwhile, 
>it looks to me like I've got to clean up this problem with BATCH 
>"LOCDATA.BAT,

Yes.

>finish configuring frysingj as a mcidas user (to practice 
>and build the templates for general mcidas users), and perhaps a few 
>other tidbits. Until then, I guess "Configuring Sessions with 
>.mcidasrc" -- or very far into it -- since I mcidas is not ready to be 
>run by a user.

Right again.  Don't worry about .mcidasrc right now.  The new GUI startup
for McIDAS allows one to make the most commonly used modifications through
an GUI.

>       Oh.... and I want to proceed on with installing mcidas on my linux box 
>here at home. My guess is that this will let me pull files off of ADDE 
>and process them here at home instead of remotely processing them via 
>ssh.

Right!  This is the cool thing about ADDE.  No data has to be local
(although the TOPO AREA files will be since they are part of the
distribution).

>(Also, I may have a voice in some future computer aquisitions in 
>this department full of Macintosh-huggers and the background knowledge 
>and experience might be useful.) I'll go back to the other thread of a 
>week or so ago for that, when I get the chance to work on that some 
>more.

McIDAS may work/compile/etc. under MacOS 10.  I will be trying this out
reasonably soon.

Talk to you later...

Tom

>From address@hidden Sat Nov 17 10:55:35 2001
>Subject: Fwd: Firewall holes for data access
>To:      address@hidden, address@hidden, address@hidden
>Cc: Unidata Support <address@hidden>,
>   address@hidden, address@hidden,
>   "Dr. Jon Hakkila" <address@hidden>

Unidata has confirmed that our ports 500 and 503 to weather.cofc.edu 
are not open. Nor would they have necessarily been open last January, 
so proactive measures are called for. Would you open those for us 
please? I haven't heard anything from you as a result of my message 
yesterday.

I'm having trouble accessing either ACTS or the Self-Service Helpdesk 
via the web, by the way. How do we log on to the Self-Service Helpdesk?

Thanks,
Jim

----------  Forwarded Message  ----------
Subject: Firewall holes for data access
Date: Fri, 16 Nov 2001 11:28:38 -0500
From: "James R. Frysinger" <address@hidden>
To: address@hidden, address@hidden
Cc: Unidata Support <address@hidden>, 
address@hidden, address@hidden, "Dr. Jon Hakkila" 
<address@hidden>


Dear Tony and Charlie,

I'm not sure which of you (or who else) is in charge of providing
 access through our firewall for data access, so please pass this to
 the proper person if my aim is off the mark.

I am close to finishing the process of restoring mcidas and mcadde to
our weather.cofc.edu which means that again we will be wanting data
 port access on/off campus with Unidata/UCAR providers.

The ports I need to have open are:
   388 LDM [the data ingester here at weather.cofc.edu]
   500 ADDE uncompressed transfers
   503 ADDE compressed transfers
ADDE is the local server into which data comes and out of which it is
served, both locally and remotely, as controlled by LDM, our local data
manager. I believe that they were open last January when we were
successfully ingesting data, but this bears checking!

PLease let me know ASAP what the status of these ports is for access
through the firewall to and from weather.cofc.edu.

As an aside, please pass to the postmaster of ashley.cofc.edu that my
Unidata colleagues tell me that my messages to them are doubling.

regards,
Jim Frysinger
also at:
   address@hidden
   (Sysadmin, weather.cofc.edu)

--
James R. Frysinger                  University/College of Charleston
10 Captiva Row                      Dept. of Physics and Astronomy
Charleston, SC 29407                66 George Street
843.225.0805                        Charleston, SC 29424
http://www.cofc.edu/~frysingj       address@hidden
Cert. Adv. Metrication Specialist   843.953.7644

-------------------------------------------------------

-- 
James R. Frysinger                  University/College of Charleston
10 Captiva Row                      Dept. of Physics and Astronomy
Charleston, SC 29407                66 George Street
843.225.0805                        Charleston, SC 29424
http://www.cofc.edu/~frysingj       address@hidden
Cert. Adv. Metrication Specialist   843.953.7644