A library providing high-performance I/O with Unidata's NetCDF
Parallel netCDF (PnetCDF) is a library providing high-performance I/O while still maintaining file-format compatibility with Unidata's NetCDF.
- Developed at science
- Sources inherited from project openSUSE:Factory
-
2
derived packages
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout openSUSE:Leap:16.0:FactoryCandidates/pnetcdf && cd $_
- Create Badge
Refresh
Refresh
Source Files
Filename | Size | Changed |
---|---|---|
_multibuild | 0000000420 420 Bytes | |
pnetcdf-1.12.2.tar.gz | 0002355892 2.25 MB | |
pnetcdf.changes | 0000061297 59.9 KB | |
pnetcdf.spec | 0000017011 16.6 KB |
Revision 3 (latest revision is 5)
Dominique Leuenberger (dimstar_suse)
accepted
request 875412
from
Egbert Eich (eeich)
(revision 3)
- Update to version 1.12.2: * Updated utility program * ncvalidator now reports the name of variable that violates the NetCDF limitation on large variables for CDF-2 files * add corrupted file bad_large_fixed_var.nc2 that contains one large fixed-size variables that is not defined last * add corrupted file bad_large_rec_2_vars.nc2 that contains 2 large record variables * add corrupted file bad_large_rec_var.nc2 that contains 1 large record variable that is not defined last * add URLs of NetCDF limitations on large variables for CDF-1 and 2 file formats * Other updates: * When calling ncmpi_create() with NC_CLOBBER flag, PnetCDF now calls access() to check whether file exists first. If the file does not exist, successive calls to truncate() or unlink() can be skipped. * Improve detection of HDF5 signature. The HDF5 signature is located at the beginning of the HDF5 superblock, but the location of HDF5 superblock may not be at the beginning of the file. It is located at byte offset 0, byte offset 512, and at successive locations in the file, each a multiple of two of the previous location; in other words, at these byte offsets: 0, 512, 1024, 2048, and so on. * Bug fixes * Fix NC_CLOBBER mode for ncmpi_create() when files are existing symbolic links. Prior to this release, symbolic links, like other regular files, was first deleted and then created. This can result in an unexpected outcome, i.e. the deletion of symbolic link. NetCDF-4 library implements this differently, by adding O_TRUNC flag when calling open() to truncate the file to length 0. Historically, PnetCDF did not adopt the same approach because MPI does not define a similar flag to O_TRUNC and the only way to
Comments 0