Migration guide v6.1.0
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.
- 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.
- 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.
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.
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_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_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
TODO
### Get side on three windings transformer leg
TODO
### Limit violations for three windings transformers
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`