Changes between Version 5 and Version 6 of Ticket #6240, comment 2


Ignore:
Timestamp:
2021-05-12T11:05:54Z (4 years ago)
Author:
Francesco Casella

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #6240, comment 2

    v5 v6  
    11The overconstrained connector semantics defined in Section [https://specification.modelica.org/master/connectors-and-connections.html#equation-operators-for-overconstrained-connection-based-equation-systems1 9.4] of Modelica 3.5 considers a fixed connection graph, that can be handled statically at compile time.
    22
    3 One of the cited examples for overconstrained types in connectors is the phase information in AC power systems. The current semantics is able to represent synchronous systems whose topology remains unchanged during simulation. The phase reference is generated by one component of the synchronous system (normally a power generator) and distributed throughout the entire synchronous system via the overconstrained connector variable. In fact, it is possible to have multiple synchronous systems in the same Modelica model, that correspond to structurally disconnected connections sub-graphs, e.g. two national grids connected by a DC link, but in any case their topology is fixed at runtime.
     3One of the cited examples for overconstrained types in connectors is the phase information in AC power systems. The current semantics is able to represent synchronous systems whose topology remains unchanged during simulation. The phase reference is generated by one component of the synchronous system (normally a large synchronous generator) and distributed throughout the entire synchronous system via the overconstrained connector variables. In fact, it is possible to have multiple synchronous systems in the same Modelica model, that correspond to structurally disconnected connections sub-graphs, e.g. two national grids connected by an undersea DC link, but in any case their topology is fixed at runtime.
    44
    55When modelling AC trasmission systems, is is possible that in case of severe perturbations, some key circuit breakers are switched open (i.e., their admittance brought to zero), effectively splitting a single synchronous system into multiple synchronous islands. Note that this requires no structural changes in the grid equations, only to set some admittance values to zero.
    … …  
    77When this happens, the two (or more) ensuing islands can settle into new steady states with different frequencies. Hence, if a single, whole-system-wide reference is still used, the phase angle of currents and voltages of the now disconnected island(s) will continue to rotate permanently with a frequency that is the difference between the local island frequency and the frequency of the island where the original root node was picked. This is very inconvenient, because it prevents variable step-size solvers to increase the step size, once the system settles to the new steady state.
    88
    9 This problem could be avoided by allowing to dynamically add or remove the unbreakable branches corresponding to {{{Connections.branch()}}} statements in the connection graph of [https://specification.modelica.org/v3.5/Ch9.html#equation-operators-for-overconstrained-connection-based-equation-systems1 Section 9.4], based on the status of the breaker components, and to add or remove the equations that show up in the same if-equation branches where the {{{Connections.branch()}}} statements are declared. It would then be possible to break up the original synchronous connections established by transmission lines when their admittance is brought to zero, thus modelling effects of circuit breakers on the synchronous sub-system topology.
     9This problem could be avoided by allowing to dynamically add or remove the unbreakable branches corresponding to {{{Connections.branch()}}} statements in the connection graph of [https://specification.modelica.org/v3.5/Ch9.html#equation-operators-for-overconstrained-connection-based-equation-systems1 Section 9.4], based on the status of the corresponding breaker components, and to add or remove the equations that show up in the same if-equation branches where the {{{Connections.branch()}}} statements are declared. It would then be possible to break up the original synchronous connections established by transmission lines when their admittance is brought to zero, thus modelling effects of circuit breakers on the synchronous sub-system topology.
    1010
    1111As a consequence, two or more disjoint connection graphs would be formed at the time of the breaker openings, each corresponding to a new synchronous island. The new graph topology should be analyzed at this point, picking a new root node for each newly formed island in the grid. Then, instead of having a single phase reference for the entire system, which would no longer be adequate, one would now have two or more independent phase references, one for each island, which would ensure that the variables of each island reach a steady state, thus avoiding the persistent sinusoidal oscillations found in the case of a statically determined connection topology.
    … …  
    1414  The only exception to this rule is when the if branch only contains {{{Connection.branch()}}} statements and equations exclusively involving the overconstrained variables of the connectors declared in the {{{Connection.branch()}}} statement. //The rationale is that in this case, the overconstrained connector semantics takes care of always getting a balanced system.//
    1515
    16 and by adding the definition of the {{{reconnectable()}}} function to the overconstrained type definitions given in Section [https://specification.modelica.org/maint/3.5/connectors-and-connections.html#overconstrained-equation-operators-for-connection-graphs 9.4.1]. From an implementation point of view, this means that parts of the graph connection analysis no longer can be performed statically at compile time, but need to be deferred to run time, because some unbreakable branches may be optionally activated or deactivated at runtime.
     16and by adding the definition of the {{{reconnectable()}}} function to the overconstrained type definitions given in Section [https://specification.modelica.org/maint/3.5/connectors-and-connections.html#overconstrained-equation-operators-for-connection-graphs 9.4.1].
     17
     18From an implementation point of view, this means that parts of the graph connection analysis no longer can be performed statically at compile time, but need to be deferred to run time, because some unbreakable branches may be optionally activated or deactivated at runtime.
    1719
    1820According to [https://specification.modelica.org/v3.5/Ch9.html#converting-the-connection-graph-into-trees-and-generating-connection-equations Section 9.4.2], everything except overconstrained connector variables is always handled in the same way, i.e., following [https://specification.modelica.org/v3.4/Ch9.html#generation-of-connection-equations Section 9.2], so the runtime analysis will be limited to overconstrained variables in connectors. Everthing else, including determining connection sets, building connection equations for flow variables, and handling stream connector variables, is unchanged and can still be managed statically at compile time.
    … …  
    2224The attached package {{{DynamicOverconstrainedConnectors2.mo}}} contains components to build conceptual models of phasor-based AC power grid models, and will be used to demonstrate the proposed approach. The components are overly simplified and only retain the minimal features that are needed to analyze this language semantics extension.
    2325
    24 In this case, the overconstrained variable is actually not the phase angle but rather the angular velocity of the phasor reference frame, which is sufficient to ensure that all state variables are constant when the synchronous islands are all operating in steady state.
     26In this case, the overconstrained variable is actually not the phase angle but rather the angular velocity of the phasor reference frame, which is sufficient to ensure that all state variables are constant when the synchronous islands are all operating in steady state, and avoids introducing extra unnecessary states to relate phase and frequency of different disconnected sub-grids.
    2527
    2628{{{System 1}}} is a basic example with two generators {{{G1}}} and {{{G2}}}, each connected to a local load, connected by an inductive transmission line {{{T}}}. The system starts in steady state with balanced loads, then at time = 1 the active power consumption of load {{{L2}}} is reduced by 20%. This starts a transient, that eventually dies out once the primary frequency controls stabilize the system at a new, higher frequency. Note that at that point, all state variables are constant, allowing implicit solvers to take large time steps.
    … …  
    6971      B_act = B;
    7072    end when;
     73    // Equations affected by the proposed change to the specification:
    7174    if closed then
    7275      port_a.omegaRef = port_b.omegaRef;
    … …  
    8083During flattening, the front end should indentify all the potentially connected subgraphs (i.e., ignoring the fact that some {{{Connections.branch()}}} statements are inside if-equations), then identify those of them that only contain static {{{Connections.branch()}}} statements, and those that contain at least one unbreakable branch declared within a conditional {{{Connections.branch()}}} statement.
    8184
    82 The former subgraphs should be handled as usual in Modelica 3.5. For the latter, all the relevant information about overconstrained types and variables, and about nodes and branches of the corresponding subgraphs, should be passed to the backend using some suitable formalism. Subgraphs that are structurally disconnected, regardless of the activation of some unbreakable branches, should be identified as such.
     85The former subgraphs should be handled by the front-end as usual in Modelica 3.5. For the latter, the front-end will process the connection sets and the flow, effort and stream variable equations as usual; however, it should pass to the back-end the relevant information about overconstrained types and variables, and about nodes and branches of the corresponding subgraphs. Subgraphs that are structurally disconnected, regardless of the activation of some unbreakable branches, should be identified as such.
    8386
    8487I guess we should try to re-use the front-end code in the backend as much as possible, and even in the runtime code (e.g. for graph analysis) as long as the MetaModelica code of the frontend can be translated into C/C++ code.
    … …  
    8790- re-build the connection graphs of all the structurally unconnected sub-graphs to which the branches that changed their activation status belong, according to the rules set forth in [https://specification.modelica.org/master/connectors-and-connections.html#equation-operators-for-overconstrained-connection-based-equation-systems1 Section 9.4], only accounting for branches that are actually active
    8891- in case a previously de-activated branch is re-established, check that the corresponding connection equation involving the overconstrained connector variables is actually verified within some tolerance, otherwise abort the simulation; this would correspond to the requirement that two islands can only be reconnected if the are operating exactly at the same frequency or phase. This check can be defined by adding one more function {{{reconnectable()}}} to the overconstrained type definition, which returns a boolean indicating if the reconnection is feasible (see below).
    89 - identify disjoint sub-graphs that are each structurally connected, and select one root node for each of them, according the standard rules set forth in [https://specification.modelica.org/v3.4/Ch9.html#converting-the-connection-graph-into-trees-and-generating-connection-equations Section 9.4.2]
     92- identify disjoint sub-graphs that are internally connected, and select one root node for each of them, according the standard rules set forth in [https://specification.modelica.org/v3.4/Ch9.html#converting-the-connection-graph-into-trees-and-generating-connection-equations Section 9.4.2]
    9093- break all loops in those sub-graphs
    9194- set each overconstrained connector variable of each sub-graph to be equal to the value of the corresponding root node variable (this can be done trivially via pointers!)
    9295
     96Regarding the last two points, the back-end processing in the case of overconstrained variables being declared as equal in the unbreakable conditional branches, and of empty constraint equation, is trivial. At the end of the day, for each connected sub-graph, all the overconstrained connector variables are equal to the one of the selected root node. I guess generating code for this is also no big deal.
    9397
    94 If a frequency reference is used, the {{{reconnectable}}} function could be implemented as
     98If a frequency reference is used as overconstrained connector variable (e.g. in the {{{PowerGrids}}} library, the {{{reconnectable}}} function could be implemented as
    9599{{{#!mo
    96100function reconnectable
    … …  
    105109}}}
    106110
    107 For phase references, one should account for {{{2*pi}}} ambiguity
     111For phase references, as in the {{{PowerSystems}}} library, one should also account for {{{2*pi}}} ambiguity
    108112
    109113{{{#!mo
    … …  
    121125}}}
    122126
    123 I suppose this feature could be implemented rather easily in OpenModelica, as a first prototype implementation of this language extension. It could be tested in an extended version of the attached {{{DynamicOverconstrainedConnectors2.mo}}} package, including some more examples with a bit more nodes and edges in the connection graphs, and finally tested on an extended version of the [https://github.com/powergrids PowerGrids library], that already envisioned such a feature.
     127I suppose this feature could be implemented rather easily in OpenModelica, as a first prototype implementation of this language extension. It could be tested in an extended version of the attached {{{DynamicOverconstrainedConnectors2.mo}}} package, including some more examples with a bit more nodes and edges in the connection graphs, and finally tested on an extended version of the [https://github.com/powergrids PowerGrids library], that could be very easily extended to include this feature, by just changing a few lines of code.
    124128
    125 Another application of this extension could be incompressible fluid systems. These systems require a component setting the pressure for each connected subsystem. When closing some strategic valves, it is possible to split the circuit in two or more unconnected parts. At that point, new pressure-setting components (i.e. root nodes) should be identified, one for each newly formed subsystem.
     129Another application of this extension could be incompressible fluid systems. These systems require a component setting the pressure for each connected subsystem, corresponding to a pressurizer or expansion tank. When closing some strategic valves, it is possible to split the circuit in two or more unconnected parts, which should of course have at least one expansion tank each. At that point, new pressure-setting components (i.e. root nodes) should be identified, one for each newly formed subsystem.
    126130
    127 If the experiments with the prototype are successful, this could form the basis of an MCP to introduce this feature into the next version of the Modelica Specification.
     131I don't yet have the code ready for this system, but I can produce it overnight if we proceed with this proposal.
     132
     133If the experiments with the prototype are successful, this text could form the basis of an MCP to introduce this feature into the next version of the Modelica Specification.