The 
Mathematica Journal
Volume 10, Issue 1

Search

In This Issue
Articles
Trott's Corner
New Products
New Publications
Calendar
News Bulletins
New Resources
Classifieds

Download This Issue 

About the Journal
Editorial Policy
Staff and Contributors
Submissions
Subscriptions
Advertising
Back Issues
Contact Information

MathModelica--An Object-Oriented Mathematical Modeling and Simulation Environment
Peter Fritzson

1. Background

Traditionally, simulation and accompanying activities [1] have been expressed using heterogeneous media and tools, with a mixture of manual and computer-supported activities:

  • A simulation model is traditionally designed on paper using traditional mathematical notation.
  • Simulation programs are written in a low-level programming language and stored on text files.
  • Input and output data, if stored at all, are saved in proprietary formats needed for particular applications and numerical libraries.
  • Documentation is written on paper or in separate files that are not integrated with the program files.
  • The graphical results are printed on paper or saved using proprietary formats.

When the result of the research and experiments, such as a scientific paper, is written, the user normally gathers together input data, algorithms, and output data and its visualizations, as well as notes and descriptions. One of the major problems in simulation development environments is that gathering and maintaining correct versions of all these components from various files and formats is difficult and error-prone.

Our vision of a solution to this set of problems is to provide integrated computer-supported modeling and simulation environments that enable the user to work effectively and flexibly with simulations. Users would then be able to prepare and run simulations as well as investigate simulation results. Several auxiliary activities accompany simulation experiments: requirements are specified, models are designed, documentation is associated with appropriate places in the models, and input and output data, as well as possible constraints on such data, are documented and stored together with the simulation model. The user should be able to reproduce experimental results. Therefore input data and parts of output data as well as the experimenter's notes should be stored for future analysis.

1.1. Integrated Interactive Programming Environments

An integrated interactive modeling and simulation environment is a special case of programming environment with applications in modeling and simulation. Thus, it should fulfill the requirements from both general integrated programming environments and the application area of modeling and simulation mentioned in the previous section.

The main idea of an integrated programming environment in general is that a number of programming support functions should be available within the same tool in a well integrated way. This means that the functions should operate on the same data and program representations and exchange information when necessary, resulting in an environment that is both powerful and easy to use. An environment is interactive and incremental if it gives quick feedback (e.g., without recomputing everything from scratch) and maintains a dialogue with the user, including preserving the state of previous interactions with the user. Interactive environments are typically both more productive and more fun to use.

There are many things that a programming environment should accomplish for the programmer, particularly if it is interactive. What functionality should be included? Comprehensive software development environments are expected to provide support for the major development phases, such as

  • requirements analysis
  • design
  • implementation
  • maintenance

A programming environment can be somewhat more restrictive and need not necessarily support early phases such as requirements analysis, but it is an advantage if such facilities are also included. The main point is to provide as much computer support as possible for different aspects of software development and to free the developer from mundane tasks so that more time and effort can be spent on the essential issues. The following is a partial list of integrated programming environment facilities, some of which are already mentioned in [2], that should be provided for the programmer:

  • Administration and configuration management of program modules and classes, and different versions of these.
  • Administration and maintenance of test examples and their correct results.
  • Administration and maintenance of formal or informal documentation of program parts, and automatic generation of documentation from programs.
  • Support for a given top-down or bottom-up programming methodology. For example, if a top-down approach should be encouraged, it is natural for the interactive environment to maintain successive composition steps and mutual references between those.
  • Support for the interactive session. For example, previous interactions should be saved in an appropriate way so that the user can refer to previous commands or results, go back and edit those, and possibly re-execute.
  • Enhanced editing support, performed by an editor that knows about the syntactic structure of the language. It is advantageous if the system allows editing of the program in different views. For example, editing of the overall system structure can be done in the graphical view, whereas editing of detailed properties can be done in the textual view.
  • Cross-referencing and query facilities, to help the user understand interdependences between parts of large systems.
  • Flexibility and extensibility (e.g., mechanisms to extend the syntax and semantics of the programming language representation and the functionality built into the environment).
  • Accessible internal representation of programs. This is often a prerequisite to the extensibility requirement. This means that there is a well-defined representation of programs as data structures in the programming language itself, so that user-written programs may inspect the structure and generate new programs. This property is also known as the principle of program-data equivalence.

