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

[Tony Kelman]

Okay, I just put up a new set of mex files for Ipopt 3.11.8 at 
http://www.coin-or.org/download/binary/Ipopt/Ipopt-3.11.8-linux64mac64win32win64-matlabmexfiles.zip

I had to slightly change my procedure for the Mac version, since the old 
Apple GCC 4.2 compilers are not happy with thread-local storage that is now 
being used in Ipopt. So I used GCC 4.8.3 from Homebrew, linked statically 
into the mex file. The VM I built the Mac mex file in is running OS X 
Mountain Lion 10.8 with Matlab R2009b, so I'm curious to know whether it'll 
work properly on other Macs with different OS X versions, different Matlab 
versions, etc. Also I recall some issues with exception handling on more 
numerically challenging problems, which may still be an issue here (I did 
limited testing, only on the basic example problems).

-Tony


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

Yes this could help as I do no have the half of what Ipopt requires to 
compile :-)

Thanks a lot.

Arnaud

On May 28, 2014, at 10:08 PM, Tony Kelman <kelman at berkeley.edu> wrote:

> 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
>