Feature request: Hard constraints for IIS extraction

[OrestisLomis]

Currently when computing an IIS all constraints are considered 'soft' constraints, i.e. all of them may be removed to construct an IIS. However it would be interesting if we could actually indicate certain constraints as 'hard' constraints. A hard constraint in the context of IIS, would be a constraint that is always considered part of the IIS. I'm using the python API for SCIP, so apologies if this is not the right place to post this.

[DominikKamp]

If a constraint is captured in the IIS subscip before running the finder, it will not be removed, but I am not sure whether this can be achieved through the API yet.

@Joao-Dionisio How can constraints be captured through the Python API?

@pmeinhold Can the IIS subscip be accessed before running an IIS finder in the C API?

[Joao-Dionisio]

PySCIPOpt#1221 wraps SCIPcaptureCons() and SCIPreleaseCons().

[DominikKamp]

Good, so the remaining task is to provide access to the IIS subscip before generation, unless the original captures are shipped to the subscip automatically, which can be unexpected.

[OrestisLomis]

Hi thanks for the quick help! I just checked out the branch which exposes SCIPcaptureCons() (and SCIPreleaseCons()) and it already seems to work as I would expect it to. Not sure what would still be missing.

[DominikKamp]

Okay, then the captures are probably already copied and scipopt/PySCIPOpt#1221 would be enough.

@pmeinhold When you find the time, could you ensure that this feature is sufficiently covered in the IIS documentation?

[pmeinhold]

Looking a little bit into this, I'm really not sure how the captures are copied.
SCIPcopyOrig(set->scip, iis->subscip, ...) is used, which, according to documentation, does not capture the variables.

Also, the subscip is currently not accessible before running IIS finders, since it is created just before running these. @DominikKamp

I'm puzzled, how capturing constraints in the original problem apparently "saves" them from deletion during IIS finding. And new features (like component detection) are not built to respect an increased usage counter anyways.

Unless I missed something big here, it needs more work to implement the requested feature correctly.

[DominikKamp]

Yes, indeed the captures are ignored by the component extension, though it should be possible to respect them.