NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTE: The netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
Hi Russ,
> > ... I think there
> > is also an implicit requirement that all APIs and features
> > from regular netCDF4 work as expected in parallel. (This is the case
> > for HDF5.)
>
> I notice that the Argonne/Northwestern group says about features not
> yet implemented in their Parallel-NetCDF software:
>
> ...
> - NC_FILL (no plan to implement)
>
> I'm not sure why they have no plans to implement this, but it may be
> that supporting the fill-value semantics of netCDF-3 to permit
> detection of unwritten values when reading defeats the performance
> gains the parallel interface makes possible. I think that trade-off
> would be OK (no automatic writing of fill-values when writing in
> parallel) for the sake of performance.
Hmm, we support fill-values in HDF5 for parallel I/O, so there's no reason
to cut it from the netCDF4 proposed feature list.
Quincey
netcdf-hdf archives: