Skip to content
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

Merged
merged 33 commits into from
Sep 23, 2021

Conversation

Hadrien-Godard
Copy link
Member

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)

  • The commit message follows our guidelines
  • Tests for the changes have been added (for bug fixes / features)
  • Docs have been added / updated (for bug fixes / features)

Does this PR already have an issue describing the problem ? If so, link to this issue using '#XXX' and skip the rest

What 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:

  • The Breaking Change or Deprecated label has been added
  • The migration guide has been updated in the github wiki (What changes might users need to make in their application due to this PR?)

Other information:

(if any of the questions/checkboxes don't apply, please delete them entirely)

…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>
Copy link
Member

@annetill annetill left a 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>
annetill and others added 3 commits September 9, 2021 16:25
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>
@@ -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())));
Copy link
Member

@annetill annetill Sep 10, 2021

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));
Copy link
Member

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?

Hadrien-Godard and others added 14 commits September 10, 2021 13:51
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: 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();
Copy link
Member

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
Copy link
Member

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.

Copy link
Member Author

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);
Copy link
Member

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?

Copy link
Member Author

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));
Copy link
Member

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.

annetill and others added 3 commits September 14, 2021 16:42
…ation.

Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
…ncy instead of NaN

Signed-off-by: Hadrien <hadrien.godard@artelys.com>
@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 4 Code Smells

88.3% 88.3% Coverage
0.0% 0.0% Duplication

@flo-dup flo-dup merged commit ac2ef5f into master Sep 23, 2021
@flo-dup flo-dup deleted the fix_referenceflowscomputedwhenfunctionelementexists branch September 23, 2021 14:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants