## 2.2The Modelica Language Starting 1989, our group developed an equation-based specification language for mathematical modeling called ObjectMath (Fritzson et al. 1995 [53], Viklund et al. 1992 [173]), using Mathematica as a basis and a frontend, but adding object orientation and efficient code generation. Following this path, in 1996 our group joined efforts with several other groups in object-oriented mathematical modeling to start a design-group for developing an internationally viable declarative mathematical modeling language. This language, called *Modelica*, has been designed by the Modelica Design Group, initially consisting mostly of the developers of a number of different equation-based object-oriented modeling languages like Allan, Dymola, NMF, ObjectMath, Omola, SIDOPS+, Smile, as well as other modeling and simulation experts. In February 2000, a non-profit organization named “Modelica Association” was founded in Linköping, Sweden, for further development and promotion of Modelica. Modelica (Elmqvist et al. 1999 [35], Fritzson 2004 [44], Fritzson and Engelson 1998 [50], Modelica.Association 1996-2008 [99], Tiller 2001 [152]) is an object-oriented modeling language for declarative equation-based mathematical modeling of large and heterogeneous physical systems. For modeling with Modelica, commercial software products such as MathModelica (MathCore [91]) or Dymola (Dynasim 2005 [27]) have been developed. Also open-source implementations like the OpenModelica system (Fritzson et al. 2002 [46], PELAB 2002-2008 [118]) are available. The Modelica language has been designed to allow tools to automatically generate efficient simulation code with the main objective of facilitating exchange of models, model libraries, and simulation specifications. The definition of simulation models is expressed in a declarative manner, modularly and hierarchically. Various formalisms can be expressed in the more general Modelica formalism. In this respect Modelica has a multi-domain modeling capability which gives the user the possibility to combine electrical, mechanical, hydraulic, thermodynamic, etc., model components within the same application model. Compared to most other modeling languages available today, Modelica offers several important advantages from the simulation practitioner’s point of view:
*Object-oriented mathematical modeling*. This technique makes it possible to create model components, which are employed to support hierarchical structuring, reuse, and evolution of large and complex models covering multiple technology domains. *A general type system* that unifies object-orientation, multiple inheritance, and generics templates within a single class construct. This facilitates reuse of components and evolution of models.
*Acausal modeling* based on ordinary differential equations (ODE) and differential algebraic equations (DAE) together with discrete equations forming a hybrid DAE.. There is also ongoing research to include partial differential equations (PDE) in the language syntax and semantics (Saldamli et al. 2002 [142]), (Saldamli 2002 [140], Saldamli et al. 2005 [141]).
*Multi-domain modeling* capability, which gives the user the possibility to combine electrical, mechanical, thermodynamic, hydraulic etc., model components within the same application model.
*A strong software component model*, with constructs for creating and connecting components. Thus the language is ideally suited as an architectural description language for complex physical systems, and to some extent for software systems. Visual *drag & drop and connect composition of models* from components present in different libraries targeted to different domains (electrical, mechanical, etc). The language is strongly typed and declarative. See (Modelica.Association 1996-2008 [99]), (Modelica-Association 2005 [101]), (Tiller 2001 [153]), and (Fritzson 2004 [44]) for a complete description of the language and its functionality from the perspective of the motivations and design goals of the researchers who developed it. Shorter overviews of the language are available in (Elmqvist et al. 1999 [35]), (Fritzson and Engelson 1998 [50]), and (Fritzson and Bunus 2002 [49]). The Modelica component model includes the following three items: a) components, b) a connection mechanism, and c) a component framework. *Components* are connected via the *connection mechanism* realized by the Modelica system, which can be visualized in connection diagrams. The *component framework* realizes components and connections, and ensures that communication works over via the connections. For systems composed of *acausal* components with behavior specified by equations, the direction of data flow, i.e., the *causality* is initially unspecified for connections between those components. Instead the causality is automatically deduced by the compiler when needed. Components have well-defined *interfaces* consisting of ports, also known as *connectors*, to the external world. A component may internally consist of other connected components, i.e., *hierarchical* modeling is possible. Figure 2 -4 shows a hierarchical component-based modeling of an industry robot. **Figure 2 4. Hierarchical model of an industrial robot, including components such as motors, bearings, control software, etc. At the lowest (class) level, equations are typically found.** ### 2.2.1An Example Modelica Model The following is an example Lotka Volterra Modelica model containing two differential equations relating the sizes of rabbit and fox populations which are represented by the variables `rabbits` and `foxes` : The model was independently developed by Alfred J Lotka (1925) and Vito Volterra (1926): The rabbits multiply (by breeding); the foxes eat rabbits. Eventually there are enough foxes eating rabbits causing a decrease in the rabbit population, etc., causing cyclic population sizes. The model is simulated and the sizes of the rabbit and fox populations are plotted in Figure 2 -5 as a function of time. **Figure 2 5. Number of rabbits – prey animals, and foxes – predators, as a function of time simulated from the predator-prey LotkaVolterra model.** The notation `der(rabbits)` means time derivative of the `rabbits` (population) variable.
**model** `LotkaVolterra` **parameter** Real g_r =0.04 "Natural growth rate for rabbits"; **parameter** Real d_rf=5e-5 "Death rate of rabbits due to foxes"; **parameter** Real d_f =0.09 "Natural death rate for foxes"; **parameter** Real g_fr=0.1 "Efficiency in growing foxes from rabbits"; Real rabbits(start=700) "Rabbits with start population 700"; Real foxes(start=10) "Foxes, with start population 10";
**equation** **der**(rabbits) = g_r*rabbits - d_rf*rabbits*foxes; **der**(foxes) = g_fr*d_rf*rabbits*foxes - d_f*foxes;
**end** `LotkaVolterra` ; ### 2.2.2Modelica as a Component Language Modelica offers quite a powerful software component model that is on par with hardware component systems in flexibility and potential for reuse. The key to this increased flexibility is the fact that Modelica classes are based on equations, i.e., acausal connections for which the direction of data flow across the connection is not fixed. Components are connected via the connection mechanism, which can be visualized in connection diagrams. The component framework realizes components and connections, and ensures that communication works and constraints are maintained over the connections. For systems composed of acausal components the direction of data flow, i.e., the causality is automatically deduced by the compiler at composition time. Two types of coupling can be established by connections depending on whether the variables in the connected connectors are non-flow (default), or declared using the `flow` prefix: Equality coupling, for non-flow variables, according to Kirchhoff’s first law. Sum-to-zero coupling, for flow variables, according to Kirchhoff’s current law. For example, the keyword `flow` for the variable `i` of type `Current` in the `Pin` connector class indicates that all currents in connected pins are summed to zero, according to Kirchhoff’s current law. **Figure 2 6. Connecting two components that have electrical pins.** Connection equations are used to connect instances of connection classes. A connection equation `connect(pin1,pin2)` , with `pin1` and `pin2` of connector class `Pin` , connects the two pins (Figure 2 -6) so that they form one node. This produces two equations, namely: pin1.v = pin2.v pin1.i + pin2.i = 0 The first equation says that the voltages of the connected wire ends are the same. The second equation corresponds to Kirchhoff's second law, saying that the currents sum to zero at a node (assuming positive value while flowing into the component). The sum-to-zero equations are generated when the prefix `flow` is used. Similar laws apply to flows in piping networks and to forces and torques in mechanical systems. |