Conversation
Signed-off-by: PRABAKARAN Sylvestre <sylvestre.prabakaran@rte-france.com>
SylvestreSakti
changed the title
…s after freezing) Signed-off-by: PRABAKARAN Sylvestre <sylvestre.prabakaran@rte-france.com>
Signed-off-by: PRABAKARAN Sylvestre <sylvestre.prabakaran@rte-france.com>
Signed-off-by: PRABAKARAN Sylvestre <sylvestre.prabakaran@rte-france.com>
Signed-off-by: PRABAKARAN Sylvestre <sylvestre.prabakaran@rte-france.com>
Signed-off-by: PRABAKARAN Sylvestre <sylvestre.prabakaran@rte-france.com>
Signed-off-by: PRABAKARAN Sylvestre <sylvestre.prabakaran@rte-france.com>
Signed-off-by: PRABAKARAN Sylvestre <sylvestre.prabakaran@rte-france.com>
|
|
||
| protected AbstractHvdcAcEmulationFlowEquationTerm(LfHvdc hvdc, LfBus bus1, LfBus bus2, VariableSet<AcVariableType> variableSet) { | ||
| super(hvdc); | ||
| ph1Var = variableSet.getVariable(bus1.getNum(), AcVariableType.BUS_PHI); |
There was a problem hiding this comment.
The removal of P boundaries in the equations may theoretically lead to another source of divergence:
If the NR solution around the HVDC links has a large angle, this may generate a flow over
transmissible PMAX and cause the NR to diverge while the situation would be OK in reality.
How can we check whether this risk is real or not for realistic networks ?
There was a problem hiding this comment.
@SylvestreSakti for this, I suggest that we just remember the risk (maybe with a comment) and if this really causes divergence we modify the curve above the linear part so that it keeps a non null derivative but is bounded
src/main/java/com/powsybl/openloadflow/ac/outerloop/FreezingHvdcACEmulationOuterloop.java
Outdated
Show resolved
Hide resolved
src/main/java/com/powsybl/openloadflow/ac/outerloop/FreezingHvdcACEmulationOuterloop.java
Show resolved
Hide resolved
src/main/resources/com/powsybl/openloadflow/reports_fr.properties
Outdated
Show resolved
Hide resolved
src/main/java/com/powsybl/openloadflow/lf/outerloop/AbstractHvdcAcEmulationLimitsOuterLoop.java
Show resolved
Hide resolved
src/main/java/com/powsybl/openloadflow/dc/DcHvdcAcEmulationLimitsOuterLoop.java
Show resolved
Hide resolved
src/main/java/com/powsybl/openloadflow/dc/DcHvdcAcEmulationLimitsOuterLoop.java
Outdated
Show resolved
Hide resolved
src/main/java/com/powsybl/openloadflow/ac/outerloop/AcHvdcAcEmulationLimitsOuterLoop.java
Outdated
Show resolved
Hide resolved
src/main/java/com/powsybl/openloadflow/ac/outerloop/AcHvdcAcEmulationLimitsOuterLoop.java
Show resolved
Hide resolved
| } | ||
|
|
||
| protected static Optional<DcOuterLoop> createDcHvdcAcEmulationLimitsOuterLoop(LoadFlowParameters parameters) { | ||
| if (parameters.isHvdcAcEmulation()) { |
There was a problem hiding this comment.
That looks like a breaking change
If AC emulation is on, saturation is taken into account, and it was not before.
In addition, how does it work with woodbury-based algorithms (sensi and security analyss)
- They assume the system is linear. If we take saturation into account, it is not.
- If they do not run the outerloops, then the N case is different from the loadflow.
There was a problem hiding this comment.
This is indeed a functional breaking change. To explicit this, we can (as discussed) add a parameter to activate or not the use of saturation for DC mode (triggering a warning when we want to use that in Woodbury engine since it breaks the linearity of the problem).
Another idea would be to detect saturation in post process in Woodbury sensi and security analysis, to launch a second analysis with saturated mode. To be discussed.
src/main/java/com/powsybl/openloadflow/lf/outerloop/AbstractHvdcAcEmulationLimitsOuterLoop.java
Outdated
Show resolved
Hide resolved
Signed-off-by: PRABAKARAN Sylvestre <sylvestre.prabakaran@rte-france.com>
Signed-off-by: PRABAKARAN Sylvestre <sylvestre.prabakaran@rte-france.com>
Signed-off-by: PRABAKARAN Sylvestre <sylvestre.prabakaran@rte-france.com>
Signed-off-by: PRABAKARAN Sylvestre <sylvestre.prabakaran@rte-france.com>
Signed-off-by: PRABAKARAN Sylvestre <sylvestre.prabakaran@rte-france.com>
Signed-off-by: PRABAKARAN Sylvestre <sylvestre.prabakaran@rte-france.com>
Signed-off-by: PRABAKARAN Sylvestre <sylvestre.prabakaran@rte-france.com>
|
2 participants
This code is largely inspired from #1048 and rebased to the current version (especially including handling of frozen HVDC Ac emulation state)
Please check if the PR fulfills these requirements
Does this PR already have an issue describing the problem?
No
What kind of change does this PR introduce?
Change of the model to simulate HVDC AC Emulation limits
What is the current behavior?
Hvdc Ac Emulation state is handled directly in the Jacobian Matrix (depending on the state, the Equation term switches between linear mode, saturated mode or frozen mode with the corresponding derivatives). This lead in very rare cases to divergence due to zero derivative when being in saturated mode.
What is the new behavior (if this is a feature change)?
The Jacobian Matrix handles only the linear mode of AC Emulation. An outer loop checks if the AC Emulation overpasses limits and switches to fixed set point (by setting target P of VSC converters in the TargetVector).
Does this PR introduce a breaking change or deprecate an API?