[Scip] Memory management (in a column generation method)

[Luigi Malagò]

hi,
thanks, now it is clear. basically i've moved from arrays to vectors, and
i'm copying pointers without using SCUPduplicateMemory functions. it seems
fine so far, as long as all pointers are handled (i.e., memory deallocated)
in the correct way.

some comments:

>>Besides, it does not copy them from the master problem to the pricing
>>problems, but just stores them within the pricer data for later use.

yes of course.

>>So this is the place where you should add new variables and also
>>the new constraints that come along with the new variables.

this is exacly what i meant, even if i was not clear in what i wrote.

>>However, these constraints will not enter the LP directly, but will be
separated
>>into the LP when they are violated. We changed this behavior to allow
>>forcing a constraint to enter the LP even when it is not violated, this
>>will be included in the next release. Please tell us if you have any
>>problems with the current behavior.

so far so good with this, i will let you know in case of problems or
unexpected behavior..

thanks, you are really helping me.
even if the SCIP documentation is complete, sometimes
it's hard to get the big picture of callback and work flow for column
generation
+ branching... (first time i work with this)


best regards
luigi


On Fri, Aug 19, 2011 at 7:24 PM, Gerald Gamrath <gamrath at zib.de> wrote:

> Hi Luigi,
>
> Am 19.08.2011 15:45, schrieb Luigi Malagò:
> > Hi list (again),
> > i have a question about how to correctly handle memory allocation in
> SCIP.
> >
> > in the binpacking example, i found this code,
> >
> > SCIP_CALL( SCIPduplicateMemoryArray(scip, &pricerdata->conss, conss,
> > nitems) );
> >
> > to duplicate data structure from master problem to the pricing problem.
> Actually, this does not duplicate the data structure, but just copies an
> array, in this case an array of pointers to constraints. It does
> essentially the same as allocating an array of the right size and
> copying the entries one by one, but is more comfortable and efficient.
> Besides, it does not copy them from the master problem to the pricing
> problems, but just stores them within the pricer data for later use.
> > in my code i have to copy just a single conss, not an array.
> >
> > i tryed something like
> >
> > SCIP_CALL( SCIPduplicateMemoryscip, &pricerdata->myConss, myConss) );
> >
> > but i didnt work, i debugged the code and some pointers screwed up.
> > so i think i solved with just ana assignment
> >
> > pricerdata->myConss = myConss;
> >
> > what is wrong with this? it is safe?
> That is exactly what you should do.
> > same problem when i moved the datastructures from array and matrix of
> > pointers
> > to vectors of pointers and vectors of vectors of pointers.
> > is it safe to just copy pointers with an assignment as above?
> Yes, you can do that.
>
> > as to good working practice:
> > in my pricing datastructure, i have pointers to all variables and
> > constraints of the pricer and also of the master,
> > since i need these to create new constraints when the variable is
> > added to the master.
> > i suppose this is the correct way and place to modify the master
> > problem in
> > SCIP_DECL_PRICERREDCOST(pricerRedcostBinpacking)
> > when i new column is added. can somebody confirm this, please?
> I do not really get your question. But the redcost callback is (besides
> the farkas callback that is called when the restricted LP is infeasible)
> the only method of the pricer that is called at each node for solving
> the LP. So this is the place where you should add new variables and also
> the new constraints that come along with the new variables. However,
> these constraints will not enter the LP directly, but will be separated
> into the LP when they are violated. We changed this behavior to allow
> forcing a constraint to enter the LP even when it is not violated, this
> will be included in the next release. Please tell us if you have any
> problems with the current behavior.
>
> Best, Gerald
> _______________________________________________
> 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/20110822/b73d22d2/attachment.html