-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AC Security Analysis with operator strategies #590
Conversation
src/main/java/com/powsybl/openloadflow/sa/AcSecurityAnalysis.java
Outdated
Show resolved
Hide resolved
430450c
to
2e77e2c
Compare
src/main/java/com/powsybl/openloadflow/sa/AcSecurityAnalysis.java
Outdated
Show resolved
Hide resolved
try { | ||
network.getSwitchStream().filter(sw -> sw.getVoltageLevel().getTopologyKind() == TopologyKind.NODE_BREAKER) | ||
.forEach(sw -> sw.setRetained(false)); | ||
allSwitchesToOpen.forEach(sw -> sw.setRetained(true)); | ||
allSwitchesToClose.forEach(sw -> { | ||
sw.setRetained(true); | ||
sw.setOpen(false); // in order to be present in the network. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the ugly part of this PR. Not easy to do otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:-) thanks! Note that there is for me a bug in the current code because we create a variant but we don't use it.
engine.getContext().getEquationSystem(); | ||
if (!allSwitchesToClose.isEmpty()) { | ||
var connectivity = network.getConnectivity(); | ||
allSwitchesToClose.stream().map(Identifiable::getId).forEach(id -> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'am going to think about a way to avoid this hack (probably no way...)
operatorStrategyResults.add(optionalOperatorStrategyResult.get()); | ||
} | ||
} else { | ||
LOGGER.warn("A contingency has several operator strategies: not supported yet"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you plan to implement it in this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, because it requires a save/restore of the network state just after contingency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And why is it a problem? Is there something different to do that what we are doing for contingencies?
src/main/java/com/powsybl/openloadflow/sa/AcSecurityAnalysis.java
Outdated
Show resolved
Hide resolved
|
||
boolean postActionsComputationOk = postActionsLoadFlowResult.getNewtonRaphsonStatus() == NewtonRaphsonStatus.CONVERGED; | ||
// FIXME: to be checked. | ||
var postActionsViolationManager = new LimitViolationManager(preContingencyLimitViolationManager, violationsParameters); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So here reference is still the base case, for violation increase criteria?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sylvlecl and @EtienneLt : it was my question... I don't know :-) Any opinion ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Internal processes compare post-action state to pre-contingency state to detect worsened violations.
src/main/java/com/powsybl/openloadflow/sa/AcSecurityAnalysis.java
Outdated
Show resolved
Hide resolved
} | ||
if (enabledBranch != null) { | ||
enabledBranch.setDisabled(false); | ||
enabledBranch.getBus1().setDisabled(false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to enable buses ? In which case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes we need it (see the unit tests) and indeed in it really not enough. For example, when we reconnect a switch that will reconnect a small component, the buses and branches of this component but be enabled. This is not handle here. @flo-dup how to do this with your connectivity?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So yes, this is not the right thing to do. We should be able to get from connectivity, the list of buses and branches that have been reconnected to main connected component. Here by just enabling side buses, we only enable a small part of potential sub network reconnected.
|
||
private LfNetwork network; | ||
|
||
public LfAction(Action action, LfNetwork network) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the plan here is to support a list of action and that LfAction will be the sum/result of PowSyBl Core actions for the current strategy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No: we keep a list of LfAction for an operator strategy. I am not able to do better...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When all design issues will be solved it should be easy to support
Signed-off-by: Geoffroy Jamgotchian <[email protected]>
Signed-off-by: Geoffroy Jamgotchian <[email protected]>
Signed-off-by: Geoffroy Jamgotchian <[email protected]>
Signed-off-by: Florian Dupuy <[email protected]>
Signed-off-by: Florian Dupuy <[email protected]>
Signed-off-by: Florian Dupuy <[email protected]>
Signed-off-by: Florian Dupuy <[email protected]>
Signed-off-by: Florian Dupuy <[email protected]>
Signed-off-by: Florian Dupuy <[email protected]>
Signed-off-by: Anne Tilloy <[email protected]>
Signed-off-by: Anne Tilloy <[email protected]>
Signed-off-by: Anne Tilloy <[email protected]>
Signed-off-by: Anne Tilloy <[email protected]>
Signed-off-by: Anne Tilloy <[email protected]>
Signed-off-by: Anne Tilloy <[email protected]>
Signed-off-by: Anne Tilloy <[email protected]>
Signed-off-by: Geoffroy Jamgotchian <[email protected]>
Signed-off-by: Anne Tilloy <[email protected]>
Signed-off-by: Anne Tilloy <[email protected]>
Signed-off-by: Geoffroy Jamgotchian <[email protected]>
Signed-off-by: Geoffroy Jamgotchian <[email protected]>
Signed-off-by: Anne Tilloy <[email protected]>
Signed-off-by: Anne Tilloy <[email protected]>
Signed-off-by: Anne Tilloy <[email protected]>
Signed-off-by: Anne Tilloy <[email protected]>
Signed-off-by: Anne Tilloy <[email protected]>
# Conflicts: # src/main/java/com/powsybl/openloadflow/sa/AbstractSecurityAnalysis.java
Signed-off-by: Geoffroy Jamgotchian <[email protected]>
var connectivity = network.getConnectivity(); | ||
allSwitchesToClose.stream().map(Identifiable::getId).forEach(id -> { | ||
LfBranch branch = network.getBranchById(id); | ||
branch.setDisabled(true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@annetill we only re-enable switches to close, but we should do it to for sub network that could be move out of main cc by this branch disabling?
Signed-off-by: Geoffroy Jamgotchian <[email protected]>
Signed-off-by: Geoffroy Jamgotchian <[email protected]>
Signed-off-by: Geoffroy Jamgotchian <[email protected]>
Signed-off-by: Geoffroy Jamgotchian <[email protected]>
Signed-off-by: Geoffroy Jamgotchian <[email protected]>
Signed-off-by: Anne Tilloy <[email protected]>
…wsybl-open-loadflow into try-as-with-actions-2
|
||
// re-update connectivity according to post contingency state (revert after LfContingency apply) | ||
connectivity.startTemporaryChanges(); | ||
contingency.getDisabledBranches().forEach(connectivity::removeEdge); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we support a bus contingency (bus/bar section or bus from a bus/breaker topology)? If one day yes, we also have to remove the disabled buses.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, we should add it now to not forget it later
@@ -546,6 +546,7 @@ public GraphConnectivity<LfBus, LfBranch> getConnectivity() { | |||
getBranches().stream() | |||
.filter(b -> b.getBus1() != null && b.getBus2() != null) | |||
.forEach(b -> connectivity.addEdge(b.getBus1(), b.getBus2(), b)); | |||
connectivity.setMainComponentVertex(getSlackBus()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@flo-dup can you please just take a look at this change and tell us if it is okay for you. Thanks!
Signed-off-by: Anne Tilloy <[email protected]>
Signed-off-by: Anne Tilloy <[email protected]>
Signed-off-by: Anne Tilloy <[email protected]>
Signed-off-by: Anne Tilloy <[email protected]>
Signed-off-by: Geoffroy Jamgotchian <[email protected]>
Signed-off-by: Geoffroy Jamgotchian <[email protected]>
Kudos, SonarCloud Quality Gate passed! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@geofjamg I agree with your improvements. Thanks for your help!
Please check if the PR fulfills these requirements (please use
'[x]'
to check the checkboxes, or submit the PR and then click the checkboxes)Does this PR already have an issue describing the problem ? If so, link to this issue using
'#XXX'
and skip the restNo
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Feature
What is the new behavior (if this is a feature change)?
We are able to simulate operator strategies, like switch closing and opening, phase shifter tap change, line reconnection.
Does this PR introduce a breaking change or deprecate an API? If yes, check the following:
Other information:
(if any of the questions/checkboxes don't apply, please delete them entirely)