Skip to content

Migration guide v6.1.0

Jump to bottom
Nicolas Rol edited this page Nov 20, 2023 · 26 revisions

Breaking changes

IIDM

Disconnectors on parallel bars

Connecting coupling devices

When creating a coupling device, each side of the coupling device is now connected to more bars than previously. The logic depends on whether the sections on which the user asks the coupling device to be connected has a position defined or not:

  • If a section has no position defined, the corresponding side of the coupling device will only be connected to this section. image
  • If a section has a position defined but the opposite side has no position defined, the corresponding side of the coupling device will be connected to all the bars parallel to the section.
  • If both sections have positions defined but have different section index, each one will be connected to every bar parallel to the respective section. image
  • If both sections have positions defined and the same section index, each side will be connected to every bar except one. If the first side corresponds to the first busbar index or the second side corresponds to the last busbar index, the first side will be connected to every bar except the last one while the second side will be connected to every bar except the first one. If not, it will be the opposite. image

Make sure that you anticipate the new connections and don't recreate them manually. Nota: only the disconnectors corresponding to the connections asked are closed, the others are open.

Naming of disconnectors

The were some inconsistencies in the naming of some disconnectors created during network modifications. Now, every disconnector created this way has a name based on the following format: <prefix>_DISCONNECTOR_<node1_number>_<node2_number>.

For example, when creating a coupling device, the names can change from:

<iidm:switch id="vl1_BREAKER" kind="BREAKER" retained="true" open="false" node1="36" node2="37"/>
<iidm:switch id="vl1_DISCONNECTOR_0" kind="DISCONNECTOR" retained="false" open="false" node1="0" node2="36"/>
<iidm:switch id="vl1_DISCONNECTOR_1" kind="DISCONNECTOR" retained="false" open="false" node1="1" node2="37"/>
<iidm:switch id="vl1_DISCONNECTOR_36_2" kind="DISCONNECTOR" retained="false" open="true" node1="36" node2="2"/>
<iidm:switch id="vl1_DISCONNECTOR_37_3" kind="DISCONNECTOR" retained="false" open="true" node1="37" node2="3"/>

to:

<iidm:switch id="vl1_BREAKER" kind="BREAKER" retained="true" open="false" node1="36" node2="37"/>
<iidm:switch id="vl1_DISCONNECTOR_36_0" kind="DISCONNECTOR" retained="false" open="false" node1="36" node2="0"/>
<iidm:switch id="vl1_DISCONNECTOR_36_2" kind="DISCONNECTOR" retained="false" open="true" node1="36" node2="2"/>
<iidm:switch id="vl1_DISCONNECTOR_37_1" kind="DISCONNECTOR" retained="false" open="false" node1="37" node2="1"/>
<iidm:switch id="vl1_DISCONNECTOR_37_3" kind="DISCONNECTOR" retained="false" open="true" node1="37" node2="3"/>

Note that the order of the disconnectors creation also changed.

Custom connection/disconnection of terminals

Two methods Terminal.connect(Predicate<Switch> isTypeSwitchToOperate) and disconnect(Predicate<Switch> isSwitchOpenable) were added. They allow the user to specify predicates indicating what kind of switch can be operated during the opening or which switch can be opened during a disconnection. Defaults predicates are made available in the SwitchPredicates class.

Connect

The connect method will now find all paths going from the terminal to a busbar section that do not contain an open switch that is not of the type of switch the user wants to operate (ie. not corresponding to the isTypeSwitchToOperate parameter). The paths will be sorted by the number of open switches and by the size of the paths. Previously, only the size of the path was considered. If there is at least one path, the shortest path will be selected and all open switches on the path will be closed.

If no predicate is used in the connect() method, only the closed non-fictional breakers will be considered.

TODO

Get side on three windings transformer leg

TODO

Limit violations for three windings transformers

TODO

TwoSides and ThreeSides

Starting from this release,

  • Branch.Side replaced by com.powsybl.iidm.network.TwoSides
  • Hvdc.Side replaced by com.powsybl.iidm.network.TwoSides
  • ThreeWindingsTransformer.Side replaced by com.powsybl.iidm.network.ThreeSides
  • Measurement.Side replaced by com.powsybl.iidm.network.ThreeSides

JSON support added and XML serialization refactoring

TODO

LoadFlowResult

A LoadFlowResult introduced a dedicated object to store a slack bus result. In a SlackBusResult, you have access to the id of the slack bus used during the calculation and the associated active power mismatch in MW (getActivePowerMismatch()). As several slack buses car be used in a single component calculation, a LoadFlowResult outputs a list of SlackBusResult.

New status NO_CALCULATION has been added, meaning that the component was not calculated, e.g. de-energized component without any voltage support. SOLVER_FAILED status has been removed, please use FAILED status for non convergence. For more details about status, a dedicated String field has been added: use getStatusText for a more detailed description.

And finally, load flow results give access now to the angle reference bus id through the method getReferenceBusId().

Methods getSlackBusId(), getSlackBusActivePowerMismatch() and isOk() are deprecated.

Compatibility

TODO or delete

Quality

Runtime dependencies

TODO or delete

Deprecated methods clean-up

TODO or delete

The following deprecated methods have been deleted:

  • TODO()

The following deprecated enum types have been deleted:

  • TODO
Clone this wiki locally