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

[Paulo César Pereira de Andrade]

2014-07-10 10:05 GMT-03:00 Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade at gmail.com>:
> 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 think I wrote too much details.

  Is it a known issue to be required to have two Ipopt builds, or is a single
Ipopt build supposed to work with either parallel or sequential MUMPS
(whatever is installed or in LD_LIBRARY_PATH)?

>   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