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 Ted, I saw your post on the mailing list and have been trying to find out why it is like this; I agree that it *looks* like an oversight, but since I didn't write that code I can't say for certain. It appears that it is new code coming in since the last release, and I've queried Dennis Heimbigner re: the context. I'll follow up with you when I know the reasoning or, hopefully, it can be removed so that we don't clobber the flag. Thanks! -Ward > I thought I would forward this to the support email, too. It looks like an > error/oversight to me, but maybe there was a reason for this change? The "#if > 0" makes me think that there's a higher level of code with a preprocessed > token? > > Cheers, > > -- Ted > > Begin forwarded message: > > > From: Ted Mansell <address@hidden> > > Subject: 64-bit offset flag ignored by netcdf 4.3.3.1 for pnetcdf? > > Date: October 9, 2015 at 5:43:58 PM CDT > > To: "netcdfgroup (address@hidden)" <address@hidden> > > > > Howdy, > > > > I have been using netcdf-c-4.3.1.1 (with a pnetcdf bug fix) for my weather > > model production runs, and just tried using 4.3.3.1 on a new system. I use > > the netcdf-4 interface to create a pnetcdf file, for which I pass the > > 64-bit offset bits: > > > > cmode = ior(ior(NF90_PNETCDF,NF90_MPIIO),nf90_64bit_offset) > > status = nf90_create(filename, cmode, ncid, comm = my_comm, info = my_info) > > > > I found that the files were being created as just "classic", however. > > > > Wei-keng Liao found the problem in libsrc5/nc5dispatch.c, which had this: > > > > 75 #if 0 > > 76 cmode &= (NC_WRITE | NC_NOCLOBBER | NC_LOCK | NC_SHARE | > > NC_64BIT_OFFSET); > > 77 #else > > 78 cmode &= (NC_WRITE | NC_NOCLOBBER | NC_LOCK | NC_SHARE ); > > 79 #endif > > > > which for whatever reason was clobbering the NC_64BIT_OFFSET bits. Is there > > any reason not to always use the first line, i.e., change this to "#if 1"? > > This is what I did, and it fixed the problem. > > > > 4.4.0-rc3 has the same issue in libsrcp/ncpdispatch.c (same line numbers). > > Shouldn't the first line (with "| NC_64BIT_OFFSET") be the default? > > > > Cheers, > > > > -- Ted > > > > __________________________________________________________ > > | Edward Mansell <address@hidden> > > | National Severe Storms Laboratory > > |-------------------------------------------------------------- > > | "The contents of this message are mine personally and > > | do not reflect any position of the U.S. Government or NOAA." > > |-------------------------------------------------------------- > > > > Ticket Details =================== Ticket ID: QGA-640676 Department: Support netCDF Priority: Normal Status: Closed