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.
> I have a question which you should be able to answer easily, and it has > to do with the writing speed of the NetCDF file. It takes about one > minute to write four arrays of size 41200 each on a Sparc Ultra 1, which > seems to me to be pretty slow. The odd thing is, the first array takes > the majority of that time; after that, the other 3 are written quickly. > Is this just a function of the NetCDF file format? It seems to write > empty data in the other 3 arrays after it writes the first. I don't have enough info about what you are doing to answer definitively. I would need to know the netcdf schema and the exact access pattern. When a netcdf file grows to accept new data, data positions beyond the old end of file which are not covered by the data 'put' underway are written with the 'fill value'. This is the default behavior. This behavior can be toggled by use of the 'setFill()' method of NetcdfFile and by a boolean argument to some of the NetcdfFile constructors. The java netcdf is not yet particularly speedy. This week we announced a release which has some speedups by using a buffered RandomAccessFile underneath NetcdfFile. > My final question is this: how much traffic is on the Java-NetCDF list? > I haven't gotten any messages from it, but I have noticed that the > NetCDF package is updated regularly. There hasn't been much traffic. This week you should have gotten a notice of the release with buffering I mention above. -glenn