NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
I've followed the discussion on this subject today. I've not looked at this issue in eons. I recall that this certainly was a problem with early netCDF releases, apparently from forcing long seeks in big files (assuming I remembered correctly). At that time, I tended to work around the problem by keeping relatively few time steps in each file mapped to the unlimited dimension, and then creating multiple files. The files would have multiple (static) dimensions and variables, but would have fast access. The applications then took care of the bookkeeping to treat the set of files as a single data set. I still use that approach today, having not revisited how to do it better with more recent versions of netCDF. -------------------------- Lloyd A. Treinish Deep Computing Institute IBM Thomas J. Watson Research Center P. O. Box 218 Yorktown Heights, NY 10598 914-945-2770 (voice) 914-945-3434 (facsimile) lloydt@xxxxxxxxxx http://www.research.ibm.com/people/l/lloydt/ http://www.research.ibm.com/weather John Galbraith <john@xxxxxxxxxxxxxxx>@unidata.ucar.edu on 09/10/2001 03:26:23 PM Please respond to John Galbraith <john@xxxxxxxxxxxxxxx> Sent by: owner-netcdfgroup@xxxxxxxxxxxxxxxx cc: Ethan Alpert <ethan@xxxxxxxxxxxx>, john@xxxxxxxxxxxxxxx, netcdfgroup@xxxxxxxxxxxxxxxx >>>>> "Steve" == Steve Emmerson <steve@xxxxxxxxxxxxxxxx> writes: >> ... I can't be certain but it seems like the entire file is >> rewritten when the unlimited dimension increases. Steve> The C implementation from the Unidata Program Center of the Steve> netCDF API *does not* rewrite the entire netCDF file when the Steve> unlimited dimension is increased -- effectively, the file is Steve> simply appended to. That is why I say "seems", because the write time "seems" to be proportional to the size of the file. I have no evidence that the file is actually being copied. In fact, I would be surprised if it was and would suspect that I am calling the netcdf library incorrectly. I probably am calling it incorrectly, based on this trouble I am having, but I don't know what my problem is yet. Steve> I don't know about the Python interface. The Python interface basically just converts the python array slices to netcdf arguments and calls ncvarputg(). (Python arrays are contiguous values). The Python module never actually touches the netcdf file except through that call to ncvarputg(). Even if the python wrapper was deathly slow, it would be the same deathly slow interval every write and it wouldn't be dependent on the file size. Maybe there is some issue with calling the old netcdf API? Thanks, John -- John Galbraith email: john@xxxxxxxxxxxxxxx Los Alamos National Laboratory, home phone: (505) 662-3849 work phone: (505) 665-6301
netcdfgroup
archives: