[Paraview-developers] ParaView plugins with MPI only on client

[Utkarsh Ayachit]

Burlen et. al.

As a compromise, this what I've done: http://review.source.kitware.com/#/t/2044/

+ The ParaView client processes (paraview and pvpython) now provide
two extra command line options "--mpi", "--no-mpi". Specifying one or
the other will make the client initialize MPI at startup.
+ The default to use when neither of the command line arguments is
specified is controlled by the CMake variable
PARAVIEW_INITIALIZE_MPI_ON_CLIENT. When this CMake variable is ON, and
no command line arguments are specified, ParaView clients will init
MPI at startup. One can override using the two new command line
options ("--mpi", "--no-mpi").
+ PARAVIEW_INITIALIZE_MPI_ON_CLIENT is OFF by default, so for people
building ParaView that are not aware of this, there will be no change.
+ We will enable PARAVIEW_INITIALIZE_MPI_ON_CLIENT on the official
ParaView binaries, so we can distribute readers, filters that rely on
MPI to run without too much hassle.

What do you think?

Utkarsh


On Mon, Jun 3, 2013 at 2:42 PM, burlen <burlen.loring at gmail.com> wrote:
> Hi Utkarsh,
>
> for my 0.02$ I don't find the idea of using mpi in the client very
> appealing. I think it's going to add complexity without delivering anything
> more than the current multicore option does.
>
> given what the mpi 3 spec says about startup, there will not be a portable
> solution any time soon (see below).
>
> I assume you'll still support client with out mpi? this will be useful for
> running the client on login nodes at hpc sites, many of which detect mpi
> programs and shut them down. For the mpi-less client codes like Michael's
> will crash it. therefor, we developers will need to do as we do now, either
> use VTK's controllers/communicators or avoid MPI calls when it's not
> available. assuming that client on login nodes is a use case that you intend
> to support, mpi in the client is not really going to make a developers life
> easier...would the hpc site then need two builds? one with mpi for server
> running on compute nodes and one without mpi for client running on login
> nodes?
>
> I'm curious as to what's wrong with the multicore solution as it stands?
> with muticore option, things just work for the user. readers/sources/filters
> don't execute in the client so the client doesn't need mpi at all. Are there
> any use cases where MPI is needed outside of a reader/soruce/filter?
>
> but say you wanted to do it what could you do?
> for startup you could do as you do now for server startups -- force the
> site/user to provide a pvsc (pvcc?), or perhaps force the site/user to
> describe the mpi startup command at build time similar to how parallel
> ctests currently work. to support running server with MPI and client
> without, it would be nice if you refactored the build so that client and
> server have independent MPI cmake configurations.
>
> Burlen
>
> from mpi 3.0 spec:
>
> """
> While a standardized startup mechanism improves the usability of MPI, the
> range of
> environments is so diverse (e.g., there may not even be a command line
> interface) that MPI
> cannot mandate such a mechanism. Instead, MPI speci es an mpiexec startup
> command
> and recommends but does not require it, as advice to implementors.
>
> """
>
> On 06/03/2013 07:55 AM, Utkarsh Ayachit wrote:
>>
>> Just FYI, we have plans to init MPI even for the client to simplify
>> the use-case that Michael has. At the same time, the issues with
>> "mpiexec" that John talks about for Windows (it also exists on Linux
>> with certain implementations) makes it tricky and hence is hasn't
>> happened yet. If any one has suggestions for a portable
>> implementation, let's start a new thread to discuss how that could be
>> done.
>>
>> Utkarsh
>
>