
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>

</head>

<body dir="ltr">

<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">

Dear Marc,</div>

<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">

<br>

</div>

<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">

Thanks for your help on this and the useful answers.</div>

<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">

<br>

</div>

<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">

For me at least, fixing the problem you mention is not necessary. Like you say branching on aggretated variables is not common.</div>

<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">

<br>

</div>

<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">

Best wishes,</div>

<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">

<br>

</div>

<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">

James</div>

<div class="elementToProof" id="Signature">

<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">

<br>

</div>

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">

James Cussens</div>

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">

Room MVB 3.26</div>

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">

School of Computer Science, University of Bristol</div>

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">

Phone: +44 (0)117 455 8723</div>

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">

<a href="https://jcussens.github.io/">https://jcussens.github.io/</a><br>

</div>

</div>

<div id="appendonsend"></div>

<hr style="display:inline-block;width:98%" tabindex="-1">

<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Marc Pfetsch <pfetsch@mathematik.tu-darmstadt.de><br>

<b>Sent:</b> 07 July 2025 12:44<br>

<b>To:</b> James Cussens <james.cussens@bristol.ac.uk>; scip@zib.de <scip@zib.de><br>

<b>Subject:</b> Re: [SCIP] aggregated variables</font>

<div> </div>

</div>

<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">

<div class="PlainText"><br>

<br>

Hi James,<br>

<br>

the answer to your question actually require some digging in the source <br>

code and I hope that I extracted the answers right.<br>

<br>

> 1. Let me check my understanding of the behaviour of SCIPtightenVarUb <br>

> when called on an aggregated variable (like <t_3 <- 1><br>

> In my previous email). My assumption is that will lead to the upper <br>

> bound on the variable to which it is aggregated ( t_3<-{1,5} in previous <br>

> email) being tightened.<br>

> Is that correct?<br>

<br>

In essence yes. Actually, this is implemented by returning the (possibly <br>

transformed) bounds of the aggregation variable, i.e., the one that is <br>

still active.<br>

<br>

> 2. If we have eg<br>

> [binary] <t_3 <- 1>: obj=-0, global bounds=[-0,1], local bounds=[-0,1], <br>

> aggregated: +1<t_3<-{1,5}><br>

> and (aggretated) variable t_3 <- 1 has a high branching priority does <br>

> this affect the branching priority of t_3<-{1,5}?<br>

<br>

Yes. If you change the priority of t_3 this will actually update the <br>

priority of t_3<-{1,5}. However, I noted that if you then call <br>

SCIPvarGetBranchPriority() on the aggregated variable (t_3), you will <br>

get the old value.<br>

<br>

Before I think about fixing this, I would need your impression whether <br>

this is worth it, because branching on aggregated variables is rather <br>

uncommon.<br>

<br>

The usual way to do it is to compute the active representative via <br>

SCIPvarGetProbvarSum() and then to branch on the active variable (see <br>

SCIPtreeBranchVar()).<br>

<br>

> 3. If I have a constraint on variables some of which are aggregated <br>

> variables Do the locks declared in that constraint have any effect on <br>

> the variables to which the aggregated variables are aggregated? For <br>

> example, if we have:<br>

> <br>

> [binary] <t_3 <- 1>: obj=-0, global bounds=[-0,1], local bounds=[-0,1], <br>

> aggregated: +1<t_3<-{1,5}><br>

> [binary] <t_3 <- 5>: obj=-0, global bounds=[-0,1], local bounds=[-0,1], <br>

> aggregated: +1<t_3<-{1,5}><br>

> <br>

> and the constraint adds a downlock on both of these two aggregated <br>

> variables, does t_3<-{1,5} get 2 downlocks added?<br>

<br>

Yes, SCIPvarAddLocks() replaces the aggregated variable by the <br>

corresponding active ones and changes the locks of the latter.<br>

<br>

I hope this helps.<br>

<br>

Best<br>

<br>

Marc<br>

<br>

> <br>

> Hi James!<br>

> <br>

>> [binary] <t_3 <- 1>: obj=-0, global bounds=[-0,1], local bounds=[-0,1], <br>

>> aggregated: +1<t_3<-{1,5}><br>

>> [binary] <t_3 <- 5>: obj=-0, global bounds=[-0,1], local bounds=[-0,1], <br>

>> aggregated: +1<t_3<-{1,5}><br>

>> <br>

>> First question: does SCIP branch on aggregated variables?<br>

> <br>

> Well, the default branching rule would avoid that because it only<br>

> considers fractional *active* variables.<br>

> <br>

> But, it would be possible in principle to branch on aggregated<br>

> variables. The prerequisite is that branching actually corresponds to a<br>

> bound change of an active variable, which is the case for aggregated<br>

> variables. (This is different for multi-aggregated variables, where<br>

> several changes of bounds of active variables could correspond to the<br>

> same bound change of the multi-aggregated variable.)<br>

> <br>

>> Second question: Is it correct that if, say, <t_3 <- 1> above were <br>

>> locally fixed to 0 (by some propagation) then <t_3<-{1,5}> and then<br>

>> <t_3 <- 5> would also get locally fixed to 0?<br>

> <br>

> In principle yes, if you interpret "locally fixed" in the right way. the<br>

> variable <t_3 <- 1> is not active and thus not actually present in the<br>

> problem (in particular, it does not have an LP-value). If you ask for<br>

> the local variable bounds of it, SCIP would resolve the aggregation and<br>

> return the bounds using the active variable <t_3<-{1,5}>. Similarly, for<br>

> <t_3 <- 5>.<br>

> <br>

> Best<br>

> <br>

> Marc<br>

> <br>

> P.S. I recommend to avoid characters like "<" (and ">") in variable<br>

> names, because these make it hard to correctly read the variable names<br>

> in a CIP file.<br>

> <br>

> _______________________________________________<br>

> Scip mailing list<br>

> Scip@zib.de<br>

> <a href="https://listserv.zib.de/mailman/listinfo/scip">https://listserv.zib.de/mailman/listinfo/scip</a> <<a href=""></a>https://listserv.zib.de/

<br>

> mailman/listinfo/scip><br>

<br>

</div>

</span></font></div>

</body>

</html>