Issues with variable fixing

[rrsadykov]

There are some issus with variable fixing

• First, columns should never be fixed, as we cannot impose an upper bound on a column (it is too expensive to take into account the dual value associated with the upper bound in the pricing). So the MasterColumnsRecord and unit_master_columns_record() test should be modified. For me, we should only keep the set of active columns in MasterColumnsRecord without anything else.
• Second, there is now ambiguity between fixing a variable and deactivating it. For the moment, fixing deactivates the variable, but just deactivation does not fixes the variable. When variable is deactivated but not fixed, what does this mean? For me, this means that lower and upper bound are fixed to zero. Thus may be we should set bounds to zero when we just deactivate the variable? Because of this ambiguity I think that recording and restoring StaticVarConstrUnit is not done completely correctly, we should review it.

[guimarqu]

About the second point,

For all variables, fixing => deactivation.

Deactivation means the variable is not part of the formulation anymore.
So when you deactivate, we ask the subsolvers to not consider the variable anymore.
It can mean you fix it to 0 but this is perhaps not the case everywhere. This is something to investigate.

Deactivation is mainly used to restore the state of a formulation when starting to evaluate a tree search node.
Also when cleaning up the master in column generation (currently unavailable). In the latter case, activating the master column variable when finding the same subproblem solution can be interpreted as an unfix.

[rrsadykov]

I think the main problem here is that in general it is not possible to store a partial solution just by fixing variables which participate in it. A variable (not only column) can participate in a partial solution and still be active. For example, if there is variable $x\in[0,5]$ you can first add $x=2$ to the partial solution and then add $x=1$ (so partial solution becomes $x=3$). After first fixing $x=2$, you cannot deactivate variable $x$, as you forbid to use a larger value of $x$ in the final solution.

Thus I think the current way of storing partial solutions (just by fixing and deactivating variables in the formulation) is not general enough, it should be changed. We need to define precisely how the partial solution will be stored. If you store it in the formulation, you should either add additional field to the variable (fixed value, or value in the current partial solution) or add a partial solution field in the formulation itself (the same type as a standard solution).

[guimarqu]

So for the partial solution, I suggest to keep the fixed variables field :

Coluna.jl/src/MathProg/manager.jl

Line 50 in b788c69

fixed_vars::Set{VarId}

but we indeed also need a new field to store the fixed lower bound on the variables.

We can have it in the FormulationManager, together with the set of fixed variables.
I'm open to a name better than "fixed lower bounds", or a name from the literature.
At the moment, we'll fix lower bounds only in the preprocessing.

[rrsadykov]

Ok for me. May be we call this field fixed_part or partial_value

[guimarqu]

go for partial_value

[rrsadykov]

Or we can have one field partial_solution::Dict{VarId,Float64} in FormulationManager instead of two fields partial_value and fixed_vars

[guimarqu]

I disagree because when the variable is fixed, we can deactivate it. This is not the case when it has a partial value. So I think we need to make a distinction.