[Scip] Separation in Diving Mode

[Gerald Gamrath]

Hi Jonas,

ok, that's good. We can probably provide an external method to recompute
the norm, or even do it automatically for all cuts in the sepastore when
leaving the diving mode.

What we meant is really creating a new cut. If you do that, the norms
are correctly computed when the cut is created. For example, you could
use SCIProwGetCols() and SCIProwGetVals() to get columns (and
corresponding variables, by using SCIPcolGetVar()) and coefficients in
the cut. You can store these in some arrays, throw away all cuts created
during diving and create them again after you left the diving mode. This
should work without changes in the SCIP core.

By the way: perhaps you could send me the changes you made in the SCIP
core in a private mail and we can discuss how those can be included into
the SCIP release.

Best,
Gerald

On 24.07.2013 10:35, Jonas Witt wrote:
> Hi Gerald and Michael,
>
> thanks for your help. I recompute row->objprod within 
> SCIProwGetObjParallelism() and it works.
>
> How should I create the cuts again after leaving the diving mode? 
> Storing the cuts somewhere and adding them to the separation storage 
> afterwards would lead to the same problem since the objective function 
> has changed from the diving objective to the original objective. So I 
> would have to recompute the values, too.
>
> Best regards,
> Jonas
>
>
> Am 23.07.2013 15:30, schrieb Gerald Gamrath:
>> 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
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> http://listserv.zib.de/mailman/listinfo/scip