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.
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.
I am trying to understand the process of solving DAEs in Dymola. According to Chapter 13.8 of Dymola's help document, Dymola would first use an index reduction algorithm to transform the original DAE into ODE, then get a BLT form after partitioning and tearing, so Dymola could solve ODE with BDF method like DASSL.
Here is the screenshot of Dymola's help document.
I also found some material about how to solve DAE from Wolfram mathematica, as shown in the following screenshot, there could be different strategies in different phases, I marked the method I think adopted in Dymola. My question is:
Does Dymola just adopt the method as I marked?
Or Dymola also adopt the method as Wolfram Mathematica, which is using different methods in different phases? If so, how does Dymola determine using which method?
Dymola does something resembling that red line, and ignoring many of the choices in that flow-chart as they are not relevant and there many equally important choices hidden.
E.g.,
The index reduction algorithm will work even if the index is 1 or 0 - it will just not do anything.
The dummy derivatives method can be seen as a projection method. (I did my master's thesis on implementing it a long time ago.)
IDAS is one of the solvers in the sundials suite. Dymola can use sundials solvers for integration, as well as a number of other solvers; and both have the model as ODE or as index 1 DAE for suitable solvers - but that's handled in the generated C-code, and doesn't influence other parts.
Has anyone tried to implement the Navier Stokes Partial Differential Equations (PDE) in Modelica?
I found the method of the spatial basis functions (SBF) which by means of numerical modifications gets Ordinary Differential Equations (ODE) that could be handled by Dymola.
Regards,
Victor
The aim of the method I was saying before is to convert PDEs in ODEs, so the issues with the CFL coefficient would disappear, the problem is that the Modelica.Fluids elements just define the equations in function of the variables in both ends of each component.
i.e dp=port_a.p-port_b.p
but with that sort of methodology, the variables such as pressure, density, mass flow... would be function also of the surrounding components... it would be a kind of massive interaction between all the components,
I would like to see an example in Modelica, because I hardly haven't found information about that topic linked to Modelica.
Modelica is a language for modeling behavior described by DAEs. As such, as long as you can create a system of ODEs, you should be able to express your problem in Modelica.
However, if your PDEs are hyperbolic, the wave dynamics in the equations might cause some issues with simulation. This is because the CFL condition imposes limits on time steps that an ordinary differential equation solver will be unaware of. If the solver includes error control, it will probably manage to get a solutions but may run quite slow because it won't know how to explicitly limit the simulation step size. If it doesn't include error control and it violates the CFL condition, the system will go unstable. Note, this only applies to systems where the CFL condition applies.
I am constructing a finite volume model in Dymola which evolves in time and space. The spatial discretization is hard coded in the equations section, the time evolution is implemented with a term consisting of der(phi).
Is the time integration of Dymola always numerically stable when using a variable step size algorithm? If not, can I do something about that?
Is the Euler integration algorithm from Dymola the explicit or implicit Euler method?
The Dymola Euler solver by default is explicit (if an in-line sovler is not selected).
The stability of time integration is going to depend on your integrator. Generally speaking, implicit methods are going to be much better than explicit ones.
But since you mention spatial and time discretization, I think it is worth pointing out that for certain classes of problems things can get pretty sticky. In general, I think elliptic and parabolic PDEs are pretty safe to solve in this way. But hyperbolic PDEs can get very tricky.
For example, the Courant-Friedrichs-Lewy condition will affect the overall stability of the solution method. But by discretizing in space first, you leave the solver with information only regarding time and it cannot check or conform to the CFL condition. My guess is that a variable time step integrator will detect the error being introduced by not following the CFL condition but that it will struggle to identify the proper time step and probably also end up permitting an unacceptably unstable solution.
MY PROBLEM
I have a SIMULINK model that has got a feeback loop aka Algebraic Loops that is causing error in the simulation. My original solver configuration was Fixed-Step with Dormand-Prince (Order 5). I also tried Fixed-Step with Order 3 (Runga-Kutta). It still has not resolved the issue.
MY QUESTION
Is there any way to resolve algebraic loop without altering the original performance or design of the circuit too much?
CLARIFICATION FOR THE QUESTION
I am sure that there will be a way to solve this. However, I don't want it to compromise the original performance of the circuit. Moreover, it is a customer-supplied data and it seems that they have managed to work this out as fine. I simply require somebody to point me to the right direction regarding how to solve this.
MY Approach so far
I tried to break the loop using:
i) Switch (if ip = 0, op = 0; if ip = 1, op = 1) I know it is stupid but it is a different block that breaks the loop.
ii) Logic gate (XORing the feedback signal with 0).
Unfortunately, I don't know how to do a zero-order hold unit delay loop that seems to be another commonly prescribed solution for this kind of problem. But I believe that may cause issues with my model's originally intended performance.
I have posted a query on Mathworks website, but no response so far. SO I thought...why not stackoverflow? Below is the image.
Add a unit delay block on the feed back signal (from Logical Operator1 to Logical Operator4).
The unit delay provides the previous value of the output signal - this won't affect most of the circuitry in this scenario.
There isn't a "one size fits all" answer when it comes to algebraic loops. Here are a few resources about algebraic loops:
What are algebraic loops in Simulink and how do I solve them?
How can I resolve algebraic loops in my Simulink model in Simulink 6.5 (R2006b)?
Algebraic Loops in the Simulink documentation
and there are many others...
In your case, I would suggest highlighting the algebraic loop (as per the doc in the hyperlink above), and try inserting a unit delay in the loop. The doc shows how to do this. Other suggestions would be to try the algebraic loop solver or model parameters related to algebraic loops, or placing an IC or Algebraic Constraint block in the loop. Again, refer to the doc in the hyperlink above for details. I assume you are constrained to use a fixed-step solver and cannot switch to a variable-step solver.