add opf controllability option for from_mpc

[jerelang]

• converted ext_grid/gen elements from importing MATPOWER/PYPOWER OPF cases may be treated as fixed setpoints, ignoring their limits
• adds optional set_opf_controllable parameter to from_ppc and from_mpc
• marks converted ext_grid and gen elements as controllable when the option is enabled
• useful for converting MATPOWER/PYPOWER OPF cases where generator injections should be optimized within their limits

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.00%. Comparing base (9997bd3) to head (5b08951).

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #2978   +/-   ##
========================================
  Coverage    72.00%   72.00%           
========================================
  Files          352      352           
  Lines        38311    38316    +5     
========================================
+ Hits         27584    27589    +5     
  Misses       10727    10727           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[vogt31337]

@jerelang , thanks for the PR. Do I understand it correctly, that this will set all ext_grid / gens to controllable if the flag is selected?

Would it not make more sense to select which one is actually controllable, based on for example if a user defined price curve is available?

[jerelang]

@vogt31337 , thanks for the review. Yes, this just sets all ext_grids/gens to controllable. I should have moved this up into from_mpc, as it is only MATPOWER specific.
I may have gotten something wrong, but in my understanding MATPOWER does neither have any controllable flags for its gens nor the pandapower "ext_grid". Therefore, converting some gens to "ext_grid" and defaulting to controllable=False, would alter the original MATPOWER OPF problem. In my case, the small PGLib-OPF benchmark case "pglib_opf_case30_ieee.m" was not solvable unless the converted ext_grid was made controllable.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[vogt31337]

@jerelang , hmm seems to be specific for the matpower opf. Would you think it would make Sense to make These gens / ext_grids always controllable?
I thought about a mechanism Like when No cost is associated or some other Flags are set.

[jerelang]

@vogt31337 If I understood it correctly, MATPOWER handles controllability completely using just the P and Q limits for each gen, so setting all to controllable by default for MATPOWER specifically and therefore not ignoring the limits anymore should be correct. I do not know however if the controllable flag for the gens has use or implications outside of OPF, which is why I implemented it as an opt-in argument.
I don't think filtering on if a cost exists would be good, as the costs are handled separately and it is possible to have controllable generators without a cost.
What could be better as a safeguard could be to set only those gens to controllable, where at least a P or Q limit exists.

[vogt31337]

I think this greatly depends on the modelling. I can Imagine scenarios in which only some gens are controllable. For example to calculate If redispatching renewables will solve a Problem.
This can be designed by setting conventional Gens to be very expensive, or by Not letting the opf Control them at all.
I am Just thinking If this is from matpower, then all the Gens would have been controlled by matpower opf.

[jerelang]

You are absolutely right about scenarios where one does not want all gens to be controllable!
What I am getting at is that in MATPOWER all gens are always controllable and there is no direct way to flag them non controllable. The only way in MATPOWER OPF seems to be by setting the OPF limits to the same value (e.g. P_min=P_max) or by modeling it as something other than a gen. The issue now is that when from_mpc converts some of the reference gens to ext_grid and sets controllable=False, it enforces the respective setpoint of the gen and ignores the OPF limits. This is a separate value and might be different than the limits, even when it is one value (e.g. P_min=P_max). So my argument is, that setting any gen to non controllable currently actually changes the original OPF MATPOWER problem, even when the gens in MATPOWER were supposed to be fixed to a certain value. Flagging all gens to controllable preserves the OPF limits, which means also the fixed behaviour as defined in the original MATPOWER case when the limits are equal.
I think this actually needs to be the default (for MATPOWER only).

[vogt31337]

@jerelang , I thought about your proposal, and I think you are right. Setting everything to controllable and then fixing it with the boundaries P_min = P_max seems like a viable option. Therefore I would like to include your PR. But a small fix has to be done.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[jerelang]

Alright, I moved the test inside the existing from_mpc test file and used the same example networks. I left the controllability option turned off as default.