Extend overconstrained connector semantics to allow runtime islanding and reconnection

[casella]

The discussion in OMC #6240 comment 2 puts forward a proposal for an extension of the current overconstrained connector semantics, that could be used to allow runtime islanding and reconnection in PowerGrids with a nice object-oriented description and with very little additional code to the library.

Of course this requires a prototype implementation in OpenModelica and, if successful, to start the MCP process to get it into the Modelica specification. I believe the prototype implementation should be relatively straightforward.

@adriguir, @RomainLosseauRTE, @MarianneSaugierRTE, @max-privato, @dietmarw, I'd like to have your feedback on this.

[casella]

Update: OSMC and RTE now have an agreement to test-implement the concept using @JKRT's Julia prototype implementation of OpenModelica, which allows to play around with extensions much more easily. Expected delivery date by Dec 2022. If the test implementation is successful, the plan is to start the process for an MCP (a change in the Modelica Language Specification) to standardize it.

Once the Modelica compiler(s) supports this feature, implementing it in a future version of the library is straighforward - one needs to:

• add the frequency reference as overconstrained variable in the terminal connector definition
• add the equations to generate (for machines and infinite buses) or propagate (for load, lines, transformers) this information to the appropriate base classes of components
• get this information from the overconstrained connectors instead of from the system object in machine models.

The system object should then include a parameter Boolean allowDynamicIslanding = false to activate this option. Components with branches that could be deactivated dynamically (e.g. transmission lines with breakers) should contain code such as:

    if closed or not allowDynamicIslanding then
      port_a.omegaRef = port_b.omegaRef;
      Connections.branch(port_a.omegaRef, port_b.omegaRef);
    end if;

In this way, with the default option the conditional equations are always active, and can be handled by any Modelica 3.5 compatible tool. If allowDynamicIslanding is set to true, then the model can only be handled if the tool supports this language extension.

Of course this would prevent implementing dynamic islanding in Modelica 3.5 in future versions of the library - however, doing this requires a lot of work, is fairly ugly in terms of Modelica modelling style, and may probably never happen.

An implementation based on dynamically breakable connection graphs would instead be very elegant and parsimonious from the point of view of the source code, hence more aligned with the intent of this library, which is to use advanced Modelica constructs to make the code as simple and high-level as possible, leaving it to the tool to handle low-level structural and numerical manipulation.

[casella]

We got very nice results on this topic, see the following documents:

• J. Tinnerholm, F. Casella, A. Pop, Towards Modeling and Simulation of Dynamic Overconstrained Connectors in Modelica, Proc. 2022 Asian Modelica Conference, DOI:10.3384/ecp19335
• J. Tinnerholm, F. Casella, A. Pop, Techniques for Modeling And Simulation of Dynamic Overcontrained Connectors, OpenModelica Workshop 2023, link.

We demonstrated that the concept is sound and can be easily implemented in Modelica tools. In principle, it involves structural variability, but in practice this is limited to a small subset of equality equations in the system, that can be easily handled in the runtime via pointers.

Of course this concept should become part of the Modelica Language Specification, we are working on that.