Advanced OpenModelica plotting package for Modelica

(1)

Institutionen för datavetenskap

Department of Computer and Information Science

Final thesis

Advanced OpenModelica plotting package for

Modelica

by

Henrik Eriksson

LIU-IDA/LITH-EX-A -- 08/036 -- SE

2008-06-22

Linköpings universitet SE-581 83 Linköping, Sweden

Linköpings universitet 581 83 Linköping

(2)

(3)

Final thesis

Advanced OpenModelica plotting package for

Modelica

by

Henrik Eriksson

LIU-IDA/LITH-EX-A–08/036–SE

Supervisors: Anders Sandholm, Prof. Peter Fritzson,

Department of Computer and Information Science, Link¨opings Uni-versitet

Examiner: Prof. Peter Fritzson,

Department of Computer and Information Science, Link¨opings Uni-versitet

(4)

(5)

PELAB, IDA 581 83 LINK ¨OPING SWEDEN 2008-06-22 x x http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-15075 LIU-IDA/LITH-EX-A–08/036–SE

Advanced OpenModelica plotting package for Modelica

Henrik Eriksson

OpenModelica is an open-source based development environment for Modelica coordinated by the Programming Environments Laboratory (PELAB) at Link¨opings Universitet.

Previously an external tool, PtPlot, has been used to create graphics from simulation data. This tool is poorly integrated with OMNotebook, the OpenModelica Notebook, which is a tool for creating interactive doc-uments where Modelica code can be edited and evaluated.

This thesis develops and implements a plotting API accessible from Mod-elica algorithmic code and extends OMNotebook to allow creation of diagrams and other forms of graphics without an external application. These diagrams are more customizable than those generated by PtPlot and allow for example logarithmic scaling. The new Modelica API for graphic programming allows access of graphic functionality from within Modelica models and Modelica functions.

Modelica, OpenModelica, OMNotebook, Interactive notebook Nyckelord Keywords Sammanfattning Abstract F¨orfattare Author Titel Title

URL f¨or elektronisk version

Serietitel och serienummer Title of series, numbering

ISSN ISRN ISBN Spr˚ak Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats ¨ Ovrig rapport Avdelning, Institution

(6)

(7)

Abstract

OpenModelica is an open-source based development environment for Model-ica coordinated by the Programming Environments Laboratory (PELAB) at Link¨opings Universitet.

Previously an external tool, PtPlot, has been used to create graphics from simulation data. This tool is poorly integrated with OMNotebook, the OpenModelica Notebook, which is a tool for creating interactive documents where Modelica code can be edited and evaluated.

This thesis develops and implements a plotting API accessible from Mod-elica algorithmic code and extends OMNotebook to allow creation of dia-grams and other forms of graphics without an external application. These diagrams are more customizable than those generated by PtPlot and allow for example logarithmic scaling. The new Modelica API for graphic program-ming allows access of graphic functionality from within Modelica models and Modelica functions.

Keywords: Modelica, OpenModelica, OMNotebook, Interactive notebook

(8)

(9)

Acknowledgements

This thesis was written as a part of my Master of Science degree in Applied Physics and Electrical Engineering at Link¨opings Universitet, Sweden. My employer was the Programming Environments Laboratory (PELAB) at the Department of Computer and Information Science (IDA).

Special thanks to my supervisor Anders Sandholm, for great support and ideas throughout the project, and to my examiner Peter Fritzson for setting up and giving me the opportunity to work on this interesting master project in the first place and for giving feedback and suggestions regarding the work.

(10)

(11)

List of Figures

1.1 Simulation of a model . . . 5

1.2 Plotting of simulation results . . . 5

1.3 Plotting with the new graphics package . . . 7

1.4 Data transfer during simulation . . . 8

5.1 Diagram generated by PtPlot (top) and the new graphics package (bottom) . . . 39

5.2 Magnification around a data point . . . 39

5.3 Diagram generated by PtPlot (top) and by the new graphics package (bottom) . . . 41

5.4 Diagram generated by PtPlot (top) and by the new graphics package (bottom) . . . 42

5.5 Geometrical objects . . . 43

8.1 Input cell and context menu . . . 54

8.2 The legend menu . . . 55

8.3 Labels . . . 56

8.4 Legend . . . 57

8.5 Ranges . . . 58

8.6 Grid . . . 59

8.7 Simulation data . . . 60

8.8 External graphics window . . . 61

9.1 Input cell with the model VanDerPol . . . 64

9.2 Input cell after a simulation . . . 64

9.3 Parametric diagram . . . 65

9.4 Zooming in an Input cell . . . 65

9.5 Magnified Input cell . . . 66

9.6 Result of the plotAll command . . . 66

9.7 The D button . . . 68

9.8 Plotting of table data . . . 69

(16)

xiv List of Figures 9.9 Drawing of geometrical objects . . . 70 9.10 Default appearance for diagrams . . . 70 9.11 Diagram with logarithmically scaled y-axis . . . 71

(17)

Chapter 1 Introduction

This chapter describes the goal, problem statement and method of the project. Essential concepts, e.g. Modelica and OpenModelica will be introduced and an overview of this report will be given.

1.1 Overview

This report is divided into several chapters with different purposes. The chapters are the following:

Chapter 1 This chapter contains background information about Modelica and OpenModelica and describes which problems this thesis aims to solve and the methods that will be used to do so.

Chapter 2 This chapter contains information about the tools that have been used.

Chapter 3 This chapter contains information about the requirements of the graphics package that will be developed.

Chapter 4 This chapter is the main part of this report and describes in more detail the changes that have been made to OMC (see section 1.3.1) and OMNotebook (see section 1.3.2) in order to reach the goals of the project.

Chapter 5 This chapter contains tests and evaluations of the graphics pack-age.

Chapter 6 This chapter presents similar graphics packages and discusses their compatibility.

(18)

2 Chapter 1. Introduction Chapter 7 This chapter contains ideas and suggestions for changes that in the future can be made to further improve the usability of OpenMod-elica.

Chapter 8 This chapter presents and describes the new features in the user interface of OMNotebook.

Chapter 9 This chapter contains a number of examples of how the graphics package can be used.

Chapter 10 This chapter contains an analysis of the results of this thesis. Appendix A This chapter contains the Modelica models that are used in

this report.

Appendix B This chapter contains the implementation of the Modelica interface of the graphics package.

Appendix C This chapter contains the XML specification of the file format of OMNotebook.

Appendix D This chapter contains the contents of the file stylesheet.xml, which specifies the appearance of cells in OMNotebook.

1.2 Modelica

Modelica is a freely available, object-oriented language for modeling of large, complex, and heterogeneous physical systems. It is suited for multi-domain modeling, for example, mechatronic models in robotics, automotive and aerospace applications involving mechanical, electrical, hydraulic and control subsystems, process oriented applications and generation, and distribution of electric power. Modelica is designed such that it can be utilized in a similar way as an engineer builds a real system: First trying to find standard com-ponents like motors, pumps and valves from manufacturers’ catalogues with appropriate specifications and interfaces and only if there does not exist a particular subsystem, a component model would be newly constructed based on standardized interfaces.[1]

Models in Modelica are mathematically described by differential, alge-braic and discrete equations. No particular variable needs to be solved for manually. A Modelica tool will have enough information to decide that au-tomatically. Modelica is designed such that available, specialized algorithms can be utilized to enable efficient handling of large models having more than hundred thousand equations.[1]

(19)

1.2. Modelica 3 The following example, Moon Landing, is given in DrModelica[2] and shows the object-oriented nature of Modelica.

model Body "Generic body" Real mass;

String name; end Body;

model CelestialBody "Celestial body" extends Body;

constant Real g = 6.672e-11; parameter Real radius; end CelestialBody; class Rocket extends Body; Real altitude(start = 59404); Real velocity(start = -2003); Real acceleration;

Real thrust; // Thrust force on the rocket

Real gravity; // Gravity forcefield

parameter Real massLossRate = 0.000277; equation

(thrust - mass*gravity) / mass = acceleration; der(mass) = -massLossRate * abs(thrust); der(altitude) = velocity;

der(velocity) = acceleration; end Rocket;

model MoonLanding

parameter Real force1 = 36350; parameter Real force2 = 1308; parameter Real thrustEndTime = 210; parameter Real thrustDecreaseTime = 43.2;

Rocket apollo(name = "Apollo13", mass(start=1038.358) );

CelestialBody moon(name = "moon", mass = 7.382e22, radius = 1.738e6); equation

apollo.thrust = if (time < thrustDecreaseTime) then force1

else if (time < thrustEndTime) then force2

else 0;

apollo.gravity = moon.g*moon.mass/(apollo.altitude + moon.radius)^2; end MoonLanding;

The model MoonLanding is created from a number of smaller objects, for example Rocket and CelestialBody, which are created by inheriting a more

(20)

4 Chapter 1. Introduction basic object, Body. This way of constructing a large model from several smaller, perhaps with some modifications like name, mass and radius in the example above, makes it easier to reuse existing code. Modelica has a large library of standard components, e.g. resistors, capacitors and motors, which can be used as they are or customized to better suit the needs of a specific simulation.

When a model is defined it can be simulated for example by invoking the Modelica compiler, OMC (see section 1.3.1). For the model above this is done with the command

simulate(MoonLanding, startTime=0, stopTime=300)

which simulates the model from 0 to 300 seconds.

1.3 OpenModelica

OpenModelica [3] is a project that aims to create a free modeling and sim-ulation environment for Modelica. The project is coordinated by PELAB [4], the Programming and Environments Laboratory, at Link¨opings univer-sitet. The main activity of the project is the development of the Modelica compiler OMC (see section 1.3.1), but also utilities like OMNotebook (see section 1.3.2) and development tools are developed.

1.3.1 OMC

OMC, the OpenModelica Compiler, is an open source Modelica compiler developed by the OpenModelica project. OMC is the main part of the OpenModelica Modelica environment and is used for example when Mod-elica models are evaluated from OMNotebook (see section 1.3.2).

1.3.2 OMNotebook

OMNotebook, the OpenModelica Notebook, is an application developed mainly by Ingemar Axelsson and Anders Fernstr¨om that provides an interactive envi-ronment where Modelica code and describing text can be combined according to Donald E. Knuth’s concept of Literate programming.[5]

1.4 Existing graphic functionality

OpenModelica already offers some ways to visualize simulation data. These rely upon an external program, PtPlot (see section 1.4.1), and are used by

(21)

1.4. Existing graphic functionality 5 invoking the command plot or plotParametric when a simulation has been run.

Figure 1.1: Simulation of a model

When a simulation command, simulate, is given from a cell in OMNote-book OMC is called through a CORBA connection (see figure 1.1). OMC then generates, compiles and executes an external program that performs the simulation and saves the results to a text file. If the simulation is com-pleted without errors, OMC returns the message done to OMNotebook. This message is then displayed in the cell that was used to send the simulation command.

Figure 1.2: Plotting of simulation results

When a plot command, plot or plotParametric, is given OMC is called as shown in figure 1.2. OMC then opens the file that was created during the simulation, reads simulation data for the variables that are specified in the call and writes this data to a new file, tmpPlot.plt. PtPlot is then called

(22)

6 Chapter 1. Introduction to generate a graph from the values in this file and save the result as a temporary image file. When this has been done OMC returns the answer done to OMNotebook. This causes the cell from which the command was given to open the temporary image file and add the contents to the active document.

1.4.1 PtPlot

PtPlot is a program for creating two-dimensional graphs developed by The Ptolemy Project[6]. The program is written in Java and can therefore be used on most platforms. PtPlot can generate many types of graphs, although OpenModelica currently uses only two-dimensional line diagrams.

1.4.2 OMNotebook

OMNotebook already has some support for displaying of simulation results. This is however limited, and allows no interactivity, as the implementation is based on image files generated by the external program PtPlot that are inserted into the document.

1.5 Purpose

OpenModelica has previously used the external program PtPlot for genera-tion of graphics from simulagenera-tion data. Although this program is well suited for this kind of tasks, this solution has some flaws. Firstly, PtPlot is writ-ten in Java, which means that the Java Virtual Machine has to be installed for OpenModelica to work as intended. Furthermore, integration with OM-Notebook is difficult which has led to the current situation where diagrams are treated as images. This makes interactivity, e.g. zooming, scaling or suchlike, impossible for diagrams that have been inserted into a document. Another problem, although smaller, is that when a plotting function is called from OMNotebook two versions of the resulting graph is displayed. One is inserted into the document and one is displayed in a new PtPlot window. A fourth problem is that the current implementation generates a lot of tempo-rary image files, which are not deleted when the program is closed. PtPlot is also available only from the API of OMC and can not be used from within Modelica models. This prevents for example models that create diagrams or other kinds of graphics.

(23)

1.6. Limitations 7

1.6 Limitations

This thesis will deal mainly with the most common types of diagrams, two-dimensional line diagrams and two-two-dimensional parametric diagrams, and variations of these. A more complete graphics package should for example contain more types of diagrams and provide means to create animations, but implementation of this kind of features will not be a part of this thesis.

1.7 Problem statement

In order to solve the problems mentioned above a new graphics package will be developed. Parts connected to OMNotebook will be developed in the same environment as this, i.e. in C++ and Qt. CORBA will still be used to send commands from OMNotebook to OMC, but instead of calling PtPlot to create diagrams OMC should send the simulation data to OMNotebook, which will handle the presentation (see figure 1.3). As OMNotebook now has access to all source data it will now be possible to manipulate diagrams, e.g. zoom or change scales.

To allow the use of graphics functions from within Modelica models a new Modelica interface will be developed. This will utilize an external library (see section 4.3.1) to communicate with OMNotebook. In addition to this, a number of new functions that can be used for drawing geometric objects like circles, rectangles and lines will be added.

(24)

8 Chapter 1. Introduction

