[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