-
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
Fix reference flow that were not computed and set as NaN when variable element is not in the main component but function element is #349
Fix reference flow that were not computed and set as NaN when variable element is not in the main component but function element is #349
Conversation
…e element factor does not exist but function element does. Signed-off-by: Hadrien <hadrien.godard@artelys.com>
Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
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.
Can you please check my two last commits and increase the test coverage ?
Signed-off-by: Hadrien <hadrien.godard@artelys.com>
Signed-off-by: Hadrien <hadrien.godard@artelys.com>
Signed-off-by: Hadrien <hadrien.godard@artelys.com>
Signed-off-by: Hadrien <hadrien.godard@artelys.com>
…y loss. There is no need to use predefined results for reference values of SKIP_ONLY_VARIABLE factors Signed-off-by: Hadrien <hadrien.godard@artelys.com>
Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
Signed-off-by: Hadrien <hadrien.godard@artelys.com>
@@ -50,6 +50,8 @@ private void calculateSensitivityValues(List<LfSensitivityFactor<AcVariableType, | |||
String contingencyId, int contingencyIndex, SensitivityValueWriter valueWriter) { | |||
Set<LfSensitivityFactor<AcVariableType, AcEquationType>> lfFactorsSet = new HashSet<>(lfFactors); | |||
lfFactors.stream().filter(factor -> factor.getStatus() == LfSensitivityFactor.Status.ZERO).forEach(factor -> valueWriter.write(factor.getContext(), contingencyId, contingencyIndex, 0, Double.NaN)); | |||
lfFactors.stream().filter(factor -> factor.getStatus() == LfSensitivityFactor.Status.SKIP_ONLY_VARIABLE).forEach(factor -> valueWriter.write(factor.getContext(), contingencyId, contingencyIndex, 0, unscaleFunction(factor, factor.getFunctionReference()))); |
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.
0
for value is not consistent with the Double.NaN
chosen as value for SKIP
factor.
} | ||
|
||
valueWriter.write(factor.getContext(), contingency != null ? contingency.getContingency().getId() : null, contingency != null ? contingency.getIndex() : -1, | ||
0d, unscaleFunction(factor, flowValue)); |
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.
Here we choose 0
for sensitivity value, it is what you want? Or is it better to choose Double.NaN
?
Signed-off-by: Hadrien <hadrien.godard@artelys.com>
…ltRef to handle the special case where we know that the sensitivity is null (variable and function elements are in different connected componants in the pre contingency network), but the reference flow can be computed in the pre contingency network, and not in the post contingency one. Here the sensitivity equals 0 but the reference flow should be set to NaN for the post contingency case. Signed-off-by: Hadrien <hadrien.godard@artelys.com>
Replace SKIP_ONLY_VARIABLE by VALID_REFERENCE Signed-off-by: Hadrien <hadrien.godard@artelys.com>
Signed-off-by: Hadrien <hadrien.godard@artelys.com>
Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
Signed-off-by: Hadrien <hadrien.godard@artelys.com>
…nctionelementexists' into fix_referenceflowscomputedwhenfunctionelementexists
Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
connectivityAnalysisResult.setPredefinedResults(); | ||
lfFactorsForContingencies.forEach(factor -> factor.setSensitivityValuePredefinedResult(null)); | ||
lfFactorsForContingencies.forEach(factor -> factor.setFunctionPredefinedResult(null)); | ||
connectivityAnalysisResult.setSensitivityValuePredefinedResults(); |
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.
Why do you need these two lines?
factor.setSensitivityValuePredefinedResult(0d); | ||
} | ||
if (!variableConnected && !functionConnected) { | ||
// SKIP status |
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.
Here I think that this level of details is not needed: in case of factor with SKIP status, in pre-contingency state, you write NaN
for sensi and NaN
for function. But you introduce a new level of detail after a contingency. It is not coherent and I think that if it is more right, it is less perfomant.
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 agree with you.
Indeed, in precontingency network, skip status is used when both variable and function are disconnected from slack and the sensitivity is set to NaN.
But in case of a contingency breaking connectivity we treat the case where both function and element are disconnected from slack and are in different connected components with a 0 value for the sensitivity.
This behavior is not coherent.
Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
@@ -129,7 +134,9 @@ protected static Terminal getEquipmentRegulatingTerminal(Network network, String | |||
|
|||
boolean areVariableAndFunctionDisconnected(GraphDecrementalConnectivity<LfBus> connectivity); | |||
|
|||
boolean isConnectedToComponent(Set<LfBus> connectedComponent); | |||
boolean isVariableConnectedToSlackComponent(Set<LfBus> connectedComponent); |
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.
What is for me a bit hard to understand if that these two functions are not used for pre-contingency state. It is an incoherent behavior, no?
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.
Those two functions are not used for pre-contingency state indeed and we only check if variable and function element are in slack connected component. This may result to an incoherent behavior regarding SKIP status as discussed in another comment.
Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
skippedFactors.forEach(factor -> valueWriter.write(factor.getContext(), null, -1, 0, Double.NaN)); | ||
// SKIP factors are for factors where both variable and function elements are not in the main connected componant. | ||
// Therefore, their sensitivity and reference values are set to NaN. | ||
skippedFactors.forEach(factor -> valueWriter.write(factor.getContext(), null, -1, Double.NaN, Double.NaN)); |
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.
See, for base case, SKIP is always NaN and NaN.
…ation. Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
…ncy instead of NaN Signed-off-by: Hadrien <hadrien.godard@artelys.com>
Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
Kudos, SonarCloud Quality Gate passed! |
Signed-off-by: Hadrien hadrien.godard@artelys.com
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 restWhat kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
What is the current behavior? (You can also link to an open issue here)
What is the new behavior (if this is a feature change)?
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)