[Scip] Fwd: getting column coefficients and realloc error
Stefan Heinz
heinz at zib.de
Mon May 17 22:31:42 MEST 2010
Hi Mattia,
> - In my problem, I am doing branch on arcs. I edited the branch plugin
> (like explained in documentation), and now I select the "longest" arc of
> the most fractional variable (a path). The best way to lead with my
> problem would be to select an arc providing the best lowerbound. To doing
> so, I need to loop over all arcs of current fractional variables, and try
> to solve the LP problem with each of these arcs. I think this is a sort of
> DIVING approach. But how can I do this in practice? Should I create a new
> Primal Heuristic plugin that explore one level of the subtrees associated
> whit current active (leaf) nodes?
You can use the diving mode in SCIP. With the method SCIPstartDive() SCIP
changes it stage into diving. With the methods
- SCIPchgVarObjDive()
- SCIPchgVarLbDive()
- SCIPchgVarUbDive()
- SCIPgetVarObjDive()
- SCIPgetVarLbDive()
- SCIPgetVarUbDive()
- SCIPsolveDiveLP()
- SCIPgetLastDivenode()
you can control the dive (see scip.c) and with SCIPendDive() you reset SCIP
into normal mode. An example for such a diving can be found in one of the
diving heuristics such as "heur_coefdiving.c". The diving within SCIP is not
restricted to heuristics it can also be performed in your brachching Plugins.
> - After few nodes the actives variables are a lot (1000 to 20k variables,
> considering 70-nodes problems). These are all the variables that my pricer
> plugin find, but in practice only a half (or less) are active columns of
> the current LP at one node (I suppose that SCIP has a own mechanism to
> define a pool of active columns).
Yes that is the case.
> Thousands of columns are anyway too
> much, because the LP solving process is very slow. Is there anyway to
> better manage this problem?
I am not sure if I got your question right. I try to answer it in the follwing
way:
There is one problem in the current version of SCIP. It is not possible to
remove variables from the problem. In your case I would suggest to select only
a certain number of the variables your pricer creates for adding to your
problem in each round. That might help to reduce the amount of useless
variables in the end.
> - A more tecnhical question. In relation whit the previous question, I
> think in my problem would help a faster LP solver, like Gurobi. I try to
> link it whit SCIP, but I get a lot of error in compilation such undefined
> funcionts (I read in some questions of other users that Gurobi is not
> fully supported at the moment). I installed the version 3.00 of Gurobi.
In case of Gurobi the problem comes from the fact that Gurobi does not support
all callback methods which are needed be integrated into a MIP solver like
SCIP. This will probably change over the next versions of Gurobi and we will
update the SCIP Gurobi interface accordingly.
> I try also to link SCIP whit CPLEX 11.1: the license is for the x86 version,
> but I have to compile SCIP in x86_64 mode because the underlying have an
> X86_64 operating system. If I try to force the installation of SCIP whit
> parameter ARCH=x86 I get this error
Since CPLEX is now free for academic people you could get a CPLEX x86_64
license. Otherwise try the command suggested by Stefan V.
-- Stefan
More information about the Scip
mailing list