Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
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: