Industrial Evaluation of Integrated Performance Analysis and Equation Model Debugging for Equation-Based Models

The ease of use and the high abstraction level of equation-based object-oriented (EOO) languages such as Modelica has the drawback that performance problems and modeling errors are often hard to (cid:28)nd. To address this problem, we have earlier developed advanced performance analysis and equation model debugging support in the OpenModelica tool. The aim of the work reported in this paper is to perform an independent investigation and evaluation of this equation model performance analysis and debugging methods and tool support on industrial models. The results turned out to be mainly positive. The integrated debugger and performance analyzer locates several kinds of errors such as division by zero, chattering, etc., and greatly facilitates (cid:28)nding the equations that take most of the execution time during simulation. It remains to further evaluate the performance pro(cid:28)ler and debugger on even larger industrial models.


Introduction
The development of today's complex products requires integrated environments and equation-based objectoriented declarative (EOO) languages such as Modelica (Modelica Association, 2014;Fritzson, 2015) for modeling and simulation.
The increased ease of use, the high abstraction, and the expressivity of such languages are very attractive properties.However, the drawback of this high-level approach is that understanding the causes of unexpected behavior, slow performance, and numerical errors of certain simulation models is very dicult, in particular for users who are not experts in simulation methods.
Therefore Pop et al. (2014) have recently developed an advanced equation model debugger for the Modelica language, as part of the OpenModelica (Open Source Modelica Consortium, 2016) tool.This is quite different from debuggers of conventional algorithmic programming language debuggers (Stallman et al., 2014;Nethercote and Seward, 2007;Zeller, 2009).Pop and Fritzson (2005) developed a debugger for the algorithmic subset of Modelica and Bunus (2004) developed a debugger that analyzes the causes of over-constrained or under-constrained systems of equations.The new debugger is also based on the recent development of the advanced bootstrapped OpenModelica compiler (Sjölund et al., 2014).
The applications used for evaluation perform simulation of combined cycle power plants.This involves the dynamics of water cycling from water to steam and back while streaming in dierent ow regimes through doi:10.4173/mic.2016.4.3 pipes, valves and volumes, aecting the heat transfer from the ue gases.To handle these rather complicated phenomena including boiling and condensation in and on tubes, accurate dynamic models often require high computation power, ecient programming as well as a good balance between accuracy and computational speed in the aspect of simulation purposes.
The performance analyzer, also called proler, which is a tool that informs where in user equations CPU power is spent and gives thereby possibility to evaluate dierent mathematical methods and make deliberated trading between accuracy and computational speed.As described in Sjölund (2015), the techniques used when proling Modelica equation-based models are quite dierent from proling of general programs (Graham et al., 1983).Some earlier more limited approaches to proling Modelica models are presented by Huhn et al. (2011) and Schulze et al. (2010).
The integrated equation model debugger has been evaluated by the designers and performs well on both small and big models.However, an independent evaluation of the integrated performance analyzer and debugger by industrial users on industrial problems was still missing.Such an evaluation is the main topic of this paper.We have earlier made a preliminary industrial evaluation only of the debugging functionality (Kinnander et al., 2016).This paper presents an evaluation of the integrated performance analysis and debugging methods and tool, including a slightly updated version of the debugging evaluation results presented by Kinnander et al. (2016).
The rest of the paper is structured as follows: rst the errors to be investigated and models to be evaluated are briey presented.Section 2 introduces the debugger tests in more detail.Section 3 presents debugging of errors in the logarithmic temperature calculation whereas Section 4 presents debugging of errors due to bad initial values.Section 5 presents the performance analyzer and its use.Finally, Section 6 presents conclusions.

Errors to be Investigated
In order to investigate dierent types of errors that could be expected to occur, a small and simple evap- The model selected is a simplied model of an error free model, hence the above test will be deliberately inserted and the debugging tool will only be examined by its outputs, while a sharper application for a real model development where errors are unknown and the debugger support for identifying them will be more apparent, will be carried out later.The reason for this is the limited time available for testing, and that a sharp application will only provide stochastic errors and could thereby not be planned in time.

Models for the Debugger and Performance Proler Evaluation
The evaporator test model shown in Figure 1    This model contributes with 39 equations of the total of 1110 equations.

