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.
Hi, Ed, On Oct 7, 2009, at 2:47 AM, Ed Hartnett wrote:
I think the smart thing to do might be to have a separate header netcdf_par.h, which is included by people who want to use parallelI/O. This way, the sequential header (netcdf.h) does not need to containanything related to mpi.Right now, I also build nc_create_par/nc_open_par functions whether thebuild is for parallel or not. I think I will have to change that too.
I think the latter by itself would be sufficient. To use parallel it has to be compiled with mpi, anyway (and kept separate from the non- mpi version), so I think a separate header gets confusing. (Not that I ever use the C interface, but you have to have different paths for the mpi and non-mpi installs already, so there shouldn't be an extra need to change the name of the include file.)
What about having a dummy alternate non-mpi nc_create_par/nc_open_par routines that spit out an error if used in a non-mpi compile? ("You need to compile netcdf with MPI, you dolt.")
-- Ted
netcdfgroup archives: