Simulink integrator returns incorrect results when fed by rate limiter?

[Erik]

I am running into a problem in simulink where integrators are returning incorrect results.

I have narrowed it down to the following: the problems appears to have something to do with a rate limiter feeding the integrator. If I replace the rate limiter with a ramp input, the problem disappears, even though the inputs identical to within 1e-14. If I use a simple DIY integrator instead of the standard simulink block, the problem also goes away.
Is there a problem with the rate limiter/integrator combination I am unaware of? Am I missing something?

Unfortunately I cannot upload the file here, so here is a screenshot instead:
http://img827.imageshack.us/img827/3387/integratorweirdness.png

The integrator in the top (yellow) half returns strange results, as seen by differentiating the output and comparing it to the input.
The lower (green) half is identical, but the input is generated in a different way, without a rate limiter. The output is now correct.

The simulation is fixed step (0.001 s) ODE5.
Input: Ramp, start t=0, slope 100. Saturates at 50.
Gain block: 300

Thanks,
Erik

[Phil Goddard]

Your comparing apples and oranges, and then blaming the banana that they aren't the same.

Firstly turn on sample time colours (Format->Sample Time Display->Colors) and note that some of your signals are discrete and some are continuous.
Then look at both input signals (not one signals and the difference as you are doing) and note that one is continuous and one is discrete.
They may be the same at sample points (which is why the difference is zero), but one is a step and one is not.
Given that the integral is the area under the curve you shouldn't expect their integral to be the same (unless a simple Euler algorithm is being used).

Then run your simulation for 0.02 seconds rather than 1 second.
Note that the signals that you say are "Slope of integrator correct" and "integrators match" are in fact not correct nor do they match.
They are close, but not the same.
So even for the ramp input your home grown integrator (which is just using the Forward Euler algorithm) gives different results to the built in integrator.

Note that for the ramp (i.e. continuous input) the error is smaller than for the rate limit input (i.e. discrete input) but they are nonetheless different.

Fundamentally your model shows the following:

1. (continuous time) integration of a continuous signal and a sampled version of that signal give different results.
2. that in general an integrator followed by a first order difference (which is all the du/dt block is doing) is not the same as the original signal
3. the ode5 integration method is not the same as Forward Euler.

None of the above are surprising, and none of the above corroborate your Subject line.

Phil.

[Erik]

Hi Phil,

First off, thanks for helping me understand this. I was aware of the differences between continuous and discrete signals, but I had never given it much thought and never would have expected such large errors resulting from it. Your tips are very helpful.

One of the reasons I was stumped is that I have been copy-pasting scopes. Apparently, I had copy-pasted a scope which was set to "sampling", and every signal was showing up as a sampled "staircase". Changing the sampling setting on the scopes to "decimation" really clears things up.

My problem remains, however. In my actual model, I need rate limiters, but the discretisation is causing unacceptable errors in integrations (up to 10% in some cases). Reduction of the step time helps, but greatly increases simulation time if I want decent accuracy.

I modeled a rate limiter using a "time delay" block (continuous) instead of a "memory" block (discrete, which is how I suppose the simulink block is implemented) . This seems to work.

I'm wondering if there are any other ways around this problem?

Thanks,
Erik

"Phil Goddard" <philN...@goddardconsulting.ca> wrote in message <i75j8o$3e9$1...@fred.mathworks.com>...

[Phil Goddard]

> I modeled a rate limiter using a "time delay" block (continuous) instead of a "memory" block (discrete, which is how I suppose the simulink block is implemented) . This seems to work.

But a rate limiter is neither a time delay nor a memory.
The latter 2 are delays, the former is not.

> My problem remains, however. In my actual model, I need rate limiters, but the discretisation is causing unacceptable errors in integrations (up to 10% in some cases). Reduction of the step time helps, but greatly increases simulation time if I want decent accuracy.

Discretization of what?

The rate limiter doesn't in and of itself introduce a discretization.
In the model you have it is discrete because the constant block feeding it is discrete and it's properties are by default set to inherent that sample rate.
Change its sampling mode to continuous and (with sample time colours on) you'll see a continuous output.

