[SCIP] FORCE BRANCHING WITH CONTINUOUS VARIABLES

[dponce at us.es]

Hi Gerald, 

thank you for your quick answer. I thought it was enough with the high
ENFOPRIORITY. Now it is working!!! 

So, I guess in my particular problem any positive values for
ENFOPRIORITY and CHECKPRIORITY should work. 

By the way, in cons_camediff of the binpacking example, is there any
reason to have high CHECKPRIORITY since the CONSCHECK is defined as
NULL? 

Best. 

Diego. 

El 10/03/2016 17:25, Gerald Gamrath escribió:

> Hi Diego,
> 
> did you implement the CONSCHECK callback of your constraint handler and does it correctly check that the summation of the variables is integral? If not, SCIP will check the root initial LP solution for feasibility and if your constraint handler does not complain, this solution will be accepted, such that the problem is already solved before branching could be invoked.
> 
> Best,
> Gerald
> 
> On 10.03.2016 11:28, dponce at us.es wrote: 
> 
> Hello Gerald, 
> 
> thank you for your answer. After some work I have more questions. 
> 
> I have removed the branching rule pluging and now it is substitued by the enfolp callback within the contraint handler pluging. However, THE ENFOLP IS NEVER INVOQUED. 
> 
> I would like to remark that in my problem I have defined ALL THE VARIABLES AS CONTINUOUS (there is no binary nor integer variable) since the only discrete entity that we have are that the sumation of some of these variables are 0-1. Neverthelees I do not want to define artificial variables as the sum of pairs. 
> 
> I've read next thread of questions and asnwers about some similar situation (enfolp seemed to be not invoqued) but it is not clear how her problem was solved. 
> 
> http://listserv.zib.de/pipermail/scip/2013-April/001433.html 
> 
> 1. Having the problem as a pure LP (with all continuous variables), will the constraint handler be invoqued? 
> 
> 2. I have thought that I could add some dummy binary variables independent from the problem that will be forzed to branch only at the end (by means of the appropriate priority of my constraint handler) at the very end of each branching of the tree, but it seems too ARTIFICIAL. Can the branching be done in a neater way? 
> 
> 3. Am I missing something? 
> 
> To put the right information, the properties of the constraint handler in my implementation are set to:
> 
> #define CONSHDLR_ENFOPRIORITY 99999 
> #define CONSHDLR_CHECKPRIORITY -1 
> #define CONSHDLR_EAGERFREQ 1 
> #define CONSHDLR_NEEDSCONS FALSE 
> 
> Best. 
> 
> Diego. 
> 
> El 07/03/2016 11:26, Gerald Gamrath escribió: 
> Hi Diego,
> 
> branching is done as part of the enforcement of LP (or pseudo) solutions. The enforcement callback of the integrality constraint handler calls the branching rules by decreasing priority. But any other constraint handler with active constraints can also do branching.
> 
> Thus, you can implement your own constraint handler which checks whether you need to do branching in the CONSENFOLP callback. You should add one constraint of this handler which stores the data needed to check feasibility.
> 
> Note that the enforcement callbacks of constraint handler are called in decreasing priority until one did perform a branching. So you could even mix branching on integer variables with other branching by your own constraint handler. If your constraint handler has a positive priority, it will always be called before the integer variable branching, otherwise afterwards. In your case, however, I would recommend to just define your variables as continuous.
> 
> Best,
> Gerald
> 
> On 04.03.2016 17:23, dponce at us.es wrote: 
> 
> Hello list, 
> 
> I have to develope a Ryan and Foster Branching similar to the binpacking one. The difference is that when I finish my branching I cannot assure integrality on the variables. But I don't have to, since I'm able to build a solution for my problem easily. 
> 
> It is possible to force the problem to go to the branching when I define my variables as continuous? If not, is there a way to just use my branching and no the default branching? 
> 
> Best. 
> 
> Diego.
> 
> _______________________________________________
> 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/pipermail/scip/attachments/20160310/9fa5a8e4/attachment.html>