[SCIP] aggregated variables

[James Cussens]

Dear Marc,

Thanks for your help on this and the useful answers.

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

Best wishes,

James

James Cussens
Room MVB 3.26
School of Computer Science, University of Bristol
Phone: +44 (0)117 455 8723
https://jcussens.github.io/
________________________________
From: Marc Pfetsch <pfetsch at mathematik.tu-darmstadt.de>
Sent: 07 July 2025 12:44
To: James Cussens <james.cussens at bristol.ac.uk>; scip at zib.de <scip at zib.de>
Subject: Re: [SCIP] aggregated variables



Hi James,

the answer to your question actually require some digging in the source
code and I hope that I extracted the answers right.

> 1. Let me check my understanding of the behaviour of SCIPtightenVarUb
> when called on an aggregated variable (like <t_3 <- 1>
> In my previous email). My assumption is that will lead to the upper
> bound on the variable to which it is aggregated ( t_3<-{1,5} in previous
> email) being tightened.
> Is that correct?

In essence yes. Actually, this is implemented by returning the (possibly
transformed) bounds of the aggregation variable, i.e., the one that is
still active.

> 2. If we have eg
> [binary] <t_3 <- 1>: obj=-0, global bounds=[-0,1], local bounds=[-0,1],
> aggregated: +1<t_3<-{1,5}>
> and (aggretated) variable t_3 <- 1 has a high branching priority does
> this affect the branching priority of t_3<-{1,5}?

Yes. If you change the priority of t_3 this will actually update the
priority of t_3<-{1,5}. However, I noted that if you then call
SCIPvarGetBranchPriority() on the aggregated variable (t_3), you will
get the old value.

Before I think about fixing this, I would need your impression whether
this is worth it, because branching on aggregated variables is rather
uncommon.

The usual way to do it is to compute the active representative via
SCIPvarGetProbvarSum() and then to branch on the active variable (see
SCIPtreeBranchVar()).

> 3. If I have a constraint on variables some of which are aggregated
> variables Do the locks declared in that constraint have any effect on
> the variables to which the aggregated variables are aggregated? For
> example, if we have:
>
> [binary] <t_3 <- 1>: obj=-0, global bounds=[-0,1], local bounds=[-0,1],
> aggregated: +1<t_3<-{1,5}>
> [binary] <t_3 <- 5>: obj=-0, global bounds=[-0,1], local bounds=[-0,1],
> aggregated: +1<t_3<-{1,5}>
>
> and the constraint adds a downlock on both of these two aggregated
> variables, does t_3<-{1,5} get 2 downlocks added?

Yes, SCIPvarAddLocks() replaces the aggregated variable by the
corresponding active ones and changes the locks of the latter.

I hope this helps.

Best

Marc

>
> Hi James!
>
>> [binary] <t_3 <- 1>: obj=-0, global bounds=[-0,1], local bounds=[-0,1],
>> aggregated: +1<t_3<-{1,5}>
>> [binary] <t_3 <- 5>: obj=-0, global bounds=[-0,1], local bounds=[-0,1],
>> aggregated: +1<t_3<-{1,5}>
>>
>> First question: does SCIP branch on aggregated variables?
>
> Well, the default branching rule would avoid that because it only
> considers fractional *active* variables.
>
> But, it would be possible in principle to branch on aggregated
> variables. The prerequisite is that branching actually corresponds to a
> bound change of an active variable, which is the case for aggregated
> variables. (This is different for multi-aggregated variables, where
> several changes of bounds of active variables could correspond to the
> same bound change of the multi-aggregated variable.)
>
>> Second question: Is it correct that if, say, <t_3 <- 1> above were
>> locally fixed to 0 (by some propagation) then <t_3<-{1,5}> and then
>> <t_3 <- 5> would also get locally fixed to 0?
>
> In principle yes, if you interpret "locally fixed" in the right way. the
> variable <t_3 <- 1> is not active and thus not actually present in the
> problem (in particular, it does not have an LP-value). If you ask for
> the local variable bounds of it, SCIP would resolve the aggregation and
> return the bounds using the active variable <t_3<-{1,5}>. Similarly, for
> <t_3 <- 5>.
>
> Best
>
> Marc
>
> P.S. I recommend to avoid characters like "<" (and ">") in variable
> names, because these make it hard to correctly read the variable names
> in a CIP file.
>
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> https://listserv.zib.de/mailman/listinfo/scip <https://listserv.zib.de/
> mailman/listinfo/scip>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.zib.de/pipermail/scip/attachments/20250709/53a3de39/attachment.html>