Building visit parallel version after serial version

[bruno-rescale]

I recently completed a serial build of visit 3.3.1 (latest) from a tarball. Here was my command below for the serial build. I have a 2-part question for building the parallel version.

./build_visit3_3_1 --no-thirdparty --cmake --python --zlib --vtk --qt
    --makeflags -j4 --prefix /program/visit/  --tarball visit3.3.1.tar.gz
    --mesagl --llvm --thirdparty-path /program/visit

(1) Are there meant to be 2 separate executables ( I believe it's /bin/visit). One for serial and one for parallel? Or should one only exist?

(2) For the parallel build and for the latest version 3.3.1, does the flag "--mpich" mean visit will use its own bundled MPI library (MPICH)? Are there any limitations with MPICH on any hardware to date? Does Visit have any preferred outside MPI implementation (intelmpi vs openmpi)? What about Intel OneAPI 2021.4, does visit support it?

Thanks in advanced!

[markcmiller86]

I recently completed a serial build of visit 3.3.1 (latest) from a tarball. Here was my command below for the serial build. I have a 2-part question for building the parallel version.

./build_visit3_3_1 --no-thirdparty --cmake --python --zlib --vtk --qt
    --makeflags -j4 --prefix /program/visit/  --tarball visit3.3.1.tar.gz
    --mesagl --llvm --thirdparty-path /program/visit

(1) Are there meant to be 2 separate executables ( I believe it's /bin/visit). One for serial and one for parallel? Or should one only exist?

Yes. Executables that do not have any dependence on parallel APIs (e.g. MPICH) will have _ser appended to their names and those that do whave dependence on parallel APIs will have _par appended to their names. Same application, different dependencies which often result in different ways of invoking them. VisIt is a multi-process application involving the viewer (main window where plots are displayed), the gui or cli (main interfaces to drive VisIt either by mouse clicks or key strokes) also called a client, mdserver (a lightweight process to tease metadata from possibly very large files or sets of files), engine_ser or engine_par (main process that does work to read and compute what gets rendered in the viewer) also called the server and if you are running in client/server mode (e.g. where client runs on a machine different from server), then also the vcl (visit component launcher) which gets launched on the server machine too. In client/server mode, gui (or cli) and viewer typically run on the client machine and engine_par and mdserver and vcl typically run on the server machine.

(2) For the parallel build and for the latest version 3.3.1, does the flag "--mpich" mean visit will use its own bundled MPI library (MPICH)?

Yes and it builds MPICH.

Are there any limitations with MPICH on any hardware to date?

Not that we are aware of. That said, there are likely cases where specialized hardware includes a vendor implementation of MPI that is tuned for that platform and may perform better than vanilla MPICH. In which case, you can try to cause build_visit to use it by controlling some enviornment variables (whose name's haven't kept up with recently and will need to seek guidance).

Does Visit have any preferred outside MPI implementation (intelmpi vs openmpi)? What about Intel OneAPI 2021.4, does visit support it?

I think VisIt is capable of working with any MPI implementation compliant with MPI 2 spec. I can't recall but I don't think we depend on MPI spec 3 yet.

Thanks in advanced!

[markcmiller86]

I think the env. variables to control build_visit where custom parallel MPI implementation is concerned are PAR_COMPILER (to specify path to c++ MPI compiler wrapper and, if necessary, PAR_INCLUDE and PAR_LIBS). See examples in our docs