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.
>To: address@hidden >cc: Bjarne B?chmann <address@hidden>, >cc: Peter Gylling J?rgensen <address@hidden> >From: Karsten Bolding <address@hidden> >Subject: restoring headers in large netcdf files >Organization: Bolding & Burchard Hydrodynamics >Keywords: 200502190949.j1J9ncv2029855 netCDF large file header restore > I've now added NF_64BIT_OFFSET when creating the .nc file and I do > indeed get: > kbk@sill01:/data/kbk/dk_03nm/2003/03$ !od > od -An -c -N4 dk_03nm.3d.000.nc > C D F 002 > > (I actually had to use 'ior(NF_CLOBBER,NF_64BIT_OFFSET)' instead of just > 'or(..' with the Intel Fortran compiler in a Linux machine - v. 8) OK, I'm not sure what the difference is between the intrinsic functions OR(N,M) and IOR(N,M). Maybe they are two names for the same Boolean bitwise OR function. > > Was it possible to create netCDF files larger than 2 GiBytes before > > version 3.6? > > > > Yes, but there are significant restrictions on the structure of large > > netCDF files that result from the 32-bit relative offsets that are > > part of the classic netCDF format. For details, see NetCDF Classic > > Format Limitations in the User's Guide: > > > > http://www.unidata.ucar.edu/packages/netcdf/netcdf/NetCDF-Classic-Format-Limitations.html > > > > Also to have files with bad headers, I think you would have had to > > close the CDF2 file and then later reopen it with nf_open() and either > > enter define mode with nf_redef() or change an attribute value with > > nf_put_att_TYPE(). If you didn't do all of these things, then I don't > > think the bug I was referring to could affect you. > > > > However, it's possible you have identified a different bug, either in > > the netCDF library or in NCO. I'm very interested in helping diagnose > > the problem. > > Before v3.6.0 when you broke the 2GB limit the program stopped with an > error message from NetCDF (don't remember the exact words now) but now > it seems you can actually make a file more than 2GB as described in the > link you give above. I checked the CDL of the file you sent, and it is the right form to be representable as a CDF1 ("classic format") file as well as a CDF2 ("64-bit offsets") file. The header and fixed-size variables take 2309824 bytes, and each record takes 12211204 bytes, so your 744 record file should have been 9087445600 bytes, about 8.46 GiBytes. You didn't have to use the new CDF2 version of the format, and if you want to be able to use your with other utilities that have not yet upgraded to netCDF 3.6 or later, it would be better to leave them as CDF1 files. I wasn't recommending that you should write them as CDF2 files (by using NF_64BIT_OFFSET). I was instead saying they would have had to be written as CDF2 files for you to have experienced the potentially serious bug I mentioned, where a CDF2 file gets changed into a CDF1 file when you reopen it for writing and add a new variable or rewrite an attribute. > > > Here is a listing of the files: > > > phy-43:~# ls -lh /nodes/{01,02,03,04}/kbk/dk_03nm/2003/01/*3d* > > > -rw-r--r-- 1 kbk kbk 8.5G Feb 19 00:15 > > > /nodes/01/kbk/dk_03nm/2003/01/dk_03nm.3d.000.nc > > <snip> > > > I would be interested in the output of "ncdump -h" for one of these > > files. Could you send me what you get when you run > > > > $ ncdump -h dk_03nm.3d.000.nc > > I've attached the result of the above command to this file. > > > > > for example? I want to determine if they are properly structured CDF1 > > files that meet the constraints for > 2 GiB files without using the > > 64-bit offsets in the CDF2 format. > > > > <snip> > > > netcdf test { > > // Last fixed variable > 2 GiB. Expect to fail when using library > > // not compiled with Large File Support. > > dimensions: > > x = 1024; > > y = 1024; > > z = 1025; > > variables: > > float x(x); > > float y(y); > > float z(z); > > short var(x, y, z); > > data: > > var = 1, 2, 3; > > } > > > > As I wrote I've updated to the latest beta version and when I do a > make extra_text I get: > ./quick_large_files -f ./example.nc > *** Creating ./example.nc for 64-bit offset large file test...ok > : > : > *** Now a 64 bit-offset file that just fits...ok > > *** All large file tests were successful. > *** Success *** > ls -l ./example.nc > -rw-r--r-- 1 kbk kbk 12884902184 Feb 21 09:24 ./example.nc > rm ./example.nc > > but when I do: > kbk@orca:/data/kbk$ ncgen -v 2 -b large.cdl > I only get: > kbk@orca:/data/kbk$ ls -l large.nc > -rw-r--r-- 1 kbk kbk 2149593328 Feb 21 09:26 large.nc > i.e. limited to 2GB > > After a few minutes !! I actually kill the program - since the file size > does not change. Oops, sorry, I should try these examples out before sending them in replies. When I run ncgen for the above file, I get $ ncgen -v 2 -b large.cdl ncgen: large.cdl line 14: out of memory when it reaches 2 GiB also, but that's a problem with ncgen trying to allocate enough memory to hold the whole variable, not a problem trying to write the file. I've just tried this to produce a CDF1 file that's bigger than 2 GiB for you to test with NCO. Put this in "large.cdl": netcdf large { dimensions: x = 1024; y = 1024; z = 1024; time = UNLIMITED; variables: byte var(time, x, y, z); // 1 GiB per record int time(time); data: time = 1, 2, 3; } Then run ncgen -b large.cdl; ls -l large.nc For me this took a little over 3 minutes to produce a file over 3 GiB in size: -rw-r--r-- 1 russ ustaff 3221225648 Feb 22 16:47 large.nc Now this is a CDF1 (classic) netCDF file, so even older versions of NCO should be able to handle it, as long as NCO is built with large file system support. If you attempt the NCO operation ncks -v time large.nc I would think it should work, if NCO is built with large file support. But I don't have NCO built with large file support to try this with right now. The version I have from 2003 gives what looks like an unrelated error: $ /scratch/russ/nco-2.7.1/bin/ncks -v time large.nc time.nc ncks: ERROR unable to determine method for remote retrieval of large.nc I will try to build a version of nco with large file support and try this out to make sure it works as it should, or if not to report it as an nco bug. > So I can't really check whether I can use nco on the file large.nc. I > however tested it on the output files generated with the new library and > I do get a: > kbk@phy-43:/nodes/01/kbk/dk_03nm/2003/04$ ncks -v elev dk_03nm.3d.000.nc > elev.nc > ERROR: program exiting through nco_err_exit() which will now call > exit(EXIT_FAILURE) > nco_err_exit(): ERROR nco_open() > Not a netCDF file > > i.e. I do not a version of nco with support for large files compiled in > so I'll have to update nco for further processing. --Russ