fictive load on isolated bus keeps hvdc isolated #1120
Conversation
vidaldid-rte
requested review from
geofjamg,
jeandemanged,
SylvestreSakti and
Hadrien-Godard
vidaldid-rte
changed the title
| @@ -412,6 +412,13 @@ public double getLoadTargetP() { | |||
| .sum(); | |||
| } | |||
|
|
|||
| @Override | |||
| public double getNonFictitiousLoadTargetP() { | |||
There was a problem hiding this comment.
Are you sure there is no performance impact to compute this on the fly ?
There was a problem hiding this comment.
The laternative I see would be
- to compute incrementally this value for all buses in each event modifying the loads.
Seems complex and gain is not obvious - to cache it at bus creation, ignoring deconnection events, actions etc..
Might cause bugs
Here it is computed;
at each restore, for each HVDC station
at contingency propagation for each HVDC
and you pay an iteration price if the bus has several loads.
This being said I'll run some mesures of this cost on a large network.
There was a problem hiding this comment.
It has ZERO performance impact the way it is used today for this new usage.
The method was never called in a sensitivity analysis of a large network with 100 contingencies.
The reason is that restoreInitialTopology that will trigger the call for each HVDC link is called in very rare and targeted occasions - when some switches are moved. So I suggest to keep it simple stupid at this time.
There was a problem hiding this comment.
Indeed it seems to be only called at Lf Network loading so only one time.
There was a problem hiding this comment.
And only if an HVDC's station bus is disabled....
| private static boolean isIsolated(Terminal terminal, LfNetworkParameters parameters) { | ||
| Bus bus = parameters.isBreakers() ? terminal.getBusBreakerView().getBus() : terminal.getBusView().getBus(); | ||
| private static boolean isIsolated(Terminal terminal) { | ||
| Bus bus = terminal.getBusView().getBus(); |
There was a problem hiding this comment.
I would rather agree on this change, but has it been motivated by something failing?
There was a problem hiding this comment.
No. Just the fact that when I wrote it first I didn't fully understand the difference betwwen BusView and BusBreakerVew
There was a problem hiding this comment.
So maybe we should revert this change and think about it in another one.
There was a problem hiding this comment.
Oh la la... So it can breaks something in a topology I have seen where HVDC disconnection matters. I'll show you next time we meet.
There was a problem hiding this comment.
So in that case, you just need to add a unit test that shows the issue.
There was a problem hiding this comment.
Done. That was a bit trickier that I thought - and the bug is more seldom that I though because:
- the breaker mode is activated in very rare occasions
- the criteria is only used for an HVDC part that is not in the LfNetwork
But the bug existed.
Signed-off-by: Didier Vidal <[email protected]>
Signed-off-by: Didier Vidal <[email protected]>
vidaldid-rte
force-pushed
the
hvdc_isolate_if_fictive_load
branch
from
eae1053
to
203f616
Compare
Signed-off-by: Didier Vidal <[email protected]>
Signed-off-by: Didier Vidal <[email protected]>
|
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?
In #965 a simple criteria was added to detect an HVDC disconnection on one side :
A station is isolated if its merged bus is not connected to any other bus neither to a load or a group.
This criteria was meant to detect quickly contingencies that disconnect a line, while allowing simple models where one side is merely simplified as a group or a load.
But in real networks it happens that a fictive load is added to a station.
This fix considers that if an HVDC's stations contains only fictive loads it is still considered isolated.
NOTE that this criteria for automatic HVDC disconnection in a contingncy is not documented at this time. There is currently no good place to document how contingenices are propagated, when the propagation is not obvious.
What is the current behavior?
If a contingency isolates a bus that is connected to a fictive load and an HVDC station, the HVDC is considered working.
What is the new behavior (if this is a feature change)?
If a contingency isolates a bus that is connected to a fictive load and an HVDC station, the HVDC is is stopped.
Does this PR introduce a breaking change or deprecate an API?
If yes, please check if the following requirements are fulfilled
What changes might users need to make in their application due to this PR? (migration steps)
Other information: