If we want to run a series of power flows given a list of actions, we have to apply an action on the IIDM network and run a power flow, and start this again for all the remaining actions. It is not really efficient and the computation time could be saved through a dedicated API.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
What is the expected behavior?
I think that we can imagine an API similar to the security analysis one, but instead of given a list of contingencies, we can give a list of actions. The outputs will be active and reactive flows, voltages and angles, stored in BusResult objects and BranchResult objects, indexed by action.
There is a related question linked to modeling of actions. Do we have to rely on the iaL for that or can we imagine dedicated object to model them (OpenSiwtch(id), Increase(id, type_of_increase), Disconnect(id, SIDE (optional)), StartGenerator(id, targetP, targetQ, voltage_regulation_on)). The question is open. Indeed this is quite similar to the modelling of events for Dynawo integration (https://github.com/powsybl/powsybl-dynawo/tree/main/dynawaltz-dsl/src/main/groovy/com/powsybl/dynawaltz/dsl/events). Here the events are modeled through groovy but could be directly Java objects.
An other approach is to have a stronger integration between the IIDM network and the OpenLoadFlow where we build the LfNetwork and the equation system the first time and we keep it in cache for the other times. We can use the IIDM network listener to change directly the LfNetwork and then the equation system (linked to the LfNetwork with a listener too). In that solution, the most complex part is to now which breakers are going to be opened to build the exhaustive graph needed in the power flow calculation.
What is the motivation / use case for changing the behavior?
Please tell us about your environment:
PowSyBl Version: ...
OS Version: ...
Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)
A feature.
If we want to run a series of power flows given a list of actions, we have to apply an action on the IIDM network and run a power flow, and start this again for all the remaining actions. It is not really efficient and the computation time could be saved through a dedicated API.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
What is the expected behavior?
I think that we can imagine an API similar to the security analysis one, but instead of given a list of contingencies, we can give a list of actions. The outputs will be active and reactive flows, voltages and angles, stored in
BusResult
objects andBranchResult
objects, indexed by action.There is a related question linked to modeling of actions. Do we have to rely on the iaL for that or can we imagine dedicated object to model them (
OpenSiwtch(id)
,Increase(id, type_of_increase)
,Disconnect(id, SIDE (optional))
,StartGenerator(id, targetP, targetQ, voltage_regulation_on)
). The question is open. Indeed this is quite similar to the modelling of events for Dynawo integration (https://github.com/powsybl/powsybl-dynawo/tree/main/dynawaltz-dsl/src/main/groovy/com/powsybl/dynawaltz/dsl/events). Here the events are modeled through groovy but could be directly Java objects.An other approach is to have a stronger integration between the IIDM network and the
OpenLoadFlow
where we build theLfNetwork
and the equation system the first time and we keep it in cache for the other times. We can use the IIDM network listener to change directly theLfNetwork
and then the equation system (linked to theLfNetwork
with a listener too). In that solution, the most complex part is to now which breakers are going to be opened to build the exhaustive graph needed in the power flow calculation.What is the motivation / use case for changing the behavior?
Please tell us about your environment:
Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)
(if a question doesn't apply, you can delete it)