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.
Related
I am using Matlab for this project. I have introduced some modifications to the ode45 solver.
I am using sometimes up to 64 components, all in the [0,1] interval and the components sum up to 1.
At some intervals I halt the integration process in order to run a quick check to see whether further integration is needed and I am looking for some clever way to efficiently figure this one.
I have found four cases and I should be able to detect each of them during a check:
1: The system has settled into an equilibrium and all components are unchanged.
2: Three or more components are wildly fluctuating in a periodic manner.
3: One or two components are changing very rapidly with low amplitude and short frequency.
4: None of the above is true and the integration must be continued.
To give an idea: I have found it to be a good practice to use the last ~5k states generated by the ode45 solver to a function for this purpose.
In short: how does one detect equilibrium or a nonchanging periodic pattern during ODE integration?
Steady-state only occurs when the time derivatives your model function computes are all 0. A periodic solution like you described corresponds rather to a limit cycle, i.e. oscillations around an unstable equilibrium. I don't know if there are methods to detect these cycles. I might update my answers to give more info on that. Maybe an idea would be to see if the last part of the signal correlates with itself (with a delay corresponding to the cycle period).
Note that if you are only interested in the steady state, an implicit method like ode15s may be more efficient, as it can "dissipate" all the transient fluctuations and use much larger time steps than explicit methods, which must resolve the transient accurately to avoid exploding. However, they may also dissipate small-amplitude limit cycles. A pragmatic solution is then to slightly perturb the steady-state values and see if an explicit integration converges towards the unperturbed steady-state.
Something I often do is to look at the norm of the difference between the solution at each step and the solution at the last step. If this difference is small for a sufficiently high number of steps, then steady-state is reached. You can also observe how the norm $||frac{dy}{dt}||$ converges to zero.
This question is actually better suited for the computational science forum I think.
Simulating models with dymola, I get different results depending on the chosen integration method. So my question is: why choose which method?
Ideally the choice of method should be based on which one most quickly gives a result close enough to the exact result.
But we don't know the exact result, and in this case at least some of the solvers (likely all) don't generate a result close enough to it.
One possibility is to first try to simulate with a lot stricter tolerance - e.g. 1e-9. (Note: for the fixed step-size solvers, Euler and Rkfix* it would be smaller step-size, but don't start using them.)
Hopefully the difference between the solvers will decrease and the different solvers give more similar results (which should be close to the exact one).
You can then always use this stricter tolerance. Or in case one solver already gave the same result with less strict tolerance - then you can use that one at less strict tolerance; but you also have to make a trade-off between the accuracy and simulation-time.
Sometimes this does not happen and even the same solver generate different results for different tolerances; without converging to a true solution.
(Assumedly the solution are close together at the start but then quickly diverge.)
It is likely that the model is chaotic in that case. That is a bit more complicated to handle and there are several options:
It could be due to a modeling error that can be corrected
It could be that the model is correct, but the system could be changed to become smoother
It could be that the important outputs converge regardless of differences in other variables
It could also be some other error (including problems during initialization), but that requires a more complete example to investigate.
Choose the solver that matches best the exact solution.
Maybe Robert Piché's work on numerical solvers gives some more clues.
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.
The QP problem is convex. For Wiki, the problem can be solved in polynomial time.
But what exactly is the order?
That is an interesting question with (in my opinion) no clear answer. I am going to assume your problem is convex and you are interested in run-time complexity (as opposed to Iteration complexity).
As you may know, QuadProg is not one algorithm but rather, a generic name for something that solves Quadratic problems. It uses a set of algorithms underneath viz. Interior Point (Default), Trust-Region and Active-Set. Source.
Depending upon what you choose, each of these algorithms will have its own complexity analysis. For Trust-Region and Active-Set methods, the complexity analysis is extremely hard. In fact, Active-Set methods are not polynomial to begin with. Counterexamples exist where Active-Set methods take exponential "time" to converge (This is true also for the Simplex Method for Linear Programs). Source.
Now, assuming that you choose Interior Point methods, the answer is still not straightforward because there are various flavours of these methods. When Karmarkar first proposed this method, it was the first known polynomial algorithm for solving Linear Programs and it had a complexity of O(n^3.5). Source. These bounds were improved quite a lot later. However, this is for Linear Programs.
Finally, to answer your question, Ye and Tse proved in 1989 that we can have an Interior Point method with complexity O(n^3). However, whether MATLAB uses this exact flavor of Interior Point method is a little tricky to know but O(n^3) would be my best guess.
Of course, my answer is rather theoretical; if you want to empirically test it out, you can do so by gradually increasing the number of variables and plotting the CPU time required to get an estimate.
I have a program in SimMechanics that uses 6 derivative blocks (du/dt). It takes about 24 hours to do 10 secs of simulation. Is there any way to reduce the calculation time of the Simulink derivative blocks?
You don't say what your integration time step is. If it's on the order of milliseconds, and you're simulating a 10 sec total transient time, that means 10,000 time steps.
The stability limit of the time step is determined by the characteristics of the dynamic system you're simulating.
It's also affected by the integration scheme you're using. Explicit integration is well-known to have stability problems for larger time steps, so if you're using an Euler method of integration you'll be forced to use a small time step.
Maybe you can switch your integration scheme to an implicit method, 5th order Runge Kutta with error correction, or Burlich-Storer. See your documentation for details.
You've given no useful information about the physics of the system of interest, the size of the model, or your simulation choices, so all this is an educated guess on my part.
Runge-Kutta methods (called ODE45 or ODE23 in Matlab dialect) are not always useful with mechanical problems, due to best performance with variable time slice setup. Move to fixed time setup and select the solver by evaluating the error order you can admit. Refer to both Matlab documentation (and some Numerical Analysis texts too, :-) ) for deeper detail.
Consider also if your problem needs some "stiff-enabled" technique of resolution. Huge constant terms could drive to instability your solver if not properly handled.