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 Coy, > > It appears we got your email support question from a week ago, but it > "slipped through the cracks" and didn't get a quick response. Sorry > about that. > > > The problem I was having was due to two calls using the same string. > > This works in NetCDF-3 but causes NetCDF-4 to throw an error when > > calling nc_enddef. It seems odd that the second call below did not > > return an error since it was the cause of the problem. I fixed this by > > simply changing "Mode" to "ModeNumber" in the second call. > > iReturn = nc_def_dim (m_iNcFileID, "Mode", NC_UNLIMITED, &m_iDim_Set); > > iReturn = nc_def_var (m_iNcFileID, "Mode", NC_SHORT, 1, aURI, > > &m_iModeNum); > > iReturn = nc_enddef(m_iNcFileID); > > It's a netCDF convention that a variable with the same name as a dimension > represents a coordinate variable. Howdy Coy! Thanks for finding this bug. I have fixed it in the netCDF codebase, which means it is available in the daily snapshot release if you wish to give it a try: ftp://ftp.unidata.ucar.edu/pub/netcdf/snapshot/netcdf-4-daily.tar.gz However, I think you should not use a variable with the same name as a dimension, unless that dimension is one of the ones used by that variable. This violates a strong netCDF convention and is likely to cause confusion for software and users who encounter this data. Thanks, Ed Ticket Details =================== Ticket ID: TLB-677315 Department: Support netCDF Priority: Normal Status: Open