On Feb 13, 2014, at 7:30 PM, Ralph Castain <r...@open-mpi.org> wrote:
> Hmmm...well, a little digging says that we probably didn't do this as > thoroughly as we should have :-/ Actually, it works exactly as we designed it... but the reasons for doing so (and its effects) are a bit obscure. OMPI imports the ROMIO implementation for MPI I/O functionality. ROMIO actually includes 2 things: the MPI I/O API (i.e., the MPI_File_* functions, constants, and handles), and the back-end implementation of the MPI I/O API. In the bundled ROMIO, we only use the latter and disable the former (and let OMPI provide its own MPI_File_* functions, constants, and handles). A long time ago, someone had the need to use a newer ROMIO than we bundled in OMPI. So we created the "turn all MPI I/O functionality off" configure switch. This not only disables ROMIO, it also disables OMPI's MPI I/O API functions, constants, and handles. It therefore lets someone use an external ROMIO and let ROMIO provide the MPI_File_* functions, constants, and handles. The other option is as you mentioned: just disabling ROMIO. In the v1.6 series, if you disable ROMIO and try to use an MPI_File_* function, it should fail at run-time. In the v1.7 series, it should transparently switch to use the OMPIO plugin (our implementation of the MPI I/O functionality). See the attached PPT for how this looks pictorially. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
ompi-mpi-io-functionality.pptx
Description: ompi-mpi-io-functionality.pptx
