Skip to content

Migration guide v6.4.0

Jump to bottom
Anne Tilloy edited this page Jun 5, 2024 · 30 revisions

Breaking Change Breaking changes for all users

Ref interface

Starting from this release the Ref interface and its implementations RefObj and RefChain are now in powsybl-commons artifact, in com.powsybl.commons.ref package.

The Ref interface was an internal utility class of powsybl-iidm-impl but its visibility was nonetheless public. If you were using this interface or one of its implementation, you need to replace the import clauses (e.g. the import com.powsybl.iidm.network.impl.util.RefObj; with com.powsybl.commons.ref.RefObj;), and include powsybl-commons artifact in your pom.xml file.

ReportNode

  • Starting from this release, the ReportNode JSON files from API v2.0 cannot be read anymore. Please switch to JSON files generated with API V2.1.
  • ReportConstants.REPORT_SEVERITY_KEY has been renamed into ReportConstants.SEVERITY_KEY

Security analysis

Security analysis runner parameters

For SecurityAnalysisProvider implementations, replace

run(Network, String workingStateId, LimitViolationDetector, LimitViolationFilter, ComputationManager, SecurityAnalysisParameters, ContingenciesProvider, List<SecurityAnalysisInterceptor>, List<OperatorStrategy>, List<Action>, List<StateMonitor>, List<LimitReduction>, ReportNode)

with

run(Network, String workingStateId, ContingenciesProvider, SecurityAnalysisRunParameters)

For SecurityAnalysis API, the various run and runAsync methods overloads are now limited to:

  • run(Network, String workingStateId, ContingenciesProvider, SecurityAnalysisRunParameters)
  • runAsync(Network, List<Contingency>, SecurityAnalysisRunParameters)
  • runAsync(Network, List<Contingency>)

LimitViolationDetector removed from SecurityAnalysis API

Starting from this release the LimitViolationDetector is removed from security analysis API. The default implementations remains available, and the DefaultSecurityAnalysis default implementation still handles a LimitViolationDetector parameter through its constructor, although it is now becoming nullable. The DefaultSecurityAnalysisProvider now builds a DefaultSecurityAnalysis with a null LimitViolationDetector.

If you want to still use the LimitViolationDetector you need to pass one to your security analysis (or to the DefaultSecurityAnalysis). Hence, you cannot use directly the DefaultSecurityAnalysisProvider anymore. It is thus not possible to call SecurityAnalysis.find() to create the SecurityAnalysis.Runner anymore. Instead, you should declare your own SecurityAnalysisProvider (which may or not extends DefaultSecurityAnalysisProvider) which will create a DefaultSecurityAnalysis using the constructor taking a LimitViolationDetector. As a consequence, the provider won't be retrieved dynamically from the default-impl-name property of the configuration file.

IIDM Validation Util rework

The ValidationUtil utility class was reworked to ensure that the validation is well performed using a validation level. The impacts are the following:

