Cgmes active reactive regulating control

[nemanja-st]

Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

Does this PR already have an issue describing the problem?
Fixes #2920 '

Does this PR introduce a breaking change or deprecate an API?

• Yes
• No

Other information:
ACTIVE_POWER and CURRENT_LIMITER are already implemented for PSTs.

[nemanja-st]

Issues observed for this PR:

1. StaticVarCompensator:
   • When StaticVarCompensatorRegulationMode is OFF and regulatingTerminal is remote, RegulatingControl is always exported with enabled set to false.
   • When StaticVarCompensatorRegulationMode is OFF and regulatingTerminal is local, RegulatingControl is never exported.
2. ShuntCompensator:
   • When voltageRegulatorOn is false and regulatingTerminal is remote, RegulatingControl is always exported with enabled set to false.
   • When voltageRegulatorOn is false and regulatingTerminal is local, RegulatingControl is never exported.
3. Implementation in commit d75dacb will need to be propagated to TC export in SV, if user exports only SV cimxml file.

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
98.8% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[annetill]

#2790 will not be available soon because it leads to an increase of iidm version. Maybe in June, but no sure at all. Do you have a unit test with a OFF mode but valid values for both voltage and reactive power control values? What is exported then?

[marqueslanauja]

Maybe create also the control when the regulating control is remote. If cgmes EQ file is imported (no SSH file), then only the regulating terminal is defined, given that the setpoint is in the SSH file. Better do not lose the regulating control in this case if the iidm model is exported. In iidm regulating terminal null is the same as local control, then only if the regulating control is remote we have to export it.

