20010308: 7.7x version of uacross fails in plotting wind barbs (cont.)

>From: "Paul L. Sirvatka" <address@hidden>
>Organization: College of DuPage
>Keywords: 200102162013.f1GKD9L01250 McIDAS-X SFCCON GRDDISP

Paul,

>Thanks for the change. It is working well now. 

OK, glad to hear it.

>As for the data...I think it is just the amount of satellite images we are
>requesting. All the other data is local.

OK, but I am suprised to hear this since there _is_ a problem serving
sounding data off of RedHat 6.2,7.0 Linux, and you are running one of
these versions of Linux on your local machine.  I am betting that the
DATALOC in effect for your cron-initiated display generations is still
using adde.ucar.edu for RTPTSRC.  Since there is a problem serving
sounding data, and since sounding data is part of RTPTSRC (it is the
combination of the UPPERMAND and UPPERSIG subsets), you should keep
pointing at a non-Linux server for the data.

>I will work to cut the sat requests by a little bit.

Again, I am not complaining about your use of the remote
ADDE server.  I am just curious about what your goals are.

It might be the case that there are some things you could do that would
both speed up your access to the data AND cut down on the total number
of bytes.  For instance, at one time I looked at what image display
requests were being made, and it seemed like several consecutive
displays would be of the same product at a different resolution.  If
this really is the case, you might be able to cut down on the total number
of bytes transferred by doing something like:

o IMGCOPY a high resolution view of the region you are interested in to
  the local MYDATA/IMAGES dataset

o IMGDISP out of the MYDATA/IMAGES image that you just copied

This will work as well as the original IMGDISPs IF the resolutions of
the larger scale views are derivable from the resolution that you copy
down.  What I mean by this is:

o if you copy down 1 km data, then any blowdown from that data will be
  the same as if you did the display from the original image

o if you copy down data blown down to 2 km resolution, then the succeeding
  blow downs will only be even multiples of 2 km.  This means that you would
  not be able to get the same view as a MAG=-3 from the original image

Since I have never run an experiment to see what the overall change in
number of bytes transferred is, I can not be definitive about what the
savings might be.  I can tell you, however, that the original 1 km VIS
images are each 26 MB in size!  So, if you are doing a number of
different views of the high resolution VIS data, it might well be the
case that the sum of all of the bytest transferred in multiple views is
actually less than transferring down the entire image and then doing
the displays from the copy!  Again, some experiments would have to be
run to determine what, if any, savings could be had.

>Do you know what times the images are in?

The time the images are filed is a little variable, but they are
typically available 15 minutes past their ordinal time.  The only
reason this is so consistent for adde.ucar.edu is that it is being fed
by a NOAAPORT receiver.  For other ADDE sites (like papagayo.unl.edu),
the time the product is available will be a function of the latency
introduced at its feeder and how slow the network is.

Tom