1.8 Method

A new TCP/IP-based interface will be developed and used to transfer simu-lation data from OMC to OMNotebook. This will be built with socket classes from Qt and will also allow simulation data to be transferred during a run-ning simulation (see figure 1.4). Usage of Qt classes has some drawbacks, OMC will depend on Qt libraries for example, but there are also advantages. Qt provides, for instance, powerful ways to serialize data and sockets that can be used to transfer these data streams. Besides, Qt is already required to build OMNotebook and OMShell, and the necessary runtime libraries are already distributed with the OpenModelica setup program (for Windows).

Drawing of diagrams and other kinds of graphics will be done using the classes QGraphicsScene and QGraphicsView, which were introduced in Qt 4.2. These provides methods to create and present various kinds of graphic primitives, e.g. lines, circles and suchlike, but also more complex objects can be generated.

The work done during this thesis can be divided into four phases: analysis, studies, implementation and evaluation.

Figure 1.4: Data transfer during simulation

1.8.1 Analysis

In this phase the requirements were examined and methods to meet these were devised.

(25)

1.8. Method 9

1.8.2 Studies

Before the implementation could begin it was necessary to examine the work that had previously been done. The largest part of this phase was spent finding out how OMNotebook was structured and implemented, but also the tools used to develop OpenModelica were studied. These are mainly MetaModelica, which was introduced in a course given by PELAB, and Qt, which was studied by following tutorials on the Internet and by reading its excellent documentation.

1.8.3 Implementation

When some understanding of OMNotebook and the tools had been acquired the implementation could begin. First a simple variant of the new Input cell that could draw diagrams from the result files created by OMC was created. Together with other students, working in similar areas, the protocol for data transfer was then specified and finally the Modelica interface for the graphics package was developed.

1.8.4 Evaluation

When the implementation was finished, tests and evaluation could start. Of course, some tests had been done during the previous phases, but now everything was evaluated more thoroughly to find and remove the last bugs. The major parts of this report were also written during this phase.

(26)

(27)

Chapter 2 APIs and tools

Several tools and APIs have been used to develop the graphics package. The most important are presented in this chapter.

2.1 C++

C++ is the language in which most of the programming has been done. The main reason for this is that it has already been used to develop OMNotebook. In order to create a platform independent graphical user interface, C++ has been extended with the toolkit Qt (see section 2.2) from Trolltech[7]. Two C++ compilers are used in the OpenModelica project: Microsoft Visual C++ and GCC.

2.1.1 Microsoft Visual C++

Microsoft Visual C++[8] is used to compile OMC and OMNotebook in Win-dows environments. This leads to some problems, which are described in more detail in section 7.3, but the performance of the resulting executables are superior to those compiled with GCC.

2.1.2 GCC

In non-Windows environments GCC[9] is the only compiler used by Open-Modelica. GCC is however used even in Windows, as it is used by OMC to compile translated Modelica source files into simulation executables.

(28)

12 Chapter 2. APIs and tools

2.2 Qt

Qt is mainly a framework for development of graphical user interfaces, which has been used to develop the graphic parts of the graphics package as well as OMNotebook, but the toolkit also contains utility classes that for instance provide easy and object-oriented means of TCP/IP communication and han-dling of information stored as XML. As the new interface for data transfer was introduced, Qt became required even for OMC. It is still possible to build OMC without Qt though (see section 4.6.1), but large parts of the new functionality are then lost.

In the beginning of this project Qt 4.2 was released. This version in-troduced many new features, such as the new classes QGraphicsScene and QGraphicsView which replaced the old QCanvas class and made handling of large numbers of graphical objects and operations, such as scaling, of these easier. These classes are heavily used by the graphics package to present data. Some problems arose as the default behavior of some components were changed. Changes in the QTextBrowser class led to broken text links for example. The problems were identified and solved though.

When the work was almost completed a new version, 4.3, was released. This version did not introduce any new features of importance to the project, although some optimization of the graphics classes increased the performance of the graphics package, and no major changes were required to use it.

2.2.1 Widgets

An important term in development of graphical user interfaces, and conse-quently in the terminology of Qt, is widget. The term denotes a graphical element used for interaction or presentation of data, for instance a button or a text field. The term will be frequently used in this report, often refer-ring to the new widget that has been developed for the graphics package, GraphWidget (see section 4.4).

2.3 MetaModelica

MetaModelica is the language in which OMC is implemented, and therefore new additions such as new commands and interfaces for data transfer has been written in this language.

(29)

2.4. Doxygen 13

2.3.1 Eclipse

The default development environment for OMC is Eclipse[10], which together with the extension MDT (see section 2.3.2) provides an environment for development in MetaModelica.

2.3.2 MDT

MDT, Modelica Development Tooling[11], is an Eclipse extension that inte-grates OMC with Eclipse. MDT was originally created as part of a master’s thesis at PELAB and is since 2006 developed and maintained by Adrian Pop.

2.4 Doxygen

Doxygen is a tool capable of analyzing source code and generate documen-tation from its structure and comments. Many programming languages are supported and the resulting documentation can be generated in many for-mats, such as LA_{TEX or HTML. Doxygen is released under GPL and has}

previously been used to generate documentation for OMNotebook, which made it a good choice for this purpose.

2.5 L

A

_TEX

(30)

(31)

Chapter 3 Requirements

The main goal of this project is to extend the data visualization capabilities of OpenModlica. This will be accomplished by solving the problems of the current solution (se section 1.5), but also by introducing new ways to draw diagrams and other types of graphics from within Modelica models.

3.1 Interaction with OMNotebook

The graphics package that will be developed should be fully integrated with OMNotebook and allow modifications of diagrams that have been previously created.

3.2 Logarithmic scaling

Some applications of OpenModelica produce simulation data with large value ranges, which make it difficult to create good plots. One solution to this problem is to scale the diagram logarithmically, and this should be allowed by the graphics package.

3.3 Zoom

To allow studying of small variations the user should be allowed to zoom in and out in a diagram.

(32)

16 Chapter 3. Requirements

3.4 Support for graphic programming

To allow creation of Modelica models that are able to draw illustrations, show diagrams and suchlike it should be possible to use the graphics package not only from the external API of OMC, but also from within Modelica models. To accomplish this, a new Modelica interface for the graphics package will be created.

3.4.1 Modelica API

The Modelica API is defined by a number of Modelica functions, located in the package Modelica.Utils.Graph, which use external libraries to access functionality of the graphics package. These functions include the following:

plot(x) Draws a two-dimensional line diagram of x as a function of time. plotParametric(x,y) Draws a two-dimensional parametric diagram with y

as a function of x.

plotTable([x1, .., y1; .. ; xn, .., yn]) Draws a two-dimensional

paramet-ric diagram with y as a function of x.

drawRect(x1, x2, y1, y2) Draws a rectangle with vertices in (x1, y1) and

(x2, y2).

drawEllipse(x1, x2, y1, y2) Draws an ellipse with the size of a rectangle

with vertices in (x1, y1) and (x2, y2).

