Machine precision in simulink

Good morning everyone.

I am currently working on simulink model.

One of the equations is

"L = qf*(XL0+(XL1*alpha_quadrant))" 

where "alpha_quadrant" is constantly zero. "XL0" and "qf" are both constants.

The result of the equation, when graphed, should be constantly -11.08, but as it can be seen in the picture the result keeps fluttering.

Is it because of the machine precision?

[dpb]

Without Simulink in the picture, a product of two constants (presuming they are and do, in fact, remain constant) will indeed produce the same result to the final rounded bit.

Simulink, however, may do something behind the scenes in the model that mungs on the input terms that are those constants and thereby introduce some rounding which it would appear from the plot is what you're seeing.

However, would have to have the pertinent section of the model for anybody to be able to tell anything more definitive -- and, I don't have and have never seen a Simulink installation so I'm guessing here on what is possible given what I do understand about its operation.

[MARCO LORENZI]

Thank you for the answer.

So i checked out and "alpha" and "XL0" are constant.

qf is constant until the 14 decimal. Can the last 2 decimal make all that noise? Would it be possible to force the calculation to stop before the 14 decimal?

[dpb]

"All that noise" is also in the 14th decimal place in the output. How can that make any real difference?

Just set

ylim([-10 -12])

on the plot so the tiny little jiggle isn't so amplified and you'd never have noticed it.

Answer 1

[Andy Bartlett]

To determine what is happening, a good approach is to log the key signals involved.

Then use MATLAB to investigate the logged values.

I suspect you'll find that either alpha_quadrant isn't always zero or qf is not constant or XL0 is not constant.

The differences in values from what you expect might be very small so you could use some techniques like the following.

format long g  % will shows higher precision than short, but can still hide some differences

a = 0.05;
b = a + eps(a);
c = a + 2*eps(a);
v = [c,a,b]      % the differences will not be visible in the command window

% converting to a string with 17 digits will be enough to see differences
mat2str(v,17)

% subtracting values is another way to make the differences visible in the
% command window
dv = diff(v)
max(dv)
min(dv)

The output of this code is:

v =
                      0.05                      0.05                      0.05
ans =
    '[0.050000000000000017 0.050000000000000003 0.05000000000000001]'
dv =
     -1.38777878078145e-17      6.93889390390723e-18
ans =
      6.93889390390723e-18
ans =
     -1.38777878078145e-17
     

Notice that differences in v are hidden even by format long g.

[MARCO LORENZI]

Thank you for your answer.

So, "alpha_quadrant" is literally set to zero because in this case the goal is to evaluate aerodynamics related to "beta" variation.

"XL0" is also a constant because it is a number introduced by a constant blockset.

The only value directly calculated is "qf" and using "mat2str(qf,17) i can se that the values are the same until the 14 decimal.

Can i ask if there is anyway to force the solutor to consider, let's say, the first 10 decimals?

[Andy Bartlett]

Solvers are designed to give "accurate enough" answers in acceptable amounts of time. Due to the limits of finite precision math, the goal is not to get the ideal math answer, just an answer "close enough" to satisfy engineering requirements. Some Simulink solvers provide the ability to specify an absolute and relative tolerance. If the goal is to reduce the fluttering of signals that in ideal precision should be constant, then you could try to make the tolerances tigher (smaller). This will likely make the simulation time longer, but increase accuracy.

Before tightening the tolerances and slowing down your simulations, you might want to look at the observed fluttering with regard to your higher level engineering requirements. Determine how much, if at all, the fluttering prevents you from achieving your higher level engineering goals.

[MARCO LORENZI]

I am really sorry to bother, but i have one last question. I am running the model to simulate aerodynamic forces on a fuselage, which basically means i need "zero" precision. By that i mean that i can calculate them with 2/3 decimals and not 12 (which is where the flutter appears).

Can i ask how can i pratically do what you just said?

[dpb]

That really isn't what Andy said -- he said, in fact, the obverse -- if you want smaller jiggles on the near constant, you have to actually add more precision, not reduce it.

You can loosen tolerances to get fewer significant digits although if you go too far, solutions may,in fact, diverge from the real solution completely.

Before that point, while your simulation may run faster and will have lower absolute accuracy, it won't be by effectively "zero-ing out" more digits of precsion; the simulation will still be calculated in double precision floating point and so will have the full mantissa; what you'll get will be even more jiggles in your constant up to that level of accuracy you've specified for the solver.

There simply is no such thing as you're thinking of it as being N digits of numeric precision and everything past that identically zero -- in fact, that is in essence infinite precision because you've set a requirement on every digit from the first to as many as you want to name.

You could, I guess, insert an s-function as the output of every block that rounds the result before passing it to the next, but it's futile and pointless to do so...just use the simulation results you get. As noted above, if you were to change the scale on the plot to something realistic about the magnitude of the value itself, you would not even see the jitter and would not have even recognized it as being there.

It just doesn't matter in a practical sense.