sogno-platform/dpsim

Reuse conductance stamp code

georgii-tishenin opened this issue · 4 comments

georgii-tishenin commented

What is the issue?
Logic for stamping of conductance is the same (or very similar) for all EMT components that are represented by Norton Equivalent or conductance, however each component re-implements this logic. Because of that, mnaCompApplySystemMatrixStamp():

  • increases a chance of copy-paste errors and complexity in implementing new components,

  • requires to read more code, once you're reviewing/trying to understand the component.

What is the possible solution?

  • Create static ("utility") functions that implement the stamping logic and put them to MathUtils.

  • Reuse the utility functions in component classes to stamp conductance into system matrix.

To provide a better idea of what I mean by that, I implemented this in a branch: reuse-conductance-stamp-code.

Describe alternatives you've considered
An alternative solution could be to put the implementation of stamping in a base class. However, not all of the components are represented by Norton Equivalent or conductance.

I believe stamping conductance into matrix fits well into MathUtils. That's why I suggest it as a first option.

Additional context

  • In reuse-conductance-stamp-code I am reusing the stamping code just for R, L, C components, however this can be extended to all components represented by Norton Equivalent or conductance, for example EMT_Ph3_GeneratorVBR.

  • Similar utility functions can be added to reuse the code for stamping admittance in DP and SP domains.

  • The logic can be extended to components that have more than 2 terminals (e.g., three-winding transformer).

  • I did not check that, but I believe we can also reuse code for stamping impedance of components represented by Thevenin Equivalent.

m-mirz commented

I think it is a good idea to remove this redundant code. Just two remarks:
Your new implementation seems to test the terminal grounded condition more often for the three phase case. I would try to avoid this since this function is called very often… better write a little bit more code.
I am wondering if we don’t have another place to put this code since it is already a little bit more specific than just „math“. Are there similar redundant pieces of code that we could pull out? You already suggested thevenin like stamps. Maybe even a new file is appropriate here with a more specific name.

martinmoraga commented

great idea!

I totally agree also with the comment of Markus. I think we dont have a specific place to put this code, we have to create a new file for that

georgii-tishenin commented

Thank you both for your replies. I agree with both remarks.
Would MNAUtils work as a name for this new utility class? Alternative could be more narrow MNAStampUtils name.

Apart from conductance/admittance stamping, there is more repeating code in the classes derived from MNASimPowerComp. Many of the MNASimPowerComp virtual functions are overridden with repeating code. For some of these virtual functions it may be even possible to provide a default implementation in MNASimPowerComp, that would already cover most of the cases. So, I would not rush to outsource them to utility class.
The reason I have started with mnaCompApplySystemMatrixStamp() is because it is the longest function in many three-phase components.