[SCIP] how to augment the lower bound
Tobias Achterberg
achterberg at zib.de
Thu Oct 19 18:27:14 CEST 2023
Hi Brannon,
in my experience, increasing just the dual bound at the node (without moving the LP
solution vector accordingly) is not terribly useful for improving performance. Basically,
the only thing that matters w.r.t. bound value is whether you can cut off a node or not.
So, if you can use your problem knowledge to prove that a certain node cannot improve the
incumbent solution, then this will be strong. If you can only say that the bound is a bit
better than what the LP says, then my guess is that this won't help too much, except if
you then later find an incumbent that allows to cut off this node.
The only places where the dual bound plays a role other than pruning nodes are
1. in the updates of the pseudo costs, and
2. in the node selection.
For 1., the effect can be pretty significant. But a change that you are considering could
actually be detrimental for the pseudo cost updates, in particular when your dual bound
improvement leads often to the same values (e.g., because you can tighten the makespan
always in discrete steps). This could lead to a situation in which the branching scores of
all variables are identical or very similar and thus confuse the branching more than it helps.
For 2., the node selection is mostly concerned with finding good feasible solutions
earlier during the search. It is not that important for reducing the time to prove
optimality (i.e., increase the dual bound). Thus, if you have good heuristics to produce
good solutions quickly, or if SCIP finds good solutions anyway in the beginning of the
search, then trying to improve the node selection is usually not too beneficial.
So, I would suggest that in a first step you only implement a cut separator that prunes a
node if you can show that the node cannot improve the incumbent. This could be helpful.
And then, you could try more, but my guess is that this will be much harder to achieve.
Regards,
Tobias
Am 2023-10-16 um 19:17 schrieb Gerald Gamrath:
> Hi Brannon,
>
> your idea to extend the LP relaxator was going in the right direction. It sounds like what
> you would like to do is write a custom relaxator plugin in SCIP. If you give it a negative
> priority, it will be called after the LP has been solved. See
> https://www.scipopt.org/doc-8.0.3/html/RELAX.php for more details and perhaps also check
> out the relaxator example.
>
> Best,
>
> Gerald
>
> On 16.10.23 18:39, Brannon King wrote:
>> I have a scheduling problem with a poor LP relaxation. However, given
>> a relaxed solution, I can augment that using some additional problem
>> knowledge. In other words, I want the ability to manually increase
>> every node's lower bound.
>>
>> When I attempt to do this via cuts, either up front or lazily, my
>> problem takes longer to solve. This is a common problem in scheduling
>> problems; cuts that try to prop up the makespan destroy the search
>> direction. How can I use my augmented relaxation without destroying
>> the search direction? I picture that my improved lower bound would
>> eliminate poor subtrees sooner, but it would not change the overall
>> branching strategy.
>>
>> I originally pictured that I would take the LP relaxator, inherit from
>> it, and make a minor modification to where it sets the lower bound. In
>> looking around, though, it seems that the LP relaxation is not in a
>> plugin. Where is it done presently? Where would I intercept this?
>>
>> Maybe I should use a node selector plugin? This seems different than
>> overriding the lower bound, though. I don't understand how the node
>> priority is set already. Does it come from the lower bound? Or is it
>> based on properties of the variables, which one looks like it needs to
>> branch, etc?
>>
>> Thanks for your time,
>> Brannon
>> _______________________________________________
>> Scip mailing list
>> Scip at zib.de
>> https://listserv.zib.de/mailman/listinfo/scip
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> https://listserv.zib.de/mailman/listinfo/scip
More information about the Scip
mailing list