drawLine(x1, x2, y1, y2) Draws a line from (x1, y1) to (x2, y2).

3.5 Usage without OMNotebook

If the functionality of the graphics package is used without OMNotebook, a new window should be opened to present the resulting graphics.

(33)

Chapter 4 Design

This chapter describes the changes and additions that have been made to OMC and OMNotebook in order to implement the functionality of the graph-ics package. The changes can be divided into the following categories: exten-sions of OMC’s API, development of a widget for presentation of graphics, extensions of OMNotebook and development of an interface that allows Mod-elica models to communicate with a GraphWidget.

4.1 Extensions of OMC’s API

The API of OMC has been extended to provide new functionality. The modifications consists mainly of some new functions for data plotting and an interface for transfer of simulation data.

4.1.1 Plotting functions

These extensions consists of three commands. plot and plotParametric that replace the previous commands with the same names and plotAll. These can be used in a number of ways, depending on the arguments that are included with the call. The following calls are supported:

(34)

18 Chapter 4. Design Command Description

plot(x) Creates a diagram with data from the last simulation that had a variable named x plot({x,y, . . . , z}) Like the previous command, but with several

variables.

plot(model, x) Creates a diagram with data from the previ-ously simulated model model.

plot(model, {x, y, . . . , z}) Like the previous, but with several variables. plotParametric(x, y) Creates a parametric diagram with data from the last simulated variables named x and y. plotParametric(model, x, y) Creates a parametric diagram with data from

the previously simulated model model. plotAll() Creates a diagram with all variables from the

last simulated model as functions of time. plotAll(model) Creates a diagram with all variables from the

model model as functions of time.

All of these commands can have any number of optional arguments to further customize the resulting diagram. The available options and their allowed values are listed below.

(35)

4.1. Extensions of OMC’s API 19 Option Default value Description

grid true Determines whether or not a grid is shown in the diagram.

title ”Plot by Open-Modelica”

This text will be used as the diagram title.

interpolation ”linear” Determines if the simulation data should be interpolated to allow draw-ing of continuous lines in the diagram. ”linear” results in linear interpolation between data points, ”constant” keeps the value of the last known data point until a new one is found and ”none” re-sults in a diagram where only known data points are plotted.

legend true Determines whether or not the variable legend is shown.

points true Determines whether or not the data points should be indicated by a dot in the diagram.

logX false Determines whether or not the horizon-tal axis is logarithmically scaled. logY false Determines whether or not the vertical

axis is logarithmically scaled.

xRange {0, 0} Determines the horizontal interval that is visible in the diagram. {0, 0} will select a suitable range.

yRange {0, 0} Determines the vertical interval that is visible in the diagram. {0, 0} will select a suitable range.

antiAliasing false Determines whether or not anti-aliasing should be used in the diagram to improve the visual quality.

vTitle ”” This text will be used as the vertical label in the diagram.

hTitle ”time” This text will be used as the horizontal label in the diagram.

4.1.2 Data transfer functions

Two types of data transfer via TCP/IP have been implemented, one for sending generated simulation data during a running simulation and one for

(36)

20 Chapter 4. Design sending required data when specific commands, such as plot or plotPara-metric, are given. These types have many things in common, but both are required as it probably is desirable for instance to be able to plot data with-out having to run a previously run simulation again. The latter type also includes parameters that govern how the generated diagram will look.

TCP/IP communication is also used to implement the Modelica interface of the graphics package. This consists of functions like drawEllipse, which when evaluated will use a socket to send its parameters to a receiving Graph-Widget.

The different modes of data transfer are identified by a text string that is sent in the first package of a data stream. The following modes have been implemented:

Identifier Description

simulationDataStream Indicates that the following data stream contains simulation data that should be stored in the active GraphWidget for later use.

ptolemyDataStream Indicates that the following data stream contains simulation data and formatting information re-quired to immediately create a diagram.

drawEllipse Indicates that the package contains information necessary to draw an ellipse in the active Graph-Widget.

drawLine Like drawEllipse, but for a line. drawPoint Like drawEllipse, but for a point. drawRect Line drawEllipse, but for a rectangle.

drawText Indicates that the package contains information necessary to print text in the active GraphWid-get.

clear Indicates that the active GraphWidget should be reset.

closeServer Indicates that the active GraphWidget should stop listening on the current port. This is used to con-trol which GraphWidget that is considered active. hold Indicates that the active GraphWidget should not

be cleared before new graphics is shown.

The following commands have been added to the API of OMC in order to control the data transfer interface:

(37)

4.1. Extensions of OMC’s API 21

Command Description

enableSendData(Boolean) Determines whether or not simu-lation data should be transferred during simulation.

setDataPort(int) Determines which port the data transfer interface should use. setVariableFilter(”x1”, ”x2”, . . . , ”xn”) Determines the variables that

should have their values sent dur-ing simulation. An empty strdur-ing indicates that all variables will be sent.

4.1.3 Implementation

Many of the changes described above could not be (easily) implemented only by using the tools and libraries that have previously been used to develop OMC. This problem has been solved by the introduction of Qt, which is already used by OMNotebook and OMShell, in OMC. One area where Qt greatly simplifies implementation is handling of sockets. The classes QTcp-Socket can for instance be combined with a QDataStream, which in turn can be used to serialize common data types. This has been used in OMC, but also in the simulation executables that are generated by OMC when models are simulated.

4.1.4 Dependencies on external libraries

As OMC is compiled with Microsoft Visual C++ in Windows environments but uses GCC and MinGW internally to generate simulation executables, both Visual C++ and GCC versions of the necessary libraries have to be distributed with OpenModelica (see also section 7.3). The library file of the graphics package, libsendData.a (GCC) or sendData.lib (Visual C++), is generated when OMC is compiled and therefore causes no problems. Win-dows versions of OMC needs a version compiled with GCC to link with simulation executables, however. This file is included in the OpenModelica setup program and is placed in $OPENMODELICAHOME/lib.

To allow use of OpenModelica on computers without Qt, the setup pro-gram also includes the Qt runtime libraries QtCore4.dll, QtGui4.dll, Qt-Network4.dll and QtXml4.dll. OMNotebook requires Visual C++ compiled versions and these are copied to $OPENMODELICAHOME/bin. The sim-ulation executables need versions compiled with GCC, and these are placed

(38)

22 Chapter 4. Design in $OPENMODELICAHOME/lib. For non-Windows systems it is assumed that Qt is installed, or that OMC is compiled without Qt (see section 4.6.1 for information about how this can be done).

4.2 Data transfer protocol

A new TCP/IP-based protocol has been developed for transfer of simulation data from OMC to the GraphWidget where the data will be presented. Two versions of this have been implemented: one for transfer of general simulation data and one for transfer and plotting of simulation data.

4.2.1 Connection establishment

When OMC needs to send data to a GraphWidget, for instance if a command like plot or plotParametric is received or if enableSendData is set to true when a model is simulated, it will attempt to establish a TCP/IP connection to port 7778 (or the port set by setDataPort). If the attempt is unsuccessful, typically because no GraphWidget is active, the external program ext.exe is launched (see section 4.4.4 for more information) in order to provide a GraphWidget where graphics can be shown. This program will open a port and OMC will then connect to this. When the connection is established, the active socket is encapsulated in a QDataStream, which will be used to stream data to the GraphWidget.

4.2.2 Transfer of general simulation data

To allow real-time plotting and access of the generated simulation data with-out having to use the temporary text files that are generated during simula-tion, a new TCP/IP-based interface for data transfer has been implemented. The interface is controlled with three new commands, which have been added to the API of OMC (see section 4.1.2). The most important of these com-mands is enableSendData, which determines whether or not the interface is active.

If the interface is activated a simulation executable will, in addition to its normal behavior, use the procedure described in section 4.2.1 to establish a connection and create a data stream to the active GraphWidget. If this succeeds a text block of the following type will be sent through this.

(quint32) packet size

(39)

4.2. Data transfer protocol 23 packet size specifies the size of the text block in bytes and simulationData-Stream indicates that the following data is simulation data.

This packet is followed by a packet containing information about the variables that are present in the current simulation.

(quint32) number of variables (QString) variable name 1 (QString) variable name 2 ...

(QString) variable name N

This is followed by packets containing simulation data. These packages have the following structure:

(quint32) number of variables in this package (QString) variable name 1

(double) variable value 1 ...

(QString) variable name M (double) variable value M

This is continues until all simulation data has been transferred. The connec-tion is then closed.

To decrease the amount of data that will be transferred from OMC to the GraphWidget, and thereby reduce the time needed for simulation, the com-mand setVariableFilter can be used to specify the interesting variables. An example of how this is done is given in section 9.3.

4.2.3 Transfer of plot data

When OMC receives the command simulate the simulation of the current model is initiated. The resulting simulation data is saved to a text file, <model name> res.plt. This file contains all variables that are used in the model and the values of these at different points of time. For instance, the command

simulate(HelloWorld, startTime=0, stopTime=4, numberOfIntervals=5)

where HelloWorld is the model described in DrModelica (see section A.1) results in the file HelloWorld res.plt containing the following data:

(40)

24 Chapter 4. Design

#Ptolemy Plot file, generated by OpenModelica #IntervalSize=6

TitleText: OpenModelica simulation plot XLabel: t DataSet: time 0, 0 4.440892098500626e-013, 4.440892098500626e-013 1, 1 2, 2 3, 3 4, 4 DataSet: \$dummy 0, 0 4.440892098500626e-013, 6.195809498454399e-023 1, 6.587035426124279e-010 2, 1.028416866697914e-009 3, -1.848214280261971e-009 4, 6.582600943470397e-010 DataSet: x 0, 1 4.440892098500626e-013, 0.9999999999995559 1, 0.3678794411714217 2, 0.1353352832366026 3, 0.04978706836785558 4, 0.01831563888872685 DataSet: der(\$dummy) 0, 0 4.440892098500626e-013, 2.790294798402648e-010 1, 8.626821481276044e-007 2, 7.316559642568771e-007 3, 8.650298917026885e-007 4, 8.534901463235358e-007 DataSet: der(x) 0, -1 4.440892098500626e-013, -0.9999999999995559 1, -0.3678794411714217 2, -0.1353352832366025 3, -0.04978706836785558 4, -0.01831563888872684

When OMC receives a plot or plotParametric command, a data stream is cre-ated as described in section 4.2.1. Simulation data from the files mentioned above are then read and sent to the active GraphWidget through this. If a model name is provided as an argument to the command OMC will try to

(41)

4.2. Data transfer protocol 25 open the file <model name> res.plt. If no model name is given the result file from the last simulated model will be used.

The previously created QDataStream object is now used to transfer the simulation data. The structure of the data stream is described below. First a quint32 (a 32-bit unsigned integer) with the size of the packet is sent. This is followed by a text string (QString), which states the purpose of the data stream (see section 4.1.2 for descriptions of the different modes of data transfer). For plot or plotParametric this identifier is ptolemyDataStream.

(QString) "ptolemyDataStream"

This package is followed by a package containing information about the set-tings that have been specified by optional parameters, or default setset-tings if no parameters are provided.

(quint32) packet size (QString) diagram title (QString) vertical title (QString) horizontal title (int) variabelnamn (int) grid (double) xMin (double) xMax (double) yMin (double) yMax (int) logX (int) logy (QString) interpolation (int) data points

(quint32) number of variables (QString) variable name 1 (QColor) colour 1

...

(QString) variable name N (QColor) colour N

This package is followed by packages containing simulation data. These have the following structure:

(42)

26 Chapter 4. Design (QString) variable name 1

(double) variable value 1 ...

(QString) variable name M (double) variable value M

When all simulation data has been transferred the connection is closed..

4.3 Modelica interface

To allow access of functions of the graphics package from Modelica models a new Modelica interface has been developed. This consists of a set of Mod-elica functions that uses OMC’s ability to link simulation executables with external libraries written in other languages (see section 4.3.1).

4.3.1 External functions

When OMC builds the simulation executables, the source files are first con-verted to c and then compiled to object files. These files are then linked to an executable program. Also external libraries can be included in this step. This is done with Library annotations (see section 4.3.2), and makes it possible to use functionality implemented in languages other than Modelica in simulation executables. An example of how this linking can be used is given below, where a function that calculates factorials is written in c and then encapsulated in a Modelica function.

Assume that the following c function is compiled into the object file facto-rial.o int factorial(int i) { if(i == 1) return 1; else return i*factorial(i-1); }

This object file can then be included in Modelica functions by using the keyword external. The name of the library file is specified by a Library annotation. In this case by annotation(Library=”factorial.o”). 1

1_{The value of the Library parameter is actually just a text string that will be passed to}

the linker when the simulation executable is linked, which means that also more advanced expressions can be used. The graphics package uses this to for instance specify paths and include more than one external library at a time. See appendix B for examples of this.

(43)

4.3. Modelica interface 27

function factorial input Integer i; output Integer j;

external "C" j = factorial(i) annotation(Library = "factorial.o"); end factorial;

4.3.2 Annotations

A Modelica annotation is extra information associated with a Modelica model. This additional information is used by Modelica environments, e.g., for sup-porting documentation or graphical model editing. Most annotations do not influence the execution of a simulation, i.e., the same results should be ob-tained even if the annotations are removed - but there are exceptions to this rule. The syntax of an annotation is as follows:

annotation(annotation_elements)

where annotation elements is a comma-separated list of annotation elements that can be any kind of expression compatible with the Modelica syntax.[2]

4.3.3 Functions

The methods described in section 4.3.1 have been used to create the Mod-elica interface, which uses functions written i C++ and Qt to handle the communication with GraphWidgets. To avoid name conflicts, the functions have been put in the package Modelica.Graphics.Plot. The functions of the Modelica interface are described below.

(44)

28 Chapter 4. Design Function Description

plot(model, ”x”) Creates a diagram with data from the variable x in the previously sim-ulated model model.

plot(model, ”x, y”) Like the function above, but with more than one variable.

plotParametric(model, ”x”, ”y”) Creates a parametric diagram with data from the variables x and y in the previously simulated model model.

plotTable([x1, y1, z1, ...; x2, y2,

z2, ...;...])

Draws y and z as functions of x.

clear() Clears the active GraphWidget. line(x0, y0, x1, y1) Draws a line from the point (x0, y0)

to the point (x1, y1) in the active

GraphWidget.

rect(x0, y0, x1, y1) Draws a rectangle with vertices in

the points (x0, y0) and (x1, y1) in

the active GraphWidget.

ellipse(x0, y0, x1, y1) Draws an ellipse with the size of a

rectangle with vertices in the points (x0, y0) and (x1, y1) in the active

GraphWidget.

hold(Boolean on) Determines whether or not the ac-tive GraphWidget should be cleared before new graphics are drawn. wait(ms) Waits for (at least) ms milliseconds.

The plot and plotParametric commands also support the optional customiza-tion arguments described in seccustomiza-tion 4.1.1. The commands for geometric shapes all have optional arguments that further specify how the resulting object will look. The arguments are described below.

(45)

4.4. GraphWidget 29 Argument Default value Description

color ”transparent” Determines the fill color of the ob-ject. Valid values are transparent, white, black, green, yellow, red, blue etc. colorRGB {-1, -1, -1} Determines the fill color of the object by RGB values. If all components are non-negative this color will be used rather than the one specified by the color argument.

lineColor ”black” Likt color, but for the line color of the object.

lineColorRGB {-1, -1, -1} Like colorRGB, but for the line color of the object.

The complete implementation of the Modelica interface of the graphics pack-age is presented in appendix B.

4.4 GraphWidget

GraphWidget is the name of the new widget (see section 2.2.1) that has been developed to create and present graphics. GraphWidget is derived from the Qt class QGraphicsView and thereby inherits an area where graphics can be drawn. In addition to this, functionality has been added for instance to handle TCP/IP communication with OMC.

4.4.1 Reception of simulation data

Reception of simulation data will occur if the word simulationDataStream is the first in the identifying package sent by OMC (see also section 4.2.2). The values that are received are stored internally in the active GraphWidget and can later be used for data plotting by clicking on Simulation data in the context menu of the GraphWidget or by clicking the button D, which appears to the right of the input field when the simulation data has been transferred. See also section 9.3 for an example of this.

4.4.2 Drawing of diagrams

Drawing of diagrams can be initiated in two ways. Either by sending com-mands like plot or plotParametric to OMC, which responds by sending a data stream described in section 4.2.3, or by using the dialog Simulation data to

(46)

30 Chapter 4. Design create diagrams from simulation data stored in the GraphWidget (see section 8.1.4).

4.4.2.1 Drawing from a data stream

If the identifying keyword of the data stream from OMC is ptolemyDataS-tream, a diagram will be created instantly from the sptolemyDataS-tream, which besides simulation data contains variable names, diagram titles and other informa-tion necessary to generate a plot. For each pair of x and y variables, typically a time value and a variable value of that time, a QGraphicsEllipseItem object is created and inserted into the QGraphicsScene object of the GraphWidget. The visibility of this object is controlled by the drawPoints parameter of the plot command. If a previous data point has been received, QGraphicsLine objects are then created to connect the two most recent data points according to the interpolation mode that is selected (see section 4.1.1). The visibility of these lines is determined by the drawLine parameter. The received simula-tion data is also stored internally in the GraphWidget and can later be used for instance to create new curves or to scale the diagram logarithmically.

4.4.2.2 Drawing from stored data

This procedure is essentially identical to that described in section 4.4.2.1. The data that is used is however not received through a data stream but instead taken from internal tables, where it has previously been stored.

4.4.3 Drawing of geometrical objects

The commands provided by the Modelica interface for drawing of geometrical objects require, unlike the plot and plotParametric commands, no simulation data to be sent. All necessary information is given as parameters (default values are used if no values are specified). When OMC receives a command like this, a data stream is created as described in section 4.2.1, and the parameters are sent through this in a packet like the following.

(QString) id (double) x0 (double) y0 (double) x1 (double) y1 (QColor) color (QColor) fill color

(47)

4.5. OMNotebook 31 The string id specifies the purpose of the transmission. See section 4.1.2 for a list of possible values.

4.4.4 External use

As the GraphWidget is a widget, it is easy to use in applications other than OMNotebook. This has been used to enable presentation of diagrams when functions of the graphics package are used from other applications than OMNotebook, for instance by running a script. If a command like plot or plotParametric is given, or if a model using functions of the graphics package is simulated it is desirable that a window showing the diagram is displayed even if OMNotebook is not running. This problem has been solved by devel-oping new application, ext.exe2_{, which is essentially just a GraphWidget in}

a dialog window.

This application will be launched if OMC fails to connect to a Graph-Widget when a command of the graphics package has been received. See section 4.2.1 for more information about this.

4.5 OMNotebook

Most of the changes that have been made to OMNotebook are related to the new cell type, the new Input cell. This cell type is an extended version of the old Input cell and uses a GraphWidget to allow generation and presentation of diagrams and other graphics. Some smaller changes have also been done. The file format has been modified, the user interface has been updated and some bugs have been resolved.

4.5.1 The new Input cell

The new Input cell looks like the old Input cell, which it extends, but differs in a number of ways. The most important addition is the ability to receive data from OMC and from this create and show diagrams and other graphics, which has been implemented by embedding a GraphWidget (see section 4.4 for more information about this) into the cell. Other changes have also been made though. A cursor position indicator has been added for instance, and basic support for indentation of Modelica code has been implemented.

2_{The name ext.exe has been selected to make execution easier in Windows}

environ-ments. In environments supporting this, the application will be marked as executable when it is compiled. Windows, howerver, requires that the name of the executable has the suffix .exe

(48)

32 Chapter 4. Design The new Input cell is by the way fully compatible with the old Input cell, which means that Input cells in old documents can be easily converted to new Input cells in order to make use of the new functionality. The old Input cell has therefore been replaced by. The name Input cell has been kept though, as it nicely describes the function of the cell.

4.5.2 File format

OMNotebook uses a XML-based file format to store its documents. The format is hierarchical and every type of cell can store for it specific data. The following is an example of the format given by Anders Fernstr¨om[12].

<!DOCTYPE OMNotebook> <Notebook> <GroupCell closed="false"> <TextCell style="Title"> <Text>(...html code...)</Text> </TextCell> <TextCell style="Text"> <Text>(...html code...)</Text> <Rule name="(...name...)">(...value...)</Rule> <Rule name="(...name...)">(...value...)</Rule> <Image name="(...name...)">(...data...)</Image> <Image name="(...name...)">(...data...)</Image> </TextCell>

<InputCell style="Input" closed="false"> <Input>(...text...)</Input> <Output>(...output data...)</Output> <Image name="(...name...)">(...data...)</Image> </InputCell> </GroupCell> </Notebook>

Interesting in this example are the lines

<Output>(...output data...)</Output>

These lines represent an Input cell and consists of the opening tag InputCell, a number of named properties of the cell that has been saved and finally the closing tag /InputCell.

The new Input cell saves data in a similar way. This type of cell is however more complex than the Input cell and requires for example that simulation data that has been received from OMC is saved. An exemple of how a new Input cell is represented is shown below.

(49)

4.5. OMNotebook 33

<InputCell MajorY="0.2" LogX="false" Title="Plot by OpenModelica" MinorX="0.1" LogY="false" Grid="true" MinorY="0.04" AutoX="true" AutoY="true" Antialiasing="false" style="" Area="...data..."

closed="false" YLabel="" Legend="true" XLabel="time" MajorX="0.5" > <Data Id="0" Label="time" > ...data... </Data>

Some information, such as source data for the variables time and x and information about which area that is currently zoomed in, has been replaced with ...data... to save space. This information is, like image data, stored as base64-encoded binary data. The information stored is:

Name Description

MajorY The size of the vertical divisions of the grid. LogX Logarithmic scaling of the horizontal axis. Title The title of the diagram.

MinorX The size of the horizontal subdivisions of the grid. LogY Logarithmic scaling of the vertical axis.

Grid Visibility of the grid.

MinorY The size of the vertical subdivisions of the grid. AutoX Automatic scale for the horizontal grid.

AutoY Automatic scale for the vertical grid. Antialiasing Anti-aliasing of the diagram.

Area Base64-encoded information about the area that is shown in the diagram.

closed Determines whether or not the diagram part of the cell is shown.

YLabel The title of the vertical axis.

Legend Determines whether or not the variable legend is shown. XLabel The title of the horizontal axis.

MajorX The size of the horizontal divisions of the grid.

These are followed by Data elements, which represent the source data that have been sent from OMC. The variables are, together with id numbers and variable names, stored as Base64-encoded binary information. The Data elements are followed by Graph elements, which use the id numbers to pair the variables together. The example above shows for instance that the Input cell contains a curve where the data element with id number 0 is used as X

(50)

34 Chapter 4. Design variable and the data element with id number 1 is used as Y variable. The Graph element also stores the color that is used, which type of interpolation that is selected and whether or not data points and the interpolation line are visible.

4.5.3 Printing

When a document is printed from OMNotebook, a temporary document is first created. Text and images are then copied from the active document to this and the built-in function print is called to perform the printing. This works well with the documents that have previously been created in OM-Notebook, as they were limited to text, possibly formatted, and images and were thereby fully compatible with the QTextDocument class. The new Input cell, however, can not be reduced to something that can easily be described with the HTML-based formatting language of the QTextDocument class. The built in function for printing of documents can therefore not be used directly. This problem has been solved by rendering Input cells to images and then include these image files in the temporary document before it is printed. As images are supported by the QTextDocument class the print command can now be used as before.

4.5.4 Other changes

Some parts of OMNotebook have been updated to correct bugs that have been found or introduced, for example by new versions of Qt, or to introduce new functionality. These changes include the following.

4.5.4.1 Recent Files

A new submenu, Recent files, has been added to the File menu. This shows recently used OMNotebook documents and allow easy access of these.

4.5.4.2 Toolbar

To allow quick access of common functions, such as opening and saving of files, cut & paste etc., a toolbar has been added to OMNotebook.

4.5.4.3 Compressed file format

The introduction of the new Input cell also entails storing of the simulation data that is necessary to create the diagrams that are included in the docu-ment. This can, depending on how long or detailed the performed simulations

(51)

4.6. Design problems 35 are, make the size of the saved documents significantly larger than in previ-ous versions of OMNotebook. To reduce these problems, support for a new compressed file format, .onbz, has been introduced. The only difference from the normal format, .onb, is that the built in support for zlib compression in Qt has been used to compress the contained data. Some of the advantages of using an XML-based file format is lost by this however, as the files will no longer be easily readable by humans. This problem existed even before, to a lesser degree, as for instance images were saved as binary data.

As OMNotebook documents often contain lots of text, the reduction of file sizes can often be significant. The table below shows the file sizes of three documents, DrModelica, VanDerPol and HelloWorld, saved in the different formats.

Document onb [kB] onbz [kB] DrModelica 222 18

HelloWorld 16 8 VanDerPol 17 9

The size of documents that contain lots of text, as DrModelica, can be re-duced many times while documents dominated by simulation data can be compressed to approximately half their original size. The reason is proba-bly that the binary representation of the simulation data already is quite efficient.

4.6 Design problems

This section will discuss problems caused by the design.

4.6.1 Qt dependencies

It has previously been said that OMNotebook is perhaps too dependent on Qt[13][12]. The development of this graphics package has not improved the situation. Furthermore, Qt dependencies have been introduced even to OMC. This should not create any problems on computers where OMNotebook is already used, as the same runtime libraries are used, but might be a problem on systems where Qt is not installed. OMC can be configured to be compiled without Qt however, but then most of the functionality introduced by the graphics package is lost. To compile OMC without Qt, make sure that the environment variable QTHOME is undefined during compilation.

(52)

36 Chapter 4. Design

4.6.2 Zooming performance

If data points are visible in a diagram when zooming is applied, these have to be resized and moved to maintain correct sizes and positions. This is in most cases not a problem when zooming in, as the number of data points in the new area are often small. When zooming out however, especially when resetting to the original zoom level, all data points have to be processed, which might require a large part of the time required for this operation. This problem can perhaps be solved by using new features of Qt (see section 7.4 for more information about this).

(53)

Chapter 5 Evaluation

In order to determine if the diagrams that are generated by the graphics package are correct, comparisons with diagrams generated by PtPlot have been made. Three of them will be presented in this chapter: a time plot, a time plot with more than one variable and a parametric diagram. The models that will be used to generate simulation data are HelloWorld and VanDerPol.

5.1 Time plot

To create a simple time plot the model HelloWorld defined in DrModelica is simulated. To reduce the amount of simulation data the number of intervals is limited with the argument numberOfIntervals=10. The simulation is started with the command below.

simulate(HelloWorld, startTime=0, stopTime=4, numberOfIntervals=10);

When the simulation is finished the file HelloWorld res.plt contains the sim-ulation data. The contents of the file is the following (some formatting has been applied).

(54)

38 Chapter 5. Evaluation Time Value 0 1 4.440892098500626e-013 0.9999999999995559 0.4444444444444444 0.6411803884299349 0.8888888888888888 0.411112290507163 1.333333333333333 0.2635971381157249 1.777777777777778 0.1690133154060587 2.222222222222222 0.1083680232218813 2.666666666666667 0.06948345122279623 3.111111111111112 0.04455142624447787 3.555555555555556 0.02856550078454138 4 0.01831563888872685

Diagrams are now created with both PtPlot and the new graphics package by using the following command.

