Open petersalemink95 opened 4 days ago
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.
maybe GenericLine
and GenericTransformerYNyn
, ...?
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.
@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.
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:
GenericBranch:
idAsymCalc: int
calculateAsymmetricParameters( o = getgetInstance(idAsymCalc), retrun o.getParam())
Helper Class (TransformerYD, etc.):
idAsymCalc: int
inputParameter1
inputParameter2
register()
Singleton:
instances: Map<int, HelperClass>
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.
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.
For the discussions about
generic_branch
see #729.The asymmetric implementation is more difficult and needs more thinking. Some options could be:
GenericBranchLine
,GenericBranchTransYNyn
, etc. With many generic implementations, it is not so generic anymore.