[Ipopt] asymmetric Hessian matrix

[Stefan Vigerske]

Hi,

can you try with Ipopt/stable/3.10 instead of what you are currently 
using? It has some fixes for the blas interface.

svn co https://projects.coin-or.org/svn/Ipopt/stable/3.10 Ipopt-3.10

Stefan

> I am running on Linux Centos. With that config argument, I still have the
> same problem.
>
> if I replace
>
> IpBlasDcopy(nx,&zero, 0, gradref, 1);
> IpBlasDcopy(nx,&zero, 0, gradpert, 1)
>
> with
>
> std::fill(gradref, gradref + nx, 0.0)
> std::fill(gradpert, gradpert + nx, 0.0)
>
> ,in the check derivative function.
>
> It works. However, I am running into the same problem somewhere else.
>
>
> On Wed, May 16, 2012 at 11:13 AM, Stefan Vigerske
> <stefan at math.hu-berlin.de>wrote:
>
>> Hi,
>>
>> the only thing that comes into my mind is that if you use Mac OS X Lion,
>> then there is a problem when using the optimized blas routines that come
>> with the system, for details see
>>   https://projects.coin-or.org/**Ipopt/ticket/181<https://projects.coin-or.org/Ipopt/ticket/181>
>>
>> This issue has not been fixed in an Ipopt release yet (only in trunk and
>> latest stable branch).
>> One workaround is to use netlib's blas/lapack implementation (do get.Blas
>> and get.Lapack in ThirdParty/Blas and ThirdParty/Lapack, resp.) and
>> building Ipopt with the configure options --with-blas=BUILD
>> --with-lapack=BUILD .
>>
>> Stefan
>>
>>   Hi,
>>>
>>> First when I use IPOPT for my problem, I see the bound constraints for
>>> parameters are violated. The library throws an exception, and the program
>>> terminated. To be specific the contraint on that parameter is [0.005,
>>> 0.006], however I see the library is trying to use 0 for that parameter.
>>>
>>> Later, I enabled second order deriviative check, however the numerical
>>> calculation gives asymmetric Hessian matrix for contraints. The values are
>>> very different one is about 3000, the other is about 3.0e13. I spend some
>>> time on the library source code. I found the following line changes the
>>> parameter magically:
>>>
>>>   for (Index i = 0; i<   nx; ++i) {
>>> std::cout<<   ivar<<   "  2.3"<<   xref[i]<<   ""<<   xpert[i]<<
>>> std::endl;
>>> }
>>>
>>> IpBlasDcopy(nx,&zero, 0, gradref, 1);
>>>
>>>
>>> for (Index i = 0; i<   nx; ++i) {
>>> std::cout<<   ivar<<   "  2.5"<<   xref[i]<<   ""<<   xpert[i]<<
>>> std::endl;
>>> }
>>>
>>> The output is:
>>> 1  2.3     0.0481804  0.0481804
>>> 1  2.3     700.976  700.976
>>> 1  2.3     0.0165778  0.0165778
>>> 1  2.3     2.54335  2.54335
>>> 1  2.3     0.27909  0.27909
>>>
>>> 1  2.5     0.0481804  0
>>> 1  2.5     700.976  700.976
>>> 1  2.5     0.0165778  0.0165778
>>> 1  2.5     2.54335  2.54335
>>> 1  2.5     0.27909  0.27909
>>>
>>> IpBlasDcopy is a Fortran function, is that the problem?
>>>
>>>
>>>
>>>
>>> ______________________________**_________________
>>> Ipopt mailing list
>>> Ipopt at list.coin-or.org
>>> http://list.coin-or.org/**mailman/listinfo/ipopt<http://list.coin-or.org/mailman/listinfo/ipopt>
>>>
>>
>>
>> --
>> Stefan Vigerske
>> Humboldt University Berlin, Numerical Mathematics
>> http://www.math.hu-berlin.de/~**stefan<http://www.math.hu-berlin.de/~stefan>
>>
>


-- 
Stefan Vigerske
Humboldt University Berlin, Numerical Mathematics
http://www.math.hu-berlin.de/~stefan