[Ipopt] Linear Solver Loader with MUMPS?

Thu May 8 13:55:49 EDT 2008

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.

Damien
  _____  

From: Stefan Vigerske [mailto:stefan at math.hu-berlin.de]
To: John Pye [mailto:john.pye at anu.edu.au], ipopt at list.coin-or.org
Sent: Wed, 07 May 2008 03:12:09 -0600
Subject: Re: [Ipopt] Linear Solver Loader with MUMPS?

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
  _______________________________________________
  Ipopt mailing list
  Ipopt at list.coin-or.org
  http://list.coin-or.org/mailman/listinfo/ipopt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.coin-or.org/pipermail/ipopt/attachments/20080508/71e08c4c/attachment.html 