20000821: 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: bottleneck in UPR's network connection
>That makes sense.  I don't know what 'centrix' is, but it doesn't sound
>like the university's ISP. As for getting something here done, it's
>rather unlikely.

But, you should still try.  Without someone voicing a concern, the
people looking after the networking will never know that someone considers
the slow service a real problem.

re: you hadn't received radar for quite awhile
>Oh. I see, I guess Aamos was right when he said he thought the feeds
>were discontinued.  See ROUTE LIST still reports them as current:
>---
>  R1 Base Reflectivity Tilt 1   300-339  AREA0322     00234 1745    none     3
>  R2 Base Reflectivity Tilt 2   340-379  AREA0374     00234 1751    none     3
>  R3 Base Reflectivity Tilt 3   380-419  AREA0416     00234 1752    none     3
>  R4 Base Reflectivity Tilt 4   420-459  AREA0452     00234 1724    none     3
>---

The feed started up again at about 4 this morning (your time).

>Is there another place where we can get these feeds? I thought Aamos was
>paying for these...

Amos is paying for the NIDS data.  The is the possibility that the San
Juan NEXRAD (JUA) was down for some reason.  The good news is you are
once again getting the data.

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

>OK

Since the new FILEing method and scouring of the data files is now working,
I propose turning off the old filing:

I just changed:

WSI    ^NEX/(.*)/(.*)/(.*)     FILE
       -overwrite /unidata/ldm/data/mcidasd/\1\2

to:

#WSI    ^NEX/(.*)/(.*)/(.*)     FILE
#       -overwrite /unidata/ldm/data/mcidasd/\1\2

in pqact.conf.

I further propose to turn off converting of the NIDS products to McIDAS
AREA files, but I won't do that until you and Amos have had a chance
to exercise the ADDE access to the FILEd products.

re: how much disk space is really available on breeze
>OK, since we still have plenty of space we can worry about that later

OK.  I will leave this to you.

re: what I was trying to demonstrate with the example ADDE commands for
displaying GINI imagery
>Oh. Right.

re: it would be a wise move to look into purchasing a NOAAPORT receiving
system
>Oh now this is something Aamos would really like. He's been trying to
>get access through a 3rd party but hasn't been lucky.  So this TG
>channel has like upper-air, radar and surface plot information or what
>kind of data?

It has global surface, upper air, pilot reports, and NCEP model output.
In December, it should also have ALL of the NEXRAD data from the US.
At this point people _really_ have to start worrying about what data
they want to keep.  The NEXRAD data portion of the stream will be huge.

>Where could we find information on pricing for one of
>these babies?

NOAA maintains a page of vendors of NOAAPORT reception systems:

NOAAPORT HomePage
http://www.nws.noaa.gov/noaaport/html/noaaport.shtml
  Manufacturers List
  http://www.nws.noaa.gov/noaaport/html/manu_lst.shtml

  
re: which products in the Unidata-Wisconsin datastream can be at 1 km
resolution

>Oh ok I see.

>Well this is where my frustrations come into play: I just tried the
>command you gave me below and got:
>
>IMGDISP RTIMAGES/GE-VIS STA=SANU MAG=-2 REFRESH='EG;MAP H'
>IMGDISP: The requested portion of the image does not exist
>IMGDISP: done
>          
>and I have no idea why?

Oops, I sent you the wrong station.  SANU is in South America.

The output is telling you that there is no portion of the image that
lies in the field of view given the load criteria specified.

Try instead:

IMGDISP RTIMAGES/GE-VIS.-1 LATLON=18:26 66:00 MAG=-2 REFRESH='EG;MAP H'

>Well, this is one of many feeds for which we
>have problems and sometimes I can't tell if it's just the connection or
>not.

The data is there; the error was in the load center.  You need to play
with IMGDISP some more to get the feel for how it can be run.  When
you get an message telling you that no portion of the image is displayable,
it means that there is an image there.  When you see this, you could
blow down the image more (which increases the field of view) to see where
you are requesting the load.

For instance, try:

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

You should get a display from this, and you will see that I made the mistake
of not seeing that SANU is in South America.

>For example:
>I know that several days ago I tried doing a surface plot of temperature
>and front information, and it was displayed beautifully.  However I
>tried today and got all sorts of errors, not with one but almost all
>data sources. Fronts would give me an error saying:
>FRNTDISP: Front not available for  15      

This is telling you that you did not get the front reports for 15Z today.

>And now, I don't know why, the program wants to display all surface
>plots on frame 12!

Through the menu?  That is by design, but it can be changed:

ESC   - Main menu
F7    - Menu Administration
F7    - Modify Menu System Parameters

This pops up a GUI.  In the GUI, you can change the Surface Plot/Contour
entry from 12 to whatever frame you like (within the constraints of choosing
a frame that exists, of course).

>For all user defined Topographic images, it just draws contour lines. 

I don't understand this one.

>For topographics images, how would I add the set TOPO/CONF?  Since I try
>to display just topographic images and get and error saying:
>IMGDISP: Image data server unable to resolve this dataset: TOPO/CONF   

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

>I'm sorry to come down with all of these things at once, but they're
>starting to get me frustrated.

It is no wonder.  You are trying to use a system without ever had any
training on it.

re: keeping an eye on things
>Please let me know what I can/have to do on my end.  I will defintely
>talk to Aamos about the reception system. Thank you.

The NIDS stuff is now being filed under /unidata/ldm/data/nexrad/NIDS/JUA/...

The ADDE access to the data works through the remote ADDE server.  I
know because I have successfully loaded JUA images on my system here
in Boulder:

DATALOC ADD RTNIDS breeze.uprm.edu
IMGDISP RTNIDS/BREF STA=JUA EU=BREF REFRESH='EG;MAP H'

Try this in your own McIDAS-X session.  It should work with no hitches.

Please note that once you have defined where to look for a dataset in
a McIDAS-X session, you don't have to do it again UNLESS:

o the IP number of the server machine changes

Tom