[Ipopt] [Coin-discuss] Trouble with C interface: glibc memory corruption error
Andreas Waechter
andreasw at watson.ibm.com
Thu May 29 13:22:00 EDT 2008
Hi John,
> Looks like my problem here was relating to a silly mistake where I had
> set the number of optimisation variables 'n' to less than the number of
> constraints 'm'. Perhaps there should be an assertion somewhere in the
> IPOPT code to prevent this (or perhaps there already is, but I didn't
> manage to turn it on :-)
It is feasible to have the number of variables n be less than the number
of constraints m. The constraints can be inequality constraints, for
example, you could have one variable, but 10 inequality constraints.
However, Ipopt will have problems if there are more equality constraints
than (free) variables. In this case it usually exits with an error
message.
Nevertheless, if you have an idea what kind of check we can add to warn
other users in case they do something like you did, let me know.
Thanks for your messages,
Andreas
>
> Thanks all for the suggestions.
>
> Cheers
> JP
>
> John Pye wrote:
>> Andreas Waechter wrote:
>>
>>> Hi John,
>>>
>>> My guess would be that there is wrong use of Ipopt's SmartPtr's.
>>> Please read the section on SmartPtr in the Ipopt documentation carefully,
>>>
>>> http://www.coin-or.org/Ipopt/documentation/node57.html
>>>
>>> The main point is that if you create any of the Ipopt objects (which
>>> inherit from ReferencedObject), you must use a SmartPtr to store the
>>> object in when you get it from "new".
>>>
>>
>> But I'm using the C interface, right, so do I still need to pass
>> SmartPtrs to CreateIpoptProblem?
>>
>> Cheers
>> JP
>>
>> _______________________________________________
>> Ipopt mailing list
>> Ipopt at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/ipopt
>>
>
>
More information about the Ipopt
mailing list