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.
Ludovic, I've simplified your bug demonstration a little bit, and the program behaves differently on two different platforms. On a Linux system using GNU compilers it runs to completion, but calling nc_inq_dimlen on beam dimension gives a much larger dimension length than it should just before closing the file. On a Sun/i386 platform with vendor C compiler, it gets an error in the HDF5 layer on a call to H5Dwrite. Ed will look at the problem next week. In the meantime, I think I can suggest a workaround or maybe a better approach. Your demonstration code is writing a "ragged array" that has an unlimited number of rows and different numbers of elements in each row. Another way to do this is to use the variable-length array feature of netCDF-4 for each row, so you would have an array of variable-length arrays. There is a test/demonstration program in ncdump/tst_vlen_data.c that shows how to do this. It writes a file that has this structure: netcdf tst_vlen_data { types: float(*) row_of_floats ; dimensions: m = 5 ; variables: row_of_floats ragged_array(m) ; row_of_floats ragged_array:_FillValue = {-999} ; data: ragged_array = {10, 11, 12, 13, 14}, {20, 21, 22, 23}, {30, 31, 32}, {40, 41}, _ ; } If a ragged array is what you really need for your application, I think this sort of structure may offer a better way to implement it. --Russ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: NJG-578265 Department: Support netCDF Priority: Normal Status: Closed