[FEATURE] asymmetric implementation of generic_branch

[petersalemink95]

For the discussions about generic_branch see #729.

The asymmetric implementation is more difficult and needs more thinking. Some options could be:

• Provide r1, x1, b1, g1, r2, x2, b2, g2 for positive and negative sequence and y_ff, y_ft, y_tf, y_tt for zero sequence
• Provide r_series / x_series and g/b_shunt_from/to
• Provide r1, x1, b1, g1, r2, x2, b2, g2, r0, x0, b0, g0, so provide the PI model for all sequences: this way only YnYn transformers can be calculated in asym calculation
• Derive other components from GenericBranch for the asymmetric calculation, like GenericBranchLine, GenericBranchTransYNyn, etc. With many generic implementations, it is not so generic anymore.

[sudo-ac]

Hi @petersalemink95,

Our suggestion would be to derive each of the different asymmetric types from the GenericBranch class and map them as a new ComponentType. E.g. a GenericBranchLine, GenericBranchTransYNyn, etc. Each of the derived classes would have its own implementation for calculating the asymmetric variables and its own input. Would that be a suitable solution? We would then implement GenericBranchLine and GenericBranchTransYNyn in our fork, if that is ok. You are welcome to make suggestions for naming the new components.

[mgovers]

maybe GenericLine and GenericTransformerYNyn, ...?

[TonyXiang8787]

Hi @sudo-ac, thanks for the suggestion.

If we define so many GenericBranch*, I wonder what generic we do have here. We really need to think hard about how to implement asymmetric generic branch. @petersalemink95, please also add this option in the list of choices to make.

For now, is it sufficient for you @sudo-ac to first implement the symmetric GenericBranch for your own use-cases? If yes, we are looking forward to seeing a PR about that.

[petersalemink95]

@TonyXiang8787 added it as an option to this issue.

@sudo-ac Thanks for the suggestion! As @TonyXiang8787 mentioned we might need to think a bit longer about the best solution. Would just implementing symmetric calculations for now suit your need? Your proposal would still be valid if we decide to implement that in a later stage if we implement only the symmetric calculations now.

[sudo-ac]

Thank you for the responses. We will first proceed with creating the merge request (though I’m currently on vacation :-)). Another idea would be to provide helper classes for calculating asymmetric parameters. The user would need to instantiate the appropriate helper class (e.g., TransformerYD) before creating a GenericBranch instance. Each helper class would have its own input parameters.

The helper class object would register itself with a unique ID in a singleton class. The GenericBranch class would receive the helper class ID through the input parameters. In the method for calculating asymmetric parameters, GenericBranch would use the ID to obtain a reference to the helper class object and then return the result.

---

Class Diagram Description:

1. GenericBranch:

   • Attributes:
     • .....
     • idAsymCalc: int
   • Methods:
     • calculateAsymmetricParameters( o = getgetInstance(idAsymCalc), retrun o.getParam())

2. Helper Class (TransformerYD, etc.):

   • Attributes:
   • idAsymCalc: int
   • inputParameter1
   • inputParameter2
   • Methods:
     • register()

3. Singleton:

   • Attributes:
     • instances: Map<int, HelperClass>
   • Methods:
     • register(id: int, instance: HelperClass)
     • getInstance(id: int): HelperClass

This is, of course, just a suggestion, and the final decision remains with the PGM team.

[petersalemink95]

Thanks for all the input @sudo-ac!
We're looking forward to reviewing the symmetric PR! (But enjoy your holiday first ;) )

We will include your latest suggestions in further discussions about the asymmetric generic branch.