python-control-discuss — Discussion list for Python Control Systems Library

Re: [python-control-discuss] DARE solver in python control

[Mitchell C. <mdc...@en...>]

Richard,

I also wanted to thank you for how awesome this package is. It has been of
great help to me recently.

Mitchell

On Fri, Sep 26, 2014 at 9:55 AM, Richard Murray <mu...@cd...>
wrote:

> Great.  I've got a pull request that I hope to get to this weekend and
> then I'll probably do a new release on SourceForge (0.6e).
>
> -richard
>
> On 26 Sep 2014, at 9:54 , Mitchell Clement <mdc...@en...> wrote:
>
> > Richard,
> >
> > Thanks for your response. I was using version 0.6d from sourceForge, I
> found that this had been fixed on the latest GitHub version.
> >
> > Mitchell
> >
> > On Fri, Sep 26, 2014 at 9:49 AM, Richard Murray <mu...@cd...>
> wrote:
> > Which version of python-control are you using?  This has been fixed in
> the latest developer version (on github):
> >
> >   https://github.com/python-control/python-control/issues/8
> >
> > -richard
> >
> > On 26 Sep 2014, at 9:04 , Mitchell Clement <mdc...@en...>
> wrote:
> >
> > > All,
> > >
> > > Has anyone else noticed that the DARE solver in python control does
> not give the same solution for the discrete time algebraic riccati equation
> as MATLAB or Octave-control's  DARE solver? Thanks.
> > >
> > > Mitchell Clement
> > >
> ------------------------------------------------------------------------------
> > > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> > > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS
> Reports
> > > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> > > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> > >
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
> > > python-control-discuss mailing list
> > > pyt...@li...
> > > https://lists.sourceforge.net/lists/listinfo/python-control-discuss
> >
> >
> >
> ------------------------------------------------------------------------------
> > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> > _______________________________________________
> > python-control-discuss mailing list
> > pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/python-control-discuss
> >
> >
> ------------------------------------------------------------------------------
> > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
> > python-control-discuss mailing list
> > pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/python-control-discuss
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> python-control-discuss mailing list
> pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-control-discuss
>

Re: [python-control-discuss] DARE solver in python control

[Richard M. <mu...@cd...>]

Great.  I've got a pull request that I hope to get to this weekend and then I'll probably do a new release on SourceForge (0.6e).

-richard

On 26 Sep 2014, at 9:54 , Mitchell Clement <mdc...@en...> wrote:

> Richard,
> 
> Thanks for your response. I was using version 0.6d from sourceForge, I found that this had been fixed on the latest GitHub version.
> 
> Mitchell
> 
> On Fri, Sep 26, 2014 at 9:49 AM, Richard Murray <mu...@cd...> wrote:
> Which version of python-control are you using?  This has been fixed in the latest developer version (on github):
> 
>   https://github.com/python-control/python-control/issues/8
> 
> -richard
> 
> On 26 Sep 2014, at 9:04 , Mitchell Clement <mdc...@en...> wrote:
> 
> > All,
> >
> > Has anyone else noticed that the DARE solver in python control does not give the same solution for the discrete time algebraic riccati equation as MATLAB or Octave-control's  DARE solver? Thanks.
> >
> > Mitchell Clement
> > ------------------------------------------------------------------------------
> > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
> > python-control-discuss mailing list
> > pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/python-control-discuss
> 
> 
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> python-control-discuss mailing list
> pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-control-discuss
> 
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
> python-control-discuss mailing list
> pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-control-discuss

Re: [python-control-discuss] DARE solver in python control

[Mitchell C. <mdc...@en...>]

Richard,

Thanks for your response. I was using version 0.6d from sourceForge, I
found that this had been fixed on the latest GitHub version.

Mitchell

On Fri, Sep 26, 2014 at 9:49 AM, Richard Murray <mu...@cd...>
wrote:

> Which version of python-control are you using?  This has been fixed in the
> latest developer version (on github):
>
>   https://github.com/python-control/python-control/issues/8
>
> -richard
>
> On 26 Sep 2014, at 9:04 , Mitchell Clement <mdc...@en...> wrote:
>
> > All,
> >
> > Has anyone else noticed that the DARE solver in python control does not
> give the same solution for the discrete time algebraic riccati equation as
> MATLAB or Octave-control's  DARE solver? Thanks.
> >
> > Mitchell Clement
> >
> ------------------------------------------------------------------------------
> > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
> > python-control-discuss mailing list
> > pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/python-control-discuss
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> python-control-discuss mailing list
> pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-control-discuss
>

Re: [python-control-discuss] DARE solver in python control

[Richard M. <mu...@cd...>]

Which version of python-control are you using?  This has been fixed in the latest developer version (on github):

  https://github.com/python-control/python-control/issues/8

-richard

On 26 Sep 2014, at 9:04 , Mitchell Clement <mdc...@en...> wrote:

> All,
> 
> Has anyone else noticed that the DARE solver in python control does not give the same solution for the discrete time algebraic riccati equation as MATLAB or Octave-control's  DARE solver? Thanks.
> 
> Mitchell Clement
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
> python-control-discuss mailing list
> pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-control-discuss

[python-control-discuss] DARE solver in python control

[Mitchell C. <mdc...@en...>]

All,

Has anyone else noticed that the DARE solver in python control does not
give the same solution for the discrete time algebraic riccati equation as
MATLAB or Octave-control's  DARE solver? Thanks.

Mitchell Clement

[python-control-discuss] repository transferred to GitHub, switching use of this mailing list

[Richard M. <mu...@cd...>]

I have completed moving the python-control repository from SourceForge to GitHub.  The GitHub project is available here:

  https://github.com/python-control

I am in the process of transferring the bugs, features, etc over the GitHub.  I'll leave user discussions items on SourceForge.

I have also created the list pyt...@sf... for the active developers on the (GitHub) project.  If you are on that list, you'll get a separate note from me in a bit and start getting commit messages once I get that set up.  If you aren't on that list but plan to continue as an active developer at some point, please send me a note with your github ID.

From now on, this list will be used for general discussions of python-control, including posts from non-developers.  

-richard

[python-control-discuss] python-control repository on SourceForge is now read-only

[Richard M. <mu...@cd...>]

As described in my earlier note, I have now converted the subversion repository for python-control to be read-only, in preparation for moving the repository to github.

A reminder for people who have contributed to the code in the past or plan to contribute in the future to send me your github ID if you haven't already.

-richard

Re: [python-control-discuss] moving python-control to github

[Rene v. P. <ren...@gm...>]

I am already on github with repagh

René


On 4 August 2014 08:47, Roberto Bucher <rob...@su...> wrote:

