Bug in TD04AD when ROWCOL='C'

[roryyorke]

The attached Fortran, when compiled under Ubuntu 14.04, demonstrates the problem. Unpack the zip file, run make, and you should see

./tfm2ss
 INFO (should be 0):
 0
 NR (should be 0):
 0
 D (should be 64):
  64.
Parameter 5 to routine TB01XD� was incorrect

For M=P=1, the 'R' and 'C' cases are essentially the same thing, but the 'R' case works, while the 'C' case bombs out.

I think the bug is here in TD04AD.f. According to the docs for the just-called TB01PD, the returned IWORK is valid for the first N non-zero entries, but this code seems to ignore that. When the transformed system is static, N is likely to be 0, and at least in the cases I tested IWORK(1) = IWORK(2) = 1, so TB01XD gets invalid arguments.

I don't know how important this is; for the purposes of python-control, if we ever did want to use column-factored denominators, we could work with the transpose of G(s), transform that to a statespace system using the now row-factored denominators, and then transpose the result. TD04AD promises an upper block Hessenberg A matrix, so they need extra transformations for the column-factored case.

I suppose this all seems a bit arcane. I found this while working on #5, and I thought I might as well report it.

tfm2ss.zip

[slivingston]

Thanks for this report. I think that it is worth fixing or, at least, adding some detection and notification in the case that is known to lead to failure.

[murrayrm]

@repagh Was this fixed in PR #27?

[repagh]

Yes, this is fixed

[roryyorke]

Confirm fix; the test case (see tfm2ss.zip in original report) now outputs

./tfm2ss
 INFO (should be 0):
           0
 NR (should be 0):
           0
 D (should be 64):
   64.000000000000000     
 INFO (should be 0):
           0
 NR (should be 0):
           0
 D (should be 64):
   64.000000000000000