Honnor HVDCOperatorActivePowerRange as well as Pmax of hvdcLine in AC emulation #1005
Conversation
vidaldid-rte
changed the title
vidaldid-rte
force-pushed
the
hvdc_acemu_maxp
branch
from
26d0d32 to
bb6d735
Compare
src/main/java/com/powsybl/openloadflow/network/impl/LfHvdcImpl.java
Outdated
Show resolved
Hide resolved
| LoadFlow.Runner loadFlowRunner = new LoadFlow.Runner(new OpenLoadFlowProvider(new DenseMatrixFactory())); | ||
| LoadFlowParameters p = new LoadFlowParameters(); | ||
| p.setHvdcAcEmulation(true); | ||
| LoadFlowResult result = loadFlowRunner.run(network, p); |
There was a problem hiding this comment.
Is there a test with HvdcAngleDroopActivePowerControl but no HvdcOperatorActivePowerRange extension?
There was a problem hiding this comment.
@rosiereflo Yes. All other tests with HVDC in AC emulation. For example testHvdcDirectionChangeAcEmulation
There was a problem hiding this comment.
Do we have to take into account the active power range extension if the hvdc is operated in set point ?
There was a problem hiding this comment.
Good question @annetill
My approach was to consider that an extension has priority.
This is consistent with the fact that the AC emulation takes priority on both the mode (side of inverter/rectifier) and active power setPoint.
But there is nature for conflict because data is duplicated and we need to agree whether giving priority on the extension is what we want or not.
@rosiereflo
EDIT: My comment was actually on the fact that poweRange has priority over hvdcLine.pmax (I had read Anne's point too quicky)
There was a problem hiding this comment.
Also the fix did not cover the case where AC Emlulation is off.
There was a problem hiding this comment.
But I have not seen consistency check between p and pmax in HvdcLineAdder
There was a problem hiding this comment.
In OLF, I have noticed that we can have a generator with a targetP over Pmax, it is not forbidden but maybe it should... for VSC converter station, no check either. Any idea @geofjamg ?
There was a problem hiding this comment.
For generators it is very common to have a targetP outside Pmin/Pmax on real data.
Usual expected behavior for these is just to leave them where they are outside Pmin/Pmax and don't change them at all, e.g. exclude them from slack distribution.
I would be against enforcing targetP within Pmin/Pmax for generators in iIDM. Same for reactive power.
For HVDC I don't have any strong opinion though... There aren't that much, and AC emulation is ultra specific to few links.
There was a problem hiding this comment.
So we can say that it is the user's responsibility and not the purpose of this fix, related to hvdc in AC emulation.
Signed-off-by: VIDAL Didier (Externe) <didier.vidal_externe@rte-france.com>
Signed-off-by: VIDAL Didier (Externe) <didier.vidal_externe@rte-france.com>
Signed-off-by: VIDAL Didier (Externe) <didier.vidal_externe@rte-france.com>
Signed-off-by: VIDAL Didier (Externe) <didier.vidal_externe@rte-france.com>
Signed-off-by: VIDAL Didier (Externe) <didier.vidal_externe@rte-france.com>
vidaldid-rte
force-pushed
the
hvdc_acemu_maxp
branch
from
bc65016 to
586cfe9
Compare
|
annetill
changed the title
Please check if the PR fulfills these requirements
What kind of change does this PR introduce?
Take into account active power limits of HVDC in AC emulations
They can be defined by
maxP in the HVDC line
Or in the HvdcOperatorActivePowerRange extension that provides a limit in each direction
What is the current behavior?
Limits are ignored in AC Emulation
What is the new behavior (if this is a feature change)?
Limits are honoured.
If P0+KdeltaPhi out of range, P is capped to a bound of the range?
Does this PR introduce a breaking change or deprecate an API?