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

Compute reference active power flows for sensitivity analysis #206

Merged
merged 35 commits into from
Feb 8, 2021

Conversation

Djazouli
Copy link
Contributor

Signed-off-by: Gael Macherel gael.macherel@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
#205

Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
@Djazouli Djazouli force-pushed the recompute_function_ref branch from 438e157 to 2d924e3 Compare January 26, 2021 16:11
Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
…s within the main component

Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
@Djazouli Djazouli requested review from annetill and geofjamg January 28, 2021 13:06
Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
Djazouli and others added 4 commits January 29, 2021 16:03
Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
…alization when having successive contingencies

Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
@Djazouli Djazouli force-pushed the recompute_function_ref branch from fd67e6b to c114a33 Compare February 1, 2021 18:39
Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
@geofjamg
Copy link
Member

geofjamg commented Feb 2, 2021

Because in DC approximation, the power factor does not exist for example. And we have not implemented the slack distribution on conform load (and we will not in the short term) in sensitivity analysis.

But this could be solved by a pre-check on sensi DC side and keep the utility class generic

Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
DcLoadFlowParameters dcLoadFlowParameters = new DcLoadFlowParameters(lfParametersExt.getSlackBusSelector(), matrixFactory,
true, lfParametersExt.isDcUseTransformerRatio(), lfParameters.isDistributedSlack(), lfParameters.getBalanceType());
DcLoadFlowResult dcLoadFlowResult = new DcLoadFlowEngine(lfNetworks, dcLoadFlowParameters).run();
private GraphDecrementalConnectivity<LfBus> createConnectivity(LfNetwork lfNetwork) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@floriand-e2r Can you move this function to a network util class ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've put it in LfNetwork directly (similarly to createZeroImpedanceSubGraph())

Map<LfBus, BusState> busStates = new HashMap<>();
if (lfParameters.isDistributedSlack()) {
double mismatch;
if (connectivity != null) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@floriand-e2r we have to think about making this "common".

participatingElements = step.getParticipatingElements(lfNetwork);
ParticipatingElement.normalizeParticipationFactors(participatingElements, "bus");
return participatingElements;
return getParticipatingElements(lfNetwork, loadFlowParameters, element -> true);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure to get the aim of this function...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It allows you to get the normalized participating elements

Copy link
Member

@annetill annetill Feb 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed I get it, it is to filter. Now, you have on bus a boolean on bus isDisabled. Do you think that it is possible to use that attribute to deal with connectivity? Then it will update the participating elements.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is possible to use the isDisabled attribute, but it less efficient.
To use the isDisabled parameter, I think we would need to:

  • Save all the buses states
  • Go through all the buses and disconnect the one that needs to be disconnected
  • Go through all the buses to get the non-disconnected participating elements
  • Restore all the buses states

With the current filtering in the DC getParticipatingElements, we are just doing:

  • Go through all the buses to get participating elements and get the one in the right connected component

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking about save the state of the bus that initial contains a participating element. Then, you disabled those that are not in the main connected component of this connectivity. Then, you can use the classical getParticipatingElements. Then you restore the buses that initially contain participating element. It is just to ensure coherence in the code, but it is not a bit deal.

Djazouli and others added 5 commits February 2, 2021 18:18
Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
Signed-off-by: Florian Dupuy <florian.dupuy@rte-france.com>
Signed-off-by: Florian Dupuy <florian.dupuy@rte-france.com>
Copy link
Contributor

@flo-dup flo-dup left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I first thought that you needed a change in GraphDecrementalConnectivity to simplify your connectivity code, but in fact you can use getSmallComponents() instead of getComponentNumber() almost everywhere, if not everywhere. There is two places where I'm not so sure about that:

  • areVariableAndFunctionDisconnected(): do you really need to know if variable and function are in two distinct "small" connected components?
  • getElementsToReconnect(): I don't think we can avoid using getComponentNumber(), do you agree on that?

Why am I trying to make those changes? Because in implementations of decremental connectivity the getComponentNumber needs some additional time to compute the map giving the number from the vertex.

// set buses injections and transformers to 0 outside the main connected component
int mainComponentNumber = connectivity.getComponentNumber(network.getSlackBus());
List<Integer> columnsToSetToZero = network.getBuses().stream()
.filter(lfBus -> connectivity.getComponentNumber(lfBus) != mainComponentNumber)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To get the buses which are not in the main component you should use directly connectivity.getSmallComponents()

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, I think getSmallComponents() returns the smallest components in size, but it has nothing to do with the slack bus (the slack could be in a small component). What I want here are the buses that are not in the same component than the slack bus.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, but couldn't we make the assumption that the slack bus is in the biggest component in size? I thought you could, but well I might be mistaken - calling @annetill and @geofjamg to the rescue!

lfFactors.forEach(factor -> factor.setPredefinedResult(null));
cutConnectivity(lfNetwork, connectivity.getConnectivity(), breakingConnectivityCandidates);
cutConnectivity(lfNetwork, connectivity, breakingConnectivityCandidates);
int mainComponent = connectivity.getComponentNumber(lfNetwork.getSlackBus());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Always equal to 0

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See previous comment, I am not sure about this

// check if the factor function and variable are in different connected components
if (factor.areVariableAndFunctionDisconnected(connectivity)) {
factor.setPredefinedResult(0d);
} else if (!factor.isConnectedToComponent(mainComponent, connectivity)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You always call isConnectedToComponent with mainComponent, so in fact you could rename it to isConnectedToMaintComponent and use getSmallComponents() instead of getComponentNumber()

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See previous conversation

annetill and others added 4 commits February 3, 2021 15:15
Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
@annetill annetill changed the title [WIP] Compute function references from within sensitivity analysis Compute reference active power flows for sensitivity analysis Feb 4, 2021
Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
…or get branch

Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
@flo-dup flo-dup force-pushed the recompute_function_ref branch from 547ce9a to 2b53ee1 Compare February 5, 2021 16:38
…not need to set alpha 1 to 0

Signed-off-by: Gael Macherel <gael.macherel@artelys.com>
@sonarqubecloud
Copy link

sonarqubecloud bot commented Feb 8, 2021

Kudos, SonarCloud Quality Gate passed!

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

98.6% 98.6% Coverage
0.0% 0.0% Duplication

@annetill annetill merged commit 0fae72a into master Feb 8, 2021
@annetill annetill deleted the recompute_function_ref branch February 8, 2021 09:45
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.

Recompute function references when doing sensitivity analysis with contingencies
4 participants