Hi Luke, On Tue, Apr 5, 2011 at 1:08 PM, Luke <hazelnu...@gmail.com> wrote: > Hello, > I did a Sympy GSoC project in 2009 on a package called PyDy [0]. > PyDy depends intimately on SymPy, but currently the two projects are > maintained separately. The basic functionality of PyDy is to provide > a set of classes which ease kinematic and dynamic analysis of > mechanical systems that obey the laws of Newtonian Mechanics. PyDy > relies on the core symbolic functionality of SymPy in a way similar to > the Geometric Algebra module (sympy/GA.py). By the end of my GSoC > summer, PyDy was very functional and I had created 12 examples of use > for deriving equations of motion for both trivial (pendulum) and non- > trivial (rolling coin, rolling torus, bicycle--almost) mechanical > systems. Sadly, the project has seen very little activity since my > GSoC project. > > There are two students in my lab who are interested in helping develop > and improve PyDy. One of the ideas we have been discussing is how the > core functionality of PyDy really depends on Sympy and we think it > would make more sense to have PyDy as a module of Sympy, probably in > sympy/physics or maybe in sympy/pydy (or some other place?). This > way, it would be more like a library that can be imported along with > Sympy if you want to formulate study symbolic equations of motion. A > few advantages of this approach are: > -- Code updates to sympy wouldn't break pydy functionality since the > core testing would be done together > -- PyDy would be available to anybody who installs sympy. This could > be really helpful for both projects because there are many physics, > math, and engineering students (both grad and undergrad) who need to > do some basic 3D vector symbolic vector analysis, and keeping pydy > within sympy would make this much easier than it currently is. > -- We could maintain a separate source tree for detailed examples of > use, which depend on many other tools besides Sympy, and don't make > sense to have distributed with sympy. > -- Developers of PyDy would be more connected to Sympy and vice-versa, > which would be a win for both groups. > > What do people think of this idea? A fair bit of work needs to be > done to make the pydy code compliant with they sympy project -- > doctests and docstrings need to be improved, but most of the testing > of PyDy's functionality is already implemented.
I definitely like this. Given the size of pydy, it's just a couple (not very large) files, so it is of the size of sympy.physics.quantum, or sympy.galgebra. And as long as there modules are of moderate size, that we can manage, and currently that is 100% the case, I would love to have them in sympy itself. The reason for that being that it will force sympy to become more polished as a library, in particular things like customized printing, that every single module is tackling with (quantum, galgebra and pydy). And having them nicely polished in sympy, it shows how to use sympy to actually do something nontrivial, in real world, that people want to use. Plus it will inspire more people to contribute useful modules in various fields. This adds real value to sympy. > > Back to the topic of GSoC, there are many other aspects of PyDy that > need work besides the possibility of integrating it into sympy. Here > are a few items: > -- Class hierarchy needs to be re-evaluated/re-designed to include > some notion of the "system" (all bodies, particles, applied forces/ > torques, generalized coordinates, degrees of freedom, etc.). > Currently all of this is embedded in the Point and ReferenceFrame > classes and is a bit hackish. > -- Handling of closed kinematic loops (four-bar linkage) needs to be > improved > -- Templates for outputting boilerplate animation code to enable > immediate visualization after symbolic derivation. > -- Improvement of LaTeX printing for vector expressions. > > We are working on a document outlining these things in more detail, we > have made it public here: > https://docs.google.com/document/d/1Egkw9VkXcIYOiXonKFGRU00gycoA7w4Oq4M085d0fAg/edit?hl=en > > I would like to ensure that work on Pydy is beneficial for the Sympy > project. Pydy is fairly heavy on the trigonometry and in the past I > ran into snags in various aspects of trigsimp. Part of this was > probably avoidable for reasons I won't go into here, but part of it > was due to aspects of sympy that needed improvement. I see this as > place of technical overlap where work on PyDy will help improve > Sympy. Another place where PyDy can help SymPy is by bringing more > uses to Sympy -- every physics and engineering student has to take a > dynamics class in which aspects of PyDy could be very beneficial to > their studies and this in turn would expose more people to Sympy. By > tying something this ubiquitous to Sympy, I think the user base would > both grow and be diversified. > > The two students in my lab that are interested should be posting > introduction emails shortly, and they are working on familiarizing > themselves with the Sympy source tree and identifying an issue that > they can fix and submit a patch for. They will be adding their > proposals to the wiki and notifying the mailing list as well. > > Seeing as both of these students are in my lab, I would be willing to > mentor them for the GSoC projects, should they be accepted. We use > git and python extensively in our lab so some of the hurdles in the > development process should be lowered by the resources and experience > of the people in my lab. This will help both students to hit the > ground running a lot more quickly. I agree with what you wrote. I would only stress one thing --- with GSoC, we really want all students to become part of the sympy community. We understand that we can't force anyone to stay around once the summer is over, but we do want to encourage that as much as we can, so that the whole sympy community can grow with GSoC. By becoming part of the sympy community, we mean occasionally helping with reviews, or on the mailinglist, reporting bugs, helping other people. The best way is of course to use sympy in your daily research. So I can see lots of potential here, because pydy depends on lots of things in sympy, trigonometry being one thing, and there is tons of room for improvement. And pulling this off, so that more people start using pydy (and contribute back), would be really great. Ondrej P.S. that reminds me, that we still have that unfinished "trig" branch. :) -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
