Angadh was one of the students who had to learn how to use physics.mechanics for class this past quarter. I think he would be in a good position to improve the documentation for this submodule, considering he just had to learn it on his own. I think I did a good job on the documentation, but just didn't have that perspective. Someone like Angadh could probably work on making the documentation more accessible.
Regarding Sage - what prevents Sage from including the version of SymPy on Github, other than SymPy not submitting a spkg to them more frequently? Is there any work that could be done to make Sage/SymPy integration easier? Or perhaps this isn't really that large of an issue? The ODE's generated by physics.mechanics typically can only be solved numerically. Luke, Jason, and I have been discussing the best way to deal with this, admittedly with no clear consensus. I think the two competing issues are speed/performance vs. convenience; dealing with specified input quantities is also a challenge (forces, control inputs, etc.). If you could imagine 2 use cases (where most of the other cases would fall somewhere between the two in terms of complexity): 1. A user who wants to create equations of motion for a simple system (like a double pendulum), supply some parameters, and get some plots. 2. A user who wants to create equations of motion for a flexible arm on a spacecraft, needs to have feedback control of the system inputs, and needs to know output quantities which are functions of the states of the system; this user then wants to integrate their equations of motion and generate some plots. The first user could benefit from being able to integrate their ODE's in SymPy and get a plot right away (at least I think they could benefit from that). With the second user, it's not so clear what the best solution is; performance and the ability to modify the code are important, but not having to type the equations into a file is also important. For this user, some sort of bare-bones C file (or a python file using inline C code) might be best. Allowing this user's code to be integrated in an environment like Sage would be even better. In summary, I think we don't know what the right way to implement integration of the equations of motion is; input would be welcome though. -Gilbert On Mar 25, 3:49 pm, Matthew Rocklin <[email protected]> wrote: > I quite like the idea of writing an ODE in SymPy and numerically computing > it elsewhere. I could see this going in two ways: > > 1) Sending simple systems to scipy's odeint - it seems ideal not to > reinvent odeint if possible > 2) Hook into the code generation module. It would be very cool to generate > C/Fortran code for this. > > On Sun, Mar 25, 2012 at 3:43 PM, Angadh Nanjangud <[email protected]>wrote: > > > > > > > > > Also, another idea is to write ode solvers in sympy so that we can > > numerically simulate our systems within sympy without dependencies; > > currently we use SciPy to d our numerical stuff and plotting. > > > Angadh > > > On Mar 25, 3:25 pm, Angadh Nanjangud <[email protected]> wrote: > > > Hi Everyone > > > > I'm Angadh, a third year Ph.D. student in mechanical and aerospace > > > engineering at UC-Davis and a prospective applicant for the GSoC 2012. > > > and the following are some of the ideas/things that I would like to > > > work on over the course of the summer if given the opportunity. > > > Over the winter quarter, I took a mechanics class and one of it's foci > > > was the usage of the sympy.physics.mechanics module to derive > > > equations of motion for mechanical systems. Over the course of my > > > experience with it, I felt that there were several things that could > > > be worked on to make the dynamics package more robust- > > > > 1. One of the things that students encountered in the class was that > > > as our systems got more complex i.e. the number of bodies or degrees > > > of freedom increased, the longer it took to generate the equations. So > > > one of the things I would like to look at would be to optimize the > > > code; to enable it to handle larger expressions. This would involve > > > looking into the .subs() and .diff() to see how they could be improved > > > upon. > > > > 2. Currently equations are generated using just one of several methods > > > in mechanics, Kane's formalism. I would like to look into adding > > > atleast another technique- either the Newton-Euler approach or > > > Lagrange's equations. > > > > 3. Another thing that I would like to do would be to improve the cross- > > > platform ability of the software i.e. to get the equations of motion > > > generated to be analyzed across various (open source) platforms such > > > as Sage. This may involve automatically updating Sage's version of > > > sympy or even writing a whole new interface for it. > > > > 4. A comprehensive documentation effort to make this module more > > > accessible for anyone who intends to use it. > > > > I would be extremely grateful if you could let me know your thoughts > > > on these ideas. > > > > Thanks > > > Angadh > > > -- > > You received this message because you are subscribed to the Google Groups > > "sympy" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > >http://groups.google.com/group/sympy?hl=en. -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
