[Ipopt] Same initialization but different solutions (notthe case with fmincon or KNitro)

[Tony Kelman]

It sounds like it might help out if I built a new set of mex files for the 
latest version of Ipopt. I'll try to make some time to do that over the next 
couple days.


-----Original Message----- 
From: Arnaud Barré
Sent: Wednesday, May 28, 2014 7:49 AM
To: Majewski, Kurt ; ipopt at list.coin-or.org
Subject: Re: [Ipopt] Same initialization but different solutions (notthe 
case with fmincon or KNitro)

Thanks to Kurt Majewski message (see below), I resolved my problem somehow.

All my previous tests were done on MacOS X (10.9) with Matlab R2014a 
(64-bit). I downloaded the latest binary proposed for this configuration: 
“Ipopt-3.11.0-linux64mac64win32win64-matlabmexfiles.zip”.

As suggested by Kurt, I downloaded a newer version of Ipopt 
(Ipopt-3.11.3-win32win64-matlabmexfiles.zip) and I ran my code on a Window 
machine as the proposed Mex files are only for Windows (Windows XP 32-bit, 
Matlab R2008b).

This time, I have exactly the same result between the different runs! So, I 
try another test by using Ipopt-3.11.0 on the Windows machine and I have 
also the same results… However, this machine has only 1 core (in fact, this 
is a virtualized machine), which could explain why it works with 
Ipopt-3.11.0 under Windows. To see if the problem is related to the 
multithreading under MacOS X, I launched Matlab with the option 
“-singleCompThread”. But I still have the same problem.

I can provide a small example of my problem if someone has a newer version 
of Ipopt on MacOS X. On the other hand, I will try to compile also the 
latest version of Ipopt for MacOS X to see if the problem comes from the MEX 
file proposed in the file 
“Ipopt-3.11.0-linux64mac64win32win64-matlabmexfiles.zip”.

Thanks everybody for your time, and thanks to the developers for this 
incredible tools!

Arnaud

On May 28, 2014, at 5:56 AM, Majewski, Kurt <kurt.majewski at siemens.com> 
wrote:

> Hi Arnaud,
>
> I noticed that you are using Ipopt 3.11.0.
> Perhaps you should update to version 3.11.8,
> in which a bug introduced in version 3.11.0
> (related to tags) has been corrected.
> This bug can cause non-deterministic behavior,
> since its occurrence depends on the memory
> allocation. Such an update could rule out that
> this bug is the reason for your observations.
> (In my case the small differences caused
> "restoration failed" errors after about 20
> iterations.)
>
> With best regards,
> Kurt Majewski
> Siemens AG
> Corporate Technology
> CT RTC BAM ORD-DE
> Otto-Hahn-Ring 6
> 81739 Munich, Germany
> Tel.: +49 89 636-41639
> Fax: +49 89 636-42284
> mailto:kurt.majewski at siemens.com
>
> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard 
> Cromme; Managing Board: Peter Loescher, Chairman, President and Chief 
> Executive Officer; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe 
> Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. 
> Solmssen, Michael Suess; Registered offices: Berlin and Munich, Germany; 
> Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
> WEEE-Reg.-No. DE 23691322