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!

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.

Sound like a good feature to add. If anyone is willing to take it on, please assign to yourself.

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.

What about AB09MD? Seems to be a nice counterpart of currently used AB09AD.

Unfortunately, neither TB01KD nor AB09MD are implemented in the pypi slycot fork. And the repo hasn't been updated for a while.

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.

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.

I have been trying to push my local repo of python-control, but it isn't working. Can someone grant me access?

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.

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.

I created a pull request for my update. If anyone has any comments, I'd love to hear them.

As noted above, this change is addressed in PR #78. Waiting on unit tests before merging into master.

I'm pretty sure we can lay this issue to rest. Addressed in PR #118.

I agree.