Model Interoperability

Summary

Discussion of model conversion and data authority between models (PowerFlow, PhasorDynamics, and EMT)

Rationale

PowerFlow, PhasorDynamics, and EMT in practice are co-dependent. Their case data and initialization are coupled, and there are some fundamental details we need to layout before implementing EMT.

Description

Although it depends on the application and dataset, the following dependence between models can be described as:

• PowerFlow initializes PhasorDynamics
• PhasorDynamics initializes EMT

In an ideal world, we would have ONE authorative EMT model from which PhasorDynamics and PowerFlow are derived (i.e., the parameters and structural properties of the case). so ideally:

• PowerFlow derived from PhasorDynamics
• PhasorDynamics derived from EMT

That is not always feasible so it is sometimes done in reverse, making reduced order assumption. Typically, the interface of these models is concerned with intialization of state, and its not clear how that should be done, or what API should own that interoperability in GridKit.

!!!Translating between domains in power systems is a known friction!!!, and it would be valuable to discuss how we might confront this in GridKit so we dont trap ourselves. We need to establish a parameter and initialization interface between these models.

This has been at the front of my mind during the PES general meeting and this week's meeting with Ignas regarding PowerFlow.

Additional information

The PowerFlow to PhasorDynamics Interface tracked in #466

Start by reviewing the PowerFlow to PhasorDynamics interface tracked in #466 and the model relationships described here. Clarify model authority, conversion direction, state initialization, and API ownership; done means an agreed interoperability design that can guide EMT implementation.