Activation of Debugger
The debugger is activated by setting the ag Launch transformational debugger .After a successful simulation the output windows are containing the following information (Figure 5).
The simulation output window contains assertion violation messages that are false, because the enthalpy ow H (W) has too narrow range in the Standard Modelica library.It ought to be at least 10 times as big.
This violation has no inuence on the simulation result (might there be an unnecessary delay?).The window shows with a green bar that 100 % of simulation is done and the blue text that it has been successful.The transformational debugger window shows all variables in the variable browsers window and all equations in the equation browser window, as found in the simulation code.All other frames in the debugger are empty.

Division by Zero by Parameter Setting
The test is done by setting parameter k_inner to zero.
The simulation output window displays the following messages (Figure 6).
The simulation output window gives the required information that simulation crashed at initialization due to an assertion that avoids division by zero and this is caused by k_inner=0.The debugger window looks as before but after clicking debug more in the simulation output window it looks as in (Figure 6).

Division by Zero by Time Function
The k_inner variable is replaced by a time function that ramps it down to zero in 100 seconds.This results in a never ending simulation.
The solver manages to pass the 100 s time point where k_inner is zero and a division by zero occurs.
No plots are available but the ramp proceeds to negative values for k_inner.The solver has skipped the exact 100 s time point, but then continued into other problems, due to the negative k_inner value.On the passage it has however produced two messages about zero division at time 100 when they occurred.In the case of the user being unaware of the division problem, the large amount of output in the simulation output window hides those messages.
For a ramped denominator passing zero, the debugger is not optimal in case the solver manages to pass the critical point and that consecutive errors then hide the information from the user.A solution would be the option to let the user decide if division by zero should be accepted or not, i.e., the solver should then interrupt and save when any denominator having a passage of zero.

Division by Zero due to Mismatch in Parameter Settings
By deselection of the heat transfer used in the LnC pipe in the Hex model (Figure 3) the test model still checks OK, but now with only 1106 equations instead of 1110.

Errors in the Logarithmic Temperature Dierence Calculation
Errors in the logarithmic temperature dierence calculation should be treated the same way as the division by zero.Interesting is however, if the solver also for this type of errors manage to pass the critical point as their time duration could be expected to be very short.
Basically this investigation is more an investigation of the solver and not the debugger but the debugger will be activated and therefore also this investigation is a part of the paper.

Temperature Dierences Passing Zero
This test is achieved by removing the numerical fences that prevent zero crossing.Unfortunately, it turns out that there are no crossings that passes delT=0 for the case simulated, and the test needs further work to be

Temperature Dierences at Outlet and Inlet Passing Equal Values
This is happening without any numerical problems, i.e., the solver skips the critical time where they are equal or happens to avoid it without any actions.

Bad Initial Values or Bad Simulation Boundaries
The debugger support, if any, is to be investigated for this type of problems where simulation runs into numerical problems.

Too high Backpressure
By increasing the back pressure from the steam pipes to exceed drum pressure, and thus preventing steam ow out of the drum the simulation terminates at 277.7 s.
The result le is written, i.e. it is possible to plot.
The plotting reveals that the simulation crash is probably due to the drum getting lled with water.The transformational debugger window points at the drum.