Except the validate(…) method, all the methods having boolean throwException as a parameter are no more accessible. Instead, you should use the method taking the parameters ValidationLevel validation, ReportNode reportNode. The validation level (which generally corresponds to the network's minimal validation level) will determine if, in case of error, it should be reported in reportNode or if an exception should be thrown. Furthermore, methods having only the ValidationLevel validationLevel parameter now take ReportNode reportNode as an additional parameter.

For instance, you could not use the following methods anymore:

  • checkActivePowerSetpoint(Validable validable, double activePowerSetpoint, boolean throwException)
  • checkActivePowerSetpoint(Validable validable, double activePowerSetpoint, ValidationLevel validationLevel)

Instead, you should use:

  • checkActivePowerSetpoint(Validable validable, double activePowerSetpoint, ValidationLevel validationLevel, ReportNode reportNode)

In addition, the following methods were removed or are no more accessible:

  • throwExceptionOrLogError(…)
  • checkConnected(…)
  • checkTemporaryLimits(…)

Code cleanup

In this release, an effort was made to reduce the project's technical debt. This work introduced some breaking changes.

Jackson

To avoid unsafe Jackson deserialization (see https://rules.sonarsource.com/java/RSPEC-4544/ ), classes implementing the interface BusRef now have to add the Jackson annotation @JsonTypeName(".<ClassName>") (with <ClassName> replaced by the class name. Note the presence of the . before the class name.). For instance IdBasedBusRef is annotated with @JsonTypeName(".IdBasedBusRef").

Removal of deprecated methods, and its impact

Following deprecated methods have been deleted:

Removed method Replacement
PlatformConfig.setDefaultConfig Directly pass PlatformConfig instance to the code you want to test.
PlatformConfig.moduleExists Test the result of PlatformConfig.getOptionalModuleConfig instead.
PlatformConfig.getModuleConfig Use PlatformConfig.getOptionalModuleConfig instead.
PlatformConfigNamedProvider.findBackwardsCompatible Use PlatformConfigNamedProvider.find instead.
PlatformConfigNamedProvider.findDefaultBackwardsCompatible Use PlatformConfigNamedProvider.findDefault instead.
StandbyAutomaton.getHighVoltageSetPoint Use StandbyAutomaton.getHighVoltageSetpoint instead.
StandbyAutomaton.setHighVoltageSetPoint Use StandbyAutomaton.setHighVoltageSetpoint instead.
StandbyAutomaton.getLowVoltageSetPoint Use StandbyAutomaton.setLowVoltageSetpoint instead.
StandbyAutomaton.setLowVoltageSetPoint Use StandbyAutomaton.setLowVoltageSetpoint instead.
StandbyAutomatonAdder.withHighVoltageSetPoint Use StandbyAutomatonAdder.withHighVoltageSetpoint instead.
StandbyAutomatonAdder.withLowVoltageSetPoint Use StandbyAutomatonAdder.withLowVoltageSetpoint instead.
UndirectedGraph.getMaxVertex If you override this method, rename it as getVertexCapacity().

⚠️ Because of the PlatformConfigNamedProvider. ...BackwardsCompatible methods' deprecation, "default" keyword will not be supported anymore in configuration files. Thus check that you use "default-impl-name" instead of "default" in your configuration, especially in load-flow and dynamic-simulation sections.

Behavior changes

The list returned by CandidateComputations.getComputationsNames() is now immutable.

Test methods renamed

Following methods were renamed in ComparisonUtils:

  • compareBytes to assertBytesEquals;
  • compareTxt to assertTxtEquals;
  • compareXml to assertXmlEquals.

This allows Sonar to detect these methods as assertions in the unit tests.


Custom IIDM Impl Notice for custom IIDM implementations maintainers

IIDM

Connectable connection/disconnection

Custom IIDM implementation maintainers should define these new methods for Connectable implementations:

  • boolean connect(Predicate<Switch> isTypeSwitchToOperate, ThreeSides side);
  • boolean disconnect(Predicate<Switch> isSwitchOpenable, ThreeSides side)

They should act as their counterparts without the side parameter, but only on the specified side.

Three-winding transformers

In ThreeWindingsTransformer.Leg interface, each implementations must add a getTransformer() method that gives the transformer associated to a leg. In ThreeWindingsTransformerToBeEstimatedAdder, two new methods must be implemented:

  • withRatioTapChangerStatus(ThreeSides side, boolean toBeEstimated) and
  • withPhaseTapChangerStatus(ThreeSides side, boolean toBeEstimated).

TCK

New TCK feature

This is not a breaking change, but we thought that this feature needed a special notice for IIDM implementation's maintainers.

When a new test class is added to the TCK ("The IIDM Technology Compatibility Kit"), its tests are not launched with your custom IIDM implementation unless you create a test class implementing it. But with the previous versions, nothing told you that new tests were added and you may though that your IIDM implementation was fully tested.

Starting from this release, a special TCK class was added to test that all other TCK tests are extended. To enable it, you need to create a new test class implementing AbstractTckSuiteExhaustivityTest in your IIDM implementation's test directory:

class TckSuiteExhaustivityTest extends AbstractTckSuiteExhaustivityTest {}

This test will fail if any other TCK test is not extended in your own IIDM implementation's TCK test suite.

New TCK dependency

Custom IIDM implementation maintainers should add the following dependency in their TCK implementation's pom.xml:

<dependency>
    <groupId>org.assertj</groupId>
    <artifactId>assertj-core</artifactId>
    <scope>test</scope>
</dependency>
Clone this wiki locally