Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Travis CI sporadically fails in control.tests.convert_test.TestConvert #194

Closed
murrayrm opened this issue Feb 23, 2018 · 5 comments
Closed

Comments

@murrayrm
Copy link
Member

Travis CI tests are failing in semi-random ways and generating the following error:

FAIL: testConvert (control.tests.convert_test.TestConvert)
Test state space to transfer function conversion.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/build/python-control/python-control/control/tests/convert_test.py", line 86, in testConvert
    ssTransformed = matlab.ss(tfOriginal)
  File "/home/travis/build/python-control/python-control/control/statesp.py", line 1149, in ss
    return tf2ss(sys)
  File "/home/travis/build/python-control/python-control/control/statesp.py", line 1223, in tf2ss
    return _convertToStateSpace(sys)
  File "/home/travis/build/python-control/python-control/control/statesp.py", line 779, in _convertToStateSpace
    num, den = sys._common_den()
  File "/home/travis/build/python-control/python-control/control/xferfcn.py", line 821, in _common_den
    % quad.imag.max()
AssertionError: Quadratic has a nontrivial imaginary part: 1.06581e-14

The error is not always present and re-running the build sometimes fixes it. It appears the problem may be due to the way that random test cases are generated (although the seed is fixed in the unit test => not sure how we are getting different results on rebuild).

@roryyorke
Copy link
Contributor

Two reasons I can think of for different results given the same inputs are:

  1. tests were run on different hardware, e.g., CPUs with and without AVX2,
  2. and uninitialized variables.

However, neither seems all that likely.

Besides that, for the assertion to be triggered (BTW, shouldn't that be assert all(quad.imag < 10 * eps) be assert all(abs(quad.imag) < 10 * eps) ?), I think a complex conjugate pairs would have to be mismatched (that is, not exactly conjugate) -- can that happen?

If this is due to round-off, why not dodge the problem with quad = np.array([1, -2*poles[n].real, poles[n].real**2 + poles[n].imag**2]) ?

@stanmoon
Copy link

stanmoon commented May 1, 2018

running:
python setup.py test

gives the following error message:
...

FAIL: testConvert (control.tests.convert_test.TestConvert)
Test state space to transfer function conversion.

Traceback (most recent call last):
File "/home/stan/control-python-libraries/python-control/control/tests/convert_test.py", line 86, in testConvert
ssTransformed = matlab.ss(tfOriginal)
File "/home/stan/control-python-libraries/python-control/control/statesp.py", line 1149, in ss
return tf2ss(sys)
File "/home/stan/control-python-libraries/python-control/control/statesp.py", line 1223, in tf2ss
return _convertToStateSpace(sys)
File "/home/stan/control-python-libraries/python-control/control/statesp.py", line 779, in _convertToStateSpace
num, den = sys._common_den()
File "/home/stan/control-python-libraries/python-control/control/xferfcn.py", line 821, in _common_den
% quad.imag.max()
AssertionError: Quadratic has a nontrivial imaginary part: 1.06581e-14


Ran 296 tests in 6.198s

FAILED (failures=1, skipped=2)
Test failed: <unittest.runner.TextTestResult run=296 errors=0 failures=1>
error: Test failed: <unittest.runner.TextTestResult run=296 errors=0 failures=1>

Don't know whether this is an important error or not.

@roryyorke
Copy link
Contributor

@stanmoon it would be great if we could reproduce this error. Could you let us know your CPU, OS and version, and also Python, Numpy, Scipy, and python-control versions? If you need help figuring any of that out, let us know.

@roryyorke
Copy link
Contributor

In case this was due to Scipy or Numpy updates I just retried this, but I can't reproduce it on my system, Ubuntu 18.04 64-bit running on a Intel i5-5200U.

I tried the following two setups:

  1. Using system Python, Numpy, etc.:

    Python 3.6.5
    Numpy 1.13.1
    Scipy 0.19.1

This probably uses "plain old" BLAS and LAPACK for linear algebra. Not sure if
that's relevant for this test anyway.

  1. Up-to-date Conda Python 3-based system:

    Python 3.6.5
    Numpy 1.14.3
    Scipy 1.10

This had MKL installed (it was a default Conda setup).

murrayrm pushed a commit that referenced this issue Jul 2, 2018
* replaced the _common_den function internals. Passes tests
* make xferfcn.py python2 compatible again
* working tf -> ss transformation now, also solved #111
* disabled MIMO test when no slycot
* do not cancel pole/zero pairs before calculating pole() in xferfcn.py
- for the above reason, do conversion on minreal'd xferfcn in statesp.py
- add a test for not canceling pole/zero pairs when calculating pole()
- add import of matlab in discrete_test.py
* change testModred; that one did state removal on a system of which the selection of states was automatic
@murrayrm
Copy link
Member Author

murrayrm commented Jul 2, 2018

Fixed in PR #206.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants