Hi Mohammed,

thanks for starting the constraint handler implementation!

Over the past days I browsed through different sources (SCIP C, OrTools GScip, PySCIPOPT) and their examples on lazy constraint callbacks. I cannot directly pinpoint the issue, but it seems like most example code for constraint handlers adds a single constraint of the handlers constraint class during setup:

• Add a single constraint of the callbacks constraint class via SCIPcreateCons => is that required?
• What is the value of the ignored _nconss during callbacks? Is it always 1?

Here's some example documentation where it also mentions adding a constraint for the constraint class:

• https://www.scipopt.org/doc/html/CONS.php Last paragraph in "Interface methods"
• In GScip it looks like they also add a single constraint

Maybe I'm just misunderstanding the example code, then sorry for the confusion :)

Hi @bgraf!
Thank you for following up and the help :) I'm still fairly new to constraint handlers. There are so many things one can do with constraint handlers (about 40 callbacks 😅), but I was trying to find a first minimal set of features to enable first. There's a flag for each constraint handler that indicates whether it needs a constraint attached to it to be called. This flag I now set to false, it removes a step for the user who wants to implement some lazy constraint, and they can later add any constraint they want in the enforce callback of the Conshdlr trait. If another use case shows up in the future I will try to support it. I just pushed a new TSP example with lazy constraints maybe this helps :)

There's a flag for each constraint handler that indicates whether it needs a constraint attached to it to be called.

Alright, then I missed that, thanks for the explanation! I'll play a bit with your TSP example and compare it with another implementation.

I reworked your example for TSPLIB instance a280 here. It works as expected!

What can we do about getting variable values in the enforce callback? Should I try to add a corresponding method to Model<Solving> or would that interact badly with your overall design considerations?

I reworked your example for TSPLIB instance a280 here. It works as expected!

Very cool! It's reassuring to hear that 😄

What can we do about getting variable values in the enforce callback? Should I try to add a corresponding method to Model<Solving> or would that interact badly with your overall design considerations?

Yes, adding it to Model would be great, I'd happily accept a PR :)