This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>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