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.
Rob, > The only sticky area is when a 64 bit machine (AMD opteron, intel > core2) creates a NC_NETCDF4 file with big dimensions, then sends that > file to a collaborator with a 32 bit machine. In that scenario, you > just give an error, essentially saying "try again on a 64 bit > machine", right? This uncovered a bug in our netCDF-4 code, which Ed just fixed in the snapshot, so now dimension sizes can be full 64-bit integers in netCDF-4/HDF5 files. However, it also uncovered a gap in our handling of big dimensions. Specifically, it's currently not possible to detect a big dimension on a 32-bit platform, instead when you try to inquire about the dimension size with nc_inq_dimlen(), you just get the dimension length truncated to the 32-bit size_t. We obviously have to do something about this, and I have proposed returning the error code NC_EDIMSIZE, which until now has only been returned when defining a dimension with an invalid size, such as a negative number. We have to determine the details of how HDF5 handles big dimensions on 32-bit platforms in order to make netCDF-4 do the right thing. I'll let you know how we resolve this, but thanks making us aware of the need for considering these issues. --Russ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: FFY-177157 Department: Support netCDF Priority: Normal Status: Closed