Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check, improve and document subcomponent handling #131

Closed
3 tasks done
Tracked by #97
dinkelbachjan opened this issue Nov 9, 2022 · 4 comments · Fixed by #159
Closed
3 tasks done
Tracked by #97

Check, improve and document subcomponent handling #131

dinkelbachjan opened this issue Nov 9, 2022 · 4 comments · Fixed by #159
Assignees
Labels
documentation Improvements or additions to documentation

Comments

@dinkelbachjan
Copy link
Contributor

dinkelbachjan commented Nov 9, 2022

  • Check that explicit subcomponent tasks are only defined when reasonable in terms of expected computational effort, otherwise let the subcomponent's pre- and poststep routines be handled by the supercomponent
  • Every SimPowerComp has a vector mSubComponents of subcomponents but most classes derived from SimPowerComp have their subcomponents as separate member variables, not utilizing this list.
    • Make use of mSubComponents to harmonize calling pre- and poststep routines, as for example shown here
  • Document the different concepts of how to handle pre- and poststep routines of subcomponents
@dinkelbachjan dinkelbachjan changed the title Every SimPowerComp has a vector mSubComponents of sub-components but most classes derived from SimPowerComp have their sub-components as separate member-variables, not utilizing this list. Check, improve and document subcomponent handling Nov 9, 2022
@JTS22
Copy link
Contributor

JTS22 commented Nov 17, 2022

Classes which include subcomponents (changes in #141):

Class Uses mSubComponents Pre- and Post-step called by parent? Parent calls Pre- and Post-steps via mSubComponents? Remarks
DP_Ph1_AvVoltageSourceInverterDQ yes yes yes -
DP_Ph1_NetworkInjection yes yes yes -
DP_Ph1_PiLine yes yes yes changed to utilize mSubComponents
DP_Ph1_PQLoadCS yes yes yes changed to utilize mSubComponents and to call subtasks in parent task
DP_Ph1_RxLine yes yes yes changed to utilize mSubComponents and to call subtasks in parent task
DP_Ph1_RxLoad yes yes yes changed to utilize mSubComponents
DP_Ph1_RxLoadSwitch yes yes yes changed to iterate over mSubComponents
DP_Ph1_SVC no yes no Class is malformed, should not compile. Not making any changes...
DP_Ph1_SynchronGeneratorIdeal yes yes yes changed to iterate over mSubComponents instead of only using comp. 0
DP_Ph1_SynchronGeneratorTrStab yes yes yes changed to utilize mSubComponents and to call subtasks in parent task
DP_Ph1_Transformer yes yes yes -
DP_Ph1_VoltageSourceRamp yes yes yes changed to utilize mSubComponents and to call subtasks in parent task. Also, why does this class exist at all? Can this not be handled by the normal VoltageSource + SignalGenerator?
EMT_Ph1_VoltageSourceRamp yes yes yes changed to utilize mSubComponents and to call subtasks in parent task. Also, why does this class exist at all? Can this not be handled by the normal VoltageSource + SignalGenerator?
EMT_Ph3_AvVoltageSourceInverterDQ yes yes yes -
EMT_Ph3_NetworkInjection yes yes yes -
EMT_Ph3_PiLine yes yes yes changed to utilize mSubComponents
EMT_Ph3_RxLine yes yes yes changed to utilize mSubComponents and to call subtasks in parent task
EMT_Ph3_RXLoad yes yes yes changed to utilize mSubComponents and to call subtasks in parent task
EMT_Ph3_SynchronGeneratorIdeal yes yes yes changed to loop over all subcomponents
EMT_Ph3_SynchronGeneratorTrStab yes yes yes changed to utilize mSubComponents and to call subtasks in parent task
EMT_Ph3_Transformer yes yes yes -
SP_Ph1_AvVoltageSourceInverterDQ yes yes yes -
SP_Ph1_Load yes yes yes changed to utilize mSubComponents and to call subtasks in parent task
SP_Ph1_NetworkInjection yes yes yes -
SP_Ph1_PiLine yes yes yes changed to utilize mSubComponents
SP_Ph1_RXLine yes yes yes changed to utilize mSubComponents and to call subtasks in parent task
SP_Ph1_SolidStateTransformer yes has no tasks has no tasks changed to add subcomponents into list
SP_Ph1_SynchronGeneratorTrStab yes yes yes changed to utilize mSubComponents and to call subtasks in parent task
SP_Ph1_Transformer yes yes yes -

@JTS22
Copy link
Contributor

JTS22 commented Nov 25, 2022

In addition to the changes made in #141, I propose another way to further unify the behavior of components with subcomponents: By creating a shared superclass MNASimPowerComp that is derived from both SimPowerComp and MNAInterface, it becomes possible to extract the various MNA method calls on the subcomponents into this common superclass. This means that the parent components only register their subcomponents once (e. g. through addMNASubComponent) and then only contain methods concerned with the MNA operations in the parent. The calls to the MNA methods of the child are handled by the superclass instead, drastically cutting down on the amount of duplicated code (especially the for (auto comp : mSubComponents) loop) in the parent classes. The MNAPreStep and MNAPostStep classes contained in almost all parent components can also be merged into the common superclass. A first working example of this can be found in #144 (Comparison with #141 in subcomponents...unify-mna-subcomponents).

@dinkelbachjan
Copy link
Contributor Author

I would suggest that the new superclass is used only for components that are composed of subcomponents, e.g. PiLine, while the simple components, e.g. Inductor remain untouched. The new superclass could be explicitly called CompositePowerComp. It handles the adding of subcomponents and the collection/arrangement of their mnaPreStep and mnaPostStep methods as you described. Any additional functionalities brought by the composite component class can be encapsulated in mnaParentPreStep and mnaParentPostStep, which are methods offered by CompositePowerComp.

@dinkelbachjan
Copy link
Contributor Author

@m-mirz We are thinking of inserting a new class CompositePowerComp as described above to unify the subcomponent handling. What do you think about that?

@m-mirz m-mirz added the documentation Improvements or additions to documentation label Dec 11, 2022
m-mirz added a commit that referenced this issue Jan 8, 2023
…141)

For all components that declare some kind of subcomponents, this PR
unifies the handling of these subcomponents such that:
- Subcomponents are always added to `mSubComponents`
- Subcomponent MNA methods (`mnaPreStep`, `mnaPostStep`...) are called
directly in the same-named parent method and not through custom tasks
- The parent calls the subcomponent's methods by iterating through
`mSubComponents`

Based on #140 
Related to #131
m-mirz added a commit that referenced this issue Jan 22, 2023
Introduces two new base classes, MNASimPowerComp<T> and
CompositePowerComp<T>. For all composite components (as defined in
#131), MNASimPowerComp
provides default implementations for all methods in MNAInterface, as
well as default MnaPreStep and MnaPostStep tasks, such that MNAInterface
is only inherited once in the parent class and not in each component
individually. Additionally, CompositePowerComp provides mnaParent...
methods for most of the MNA methods in MNAInterface. Via the
addMNASubComponent method, a component can register subcomponents for
which the relevant MNA methods are called automatically by the
CompositePowerComp parent class. For each MNA method, the child
component class can decide to either override the normal mna... method
and provide subcomponent handling themselves, or override just the
mnaParent... method and let the subcomponents (and some other common
operations) get handled by the parent class methods.

While the MNASimPowerComp class is not used for any non-composite
components in this PR, the unification of MNA methods for these
components is covered in
#150 .

Based on #142
Related to #131
Rebase of #144
@m-mirz m-mirz closed this as completed in da1dfad Feb 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants