Description

Equation-Based Modeling of Variable-Structure Systems, March 15, 2010 Presenting SOL An Object-Oriented Modeling Language for Variable-Structure Systems. PhD Examination of Dirk Zimmer, Outline Equation-Based

Information

Category:
## Research

Publish on:

Views: 12 | Pages: 63

Extension: PDF | Download: 0

Share

Transcript

Equation-Based Modeling of Variable-Structure Systems, March 15, 2010 Presenting SOL An Object-Oriented Modeling Language for Variable-Structure Systems. PhD Examination of Dirk Zimmer, Outline Equation-Based Modeling in Sol Variable-Structure Systems Dynamic Processing of DAEs Example: The Trebuchet Conclusions Dirk Zimmer, March 2010, Slide 2 Equation-Based Modeling Physical Models are most generally and conveniently expressed by using differentialalgebraic equations(daes). Equation-based computer languages like Sol enable the modeler to formulate his models directly by terms of equations. t = Iα α = ω& ω = ϕ& t = (1 + cos ϕ)t Dirk Zimmer, March 2010, Slide 3 Equation-Based Modeling Physical Models are most generally and conveniently expressed by using differentialalgebraic equations(daes). Equation-based computer languages like Sol enable the modeler to formulate his models directly by terms of equations. The Sol model describes an engine driving a flywheel. The resulting modeling file can then be used for simulation. model SimpleMachine define inertia as 1.0; interface: parameter Real meant; static Real w; implementation: static Real phi; static Real t; static Real a; t = inertia*z; z = der(x=w); w = der(x=phi); t = (1+cos(x=phi))*meanT; end SimpleMachine; Dirk Zimmer, March 2010, Slide 4 Object Orientation For large systems of equations, it is inconvenient and errorprone to write them down as a whole. Instead, the system shall be composed from reusable submodels. To this end, each model in Sol consists in three parts that enable its generic usage: Theheader The interface The implementation model SimpleMachine define inertia as 1.0; interface: parameter Real meant; static Real w; implementation: static Real phi; static Real t; static Real a; t = inertia*z; z = der(x=w); w = der(x=phi); t = (1+cos(x=phi))*meanT; end SimpleMachine; Dirk Zimmer, March 2010, Slide 5 Object Orientation Every organizational entity in Sol represents a model (One- Component approach). For instance, packages are models that consist solely of a header In this way, we can build a complete model library using Sol models. The example on the right shows excerpts from a library for 1Drotational mechanics package Mechanics [ ] model Engine2 extends Interfaces.OneFlange; interface: parameter Real meantorque; implementation: static Real transm; transm = 1+cos(x = f.phi); f.t = meantorque*transm; end Engine2; model FlyWheel extends Interfaces.OneFlange; interface: parameter Real inertia; static Real w; implementation: static Real z; w = der(x=f.phi); z = der(x=w); -f.t = z*inertia; end FlyWheel; [ ] end Mechanics; Dirk Zimmer, March 2010, Slide 6 Object Orientation Using these library models, we can now compose our top-model without the use of a single equation. This highlights the object-oriented aspects of modern equation-based languages. model Machine implementation: static Mechanics.FlyWheel F{inertia 1}; static Mechanics.Gear G{ratio 1.8}; static Mechanics.Engine2 E{meanTorque 10}; connection{a g.f2, b f.f}; connection{a e.f, b g.f1}; end Machine; Dirk Zimmer, March 2010, Slide 7 Advantages of EOO-Languages Equation-based modeling languages are declarative languages. The modeler can focus on what he wants rather than spending his time on how to achieve a computational realization. This makes the models more self-contained and the knowledge can be conveniently organized in an object-oriented form. Although Sol has been designed from scratch, it builds upon its predecessor, namely Modelica. It represents the state of art with respect to the modeling of physical systems in industry. SowhatisnewaboutSol? Dirk Zimmer, March 2010, Slide 8 Variable-Structure Systems Sol supports the modeling of variable-structure systems. Variable-structure systems forms a collective term for models, where equations change during the time of simulation. The motivation for such models are manifold: Ideal switching processes. Variable number of entities or agents. Variable level of detail. User interaction. Dirk Zimmer, March 2010, Slide 9 Variable-Structure Systems A structural change may cause severe changes in the model structure. Even the exchange of a single equation may concern the whole system. This is why hardly any simulation environment supports this classofmodelsinatrulygeneralway. Onlyafewattemptshavebeenmade: MOSILAB, Chi, HYBRSIM, or recently Hydra Dirk Zimmer, March 2010, Slide 10 Advantages of Sol Most equation-based languages lack the required expressiveness to support variable-structure systems. Sol overcomes this deficiency by generalizing the prevalent language constructs. Thus, Sol enables the creation and removal of equations or even complete objects anytime during the simulation. To this end, the modeler describes the system in a constructive way, where the structural changes are expressed by conditionalized declarations. Dirk Zimmer, March 2010, Slide 11 Structural Change: Example Let us look at a very simple example: The library features two different engine models. One with a constant torque and one with a fluctuating torque, roughly emulating a piston engine. Our intention is to use the latter, more detailed model at start and to switch to the simpler model as soon as the wheel s inertia starts to flatten out the fluctuation of the torque. package Mechanics [ ] model Engine1 extends Interfaces.OneFlange; interface: parameter Real meantorque; implementation: f.t = meantorque; end Engine1; model Engine2 extends Interfaces.OneFlange; interface: parameter Real meantorque; implementation: static Real transm; transm = 1+cos(x = f.phi); f.t = meantorque*transm; end Engine2; [ ] end Mechanics; Dirk Zimmer, March 2010, Slide 12 Structural Change: Example The simulation of the system is trivial. The plot depicts the angular velocity overtime. Dirk Zimmer, March 2010, Slide 13 Structural Change: Example model Machine implementation: static Mechanics.FlyWheel F{inertia 1}; static Mechanics.Gear G{ratio 1.8}; connection{a f.f, b g.f2} static Boolean fast; if initial() then fast false; end; if fast then static Mechanics.Engine1 E{meanT 10}; connection{a e.f, b g.f1}; else then static Mechanics.Engine2 E{meanT 10}; connection{a e.f, b g.f1}; end; when F.w 40 then fast true; end; end Machine; The Boolean variable fast represents the current mode. Dirk Zimmer, March 2010, Slide 14 Structural Change: Example model Machine implementation: static Mechanics.FlyWheel F{inertia 1}; static Mechanics.Gear G{ratio 1.8}; connection{a f.f, b g.f2} static Boolean fast; if initial() then fast false; end; if fast then static Mechanics.Engine1 E{meanT 10}; connection{a e.f, b g.f1}; else then static Mechanics.Engine2 E{meanT 10}; connection{a e.f, b g.f1}; end; when F.w 40 then fast true; end; end Machine; The Boolean variable fast represents the current mode. Itisinitiallysettofalse Dirk Zimmer, March 2010, Slide 15 Structural Change: Example model Machine implementation: static Mechanics.FlyWheel F{inertia 1}; static Mechanics.Gear G{ratio 1.8}; connection{a f.f, b g.f2} static Boolean fast; if initial() then fast false; end; if fast then static Mechanics.Engine1 E{meanT 10}; connection{a e.f, b g.f1}; else then static Mechanics.Engine2 E{meanT 10}; connection{a e.f, b g.f1}; end; when F.w 40 then fast true; end; end Machine; The Boolean variable fast represents the current mode. Itisinitiallysettofalse An if-branch expresses the two modes. Dirk Zimmer, March 2010, Slide 16 Structural Change: Example model Machine implementation: static Mechanics.FlyWheel F{inertia 1}; static Mechanics.Gear G{ratio 1.8}; connection{a f.f, b g.f2} static Boolean fast; if initial() then fast false; end; if fast then static Mechanics.Engine1 E{meanT 10}; connection{a e.f, b g.f1}; else then static Mechanics.Engine2 E{meanT 10}; connection{a e.f, b g.f1}; end; when F.w 40 then fast true; end; end Machine; The Boolean variable fast represents the current mode. Itisinitiallysettofalse An if-branch expresses the two modes. Each mode can declare its own variables or submodels and provide equations. Dirk Zimmer, March 2010, Slide 17 Structural Change: Example model Machine implementation: static Mechanics.FlyWheel F{inertia 1}; static Mechanics.Gear G{ratio 1.8}; connection{a f.f, b g.f2} static Boolean fast; if initial() then fast false; end; if fast then static Mechanics.Engine1 E{meanT 10}; connection{a e.f, b g.f1}; else then static Mechanics.Engine2 E{meanT 10}; connection{a e.f, b g.f1}; end; when F.w 40 then fast true; end; end Machine; The Boolean variable fast represents the current mode. Itisinitiallysettofalse An if-branch expresses the two modes. Each mode can declare its own variables or submodels and provide equations. An Event models the switch between the modes. Dirk Zimmer, March 2010, Slide 18 Solsim: Processing Scheme Parsing To understand, how such a system is simulated, let us take a look at the simulator Solsim. It represents an interpreter. Preprocessing Instantiation and Flattening Evaluation Time Integration The main processing loop of the interpreter contains 3 stages: Instantiation and flattening Dynamic causalization Evaluation Dynamic DAE Processing Event Handling In a classic Modelica translator these stages are executed once in sequential order. In Solsim, they formaloop. Dirk Zimmer, March 2010, Slide 19 Solsim: Processing Scheme To understand, how such a system is simulated, let us take a look at the simulator Solsim. It represents an interpreter. The main processing loop of the interpreter contains 3 stages: Instantiation and flattening Dynamic causalization Evaluation In a classic Modelica translator these stages are executed once in sequential order. In Solsim, they formaloop. Dirk Zimmer, March 2010, Slide 20 Dynamic DAE Processing The heart of the processing loop is the dynamic DAE processing (DDP). Input: Output: Remove equation Add equation Dynamic DAE Processing Causality Graph Dirk Zimmer, March 2010, Slide 21 Index Reduction ThetargetofthisprocessingstageistotransformtheDAEform. F(x p, x p, u(t), t) = 0 into the following state-space form that suits a numerical ODE solution. x= f(x, u(t), t) where the set of state-vector xis a sub-vector of x p. The difficulty of this transformation is commonly described by the perturbation index of the DAE system. Dirk Zimmer, March 2010, Slide 22 Index Reduction There are three major cases: Index-0 systems: The system can be solved by forward substitution. Hence it is sufficient to order the equations. Causalization, Topological Sorting Index-1 systems with algebraic loops: The system cannot be solved by forward substitution anymore. It is required to solve one or several systems of equations. TearingofLoops Index-2 systems and higher-index systems: Again forward substitution is insufficient but there are algebraic constraints between the elements of x p. It is required to differentiate a subset of equations. Algorithmic Differentiation equations equations equations x = x p x = x p x x p variables variables variables Dirk Zimmer, March 2010, Slide 23 Causality Graph The reduced system can be represented as causality graph Each vertex represents an equation(or relation). If the equation is causalized, it points to all those equations that are dependent on the variable it determines. The causality graph is cycle-free andgivesrisetoapartialorder. F.z = der(x=f.w) F.w 40 G.ratio 1.8 E.meanT 10 F.w = der(x=f.f.phi) F.f.phi + G.f2.phi G.f1.phi=G.ratio*G.f2.phi E.f.phi = G.f1.phi E.transm = 1+cos(x=E.phi) E.f.t = E.meanT*E.transm E.f.t + G.f1.t = 0 G.f1.t = G.f2.t/G.ratio F.inertia 1 F.f.t + G.f2.t = 0 -F.f.t = F.intertia*F.z Dirk Zimmer, March 2010, Slide 24 Causality Graph Each update in the set of equations is tracked in the graph. F.z = der(x=f.w) F.w 40 F.w = der(x=f.f.phi) F.f.phi + G.f2.phi G.ratio 1.8 G.f1.phi=G.ratio*G.f2.phi E.meanT 10 E.f.phi = G.f1.phi E.transm = 1+cos(x=E.phi) E.f.t = E.meanT*E.transm E.f.t + G.f1.t = 0 G.f1.t = G.f2.t/G.ratio F.inertia 1 F.f.t + G.f2.t = 0 -F.f.t = F.intertia*F.z Dirk Zimmer, March 2010, Slide 25 Causality Graph Each update in the set of equations is tracked in the graph. F.z = der(x=f.w) F.w 40 F.w = der(x=f.f.phi) F.f.phi + G.f2.phi When we replace the engine model, we first remove the old equations. G.ratio 1.8 E.meanT 10 G.f1.phi=G.ratio*G.f2.phi E.f.phi = G.f1.phi E.transm = 1+cos(x=E.phi) E.f.t = E.meanT*E.transm E.f.t + G.f1.t = 0 G.f1.t = G.f2.t/G.ratio F.inertia 1 F.f.t + G.f2.t = 0 -F.f.t = F.intertia*F.z Dirk Zimmer, March 2010, Slide 26 Causality Graph Each update in the set of equations is tracked in the graph. F.z = der(x=f.w) F.w 40 F.w = der(x=f.f.phi) F.f.phi + G.f2.phi When we replace the engine model, we first remove the old equations. G.ratio 1.8 G.f1.phi=G.ratio*G.f2.phi The dependent equations remain then potentially causalized. G.f1.t = G.f2.t/G.ratio F.inertia 1 F.f.t + G.f2.t = 0 -F.f.t = F.intertia*F.z Dirk Zimmer, March 2010, Slide 27 Causality Graph Each update in the set of equations is tracked in the graph. When we replace the engine model, we first remove the old equations. The dependent equations remain then potentially causalized. By doing so, we attempt to preserve the existing graph from overhasty changes. F.z = der(x=f.w) F.w 40 G.ratio 1.8 F.w = der(x=f.f.phi) F.f.phi + G.f2.phi G.f1.phi=G.ratio*G.f2.phi G.f1.t = G.f2.t/G.ratio F.inertia 1 F.f.t + G.f2.t = 0 -F.f.t = F.intertia*F.z Dirk Zimmer, March 2010, Slide 28 Causality Graph When we add the equations of the new engine model... F.z = der(x=f.w) F.w 40 F.w = der(x=f.f.phi) F.f.phi + G.f2.phi G.ratio 1.8 G.f1.phi=G.ratio*G.f2.phi E.f.phi = G.f1.phi E.meanT 10 E.f.t = E.meanT E.f.t + G.f1.t = 0 G.f1.t = G.f2.t/G.ratio F.inertia 1 F.f.t + G.f2.t = 0 -F.f.t = F.intertia*F.z Dirk Zimmer, March 2010, Slide 29 Causality Graph When we add the equations of the new engine model... F.z = der(x=f.w) F.w 40 F.w = der(x=f.f.phi) F.f.phi + G.f2.phi theygetcausalized G.ratio 1.8 G.f1.phi=G.ratio*G.f2.phi E.f.phi = G.f1.phi E.meanT 10 E.f.t = E.meanT E.f.t + G.f1.t = 0 G.f1.t = G.f2.t/G.ratio F.inertia 1 F.f.t + G.f2.t = 0 -F.f.t = F.intertia*F.z Dirk Zimmer, March 2010, Slide 30 Causality Graph When we add the equations of the new engine model... theygetcausalized and the potential causalization gets reinstated. F.z = der(x=f.w) F.w 40 G.ratio 1.8 F.w = der(x=f.f.phi) F.f.phi + G.f2.phi G.f1.phi=G.ratio*G.f2.phi E.f.phi = G.f1.phi E.meanT 10 E.f.t = E.meanT E.f.t + G.f1.t = 0 G.f1.t = G.f2.t/G.ratio F.inertia 1 F.f.t + G.f2.t = 0 -F.f.t = F.intertia*F.z Dirk Zimmer, March 2010, Slide 31 Causality Graph This structural change could be handled with minimal effort. We can redraw the graph. The left part is solely based on constant values and needs to be computed only once. Dirk Zimmer, March 2010, Slide 32 Causality Conflicts Unfortunately, not all structural changes are so nice. Dirk Zimmer, March 2010, Slide 33 Causality Conflicts: Example Start Dirk Zimmer, March 2010, Slide 34 Causality Conflicts: Example Remove a=1 ; Add d=1 a = 1 b = a c = b x = b d = c z = x z = x d = 1 Dirk Zimmer, March 2010, Slide 35 Causality Conflicts: Example d is now overdetermined. d=1 is put into residual form. b=a remains potentially causalized. b = a c = b x = b d = c z = x z = x Res = (d 1) Dirk Zimmer, March 2010, Slide 36 Causality Conflicts: Example We look up the source of overdetermination. Dirk Zimmer, March 2010, Slide 37 Causality Conflicts: Example Remove existing causalities. Dirk Zimmer, March 2010, Slide 38 Causality Conflicts: Example Recausalize. Dirk Zimmer, March 2010, Slide 39 Causality Conflicts: Example Done. d = 1 d = c c = b x = b b = a z = x z = x Dirk Zimmer, March 2010, Slide 40 Sources of Overdetermination Each equation can be in four different states: Non-causalized Causalized Potentially causalized Causalized in residual form Within index-0 systems, potentially causalized equations are the only source of overdetermination. In index-1 systems, tearing variables are another source of overdetermination. In higher-index systems, the selected state variables may also represent a source of overdetermination. Dirk Zimmer, March 2010, Slide 41 General Processing Scheme For all systems, there is a common approach: 1. Perform forward causalization as much as possible. 2. Forward causalization is supported by potential causalization, selection of tearing variables, and selection of state variables. 3. In case of conflicts, generate residuals. 4. Examine potential sources of overdetermination. 5. When the source has been located, take corresponding action to resolve the conflict. Our approach works very well for index-0 system, it is also good for index-1 systems and represents a practicable solution for higher-index systems. Dirk Zimmer, March 2010, Slide 42 The Trebuchet Let us demonstrate the power of Sol by means of another example: The trebuchet is an old catapult weapon developed in the Middle Ages. Technically, it is a double pendulum propelling a projectile in a sling. The rope of the sling is released on a predetermined angle γ when the projectile is about to overtake the lever arm. Dirk Zimmer, March 2010, Slide 43 The Trebuchet Let us state a few assumptions for the model: All mechanics are planar. The positional states of any object are x, y and the orientation angle φ. All elements are rigid. The sling rope is ideal and weightless. It exhibits an inelastic impulse when being stretched to maximum length. The revolute joint of the counterweight is limited to a certain angle β. It also exhibits an inelastic impulse when reaching its limit. Air resistance or friction is neglected. Dirk Zimmer, March 2010, Slide 44 The Trebuchet Whereas these idealizations simplify the parameterization of the model, they pose serious difficulties for a general simulation environment. Although being fairly simple, the model can neither be modeled nor simulated with Modelica yet. At least not in a truly objectoriented manner. Indeed, the trebuchet represents a very suitable example for variable-structure systems since it puts up a broad set of requirements. List of Requirements(incomplete): The simulator must provide means for the numerical time integration. The simulator must provide means for the symbolical differentiation. The simulator must provide means for the numerical solution of linear and nonlinear systems of equations. The simulator must be able to trigger events. The simulator must be able to handle consecutive, discrete events and to synchronize them The simulator shall support the runtime instantiation and deallocation of arbitrary components. Changes in the set of DAEs shall be handled in an efficient manner that provides a general solution. Dirk Zimmer, March 2010, Slide 45 Object-Oriented Modeling For the object-oriented modeling, we decompose the model into components from a planar mechanical library. m=100 rodmass rod1 a b r={-10,0} rod2 a b r={2,5,0} limitedrev a b m=30 revolute m=10e3 w eight fixed r={0,8} a b r={0,-3} rod3 a b tornbody The total model contains from 246 to 256 variables. The corresponding systems of DAEs have the perturbation index 3. They need to be differentiated twice and they contain linear equation systems. Dirk Zimmer, March 2010, Slide 46 Object-Oriented Modeling Three of these components exhibit structural changes: m=100 rodmass rod1 a b r={-10,0} rod2 a b r={2,5,0} limitedrev a b m=30 revolute m=10e3 w eight fixed r={0,8} a b r={0,-3} rod3 a b tornbody Whereas the top-model can be neatly decomposed into generally applicable components, the modeling of these components requires a skilled modeler. Dirk Zimmer, March 2010, Slide 47 Revolute Joint: Modes The classic revolute joint just has one continuous-time mode. An intermediate mode is required in order to handle external i

Related Search

Similar documents

We Need Your Support

Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks