[Scip] Separation in Diving Mode

Gerald Gamrath gamrath at zib.de
Tue Jul 23 15:30:58 MEST 2013


Hi Jonas,

SCIPseparateSol() was not designed to be called during diving, since a
changed diving objective function is not handled. However, it seems to
be fixable.

In your case, the assertion comes up, because the row->objprod is
computed when the row is created, so w.r.t. the diving objective. At
that point, also lp->objsqrnorm is computed w.r.t. the diving objective,
and computing the objective parallelism at that point should work.
However, those values are not updated when you leave the diving mode, by
setting lp->objsquarenormunreliable to TRUE, you forced SCIP to
recompute the latter one. The product between row and objective,
however, was not recomputed, and thus, the parallelism was computed
incorrectly.

As a test for you, you could try to recompute row->objprod within
SCIProwGetObjParallelism() as well by calling rowCalcNorms(row, set).
Please let us know if this works.

The more correct way would be to create the cuts again after leaving the
diving mode and remove the "old" diving cuts from the separation storage.

Best,
Gerald and Michael

On 18.07.2013 11:56, Jonas Witt wrote:
> Hi all,
>
> I have written a separator (in GCG but I have a SCIP problem) which 
> holds a non-basic feasible solution x and tries to separate this 
> solution by applying the follwing strategy:
> It calculates a basic feasible solution x* , generates cutting planes 
> which cut off x* and adds all generated cutting planes which also cut 
> off x to the separation storage. I call SCIPstartDive(), change the dive 
> objective by SCIPchgVarObjDive() and obtain x* by solving the dive LP 
> (SCIPsolveDiveLP()). Then I call SCIPseparateSol() with solution NULL 
> and store the cuts which cut off x.
>
> This works fine, but sometimes there are some problems with the function 
> SCIProwGetObjParallelism() which is called when adding a cut to the 
> separation storage. It calculates the scalar of 
> row*lpobj/||row||*||lpobj|| where || || is the square norm. Since it 
> uses the current LP's objective function (which has changed due to 
> SCIPchgVarObjDive()), some of the values stored in the row or the 
> current LP are wrong. This leads to a wrong calculation and for example 
> to the following error:
> src/scip/lp.c:6731: SCIProwGetObjParallelism: Assertion 
> `SCIPsetIsSumLE(set, parallelism, 1.0)' failed.
>
> I tried to set lp->objsquarenormunreliable = TRUE in 
> SCIPlpMarkDivingObjChanged() and in SCIPendDive(). First, this worked 
> for me. But now the problem occurred again. Should I recalculate the 
> norms which are stored in the row everytime I call 
> SCIProwGetObjParallelism() or is there an easier way to avoid errors 
> like that?
>
> Best regards,
> Jonas
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> http://listserv.zib.de/mailman/listinfo/scip



More information about the Scip mailing list