fix: bugfix three winding transformers in graphs

[vincentkoppen]

Depends on #267 to be merged first
Fixes #167

There were multiple ways to solve this problem:

• Keep 2 representations of the graph internally and use the "correct" one for each algorithm
  Disadvantage on memory
• Represent a three-winding transformer as a star and adjust algorithms where necessary.
  Disadvantage: a lot of current algorithms/queries become harder, since you always need to hop / remove the node.
• Keep representation as is (a cycle), but fix the algorithms that are hit by the problem (currently only 2 that share a lot of similarity)

Neither option is perfect, but for now keeping it mostly as is and fixing the two algorithms that were incorrect seems like the easiest/cleanest option.
For these algorithms we:

• Remove one edge of the cycle (if all three active)
• Perform normal algorithm
• If any of the returned paths contains all three nodes of the three winding transformer after each other, we know that in reality we would have taken the removed edge instead of "walking through the three winding trafo". So we replace those
• Return to user
  This way we do not return additional paths that are not there, nor do we see cycles that are not there (since we removed the cycles introduced by the three winding trafo's).

Later if we add even more algorithm we can always revisit again en see whether one of the other option becomes a better solution.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[jaapschoutenalliander]

Happy with the suggested solution for now. Some input on the implementation but mainly looks good

[jaapschoutenalliander]

I suggest putting the boiler plate to remove the three winding transformers and re-add them in a re-usable wrapper. If there are more algorithms that need it they can easily do that:

something like

    def _run_with_three_winding_correction(
        self,
        algorithm: Callable[[], list[list[int]]],
    ) -> list[list[int]]:
        branches_to_remove = self._branches_to_remove_from_three_winding_transformers()
        with self.tmp_remove_branches(branches_to_remove):
            result = algorithm()
        if branches_to_remove:
            return self._squash_paths_inside_three_winding_transformers(result)
        return result

[Thijss]

Seems like a good idea. I guess for readability we could even make a contextmanager.

with self._three_winding_correction():
    ...

[vincentkoppen]

I will experiment with this, for the current functionality this works. But only since the two algorithms that we need to "fix" happen to have the same output (list[list[int]]). If we have a third algorithm later on that needs fixing with a different output type, we might have to revisit.
--> Think I can also solve this by also applying a "post-processs" function that we can now set as default to the current one

[vincentkoppen]

I don't think a context manager can work, unless we do not include the _squash_paths_inside_three_winding_transformers part in it.
We do not get access to the result of the function that is called within the context manager, which is needed for that function.

[vincentkoppen]

@Thijss and @jaapschoutenalliander I have simplified the setup I think, let me know what you think! :)

[jaapschoutenalliander]

Nice, happy with this approach

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud