20000817: 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: switched feed to FSU
>Oh I see, I just noticed that. We've been not getting any data during
>the afternoon times lately, but the reason I changed to Alabama was that
>even with FSU we had a similar problem. I didn't know that they hadn't
>been receiving information recently.

These things come and go.  The reason I switched to FSU was that I wanted
to verify that the changes I had made were working.

The real bottle neck in your network connection seems to be somewhere
close to you.  The other day we did a number of traceroutes to breeze
from our systems in Colorado, and packets got to Puerto Rico fairly
fast.  Once on the island, however, the ping times climbed dramatically.
One test seemed to show that the big holdup was in 'centrix'.  Is this
the ISP for the university?  I would have chats with the networking
people on campus to see if there is something you can do (you being
the university) to get better service.

>You've got the green light to change over to ADDE.

OK.  I just added an action to your ~ldm/etc/pqact.conf to file NIDS
products in ~ldm/data/nexrad/NIDS/JUA/...  I also setup the NIDS.CFG
file in ~mcidas/workdata to be able to find the raw NIDS products
in that directory tree.  I wish I could say that everything is working,
but I see that breeze hasn't received any NIDS products from WSI since
01:52 on Aug 18:

8428533 -rw-rw-r--    1 unidata   225088 Aug 18 07:31 AREA0108
8403082 -rw-rw-rw-    1 unidata   225088 Aug 18 05:13 AREA0112
8636682 -rw-rw-r--    1 unidata   897280 Aug 18 05:10 AREA0275
8428532 -rw-rw-r--    1 unidata   225088 Aug 18 05:10 AREA0107
8403369 -rw-rw-r--    1 unidata      108 Aug 18 01:52 JUASTAT
8490999 -rw-rw-r--    1 unidata       52 Aug 17 19:00 JUARESP

Even at that, then next most recent product came in on August 17 at 19:00.

>Aamos however, asks
>if we could go back to the old system should problems arise.

Right now, both decoding of the NIDS products and filing them is setup.
This should be satisfactory.  After things have proven that they are
working correctly, we can shut off the converting of the NIDS products
to AREA by nids2area.

>You should
>have soon about 4GB of free space to work with, if you need more, let us
>know.

breeze seems to have lots of disk space.  It also seems like a lot
of it is in use with files that could maybe moved off to tape:

cd /user2/unidata
ls -al
total 72
drwxrwxr-x    5 ldm      unidata       53 Apr 24  1998 .
drwxr-sr-x    6 root     sys           65 Dec 29  1999 ..
drwxrwsr-x   15 ldm      unidata     4096 Aug  7 19:44 data
drwxrwxr-x    5 mcidas   unidata       60 Nov 16  1998 mcidas
drwxrwxr-x    2 mcidas   unidata    32768 Aug 19 23:29 xcddata

du -sk data
1078152 data

This looks to me like 10 GB of disk being used in data and its subdirectories.

>Once it's working I'll need to know what files can be deleted
>(from the AREA scouring) so that we have more space.

nids2area is creating AREA files in the 300 - 1100 range.  Once it is
turned off and you have transitioned to looking at the radar data through
ADDE access, these files can be deleted.

>You said that you
>get higher resoltions through ADDE and we've seen that.

What I was attempting to point out was:

o McIDAS access through ADDE to data that is not located on your
  system

o McIDAS support of the NOAAPORT GINI imagery through the GINI ADDE
  server that I added to McIDAS

o the ability to look at a variety of data on systems of folks that
  are willing to cooperate with you (i.e. willing to allow you to
  look at data through their remote ADDE servers)

Given your networking problems, it may be wise for Amos to think about
looking for funds to purchase and install a NOAAPORT reception system.
If you (UPR that is) got a two channel system (the Telecommunications
Gateway (TG) channel (contains observations and model output) and
the GOES-East channel, you would have all the data you would need and
not have to fight the network bottle neck that you have been fighting
for years.  The cost of NOAAPORT reception systems is decreasing over
time, so the prospects for getting one without a great financial
hardship is improving.

>We were
>wondering as to the reason why AREA files have lower resolution, since
>Aamos thought we were already getting 1KM images, while in reality they
>seem to be 10km images. 

The AREA files that you are getting are sectors from much larger, and in
the case of visible data, much higher resolution datasets.  We send
out VIS and IR sectors in 4 km resolution, and WV in 8 km resolution.
The 4 km for the IR and the 8 km for the WV are as high a resolution
as there is.  The VIS channel on GOES, on the other hand, has 1 km
resolution images.

In one sense Amos was right.  The floater products in the Unidata-Wisconsin
channel can be in 1 km resolution.  It depends on what was selected for
the floater for the day.  Again, the IR (10.7 um) and WV (6.8 um) channels
are being sent in their maximum resolution already.

Some of the composite products like the Mollweide composites are in even
lower resolution.  Perhaps Amos was thinking of these?  Or, perhaps
he was thinking that the display out of the Fkey menu was in full resolution;
they are not.  The images loaded out of the Fkey menu are blown-down
(reduced) by a factor of two. This would make the 4 km IRs look like
8 km and the 8 km WVs look like 16 km.  You can prove this to yourself
by running some tests with the imagery in the broadcast.

Compare:

IMGDISP RTIMAGES/GE-VIS STA=SANU MAG=-2 REFRESH='EG;MAP H'

with:

IMGDISP RTIMAGES/GE-VIS STA=SANU MAG=1 REFRESH='EG;MAP H'

>So will all of the feeds be ADDEized? or just NIDS products?  

Just NIDS for right now.  Plus, the comment about the feeds being
ADDEized is not correct.  All that I am doing is changing the
LDM action from decoding the NIDS products into AREA files to simply
FILEing them in "raw" files.  My NIDS ADDE server can then use the
products just as they were received.  This eliminates the conversion
step at ingest, but adds an effective conversion step at display.
The real objective is to be able to keep more images and maintain
the numbers of them more easily.  The other thing is that the Fkey
menu actions for NIDS products should once again work for you since
they were ADDEized in the 7.6 release.

>Thank You,

I will keep an eye on things this weekend and probably touch base with
you again on Monday.

Tom