Exception during contingency propagation

[sylvlecl]

• Do you want to request a feature or report a bug?

Bug

• What is the current behavior?

This issue has been encountered through pypowsybl binding : when computing sensitivities with contingencies on a node breaker test case, we frequently encounter null pointer exceptions, depending on the input contingencies.

See stack below, and a test case to reproduce it on that commit: https://github.com/powsybl/powsybl-open-loadflow/commit/42a11465da29aee659c20bb40985f1718cb9f7a1

java.lang.NullPointerException
	at com.powsybl.openloadflow.util.PropagatedContingency.isCoupler(PropagatedContingency.java:138)
	at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:176)
	at java.util.HashMap$KeySpliterator.tryAdvance(HashMap.java:1624)
	at java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:127)
	at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:502)
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:488)
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
	at java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:150)
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:543)
	at com.powsybl.openloadflow.util.PropagatedContingency.createListForSensitivityAnalysis(PropagatedContingency.java:76)
	at com.powsybl.openloadflow.sensi.OpenSensitivityAnalysisProvider.run(OpenSensitivityAnalysisProvider.java:208)
	at com.powsybl.openloadflow.sensi.OpenSensitivityAnalysisProvider.run(OpenSensitivityAnalysisProvider.java:167)

In the "isCoupler" method, we make the wrong assumption that a switch has terminals on both sides.

[annetill]

@sylvlecl thanks for your issue, we are going to try to fix that. I imagine that for you, it is not enough to just check if terminals are not equal to zero. What is a coupler for you, how can we find them ?

[sylvlecl]

You're right: just checking terminals are not null will avoid the null pointer but will not identify correctly couplers, in the general case. Most often, a coupler is connected to disconnectors, which are themselves connected to bus bars.

Therefore, to identify couplers, we must traverse the topology from the breaker in order to check if the first encountered equipments on both sides are bus bars (or configured bsues in bus breaker?). Note that there might be multiple bus bars on each side.

From a wider point of view, as far as I remember, that identification of couplers aims at identifying contingencies that we cannot simulate correctly for now in open loadflow : from that point of view, I am not 100% sure that identifying couplers will be enough to identify all those cases, maybe it needs more thoughts!

[flo-dup]

I created a PR based on your test branch with a traverser. In bus breaker view, isCoupler always returns false, as I'm not sure on how to detect it there. Besides, isn't it a bit tough though to use a traverser on each switch to open for all contingencies?

[geofjamg]

Can we close this issue?

Yes I think we can because contingency propagation is no longer supported in sensitivity analysis.