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

DC security analysis: support operator strategies #622

Closed
annetill opened this issue Oct 14, 2022 · 2 comments
Closed

DC security analysis: support operator strategies #622

annetill opened this issue Oct 14, 2022 · 2 comments
Assignees

Comments

@annetill
Copy link
Member

annetill commented Oct 14, 2022

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

A feature.

  • What is the current behavior?

We can only run a DC security analysis with contingencies but without any operator strategy.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

  • What is the expected behavior?

I think that the easiest way to handle this issue is to start by supporting LineConnectionAction. We can use the Metrix 6 buses case as unit test.

  • First, we run a classical DC security analysis with contingencies using the sensitivity analysis API.
  • After the run, for each contingency we have to check for each operator strategy if the condition is fulfilled. For that, we have to fix/improve the state monitor in order to involve all the branches necessary to check the conditions. Note that is can be done through the violations of the post-contingency state.
  • If the condition is fulfilled, we have to apply the action:
  1. In case of a line deconnection, you have to get the initial network, apply the contingency and apply the action as we do for AC implementation. It will update the system equation. Then run a DC loadflow and get the new violations.
  2. In case of a line connection, first we have to insure that the line is inside the initial network (maybe the complex part, I could help on that) but disabled. Then you apply the contingency and the action as described before. Then run a DC loadflow and get the new violations.
  • What is the motivation / use case for changing the behavior?

  • Please tell us about your environment:

    • PowSyBl Version: ...
    • OS Version: ...
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

jlbouchot added a commit that referenced this issue Oct 20, 2022
Signed-off-by: Jean-Luc Bouchot <jlbouchot@gmail.com>
@obrix
Copy link
Member

obrix commented Oct 25, 2022

@jlbouchot After some discussion with @annetill It seems one of the step for this implementation is to move AcSecurityAnalysis.runActionSimulation into AbstractSecurityAnalysis to be usable from DcSecurityAnalysis.
We should probably also create a DcLoadFlowContext and factorize what is in common with AcLoadFlowContext.

obrix pushed a commit that referenced this issue Nov 9, 2022
Signed-off-by: Jean-Luc Bouchot <jlbouchot@gmail.com>
@annetill
Copy link
Member Author

annetill commented Jan 9, 2024

I close the issue because after #927, AC and DC security analysis codes are shared. We just have to continue the work of implementing remaining remedial actions.

@annetill annetill closed this as completed Jan 9, 2024
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

No branches or pull requests

4 participants