[Scip] Primal solution is not accepted because of fixings during presolving.

[Gerald Gamrath]

Hi Daniel,

the dual fixing presolver fixes variables based on the variable locks. A
down (up) lock means that the constraint adding that lock can become
infeasible when the value of the variable is decreased (increased).
For example, variables with a positive coefficient in a linear
constraint will get a down lock, if it is a ">=" constraint, an uplock
if it is an "<=" inequality and both up and down lock if it is an equation.

Based on this information and the objective coefficient, the dualfixing
presolver will fix variables to their lower bound if they have a
positive objective coefficient (in minimization) and no down locks.
If you want to keep it from doing this, your constraint handler should
add a down lock to the variable via SCIPaddVarLocks(), providing a value
of 1 or larger as nlocksdown (this is just the number of locks you want
to add with the call).

If the solution which you create is infeasible in case you set all fixed
variables the the fixed value, the reasoning of the dualfixing presolver
is probably wrong because your constraints don't set the locks
correctly. This is the reason why the CONSLOCK-callback, which seems
unimportant at first glance, is a fundamental callback. On the other
hand, you can of course add locks even if they are not implied by the
constraint as a "trick" to prevent dual presolving on a variable.

Best,
Gerald

On 18.02.2013 13:09, Daniel Karch wrote:
> Hi,
>
> I have written a branching rule that is sometimes able to construct a
> primal solution to
> my problem, and I want to add that solution via SCIPaddSol. However,
> for some variables 
> SCIPsetSolVar fails with something like
>
> ERROR: cannot set solution value for variable <t_psi_e_9_0> fixed to
> -0 to different value 1
>
> I have found out that the variable is fixed to zero during presolving
> by presol_dualfix. How can I
> prevent this from happening? I use SCIPaddVarLocks in my constraint
> handlers to keep variables
> from being rounded down, but there I have to provide the parameters
> nlocksdown and nlocksup, 
> that I don't have available now. I don't really know on what grounds
> SCIP decides which variables
> it can fix, and it may be that fixing that variable does not exclude
> all optimal solutions, but in my
> situation it is inconvenient that it excludes feasible solutions that
> I want to add.
>
> Best regards,
>
>   Daniel
>
>
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> http://listserv.zib.de/mailman/listinfo/scip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserv.zib.de/mailman/private/scip/attachments/20130218/89c5dbbd/attachment.html