1.2. Vision of Integrated Interactive Environment for Modeling and Simulation

Our vision for the MathModelica integrated interactive environment is to fulfill essentially all the requirements for general integrated interactive environments combined with the specific needs for modeling and simulation environments, such as

  • specification of requirements, expressed as documentation and/or mathematics
  • design of the mathematical model
  • symbolic transformations of the mathematical model
  • a uniform general language for model design, mathematics, and transformations
  • automatic generation of efficient simulation code
  • execution of simulations
  • evaluation and documentation of numerical experiments
  • graphical presentation

The design and vision of MathModelica is to a large extent based on our earlier experience in research and development of integrated incremental programming environments (e.g., the DICE system [3] and the ObjectMath environment [4, 5]) and many years of intensive use of advanced integrated interactive environments such as the Interlisp system [2, 6, 7], and Mathematica [8, 9]. The Interlisp system was actually one of the first really powerful integrated environments and still exceeds most current programming environments in terms of powerful facilities available to the programmer. It was also the first environment that used graphical window systems in an effective way [10] (e.g., before the Smalltalk environment [11] and the Macintosh window system appeared).

Mathematica, which has been available since 1988, is an integrated interactive programming environment with many similarities to Interlisp, containing comprehensive programming and documentation facilities, accessible intermediate representation with program-data equivalence, graphics, and support for mathematics and computer algebra. Mathematica is more developed than Interlisp in several areas (e.g., syntax, documentation, and pattern matching), but less so in programming support facilities.

1.3. Mathematica, Modelica, and MathModelica

It turns out that Mathematica is an integrated programming environment that fulfils many of our requirements. However, it lacks object-oriented modeling and structuring facilities as well as generation of efficient simulation code needed for effective modeling and simulation of large systems. These modeling and simulation facilities are provided by the object-oriented modeling language Modelica [12, 13, 14, 15, 16, 17, 18, 19].

Our solution to the problem of a comprehensive modeling and simulation environment is to combine Mathematica and Modelica into an integrated interactive environment called MathModelica. This environment provides an internal representation of Modelica that builds on and extends the standard Mathematica representation, which makes it well integrated with the rest of the Mathematica system.

The realization of the general goal of a uniform general language for model design, mathematics, and symbolic transformations is based on an integration of the two languages Mathematica and Modelica into an even more powerful language. This language is Modelica in Mathematica syntax, extended with a subset of Mathematica. Only the Modelica subset of MathModelica can be used for object-oriented modeling and simulation, whereas the Mathematica part of the language can be used for interactive scripting and symbolic transformations.

Mathematica provides representation of mathematics and facilities for programming symbolic transformations, whereas Modelica provides language elements and structuring facilities for object-oriented component based modeling, including a strong type system for efficient code and engineering safety. However, this language integration is not yet realized to its full potential in the current release of MathModelica, even though the current level of integration provides many impressive capabilities. Future improvements of the MathModelica language integration might include making the object-oriented facilities of Modelica are also available for ordinary Mathematica programming, as well as making some of the Mathematica language constructs available within code for simulation models.

The current MathModelica system builds on experience from the design of the ObjectMath [4, 5] modeling language and environment, early Modelica prototypes [20, 21], as well as results from object-oriented modeling languages and systems such as Dymola [22, 23] and Omola [24, 25], which together with ObjectMath and a few other object-oriented modeling languages (e.g., [26, 27, 28, 29, 30]) have provided the basis for the design of Modelica.

ObjectMath was originally designed as an object-oriented extension of Mathematica augmented with efficient code generation and a graphic class browser. The ObjectMath effort was initiated in 1989 and concluded in the fall of 1996 when the Modelica Design Group was started and later renamed the Modelica Association. At that time, instead of developing a fifth version of ObjectMath, we decided to join forces with the originators of a number of other object-oriented mathematical modeling languages in creating the Modelica language, with the ambition of eventually making it an international standard. In many ways the MathModelica product can be seen as a logical successor to the ObjectMath research prototype.



     
About Mathematica | Download Mathematica Player
© Wolfram Media, Inc. All rights reserved.