GeezerVison is showing github.com — Truncated balanced realization for unstable state space models · Issue #77 · python-control/python-control
Truncated balanced realization for unstable state space models #77DescriptionDoes anyone know if there is a plan, or if one already exists, to implement a balred() function in python-control that can do a balanced realization and truncate the system like MATLAB's balred() function does? Thanks for any help. Activityroryyorke commented on Feb 19, 2016 balred appears to be implemented: http://python-control.readthedocs.org/en/latest/generated/control.balred.html#control.balred, which uses http://slicot.org/objects/software/shared/doc/AB09AD.html
However, this implementation doesn't handle unstable systems (Matlab separate out the stable part, and apply the reduction to part that only: http://www.mathworks.com/help/control/ref/balred.html )
>>> g=control.rss(5)
>>> h=control.ss(-g.A,g.B,g.C,g.D)
>>> control.balred(g,1)
A = [[-0.58673865]]
B = [[ 1.53564835]]
C = [[-1.53564835]]
D = [[-1.03540053]]
>>> control.balred(h,1)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/rory/git/python-control/control/modelsimp.py", line 251, in balred
raise ValueError("Oops, the system is unstable!")
ValueError: Oops, the system is unstable!mdclemen commented on Feb 19, 2016 ContributorAuthor More actions I meant is there a plan to make the current balred() more like MATLAB's balred()? That is to say one that can truncate unstable systems. murrayrm commented on Feb 19, 2016 Sound like a good feature to add. If anyone is willing to take it on, please assign to yourself. roryyorke commented on Feb 25, 2016 It looks like SLICOT's TB01KD could be the basis for this: http://www.icm.tu-bs.de/NICONET/doc/TB01KD.html
Unfortunately I don't think this is yet exposed in slycot (though I'm not sure which of the forks of slycot python-control uses). Anyway, one way to get "stabsep" into python-control would be to first expose TB01KD in the relevant slycot, and base python-control work on that.
A more, um, character-building approach would be to reimplement TB01KD in python. mp4096 commented on Feb 25, 2016 murrayrm commented on Feb 25, 2016 There is a discussion about SLICOT (and slycot) in issue #27. Because SLICOT requires a FORTRAN compiler and is now closed source, there is some desire to move away from it. Having said that, the current slycot forks are based on the earlier open source version of SLICOT and so we can certainly use that.
One possibility as an interim measure would be to put one of the slycot forks into this project (as python-control/slycot) so that we have a more active version. We could then write the slycot hooks for the AB09MD routine.
I'd be interested in getting @cwrowley's take on this. mdclemen commented on Feb 25, 2016 ContributorAuthor More actions I've written a routine that will do the stable/unstable decomposition, then do the balanced realization on the stable part (using the existing balred()), then put the parts back together. Once I've further tested it and figured out how to really use github, I'll upload it. The algorithm is outlined here and I'm fairly sure this is what MATLAB's balred() does. mdclemen commented on Feb 26, 2016 ContributorAuthor More actions I have been trying to push my local repo of python-control, but it isn't working. Can someone grant me access? roryyorke commented on Feb 27, 2016 The usual process is that your create your own fork of python-control here on github (mdclemen/python-control - do this by pushing the "Fork" button on the top right of https://github.com/python-control/python-control ).
Push your changes there; my git mojo isn't that good, but I suggest making mdclemen/python-control the "upstream" for your local repo - see git-push -u.
Finally, submit a pull request (should be a button on your repo's github page to do that); the pull request is then reviewed and, assuming all looks good, merged. cwrowley commented on Feb 27, 2016 That's an interesting suggestion by @murrayrm to put one of the slycot forks in python-control. I can think of a couple of possible disadvantages though: first, it would probably not be ideal to require a fortran compiler in order to install python-control; second, if others contribute to slycot through one of the other forks, these contributions wouldn't make it into python-control. So I'd lean towards keeping them separate.
I will say that compiling/installing SLICOT remains an annoying issue, because many potential users don't have a fortran compiler, or the fortran libraries installed. Last year I was encouraging students in my controls class to use python-control instead of Matlab, but everybody except the one or two Linux users had issues with installing SLICOT, and almost all gave up and went back to Matlab. There could well be better solutions using wheels and/or Anaconda, but I never did figure out a conda recipe for Macs that didn't require already having lapack installed (I should probably revisit this though), and I have no clue about Windows.
Only a few routines from SLICOT are used by python-control though (e.g., pole placement, Riccati solvers), so it wouldn't be too crazy to reimplement those in pure python or cython. mdclemen commented on Mar 2, 2016 ContributorAuthor More actions I created a pull request for my update. If anyone has any comments, I'd love to hear them. murrayrm commented on May 30, 2016 As noted above, this change is addressed in PR #78. Waiting on unit tests before merging into master. mdclemen commented on Jan 27, 2017 ContributorAuthor More actions I'm pretty sure we can lay this issue to rest. Addressed in PR #118. slivingston commented on Jan 27, 2017
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|