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

20010815: IMGLIST vs IMGCOPY using NEXRAD data

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.

  • Subject: 20010815: IMGLIST vs IMGCOPY using NEXRAD data
  • Date: Fri, 17 Aug 2001 20:39:04 -0600
>From: Rick Kohrs <address@hidden>
>Organization:  SSEC
>Keywords:  200108091622.f79GMP122796 McIDAS nexradir nexraget

Rick,

>The caching would explain the difference.  What is actually cached?  My
>batch job goes through several radar sites and I am always seeing
>IMGLIST take longer than IMGCOPY.  Are things cached based on ID?

What the OS caches is up to itself.  Since the header portion of each file
has to be read to get the information necessary to synthesize an AREA
header, that data will get cached by the OS.  This information will be
used by the IMGCOPY phase as the server _once again_ determines which
file contains the information needed, so finding the file to send will
be quicker.  The actual job of extracting and sending the NEXRAD data
back to the client is relatively quick since the file will already be
open and seeked to the beginning of data (opening files and seeking in
them are heavy weight processes).  The actual amount of data that gets
sent back in the copy is very small for NEXRAD data especially after it
is compressed, so that time is neglegible.

The listing of NEXRAD data could be made faster _if_ one could assume
that information needed to be sent back for things like IMGLIST were
contained in the name of the file.  This does not help, however, in
something that must be calculated: the resolution at the center of
an image.

Tom