if (regulatingControlId == null
                   && (SteadyStateHypothesisExport.isValidVoltageSetpoint(shuntCompensator.getTargetV())
                   || !Objects.equals(shuntCompensator, shuntCompensator.getRegulatingTerminal().getConnectable()))) {

[nemanja-st]

This is RC creation from scratch (regulatingControlId == null) so it comes down to deciding if Shunt has voltage regulating capability from IIDM.
If targetV is not set, in case of full CGMES export from IIDM, SSH will have incorrect values for the control.

[marqueslanauja]

If the targetV is not set, the validation level is EQUIPMENT and does not make sense to export the SSH file.
I prefer to export properly the EQ file, including the control, in concordance with the validation level.

[marqueslanauja]

In concordance with the previous comment, we can export it if:

if (regulatingControlId == null && (validVoltageSetpoint
                            || validReactiveSetpoint
                            || !Objects.equals(svc, svc.getRegulatingTerminal().getConnectable()))) {

[nemanja-st]

Again, this is related to RC creation from scratch (no CGMES import).
In CGMES, SVC must have a RC in order to function (SVC parameters regarding control should be ignored). This is valid for local and remote controls.
In this implementation, we avoid exporting RC only when regulationMode is not set and we have both voltage and reactive targets (it's not clear which to use).

[marqueslanauja]

I am in favor of exporting the maximum information if the information is valid. In this case, I prefer to export the voltage control as disabled than do not export anything, but of course both options are valid.

[annetill]

We have a use case where we export only an EQ file, without SSH file.

[marqueslanauja]

My proposal:

RemoteReactivePowerControl rrpc = generator.getExtension(RemoteReactivePowerControl.class);
String mode = getGeneratorRegulatingControlMode(generator, rrpc);
Terminal regulatingTerminal = mode.equals(RegulatingControlEq.REGULATING_CONTROL_VOLTAGE) ? generator.getRegulatingTerminal() : rrpc.getRegulatingTerminal();

private static String getGeneratorRegulatingControlMode(Generator generator, RemoteReactivePowerControl rrpc) {
        if (rrpc == null) {
            return RegulatingControlEq.REGULATING_CONTROL_VOLTAGE;
        }
        boolean enabledVoltageControl = generator.isVoltageRegulatorOn();
        boolean enabledReactivePowerControl = rrpc.isEnabled();
        
        if (enabledVoltageControl) {
            return RegulatingControlEq.REGULATING_CONTROL_VOLTAGE;
        } else if (enabledReactivePowerControl) {
            return RegulatingControlEq.REGULATING_CONTROL_REACTIVE_POWER;
        } else {
            boolean validVoltageSetpoint = SteadyStateHypothesisExport.isValidVoltageSetpoint(generator.getTargetV());
            if (validVoltageSetpoint) {
                return RegulatingControlEq.REGULATING_CONTROL_VOLTAGE;
            } else {
                return RegulatingControlEq.REGULATING_CONTROL_REACTIVE_POWER;
            }
        }
    }

We can define the getGeneratorRegulatingControlMode method in the CgmesExportUtil class and use it during the SSH export to be coherent with the EQ export.

[nemanja-st]

The difficulty here is in priorities: Is the RRPC extension priority or voltage control?

Example: rrpc exists, voltage control is enabled -> We export voltage control, regardless of rrpc status.

Since rrpc has to be created explicitly as an extension, assumption is that it has the priority.
Therefore, if rrpc is there, we ignore voltage control completely and only use rrpc parameters.

[annetill]

If the reactive power control extension is present and enabled, it does not override the voltage control if enabled. Maybe it is a mistake but it is what is developed inside open loadflow.

[marqueslanauja]

I prefer to select the control priority using the electrical information rather than the software information. The final user, in most of the cases, will not know how the model is internally implemented. Then, if both controls have the same valid attributes I prefer to export the voltage control. But as before, both options are valid.

[marqueslanauja]

My proposal:

private static String getSvcMode(StaticVarCompensator svc) {
        if (svc.getRegulationMode().equals(StaticVarCompensator.RegulationMode.VOLTAGE)) {
            return RegulatingControlEq.REGULATING_CONTROL_VOLTAGE;
        } else if (svc.getRegulationMode().equals(StaticVarCompensator.RegulationMode.REACTIVE_POWER)) {
            return RegulatingControlEq.REGULATING_CONTROL_REACTIVE_POWER;
        } else {
            if (SteadyStateHypothesisExport.isValidReactivePowerSetpoint(svc.getReactivePowerSetpoint())) {
                return RegulatingControlEq.REGULATING_CONTROL_VOLTAGE;
            } else {
                return RegulatingControlEq.REGULATING_CONTROL_REACTIVE_POWER
            }
        }
    }

We can also define the getSvcMode method in the CgmesExportUtil class and use it during the SSH export to be coherent with the EQ export.

[nemanja-st]

Same comment as above, when SVC control mode is not defined, and we have valid voltage and reactive targets, the control shouldn't be exported.
But I agree it should be a common method in CgmesExportUtil.

[marqueslanauja]

I am in favor of exporting the maximum information and in this case I prefer to export the voltage control as disabled but both options are valid.

[marqueslanauja]

We can use a method to obtain the tccMode and define it in the CgmesExportUtil class and use it during the SSH export to be always coherent with the EQ export.

[marqueslanauja]

I suppose that you added to be able to export the SSH file without exporting the EQ file.
You also have to add this method some lines below for the threeWindingsTransformers.

[nemanja-st]

Thanks, I'll update that!

[marqueslanauja]

Use the getGeneratorRegulatingControlMode method to obtain the mode, then depending on the mode set the attributes

[marqueslanauja]

Maybe move this method to the CgmesExportUtil class given that is used in several classes

[marqueslanauja]

Maybe move also to the CgmesExportUtil class

[marqueslanauja]

Maybe use the getSvcMode to obtain the mode, then depending on the mode set the attributes

[marqueslanauja]

Maybe use the method used in the EQ export to obtain the mode and then depending on the mode set the unitMultiplier

[nemanja-st]

Hello @marqueslanauja @annetill
I implemented the suggestions, refactored the code and fixed some tests 1035fca and 3b825b0.

The behavior on control export currently:

• Generator:
  • Imported control is always exported.
  • No control when no reactive capability (Qmin=Qmax)
  • Reactive control when reactive is enabled and voltage disabled
  • Voltage in all other cases
• Shunt:
  • No control when control is not remote and no voltage setpoint
  • Voltage exported in all other cases
• SVC:
  • No control when control is local, OFF and there are no valid Q or V targets
  • Reactive control when control is REACTIVE or control is OFF and reactive power target is valid and voltage target is invalid
  • Voltage control in all other cases
• RTC:
  • Control is not exported when it's not defined (RatioRegulationMode not defined), regardless if it has remote terminal or not.
  • Otherwise, control exported based on RatioRegulationMode

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
97.4% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[annetill]

Hi @nemanja-st, documentation is missing

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
97.4% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud