[Ipopt] Ipopt Questions & Suggestions

[Andreas Waechter]

Hi Drosos,

Thank you for your kind message.

In the future, please send email regarding Ipopt to the Ipopt mailing list 
(http://list.coin-or.org/mailman/listinfo/ipopt) - the correspondence 
might be of interest to others, and it also might be that someone else has 
a better answer than I do.

> thank you very much for the wonderful piece of software you are hanging 
> out to us for free. I have a couple of questions to ask and also some 
> suggestions to make.
>
> COMPILATION:
> ============
> There are some problems I have found with the configuration. I have been 
> using PARDISO since it was publicly released. In the configuration I 
> supplied:
>
> configure --with-blas="-Lmyblasdir/ -lmyblas" 
> --with-pardiso="-Lmypardisodir/ -lmypardiso".
> The names -lmyblas and -lmypardiso are fake just to illustrate how I 
> configured. As BLAS I used intel mkl blas libraries and as mypardiso a 
> name which is NOT libpardiso.so but something else.
>
> The problem is that I cannot run any of the cpp examples. The message I 
> get is:
>
>
> Exception of type: OPTION_INVALID in file "IpAlgBuilder.cpp" at line 319:
> Exception message: Selected linear solver Pardiso not available.
> Tried to obtain Pardiso from shared library "libpardiso.so", but the following error occured:
> libpardiso.so: cannot open shared object file: No such file or directory
>
> EXIT: Invalid option encountered.
>
>
> *** The problem FAILED!
>
>
> I have to copy libmypardiso.so to ../../lib/, and rename it 
> ../../lib/libpardiso.so. Otherwise the executable will always give me 
> the same error message. Why isn't that taken care of, in the 
> configuration step? I mean, what is the reason to specify my own pardiso 
> library --with-pardiso=, if that doesn't help and any executable is 
> trying to find libpardiso.so?

There are two ways in which Pardiso can be used:

1. If you configure Ipopt telling it where the Pardiso library is (with 
--with-pardiso), Ipopt will be compiled, assuming that Pardiso is 
available, and the executables will be linked with the Pardiso library you 
specified.  Since Pardiso is a shared object, you will need to make sure 
that the library (however you called it, it does not need to be called 
libpardiso.so) can be found, e.g., by setting LD_LIBRARY_PATH accordingly.

Since you used the --with-pardiso flag in your configuration, this is what 
should have happened.  But something seems to have gone wrong there, and 
therefore you actually see the second option:

2. If Ipopt has not been configured with a --with-pardiso option, the 
compilation takes places without knowing anything about Pardiso.  However, 
if once chooses "linear_solver=pardiso" as option, Ipopt then tries to 
look for a shared objected called "libpardiso.so" and tries to load this 
dynamic library to obtain the symbol for the pardiso call.  In your 
output, we can see that this is what is happening:

Tried to obtain Pardiso from shared library "libpardiso.so"...

but if failed to do that as well.


So, you probably want to make sure option 1 goes through correctly.  I 
suggest you start over from the beginning again, specifying both 
--with-blas and --with-pardiso (make sure the spelling is correct, 
otherwise the flags are ignored, there is no error or warning message if 
unknown --with-* flags are used).  In the configure output, you should see 
something like:

checking whether user-supplied Pardiso library "/home/andreasw/lib/libpardiso.so" works... yes

about 80 lines or so before the end of the output.  If this line is not 
there, you somehow gave incorrect configure options.

> HESSIAN :
> =========
> Most PDE constraint Optimization problems, do not allow an easy 
> evaluation of gradients of the objective with respect to the controls 
> variables. First gradients may be obtained by the Adjoint formulation. 
> Unfortunately the Hessian, is extremely hard to obtain. There are some 
> publications however, where a method is suggested which can evaluate the 
> action of the Hessian on a given vector. Isn't that enough for interior 
> point methods? If yes, then could it be implemented in a future version 
> of IPOPT? Could you provide some hints?

Ipopt has the option to approximate the Hessian via a quasi-Newton method, 
see the documentation.  This works in many cases, but it can also make the 
algorithm less robust and you might have to experiment with some options 
(particularly regarding termination).  In that case you don't need to 
provide any second derivative information.

Hessian-vector products are not enough for Ipopt.  Ipopt obtains the 
search direction by solving a linear system of questions by means of a 
factorization (this is what you need Pardiso or another linear solver 
for), and you need to have the full matrix available at this point.  If 
one would use an iterative linear solver to solve this augmented system, 
matix-vector products would suffice, but Ipopt does not (yet) have this 
option, and in such a case the user would also have to provide a 
preconditioner (for the entire augmented system) which opens a big can of 
worms.  So, at this point, Hessian-vector products are not enough.  In the 
far future this might change... :-)

> P.S.
> excellent C++ by the way with the exception of coding standard,
> and configure script! I prefer simple Makefiles. They make life
> much-much easier and less troublesome.

We decided to use the autotools for Ipopt and many COIN-OR projects. 
This makes protability much easier, and when it works it is much easier to 
use than asking users to edit their makefiles, particularly for complex 
software projects.  But it also makes the actual Makefiles (now machine 
generated) rather complex.  But as a user, you don't need to use those, 
you can work with simple makefiles as they are found in the examples 
directories.

I hope this helps,

Andreas