adbuerger/pycombina

pycombina - Solving binary approximation problems in Python

pycombina's Issues

Installation error

Hello there,

I want use pycombina for my work (I used CPLEX before). However, I encounter installation errors on two different PCs, one with Intel CPU and the other with AMD.

The error messages for the two PCs are the same, and I put the screenshot here for you.

I installed MSVS 2019 community and Anaconda 2020.11, both in x64 version. I also installed CMake in Anaconda and in Windows. Could you help me solve this problem?

Best regards,

Yutao

Over-fulfillment of dwell time constraints

Setting dwell time constraints where the dwell time is a multiple of the step size on the time grid might lead to sporadic over-fulfillment of the defined dwell times in the binary solution. A fix is currently being worked on.

As a workaround, users can consider to slightly alter the duration of an according dwell time so that the corresponding control remains active for the same amount of time steps as with the original dwell time. For minimum dwell times, this would mean a slight decrease, and for maximum dwell times this would mean a slight increase of the original duration.

'set_max_up_times()' behaves like 'set_total_max_up_times'

When testing different types of combinatorial constraints, I noticed that set_max_up_times does not work as intended. The function limits the total up-time over the entire prediction horizon instead of limiting the time after activation.

I created a simple example (Python code: PycombinaTestCombinatorialConstraints.zip):
t=[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
b_rel=[0.9,0.9,0.8,0.7,0.1,0.,0.,0.7,0.8]

1. No combinatorial constraints

• b_bin=[1. 1. 1. 0. 0. 0. 0. 1. 1.]
• J_CIA=4.0e-1
• Benchmark

2. binapprox.set_min_up_times([4,0])

• b_bin=[1. 1. 1. 1. 0. 0. 0. 0. 1.]
• J_CIA=7.0e-1
• Works as intended

3. binapprox.set_max_up_times([3,0])

• b_bin=[1. 1. 1. 0. 0. 0. 0. 0. 0.]
• J_CIA=1.9e-0
• According to the definition this should give the same results as 1, but this is not the case; the last two values are 0 instead of 1. This simple example indicates that set_max_up_times limits the TOTAL number of 1’s instead of per activation

4. binapprox.set_total_max_up_times([3,0])

• b_bin=[1. 1. 1. 0. 0. 0. 0. 0. 0.]
• J_CIA=1.9e0
• This gives the same result as 3, indicating that both functions lead to the same result.

Symmetry Makes Things Slow

#19 uses cvxpy to abstract the MILP solver and #20 uses PuLP as an abstraction.

In #20, PuLP spends less time preprocessing (0.64s) than cvxpy (83s), but the problem PuLP generates takes CBC 402s to solve versus the 158s CBC takes to solve the problem cvxpy generates.

Both solve times can probably be substantially reduced by breaking symmetry.

Running

python3 setup.py test

on branches #19 and #20 gives the above run times.

The cvxpy branch (#19) passes the test_check_objective test while the PuLP branch (#20) fails this test with the error:

AssertionError: 1603.3299 != 1603.3298534939174 within 6 places (4.6506082526320824e-05 difference)

as we can see, the objective is (probably not) meaningfully different.

Therefore we can say that Gurobi, cvxpy+CBC, and PuLP+CBC all reach the same objective value. However, they disagree on the optimal solution. PuLP+CBC produces a control strategy that differs from Gurobi's in 22 of 359 (6.13%) elements. cvxpy+CBC produces a control strategy that differs from Gurobi's in 16 of 359 (4.46%) elements.

The strategies produced by all three approaches produce the same objective value, but otherwise differ. This implies that test problem, at least, has symmetries. Eliminating symmetries often accelerates time-to-solution. I wonder if we can find a way to do so here?

Fulfillment of dwell time contraints at end of time horizon

At the moment, dwell time constraints are not handled consistently at the end of the time horizon. We should therefore have a flag for the user to set whether dwell time constraints should be enforced at the end of the time horizon or not.

Dwell time sum-up rounding

Hi there,

currently, CombinaSUR does not support dwell times, i.e. min_up_times and max_down_times are ignored. However, the dwell time sum-up rounding algorithm (DSUR) described in this paper (section 6.1) yields promising results for huge CIA instances (n_oc * n_t > 5000), where the branch and bound algorithm is computationally too expensive.

Are there already any plans to include the DSUR algorithm? Provided there's interest, I could submit a PR.