[Scip] Fwd: getting column coefficients and realloc error

Mon May 17 15:44:12 MEST 2010

Hi! Thanks for the quick response, now I solved the problem posted
previously.

Hi Mattia,
>
>
> > Hi all,
> >   I am developing a Branch&Price application in SCIP (1.2.0, linked with
> > Soplex 1.4.2b , gcc version 4.3.3 on Ubuntu SMP x86_64), with a column
> > generation approach. Simply I defined plugin Pricer that is a shortest
> path
> > problem (in accord to my model decomposition), and a new constraint
> handler
> > to store branching decision (like explained in SCIP: FAQ). A variable in
> my
> > model represent a path of a given commodity from a source to a
> destination.
> > What I want to do is to obtain the column coefficient of a given
> variable,
> > without storing this information in SCIP_VARDATA, too expensive for my
> > purpose (path o f hundred nodes for over 10e6 variables). I try this
> > procedure:
> >   SCIP_VAR** vars = SCIPgetVars(scip);
> >   SCIP_COL* col = SCIPvarGetCol(vars[0]);
> >   SCIP_Real* vals = SCIPcolGetVals(col);
> > But what I get is a set of 1's and 0's in positions that do not match
> > generated path (clearly, when new priced var is found, it is added to the
> > problem, and coefficients of the constraints involved are updated in
> >  order). May be because I relate whit transformed variable and not whit
> >  original variable? But I read that priced var don't have an original
> >  counterpart. So how can I solve this problem?
> Well it is not possible to construct the information you need out of a
> SCIP_COL. The reason is that a column in SCIP knows the rows which have
> nonzero entries. The row, however, does not know the constraint which
> created
> that row. If you think that it is not possible to store the necessary
> information in SCIP_VARDATA you can construct the information in the
> following
> way.
> You loop  over you (linear) constraints and ask each constraint for its
> variables (SCIPgetVarsLinear(), SCIPgetNVarsLinear()) and check if the
> variable you currently have in your hand is part of that linear constraint.
> So
> this means your idea should work if you use the (linear) constraints
> instead
> of the SCIP_COL. I hope that helps.
>

I stored my paths in a one dimensional wide enough array. In this way I do
not charge the SCIP_VAR whit these information.

>
> > I have a second problem. when creating a new constraint handler (as
> > mentioned before), I get sometimes a segmentation fault error when I put
> a
> > new constraint on the stack (more precisely when the program try to
> > Reallocate memory for new constraint). The code used is the same as in
> the
> > Coloring example provided with the default SCIP installation.
> >
> > /* put constraint on the stack */
> >    if ( conshdlrData->nstack >= conshdlrData->maxstacksize )
> >    {
> >       SCIPreallocMemoryArray(scip, &(conshdlrData->stack),
> > 2*(conshdlrData->maxstacksize));
> >       conshdlrData->maxstacksize = 2*(conshdlrData->maxstacksize);
> >       SCIPdebugMessage("reallocating Memory for stack! %d --> %d\n",
> > conshdlrData->maxstacksize/2, conshdlrData->maxstacksize);
> >    }
> >    conshdlrData->stack[conshdlrData->nstack] = cons;
> >    ++(conshdlrData->nstack);
> >
> > May be the problem is elsewhere, but the backtrace I obtain is as follow:
> Could you check the values for conshdlrData->maxstacksize? Did you run SCIP
> and your program in debug mode? If not recompile SCIP and your program
> using
> the command "make OPT=dbg" and rerun your program and check if an assert()
> comes up.
>

This was a programming error in my code, now it is solved.

>
> Best Stefan
>
> >
> > *** glibc detected *** ./gse1/bin/gse: realloc(): invalid next size:
> > 0x000000000243bfb0 ***
> > ======= Backtrace: =========
> > /lib/libc.so.6[0x7f22d49b0a58]
> > /lib/libc.so.6[0x7f22d49b4d51]
> > /lib/libc.so.6(realloc+0x12e)[0x7f22d49b5bde]
> > ./gse1/bin/gse[0x6034e9]
> > ./gse1/bin/gse[0x5f1445]
> > ./gse1/bin/gse[0x5f12a8]
> > ./gse1/bin/gse[0x5f918b]
> > ./gse1/bin/gse[0x5b48ae]
> > ./gse1/bin/gse[0x5af200]
> > ./gse1/bin/gse[0x596a41]
> > ./gse1/bin/gse[0x5a1f8d]
> > ./gse1/bin/gse[0x5a25dc]
> > ./gse1/bin/gse[0x45df04]
> > ./gse1/bin/gse[0x45f456]
> > ./gse1/bin/gse[0x4627d9]
> > ./gse1/bin/gse[0x464256]
> > ./gse1/bin/gse[0x44bf5c]
> > ./gse1/bin/gse[0x4046d6]
> > /lib/libc.so.6(__libc_start_main+0xe6)[0x7f22d4955466]
> > ./gse1/bin/gse[0x404479]
> > ======= Memory map: ========
> > [...]
> > [...]
> >
> >
> > How can I solve this problem?
> >
> > Thank you for the time you will spend to read and answer my questions.
> >
>

My questions now are the following.

 - 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?
-  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). Thousands of columns are anyway too much, because
the LP solving process is very slow. Is there anyway to better manage this
problem?
- 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. 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

:~/scip-1.2.0$ make LPS=cpx ZIMPL=false READLINE=false ARCH=x86
-> generating library lib/libscip-1.2.0.linux.x86.gnu.opt.a
-> generating library lib/libobjscip-1.2.0.linux.x86.gnu.opt.a
-> generating library lib/liblpicpx-1.2.0.linux.x86.gnu.opt.a
-> linking bin/scip-1.2.0.linux.x86.gnu.opt.cpx
/usr/bin/ld: skipping incompatible lib/libscip-1.2.0.linux.x86.gnu.opt.a
when searching for -lscip-1.2.0.linux.x86.gnu.opt
/usr/bin/ld: cannot find -lscip-1.2.0.linux.x86.gnu.opt
collect2: ld returned 1 exit status
make: *** [bin/scip-1.2.0.linux.x86.gnu.opt.cpx] Error 1

Thanks in advance for your help. Best regards.

-- 
Mattia Barbieri
barbieri.mattia at gmail.com

-- 
Mattia Barbieri
barbieri.mattia at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserv.zib.de/mailman/private/scip/attachments/20100517/30d35999/attachment.html