Are you trying to discretize the integrator?
In that case your model isn't correct because the integrator is wrapped by a feedback loop but your Euler integrator is not.
Hence the two will give different results.

Phil.

[Erik]

Hi Phil,

> But a rate limiter is neither a time delay nor a memory.
> The latter 2 are delays, the former is not.

Inside the *dynamic* rate limiter there is a delay, such that the current value of a signal can be compared with a previous value to determine the rise/fall rate. If you "look under mask" of the dynamic rate limiter (the block I'm actually using in my real model), you'll see a 1/z block (discrete). This block introduces the sample time delay for the rate determination. I assumed the regular rate limiter was similar. I also thought that this discrete delay was the root of my problem.

I built a similar rate limiter using the "time delay" block instead of the 1/z. This seemed to fix the integration inaccuracy I was seeing.

> The rate limiter doesn't in and of itself introduce a discretization.
> In the model you have it is discrete because the constant block feeding it is discrete and it's properties are by default set to inherent that sample rate.
> Change its sampling mode to continuous and (with sample time colours on) you'll see a continuous output.

I just checked this; and you're right. I think I finally understand what happened (please correct me if I'm wrong about any of this):

1) My "big" model was having integration inaccuracies.
2) I narrowed the problem down to a "dynamic rate limiter" in the model. The signal entering it was continuous, originating at a "step" source in a another subsystem.
3) Simplyfing further, I removed the source subsystem, and replaced with a "Constant" block. The problem remained.
4) I swapped the "dynamic rate limiter" for a plain vanilla "rate limiter". The problem remained. Apparently this was now due to the sampling parameter being set to "inherited" while connected to a "constant" block.
5) I made the example model with a regular "rate limiter" and a "constant" input, and I encountered the same problem. This is the picture I posted earlier.

The only thing I'm not understanding is why is the signal line exiting the dynamic rate limiter not red then? Why is its scope trace smooth, and not a staircase? It looks like it's continuous, but the integrator still seems to "misbehave"...

Take a look at this screenshot:
http://img815.imageshack.us/img815/3387/integratorweirdness.png

The top two systems are accurate now, but the lower one shows a large error in the integration, even though all signals seem continuous. I calculated analytically that the input to the integrator should level off to 100. The first two do, but the last one doesn't.

> Are you trying to discretize the integrator?
> In that case your model isn't correct because the integrator is wrapped by a feedback loop but your Euler integrator is not.

No, that's not my goal. I am modeling a continuous system, and would like to keep it that way. The dynamic rate limiter seems to be causing trouble with the continuous model. The Euler integrator has nothing to do with the model itself, I was just using it for comparison.

Thanks again,
Erik

[Phil Goddard]

The issue can be boiled down further, consider the following model:

Step (or any other continuous time signal) fed into both a Rate Limiter and a Rate Limiter Dynamic then both those blocks fed into a mux and the mux fed into an integrator.
Set the two rate limiting blocks to have the same rates.
Put scopes on the input and output of the integrator.

Run the simulation and note that the output of the mux shows both signals to be identical but the output of the integrator shows them to have different integrals.

To get the integrals the same you can either
1. Use ode1(Euler)
2. Put a Zero Order Hold on the output of the Rate Limiter block.

That seems to indicate that although the Rate Limiter Dynamic block shows as having a continuous output it is actually being integrated as if it is discrete.

It's not clear to me if that's a bug or whether it's something that isn't documented.

Phil.

[Erik]

> That seems to indicate that although the Rate Limiter Dynamic block shows as having a continuous output it is actually being integrated as if it is discrete.
>
> It's not clear to me if that's a bug or whether it's something that isn't documented.

That's interesting... At least my confusion was not completely unwarranted. Maybe someone from the Mathworks can chime in?

At least I have solved my problem. I will just use my custom dynamic rate limiter, based on a continuous time delay instead of the 1/z block. My model is returning accurate results now.

Thanks for all your help,
Erik