Menu
▾
▴
Re: [python-control-discuss] Major updates from the Princeton group
|
From: Richard M. <mu...@cd...> - 2011-02-08 16:44:26
|
This sounds good. I'll try to spend some time looking at the new branch and then quickly switching to control-0.4a as the working version (trunk). -richard On 8 Feb 2011, at 8:39 , Kevin Chen wrote: > Developers, > > We are going to push our changes to a branch called control-0.4a (not control-0.3d, sorry! I hope this is okay. It took a while to get this branch working.). This is my first time using hgsvn, so I hope it works okay. After the push, the trunk should remain unchanged from 0.3c, and the new code should appear in branches/control-0.4a. > > - the Princeton group > > On Tue, Feb 8, 2011 at 11:32, Lauren Padilla <lpa...@pr...> wrote: > > > Begin forwarded message: > > From: Richard Murray <mu...@cd...> > Date: February 6, 2011 5:47:40 PM EST > To: pyt...@li... > Subject: Re: [python-control-discuss] Major updates from the Princeton group > Reply-To: pyt...@li... > > Brandt, Steve, Kevin, and Lauren: > > These look like really great changes and will definitely push the python-control library forward! What I suggest you do is create a copy of the current trunk as a branch (branches/control-0.3d) and then post all of your changes. This will let those of us working on the current trunk use the branch of needed, but hopefully switch to the new structure as soon as possible. > > I suggest that we updated the revision number after your changes, so we will create tags/control-0.4a based on your updated trunk. If you can create a page on the wiki that has the details of your revision (basically the e-mail below), that should help us keep track of what changed. > > As soon as I have a chance, I'll go through and start updating old functions to fit the new documentation on unit test structure, just to make sure I understand how to do this. > > Thanks for all of the hard work! I hope you all continue to contribute changes now and then, despite your class being done. > > -richard > > On 3 Feb 2011, at 14:07 , Lauren Padilla wrote: > > > Richard and developers, > > > > We are writing this note to discuss the major changes that we, the Princeton group, have made to our internal python-control repository. We have more or less completed our contribution to the project, and would like to push our changes to the SVN repository. > > > > == Unfinished business == > > > > - The ss2tf and tf2ss conversions are carried out in SLICOT, wrapped in Slycot, then wrapped in statesp._convertToStateSpace() and xferfcn._convertToTransferFunction(). (As for the user interface, these are then wrapped by tf2ss() and ss2tf(), and finally wrapped by ss() and tf().) The conversions seem to be buggy sometimes. This can be seen by running TestConvert.py, which makes a random state space (sys1), converts it to a transfer function (sys2), back to a state space (sys3), and back to a transfer function (sys4). Sometimes the outputs are correct; other times they are not; and yet other times, our machines enter an infinite loop. We did not have time to solve this issue completely, so it remains open. > > - hsvd() works, but there are better ways to compute the Hankel singular values. Better algorithms, however, may be substantial and difficult to program. Also, we did include MATLAB's baldata output. balred() can return the balancing data. > > - balred() does not yet support MatchDC. > > - h2syn() and hinfsyn() are implemented, but not yet tested. > > - We used Sphinx to create our python-control documentation, as previously discussed on this board. For the most part, however, we only added Sphinx-style documentation to the functions we worked on directly. Some of the docstrings in the library should be updated to this format, if it's desirable to continue using Sphinx. > > - Plotting MIMO systems has not been implemented. In the future, we envision the following common interface for most plotting routines (step, bode, impulse, ...): > > 1. return (i,j,k) array where i = # inputs, j = # outputs, k = # frequencies or times > > 2. plot=True optional argument to actually plot instead of just returning values > > 3. squeeze output so that for SISO system, return is not an (i,j,k), but rather a (k,). > > - It may be desirable to have the TransferFunction class represent SISO numerators and denominators as numpy arrays, instead of lists of lists of arrays. This might be nontrivial to implement. > > > > == LTI Class structure == > > > > As previously discussed on this board, we decided to remove the use of scipy.signal.lti as a parent class. Its restriction to SISO and SIMO systems makes it impractical to use. Therefore, we now have our own structure. The parent class, "Lti," currently only has two fields and nothing else, but this can be expanded in the future. "StateSpace" and "TransferFunction" are now child classes of "Lti," and almost have full MIMO functionality. > > > > In addition to implementing this new class structure, the classes themselves have been developed quite a bit. For instance, both StateSpace.__init__() and TransferFunction.__init__() now have guards to make sure the inputs are valid. In addition, many (but not all) functions have been expanded to support MIMO. For instance, almost all of the operator overloads in TransferFunction were completely rewritten to support MIMO; however, __div__() and __rdiv__() are not yet implemented for MIMO. See the source code for more details. Functions not completed raise NotImplementedError. > > > > == Slycot == > > > > We have wrapped five additional SLICOT functions into Slycot. These Slycot wrappers are used in h2syn(), hinfsyn(), ss2tf(), tf2ss(), and balred(). We are working with Enrico Avventi to merge our changes to his Slycot repository on github. We anticipate some iteration with Enrico before a fully integrated Slycot library is available for download. Until then, we will email a patch and instructions for use by python-control developers and users. > > > > == Unit tests == > > > > The unit tests are packaged, and can be run together using > >>>> import control > >>>> control.tests() > > > > There are a total of nine unit test files (Test*.py). Most of these should be self-explanatory. However, these may not be: > > - TestConvert.py: This file is not finished. Ideally, it would convert random state spaces back and forth between state space and transfer function form, and check that the conversions are correct. However, the conversions are sometimes buggy (see Unfinished Business below). > > - TestFreqResp.py: This is not a unit test, but can be used to check for errors and exceptions in freqresp.py and matlab.bode(). > > - TestSlycot.py: Also not a unit test. This checks for correct functionality of the ss2tf and tf2ss Slycot wrappers tb04ad and td04ad. > > > > == Functions implemented == > > > > This is a brief list of functions we either created or revised significantly. > > > > - StateSpace, TransferFunction > > - As stated above, these two classes were heavily revamped. In addition to these revisions, we added: > > - __init__(): The initializer can now also act as a copy constructor. StateSpace(ss_obj) and TransferFunction(tf_obj) perform deep copies. I believe that Python does not support assignment (=) overloading. Generally speaking, one should never use > >>>> sys1 = sys2 > > since this will be a shallow copy. > > - returnScipySignalLti: scipy.signal.lti is still useful for its few methods. For a MIMO LTI system, this function returns a list of a list of SISO scipy.signal.lti objects--one object for each element of the MIMO transfer function. We use this in lsim, step, initial, and impulse. > > - We also added some "private" methods to these two classes. (E.g., TransferFunction._truncatecoeff(), TransferFunction._common_den(), etc.) In general, these methods are for bookkeeping and do not affect the interface. > > - Random state space generation > > - rss() > > - drss() > > - the generating function _rss_generate() > > - Controllability and observability functions > > - gram() > > - obsv() > > - ctrb() > > - Model reduction tools > > - modred() > > - hsvd() > > - balred() > > - markov() > > - Synthesis tools; these have not been tested > > - h2syn() > > - hinfsyn() > > - Plotting tools > > - matlab.bode() > > - freqresp.bode() > > - default_frequency_range() > > - step() > > - impulse() > > > > == Contact == > > > > If you need to contact us in the future, email us at > > - bb...@pr... > > - sbr...@pr... > > - kk...@pr... > > - lpa...@pr... > > > > Happy coding, > > Brandt, Steve, Kevin, and Lauren > > ------------------------------------------------------------------------------ > > The modern datacenter depends on network connectivity to access resources > > and provide services. The best practices for maximizing a physical server's > > connectivity to a physical network are well understood - see how these > > rules translate into the virtual world? > > http://p.sf.net/sfu/oracle-sfdevnlfb > > _______________________________________________ > > python-control-discuss mailing list > > pyt...@li... > > https://lists.sourceforge.net/lists/listinfo/python-control-discuss > > > ------------------------------------------------------------------------------ > The modern datacenter depends on network connectivity to access resources > and provide services. The best practices for maximizing a physical server's > connectivity to a physical network are well understood - see how these > rules translate into the virtual world? > http://p.sf.net/sfu/oracle-sfdevnlfb > _______________________________________________ > python-control-discuss mailing list > pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-control-discuss > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb_______________________________________________ > python-control-discuss mailing list > pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-control-discuss |
