The parameters in "for" and "sum" statements in solving similar problems

[Michael Christon]

Hi Dear professor Lofberg:

I recently used the yalmip toolbox in MATLAB to call CPLEX to optimize a unit commitment problem,

The operation cycle of my program is one week. I want to solve the unit commitment results of several weeks.

So I used the optimizer. By setting the Parameters and WantedVariables of the optimizer to change the parameters, I could schedule the solution circularly and save the time of yalmip analysis and modeling.

However, at this time, I encountered a problem that some of the parameters I designed for each cycle change were in the "for " and "sum" statement, which resulted in a running error.

program like this:

for j = 1:size(CN_Nb,1)

    st = [st, sum(1 - v(j,2:(G(j)+1))) == 0];

end

for j = 1:size(CN_Nb,1)

    for k = (1+G(j)):(NbTime-cn.UT(j)+1)

        t = k+1;

        st = [st, sum(v(j,t:t+cn.UT(j)-1)) >= cn.UT(j) * (v(j,t) - v(j,t-1))];

    end

end

In this formula, G (j) is the parameter to be changed in each cycle, not the variable,But the optimizer will think it's a variable and can't recognize it.

error like this:

Undefined operator ':' for input arguments of type 'sdpvar'.

Error in year_optimazer (line 313)

    st = [st, sum(1 - v(j,2:(G(j)+1))) == 0];

Do you have any way to solve this problem?

[Johan Löfberg]

You will have to model it in some completely different way

One way is to sum(1 - cj'*v(j,:)) and then have the vector cj be a new parameter which takes 0/1 values depending on your G parameter

[Michael Christon]

You're right, the "sum" statement can do this, 

but how should G (j) in the "for" statement change its form? I don't have a good solution.

Look at G(j) in my second line.

[Johan Löfberg]

You're simply going to have to use a similiar strategy.

for i = k:n

 Model = [Model, x(i) >= 1]

end

for parameter k, would be parameter.*(x-1) >= 0, and then parameter would take 0/1 values

[Michael Christon]

"for parameter k, would be parameter.*(x-1) >= 0, and then parameter would take 0/1 values"

I can't understand this sentence. Can you explain it in more detail?

[Johan Löfberg]

instead of

sdpvar k
x = sdpvar(n,1);
Model = x(k:n)>= 1
P= optimizer(Model,[],[],k,x)
P(3)

you do

sdpvar k
x = sdpvar(n,1);
g = sdpvar(n,1);
Model = g.*(x - 1) >= 0
P= optimizer(Model,[],[],g,x)
gg = zeros(n,1);gg(3:end)=1;
P(gg)

[Michael Christon]

Hi Dear professor Lofberg:

According to the method you gave, I wrote the following statement:

v     = binvar(2,169,'full');
vG  = binvar(2,169,'full');

for j = 1:size(2,1)

    st = [st, vG(j,:) .* (v(j,:) - 1) == 0];

end

Where "VG" is the parameter and "V" is the variable. However, every time I run MATLAB, it always shows "busy".

Through debugging, I find that every time I add the above constraint, there will be a statement that stops at the bottom all the time. 

controller = optimizer(st,z,ops,parameters_in,solutions_out);

What do you think is the problem?

Is it relevant for me to use the CPLEX solver?
Will CPLEX decide that multiplication of two variables is an error and cannot be compiled?

[Johan Löfberg]

You would have to supply a reproducible example for me to be able to say anything

No reason to define the parameter vG as a binary. Might lead to some weird effect perhaps where YALMIP tries to do something too clever dealing with that structure

[Michael Christon]

for j = 1:size(CN_Nb,1)

    st = [st, vG(j,:) .* (v(j,:) - 1) == 0];

end

My program is not complete, but it is enough to reflect the problem. 

This picture shows the running time of the program containing the above statements. Obviously, "LMI. Subsref" has a long running time.

The following figure shows the situation without the statement. Obviously, time is back to normal.

Why only two more constraints cost so much running time? I don't understand. Can you help me solve it?

[Johan Löfberg]

First, your ode is poorly vectorized, and that has to be fixed if you want to speed things up

Having said that, if you simply want to force some binaries to be 1, no reason to complicate matters with that bilinear zeroing which will be expensive to manipulate symbolically. Just write it as -vG <= v-1 <= vG and you get the same effect, activated when vG is 0, and inactive when vG>1