ORNL / ORNL/GridKit

Support For Partitioning.

Open
#142 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

development enhancement
Dominant language
C++
Stars
27
Forks
11
Avg merge
3d 8h
Merged PRs (30d)
23

Description

The first step for any partitioning is the ability to evaluate groups of the system independently under different inputs.

Some current issues with GridKit make implementing partitioned integration methods problematic. This issue provides a list of some current issues.

  • Independent evaluations of subsystems. In PhasorDynamics when evaluating the component residuals. They directly effect the residuals of the Buses they are connected to. More formally if every component is an f then partitioning method want to only evaluate that. The current implementation of evaluateResidual evaluates f and 'something additional'. This 'something addition' is effecting the global residual F. A simple example is GENROUwS. The operation of += effects the bus residuals via the references. With partitioning there is a need to evaluate the generator without effecting the bus. My suggestion is to keep bus/component interactions only at the composer level and not between each other. This can be done by removing references to the bus and instead creating an output function h which returns these values (matching the mathematical formalism). This is not an issue with PowerElectronics.
  • Hierarchical setup. If the composer itself is passed as a component to another composer. This allows for group evaluations of various residuals which is necessary for partitioning and sub-integrators. For PowerElectronics this is relatively straight forward. The external variables need to be add to the composer then it should work. For PhasorDynamics it is not clear to me the best way to proceed on this.
  • Currently the models are in Implicit Differential Equation form 0 = F(y,y'). It will be important moving forward to switch to Hessenberg form. I.e. The differential function x' = b(x,z) is separate from the constraint 0=g(x,z). This additional makes differential variables x and algebraic variables z distinctly separated. Sticking with Implicit Differential Equation makes the design of new methods more complicated. All model examples present here are mappable to Hessenberg form. If needed a constant invertible mass matrix is doable i.e. Mx'=b(x,z) but this can come later as currently no example model uses this.
  • Additionally on Hessenberg form and evaluating over different partitions. The differential function and constraint need to evaluable on different inputs without effecting each other. I.e. evaluating b(x1,z1) should not effect evaluations of g(x2,z2) and vice versus.

These are currently the pressing issues I see that are first to overcome for partition integration.

To summarize, the components need to be able to evaluate their sub-residuals independent of other components on separate inputs. Composers themselves can be considered components for easier grouping and evaluations. This is important to sub-integrator routines. Maintaining a composer level interfacing of components will assist in this (hierarchy structure). Additional a transition to Hessenberg form will be needed.

@Steven-Roberts Any additional comments or suggestions will be helpful.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the cited src/Model/PhasorDynamics/SynchronousMachine/GENROUwS/Genrou.cpp location and trace evaluateResidual through the PhasorDynamics component and composer interfaces. Compare those paths with the PowerElectronics setup and identify how independent evaluations, hierarchical composers, and Hessenberg-form functions would affect the design. Done means the partitioning architecture and required interface changes are agreed and documented across the relevant models.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
18/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.