Performance Analyzer Usage Evaluation
The performance analyzer (usually called proler) analysis methods and implementation are described in more detail in (Sjölund, 2015, Chapter 5).
The OpenModelica proler uses compiler-assisted source code instrumentation.
1 LBA in Figure 1, named according to the Kraftwerk-Kennzeichen-System (KKS) identication system.Exploring the 28 equations (Figure 13) reveals only one that is provided by the user (amongst the equations using 85 % of the calculation time).The rest are equations from the Modelica Fluid library.To see the impact by that equation on the performance, one of its parameters was changed.The equation has a parameter delTlim that is limiting the heat transfer calculation preventing that the temperature dierences become equal, thereby causing a simulation crash.Increasing delTlim value from 0.1 to 0.5 , which deteriorates the accuracy of the heat transfer calculation, gives the result that equations with index 1693 makes a minor reduction from 27.5 % to 27.4 % of the total time (Figure 14 and Figure 15), but the simulation time (major part of the total time) is anyway reduced from 30.0 to 28.5 s (not shown).
From that change the user could conclude that changing delTlim, which rather drastically deteriorates the accuracy of the heat transfer, the resulting improvement on the performance for index 1693 is neg-ligible, but the change any way inuences the total time a bit more substantially.
In general our experience is that the performance analyzer/proler is a very important tool for model performance optimization since it is very easy to see the link between a slow execution and the equations used.This information is very helpful when changing the model in order to speed up its simulation.Library such as V6Engine.To really evaluate the benets of the debugger, but also its functionality, it should also be applied to larger industrial models.
The following conclusions were made from the tests with the transformational debugger and performance analyzer for equation models: The debugger works well to nd zero denominators that are parameters.
orator model is used.This has been fetched from a larger model used for transient analysis of combined power plants by Siemens Industrial Turbomachinery AB in Finspång, Sweden.The following errors are to be investigated: 1. Division by zero 2. Errors in the average logarithmic temperature difference used for heat transfer calculation: a) Inlet temperature dierence =0 b) Inlet temperature dierence=outlet temperature dierence.3. Boiling in the evaporator that causes halt of simulation progress by much too small time steps (stiness) 4. Various test of bad initial values, with variation of pressure, temperatures, ows and masses in the dierent parts of the process.
will be used for the investigation, containing an instance (Evap) of the Evaporator model shown in the middle of the connection diagram.It consists of an evaporator model that has ue gases as heating source and water as coolant, producing dry steam to the steam sink.The steam production is decided by the heat from the ue gases, the enthalpy (temperature and pressure) of the water source (FWpump), and the steam extraction to the steam sink (SteamSink) that in turn is tracking the evaporators drum pressure with a negative bias of 0.1 to 1 bar.

Figure 5 :
Figure 5: Information from OpenModelica with debugger activated at successful simulation

Figure 7 :
Figure 7: Outputs after no use of heat transfer specied but corresponding heat transfer connectors any way connected

Figure 8 :
Figure 8: Information from the debugger variables browser The simulation output window recommends to log nonlinear systems(NLS).Doing this gives a not respond-ing OpenModelica.Restart gives a runtime error.A restart and simulation again without LOG_NLS activated gives the same result.The plotting of the Drum parameter mass shows that drum gets lled as it has no outlet (Figure9).The debugger test failed here on an OpenModelica problem with handling LOG_NLS.However, at this error the result le was generated and provides useful information for debugging.On the other hand, LOG_NLS is not a part of the debugger.The debugger information for this type of failure is not sucient to remedy the problem directly, although it points at the drum as a probable cause.Eventually the recommended logging of NLS could have given the direct cause of crash.From the OpenModelica user point of view, the plotting after crash is very valuable, and it reveals that the drum gets lled from the steam pipe model 1 , which calls for corrective actions regardless of the what caused the actual solver crash.

Figure 9 :
Figure 9: Plot of drum mass at blocked drum outlet

Figure 10 :
Figure 10: Output on computer screen after a successful execution with proler activated (option all selected)

Figure 15 :
Figure 15: Close-up of performance proler output after a minor model adjustment.The 28 equations at Index 1693 use 27.4% of the time.
The debugger does not come into play automatically if the zero denominator is only a momentarily value, as the solver managed work around such time points in so far tested simulations.However, it catches the problem in the simulation output window, and gives a message that by clicking opens the transformational debugger window which displays the concerned equation.However, there is a risk that this is unnoticed as the solver continues and could generate a lot of consequential or other messages that could hide the zero denominator messages.It would be preferable if the simulation output window could aggregate messages of the same type into one, expandable, line, thereby giving a better overview of all the types of messages the simulation has generated.A zero denominator caused by structural model errors, like connection to not used connectors (this should not pass the model checking) the debugger points to the causing equation.One could not ask more of the transformational debugger, but the OpenModelica model check or model building could be made to prevent such mistakes.In case of numerical problems causing long execution times the debugger points to the equations that have problems, but to understand the exact problem, plots of variables could be necessary hence the result le should always be generated, regardless if the simulation is interrupted by solver or manually.This is not the case in the tested version for all the tests.The performance analyzer/proler is a very important tool for model optimization as it is possible to easily see the link between a slow execution and the equations used.Compared to the alternative method where only the CPU curve together with plots of all other variables are available for guidance in the process of nding a good spot in the model to improve, the proler makes the process of performance optimization of models radically shorter.