Extra zeros added to a TF by zero()

I'm seeing extra zeros added to a TF by zero().

Here's a state space TF, in zpk form (for compactness, as the SS form is large with 17 states):

>> zpk(testTf)
ans =
-1.9848e-09 (s+1994) (s^2 + 320s + 2.527e05)
Continuous-time zero/pole/gain model.

This looks like a 3-zero system.

Now I check zeros on the zpk() system, and it's as expected:

>> zero(zpk(testTf))
ans =
-1.9941e+03 + 0.0000e+00i
-1.6000e+02 + 4.7651e+02i
-1.6000e+02 - 4.7651e+02i

But if I check zeros on the system itself without zpk(), I get 7 zeros:

>> zero(gff_pre)
ans =
-1.6000e+02 + 4.7651e+02i
-1.6000e+02 - 4.7651e+02i
-1.9941e+03 + 0.0000e+00i
-6.4648e+02 + 0.0000e+00i
-7.9341e+02 + 0.0000e+00i
-1.9941e+03 + 0.0000e+00i
-5.3978e+03 + 0.0000e+00i

Why? What might be occurring here?

Is zpk() removing zeros from the original state space TF? If so, why?

If not, is zpk() not an accurate representation of the system? To my understanding, all SS can be turned into TF (not including delays, which testTf doesn't have)

[Jon]

Maybe pole zero cancellations, and the cancelled zeros are not displayed in the more compact form. Please attach a .mat file with your systems defined so others can try to replicate and explain further.

[John]

Thanks. Attaching testTf.

I think you're right, that there are pole-zero cancellations...

Answer 1

[Jon]

Thanks for attaching your data.

As suggested in my original comments, and by @John you are seeing the effect of pole zero cancellations in the zpk form. Here are the poles and zeros of your state space system (testTf)

>> pole(testTf)

ans =

   1.0e+03 *

   -0.6465
   -0.7934
   -1.9941
   -5.3978

>> zero(testTf)

ans =

   1.0e+03 *

  -0.1600 + 0.4765i
  -0.1600 - 0.4765i
  -1.9941 + 0.0000i
  -0.6465 + 0.0000i
  -0.7934 + 0.0000i
  -1.9941 + 0.0000i
  -5.3978 + 0.0000i

The poles and zeros cancel for -646.5,-793.4,-1994.1 (one of them), and -53978 this leaves the zeros at -160+/- 476.5i and -1994.1

as confirmed by

  >> zero(zpk(testTf))

ans =

   1.0e+03 *

  -1.9941 + 0.0000i
  -0.1600 + 0.4765i
  -0.1600 - 0.4765i

[Paul]

@Jon is correct that zpk (and tf) can do pole/zero cancellation on conversion of an ss object, but there is a subtlety that should be kept in mind.

testTf = load('testTf.mat','testTf');
testTf = testTf.testTf;

Note that testTf is in descriptor form, but I don't think that matters.

testTf is not structurally minimal as we can see by applying sminreal, which elminates 12 states

size(testTf)

State-space model with 1 outputs, 1 inputs, and 17 states.

size(sminreal(testTf))

State-space model with 1 outputs, 1 inputs, and 5 states.

And we see that using zpk on testTf

h1 = zpk(testTf)

h1 =
 
  -1.9848e-09 (s+1994) (s^2 + 320s + 2.527e05)
 
Continuous-time zero/pole/gain model.

and on its sminreal'd form

h2 = zpk(sminreal(testTf))

h2 =
 
  -1.9848e-09 (s+1994) (s^2 + 320s + 2.527e05)
 
Continuous-time zero/pole/gain model.

yield the same result. Same thing would happen with tf. However, as best as I understand, this feature, which I believe is undocumented, only applies for state space realizations that are not structurally minimal, as opposed to nonminimal in general.

Consider the following system with one pole and zero in common

sys = zpk(-1,[-1 -2],1)

sys =
 
     (s+1)
  -----------
  (s+1) (s+2)
 
Continuous-time zero/pole/gain model.

These round trips do not do the cancellation

zpk(ss(sys))

ans =
 
     (s+1)
  -----------
  (s+1) (s+2)
 
Continuous-time zero/pole/gain model.

tf(ss(sys))

ans =
 
      s + 1
  -------------
  s^2 + 3 s + 2
 
Continuous-time transfer function.

because the intermediate realization is not structurally minimal (perhaps due to round-off error)

ss(sys)

ans =
 
  A = 
              x1         x2
   x1         -1  7.451e-09
   x2          0         -2
 
  B = 
       u1
   x1   0
   x2   1
 
  C = 
              x1         x2
   y1  7.451e-09          1
 
  D = 
       u1
   y1   0
 
Continuous-time state-space model.

though it is nonminimal to the default tolerance

zpk(minreal(ss(sys)))

1 state removed.

ans =
 
    1
  -----
  (s+2)
 
Continuous-time zero/pole/gain model.

But if we clean up the ss realization and make it structurally minimal

sys = ss(sys);
sys.a(1,2) = 0;
sys.c(1,1) = 0

sys =
 
  A = 
       x1  x2
   x1  -1   0
   x2   0  -2
 
  B = 
       u1
   x1   0
   x2   1
 
  C = 
       x1  x2
   y1   0   1
 
  D = 
       u1
   y1   0
 
Continuous-time state-space model.

then we see the pole/zero cancellation

zpk(sys)

ans =
 
    1
  -----
  (s+2)
 
Continuous-time zero/pole/gain model.

tf(sys)

ans =
 
    1
  -----
  s + 2
 
Continuous-time transfer function.

For SISO systems, the transformation of an ss object to either tf or zpk will reduce the order of the result if the ss object is not structurally minimal.

[Jon]

Thanks for your help understanding this rather complicated and subtle behavior that happens in the underlying calculations

Answer 2

[LeoAiE]

It's possible that when you convert the state-space model to a transfer function, some additional zeros might be introduced due to numerical inaccuracies or the way MATLAB handles the conversion internally. These extra zeros might be very close to some poles, making them practically insignificant when analyzing the system behavior.

When you convert the state-space model to a zero-pole-gain (zpk) model, MATLAB might be simplifying the model by canceling out those insignificant zeros and poles. This would explain why you see fewer zeros in the zpk model compared to the original state-space model.

To check if this is the case, you can compare the poles of the original state-space model with the poles of the zpk model:

poles_ss = pole(testTf); 
poles_zpk = pole(zpk(testTf)); 

If some of the extra zeros in the original state-space model are very close to the poles, it's likely that MATLAB is canceling them out during the conversion to zpk.

In general, zpk representations are useful for analyzing the behavior of a system, but they might not capture all the numerical details of the original state-space model. The difference between the two representations might not be significant in practice, depending on the specific system and the context in which it's being used.