[Ipopt] Same initialization but different solutions (notthe case with fmincon or KNitro)
Arnaud Barré
arnaud.barre at gmail.com
Thu May 29 11:15:01 EDT 2014
After following your instructions to compile Ipopt, the results is… It works!
Let me know if you want to find the issue related to the proposed MacOS MEX file (Apple BLAS library?), I can now recompile differently Ipopt and test other configurations.
Thanks a lot for your time.
Arnaud
On May 29, 2014, at 9:58 AM, Arnaud Barré <arnaud.barre at gmail.com> wrote:
> The output of the script ‘main’ on Matlab R2014 (MacOS 64-bit) is the following:
>
> ----------------------------------------------------------
> STATISTICS
> ----------------------------------------------------------
> Results average
> ----------------------------------------------------------
> fmincon: -0.1621 0.1401 -0.7287 0.0964 1.0087 -0.5433 2.0622 0.5012 -0.3077
> Ipopt: -0.1657 0.1647 -0.7158 0.0657 0.9480 -0.5212 2.0945 0.5014 -0.2894
> ----------------------------------------------------------
> Results standard deviation
> ----------------------------------------------------------
> fmincon: 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
> Ipopt: 0.0010 0.0018 0.0014 0.0011 0.0049 0.0011 0.0042 0.0014 0.0006
>
> The tolerance convergence is set to 5.8e-7. Comparing to the results of the standard deviation, I am not in this range of error. I would expect zeros everywhere (as it is under Windows).
>
> What is the output under Linux?
>
> Thanks for the instructions, I will give it a try today.
>
> On May 29, 2014, at 9:45 AM, Tony Kelman <kelman at berkeley.edu> wrote:
>
>> Seems repeatable on my Linux machine. I'd put this down to Apple's BLAS library, most likely. You never answered my question of how different the results are (and it takes too long to start the Mac VM for me to check the numbers myself), if they're all within convergence tolerances then is this really that big of an issue? What do you need bitwise identical results for?
>>
>> We can try to compile a version of the mex file using the serial reference BLAS and see if that works, but it's annoying to build these in a VM so I'll give you instructions for how to do it.
>>
>> 1. Install homebrew (see command at bottom of http://brew.sh) and Xcode command line tools
>> 2. brew update
>> 3. brew install gcc
>> 4. Download Ipopt source code
>> 5. run ./get.Blas, ./get.Lapack, ./get.Metis, and ./get.Mumps respectively in ThirdParty/Blas, etc
>> 6. mkdir -p build/share
>> 7. cp Ipopt/contrib/MatlabInterface/MatlabInterface.site build/share/config.site
>> 8. cd build
>> 9. run the "matlabroot" command in Matlab and copy the result in place of <MATLABROOT> in the next step
>> 10. ../configure --enable-matlab-ma57 CC=/usr/local/bin/gcc \
>> CXX=/usr/local/bin/g++ --enable-matlab-static --with-matlab-home=<MATLABROOT>
>> 11. make all -j4
>> 12. make test
>> 13. make install
>> 14. cd Ipopt/contrib/MatlabInterface/src
>> 15. make install
>>
>> You should now have a new version of ipopt.mexmaci64 that uses the serial reference BLAS instead of the optimized Apple vecLib BLAS, and can test whether that gives the same behavior.
>>
>> You may run into a couple of issues that were recently reported to the mailing list here http://list.coin-or.org/pipermail/ipopt/2014-May/003696.html and here http://list.coin-or.org/pipermail/ipopt/2014-May/003697.html - although if you're trying to use Matlab R2014a then things may not be working currently. However I have no idea what specifically might be broken as I do not have that version of Matlab installed.
>>
>>
>> -----Original Message----- From: Arnaud Barré
>> Sent: Thursday, May 29, 2014 6:05 AM
>> To: Tony Kelman
>> Cc: ipopt at list.coin-or.org
>> Subject: Re: [Ipopt] Same initialization but different solutions (notthe case with fmincon or KNitro)
>>
>> Hi Tony,
>>
>> Thanks for the new binary package. Unfortunately, the problem is still here (while it works under Windows XP 32-bit). I tried both the ma57 and mumps linear solver, but in both case I do not have the same results.
>>
>> I attached some Matlab code to reproduce my problem. Maybe it could help you to know if the problem is related to the compilation of Ipopt or if it is related to the OS/Matlab version.
>>
>> You only have to call ‘main’ in the Matlab command window. The script will solve 5 times the same problem using fmincon and Ipopt. Some results are displayed (mean and standard deviation of the solutions). If the result are the same, the standard deviation has to be 0 (or very close to).
>>
>> Arnaud
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On May 29, 2014, at 2:45 AM, Tony Kelman <kelman at berkeley.edu> wrote:
>>
>>> 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
>>>>
>>>
>>
>
>
> _______________________________________________
> Ipopt mailing list
> Ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/ipopt
More information about the Ipopt
mailing list