> I created a github account:   "robertobucher"
>
> Please add me to github python-control
>
>
> Best regards
>
> Roberto
>
> On 08/04/2014 02:30 AM, Richard Murray wrote:
> > Based on the feedback that I have received so far, I'd like to proceed
> with the transfer of the python-control source repository and issues
> tracking from SourceForge to Github.  There is a project already set up to
> handle this at
> >
> >    https://github.com/python-control
> >
> > I propose the following timeline to implement this:
> >
> > * 4-6 Aug 2014 (Mon-Wed): add everyone with a github account who is a
> current developer for python-control to the developer list for the
> python-control project on Github.  The goal would be to complete this by
> Wed, so that we can use this information to preserve some of the commit
> logs by mapping contributions from SourceForge IDs to Github IDs.
> >
> > ⇒ Requested action: if you are current python-control developer, please
> send me your github ID (creating one if needed).
> >
> > * 6 Aug 2014 (Wed), ~8 am PDT: move sourceforge/python-control to
> read-only access, so that the repository is stable.  Any commits by current
> developers should be done before this date.
> >
> > ⇒ Requested action: if you have any code that you are developing that is
> not currently committed to the repository, please commit to either trunk or
> branches by 6 Aug 2014 (Wed) at 8 am PDT.  Everything that is in the
> subversion repository on SourceForge should be preserved as long as it is
> committed by that date and time.
> >
> > * 6-8 Aug 2014 (Wed-Fri): move repository + issues over to Github, using
> the procedure outlined below (from Scott Livingston).  During this time,
> python-control will still be available for read-only checkout from
> SourceForge, but developers should wait until the weekend before checking
> out a git version for modifications.
> >
> > * 9 Aug 2014 (Sat): python-control becomes available via Github for read
> access (anyone) and write access (developers). Mailing lists and release
> snapshots remain on SourceForge.
> >
> > * 9 Aug 2014 (Sat): create a new mailing list called
> python-control-developers for the list of people who are active developers
> and open up access to python-control-discuss so that anyone can post.  The
> developers list will get e-mail on commits and be used for other detailed
> discussions (like this one); the discussion list will be used for
> discussions of features, problems, etc with users of python control, as
> needed.  (Several people have requested being added to the discuss list for
> this purpose.)
> >
> > * Later: remove repository and issues from SourceForge, leaving only the
> mailing lists and version snapshots.
> >
> > Please let me know if you have any issues/conflicts with the proposed
> timeline.  We can always back up at just about any point if needed, but
> once people start developing on Github then we obviously can't go back to
> SourceForge or subversion without losing some work.
> >
> > -richard
> >
> > On 3 Aug 2014, at 11:02 , Scott C. Livingston <
> sli...@cd...> wrote:
> >
> >> Below are instructions including links to further reading.
> >>
> >> 1. backup everything
> >>
> >> You should obtain a complete copy of the subversion repository (server
> >> side) using
> >>
> >>    $ rsync -av svn.code.sf.net::p/python-control/code .
> >>
> >> and all of the project site content by clicking the "Export" button from
> >> the Admin panel at
> >>
> >>    https://sourceforge.net/p/python-control/admin/export
> >>
> >> The latter is delivered as JSON (http://json.org) files and includes
> all
> >> bug reports, feature requests, etc.  You can test your copy of the
> >> repository by checking it out locally, e.g., from the directory where
> >> you ran rsync, try
> >>
> >>    $ svn co file://`pwd`/code try-co
> >>
> >>
> >> 2. repository (abbreviated as "repo" below)
> >>
> >> http://git-scm.com/book/en/Git-and-Other-Systems-Migrating-to-Git
> >>
> >> The primary difficulties are:
> >> a. mapping usernames associated with svn commits to committers and
> >> authors in the git repo;
> >> b. converting branches in svn to branches in the git repo;
> >> c. converting tags in svn to tags in the git repo;
> >> d. moving properties to the git configuration files; e.g., svn:ignore
> >> properties should be changed into .gitignore files.
> >>
> >> #b and #c are automated, though sometimes you must make manual
> >> corrections.  A method for achieving #a is described in the URL given
> >> above to S. Chacon's book "Pro Git".
> >>
> >> As for the repo on SourceForge.net, I recommend that you freeze it for a
> >> while before deleting it.  By "freeze it" I mean change to read-only
> >> access, so that `svn checkout` would succeed but `svn commit` would
> fail.
> >>
> >>
> >> 3. issue trackers
> >>
> >> There are scripts to automate transfer of bug reports, feature requests,
> >> and other "tickets" on SourceForge.net, but I prefer to do it manually
> >> because I can
> >>
> >> a. replace SourceForge.net handles with GitHub.com handles (when the
> >> person has an account on both); and
> >> b. review all open issues.
> >>
> >> All of the tickets on SourceForge can have file attachments, but issues
> >> on GitHub cannot have attachments.  However, I just skimmed several of
> >> the tickets for python-control and did not notice attachments.  If any
> >> are found, one solution is to open an issue and paste the file into the
> >> text of the issue.
> >>
> >> 4. wiki
> >>
> >> Both GitHub and SourceForge use Markdown syntax with extensions, so
> >> moving the wiki should be as easy as copy-and-paste and then modify
> >> special items, e.g., change [[download_button]] to
> >> [download](
> https://sourceforge.net/projects/python-control/files/latest/download).
> > ...
> >> 5. Commit e-mails
> >>
> >> If you still want repository commits to be echoed to the mailing list,
> >> then a "service" [1] will need to be added.  Based on my guess of the
> >> future name of the repository, try the direct link
> >>
> >>
> https://github.com/python-control/python-control/settings/hooks/new?service=email
> >>
> >> If that link fails, go to the repository page on GitHub, click the
> >> "Settings" button the right side, and then click "Webhooks & Services"
> >> on the left.  Click the "Add service" button and select "Email".
> >
> ------------------------------------------------------------------------------
> > Infragistics Professional
> > Build stunning WinForms apps today!
> > Reboot your WinForms applications with our WinForms controls.
> > Build a bridge from your legacy apps to the future.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> > _______________________________________________
> > python-control-discuss mailing list
> > pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/python-control-discuss
>
>
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> python-control-discuss mailing list
> pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-control-discuss
>



-- 
René van Paassen        | ______o____/_|     Ren...@gm...
                       <[___\_\_-----<               t: +31 15 2628685
                        |  o'                   mobile: +31 6 39846891

Re: [python-control-discuss] moving python-control to github

[Roberto B. <rob...@su...>]

I created a github account:   "robertobucher"

Please add me to github python-control


Best regards

Roberto

On 08/04/2014 02:30 AM, Richard Murray wrote:
> Based on the feedback that I have received so far, I'd like to proceed with the transfer of the python-control source repository and issues tracking from SourceForge to Github.  There is a project already set up to handle this at
>
>    https://github.com/python-control
>
> I propose the following timeline to implement this:
>
> * 4-6 Aug 2014 (Mon-Wed): add everyone with a github account who is a current developer for python-control to the developer list for the python-control project on Github.  The goal would be to complete this by Wed, so that we can use this information to preserve some of the commit logs by mapping contributions from SourceForge IDs to Github IDs.
>
> ⇒ Requested action: if you are current python-control developer, please send me your github ID (creating one if needed).
>
> * 6 Aug 2014 (Wed), ~8 am PDT: move sourceforge/python-control to read-only access, so that the repository is stable.  Any commits by current developers should be done before this date.
>
> ⇒ Requested action: if you have any code that you are developing that is not currently committed to the repository, please commit to either trunk or branches by 6 Aug 2014 (Wed) at 8 am PDT.  Everything that is in the subversion repository on SourceForge should be preserved as long as it is committed by that date and time.
>
> * 6-8 Aug 2014 (Wed-Fri): move repository + issues over to Github, using the procedure outlined below (from Scott Livingston).  During this time, python-control will still be available for read-only checkout from SourceForge, but developers should wait until the weekend before checking out a git version for modifications.
>
> * 9 Aug 2014 (Sat): python-control becomes available via Github for read access (anyone) and write access (developers). Mailing lists and release snapshots remain on SourceForge.
>
> * 9 Aug 2014 (Sat): create a new mailing list called python-control-developers for the list of people who are active developers and open up access to python-control-discuss so that anyone can post.  The developers list will get e-mail on commits and be used for other detailed discussions (like this one); the discussion list will be used for discussions of features, problems, etc with users of python control, as needed.  (Several people have requested being added to the discuss list for this purpose.)
>
> * Later: remove repository and issues from SourceForge, leaving only the mailing lists and version snapshots.
>
> Please let me know if you have any issues/conflicts with the proposed timeline.  We can always back up at just about any point if needed, but once people start developing on Github then we obviously can't go back to SourceForge or subversion without losing some work.
>
> -richard
>
> On 3 Aug 2014, at 11:02 , Scott C. Livingston <sli...@cd...> wrote:
>
>> Below are instructions including links to further reading.
>>
>> 1. backup everything
>>
>> You should obtain a complete copy of the subversion repository (server
>> side) using
>>
>>    $ rsync -av svn.code.sf.net::p/python-control/code .
>>
>> and all of the project site content by clicking the "Export" button from
>> the Admin panel at
>>
>>    https://sourceforge.net/p/python-control/admin/export
>>
>> The latter is delivered as JSON (http://json.org) files and includes all
>> bug reports, feature requests, etc.  You can test your copy of the
>> repository by checking it out locally, e.g., from the directory where
>> you ran rsync, try
>>
>>    $ svn co file://`pwd`/code try-co
>>
>>
>> 2. repository (abbreviated as "repo" below)
>>
>> http://git-scm.com/book/en/Git-and-Other-Systems-Migrating-to-Git
>>
>> The primary difficulties are:
>> a. mapping usernames associated with svn commits to committers and
>> authors in the git repo;
>> b. converting branches in svn to branches in the git repo;
>> c. converting tags in svn to tags in the git repo;
>> d. moving properties to the git configuration files; e.g., svn:ignore
>> properties should be changed into .gitignore files.
>>
>> #b and #c are automated, though sometimes you must make manual
>> corrections.  A method for achieving #a is described in the URL given
>> above to S. Chacon's book "Pro Git".
>>
>> As for the repo on SourceForge.net, I recommend that you freeze it for a
>> while before deleting it.  By "freeze it" I mean change to read-only
>> access, so that `svn checkout` would succeed but `svn commit` would fail.
>>
>>
>> 3. issue trackers
>>
>> There are scripts to automate transfer of bug reports, feature requests,
>> and other "tickets" on SourceForge.net, but I prefer to do it manually
>> because I can
>>
>> a. replace SourceForge.net handles with GitHub.com handles (when the
>> person has an account on both); and
>> b. review all open issues.
>>
>> All of the tickets on SourceForge can have file attachments, but issues
>> on GitHub cannot have attachments.  However, I just skimmed several of
>> the tickets for python-control and did not notice attachments.  If any
>> are found, one solution is to open an issue and paste the file into the
>> text of the issue.
>>
>> 4. wiki
>>
>> Both GitHub and SourceForge use Markdown syntax with extensions, so
>> moving the wiki should be as easy as copy-and-paste and then modify
>> special items, e.g., change [[download_button]] to
>> [download](https://sourceforge.net/projects/python-control/files/latest/download).
> ...
>> 5. Commit e-mails
>>
>> If you still want repository commits to be echoed to the mailing list,
>> then a "service" [1] will need to be added.  Based on my guess of the
>> future name of the repository, try the direct link
>>
>> https://github.com/python-control/python-control/settings/hooks/new?service=email
>>
>> If that link fails, go to the repository page on GitHub, click the
>> "Settings" button the right side, and then click "Webhooks & Services"
>> on the left.  Click the "Add service" button and select "Email".
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> python-control-discuss mailing list
> pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-control-discuss

[python-control-discuss] moving python-control to github

[Richard M. <mu...@cd...>]

Based on the feedback that I have received so far, I'd like to proceed with the transfer of the python-control source repository and issues tracking from SourceForge to Github.  There is a project already set up to handle this at

  https://github.com/python-control

I propose the following timeline to implement this:

* 4-6 Aug 2014 (Mon-Wed): add everyone with a github account who is a current developer for python-control to the developer list for the python-control project on Github.  The goal would be to complete this by Wed, so that we can use this information to preserve some of the commit logs by mapping contributions from SourceForge IDs to Github IDs.  

⇒ Requested action: if you are current python-control developer, please send me your github ID (creating one if needed).

* 6 Aug 2014 (Wed), ~8 am PDT: move sourceforge/python-control to read-only access, so that the repository is stable.  Any commits by current developers should be done before this date.

⇒ Requested action: if you have any code that you are developing that is not currently committed to the repository, please commit to either trunk or branches by 6 Aug 2014 (Wed) at 8 am PDT.  Everything that is in the subversion repository on SourceForge should be preserved as long as it is committed by that date and time.

* 6-8 Aug 2014 (Wed-Fri): move repository + issues over to Github, using the procedure outlined below (from Scott Livingston).  During this time, python-control will still be available for read-only checkout from SourceForge, but developers should wait until the weekend before checking out a git version for modifications.

* 9 Aug 2014 (Sat): python-control becomes available via Github for read access (anyone) and write access (developers). Mailing lists and release snapshots remain on SourceForge.  

* 9 Aug 2014 (Sat): create a new mailing list called python-control-developers for the list of people who are active developers and open up access to python-control-discuss so that anyone can post.  The developers list will get e-mail on commits and be used for other detailed discussions (like this one); the discussion list will be used for discussions of features, problems, etc with users of python control, as needed.  (Several people have requested being added to the discuss list for this purpose.)

* Later: remove repository and issues from SourceForge, leaving only the mailing lists and version snapshots.

Please let me know if you have any issues/conflicts with the proposed timeline.  We can always back up at just about any point if needed, but once people start developing on Github then we obviously can't go back to SourceForge or subversion without losing some work.

-richard

On 3 Aug 2014, at 11:02 , Scott C. Livingston <sli...@cd...> wrote:

> Below are instructions including links to further reading.
> 
> 1. backup everything
> 
> You should obtain a complete copy of the subversion repository (server
> side) using
> 
>   $ rsync -av svn.code.sf.net::p/python-control/code .
> 
> and all of the project site content by clicking the "Export" button from
> the Admin panel at
> 
>   https://sourceforge.net/p/python-control/admin/export
> 
> The latter is delivered as JSON (http://json.org) files and includes all
> bug reports, feature requests, etc.  You can test your copy of the
> repository by checking it out locally, e.g., from the directory where
> you ran rsync, try
> 
>   $ svn co file://`pwd`/code try-co
> 
> 
> 2. repository (abbreviated as "repo" below)
> 
> http://git-scm.com/book/en/Git-and-Other-Systems-Migrating-to-Git
> 
> The primary difficulties are:
> a. mapping usernames associated with svn commits to committers and
> authors in the git repo;
> b. converting branches in svn to branches in the git repo;
> c. converting tags in svn to tags in the git repo;
> d. moving properties to the git configuration files; e.g., svn:ignore
> properties should be changed into .gitignore files.
> 
> #b and #c are automated, though sometimes you must make manual
> corrections.  A method for achieving #a is described in the URL given
> above to S. Chacon's book "Pro Git".
> 
> As for the repo on SourceForge.net, I recommend that you freeze it for a
> while before deleting it.  By "freeze it" I mean change to read-only
> access, so that `svn checkout` would succeed but `svn commit` would fail.
> 
> 
> 3. issue trackers
> 
> There are scripts to automate transfer of bug reports, feature requests,
> and other "tickets" on SourceForge.net, but I prefer to do it manually
> because I can
> 
> a. replace SourceForge.net handles with GitHub.com handles (when the
> person has an account on both); and
> b. review all open issues.
> 
> All of the tickets on SourceForge can have file attachments, but issues
> on GitHub cannot have attachments.  However, I just skimmed several of
> the tickets for python-control and did not notice attachments.  If any
> are found, one solution is to open an issue and paste the file into the
> text of the issue.
> 
> 4. wiki
> 
> Both GitHub and SourceForge use Markdown syntax with extensions, so
> moving the wiki should be as easy as copy-and-paste and then modify
> special items, e.g., change [[download_button]] to
> [download](https://sourceforge.net/projects/python-control/files/latest/download).
...
> 5. Commit e-mails
> 
> If you still want repository commits to be echoed to the mailing list,
> then a "service" [1] will need to be added.  Based on my guess of the
> future name of the repository, try the direct link
> 
> https://github.com/python-control/python-control/settings/hooks/new?service=email
> 
> If that link fails, go to the repository page on GitHub, click the
> "Settings" button the right side, and then click "Webhooks & Services"
> on the left.  Click the "Add service" button and select "Email".

Re: [python-control-discuss] SourceForge Repo Clone Complete

[Jason M. <moo...@gm...>]

+1 to moving to github. I believe that many projects find that their
software is used more and that the number of contributors grows when
switching to github (or other distributed version control systems with nice
interactive web interfaces).


Jason
moorepants.info
+01 530-601-9791


On Mon, Jul 28, 2014 at 7:12 AM, Clancy Rowley <cwr...@pr...>
wrote:

> This all sounds very sensible to me.  I am strongly in favor of moving to
> GitHub, and I think the combination of GitHub for hosting the repository
> and SourceForge for hosting the releases and mailing lists is a good one.
>  It seems to be used by a number of other projects besides matplotlib too:
> for instance, scikit-learn is a popular package for machine learning tools,
> and it looks like that is what they do:
>         https://scikits.appspot.com/scikit-learn
>
> -clancy
>
> On Jul 27, 2014, at 2:33 PM, Richard Murray <mu...@cd...>
> wrote:
>
> > Spurred by Clancy's discussion about SciPy, I wanted to bring up again
> the idea of switching python-control over to git and/or github.  I'm
> attaching below part of a discussion on this list that had a summary that
> Andrew Straw sent out.
> >
> > Here is one possible approach that we are using with pretty good success
> on another project:
> >
> > * We move the control-python code over to github.  I already have set up
> a project on github for this (a long time ago) and James Goppert has a
> clone on github => we could basically clone James's version into the
> project directory and then set everyone up as developers.
> >
> > * We use github feature/bug lists for developers.  I find the
> functionality that github provides to be quite good, including the ability
> to reference commit's in posts.
> >
> > * We leave the tarballs for python-control releases and copies of user
> manuals on sourceforge.  This is constant with the matplotlib approach that
> Andrew describes below.  As far as I know, github does not provide this
> functionality.
> >
> > * We leave the mailing lists for the project on SourceForge.  Near as I
> can tell, github doesn't have good functionality here.  I would also
> suggest that we reorganize the lists just a bit:
> >
> > - python-control-announce: use for announcements of new releases,
> features
> > - python-control-discuss: use for user discussions about python-control
> (i.e., re-purpose this mailing list)
> > - python-control-developers: use for developer discussions about
> python-control (new list)
> >
> > The reason for re-purposing the discuss list is that a couple of people
> have contacted me about wanting to discuss features, but aren't really
> interested in developer traffic (e.g., e-mails on commits).
> >
> > * We eventually use the python-control project on github as the master
> copy for PyPI and also for code coverage testing.  James Goppert has this
> running on his version, so hopefully he would be willing to just switch
> things over for us and also keep maintaining that functionality.
> >
> > It would be great to get some comments on this from anyone who has an
> opinion!
> >
> > -richard
> >
> > On 5 Sep 2012, at 1:31 , Andrew Straw <str...@as...> wrote:
> >
> >> On 09/05/2012 08:10 AM, Richard Murray wrote:
> >>> There hasn't been much conversation about this, but converting to git
> is probably the way to go in the long run (better functionality for
> distributed development).  Sourceforge supports git and we can easily
> transfer projects from subversion to git:
> >>>
> >>>
> >>> https://sourceforge.net/apps/trac/sourceforge/ticket/24534
> >>>
> >>>
> >>> I don't have much experience with github versus sourceforge in terms
> of the various features, and so don't have a strong preference beyond doing
> whatever works best for the people who are actively developing code for the
> library.
> >>>
> >>
> >> As an example, when matplotlib switched from the code repository using
> svn + sourceforce to git + github, there was a dramatic increase in
> contributions. MPL continues to use sourceforge for the email lists. The
> issue tracking was later switched to github, despite some missing
> functionality, in order to have integration with the version control system
> (having "closed issue" messages linked to the commit that closed them). All
> that said, these data are from some time ago (2 years, approximately) --
> since that time, sourceforge seems to have made some dramatic changes
> (adding git, revising their issue tracking system) and I cannot fairly
> compare sourceforge's current offerings. See
> https://github.com/matplotlib/matplotlib for the MPL github respository.
> So, my evidence is that your criterion of "whatever works best for the
> people who are actively developing code for the library" will be best
> served by moving to github because you'll gain new contributors. This was
> more-or-le!
> > ss the discussion we had in the matplotlib email list and, although I
> haven't quantified it, the evidence of new contributors is very clear.
> >>
> >> You'll also gain resonance with similar minds using similar tools and
> also possibly interested in python-control, thus increasing the likely
> number of high-quality contributions. Here are some projects that all use
> github as their primary repository as far as I know:
> >>
> >> * numpy https://github.com/numpy/numpy
> >> * IPython https://github.com/ipython/ipython
> >> * sympy https://github.com/sympy/sympy
> >> * scipy https://github.com/scipy/scipy
> >> * ROS https://github.com/ros
> >>
> >> As far as how to switch to github, I guess the easiest way, if SF
> offers a "convert this repository to git" button, is to press that button
> and then clone the SF repository to your local computer, create a github
> repository and then push your local repository onto github. (Then maybe
> delete the SF one or at least block writing to it.)
> >>
> >> -Andrew
> >>
> >>
> ------------------------------------------------------------------------------
> >> Live Security Virtual Conference
> >> Exclusive live event will cover all the ways today's security and
> >> threat landscape has changed and how IT managers can respond.
> Discussions
> >> will include endpoint security, mobile security and the latest in
> malware
> >> threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> >> python-control-discuss mailing list
> >> pyt...@li...
> >> https://lists.sourceforge.net/lists/listinfo/python-control-discuss
> >
> >
> >
> ------------------------------------------------------------------------------
> > Want fast and easy access to all the code in your enterprise? Index and
> > search up to 200,000 lines of code with a free copy of Black Duck
> > Code Sight - the same software that powers the world's largest code
> > search on Ohloh, the Black Duck Open Hub! Try it now.
> > http://p.sf.net/sfu/bds
> > _______________________________________________
> > python-control-discuss mailing list
> > pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/python-control-discuss
>
>
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> python-control-discuss mailing list
> pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-control-discuss
>

Re: [python-control-discuss] SourceForge Repo Clone Complete

[Clancy R. <cwr...@pr...>]

This all sounds very sensible to me.  I am strongly in favor of moving to GitHub, and I think the combination of GitHub for hosting the repository and SourceForge for hosting the releases and mailing lists is a good one.  It seems to be used by a number of other projects besides matplotlib too: for instance, scikit-learn is a popular package for machine learning tools, and it looks like that is what they do:
	https://scikits.appspot.com/scikit-learn

-clancy

On Jul 27, 2014, at 2:33 PM, Richard Murray <mu...@cd...> wrote:

> Spurred by Clancy's discussion about SciPy, I wanted to bring up again the idea of switching python-control over to git and/or github.  I'm attaching below part of a discussion on this list that had a summary that Andrew Straw sent out.
> 
> Here is one possible approach that we are using with pretty good success on another project:
> 
> * We move the control-python code over to github.  I already have set up a project on github for this (a long time ago) and James Goppert has a clone on github => we could basically clone James's version into the project directory and then set everyone up as developers.
> 
> * We use github feature/bug lists for developers.  I find the functionality that github provides to be quite good, including the ability to reference commit's in posts.
> 
> * We leave the tarballs for python-control releases and copies of user manuals on sourceforge.  This is constant with the matplotlib approach that Andrew describes below.  As far as I know, github does not provide this functionality.
> 
> * We leave the mailing lists for the project on SourceForge.  Near as I can tell, github doesn't have good functionality here.  I would also suggest that we reorganize the lists just a bit:
> 
> - python-control-announce: use for announcements of new releases, features
> - python-control-discuss: use for user discussions about python-control (i.e., re-purpose this mailing list)
> - python-control-developers: use for developer discussions about python-control (new list)
> 
> The reason for re-purposing the discuss list is that a couple of people have contacted me about wanting to discuss features, but aren't really interested in developer traffic (e.g., e-mails on commits).
> 
> * We eventually use the python-control project on github as the master copy for PyPI and also for code coverage testing.  James Goppert has this running on his version, so hopefully he would be willing to just switch things over for us and also keep maintaining that functionality.
> 
> It would be great to get some comments on this from anyone who has an opinion!
> 
> -richard
> 
> On 5 Sep 2012, at 1:31 , Andrew Straw <str...@as...> wrote:
> 
>> On 09/05/2012 08:10 AM, Richard Murray wrote:
>>> There hasn't been much conversation about this, but converting to git is probably the way to go in the long run (better functionality for distributed development).  Sourceforge supports git and we can easily transfer projects from subversion to git:
>>> 
>>> 
>>> https://sourceforge.net/apps/trac/sourceforge/ticket/24534
>>> 
>>> 
>>> I don't have much experience with github versus sourceforge in terms of the various features, and so don't have a strong preference beyond doing whatever works best for the people who are actively developing code for the library.
>>> 
>> 
>> As an example, when matplotlib switched from the code repository using svn + sourceforce to git + github, there was a dramatic increase in contributions. MPL continues to use sourceforge for the email lists. The issue tracking was later switched to github, despite some missing functionality, in order to have integration with the version control system (having "closed issue" messages linked to the commit that closed them). All that said, these data are from some time ago (2 years, approximately) -- since that time, sourceforge seems to have made some dramatic changes (adding git, revising their issue tracking system) and I cannot fairly compare sourceforge's current offerings. See https://github.com/matplotlib/matplotlib for the MPL github respository. So, my evidence is that your criterion of "whatever works best for the people who are actively developing code for the library" will be best served by moving to github because you'll gain new contributors. This was more-or-le!
> ss the discussion we had in the matplotlib email list and, although I haven't quantified it, the evidence of new contributors is very clear.
>> 
>> You'll also gain resonance with similar minds using similar tools and also possibly interested in python-control, thus increasing the likely number of high-quality contributions. Here are some projects that all use github as their primary repository as far as I know:
>> 
>> * numpy https://github.com/numpy/numpy
>> * IPython https://github.com/ipython/ipython
>> * sympy https://github.com/sympy/sympy
>> * scipy https://github.com/scipy/scipy
>> * ROS https://github.com/ros
>> 
>> As far as how to switch to github, I guess the easiest way, if SF offers a "convert this repository to git" button, is to press that button and then clone the SF repository to your local computer, create a github repository and then push your local repository onto github. (Then maybe delete the SF one or at least block writing to it.)
>> 
>> -Andrew
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and 
>> threat landscape has changed and how IT managers can respond. Discussions 
>> will include endpoint security, mobile security and the latest in malware 
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
>> python-control-discuss mailing list
>> pyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/python-control-discuss
> 
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> python-control-discuss mailing list
> pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-control-discuss

Re: [python-control-discuss] SourceForge Repo Clone Complete

[Scott C. L. <sli...@cd...>]

On 27/07/14 11:33, Richard Murray wrote:
> * We leave the tarballs for python-control releases and copies of user manuals on sourceforge.  This is constant with the matplotlib approach that Andrew describes below.  As far as I know, github does not provide this functionality.

GitHub provides capabilities for releases and project websites:

1. https://help.github.com/articles/about-releases
2. https://help.github.com/articles/what-are-github-pages

A significant alternative to hosting manuals on GitHub Pages or
SourceForge.net is "Read the Docs" (https://readthedocs.org/), which
easily hosts documentation for multiple releases and provides export
mechanisms (e.g., to PDF).  For an example, try
https://virtualenv.readthedocs.org/

I discourage using GitHub for distributing releases because GitHub
previously has gone through a cycle of offering it, then removing it
[1], and then allowing releases again [2].


[1] https://github.com/blog/1302-goodbye-uploads
[2] https://github.com/blog/1547-release-your-software

Re: [python-control-discuss] SourceForge Repo Clone Complete

[Richard M. <mu...@cd...>]

Spurred by Clancy's discussion about SciPy, I wanted to bring up again the idea of switching python-control over to git and/or github.  I'm attaching below part of a discussion on this list that had a summary that Andrew Straw sent out.

Here is one possible approach that we are using with pretty good success on another project:

* We move the control-python code over to github.  I already have set up a project on github for this (a long time ago) and James Goppert has a clone on github => we could basically clone James's version into the project directory and then set everyone up as developers.

* We use github feature/bug lists for developers.  I find the functionality that github provides to be quite good, including the ability to reference commit's in posts.

* We leave the tarballs for python-control releases and copies of user manuals on sourceforge.  This is constant with the matplotlib approach that Andrew describes below.  As far as I know, github does not provide this functionality.

* We leave the mailing lists for the project on SourceForge.  Near as I can tell, github doesn't have good functionality here.  I would also suggest that we reorganize the lists just a bit:

- python-control-announce: use for announcements of new releases, features
- python-control-discuss: use for user discussions about python-control (i.e., re-purpose this mailing list)
- python-control-developers: use for developer discussions about python-control (new list)

The reason for re-purposing the discuss list is that a couple of people have contacted me about wanting to discuss features, but aren't really interested in developer traffic (e.g., e-mails on commits).

* We eventually use the python-control project on github as the master copy for PyPI and also for code coverage testing.  James Goppert has this running on his version, so hopefully he would be willing to just switch things over for us and also keep maintaining that functionality.

It would be great to get some comments on this from anyone who has an opinion!

-richard

On 5 Sep 2012, at 1:31 , Andrew Straw <str...@as...> wrote:

> On 09/05/2012 08:10 AM, Richard Murray wrote:
>> There hasn't been much conversation about this, but converting to git is probably the way to go in the long run (better functionality for distributed development).  Sourceforge supports git and we can easily transfer projects from subversion to git:
>> 
>>   
>> https://sourceforge.net/apps/trac/sourceforge/ticket/24534
>> 
>> 
>> I don't have much experience with github versus sourceforge in terms of the various features, and so don't have a strong preference beyond doing whatever works best for the people who are actively developing code for the library.
>> 
> 
> As an example, when matplotlib switched from the code repository using svn + sourceforce to git + github, there was a dramatic increase in contributions. MPL continues to use sourceforge for the email lists. The issue tracking was later switched to github, despite some missing functionality, in order to have integration with the version control system (having "closed issue" messages linked to the commit that closed them). All that said, these data are from some time ago (2 years, approximately) -- since that time, sourceforge seems to have made some dramatic changes (adding git, revising their issue tracking system) and I cannot fairly compare sourceforge's current offerings. See https://github.com/matplotlib/matplotlib for the MPL github respository. So, my evidence is that your criterion of "whatever works best for the people who are actively developing code for the library" will be best served by moving to github because you'll gain new contributors. This was more-or-less the discussion we had in the matplotlib email list and, although I haven't quantified it, the evidence of new contributors is very clear.
> 
> You'll also gain resonance with similar minds using similar tools and also possibly interested in python-control, thus increasing the likely number of high-quality contributions. Here are some projects that all use github as their primary repository as far as I know:
> 
> * numpy https://github.com/numpy/numpy
> * IPython https://github.com/ipython/ipython
> * sympy https://github.com/sympy/sympy
> * scipy https://github.com/scipy/scipy
> * ROS https://github.com/ros
> 
> As far as how to switch to github, I guess the easiest way, if SF offers a "convert this repository to git" button, is to press that button and then clone the SF repository to your local computer, create a github repository and then push your local repository onto github. (Then maybe delete the SF one or at least block writing to it.)
> 
> -Andrew
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> python-control-discuss mailing list
> pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-control-discuss

[python-control-discuss] SF.net python-control commit:[305] trunk

[<re...@us...>]

Revision: 305
          http://sourceforge.net/p/python-control/code/305
Author:   repa
Date:     2014-07-08 10:59:01 +0000 (Tue, 08 Jul 2014)
Log Message:
-----------
corrected comments on time responses, with the "input" parameter to be
ignored on initial response calculation; initial response does not depend
on input!

Modified Paths:
--------------
    trunk/src/matlab.py
    trunk/src/timeresp.py
    trunk/tests/matlab_test.py
    trunk/tests/timeresp_test.py

Modified: trunk/src/matlab.py
===================================================================
--- trunk/src/matlab.py	2014-07-08 10:57:18 UTC (rev 304)
+++ trunk/src/matlab.py	2014-07-08 10:59:01 UTC (rev 305)
@@ -1103,8 +1103,8 @@
     """Root locus plot
 
     The root-locus plot has a callback function that prints pole location, 
-    gain and damping to the Python consol on mouseclicks on the root-locus 
-    graph.
+    gain and damping to the Python console on mouseclicks on the root-locus 
+    graph. 
 
     Parameters
     ----------
@@ -1112,6 +1112,9 @@
         Linear system
     klist: 
         optional list of gains
+
+    Keyword parameters
+    ------------------
     xlim : control of x-axis range, normally with tuple, for
         other options, see matplotlib.axes
     ylim : control of y-axis range
@@ -1165,7 +1168,7 @@
     margin: no magnitude crossings found
     
     .. todo:: 
-        better ecample system!
+        better example system!
         
         #>>> gm, pm, wg, wp = margin(mag, phase, w)
     """
@@ -1178,7 +1181,7 @@
         raise ValueError("Margin needs 1 or 3 arguments; received %i." 
             % len(args))
             
-    return margin[0], margin[1], margin[4], margin[3]
+    return margin[0], margin[1], margin[3], margin[4]
 
 def dcgain(*args):
     '''
@@ -1279,10 +1282,11 @@
     '''
     Step response of a linear system
     
-    If the system has multiple inputs or outputs (MIMO), one input and one 
-    output have to be selected for the simulation. The parameters `input` 
-    and `output` do this. All other inputs are set to 0, all other outputs 
-    are ignored.
+    If the system has multiple inputs or outputs (MIMO), one input has
+    to be selected for the simulation.  Optionally, one output may be
+    selected. If no selection is made for the output, all outputs are
+    given. The parameters `input` and `output` do this. All other
+    inputs are set to 0, all other outputs are ignored.
     
     Parameters
     ----------
@@ -1301,7 +1305,7 @@
         Index of the input that will be used in this simulation.
 
     output: int
-        Index of the output that will be used in this simulation.
+        If given, index of the output that is returned by this simulation.
 
     **keywords:
         Additional keyword arguments control the solution algorithm for the 
@@ -1326,19 +1330,21 @@
     Examples
     --------
     >>> yout, T = step(sys, T, X0)
+
     '''
     T, yout = timeresp.step_response(sys, T, X0, input, output, 
-                                   transpose = True, **keywords)
+                                     transpose=True, **keywords)
     return yout, T
 
-def impulse(sys, T=None, input=0, output=0, **keywords):
+def impulse(sys, T=None, input=0, output=None, **keywords):
     '''
     Impulse response of a linear system
     
-    If the system has multiple inputs or outputs (MIMO), one input and
-    one output must be selected for the simulation. The parameters
-    `input` and `output` do this. All other inputs are set to 0, all
-    other outputs are ignored.
+    If the system has multiple inputs or outputs (MIMO), one input has
+    to be selected for the simulation.  Optionally, one output may be
+    selected. If no selection is made for the output, all outputs are
+    given. The parameters `input` and `output` do this. All other
+    inputs are set to 0, all other outputs are ignored.
     
     Parameters
     ----------
@@ -1381,14 +1387,13 @@
                                    transpose = True, **keywords)
     return yout, T
 
-def initial(sys, T=None, X0=0., input=0, output=0, **keywords):
+def initial(sys, T=None, X0=0., input=None, output=None, **keywords):
     '''
     Initial condition response of a linear system
     
-    If the system has multiple inputs or outputs (MIMO), one input and one 
-    output have to be selected for the simulation. The parameters `input` 
-    and `output` do this. All other inputs are set to 0, all other outputs 
-    are ignored.
+    If the system has multiple outputs (?IMO), optionally, one output
+    may be selected. If no selection is made for the output, all
+    outputs are given.
     
     Parameters
     ----------
@@ -1404,10 +1409,11 @@
         Numbers are converted to constant arrays with the correct shape.
 
     input: int
-        Index of the input that will be used in this simulation.
+        This input is ignored, but present for compatibility with step
+        and impulse.
 
     output: int
-        Index of the output that will be used in this simulation.
+        If given, index of the output that is returned by this simulation.
 
     **keywords:
         Additional keyword arguments control the solution algorithm for the 
@@ -1432,9 +1438,10 @@
     Examples
     --------
     >>> T, yout = initial(sys, T, X0)
+
     '''
-    T, yout = timeresp.initial_response(sys, T, X0, input, output, 
-                                   transpose = True, **keywords)
+    T, yout = timeresp.initial_response(sys, T, X0, output=output, 
+                                        transpose=True, **keywords)
     return yout, T
 
 def lsim(sys, U=0., T=None, X0=0., **keywords):

Modified: trunk/src/timeresp.py
===================================================================
--- trunk/src/timeresp.py	2014-07-08 10:57:18 UTC (rev 304)
+++ trunk/src/timeresp.py	2014-07-08 10:59:01 UTC (rev 305)
@@ -389,7 +389,8 @@
 def step_response(sys, T=None, X0=0., input=0, output=None,
                   transpose = False, **keywords):
     #pylint: disable=W0622
-    """Step response of a linear system
+    """
+    Step response of a linear system
     
     If the system has multiple inputs or outputs (MIMO), one input has
     to be selected for the simulation. Optionally, one output may be
@@ -468,15 +469,14 @@
     return T, yout
 
 
-def initial_response(sys, T=None, X0=0., input=0, output=None, transpose=False,
-                     **keywords):
+def initial_response(sys, T=None, X0=0., input=None, output=None, 
+                     transpose=False, **keywords):
     #pylint: disable=W0622
     """Initial condition response of a linear system
     
-    If the system has multiple inputs or outputs (MIMO), one input and one 
-    output have to be selected for the simulation. The parameters `input` 
-    and `output` do this. All other inputs are set to 0, all other outputs 
-    are ignored.
+    If the system has multiple outputs (?IMO), optionally, one output
+    may be selected. If no selection is made for the output, all
+    outputs are given.
     
     For information on the **shape** of parameters `T`, `X0` and 
     return values `T`, `yout` see: :ref:`time-series-convention`
@@ -495,7 +495,8 @@
         Numbers are converted to constant arrays with the correct shape.
 
     input: int
-        Index of the input that will be used in this simulation.
+        Ignored, has no meaning in initial condition calculation. Parameter
+        ensures compatibility with step_response and impulse_response
 
     output: int
         Index of the output that will be used in this simulation. Set to None
@@ -531,9 +532,9 @@
     """
     sys = _convertToStateSpace(sys) 
     if output == None:
-        sys = _mimo2simo(sys, input, warn_conversion=False)
+        sys = _mimo2simo(sys, 0, warn_conversion=False)
     else:
-        sys = _mimo2siso(sys, input, output, warn_conversion=False)
+        sys = _mimo2siso(sys, 0, output, warn_conversion=False)
 
     # Create time and input vectors; checking is done in forced_response(...)
     # The initial vector X0 is created in forced_response(...) if necessary
@@ -549,12 +550,13 @@
 def impulse_response(sys, T=None, X0=0., input=0, output=None,
                     transpose=False, **keywords):
     #pylint: disable=W0622
-    """Impulse response of a linear system
+    """
+    Impulse response of a linear system
     
-    If the system has multiple inputs or outputs (MIMO), one input and one 
-    output have to be selected for the simulation. The parameters `input` 
-    and `output` do this. All other inputs are set to 0, all other outputs 
-    are ignored.
+    If the system has multiple inputs or outputs (MIMO), one input has
+    to be selected for the simulation. Optionally, one output may be
+    selected. The parameters `input` and `output` do this. All other
+    inputs are set to 0, all other outputs are ignored.
     
     For information on the **shape** of parameters `T`, `X0` and 
     return values `T`, `yout` see: :ref:`time-series-convention`

Modified: trunk/tests/matlab_test.py
===================================================================
--- trunk/tests/matlab_test.py	2014-07-08 10:57:18 UTC (rev 304)
+++ trunk/tests/matlab_test.py	2014-07-08 10:59:01 UTC (rev 305)
@@ -190,8 +190,8 @@
         #Test MIMO system, which contains ``siso_ss1`` twice
         sys = self.mimo_ss1
         x0 = np.matrix(".5; 1.; .5; 1.")
-        y_00, _t = initial(sys, T=t, X0=x0, input=0, output=0)
-        y_11, _t = initial(sys, T=t, X0=x0, input=1, output=1)
+        y_00, _t = initial(sys, T=t, X0=x0, output=0)
+        y_11, _t = initial(sys, T=t, X0=x0, output=1)
         np.testing.assert_array_almost_equal(y_00, youttrue, decimal=4)
         np.testing.assert_array_almost_equal(y_11, youttrue, decimal=4)
 

Modified: trunk/tests/timeresp_test.py
===================================================================
--- trunk/tests/timeresp_test.py	2014-07-08 10:57:18 UTC (rev 304)
+++ trunk/tests/timeresp_test.py	2014-07-08 10:59:01 UTC (rev 305)
@@ -109,8 +109,8 @@
         #Test MIMO system, which contains ``siso_ss1`` twice
         sys = self.mimo_ss1
         x0 = np.matrix(".5; 1.; .5; 1.")
-        _t, y_00 = initial_response(sys, T=t, X0=x0, input=0, output=0)
-        _t, y_11 = initial_response(sys, T=t, X0=x0, input=1, output=1)
+        _t, y_00 = initial_response(sys, T=t, X0=x0, output=0)
+        _t, y_11 = initial_response(sys, T=t, X0=x0, output=1)
         np.testing.assert_array_almost_equal(y_00, youttrue, decimal=4)
         np.testing.assert_array_almost_equal(y_11, youttrue, decimal=4)
         

[python-control-discuss] SF.net python-control commit:[304] trunk

[<re...@us...>]

Revision: 304
          http://sourceforge.net/p/python-control/code/304
Author:   repa
Date:     2014-07-08 10:57:18 +0000 (Tue, 08 Jul 2014)
Log Message:
-----------
Correction to the gain margin calculation. Old implementation also returned
gains where arg(H) == 0. 
Switched around the w_180 and wc return parameters, to match the order
of gain margin (matching w_180) and phase margin (matching wc) return. 

Modified Paths:
--------------
    trunk/src/margins.py
    trunk/tests/margin_test.py

Modified: trunk/src/margins.py
===================================================================
--- trunk/src/margins.py	2014-07-06 17:06:44 UTC (rev 303)
+++ trunk/src/margins.py	2014-07-08 10:57:18 UTC (rev 304)
@@ -80,6 +80,9 @@
 # idea for the frequency data solution copied/adapted from
 # https://github.com/alchemyst/Skogestad-Python/blob/master/BODE.py
 # Rene van Paassen <ren...@gm...>
+#
+# RvP, July 8, 2014, corrected to exclude phase=0 crossing for the gain
+#                    margin polynomial
 def stability_margins(sysdata, deg=True, returnall=False, epsw=1e-10):
     """Calculate gain, phase and stability margins and associated
     crossover frequencies.
@@ -147,7 +150,19 @@
         # test imaginary part of tf == 0, for phase crossover/gain margins
         test_w_180 = np.polyadd(np.polymul(inum, rden), np.polymul(rnum, -iden))
         w_180 = np.roots(test_w_180)
-        w_180 = np.real(w_180[(np.imag(w_180) == 0) * (w_180 > epsw)])
+
+        # first remove imaginary and negative frequencies, epsw removes the
+        # "0" frequency for type-2 systems
+        w_180 = np.real(w_180[(np.imag(w_180) == 0) * (w_180 >= epsw)])
+
+        # evaluate response at remaining frequencies, to test for phase 180 vs 0
+        resp_w_180 = np.real(np.polyval(sys.num[0][0], 1.j*w_180) /
+                             np.polyval(sys.den[0][0], 1.j*w_180))
+
+        # only keep frequencies where the negative real axis is crossed
+        w_180 = w_180[(resp_w_180 < 0.0)]
+
+        # and sort
         w_180.sort()
 
         # test magnitude is 1 for gain crossover/phase margins
@@ -203,14 +218,14 @@
     SM = np.abs(sys.evalfr(wstab)[0][0]+1)
 
     if returnall:
-        return GM, PM, SM, wc, w_180, wstab
+        return GM, PM, SM, w_180, wc, wstab
     else:
         return (
             (GM.shape[0] or None) and GM[0], 
             (PM.shape[0] or None) and PM[0], 
             (SM.shape[0] or None) and SM[0], 
+            (w_180.shape[0] or None) and w_180[0],
             (wc.shape[0] or None) and wc[0],
-            (w_180.shape[0] or None) and w_180[0],
             (wstab.shape[0] or None) and wstab[0])
 
 

Modified: trunk/tests/margin_test.py
===================================================================
--- trunk/tests/margin_test.py	2014-07-06 17:06:44 UTC (rev 303)
+++ trunk/tests/margin_test.py	2014-07-08 10:57:18 UTC (rev 304)
@@ -17,11 +17,18 @@
         self.sys2 = TransferFunction([1], [1, 2, 3, 4])
         self.sys3 = StateSpace([[1., 4.], [3., 2.]], [[1.], [-4.]],
             [[1., 0.]], [[0.]])
+        s = TransferFunction([1, 0], [1])
+        self.sys4 = (8.75*(4*s**2+0.4*s+1))/((100*s+1)*(s**2+0.22*s+1)) * \
+                                      1./(s**2/(10.**2)+2*0.04*s/10.+1)
 
     def test_stability_margins(self):
         gm, pm, sm, wg, wp, ws = stability_margins(self.sys1);
         gm, pm, sm, wg, wp, ws = stability_margins(self.sys2);
         gm, pm, sm, wg, wp, ws = stability_margins(self.sys3);
+        gm, pm, sm, wg, wp, ws = stability_margins(self.sys4);
+        np.testing.assert_array_almost_equal(
+            [gm, pm, sm, wg, wp, ws],
+            [2.2716, 97.5941, 1.0454, 10.0053, 0.0850, 0.4973], 3) 
 
     def test_phase_crossover_frequencies(self):
         omega, gain = phase_crossover_frequencies(self.sys2)

[python-control-discuss] SF.net python-control commit:[303] trunk/src/margins.py

[<re...@us...>]

Revision: 303
          http://sourceforge.net/p/python-control/code/303
Author:   repa
Date:     2014-07-06 17:06:44 +0000 (Sun, 06 Jul 2014)
Log Message:
-----------
Slightly increase the epsilon value for margin computation frequency, 
many type 2 systems (on Windows, 32 bit pythonxy, but not on 64 bit Linux
which I tested on) got cross over margins calculated at frequencies 
around 1e-11

Modified Paths:
--------------
    trunk/src/margins.py

Modified: trunk/src/margins.py
===================================================================
--- trunk/src/margins.py	2014-06-16 08:38:23 UTC (rev 302)
+++ trunk/src/margins.py	2014-07-06 17:06:44 UTC (rev 303)
@@ -80,13 +80,14 @@
 # idea for the frequency data solution copied/adapted from
 # https://github.com/alchemyst/Skogestad-Python/blob/master/BODE.py
 # Rene van Paassen <ren...@gm...>
-def stability_margins(sysdata, deg=True, returnall=False, epsw=1e-12):
+def stability_margins(sysdata, deg=True, returnall=False, epsw=1e-10):
     """Calculate gain, phase and stability margins and associated
     crossover frequencies.
     
     Usage
     -----
-    gm, pm, sm, wg, wp, ws = stability_margins(sysdata, deg=True)
+    gm, pm, sm, wg, wp, ws = stability_margins(sysdata, deg=True,
+                                               returnall=False, epsw=1e-10)
     
     Parameters
     ----------
@@ -101,7 +102,7 @@
     returnall=False: boolean
         If true, return all margins found. Note that for frequency data or
         FRD systems, only one margin is found and returned. 
-    epsw=1e-12: float
+    epsw=1e-10: float
         frequencies below this value are considered static gain, and not
         returned as margin.
        
@@ -114,7 +115,7 @@
         one crossover frequency is detected, returns the lowest corresponding
         margin. 
         When requesting all margins, the return values are array_like, 
-        and all margins are returns for linear systems not equal to FRD
+        and all margins are returned for linear systems not equal to FRD
         """
 
     try:

Re: [python-control-discuss] Any reason for the behavior of matlab.initial ?

[Richard M. <mu...@cd...>]

Agree that the current wording doesn't make sense; presumably just copied over from 'step' or 'impulse'.  It *might* be worth leaving the input parameter in place just so that you can change 'step' to 'initial' and not have to redo arguments.  But even then the documentation should reflect that fact that the input is ignored.

-richard

On 2 Jul 2014, at 0:27 , Rene van Paassen <ren...@gm...> wrote:

> Hi, 
> 
> Just had a student confused with the behavior of initial in the module control.matlab. Looking at the help:
> 
> initial(sys, T=None, X0=0.0, input=0, output=0, **keywords)
>     Initial condition response of a linear system
>     
>     If the system has multiple inputs or outputs (MIMO), one input and one 
>     output have to be selected for the simulation. The parameters `input` 
>     and `output` do this. All other inputs are set to 0, all other outputs 
>     are ignored.
> 
> I think the part about inputs is complete bull, since they don't play a role in initial condition response. Is there any reason to select only a single output? 
> 
> If there are no objections, I will update this one, and make it a bit more in line with the one in Matlab (R)
> 
> Greetings, 
> 
> René
> 
> -- 
> René van Paassen        | ______o____/_|     Ren...@gm...
>                        <[___\_\_-----<               t: +31 15 2628685
>                         |  o'                   mobile: +31 6 39846891
> 
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft_______________________________________________
> python-control-discuss mailing list
> pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-control-discuss

[python-control-discuss] Any reason for the behavior of matlab.initial ?

[Rene v. P. <ren...@gm...>]

Hi,

Just had a student confused with the behavior of initial in the module
control.matlab. Looking at the help:

initial(sys, T=None, X0=0.0, input=0, output=0, **keywords)
    Initial condition response of a linear system

    If the system has multiple inputs or outputs (MIMO), one input and one
    output have to be selected for the simulation. The parameters `input`
    and `output` do this. All other inputs are set to 0, all other outputs
    are ignored.

I think the part about inputs is complete bull, since they don't play a
role in initial condition response. Is there any reason to select only a
single output?

If there are no objections, I will update this one, and make it a bit more
in line with the one in Matlab (R)

Greetings,

René

-- 
René van Paassen        | ______o____/_|     Ren...@gm...
                       <[___\_\_-----<               t: +31 15 2628685
                        |  o'                   mobile: +31 6 39846891

[python-control-discuss] SF.net python-control commit:[302] trunk/src

[<re...@us...>]

Revision: 302
          http://sourceforge.net/p/python-control/code/302
Author:   repa
Date:     2014-06-16 08:38:23 +0000 (Mon, 16 Jun 2014)
Log Message:
-----------
extend comments for root-locus procedure

Modified Paths:
--------------
    trunk/src/matlab.py
    trunk/src/rlocus.py

Modified: trunk/src/matlab.py
===================================================================
--- trunk/src/matlab.py	2014-06-13 04:26:38 UTC (rev 301)
+++ trunk/src/matlab.py	2014-06-16 08:38:23 UTC (rev 302)
@@ -1112,6 +1112,14 @@
         Linear system
     klist: 
         optional list of gains
+    xlim : control of x-axis range, normally with tuple, for
+        other options, see matplotlib.axes
+    ylim : control of y-axis range
+    Plot : boolean (default = True)
+        If True, plot magnitude and phase
+    PrintGain: boolean (default = True)
+        If True, report mouse clicks when close to the root-locus branches,
+        calculate gain, damping and print
 
     Returns
     -------

Modified: trunk/src/rlocus.py
===================================================================
--- trunk/src/rlocus.py	2014-06-13 04:26:38 UTC (rev 301)
+++ trunk/src/rlocus.py	2014-06-16 08:38:23 UTC (rev 302)
@@ -65,6 +65,9 @@
         Linear input/output systems (SISO only, for now)
     kvect : gain_range (default = None)
         List of gains to use in computing diagram
+    xlim : control of x-axis range, normally with tuple, for
+        other options, see matplotlib.axes
+    ylim : control of y-axis range
     Plot : boolean (default = True)
         If True, plot magnitude and phase
     PrintGain: boolean (default = True)

[python-control-discuss] SF.net python-control commit:[301] trunk/src/matlab.py

[<re...@us...>]

Revision: 301
          http://sourceforge.net/p/python-control/code/301
Author:   repa
Date:     2014-06-13 04:26:38 +0000 (Fri, 13 Jun 2014)
Log Message:
-----------
Updated the function overview in Matlab, to match some added functions

Modified Paths:
--------------
    trunk/src/matlab.py

Modified: trunk/src/matlab.py
===================================================================
--- trunk/src/matlab.py	2014-06-11 05:00:09 UTC (rev 300)
+++ trunk/src/matlab.py	2014-06-13 04:26:38 UTC (rev 301)
@@ -134,6 +134,8 @@
 \-  lti/set                     set/modify properties of LTI models
 \-  setdelaymodel               specify internal delay model (state space
                                 only)
+\*  :func:`rss`                 create a random continuous state space model
+\*  :func:`drss`                create a random discrete state space model
 ==  ==========================  ============================================
 
 
@@ -141,7 +143,7 @@
 ----------------------------------------------------------------------------
 
 ==  ==========================  ============================================
-\   lti/tfdata                  extract numerators and denominators
+\*  :func:`tfdata`              extract numerators and denominators
 \   lti/zpkdata                 extract zero/pole/gain data
 \   lti/ssdata                  extract state-space matrices
 \   lti/dssdata                 descriptor version of SSDATA
@@ -159,7 +161,7 @@
 \   zpk                         conversion to zero/pole/gain
 \*  :func:`ss`                  conversion to state space
 \*  :func:`frd`                 conversion to frequency data
-\   c2d                         continuous to discrete conversion
+\*  :func:`c2d`                 continuous to discrete conversion
 \   d2c                         discrete to continuous conversion
 \   d2d                         resample discrete-time model
 \   upsample                    upsample discrete-time LTI systems
@@ -183,7 +185,7 @@
                                 (see also overloaded ``*``)
 \*  :func:`~bdalg.feedback`     connect lti models with a feedback loop
 \   lti/lft                     generalized feedback interconnection
-\   lti/connect                 arbitrary interconnection of lti models
+\*  :func:'~bdalg.connect'      arbitrary interconnection of lti models
 \   sumblk                      summing junction (for use with connect)
 \   strseq                      builds sequence of indexed strings 
                                 (for I/O naming)

[python-control-discuss] SF.net python-control commit:[300] trunk/tests/matlab_test.py

[<re...@us...>]

Revision: 300
          http://sourceforge.net/p/python-control/code/300
Author:   repa
Date:     2014-06-11 05:00:09 +0000 (Wed, 11 Jun 2014)
Log Message:
-----------
added a more complex test case to the matlab code. This test case was
actually hit upon by one of my students, the control/numpy combination
resulted in phase margin detected near omega=0

Modified Paths:
--------------
    trunk/tests/matlab_test.py

Modified: trunk/tests/matlab_test.py
===================================================================
--- trunk/tests/matlab_test.py	2014-05-23 12:41:47 UTC (rev 299)
+++ trunk/tests/matlab_test.py	2014-06-11 05:00:09 UTC (rev 300)
@@ -534,7 +534,62 @@
                       -0.304617775734327   0.075182622718853"""), sysd.B)
         
 
+    def testCombi01(self):
+        # test from a "real" case, combines tf, ss, connect and margin
+        # this is a type 2 system, with phase starting at -180. The
+        # margin command should remove the solution for w = nearly zero
 
+        # Example is a concocted two-body satellite with flexible link
+        Jb = 400;
+        Jp = 1000;
+        k = 10;
+        b = 5;
+
+        # can now define an "s" variable, to make TF's 
+        s = tf([1, 0], [1]);
+        hb1 = 1/(Jb*s);
+        hb2 = 1/s;
+        hp1 = 1/(Jp*s);
+        hp2 = 1/s;
+
+        # convert to ss and append
+        sat0 = append(ss(hb1), ss(hb2), k, b, ss(hp1), ss(hp2));
+
+        # connection of the elements with connect call
+        Q = [[1, -3, -4],  # link moment (spring, damper), feedback to body
+             [2,  1,  0],  # link integrator to body velocity
+             [3,  2, -6],  # spring input, th_b - th_p
+             [4,  1, -5],  # damper input
+             [5,  3,  4],  # link moment, acting on payload
+             [6,  5,  0]]
+        inputs = [1];
+        outputs = [1, 2, 5, 6];
+        sat1 = connect(sat0, Q, inputs, outputs);
+        
+        # matched notch filter
+        wno = 0.19
+        z1 = 0.05
+        z2 = 0.7
+        Hno = (1+2*z1/wno*s+s**2/wno**2)/(1+2*z2/wno*s+s**2/wno**2)
+        
+        # the controller, Kp = 1 for now
+        Kp = 1.64
+        tau_PD = 50.
+        Hc = (1 + tau_PD*s)*Kp
+
+        # start with the basic satellite model sat1, and get the 
+        # payload attitude response
+        Hp = tf(sp.matrix([0, 0, 0, 1])*sat1)
+        
+        # total open loop
+        Hol = Hc*Hno*Hp
+        
+        gm, pm, wg, wp = margin(Hol)
+        self.assertAlmostEqual(gm, 3.32065569155)
+        self.assertAlmostEqual(pm, 46.9740430224)
+        self.assertAlmostEqual(wp, 0.0616288455466)
+        self.assertAlmostEqual(wg, 0.176469728448)
+
 #! TODO: not yet implemented
 #    def testMIMOtfdata(self):
 #        sisotf = ss2tf(self.siso_ss1)

Re: [python-control-discuss] some problems with control-0.6c

[Roberto B. <rob...@su...>]

After the first tests it seems to be ok.

On next Monday I'll try to regenerate RT code using the modified control 
scripts and I'll test the results in my laboratory.

Thanks

Roberto

On 05/23/2014 02:47 PM, Rene van Paassen wrote:
> I added capability for c2d to convert MIMO state-space systems, based 
> on a slycot function added to the repagh/slycot on github, so you need 
> a new slycot for that.
>
> Thanks for the testing, by the way!
>
> René
>
>
> On 17 December 2013 11:25, Roberto Bucher <rob...@su... 
> <mailto:rob...@su...>> wrote:
>
>     Hi all
>
>     I'm testing the last control-0.6c toolbox in order to actualize my
>     yottalab package and I found some differences between the results of a
>     couple of functions:
>
>     1) the c2d function should maintain the form of the state-space
>     function. It seems that the system is first transformed into a
>     transfer
>     function and then discretized. In my opinion it is important that the
>     state-space form of the discrete system is exactly the same (same
>     states) that I have in the continuous representation.
>
>     2) The dare functions gives some wrong results, and I'll check the lqr
>     function asap. Using the delivered "dare" function (mateqn.py) I have
>     wrong values of the feedback gains (compared with the values given by
>     matlab dlqr and scilab)
>
>     3) the lqr function doesn't accept a call like
>
>     lqr(sys,Q,R) -> only 3 parameters!
>
>
>     In the next time I'll check the gains returned by the lqr function,
>     compared with matlab and scilab.
>
>     Best regards
>
>     Roberto
>
>
>
>     ------------------------------------------------------------------------------
>     Rapidly troubleshoot problems before they affect your business.
>     Most IT
>     organizations don't have a clear picture of how application
>     performance
>     affects their revenue. With AppDynamics, you get 100% visibility
>     into your
>     Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>     AppDynamics Pro!
>     http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>     _______________________________________________
>     python-control-discuss mailing list
>     pyt...@li...
>     <mailto:pyt...@li...>
>     https://lists.sourceforge.net/lists/listinfo/python-control-discuss
>
>
>
>
> -- 
> René van Paassen        | ______o____/_| Ren...@gm... 
> <mailto:Ren...@gm...>
> <[___\_\_-----<               t: +31 15 2628685
> |  o'                   mobile: +31 6 39846891
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
>
>
> _______________________________________________
> python-control-discuss mailing list
> pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-control-discuss

Re: [python-control-discuss] some problems with control-0.6c

[Rene v. P. <ren...@gm...>]

I added capability for c2d to convert MIMO state-space systems, based on a
slycot function added to the repagh/slycot on github, so you need a new
slycot for that.

Thanks for the testing, by the way!

René


On 17 December 2013 11:25, Roberto Bucher <rob...@su...> wrote:

> Hi all
>
> I'm testing the last control-0.6c toolbox in order to actualize my
> yottalab package and I found some differences between the results of a
> couple of functions:
>
> 1) the c2d function should maintain the form of the state-space
> function. It seems that the system is first transformed into a transfer
> function and then discretized. In my opinion it is important that the
> state-space form of the discrete system is exactly the same (same
> states) that I have in the continuous representation.
>
> 2) The dare functions gives some wrong results, and I'll check the lqr
> function asap. Using the delivered "dare" function (mateqn.py) I have
> wrong values of the feedback gains (compared with the values given by
> matlab dlqr and scilab)
>
> 3) the lqr function doesn't accept a call like
>
> lqr(sys,Q,R) -> only 3 parameters!
>
>
> In the next time I'll check the gains returned by the lqr function,
> compared with matlab and scilab.
>
> Best regards
>
> Roberto
>
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> python-control-discuss mailing list
> pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-control-discuss
>



