The Math Forum

Search All of the Math Forum:

Views expressed in these public forums are not endorsed by NCTM or The Math Forum.

Math Forum » Discussions » Software » comp.soft-sys.matlab

Notice: We are no longer accepting new posts, but the forums will continue to be readable.

Topic: Simulink, ODE15S and stiff-system solutions getting unnecessarily stuck.
Replies: 2   Last Post: May 24, 2013 4:35 PM

Advanced Search

Back to Topic List Back to Topic List Jump to Tree View Jump to Tree View  

Posts: 1
Registered: 5/24/13
Re: Simulink, ODE15S and stiff-system solutions getting unnecessarily stuck.
Posted: May 24, 2013 4:35 PM
  Click to see the message monospaced in plain text Plain Text   Click to reply to this topic Reply

Mike Tocci <> wrote in message <clu67s$53d$>...
> Kelvin Hales wrote:
> > I find when solving my present stiff Simulink 5.1 (R13SP1) system
> > with ODE15s, that the solution tends to grind to a halt when
> > approaching a steady-state, i.e. most annoyingly at the very point
> > where it should start to take bigger steps and zoom along. If,
> > however, I stop the simulation and re-start it by initialising the
> > states with the end state of the previous run, then the solution
> > immediately picks-up and shoots along.
> >
> > Any ideas anyone?
> > Its as though the solver is getting bogged down in the detail
> > because it cannot forget the previous small time-steaps.
> > A problem with a zero-crossing detection, maybe?
> > Is there something in the Simulink debugger/profiler that would
> > reveal what's happening?
> >
> >
> > Kelvin B. Hales
> > Kelvin Hales Associates Limited
> > Consulting Control Engineers
> > Web:

> Hi Kelvin,
> I'm not 100% sure, but it could be zero-crossings that are causing
> this. Whenever you stop a simulation and use the final state as an
> initial state, there is some information not stored in the state
> vector that is lost. This could be affecting the zc detection in
> some blocks.
> I do recommend using the Simulink debugger to try to find the problem.
> If you use the command-line debugger (sldebug), there are commands to
> print out solver information. I'd try setting a time break point
> (tbreak) so you get to the point where the model nears steady state,
> and then use the command "strace 4" to print out all the information
> in the solver. If there's any information in the output that's not
> clear, let me know and I'll see if I can help. There can be alot of
> information printed to the screen, so I recommend taking a few time
> steps using "step top" to see if you can tell why the time steps are
> so small.
> Hope that helps,
> Mike

I too have the same issue. I'm simulating a highly dynamic system with lots of power setpoint jumps with ODE15s. The model matches all the extreme dynamic changes fine until a large drop in power after being held at a steady state value. At this large drop in power, the model starts to progress at a snail pace. The step size it progresses at is at about 8e-8 seconds.

I am playing around with the minimum step size, maximum step size, relative error tolerance, and absolute error tolerance, but nothing is getting me past this point.

I am attempting to use a fixed step solver, but am not partial to this because it is so slow.

I will look into the suggestion posted by Mike. Any other suggestions are appreciated.



Point your RSS reader here for a feed of the latest messages in this topic.

[Privacy Policy] [Terms of Use]

© The Math Forum at NCTM 1994-2018. All Rights Reserved.