Too few poles for MIMO tf

[roryyorke]

2x2 MIMO system I/s (diagonal, integrators on diagonal) is reported as having 1 pole. Converting to state-space gives the correct number of poles.

tested with slycot python-control/Slycot@a1f43ab and python-control cdd3e73

import numpy as np
import control

num = [ [ [1], [0] ],
        [ [0], [1] ] ]

den = [ [ [1,0], [1] ],
        [ [1],   [1,0] ] ]

g = control.tf(num,den)
print('g.pole()',g.pole())
print('control.ss(g).pole()',control.ss(g).pole())

output:

g.pole() [ 0.]
control.ss(g).pole() [-0. -0.]

[murrayrm]

Took a quick look at this. The problems seems to be in control.TransferFunction._common_den. The method used to put together the common denominator for a MIMO transfer function is to create a list of all unique poles that are found. This obviously won't work in the case of repeated poles. Definite bug.

[repagh]

Does this still happen with my new implementation of _common_den ?

[roryyorke]

I'll try to take a look this weekend. I see you have put the brakes on this over at #194 [edit: oops, meant #206]. I see Matlab describe their MIMO tf pole algorithm here: https://www.mathworks.com/help/control/ref/pole.html (see "algorithms" near the end) I can't remember if that's what is intended here.

…

On Wed, 30 May 2018, 13:39 Rene van Paassen ***@***.***> wrote: Does this still happen with my new implementation of _common_den ? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#111 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGxfv5bMBTnl9GS9sOmwUAK9p21zAB4ks5t3oT6gaJpZM4J4Tko> .

[roryyorke]

Here's a moderately tricky case from Maciejowski's Multivariable Control, Example 2.2:

num = [ [ [1],       [-1]      ],
        [ [1,1,-4],  [2,-1,-8] ],
        [ [1,-2],    [2,-4] ] ]

den = [ [ [1,3,2],   [1,3,2] ],
        [ [1,3,2],   [1,3,2] ],
        [ [1,1],     [1,1]   ]  ]

g = control.tf(num, den)

This has three poles: two at -1, and one at -2. It also has a transmission zero at +2, which might be of interest as a test case for #205.

Matlab's pole(tf(num,den)) gives poles [-2,-2,-1,-1,-1] for this system (but pole(minreal(ss(tf(num,den)))) gives the right answer).

Octave's control toolbox version 3.0.0 resorts to minreal(ss(g)) for MIMO poles; for this example, it gives [-1,-1,-2,-2]. If I do the same thing in python-control, I get [-1,-1,-2].

[ilayn]

This is system can be put into

[ 1/(s^2+3s+2)                                   ] * [1 -1]
[               (s^2+s-4)/(s^2+3s+2)             ]   [1  2]
[                                     (s-2)/(s+1)]   [1  1]

Then we have 5 poles indeed. However if we decompose to the other side by MFD then we get the four pole answer by adding (s+2)/(s+2) to the last row elements. But that adds a spurious zero at -2.

So we shift the problem from pole to zero in terms of minimality. The actual answer is only possible to find if the common denominator can be completed to [1, 4, 5, 2] by taking into account that the -1 poles have different directions but that needs a significantly more tedious search otherwise the problem would be giving more poles than the actual, instead of too few. Hence for Transfer models I think this is as good as it gets as far as I can see.

Since tzero works exclusively with state models, the answer would always be 2 or [2, -2] depending on which nonminimal representation is given.

[roryyorke]

Is an algorithm based on extracting common denominators to left (row-wise) or right (column-wise) (or both?) a reasonable option? Or should we just convert to state-space and get the poles that way?

[ilayn]

Unfortunately, I am not aware of any algorithms that solves this satisfactorily for transfer models by obtaning Mcmillan forms. As your example nicely demonstrates, there is a need to evaluate the pole directions and I am not sure that it is worth the effort to bother with all pathological cases.

However, the initial example clearly has a bug of not taking into account the multiplicities as Richard mentioned. I guess having more poles than the Mcmillan degree is OK since nonminimality is a common expectation. But fewer poles is not correct in my opinion and might be misleading.

[murrayrm]

PR #206 claims to have fixed this problem. It definitely fixes the problem identified by @roryyorke at the top of this issue. For the "tricky case from Maciejowski's Multivariable Control, Example 2.2", I get the following:

In [4]: control.pole(g)
Out[4]: array([-2., -1., -2., -1.])

In [5]: control.pole(control.minreal(control.ss(g)))
0 states have been removed from the model
Out [5]: array([-2., -1., -1.])

This appears to be right, but leaving for @roryyorke to confirm and then we can close out this issue.

[roryyorke]

Will try to review this weekend.

…

On Wed, 18 Jul 2018, 06:07 Richard Murray ***@***.***> wrote: Assigned #111 <#111> to @roryyorke <https://github.com/roryyorke>. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#111 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGxfpa1sVu7Xlv58tkj5kYHKBxMYHmbks5uHrRogaJpZM4J4Tko> .

[roryyorke]

Tested a007fcc, looks good to me.