[Ipopt] Linear Solver Loader with MUMPS?

[Stefan Vigerske]

Hi,

I think I can answer a few of these...

> I have downloaded IPOPT 3.4.0 and set about trying to compile it. I'm
> very pleased to see the work on the Linear Solver Loader that will make
> it much easier to distribute programs that use IPOPT. I just had a few
> questions...
> 
>    1. BLAS and LAPACK are listed as external code that must be
>       downloaded, but I haven't downloaded those as instructed and yet
>       IPOPT still compiles. I presume this means that the copies of BLAS
>       and LAPACK already on my (Linux) system have been detected. Is
>       that true? 

Yes, I guess so.
It should be indicated by the configure run, something like "lapack 
library found"...

>    2. It's possible to compile IPOPT without any linear solvers being
>       available at build-time. I see that there is a IPOPT Option
>       available to allow the linear solver to be selected at runtime.
>       But how can I query the list of available linear solvers at
>       runtime, such that I can ensure I pick a valid solver?

I think there is no option currently. When you run it with 
"print_documentation yes" (or similar) then you should get a list of all 
interfaces that have been compiled in.
To check which ones are available, Ipopt would need to try to load the 
corresponding shared objects to see whether they are available and 
functioning. Such a feature is not implemented (yet).

> What if I
>       have a default build of IPOPT and I have libpardiso.so on my
>       system, but not libhsl.so -- will libpardiso.so be selected
>       automatically?

No.
It's more on a trial-and-error basis currently. ;-)

>    3. Is there documentation available on the API required in the
>       dlopenable shared libraries used by the Linear Solver Loader?

No.
The "API" is tailored exactly to the solvers (see 4).

>    4. If I wanted to add support for a new linear solver, would it
>       require changes to libipopt.so, or can it be registered
>       dynamically at runtime?

I think it requires changes it libipopt.so. There is no dynamic load for 
an object that implements the SparseSymLinearSolverInterface methods 
implemented currently. That sounds like an interesting feature, but I do 
not know if there are enough people who would actually use it. Probably 
they would then prefer to build their own Ipopt library with their own 
linear solver included.

The dynamic load of HSL and Pardiso routines works on a very low level 
basis, i.e., it just loads exactly the available symbols of HSL (ma27id, 
ma27ad, ma57ad, ...) or Pardiso (pardisoinit, pardiso). The actual Ipopt 
to HSL and Pardiso interfaces are still in the libipopt.so.
This has the advantage that you do not need to use any Ipopt code to 
create the linear solver shared libraries. For Pardiso, you can even 
just use the libraries that they provide on their webpage.

Well, so if you want to use the linear solver loader to load your own 
linear solver, then you would need to make your linear solver look like 
either MA27, MA57, or Pardiso, i.e., implement the same functions (same 
names, same parameters, same behaviour). This way you would somehow fake 
a MA27, or ... solver for the Ipopt which could work.
But I wouldn't call it an API, and so it also does not need 
documentation ;-).

>    5. If I downloaded HSL into the ThirdParty directory, can I control,
>       using ./configure, whether HSL is statically or dynamically linked
>       to IPOPT, or whether the Linear Solver Loader .so file is instead
>       generated? How do I do that? Or is it determined just by the
>       absence/presence of the ma27ad.f file at configure-time?

Andreas knows better about this.
If there is no ma27ad.f, then Ipopt is build with the linear solver 
loader, and it tries to find a libhsl.so with a ma27ad symbol at runtime 
(if the linear_solver option says "ma27").
There is some configure option to tell that a dynamically loadable 
library should be generated, but I forgot the exact functionality :-(. 
At least when you checkout ThirdParty/HSL separately then you should be 
able to use it to build a libhsl.so that works with the linear solver 
loader.

>    6. Is there any plan to migrate MUMPS to a dlopenable solver, rather
>       than it always being statically linked?

Short answer: Yes, but nothing urgent.
Long answer: Originally the motivation to do the linear solver loader 
was to be able to provide Ipopt libraries where the user can plug in HSL 
and Pardiso if they are ok with the licensing issue. Since with MUMPS 
their is no licensing problem (as far as I know), there is also no 
linear solver loader interface for it.
However, a problem that came up from time to time with MUMPS is that it 
requires a Fortran90 compiler to build, and especially for Windows 
systems this seem to be a hard requirement. To make things work easier 
here, one could provide an already compiled MUMPS libraries for public 
download somewhere and let Ipopt use it either at build time (by some 
--with-mumps options) or at run time (via the Linear Solver Loader). The 
former has the advantage that Ipopt with Mumps could be build without a 
Fortran 90 compiler (or, on Windows, using f2c for blas and lapack, even 
without a Fortran compiler at all), but the user also needs to provide 
the fortran90 runtime libraries belonging to the fortran compiler that 
was used to build the mumps library (libifcore.so and co. in case of 
ifort; libgfortran... in case of gfortran). Even though I think it is 
allowed to be make them available for public download, they at least 
make the linkage more tricky again (many linker parameters...).
Creating a mumps.dll that can be load at runtime may be a good way out, 
since such a dll (as Andreas told me) is completely self contained, 
i.e., would contain already all fortran library dependencies (should be 
a big file then).

Best,
Stefan

-- 
Stefan Vigerske
Humboldt University Berlin, Numerical Mathematics
http://www.math.hu-berlin.de/~stefan