Active Power Control extension: add participationFactor #2402
Conversation
…ferencePriority attributes Signed-off-by: Damien Jeandemange <damien.jeandemange@artelys.com>
Signed-off-by: Damien Jeandemange <damien.jeandemange@artelys.com>
| * 0 = don't care (default) 1 = highest priority. 2 is less than 1 and so on. | ||
| * @return reference priority | ||
| */ | ||
| int getReferencePriority(); |
There was a problem hiding this comment.
We already have an extension SlackTerminal for that (see CGMES import how referencePriority is used to create a SlackTerminal extension)
There was a problem hiding this comment.
SlackTerminal could indeed work for this but not in the general case:
- there can be only one SlackTerminal per VoltageLevel. In the case where there are two generators in on VoltageLevel, gen1 with priority 1, gen2 with priority 2. Say both are connected initially, but then the user disconnects the generator in priority 1, the other generator with priority 2 cannot be picked up.
- SlackTerminal-s across different VoltageLevel-s do not have have any relative priority. So If I have two VoltageLevel-s, VL1 with gen1 of referencePriority1, VL2 with gen2 of referencePriority2, in this case it is not possible to represent that gen1 has higher priority than gen2 for slack slelection.
There was a problem hiding this comment.
The problem with referencePriority on generators is that it does not cover the general case of slack bus selection but only slack bus on PV buses. Only very old power flow, does not allow general slack bus selection and most of the time best slack bus is not on a PV bus (like when you select most meshed bus). Also we tend to have more and more generators modelling on MT in our cases (so in 15Kv behind a step up transformer) and having a slack of this kind of bus is not robust.
Maybe we should just try to improve/enrich existing SlackTerminal extension in order to meet your needs ?
There was a problem hiding this comment.
just thinking... an alternative solution could be to enhance the existing SlackTerminal extension to allow 1/ for multiple SlackTerminal extensions to be present in a given VoltageLevel, and 2/ add priority to the extension. But This would cause issues for backward compatibility of existing tools relying on this extension, and 2/ the very same extension is used for slack selection results, and when it comes to slack selection results, priority don't really make sense any more.
There was a problem hiding this comment.
I de-scoped referencePriority from this PR, have to think about it
There was a problem hiding this comment.
Why not, maybe in order to complete this PR, we can just remove the referencePriority and think about how to improve slack selection part in another issue/PR ?
There was a problem hiding this comment.
I removed referencePriority from this PR and entered issue #2412 to track this topic
| @@ -36,6 +36,10 @@ public enum VoltageInitMode { | |||
| public enum BalanceType { | |||
| PROPORTIONAL_TO_GENERATION_P, | |||
| PROPORTIONAL_TO_GENERATION_P_MAX, | |||
| PROPORTIONAL_TO_GENERATION_REMAINING_MARGIN, | |||
There was a problem hiding this comment.
Remaining margin means proportional to pmax - targetP ?
There was a problem hiding this comment.
yes exactly (provided that pmax - targetP is positive)
could probably better renamed PROPORTIONAL_TO_GENERATION_RESERVE_MARGIN, or just PROPORTIONAL_TO_GENERATION_RESERVE ... any thought ?
There was a problem hiding this comment.
PROPORTIONAL_TO_GENERATION_REMAINING_MARGIN seems ok to me
There was a problem hiding this comment.
Maybe we should you add a comment to describe exactly what does it mean
There was a problem hiding this comment.
I added javadoc to the options
jeandemanged
changed the title
Signed-off-by: Damien Jeandemange <damien.jeandemange@artelys.com>
jeandemanged
force-pushed
the
active_power_control_extension_enhancements
branch
from
10b5a29 to
a2656cc
Compare
Signed-off-by: Damien Jeandemange <damien.jeandemange@artelys.com>
jeandemanged
changed the title
Signed-off-by: Damien Jeandemange <damien.jeandemange@artelys.com>
Signed-off-by: VEDELAGO MIORA <miora.ralambotiana@rte-france.com>
|
Kudos, SonarCloud Quality Gate passed! |
Signed-off-by: Damien Jeandemange <damien.jeandemange@artelys.com> Co-authored-by: VEDELAGO MIORA <miora.ralambotiana@rte-france.com>
add participationFactor attribute in Active Power Control extension
Signed-off-by: Damien Jeandemange damien.jeandemange@artelys.com
Please check if the PR fulfills these requirements
doc/website update for next release to be done
Does this PR already have an issue describing the problem ?
No
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Feature:
What is the current behavior?
No support of participationFactor representation, for use by LoadFlow
What is the new behavior (if this is a feature change)?
Does this PR introduce a breaking change or deprecate an API? If yes, check the following:
Note sure ...
I made the attribute optional in the XML serialization, so I do not think this qualifies as a breaking change. Please let me know if you prefer that I bump a new version of the active power control extension xsd...
Other information:
Please le me know if you prefer a separate extension for this instead of reusing the existing ActivePowerControl extension (which seems a good place imho)
Other PRs will follow to: