Repository navigation
Too few poles for MIMO tf #111
Description
Activity
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.Does this still happen with my new implementation of _common_den ?
- 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> .
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].
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-1poles 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
tzeroworks exclusively with state models, the answer would always be 2 or[2, -2]depending on which nonminimal representation is given.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?
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.
- added a commit that references this issue
on Jul 2, 2018 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.
- 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> .
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
output: