octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: octave-mpi questions


From: Martin Siegert
Subject: Re: octave-mpi questions
Date: Mon, 24 Feb 2003 21:03:51 -0600
User-agent: Mutt/1.4i

On Fri, Feb 21, 2003 at 07:01:25PM -0600, John W. Eaton wrote:
> On 21-Feb-2003, Martin Siegert <address@hidden> wrote:
> 
> | My impression is that MPICH2 is really beta (e.g., the F90 interface does
> | not exist yet).
> 
> We only need a C interface, so I don't think this matters much.  Other
> than missing interfaces, are there serious problems with MPICH2?

It's not that octave may be able to live with an incomplete version -
replacing the MPI library means that all other MPI programs have to
be able to use that version. It is impossible (at least from a support
point of view) to have a different MPI implementation for every and
each program.

> | The only MPI-1 compliant way of calling MPI_Init is
> | MPI_Init(&argc,&argv);
> | The question now is: is there a way to provide octave's command line
> | arguments to the mpi_init module?
> 
> Sure, they are already available in the argv variable that is defined
> when Octave starts.  But this is just a copy in an octave_value
> object, so you would need to convert it back to an array of C
> character strings.
> 
> In the thread starting here:
> 
>   http://www.octave.org/octave-lists/archive/help-octave.2001/msg00138.html
> 
> a claim was made that the argv/argc passed to MPI_Init must be
> pointers to the actual variables passed to main, and that MPI_Init
> needs to see them before they are processed by the program that calls
> MPI_Init.  The MPI standard may claim that those are requirements, but
> so far, no one has been able to explain *why* the standard includes
> these requirements.  Also, there was a claim that bad things happen if
> the function that calls MPI_Init returns, and I'm not sure whether
> that is another limitation of the standard or was simply due to a
> buggy implementation.
> 
> So, can anyone tell me *why* these things should cause problems?  It
> seems to me that we should be able to define  MPI_Init in Octave that
> does something like
> 
>   mpi_init (argv)
> 
> where argv is a cell array of strings that are packaged as appropriate
> and passed on to the C MPI_Init.

>From the MPI-1.1 Standard:
<quote>
An MPI implementation is free to require that the arguments in the C binding
must be the arguments to main.

Rationale.

The command line arguements are provided to MPI_Init to allow an MPI
implementation to use them in initializing the MPI environment. They are
passed by reference to allow an MPI implementation to provide them in
environments where the command-line arguments are not provided to main.
</quote>

E.g., under mpich running "mpirun -np 5 ./octave-2.1.44 -q mpi_test.m" will
cause an exec of

./octave-2.1.44 -q mpi_test.m -p4pg /usr/local/src/mpi_octave-ss20021218/PI9261 
-p4wd /usr/local/src/mpi_octave-ss20021218

> Then users could pass whatever
> arguments they like to the MPI system and we wouldn't have to modify
> Octave's main program or argument processing at all (except perhaps we
> would need a way start Octave and have it run a function and then
> continue processing, so the client processes would know to go into
> listener mode, waiting for commands from the server process).

I users cannot pass whatever they like to the MPI system. They must pass
those command line arguments that are important for the MPI environment:
In the example above that would be "-p4pg ... -p4wd ...".
That part must be included when calling MPI_Init().

> It would also be nice if Octave's mpi_init could start the client
> processes, so you wouldn't have to use mpirun (or similar) to do that
> when initially starting Octave.
> 
> There was another thread about these issues starting here:
> 
>   
> http://www.octave.org/octave-lists/archive/octave-maintainers.2002/msg00207.html

I cannot see how you can avoid "mpirun". Furthermore, I'd find I that highly
undesirable: MPI users are used to start their programs with mpirun.

Cheers,
Martin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]