Oops. Typing too fast: I meant
" If they want NetCDF3 files they can use the NetCDF subset service
or use tools like NCO that can read opendap and
On Mon, May 2, 2011 at 4:57 PM, Rich Signell <rsignell@xxxxxxxx> wrote:
> You might also check into using NetCDF4 files with deflation instead
> of .nc.gz. Your users can still download as opendap or any of the
> other services. If they want netcdf4 files they can use the NetCDF
> subset service or use tools like NCO that can read opendap and
> generate NetCDF 3 files. You can convert NetCDF3 to NetCDF4 using
> level 1 deflation using NCO ( ncks -4 -L 1 netcdf3.nc netcdf4.nc).
> They should be about the same size as the nc.gz files, and will be
> much faster to read since you don't have to uncompress the whole file.
> On Mon, May 2, 2011 at 2:27 PM, jerry y pan <jerry.ypan@xxxxxxxxx> wrote:
>> Hi John,
>> Our TDS (4.2) uses some compressed netcdf files (*.nc.gz) and it works fine,
>> except that the very first access to them were slow (relatively large files,
>> about 400 MB each). The subsequent accesses would be much faster, but it
>> would become slow again after a while of non-activity. I can see that TDS
>> uncompress these files to the temp data location, my question is that if TDS
>> cleans up these temp files, which leads to the work to decompress them next
>> time and hence the subsequent slowness? If so, is there a way to keep the
>> cache there permanently? Or, perhaps the faster response right after the
>> first access is due to in memory cache? Any configuration I could twist the
>> -Jerry Pan
>> thredds mailing list
>> For list information or to unsubscribe, visit:
> Dr. Richard P. Signell (508) 457-2229
> USGS, 384 Woods Hole Rd.
> Woods Hole, MA 02543-1598
Dr. Richard P. Signell (508) 457-2229
USGS, 384 Woods Hole Rd.
Woods Hole, MA 02543-1598