I build a Modelica model, but when checking the model (Here is the model download link), it shows a local singularity like in the following screenshot.
so I delete the code showed in the error message.
h[3]=(hout+hl)/2
but although the model checks fine, there is a strong nonlinearity issue which causes the initialization failure.
So I try to delete the following code line:
h[1]=(hin+hv)/2
and the model not only checks but also there is no initialization issue.
My questions are:
When debugging the model singularity, the error message showed by Dymola might be not the singularity source of the model? Is there a general method to find the source of the singularity problem? Or I have to analyze the equations in the model manually?
How to minimize the nonlinearity of the Modelica model and ensure convergence? I found this problem exists in many fields, especially in the thermo-hydraulic models, I found that one way to deal with this problem is the way used in Thermao Power Library from Modelon and ThermoSysPro for EDF, these two libraries divide the models or connector into two types: flow and volume. To ensure convergence, it requires to use a staggered grid scheme like in the following screenshot.
So is there another method to deal with the nonlinearity problem in thermo-hydraulic models?
is there a common view on how to deal with the nonlinearity problem in thermo-hydraulic models?
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.
Here is the link of the model:https://mbe.modelica.university/behavior/discrete/decay/#chattering
The simulation result for the following result in Dymola 2021 would be:
model WithChatter(stopTime=1.001s)
model WithChatter(stopTime=1.5s)
As we could see, noEvent operator does decrease the CPUTime, but it also causes the system stiff, it would be easier to understand with more explanation about why noEvent would cause the system stiff.
Based on the event logging of model WithChatter, the simulation process actually uses the minimum time step because the der(x) is not a continuous function. But why doesn't this approach suit the model WithNoEvents?(https://mbe.modelica.university/behavior/discrete/decay/#speed-vs-accuracy)
If noEvent operator means using the integrator directly, it might require the functions in the equation system have to be continuous? So Does this mean that the model used in the Chattering example(https://mbe.modelica.university/behavior/discrete/decay/#chattering) isn't appropriate, since the function in this model is not continuous?
The model used in the chattering example isn't appropriate since it is not continuous, and the error message from dassl is just a boiler-plate message, so the model isn't stiff but discontinuous as you found.
Markus A has a good point in the related question When to use noEvent operator in Modelica language? that using noEvent to avoid chattering is in general not a good idea, and one should normally try to rewrite the model instead of adding noEvent.
This specific model is sort of similar to a friction model where you would have
der(v)=(if v>=0 then -1 else 1)+f_other/m;
The solution for friction is not to introduce noEvent, but to add a stuck mode as in Modelica.Mechanics.Rotational.Components.BearingFriction.
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.
Problem Faced:
I have a SIMULINK model that has got two algebraic loops.
In order to overcome this I have set the model configuration properties as "warning".
The model runs well and has got the expected dynamics as shown in below image.
enter image description here
Now I need to convert this model to .exe which will be accessed by a GUI.
In order to do so I have to break this algebraic loop by using a unit delay block else the build process does not execute EVEN IF the configuration properties of the simulation model has been set to "none/warning".
But in the process of using a unit delay block, entire dynamics of the solution changes which shows that its a numerical error as shown in below image..
enter image description here
I request, somebody please suggest a suitable solution in dissolving this algebraic loop error without changing the dynamics of the model.
In many situations Simulink is capable of solving algebraic loops and provide a solution, but it can not generate code (see "Implications of Algebraic Loops in a Model" at the end). If I assume your implicit goal of creating an exe is to run it on systems without Simulink, that is not possible.
I am new to the topic of co-simulation. I am familiar with the definitions (based on Trcka "COMPARISON OF CO-SIMULATIONAPPROACHES FOR BUILDING ANDHVAC/R SYSTEM SIMULATION "):
Quasi-dynamic coupling, also called loose coupling,
orping-pongcoupling, where distributed models run in sequence, and one
model uses the known output values, based on the values at the previous
time steps, of the coupled model.
Fully-dynamic coupling, also called strong coupling, oronion coupling,
where distributed models iterate withineach time step until the error
estimate falls within a predefined tolerance.
My question: Is FMI/co-simulation a loose coupling method? What is FMI/model-exchange? From my understanding, it is not a strong coupling method. Am I understanding it correct that in model-exchange, the tool that imports the FMU is collecting all ODE and algebraic equations and the tool solve the entire system with a single solver. So it is more a standard to describe models in a unified way so that they can be integrated in different simulation environments?
Thank you very much for your help
FMI/Model-exchange is targeted at the distribution of models (systems of differential algebraic equations), whereas FMI/Co-Simulation targets the distribution of models along with an appropriate solver.
Due to the many challenges in coding solvers with an appropriate support of rollback, it is hard to come by exported FMUs that can be used in a strongly coupled co-simulation.
So, to answer your question: it depends on the scenario. If you wish to simulate a strongly coupled physical system using FMI/Co-simulation, and you wish to do so with multiple FMUs, it better be that these support rollback, to avoid stability issues. If you have, for example, a scenario where one FMU simulates the physical system, and another FMU simulates a controller, then you may do well with a loose coupling approach.
It is hard to pinpoint exactly how strongly coupled two FMUs need to be before you need to apply a stabilization technique.
Have a look at the following experiment, which compares a strong coupling master with a loose coupling one.
Both master are used for the co-simulation of a strongly coupled mechanical system:
https://github.com/into-cps/case-study_mass-springer-damper
Also, see the following report (disclosure: I contributed to it :) ) for an introduction to these concepts:
https://arxiv.org/pdf/1702.00686v1
I'm not an expert on simulation solver but I'm involved in an implementation of an FMI Co-Simulation slave.
First, you are entirely right about the model-exchange.
Regarding the co-simulation, The solver sets the input values, do a step and read the output values. There is no interactions within timestep. I would say that is more a Quasi-dynamic coupling.
But it is possible for the solver to cancel the previous step in order to refine time step and redo computation, ...And so on until the error estimate falls within a predefined tolerance. That is more close to a fully-dynamic coupling.
Because it is the responsibility of the solver (Co-simulation master) to set/get input/output values and to do step (and refining timesteps), definition of coupling with other model will depends on solver.
regards,