[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: netcdf/nco bug
- Subject: Re: netcdf/nco bug
- Date: Wed, 13 Oct 2004 09:51:12 -0600
Mike,
> Thanks for the notes. I rebuilt NCO against:
> NETCDF_LIB=/usr/local/apps/netcdf-3.6.0-beta6/lib64/r4i4
> NETCDF_INC=/usr/local/apps/netcdf-3.6.0-beta6/include
>
> But I still have the same problem with ncks.
>
> If I build b+a.nc, I get a few vbls out of a but not many.
>
> I'm stumped. I'm going to read your FAQ in depth but if you have any
> further suggestions I'd be anxious to hear them.
In that case, I suspect this may be a problem with ncks, which will
need to be updated for use with netCDF-3.6.0. It's author (Charlie
Zender) hasn't had a chance yet to test his utilities with the
netCDF-3.6.0 library, and make whatever changes are necessary.
Now that I think about it, I'll bet that ncks needs to be modified in
the following way:
- By looking at the sizes of things and doing some arithmetic, it
should determine whether the output netCDF file requires 64-bit
offsets to the beginning of at least one of its variables.
- If a 64-bit offset output file is needed, it should call
nc_create() with the extra mode flag NC_64BIT_OFFSET.
Otherwise, it will still be creating classic-format netCDF files with
their rigid constraints required by using 32-bit file offsets.
Alternatively ncks and the other netCDF operators could add an
additional flag that indicates output files should use the 64-bit
offset format and let the user determine when and whether that is
necessary.
As a workaround for this user, you could test my theory by just
modifying the nc_create() calls in ncks to always generate files in
the new 64-bit offset format and see if it then works. However, these
files will not be accessible by other utilities that haven't also be
linked against 3.6.0, so this might be a problem until the transition
is further along.
Until Charlie Zender actually has a chance to look at this and decide
how best to update his utilities to make use of the new netCDF large
file facilities, I would recommend against users trying to manipulate
large netCDF files with ncks linked against the 3.6.0 library.
However, it should still be possible for the model Jeff is using to
directly write the large file he wants by using 3.6.0 and the
appropriate nf90_create() flag for 64-bit offset files.
I'm CC:ing Charlie Zender on this, to let him know about the
potential problem we are creating by releasing this beta software
before third-party developers have a chance to update their
utilities. However, I think we make it clear in the accompanying FAQ
that we discourage use of the new format unless it is absolutely
necessary due to the transition necessary to allow third-party
software to be upgraded to the new release:
http://my.unidata.ucar.edu/content/software/netcdf/faq-lfs.html
Charlie, I'm appending a draft of the note I'll send to netcdfgroup
soon to announce this beta release. It's really intended for
developers like you to give us feedback on what's in this release.
Sorry there are people jumping the gun on this, causing transition
problems like this one.
--Russ
To: netcdfgroup
Cc:
Subject: netCDF 3.6.0-beta6 with Large File Support
Reply-to: address@hidden
Organization: UCAR Unidata Program
Fcc: +outbox
Hi,
A new beta release of netCDF-3.6.0 is available for external testing:
ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-beta.tar.gz
Simplified installation instructions for the beta release are
available at:
http://www.unidata.ucar.edu/packages/netcdf/INSTALL-beta/
This release is close to final, but we would appreciate feedback on
any problems you might discover.
NetCDF version 3.6 improves large file support, Windows compatibility,
ease of installation, and performance using the Fortran-90 interface.
In addition, it fixes a few bugs, mostly associated with large file
support.
In previous releases it was possible to create netCDF files that
exceeded 2 GiB by observing fairly severe constraints on the structure
of the data. For example, you could use a single large fixed-size
variable for the last variable with no record variables, or you could
use the record dimension for all large variables with a large number
of records. Such restrictions were necessary due to the use of 32-bit
fields in the netCDF format for offsets that point to the beginning of
data for each variable.
Version 3.6 introduces a new variant of the netCDF file format, while
preserving backward compatibility with the existing format. The new
variant has 64-bit fields for file offsets, removing many of the size
constraints for netCDF files. Greg Sjaardema of Sandia Labs provided
the initial version of the C library code to support 64-bit offsets,
and we added changes to increase the maximum variable and record size,
to permit use from Fortran, C++, and Java interfaces, to support
creation of large files with the ncgen utility, and to check declared
variable shapes for conformance with remaining size constraints. The
new library will access data transparently in both the classic and
64-bit offset formats.
Version 3.6 is configured to make use Large File Support by default if
available on the target platform. Building and installing from source
has been simplified so that there is no need to set environment
variables on most platforms.
We are maintaining a list of questions and answers for netCDF large
file support:
http://www.unidata.ucar.edu/packages/netcdf/faq-lfs.html
More information about the 3.6.0-beta release is contained in the
RELEASE_NOTES:
http://www.unidata.ucar.edu/packages/netcdf/release-notes-3.6.0-beta6
or the new draft documentation:
http://www.unidata.ucar.edu/packages/netcdf/newdocs/netcdf/index.html
If you have other questions or encounter problems with the beta
release, please contact address@hidden. Thanks!
-- Russ Rew
-- Ed Hartnett