[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