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.
Hi Kent, Thanks for all your work on isolating the bug. I think the problem may be that netCDF-4 has no such type as a "fixed length string", it only has the "string" type, which is always variable length, and an "array of char" type, which was in the netCDF-3 classic model, and for which a dimension must be defined and named to identify the langth of the char array. When Ed added support for reading HDF5 files that were not netCDF-4 files, he may have not realized fixed-length chars were a new type that the netCDF-4 data model does not support. They either have to be converted to variable length strings (perhaps with a hidden attribute indicating they are fixed length) or as array of char, with a new dimension defined that does not correspond to an associated HDF5 dataspace. Or, we have to add support for a new type, which is a lot of work. The netCDF-4 data model supports fixed-size arrays as members of structs, without having to define associated named dimensions. But as far as I understand, it does not support fixed-size arrays that have no associated, named dimensions. I'll have to look at this a little more carefully to verify that the problem is in the netCDF-4 library layer rather than ncdump, but if so, the fix will have to be in the library. --Russ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: MJR-379092 Department: Support netCDF Priority: Normal Status: Closed