Add flag to enable/disable static var compensator regulation #3324
Conversation
quinarygio
force-pushed
the
svc_enable_regulation_flag
branch
from
bb8328b to
0198915
Compare
Signed-off-by: Giovanni Ferrari <[email protected]>
quinarygio
force-pushed
the
svc_enable_regulation_flag
branch
from
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]>
quinarygio
force-pushed
the
svc_enable_regulation_flag
branch
from
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.
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.
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.
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.
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.
| 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.
| 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.
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.