GSoC Idea
Angadh Nanjangud
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
Angadh Nanjangud
numerically simulate our systems within sympy without dependencies;
currently we use SciPy to d our numerical stuff and plotting.
Angadh
Aaron Meurer
On Sun, Mar 25, 2012 at 4:25 PM, Angadh Nanjangud <anga...@gmail.com> 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.
Cool. You could use a profiling tool like kernprof or the built-in
CProfile to do this. Also check if the printing is the bottleneck
(generate an equation of motion, but don't print it, and see if that
makes things faster).
>
> 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.
I'm not sure I understand what you are suggesting here. Sage will
generally include the latest version of SymPy. And anything that can
run Python can run SymPy.
>
> 4. A comprehensive documentation effort to make this module more
> accessible for anyone who intends to use it.
I noticed that Gilbert already has some pretty nice documentation for
the existing module. Are there deficiencies in it? Or are you
referring to the documentation for the new code that you plan to
write?
>
> I would be extremely grateful if you could let me know your thoughts
> on these ideas.
>
> Thanks
> Angadh
Sounds good so far. You should start writing up a proposal (see
https://github.com/sympy/sympy/wiki/gsoc-2012-application-template),
and also start looking into writing a patch for the patch requirement
(look through the code and issues list for something to fix, and
submit a pull request).
Let us know if you need any help.
Aaron Meurer
Matthew Rocklin
--
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Jason Moore
What is the general rule of thumb about how much numerical type of code can be included with SymPy? The ode solvers are almost strictly numerical except for some particular nice problems.
Jason
To unsubscribe from this group, send email to sympy+unsubscribe@googlegroups.com.
Gilbert gede
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 <mrock...@gmail.com> 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.
>
Tim Lahey
I've put together some thoughts on the ODEs, which I've outlined below.
On Mon, Mar 26, 2012 at 12:48 AM, Gilbert gede <gilbe...@gmail.com> wrote:
>
> 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.
True and useful mainly for teaching purposes, but definitely useful.
> 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.
In this case, there's a few ways about getting the numerical
equations. The first would be to use Raleigh-Ritz and assume forms for
each of the spatial variables which would then lead to the finite
element equations. The second would be to derive them normally and use
Galerkin to get the finite element equations. It's also possible that
one could do a modal analysis approach. While my standard approach is
Raleigh-Ritz, I'd recommend Galerkin since it's the most general.
Plus, it would work well with the existing framework since you can
apply it directly to the resulting PDEs.
After getting the new equations, I would think that a code generation
approach would be best. That way one could hook it into any solver of
choice. To give an example of how something like this might be used,
I'll describe how I do a similar problem.
For my finite element code (written in a mix of Maple and Matlab), I
use Maple's code generation to output element mass and stiffness
matrices as Matlab functions. That way, the parameters can be passed
at runtime during assembly. I then use a Newmark-Beta solver to
directly solve the 2nd order system of ODEs, rather than convert to a
1st order system.
If someone is going to do FE numerical equations, I highly recommend
Bathe and Wilson's book. Also, there's an excellent paper by Vermeulen
and Heppler that has a section on a test to see if a particular
discretisation will suffer from locking.
I'd really like to see a GSoC project on the mechanics module. If it
doesn't happen, I may try and find the time to do some work on it.
Oh, while I probably can't be an official mentor (I'm trying to finish
my thesis this summer), I probably can take some questions.
Cheers,
Tim.
--
Tim Lahey
PhD Candidate, Systems Design Engineering
University of Waterloo
http://about.me/tjlahey
Aaron Meurer
You could also help us review applications, if you have time. If so,
just sign up on the google-melange.com site.
Aaron Meurer
>
> Cheers,
>
> Tim.
>
> --
> Tim Lahey
> PhD Candidate, Systems Design Engineering
> University of Waterloo
> http://about.me/tjlahey
>
Tim Lahey
I've registered with google-melange.com. I'd be happy to help with
reviewing applications. Just let me know when, where, and how to help.
Cheers,
Tim.
On Mon, Mar 26, 2012 at 2:49 PM, Aaron Meurer <asme...@gmail.com> wrote:
>
> You could also help us review applications, if you have time. If so,
> just sign up on the google-melange.com site.
>
Aaron Meurer
Aaron Meurer
Tim Lahey
Tim Lahey
On Mon, Mar 26, 2012 at 6:12 PM, Aaron Meurer <asme...@gmail.com> wrote:
> You need to submit a request to be a mentor for the SymPy organization.
>
> Aaron Meurer
--
Tim Lahey
tjl...@cgl.uwaterloo.ca
Angadh Nanjangud
> 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.
external dependencies like that and just have the solver in sympy.
I do intend to look into getting code output for different platforms.
But I was also thinking about maybe writing a Runge-Kutta (or other
commonly used numerical method) solver in SymPy. Any thoughts on that?
Tim Lahey
On Sun, Apr 1, 2012 at 3:53 AM, Angadh Nanjangud <anga...@gmail.com> wrote:
>
> Gilbert's latest code does use scipy but our thoughts are to eliminate
> external dependencies like that and just have the solver in sympy.
> I do intend to look into getting code output for different platforms.
> But I was also thinking about maybe writing a Runge-Kutta (or other
> commonly used numerical method) solver in SymPy. Any thoughts on that?
The problem I see is that any numerical method written in SymPy for
solving ODEs will be much slower than using SciPy. I don't see the
point in duplicating functionality that's readily available (and is
better) elsewhere. The advantages I see in a SymPy numerical ODE
method are a) that it can use arbitrary precision and could support
more precise tolerances and b) that it could be used in a pure Python
environment. I don't see that these are particularly important for
numerical ODE solving, but others may differ. I'd rather see effort
put into improving the interaction with external ODE solvers (however
that may be done).
Part of the problem is that writing numerical ODE solvers can be
tricky to do well (but it's not hard to do poorly). There's a reason
people are still using old Fortran solvers rather than rewriting them.
Cheers,
Tim.
--
Tim Lahey
PhD Candidate, Systems Design Engineering
University of Waterloo
Angadh Nanjangud
Thanks!
Angadh
Luke
> Thanks!
>
> Angadh
I agree with Tim; I think the effort would be better spent making the
existing functionality interact with well tested and reliable
solvers,. To address the scipy/numpy dependency issue, I think
getting sympy.physics.mechanics into sage would solve this problem
very well.
Luke
Aaron Meurer
in. If anyone wants to expedite the process, you could help with
blocking issues
(http://code.google.com/p/sympy/issues/list?can=2&q=Milestone%3DRelease0.7.2+&colspec=ID+Type+Status+Priority+Milestone+Reporter+Summary+Stars&cells=tiles),
especially the ones with Priority-Critical.
Aaron Meurer