Because SOC is defined as current energy stored in the system divided by total energy capacity, both of which are problem variables which makes SOC an @NLexpression. Modeling SOC as an @expression would require that I explicitly fix the total energy capacity of the system instead of it being left to the optimization.
You may find this report and example interesting, [2004.14768] A Flexible Storage Model for Power Network Optimization, a few NL constraints should be sufficient for modeling very general energy storage devices.
A probably out of date reference implementation is here, GitHub - lanl-ansi/energy-storage-example: An example of energy storage optimization using PowerModels
Thank you for this! I will take a closer look and see if I can use splines to model the charge/discharge curves.
EDIT: Hi @jd-foster, I have had a look at the paper. My understanding is that splines allow a more complex interpolation compared to the standard linear interpolation methodology. However, based on the model variables and structure I have, I believe I would still run into the issue of having to use ifelse statements to determine at which point on the curve (i.e., which spline parameters to use) to calculate the discharge/charge power at a particular SOC.
Thank you for this! Actually, I only need 1 constraint (the aim was to replace a linear constraint with a piecewise-linear or piecewise-nonlinear constraint). But, it the piecewise route causes issues, I could use a single function to represent the relationship between SOC and power although this might be less accurate than the piecewise models.
Hi @odow
When I run simulations after including the SOS constraints, Gurobi goes into the solution phase where it tries to reduce the MIP gap to below the tolerance although this is not a MIP model. In the attached screenshot, I have shown the terminal outputs of 2 cases - one with only 2 SOS constraints and the other with a lot. In the former, integer variables are somehow created after the presolve phase which I guess justifies Gurobi trying to reduce the MIP gap. Anyway, for this case, it exits this phase after the first iteration and the problem converges quickly. For the actual case of interest with 17520 SOS constraints, integer variables are not created after pre-solve but Gurobi is still trying to reduce the MIP gap for some reason. This case does not converge and the terminal shows that there are no incumbent or gap values. Do you know what the issue is here? Increasing the number of SOS constraints beyond a threshold seems to the be the root cause
.
Yes, Gurobi may struggle if you have a large number of SOS constraints. There’s no good solution here. Your model is just hard to solve.
Ah, ok. Then I will try a simpler model. Thank you for this discussion Oscar! It has really helped, appreciate it.
1 Like
No problem. I’d look into some of the links others have provided above.