Changes between Initial Version and Version 1 of Ticket #6238


Ignore:
Timestamp:
2020-11-22T23:55:11Z (5 years ago)
Author:
Francesco Casella
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #6238 – Description

    initial v1  
    3939
    4040Handling this case at runtime is relatively straighforward. During initialization, and each time an if-equation is triggered that contains a {{{Connection.branch(A.R, B.R)}}} call and an equation {{{A.R = B.R}}}, the runtime must:
    41 - build the connection graph 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]
     41- build the connection graph 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 active once the if-equation has been processed
    4242- identify disjoint sub-graphs and select one root node for each of them, if not already given by {{{Connection.root()}}}
     43- break all loops in the graph, replacing the connection equation with the (empty) constraint in each branch that is broken
    4344- 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)
    4445- in case a branch is re-established, it may be sensible to add a numerical check that the corresponding equation involving the overconstrained connector variables is actually verified within some tolerance, otherwise aborting the simulation; this would correspond to the requirement that two islands can only be reconnected if the are operating exactly at the same frequency. This check could be defined by adding one more function to the overconstrained type definition, which returns a boolean indicating if the reconnection is feasible