Dymola simulations can terminate before the simulation end time for a variety of reasons. One of the more common, but thankfully simple to address, error messages is that of a divide by zero error. As the name implies, this is where Dymola tries to divide one quantity by another; if the denominator is zero, the result is infinite (and thus undefined). Therefore, when Dymola encounters this, the simulation is terminated. There are some simple ways to avoid this condition. Each has upsides and downsides, so it is up to the user to decide which approach is the best depending upon the situation. Here, I provide 4 possible fixes which can be deployed to get your simulations back up and running.
Refactor the problem
Arguably the cleanest (mathematically) method to avoid divide by zero errors is to multiply quantities, rather than dividing one by the other. This method, while adding no overheads to the simulation, would require the reformulation of some equations to be adequately implemented. However, during the symbolic manipulation stage, Dymola will often end up with the offending value back in the denominator and thus the problem hasn’t been solved. If you have a situation where both the numerator and denominator simultaneously approach zero, this fix can be successful.
While this isn’t a particularly robust approach, it can often be effective. Within the Modelica Standard Library, there are various useful constants. One such is the Modelica.Constants.small value, a constant of 1e^-60 (Note that the actual value may vary across tools / platforms). This can be added to any denominator variable which tends to zero; as it is so precise, the likelihood of the variable equaling the value of the small constant is much less than that of zero. Upsides of this method are that it is trivial to implement and will have negligible effect on simulation time. Nevertheless, it does introduce a (very) small error to the results. There is also the remote chance that the solver will land on the small value and still result in a simulation termination due to a denominator of zero.
Use max / min to avoid zero
Utilization of the max / min operators within Dymola will not trigger events. If the expression in the denominator only operates in positive space, simply writing the following would work.
Similarly, one can use the min operator if the expression in the denominator only operates in the negative space.
Detect zero quantities
One final method, is to write code to detect a denominator quantity becoming zero and change the denominator to a non-zero value. Various methods can be deployed to achieve this, the simplest of which is to write an if statement, where detection of a zero value triggers the use of a non-zero denominator. If deployed without using noEvent, the simulation may still fail as the solver may attempt to calculate both of the branches of the statement simultaneously at the event instant, and thus still throw a divide by zero error.
Each method presented above has their uses depending upon the application. When simulation speed is of paramount importance, reformulating the offending equation to multiply rather than divide might be the most suitable, as no extra calculations are undertaken. However, this can be a lengthy process depending upon the model, and thus may take the user more time to implement, and also may not yield a working simulation depending on the symbolic manipulation step. Adding the Modelica small constant is useful when the user wants to work solely in Dymola’s graphical interface. If you are lucky enough to have a denominator which operates entirely in the positive or negative domains, utilizing the min / max operators will be a fast and robust solution. Installing a zero detection clause is robust and relatively easy to implement, but risks either increasing simulation time or potentially introducing a small error to the results.
Generally, one of the example methods (or a combination of them) can help you avoid those pesky divide by zero simulation terminations. The best option very much is up to the user; and varies depending on the application!
Nate Horn – Vice President