Mechanomy

Software for Pre-CAD systems design

Solving Modelica Models

Modelica

Continuing our tour, let's take a quick dive through the steps required to solve a Modelica model and simulate the system it describes.

First is the model text, the Modelica code you write to describe elements of your system and their interaction. Avoiding ambiguity requires strict adherence to the Modelica language specification, which in turn is developed by the Modelica Association to be able to model many different systems. The language has strengths and weaknesses, as do the standard model libraries, but the important part is that the language is standardized and versioned, allowing models to be written without strict dependence on the software tool used for writing them. And even when the model is primarily composed through a graphical layer, the underlying file format is text based and easily human readable.

To simulate a given model file, the tool will first check the syntax for adherence to the language specification, no rule-breaking allowed. If the text is syntactically correct, the next major step is to perform a symbolic simplification of the system. This step combines the equations in your model file and any referenced libraries into a single mathematical description of the system. This description often contains redundancies, that is trivial equations that can be removed for faster simulation. For instance, if a variable is initialized to zero and never modified, every occurrence of that variable can be eliminated from the other equations, and likewise for constant parameters. Removing these permits the identification of the number of unknown variables and the number of equations that may be solved to determine the unknown variables. These must equal; if there are too many unknown variables the system cannot be solved exactly, while too many equations implies an over-determined system, one that is trying to be in two places at once.

Fixing these modeling errors can take time, as it requires a lot of thought about the system and the implications of various modeling choices. One of the main limitations of computational modeling is that it doesn't produce the same sort of system knowledge that paper-based approaches tend to; a Modelica tool will not give you a free-body diagram. Instead, iterative model development and thoughtful system consideration is a dependable method to modeling many systems.

Continuing, correct model syntax and sufficient variables and equations produces a system of equations that can be solved to simulate your system. These equations can be solved exactly only very rarely, and only for the simplest of systems, to the point that Modelica tools do not include algebraic solution methods. Instead, as we are almost always simulating dynamic systems, numerical methods are applied that, essentially, solve the system incrementally at small time increments and thereby piece together the system dynamics over the desired time domain. These solvers use properties of the system equations to choose timesteps that are smaller than the modeled phenomena to try to capture all of the relevant behavior. Small timesteps, though, require many solutions of the system which each take a certain amount of time to solve. These add up and can lead to long simulation times and large simulation data files[1].

Some systems will solve nicely and robustly, but more common are systems that have certain configurations where the solver is unable to find a unique solution. Typically referred to as singularities, there are a variety of reasons a set of equations may fail to solve under certain conditions. The common example is asking a robot arm to reach some point beyond its workspace; the finite length of the arm segments prevent solution of the equations, even though they can be solved for other tasks. These conditions are not always easy to identify, especially for non-physical models and current tools do little to explain this to the user. This also supports an incremental and iterative model development strategy.

Once these stages have been worked through, interpreting the results requires careful consideration. The best case is when you have data from a real-world system that you can use to validate and understand the simulation. But this is a bit like putting the cart before the horse, as much of our interest in simulating systems is to guide later development activities. Hypothetical system simulation is challenging because the results are highly dependent on the modeler's initial assumptions for important parameters like friction and the values of stiffness, mass, or other system parameters. We tend to start with the obvious: like making sure that system energy is constant (if frictionless) or decreasing, and that the general directions of motion are correct. The first timestep can be taken as a quasistatic solution; graphing this is often helpful for checking that the modeler's system conception is consistent. Beyond these cursory checks plotting or animating the simulation results allows exploration of the system behavior and evaluation of the system's suitability to the intended task.

More than this is up to the user. One of our common interests is evaluating bearing forces over the course of system movement, to check whether the intended bearing is sufficient to the task. These dynamic loads are only the start of a bearing analysis, but it is a good starting spot. Many more effects may be explored through any set of results, and it is also often interesting to explore how performance changes in response to slight parameter changes.

The non-physicality of simulations makes their creation and use in product development and system analysis challenging, with success or failure highly dependent on problem formulation and modeling strategy. That said, when done well a simulated system can provide a common reference to guide later development activities, allowing teams to see around certain corners and explore paths before investing in whole-system prototyping. As always, we're happy to help you save time by simulating systems, say hi to start a conversation.

  1. The canonical example is on the heating and cooling of a building, where you may want to simulate building operation over the four seasons but individual heaters and air conditioners may only be active for minutes at a time. With 525,600 minutes in a year, if a solver solves the system once every minute using standard 8byte double variables, each variable will have a size of 4.2MB. With buildings often involving thousands of variables, result files quickly measure in the Gigabytes. ↩︎

— Ben Conrad