-- 
René van Paassen        | ______o____/_|     Ren...@gm...
                       <[___\_\_-----<               t: +31 15 2628685
                        |  o'                   mobile: +31 6 39846891

[python-control-discuss] SF.net python-control commit:[299] trunk

[<re...@us...>]

Revision: 299
          http://sourceforge.net/p/python-control/code/299
Author:   repa
Date:     2014-05-23 12:41:47 +0000 (Fri, 23 May 2014)
Log Message:
-----------
Added c2d functionality for MIMO state-space systems; both in matlab mode
and for python mode; added tests for same

Modified Paths:
--------------
    trunk/src/dtime.py
    trunk/src/matlab.py
    trunk/src/statesp.py
    trunk/tests/discrete_test.py
    trunk/tests/matlab_test.py

Modified: trunk/src/dtime.py
===================================================================
--- trunk/src/dtime.py	2014-03-23 20:39:48 UTC (rev 298)
+++ trunk/src/dtime.py	2014-05-23 12:41:47 UTC (rev 299)
@@ -94,11 +94,25 @@
     if not isctime(sysc):
         raise ValueError("First argument must be continuous time system")
 
-    # TODO: impelement MIMO version
+    # If we are passed a state space system, convert to transfer function first
+    if isinstance(sysc, StateSpace) and method == 'zoh':
+        
+        try:
+            # try with slycot routine
+            from slycot import mb05nd
+            F, H = mb05nd(sysc.A, Ts)
+            return StateSpace(F, H*sysc.B, sysc.C, sysc.D, Ts)
+        except ImportError: 
+            if sysc.inputs != 1 or sysc.outputs != 1:
+                raise TypeError(
+                    "mb05nd not found in slycot, or slycot not installed")
+            
+    # TODO: implement MIMO version for other than ZOH state-space
     if (sysc.inputs != 1 or sysc.outputs != 1):
         raise NotImplementedError("MIMO implementation not available")
 
-    # If we are passed a state space system, convert to transfer function first
+    # SISO state-space, with other than ZOH, or failing slycot import, 
+    # is handled by conversion to TF
     if isinstance(sysc, StateSpace):
         warn("sample_system: converting to transfer function")
         sysc = _convertToTransferFunction(sysc)

Modified: trunk/src/matlab.py
===================================================================
--- trunk/src/matlab.py	2014-03-23 20:39:48 UTC (rev 298)
+++ trunk/src/matlab.py	2014-05-23 12:41:47 UTC (rev 299)
@@ -1524,8 +1524,29 @@
     return (tf.num, tf.den)
 
 # Convert a continuous time system to a discrete time system
-def c2d(sysc, Ts, method):
-    # TODO: add docstring
+def c2d(sysc, Ts, method='zoh'):
+    '''
+    Return a discrete-time system
+
+    Parameters
+    ----------
+    sysc: Lti (StateSpace or TransferFunction), continuous
+        System to be converted
+
+    Ts: number
+        Sample time for the conversion
+
+    method: string, optional
+        Method to be applied, 
+        'zoh'        Zero-order hold on the inputs (default)
+        'foh'        First-order hold, currently not implemented
+        'impulse'    Impulse-invariant discretization, currently not implemented
+        'tustin'     Bilinear (Tustin) approximation, only SISO
+        'matched'    Matched pole-zero method, only SISO
+    '''
     #  Call the sample_system() function to do the work
-    return sample_system(sysc, Ts, method)
+    sysd = sample_system(sysc, Ts, method)
+    if isinstance(sysc, StateSpace) and not isinstance(sysd, StateSpace):
+        return _convertToStateSpace(sysd)
+    return sysd
 

Modified: trunk/src/statesp.py
===================================================================
--- trunk/src/statesp.py	2014-03-23 20:39:48 UTC (rev 298)
+++ trunk/src/statesp.py	2014-05-23 12:41:47 UTC (rev 299)
@@ -610,7 +610,7 @@
                 ssout[3][:sys.outputs, :states], 
                 ssout[4], sys.dt)
         except ImportError:
-            # TODO: do we want to squeeze first and check dimenations?
+            # TODO: do we want to squeeze first and check dimensions?
             # I think this will fail if num and den aren't 1-D after
             # the squeeze
             lti_sys = lti(squeeze(sys.num), squeeze(sys.den))

Modified: trunk/tests/discrete_test.py
===================================================================
--- trunk/tests/discrete_test.py	2014-03-23 20:39:48 UTC (rev 298)
+++ trunk/tests/discrete_test.py	2014-05-23 12:41:47 UTC (rev 299)
@@ -272,6 +272,10 @@
             self.assertEqual(sysd.dt, 1)
             # TODO: put in other generic checks
 
+        for sysc in (self.mimo_ss1, self.mimo_ss1c):
+            sysd = sample_system(sysc, 1, method='zoh')
+            self.assertEqual(sysd.dt, 1)
+
         # TODO: check results of converstion
 
         # Check errors

Modified: trunk/tests/matlab_test.py
===================================================================
--- trunk/tests/matlab_test.py	2014-03-23 20:39:48 UTC (rev 298)
+++ trunk/tests/matlab_test.py	2014-05-23 12:41:47 UTC (rev 299)
@@ -515,7 +515,26 @@
         np.testing.assert_array_almost_equal(hm.num[0][0], hr.num[0][0])
         np.testing.assert_array_almost_equal(hm.den[0][0], hr.den[0][0])
 
+    def testSS2cont(self):
+        sys = ss(
+            np.mat("-3 4 2; -1 -3 0; 2 5 3"),
+            np.mat("1 4 ; -3 -3; -2 1"),
+            np.mat("4 2 -3; 1 4 3"),
+            np.mat("-2 4; 0 1"))
+        sysd = c2d(sys, 0.1)
+        np.testing.assert_array_almost_equal(
+            np.mat(
+                """0.742840837331905  0.342242024293711  0.203124211149560;
+                  -0.074130792143890  0.724553295044645 -0.009143771143630;
+                   0.180264783290485  0.544385612448419  1.370501013067845"""),
+            sysd.A)
+        np.testing.assert_array_almost_equal(
+            np.mat(""" 0.012362066084719   0.301932197918268;
+                      -0.260952977031384  -0.274201791021713;
+                      -0.304617775734327   0.075182622718853"""), sysd.B)
+        
 
+
 #! TODO: not yet implemented
 #    def testMIMOtfdata(self):
 #        sisotf = ss2tf(self.siso_ss1)