Add Subsystem and Partition Interfaces for PowerElectronics

[abdourahmanbarry]

Description

In this PR, we implement SubsystemModel for partitioned Power Electronics simulation. The implementation provides the infrastructure required to partition Power Electronics networks, and to evaluate subsystem residuals and Jacobians independently.

This is the third of four stacked pull requests that split PR #492 into simpler, more manageable chunks.

Proposed changes

We added a SubsystemModel class to represent an individual partition and a BusPartitionInterface component to mark partition boundaries. Together, these enable us to partition larger networks for co-simulation and parallel function evaluation.

Checklist

• All tests pass.
• Code compiles cleanly with flags -Wall -Wpedantic -Wconversion -Wextra.
• The new code follows GridKit™ style guidelines.
• There are unit tests for the new code.
• The new code is documented.
• The feature branch is rebased with respect to the target branch.
• The CHANGELOG.md has been updated to reflect the changes. If this is a minor PR that is part of a larger fix already included in the file, state so.

[superwhiskers]

just an architectural question

[superwhiskers]

so, my main question here is why do we need this notion of distinct "systems" and "subsystems" present in the codebase?

when first learning about system partitioning stuff in gridkit, it seemed more natural to me to instead allow the system itself to be a component that can be used in another system. the "non-owning" nature of SubsystemModel as implemented here seems like it could be more naturally captured by a SystemModelRef or some similar type that encapsulates the notion of "referencing" a system model or something like that (perhaps to match the bus partition interface thing for components---SystemModelInterface).

what was the motivation behind this design choice? it seems more natural to build up from smaller components than to break apart.

[abdourahmanbarry]

Good question. There are several reasons for doing it this way.

First, when we partition a system, each subsystem is smaller than the original system, so we can no longer directly use the global indices of the components when evaluating the subsystem. We therefore need to map the global system indices to the corresponding local subsystem indices. This mapping is not needed when evaluating the monolithic system, but it is something we must do before we can evaluate partitions independently.

Second, there is an important difference in how the two models are used. PowerElectronicsModel is designed to construct and own a network. We add components and nodes to it to build up the system. SubsystemModel expects to receive part of an already existing network. It is not trying to construct another network or own those components. If we combine everything into a single class, the same class would need logic for both constructing a network(not need when you are absorbing a part of an already existing network) and representing a partition of an existing network, in addition to handling local/global index mappings and internal/external variables management. I think keeping those responsibilities separate makes the design easier to understand. In addition, the SubsystemModel is still a System model because it inherits and reuses a lot of code from the System Model.

I agree with you that, ideally, we would want a System Model that can be treated as a component, and can be nested hierarchically to arbitrary depth. This was actually one of our design considerations. However, we agreed that supporting that design properly would require a substantial amount time, but we do not have much time left under the scope of the AGM project.

[superwhiskers]

i think that we should open an issue regarding "componentized" system models to replace the partitioning implementation approach implemented in this pull request if doing so right now is too difficult

[abdourahmanbarry]

We are already heading down that direction with this implementation. It might need couple of cycles to get there. This is a good starting point I think. I have attached a snapshot of a design document I shared with Slaven couple of months ago. It needs to be update, but this section talks about doing exactly what you are thinking.