Re: openmpi_ext successfully running with other mpi stacks

[c.]

On 6 Jun 2013, at 20:09, Sukanta Basu <address@hidden> wrote:

> ---------- Forwarded message ----------
> From: Doug James <address@hidden>
> Date: Wed, Jun 5, 2013 at 8:51 PM
> Subject: openmpi_ext successfully running with other mpi stacks
> To: "address@hidden" <address@hidden>
> Cc: "address@hidden" <address@hidden>, Robert McLay
> <address@hidden>, Yaakoub El-Khamra <address@hidden>,
> Bill Barth <address@hidden>
> 
> 
> Riccardo --
> 
> 
> 
> Sukanta Basu, one of scientists using the Stampede
> (http://www.tacc.utexas.edu/resources/hpc) supercomputer at the Texas
> Advanced Computing Center (TACC), recently contacted TACC for help
> deploying openmpi_ext on Stampede. Because we use mvapich2 and Intel
> MPI rather than OpenMPI on Stampede, we took a look at whether
> openmpi_ext would run under other MPI stacks. I'm happy to report that
> TACC's Yaakoub El-Khamra was quickly able to modify openmpi_ext so it
> would run under mvapich2 (essentially all he had to do was comment out
> the openmpi-specific components of the MPI_Status struct). Sukanta is
> in the early stages of testing his code, but reports that the mods
> appear to work fine. We'll eventually test it with impi as well, and
> have high confidence it will work.
> 
> 
> 
> Would you be interested in incorporating these mods into your product?
> If so, we'll be glad to supply them to you. If not, we'll likely
> proceed independently (complying with your GPLv3+ license of course)
> and make the modified code available for TACC users (and perhaps
> eventually to a wider audience).
> 
> 
> 
> If you are interested in the mods, I suggest considering a new name
> for your product so that it reflects its broader capabilities. In any
> case, we congratulate and thank you for your work on openmpi_ext, and
> wish you well on this and all your other initiatives.
> 
> 
> 
> Regards,
> 
> Doug James

Dear Doug,

I'm the current maintainer of the openmpi_ext package [*].
If you have patches to improve the package functionality
or its portability they are very welcome.

The correct procedure to get those patches in the repository
is to post them to the tracker on savannah [1], so they don't get forgotten 
and to discuss them on the maintainers' mailing list [2].

If you intend to do more extensive changes and work continuously on the package 
we may also arrange giving you direct access to the subversion repository.

If you prefer to fork the project and develop it indipendently,
as long as you comply with the prescription of the GPL,
that is of course one of the freedoms granted to you by the GPL
itself, but I do not recommend doing so.

Please be advised in particular that ongoing changes to the liboctave API
will probaly break the package compatibility with future versions of Octave.

As for the specific modification you refer to, it sounds OK, a similar 
change has actually been suggested before in order to allow
compatibility with different versions of openmpi [3],
yet, a better (cleaner and more portable) solution would be to interact with 
MPI_Status objects
via their public methods rather than accessing their private (and undocumented)
properties directly.

Best regards,
Carlo de Falco


P.S. we don't usually refer to the software we write as a "product"

[*] Actually I took over Riccardo's task since he was too busy to manage 
it at some point, but it seems his circumstances may be changing and I'd be 
really glad if he could take it again ;)
[1] https://savannah.gnu.org/patch/?group=octave
[2] https://mailman.cae.wisc.edu/listinfo/octave-maintainers
[3] http://octave.1599824.n4.nabble.com/openmpi-ext-tp4642719p4643859.html