-
Notifications
You must be signed in to change notification settings - Fork 44
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
Add flag to enable/disable static var compensator regulation #3324
base: main
Are you sure you want to change the base?
Conversation
bb8328b
to
0198915
Compare
Signed-off-by: Giovanni Ferrari <[email protected]>
0198915
to
aeade02
Compare
Signed-off-by: Giovanni Ferrari <[email protected]>
Signed-off-by: Giovanni Ferrari <[email protected]>
Signed-off-by: Giovanni Ferrari <[email protected]>
aeade02
to
415d758
Compare
|
This PR will impact powsybl-open-loadflow whiche still handles |
} | ||
|
||
private static ValidationLevel checkSvcRegulator(Validable validable, double voltageSetpoint, double reactivePowerSetpoint, | ||
private static ValidationLevel checkSvcRegulator(Validable validable, boolean regulating, double voltageSetpoint, double reactivePowerSetpoint, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the checkPhaseTapChangerRegulation
function, there is a check on (regulationMode == null
). I think we need the same kind of check here too if we give regulationMode
a null value in RegulatingControlMappingForStaticVarCompensator
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to be more homogene between the checkPhaseTapChangerRegulation
, checkRatioTapChangerRegulation
and checkSvcRegulator
as the all have the regulating boolean + some RegulationMode and we don't want the RegulationMode to be null, especially when regulating=true
.
Extra note: for the PhaseTapChanger
the RegulationMode FIXED_TAP
will soon be removed (#3344 )
We want RegulationMode to never be null (so like it is done in checkPhaseTapChangerRegulation
).
For retrocompatibility, on older IIDM versions when the RegulationMode is not set or does not correspond to an authorized one (for ratio tap changer, phase tap changer or svc) then we can update its value with a one by default + a warning message. The value by default can be:
- for SVC:
VOLTAGE
- for ratio tap changer:
VOLTAGE
- for phase tap changer:
CURRENT_LIMITER
} | ||
|
||
svc.setVoltageSetpoint(targetVoltage); | ||
svc.setReactivePowerSetpoint(targetReactivePower); | ||
if (rc.controlEnabled) { | ||
svc.setRegulationMode(regulationMode); | ||
} | ||
if (regulationMode == null) { | ||
svc.setRegulating(false); | ||
} | ||
} | ||
|
||
// SVCControlMode and voltageSetPoint are optional in Cgmes 3.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this comment imply that they are mandatory in CGMES 2.4.15? I will check out of curiosity.
} | ||
|
||
private static ValidationLevel checkSvcRegulator(Validable validable, double voltageSetpoint, double reactivePowerSetpoint, | ||
private static ValidationLevel checkSvcRegulator(Validable validable, boolean regulating, double voltageSetpoint, double reactivePowerSetpoint, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to be more homogene between the checkPhaseTapChangerRegulation
, checkRatioTapChangerRegulation
and checkSvcRegulator
as the all have the regulating boolean + some RegulationMode and we don't want the RegulationMode to be null, especially when regulating=true
.
Extra note: for the PhaseTapChanger
the RegulationMode FIXED_TAP
will soon be removed (#3344 )
We want RegulationMode to never be null (so like it is done in checkPhaseTapChangerRegulation
).
For retrocompatibility, on older IIDM versions when the RegulationMode is not set or does not correspond to an authorized one (for ratio tap changer, phase tap changer or svc) then we can update its value with a one by default + a warning message. The value by default can be:
- for SVC:
VOLTAGE
- for ratio tap changer:
VOLTAGE
- for phase tap changer:
CURRENT_LIMITER
@@ -34,7 +34,7 @@ public class RegulatingControlMappingForStaticVarCompensators { | |||
} | |||
|
|||
public static void initialize(StaticVarCompensatorAdder adder) { | |||
adder.setRegulationMode(StaticVarCompensator.RegulationMode.OFF); | |||
adder.setRegulating(false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
adder.setRegulating(false); | |
adder.setRegulating(false); | |
adder.setRegulationMode(StaticVarCompensator.RegulationMode.VOLTAGE); |
shouldn't we set the RegulationMode as VOLTAGE
to avoid having a null RegulationMode in those kind of cases?@geofjamg
@@ -121,7 +121,7 @@ private boolean setRegulatingControl(CgmesRegulatingControlForStaticVarCompensat | |||
okSet = true; | |||
} else { | |||
context.fixed("SVCControlMode", () -> String.format("Invalid control mode for static var compensator %s. Regulating control is disabled", svc.getId())); | |||
regulationMode = StaticVarCompensator.RegulationMode.OFF; | |||
regulationMode = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
regulationMode = null; | |
regulationMode = svc.getRegulationMode(); | |
svc.setRegulating(false); |
To be discussed but here we need to avoid having a null RegulationMode + disable the regulation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we previously need to check that the svc.getRegulationMode()
is not null and if so set it as VOLTAGE
to avoid null?
Please check if the PR fulfills these requirements
Does this PR already have an issue describing the problem?
#2790
What kind of change does this PR introduce?
Does this PR introduce a new Powsybl Action implying to be implemented in simulators or pypowsybl?
What is the current behavior?
What is the new behavior (if this is a feature change)?
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:
An issue has to be created in powsybl-open-loadflow and delivered in the same release as this PR.