<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN'>
<html>
<head>
<meta http-equiv='Content-Type' content='text/html;charset=us-ascii'>
<style>BODY{font:10pt Tahoma, Verdana, sans-serif;}</style>
</head>
<body>
In about a month I'll be in a position to provide Windows-built MUMPS libs/dlls/so's. I don't have the bandwdth to host them, but I can build them and supply them to someone who can host. MUMPS on Windows is pretty straightforward, there's a project called WinMumps (Google for it) or you can use SCons.<br><br>Damien<br><blockquote style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px; margin-right: 0px;"><hr><b>From:</b> Stefan Vigerske [mailto:stefan@math.hu-berlin.de]<br><b>To:</b> John Pye [mailto:john.pye@anu.edu.au], ipopt@list.coin-or.org<br><b>Sent:</b> Wed, 07 May 2008 03:12:09 -0600<br><b>Subject:</b> Re: [Ipopt] Linear Solver Loader with MUMPS?<br><br>Hi,<br>
<br>
I think I can answer a few of these...<br>
<br>
> I have downloaded IPOPT 3.4.0 and set about trying to compile it. I'm<br>
> very pleased to see the work on the Linear Solver Loader that will make<br>
> it much easier to distribute programs that use IPOPT. I just had a few<br>
> questions...<br>
> <br>
> 1. BLAS and LAPACK are listed as external code that must be<br>
> downloaded, but I haven't downloaded those as instructed and yet<br>
> IPOPT still compiles. I presume this means that the copies of BLAS<br>
> and LAPACK already on my (Linux) system have been detected. Is<br>
> that true? <br>
<br>
Yes, I guess so.<br>
It should be indicated by the configure run, something like "lapack <br>
library found"...<br>
<br>
> 2. It's possible to compile IPOPT without any linear solvers being<br>
> available at build-time. I see that there is a IPOPT Option<br>
> available to allow the linear solver to be selected at runtime.<br>
> But how can I query the list of available linear solvers at<br>
> runtime, such that I can ensure I pick a valid solver?<br>
<br>
I think there is no option currently. When you run it with <br>
"print_documentation yes" (or similar) then you should get a list of all <br>
interfaces that have been compiled in.<br>
To check which ones are available, Ipopt would need to try to load the <br>
corresponding shared objects to see whether they are available and <br>
functioning. Such a feature is not implemented (yet).<br>
<br>
> What if I<br>
> have a default build of IPOPT and I have libpardiso.so on my<br>
> system, but not libhsl.so -- will libpardiso.so be selected<br>
> automatically?<br>
<br>
No.<br>
It's more on a trial-and-error basis currently. ;-)<br>
<br>
> 3. Is there documentation available on the API required in the<br>
> dlopenable shared libraries used by the Linear Solver Loader?<br>
<br>
No.<br>
The "API" is tailored exactly to the solvers (see 4).<br>
<br>
> 4. If I wanted to add support for a new linear solver, would it<br>
> require changes to libipopt.so, or can it be registered<br>
> dynamically at runtime?<br>
<br>
I think it requires changes it libipopt.so. There is no dynamic load for <br>
an object that implements the SparseSymLinearSolverInterface methods <br>
implemented currently. That sounds like an interesting feature, but I do <br>
not know if there are enough people who would actually use it. Probably <br>
they would then prefer to build their own Ipopt library with their own <br>
linear solver included.<br>
<br>
The dynamic load of HSL and Pardiso routines works on a very low level <br>
basis, i.e., it just loads exactly the available symbols of HSL (ma27id, <br>
ma27ad, ma57ad, ...) or Pardiso (pardisoinit, pardiso). The actual Ipopt <br>
to HSL and Pardiso interfaces are still in the libipopt.so.<br>
This has the advantage that you do not need to use any Ipopt code to <br>
create the linear solver shared libraries. For Pardiso, you can even <br>
just use the libraries that they provide on their webpage.<br>
<br>
Well, so if you want to use the linear solver loader to load your own <br>
linear solver, then you would need to make your linear solver look like <br>
either MA27, MA57, or Pardiso, i.e., implement the same functions (same <br>
names, same parameters, same behaviour). This way you would somehow fake <br>
a MA27, or ... solver for the Ipopt which could work.<br>
But I wouldn't call it an API, and so it also does not need <br>
documentation ;-).<br>
<br>
> 5. If I downloaded HSL into the ThirdParty directory, can I control,<br>
> using ./configure, whether HSL is statically or dynamically linked<br>
> to IPOPT, or whether the Linear Solver Loader .so file is instead<br>
> generated? How do I do that? Or is it determined just by the<br>
> absence/presence of the ma27ad.f file at configure-time?<br>
<br>
Andreas knows better about this.<br>
If there is no ma27ad.f, then Ipopt is build with the linear solver <br>
loader, and it tries to find a libhsl.so with a ma27ad symbol at runtime <br>
(if the linear_solver option says "ma27").<br>
There is some configure option to tell that a dynamically loadable <br>
library should be generated, but I forgot the exact functionality :-(. <br>
At least when you checkout ThirdParty/HSL separately then you should be <br>
able to use it to build a libhsl.so that works with the linear solver <br>
loader.<br>
<br>
> 6. Is there any plan to migrate MUMPS to a dlopenable solver, rather<br>
> than it always being statically linked?<br>
<br>
Short answer: Yes, but nothing urgent.<br>
Long answer: Originally the motivation to do the linear solver loader <br>
was to be able to provide Ipopt libraries where the user can plug in HSL <br>
and Pardiso if they are ok with the licensing issue. Since with MUMPS <br>
their is no licensing problem (as far as I know), there is also no <br>
linear solver loader interface for it.<br>
However, a problem that came up from time to time with MUMPS is that it <br>
requires a Fortran90 compiler to build, and especially for Windows <br>
systems this seem to be a hard requirement. To make things work easier <br>
here, one could provide an already compiled MUMPS libraries for public <br>
download somewhere and let Ipopt use it either at build time (by some <br>
--with-mumps options) or at run time (via the Linear Solver Loader). The <br>
former has the advantage that Ipopt with Mumps could be build without a <br>
Fortran 90 compiler (or, on Windows, using f2c for blas and lapack, even <br>
without a Fortran compiler at all), but the user also needs to provide <br>
the fortran90 runtime libraries belonging to the fortran compiler that <br>
was used to build the mumps library (libifcore.so and co. in case of <br>
ifort; libgfortran... in case of gfortran). Even though I think it is <br>
allowed to be make them available for public download, they at least <br>
make the linkage more tricky again (many linker parameters...).<br>
Creating a mumps.dll that can be load at runtime may be a good way out, <br>
since such a dll (as Andreas told me) is completely self contained, <br>
i.e., would contain already all fortran library dependencies (should be <br>
a big file then).<br>
<br>
Best,<br>
Stefan<br>
<br>
-- <br>
Stefan Vigerske<br>
Humboldt University Berlin, Numerical Mathematics<br>
<a href="http://www.math.hu-berlin.de/%7Estefan" target="_blank">http://www.math.hu-berlin.de/~stefan</a><br>
_______________________________________________<br>
Ipopt mailing list<br>
<a href="mailto:Ipopt@list.coin-or.org">Ipopt@list.coin-or.org</a><br>
<a href="http://list.coin-or.org/mailman/listinfo/ipopt" target="_blank">http://list.coin-or.org/mailman/listinfo/ipopt</a><br>
</blockquote><style>
</style>
</body></html>