plot(x);

The diagrams, shown in figure 5.1, seems to correspond well with each other, and with the data from the result file. The diagram created by the graphics package is then magnified about the point (2.222, 0.1083) to allow a more detailed comparison with the source data. The result is shown in figure 5.2. As can be seen in the diagram, the data point seems to be located where it should.

5.2 Time plot with multiple variables

To compare time plots with multiple variables, the model VanDerPol from DrModelica is used. As in the previous test, the number of intervals is limited to ten. The following command is used to simulate the model.

simulate(VanDerPol, startTime=0, stopTime=20, numberOfIntervals=10);

(55)

5.2. Time plot with multiple variables 39

Figure 5.1: Diagram generated by PtPlot (top) and the new graphics package (bottom)

(56)

40 Chapter 5. Evaluation Time x y 0 1 1 4.440892098500626e-013 1.000000000000444 0.9999999999995559 2.5 -0.2872466150239476 -1.621414776691852 5 -0.759457035812578 1.430077085013957 7.5 1.595500922011536 -0.8452457315733301 10 -1.934781983084742 -0.1250671716518284 12.5 1.413583393480123 1.589251894042807 15 -0.1415264955095855 -2.038355765155822 17.5 -1.040247557317524 1.489255085293868 20 1.797484311949717 -0.7717972011848642 22.5 -1.966454874188533 -0.3814020027103569 25 1.205795807179632 1.839024158929212

Diagrams were then generated with the command

plot({x, y});

The results are shown in figure 5.3.

The diagrams seem to correspond well in this case too.

5.3 Parametric diagrams

Finally the two versions of parametric diagrams are compared. Like in the last test, the model VanDerPol from DrModelica is used to generate simu-lation data. The diagrams were created with the following command.

plotParametric(x, y)

The results are shown in figure 5.4.

The diagrams seem to be quite similar here too.

5.4 Drawing of geometrical objects

Drawing of geometrical objects from Modelica models is supposed to be useful for instance to illustrate simulations of models such as Game of Life, in which shapes like rectangles could be used to indicate the living cells. This does not work yet however. The problems lies not in the graphics package though, but rather in limitations of OMC, which currently lacks some functionality needed to simulate models of this kind.

(57)

5.4. Drawing of geometrical objects 41

Figure 5.3: Diagram generated by PtPlot (top) and by the new graphics package (bottom)

5.4.1 Introduction to Game of Life

The Game of Life is a cellular automaton, a kind of discrete simulation, invented by John Conway that was introduced in Scientific American in 1970[14]. The simulation consists of a two-dimensional space divided into cells, an initial state with a distribution of ”living” cells and a set of rules. Every state can, by use of these rules, be transformed into a new state. The most commonly used rules are listed below.

• A living cell with less than two neighbors dies. • A living cell with more than three neighbors dies. • A cell with two or three neighbors is unchanged. • A dead cell with three neighbors is revived.

(58)

42 Chapter 5. Evaluation

Figure 5.4: Diagram generated by PtPlot (top) and by the new graphics package (bottom)

5.4.2 Problems with Game of Life simulations

A Game of Life model should be pretty simple to create. A matrix of Boolean values could be used to represent the states of the cells and a loop could then be used to apply the rules to each cell in order to transform the current state to the next. The implementation of this requires that the previous values of the state matrix are accessible at any given time. Modelica has a keyword for situations like these, pre. OMC does however not support this for use with matrices at the time of writing of this report, which makes implementations of this kind impossible (or hard at least). Another limitation is that for loops in algorithm sections of Modelica models is currently not supported by OMC. These limitations have prevented interesting tests to be performed. In-stead simple models like the following have been used to evaluate the behavior of the functions.

(59)

5.4. Drawing of geometrical objects 43 parameter Integer n=10; protected Boolean b[n,n]; equation for x in 1:n loop for y in 1:n loop

when initial() then

if((y == 1) or (y == 10) or (x == 1) or (x == 10)) then b[x,y] = pltpkg.rect(x, y, x+1, y+1, fillColor = "blue", color = "green");

else if(y >= 4 and y <= 5 and x >= 4 and x <= 5) then b[x,y] = pltpkg.line(x, y, x+1, y+1, color = "red"); else

b[x,y] = pltpkg.ellipse(x, y, x+1, y+1, fillColor = "yellow", color = "black"); end if; end if; end when; end for; end for; end testGeom;

This seems to work as intended however, as is shown in figure 5.5.

(60)

(61)

Chapter 6 Related work

6.1 Martin Otter’s graphics package

When this thesis was almost completed a similar package (henceforth ref-erenced as package B) was presented by Prof. Martin Otter at Institute of Robotics and Mechatronics DLR Research Center in Oberpfaffenhofen. This was implemented in the simulation environment Dymola by Dynasim[15] and had functions for plotting of table data from a model or from file and a nice way of organizing window properties.

6.2 Compatibility

To adapt the graphics package of this thesis (package A) and make it compat-ible with package B should mainly require variable names to be changed, but some features requires further development of OMC to work. The following example is given by Martin Otter and shows some of these.

function demoPlotTable_OneWindow

"Demonstrate plotting of plotTable with one sub window" import Modelica_Plot; protected Real lossTable[:,5]= [ 0, 0.95, 0.92, 20, 25; 10, 0.94, 0.92, 23, 28; 20, 0.92, 0.92, 32, 35; 30, 0.90, 0.91, 43, 46; 40, 0.90, 0.90, 56, 60]; algorithm Modelica_Plot.plotTable(table=lossTable,

columnLabels={"w_a [rad/s]", "eta_mf1", "eta_mf2", "tau_bf1", "tau_bf2"}, subWindows={0,0,0,1,1},windowProperties=

Advanced OpenModelica plotting package for Modelica

Institutionen för datavetenskap

Department of Computer and Information Science

Final thesis

Advanced OpenModelica plotting package for

Modelica

Henrik Eriksson

LIU-IDA/LITH-EX-A -- 08/036 -- SE

2008-06-22

Final thesis

Advanced OpenModelica plotting package for

Modelica

by

Henrik Eriksson

Abstract

Acknowledgements

Contents

List of Figures

Chapter 1

Introduction

1.1

Overview

1.2

Modelica

1.3

OpenModelica

1.3.1

OMC

1.3.2

OMNotebook

1.4

Existing graphic functionality

1.4.1

PtPlot

1.4.2

OMNotebook

1.5

Purpose

1.6

Limitations

1.7

Problem statement

1.8

Method

1.8.1

Analysis

1.8.2

Studies

1.8.3

Implementation

1.8.4

Evaluation

Chapter 2

APIs and tools

2.1

C++

2.1.1

Microsoft Visual C++

2.1.2

GCC

2.2

Qt

2.2.1

Widgets

2.3

MetaModelica

2.3.1

Eclipse

2.3.2

MDT

2.4

Doxygen

2.5

L

TEX

Chapter 3

Requirements

3.1

Interaction with OMNotebook

3.2

_TEX