I have a transient model with Modelia.Fluid Valves and Dynamic Pipes that is running slowly. I am trying to find strategies and tools for identifying what is causing the slowness. By following the guidance in the Using the Profiler from OMEdit section of the Modelica Performance Analyzer documentation, I am able to see that the non-linear torn systems of equations are taking most of the CPU time which is helpful. However, I would like to learn more about what is causing the simulation to run slowly.
From reading Automatic tracking of stiff calculations in the models for improving simulation performance, it looks like Dymola has a "State variable logging => Which states that dominate error" option that appears to give insight to what part of the model is causing the integration step size to be reduced. I have read through the OpenModelica Compiler Flags and Simulation Flags documentation and have not found a similar option. Does OpenModelica have a similar option? Are there any tools or options within OpenModelica that will help me understand what parts of my model are causing my model to reduce the step size and run slowly or run slowly for other reasons?
If it matters, I am using the DASSL solver and OpenModelica 1.20.0.
Thanks,
Michael
Related
I was trying to compare the performance of a microgrid between Simulink and Openmodelica. The microgrid has different VSC converters working in EMT average, synchronous generators, loads, lines and buses and the model obtains quite logical results, the problem is that when the same model is created with OpenModelica, the following error is obtained with DASSL solver and a step size of 2e-5 s:enter image description here . Also, the libraries used are Dynawo and the standard Modelica library. Does anybody knows what this error means and how can it be solved? If anybody wants to see the models or needs more information I could send it.
Thanks!
I tried to simplify the model the much as possible, using simple control techniques for the VSCs (no droops or LVRT) in Simulink and Modelica and I confirmed that the same values are used in both models. Also, I changed the tolerance, the step size and the solver.
Is it possible to extract the ODE System from OpenModelica?
Using the nice GUI of OpenModelica to generate an ODE System which can be solved for further processings for example in Python would be really nice!
I know about the FMI interface, which we use at the moment for our simulations, but due to many bugs and problems which occur especially by the usage of PyFMI, just using ODE system might give us more control and stability in our further research.
In Dymola, I often meet a nonlinear system initialization failure or maybe a stiff system that is hard to solve in the large thermo-fluid system, but for a simple system, there wouldn't be this kind of problem. My questions are:
So I am wondering how much is the largest capability of solving a nonlinear system model? For example, how many nonlinear equations I could include in my model at most?
Is there any setting in Dymola which allows increasing the capability of solving nonlinear system?
How could I decrease the number of nonlinear equations in the model without damage to the accuracy of the model?
These are pretty difficult questions to be answered in a generally valid fashion. Still I'll try to share some of my experience with Dymola and non-linear systems.
There is no hard number which will limit the size. It depends more on how strongly non-linear the equations are than on their number. I have simulated models with non-linear systems of size 150, which are pretty stable while others of size 10 can brake...
There are multiple perspectives to this
I have worked on some models that made the C-Compiler run out of memory during compilation. If you have this sort of problem, forcing 64Bit compilation by setting Advanced.CompileWith64=2 can help. Then you shouldn't run out of memory any more. This only refers to the size only.
Performance for non-linear systems can be improved by activating DAE-mode by setting Advanced.Define.DAEsolver=true. This does not work with all solvers though.
Additionally to the above it can help to set Advanced.MoveEquationsToDynamics=true, for which the manual states: "It forces the integrator to solve the nonlinear
equations each integrator step and thereby it also updates the initial guesses more often."
As mentioned by Erik, the homotopy()-operator can be very important as it helps the solver converging in case of difficult initialization.
This is very specific to the model. Decoupling can help, e.g. by splitting the system in smaller systems by adding energy storing elements/states. This can be done based on physics of the system and is the preferable solution if possible. As an (more artificial) alternative filter/delays can be added. Usually this has a negative effect on accuracy.
I very much agree with Markus's advice but would also like to remind you about Modelica's homotopy operator. A well-chosen simplified model can greatly help Dymola to initialize a model with a large and difficult non-linear system.
In general good initial guesses are very important when solving non-linear systems. Using homotopy is simply an implicit way to provide these good guesses.
we want to publish an Open-Source for integrating Reinforcement Learning to Smartgrid optimization.
We use OpenModelica as GUI, PyFMI for the import to Python and Gym.
Nearly everything is running, but a possibility to connect or disconnect additional loads during the simulation is missing. Everything we can do for now is a variation of the parameters of existing loads, which gives some flexibility, but way less then the possibility to switch loads on and off.
Using the implemented switches in OpenModelica is not really an option. They just place a resistor at this spot, giving it either a very low or very high resistance. First, its not really decoupled, and second, high resistances make the ODE-system stiff, which makes it really hard (and costly) to solve it. In tests our LSODA solver (in stiff cases basically a BDF) ran often in numerical errors, regardless of how the jacobian was calculated (analytically by directional derivatives or with finite differences).
Has anyone an idea how we can implement a real "switching effect"?
Best regards,
Henrik
Ideal connection and disconnection of components during simulation
requires structure variability, which is not fully supported
by Modelica (yet). See also this answer https://stackoverflow.com/a/30487641/8725275
One solution for this problem is to translate all possible
model structures in advance and switch the simulation model if certain conditions are met. As there is some overhead involved, this approach only makes sense, when the model is not switched very often.
There is a python framework, which was built to support this process: DySMo. The tool was written by Alexandra Mehlhase, who made a lot of interesting publications regarding structure variability, e.g. An example of beneficial use of
variable-structure modeling to enhance an existing rocket model.
The paper Simulating a Variable-structure Model of an Electric Vehicle for Battery Life Estimation Using Modelica/Dymola and Python of Moritz Stueber is also worth a look. It contains a nice introduction about variable structure systems and available solutions.
I am working on modeling and controlling of a hydraulic system. Modeling of the system is modeled in Matlab simscape in simulink environment which is looks like this
and for basic controlling to control the piston position (Piston Pos in figure) I have established simple feedback to check the position.
While I run the simulation when this comes to control the position Simulation takes too much time. For example if I gave desired piston position 300 mm than while output comes to around 290-294 mm simulation time reaches at around 5.18sec than it is stuck on that for longer time.
I want to know that, is there any way to speed up the simulation ?
I am using Matlab simulink solver ode23t due to simscape modeling.
Speeding up simulations in general is vast subject. It seems the issue here is an event which triggers multiple small time-step in the variable step solver.
This can be perfectly normal, for example a clutch engaging, or a valve opening.
To check whether or nor this is the case you can execute (make sure time-logging is enabled):
semilogy(tout(2:end), diff(tout))
Sharp downward spikes indicate small time-steps were taken. For a more in-depth analysis you can use the Solver Profiler:
https://www.mathworks.com/help/simulink/ug/examine-solver-behavior-using-solver-profiler.html
This will give you detailed information as to which components are causing solver resets.
Such behavior can be difficult to debug if you're not used to the tool. I'd highly recommend getting in touch with MathWorks tech support if the behavior persists. They'll be able to look at your model and diagnose the issue.