[Coin-ipopt] Re: IPOPT

[Andreas Waechter]

Hi Iain,

Many thanks for your message and your interest in IPOPT.  I'm sending my
reply also to the IPOPT mailing list, since it might answer questions
that other users also have.

> I read from the archives that you were hoping to make a release of a beta of
> an improved version of IPOPT.

As a matter of fact, I released it last night as the official version -
see the last announcement on the coin-ipopt mailing list. :)

> Around 18 months ago I had a look at the version as it was
> then but found some problems with the possibility of using it as a component
> in an application (we develop Windows applications).  These were as follows:
>
>
>
> (1)     The Readme file indicated (if I recall correctly) that there were
> too many adjustable parameters and that this would have to be rationalized.

There are still many adjustable parameters available, but you don't have
to set them all by hand, since they have reasonable default values.  You
only need to worry about an option if you want to change it.

In the new release, I tried to clean up the READM.IPOPT file somewhat, and
in particular I separated the description of the available options into
two parts.  The first describes options that at some point might be of
interest for a regular user; those are not too many.  The other part has
the 'expert' options, that nobody except the developers should need.

> (2)     There was no way of computing the required amount of workspace
> memory required.  If it ran out of memory it would simply execute a Fortran
> STOP statement and there would be no indication how much more memory would
> be required.

As I mentioned in the announcement, IPOPT now uses dynamic memory
allocation, so that you wouldn't have to worry about this anymore.  This
is done via a wrapper to C's malloc, so you will need a C compiler (and a
Fortran compiler that understands the '%VAL' command).  This works fine
(without user intervention) on all UNIX/Linux/Cygwin platforms I have
tested.  It also works on Windows with native compilers (I have tested it
on Microsoft Visual Studio 2003 (Standard) with the Intel Fortran 8.0
compiler, and project files are provided).

By the way, the previous version of IPOPT didn't just 'STOP', but properly
returned with an error code (IERR = 98 or 99).  :-)

> (3)     It required the use of TRON (for certain options), and when I
> downloaded the then current version of TRON, I found that the main routine
> had a different number of arguments to what was used in the code.

The new version no longer requires TRON, at least not if you use the
full-space option of IPOPT (which is the default and which is probably
what you want to use anyway).

For the reduced-space option, TRON is still the only restoration phase
for the filter line search.  Your observation that the number of arguments
differs is correct.  This is because the TRON source code actually has to
be modified first before it can be compiled with IPOPT.  For this, patch
files are included that have to be applied to the TRON source first.  On a
UNIX-like system, all this is done automatically if one follows the
instructions in the INSTALL file.

> Finally (though this is not so critical), is the
> solve thread-safe?  If not, does it make extensive use of COMMON blocks and
> SAVE statements?

The current implementation of IPOPT is not thread-safe.  It uses COMMON
blocks (which one could probably easily get rid of).  But more
importantly, it uses a lot of SAVE statements, and changing this would
require major re-writing.  In the future we might consider a
reimplementation of IPOPT in C, which would then be threadsafe, but this
is not going to happen within the next few weeks.

I hope this answers you questions.

Best regards,

Andreas