[Ipopt] [mumps-users] Ipopt MUMPS interface and MPI problems

Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade at gmail.com
Thu Jul 10 09:05:45 EDT 2014


2014-07-09 20:09 GMT-03:00 Stefan Vigerske <stefan at math.hu-berlin.de>:
> Hi,

  Hi,

> There is a check for MPI_Initialized in configure, which should make sure
> that HAVE_MPI_INITIALIZED is defined in case the function is available.
> Did you have to set it by hand because you use a selfmade build system, or
> does the check in configure not work in your case? If the latter, it might
> be interesting if it could be fixed.

  I preferred to add -DHAVE_MPI_INITIALIZED=1 to C{,XX}FLAGS as this
is supposed to make it clear detection was correct. It is (apparently) not
properly handling whatever is passed to --with-mump-* options to the build
of the test program, which fails to link due to undefined MPI_Initialized
symbol.

  Another issue I am having is that Fedora has openmpi, and while the
latest MUMPS package has a parallel and a sequential build, I cannot
make a single Ipopt build because MUMPS apparently does not provide
enough stubs for openmpi. To avoid needing an explicit -lmpi_cxx in
"pkg-config --libs ipopt" I patched to add
#define OMPI_SKIP_MPICXX 1
before include of mpi.h, but that still does not work if later using the
sequential MUMPS, due to missing ompi_mpi_comm_world symbol.
I tried building a MUMPS with a stub ompi_mpi_comm_world symbol
in the sequential MUMPS, but then it fails due to the missing
_ZN3MPI8Datatype4FreeEv symbol

$ c++filt _ZN3MPI8Datatype4FreeEv
MPI::Datatype::Free()

and that should be enough to give up attempting a single Ipopt
build, as would need to add C++ stubs to MUMPS (only C) to
avoid that, or maybe the problem lies in openmpi that should not
have generated that dependency when OMPI_SKIP_MPICXX
was defined.

> Stefan
>
>
>
> On 07/10/2014 12:36 AM, Dominique Orban wrote:
>>
>> I'm using 3.11.8 but the problem persists unless you build with
>> -DHAVE_MPI_INITIALIZED.
>>
>> Dominique
>>
>>
>> On Wed, Jul 9, 2014 at 6:29 PM, Paulo César Pereira de Andrade <
>> paulo.cesar.pereira.de.andrade at gmail.com> wrote:
>>
>>> 2014-07-09 17:37 GMT-03:00 Dominique Orban <dominique.orban at gmail.com>:
>>>
>>>    Hi,
>>>
>>>> In Homebrew, we compile IPOPT with -DHAVE_MPI_INITIALIZED to get around
>>>> this. See
>>>> https://github.com/Homebrew/homebrew-science/blob/master/ipopt.rb#L36
>>>
>>> and
>>>>
>>>> recent discussions on the IPOPT mailing list.
>>>
>>>
>>>    Many thanks! I was indeed trying to fix the package and did not
>>> notice that the latest release already have the solution for the problem.
>>>
>>>> Dominique
>>>>
>>>>
>>>> On Wed, Jul 9, 2014 at 3:45 PM, Paulo César Pereira de Andrade
>>>> <paulo.cesar.pereira.de.andrade at gmail.com> wrote:
>>>>>
>>>>>
>>>>>    Hi,
>>>>>
>>>>>    The Ipopt MUMPS interface calls MPI_Init in the class constructor
>>>>> and MPI_Finalize in the destructor. But openmpi causes a fatal
>>>>> error due to it:
>>>>>
>>>
>>> --------------------------------------------------------------------------
>>>>>
>>>>> Calling MPI_Init or MPI_Init_thread twice is erroneous.
>>>>>
>>>
>>> --------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> Debian uses this patch for Ipopt:
>>>>>
>>>>>
>>>>>
>>>
>>> http://sources.debian.net/src/coinor-ipopt/3.11.7-2/debian/patches/mpi-init.patch
>>>>>
>>>>>
>>>>> But "only" that patch causes the Ipopt testsuite to fail due to calling
>>>>> MPI functions before MPI_Init.
>>>>>
>>>>> What is the proper way to handle it? I believe it should be
>>>>> somewhat like only call MPI_Init and MPI_Finalize from the
>>>>> test suite main function, but I have few knowledge of all
>>>>> details (e.g. maybe only required if linking Ipopt to a parallel
>>>>> MUMPS) ...

Thanks,
Paulo



More information about the Ipopt mailing list