I am interested in applying to Google Summer of Code to work on a SymPy project
Elliot Marshall
Elliot Marshall
Aaron Meurer
application process, you should clone the git version of SymPy (you
likely already have, though, if you've been using the mechanics
module). Then, you should look through our issue tracker, or just
through the code itself to find something to fix. We require that all
applicants submit at least one patch that is accepted and merged.
You should also start thinking about the application itself. See
https://github.com/sympy/sympy/wiki/gsoc-2012-application-template.
Aaron Meurer
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/sympy/-/50UcUmCEgGYJ.
>
> 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.
Tim Lahey
> For example, I would like to write the functions necessary so that, using
> sympy.physics.mechanics, one could use Euler, Lagrange, and possibly other
> methods to find the dynamical equations of motion for a system.
I assume you mean Euler-Lagrange? I'd like to see it progress to
handling variables that vary spatially and not just in time. That
said, I'd like Euler-Lagrange support as well. Supporting vector
variables (in a linear algebra sense) would be nice as well. I believe
there's been work on symbolic matrix expressions in Sympy. This would
allow for the derivation of finite element equations.
Implementing just Euler-Lagrange shouldn't take too long if one is
familiar with the programming of the module. I expect probably a few
weeks to a month at most. My implementation of E-L in Maple is less
than a page of code, most of that is converting from a function to a
variable that can be differentiated and back. There will be a bit
setting things up for the E-L equation, but some can probably be
reused from the current module.
Cheers,
Tim.
--
Tim Lahey
PhD Candidate, Systems Design Engineering
University of Waterloo
http://about.me/tjlahey
Aaron Meurer
respect to functions and derivatives:
In [153]: diff(x*f(x)**2 + f(x)*diff(f(x), x), f(x))
Out[153]:
d
2⋅x⋅f(x) + ──(f(x))
dx
In [154]: diff(x*f(x)**2 + f(x)*diff(f(x), x), diff(f(x), x))
Out[154]: f(x)
So your boilerplate code would be unnecessary in SymPy.
From what I remember, Gilbert used this to implement some degree of
Euler-Lagrange in the mechanics module. You'll have to ask him or
look at the code for the specifics, though.
Aaron Meurer
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
Tim Lahey
On Sun, Mar 25, 2012 at 5:27 PM, Aaron Meurer <asme...@gmail.com> wrote:
> There is already support in the git master for taking derivatives with
> respect to functions and derivatives:
>
> In [153]: diff(x*f(x)**2 + f(x)*diff(f(x), x), f(x))
> Out[153]:
> d
> 2⋅x⋅f(x) + ──(f(x))
> dx
>
> In [154]: diff(x*f(x)**2 + f(x)*diff(f(x), x), diff(f(x), x))
> Out[154]: f(x)
>
> So your boilerplate code would be unnecessary in SymPy.
What about if f(x) isn't just f(x) but g(x,y,z,t)? And taking
derivatives with respect to that (and its derivatives). That's the
situation I'm in. I knew the f(x) case was implemented, but I didn't
think that the g(x,y,z,t) case was. For straightforward dynamics
problems, the f(x) case is enough, but once you add in flexible
bodies, you need the g(x,y,z,t) case as well along with all possible
derivatives.
I'd love to see a full Euler-Lagrange equation implementation. Most
(including mine), only do the standard Euler-Lagrange equation, but
for different functionals, you can can get much more complicated
Euler-Lagrange equations than just the standard one. But, to get the
full one, you'd need to implement Calculus of Variations and support
taking a variation with respect to a functional. I have a basic
implementation in Maple, but it's not particularly robust.
Aaron Meurer
> Aaron,
>
> On Sun, Mar 25, 2012 at 5:27 PM, Aaron Meurer <asme...@gmail.com> wrote:
>> There is already support in the git master for taking derivatives with
>> respect to functions and derivatives:
>>
>> In [153]: diff(x*f(x)**2 + f(x)*diff(f(x), x), f(x))
>> Out[153]:
>> d
>> 2⋅x⋅f(x) + ──(f(x))
>> dx
>>
>> In [154]: diff(x*f(x)**2 + f(x)*diff(f(x), x), diff(f(x), x))
>> Out[154]: f(x)
>>
>> So your boilerplate code would be unnecessary in SymPy.
>
> What about if f(x) isn't just f(x) but g(x,y,z,t)? And taking
> derivatives with respect to that (and its derivatives). That's the
> situation I'm in. I knew the f(x) case was implemented, but I didn't
> think that the g(x,y,z,t) case was. For straightforward dynamics
> problems, the f(x) case is enough, but once you add in flexible
> bodies, you need the g(x,y,z,t) case as well along with all possible
> derivatives.
In [162]: diff(x*g(x, y, z, t)**2 + g(x, y, z, t)*diff(g(x, y, z, t),
x), g(x, y, z, t))
Out[162]:
d
2⋅x⋅g(x, y, z, t) + ──(g(x, y, z, t))
dx
In [163]: diff(x*g(x, y, z, t)**2 + g(x, y, z, t)*diff(g(x, y, z, t),
x), diff(g(x, y, z, t), x))
Out[163]: g(x, y, z, t)
Take a look at the docstring of diff (in master) for how this is implemented.
Aaron Meurer
>
> I'd love to see a full Euler-Lagrange equation implementation. Most
> (including mine), only do the standard Euler-Lagrange equation, but
> for different functionals, you can can get much more complicated
> Euler-Lagrange equations than just the standard one. But, to get the
> full one, you'd need to implement Calculus of Variations and support
> taking a variation with respect to a functional. I have a basic
> implementation in Maple, but it's not particularly robust.
>
> Cheers,
>
> Tim.
>
> --
> Tim Lahey
> PhD Candidate, Systems Design Engineering
> University of Waterloo
> http://about.me/tjlahey
>
Tim Lahey
>
> In [162]: diff(x*g(x, y, z, t)**2 + g(x, y, z, t)*diff(g(x, y, z, t),
> x), g(x, y, z, t))
> Out[162]:
> d
> 2⋅x⋅g(x, y, z, t) + ──(g(x, y, z, t))
> dx
>
> In [163]: diff(x*g(x, y, z, t)**2 + g(x, y, z, t)*diff(g(x, y, z, t),
> x), diff(g(x, y, z, t), x))
> Out[163]: g(x, y, z, t)
>
> Take a look at the docstring of diff (in master) for how this is implemented.
>
Thanks! This is great. I think I need to delete my fork (I think all
my changes are already merged in) and make a new one. I really should
try this.
Aaron Meurer
And by the way, this was implemented last summer, so unless you
haven't pulled in a really long time, you might already have it.
Aaron Meurer
Tim Lahey
> There's no need to refork/reclone. Just checkout master and do git pull.
There's some problems with my clone. I didn't touch anything because
of outstanding pull requests, but I think they're all in now.
>
> And by the way, this was implemented last summer, so unless you
> haven't pulled in a really long time, you might already have it.
I haven't pulled in a long time (since before last year's GSoC). I
think this was done as part of GSoC.
Thanks,
Aaron Meurer
> On Sun, Mar 25, 2012 at 6:49 PM, Aaron Meurer <asme...@gmail.com> wrote:
>> There's no need to refork/reclone. Just checkout master and do git pull.
>
> There's some problems with my clone. I didn't touch anything because
> of outstanding pull requests, but I think they're all in now.
Whatever works for you, but it's always possible to clean things up
without recloning. I can help you do it if you want.
>
>>
>> And by the way, this was implemented last summer, so unless you
>> haven't pulled in a really long time, you might already have it.
>
> I haven't pulled in a long time (since before last year's GSoC). I
> think this was done as part of GSoC.
Yeah, it more or less was (Brian implemented it, partly to help out
Gilbert with his mechanics project).
Aaron Meurer
>
> Thanks,
>
> Tim.
>
> --
> Tim Lahey
> PhD Candidate, Systems Design Engineering
> University of Waterloo
> http://about.me/tjlahey
>
Jason Moore
Nice support for flexible systems in sympy.physics.mechanics would be a great addition. We haven't thought about that in great detail yet. But it is an obvious next step.
Jason
Luke
> sympy.physics.mechanics, one could use Euler, Lagrange, and possibly other
> methods to find the dynamical equations of motion for a system.
Elliot, since the kinematics part of sympy.physics.mechanics is in
pretty good shape, I would suggest outlining a Lagrange class, similar
in some regards to the Kane class, which would let the user specify
all information needed to construct the Lagrangian, and would then
generate the equations of motion.
Before you think to much about implementation, I think a valuable
thing to do would be to write out sample use cases and code sessions
which would show how a typical session would flow and would let you
think about the interface the Lagrange class would have. Try coming
up with a bunch of different interfaces to see what would be the most
intuitive to somebody who has their dynamics book opened to chapter on
Lagrange's method -- ideally I think you want a pretty close mapping
between the math and the code you write to perform that math
symbolically.
sympy.physics.mechanics needs improvement in the department of code
output. If implementing a Lagrange class proved straightforward, I
think it would make sense to build a code output class which could
take either a Kane object or a Lagrange object, and generate output
code in python/C/fortran/matlab/??? format which would then be usable
independently from the script you used to derive the equations in.
Another idea on this front is to have a member function to the Kane or
Lagrange class which could be passed directly to a python ODE
integrator like scipy.odeint, eliminating the need to output code to
file. This would allow you to derive and simulate all from the same
script. This might only be feasible for small problems though since
it will likely to be pretty slow.
Also, I think it makes sense to first tackle the case where you are
dealing with rigid bodies and you obtain ODE's, as opposed to flexible
bodies where you obtain PDE's. Once that is complete and works
reliably, it makes sense to pursue the flexible body case. I don't
think it make sense to pursue the flexible case until after that
though, and code output will vary significantly between the two
because you obtain PDE's in one case and ODE's in the other.
Luke
>
>
> On Tuesday, March 20, 2012 3:55:48 PM UTC-7, Elliot Marshall wrote:
>>
>> Hello world,
>>
>> I am a graduate student studying dynamics at UC Davis. We have been using
>> a dynamics package for one of my classes that was written by some current
>> graduate students in my research group. They have previous experience with
>> GSoC developing this dynamics package. The package is by no means completed
>> and I would like to work on developing it this summer. Any suggestions on
>> how to go about the application process would be greatly appreciated.
>>
>> Thank you,
>>
>> Elliot Marshall
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/sympy/-/50UcUmCEgGYJ.
>
> 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.
--
"Those who would give up essential liberty to purchase a little
temporary safety deserve neither liberty nor safety."
-- Benjamin Franklin, Historical Review of Pennsylvania, 1759
Aaron Meurer
Also look at the already existing code generation module, to see what
it can do and how it can be utilized.
Aaron Meurer
Elliot Marshall
Aaron Meurer
mechanics, so the code that computes the variation should be separate
from the code that is specific to mechanics.
Aaron Meurer
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/sympy/-/Zrs67r4y_6QJ.
Brian Granger
I sent earlier today? One important point is that there is absolutely
no reason to have a custom Lagrangian class. You can just build the
Lagrangian as a standard sympy expression. Please have a look at the
issue I opened on this topic:
http://code.google.com/p/sympy/issues/detail?id=3198
On Wed, Mar 28, 2012 at 2:35 PM, Elliot Marshall <marsha...@gmail.com> wrote:
> Thank you all for the input. This is very helpful. I would like to get to
> the point where a Lagrangian class can be used to produce equations of
> motion outputted in whatever format is desired. Allowing the user to select
> the output format would allow him to proceed with simulation in whatever
> manner he is most comfortable/knowledgeable with. It would also be cool to
> integrate simulation using sympy.odeint for simple problems to quickly get
> from problem statement to simulation.
>
> Elliot
>
> https://groups.google.com/d/msg/sympy/-/_R42XJLiq-0J.
> 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.
--
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgra...@calpoly.edu and elli...@gmail.com
Luke
> I sent earlier today? One important point is that there is absolutely
> no reason to have a custom Lagrangian class. You can just build the
> Lagrangian as a standard sympy expression.
One reason to have a custom Lagrangian class is that it helps keep
track of systems where you have a large number of
particles/bodies/constraints/interacting forces. For simple systems
you can surely write the Lagrangian in a line or two, but for more
interesting systems, it becomes onerous and error prone to do this
"manually". Having a class which allows you to pass it a list of
particles/bodies, and the forces/torques acting on them, as well as
any kinematic constraints that may be present, greatly simplifies the
work the user must do and reduces the likelihood of making a mistake.
I see many reasons to have a custom Lagrangian class.
Luke
Tim Lahey
>
> One reason to have a custom Lagrangian class is that it helps keep
> track of systems where you have a large number of
> particles/bodies/constraints/interacting forces. For simple systems
> you can surely write the Lagrangian in a line or two, but for more
> interesting systems, it becomes onerous and error prone to do this
> "manually". Having a class which allows you to pass it a list of
> particles/bodies, and the forces/torques acting on them, as well as
> any kinematic constraints that may be present, greatly simplifies the
> work the user must do and reduces the likelihood of making a mistake.
> I see many reasons to have a custom Lagrangian class.
I can see a reason to have a class to hold the Lagrangian (i.e., the
work-energy expression), but the Euler-Lagrange equation itself should
be broken out separately since it has uses far beyond mechanics. I've
been thinking about writing support for general Calculus of Variations
in SymPy, but it's likely to wait until the end of the summer at the
earliest.
Brian Granger
OK, I can see that such a class would be useful for more complex
systems, especially when things like constraints come into play. But,
users should always be able to define a Lagrangian using regular sympy
expressions. Also, the underlying Euler-Lagrange equations should
work with regular sympy expressions as well.
Cheers,
Brian
> Luke
>
> --
> 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.
>
--
Brian Granger
The Euler-Lagrange module I posted as a sympy issue already handles
most Lagrangians. The only thing I did not include is constraints,
but that should not be too diffcult to add.
Cheers,
Brian
> Cheers,
>
> Tim.
>
> --
> Tim Lahey
> PhD Candidate, Systems Design Engineering
> University of Waterloo
> http://about.me/tjlahey
>
> --
> 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.
>
--
Ronan Lamy
These are reasons to have a System class, with method(s) to create a
Lagrangian.
> I see many reasons to have a custom Lagrangian class.
I don't see how it would help. I think that it might rather cause code
duplication and confuse the notion of what a Lagrangian is.
Elliot Marshall
Gilbert gede
be some serious negative implications of attempting this.
For multibody systems, there can be a large number of internal forces
in contacts and joints (non-contributing forces). With Kane's Method
or Lagrange's Method, you do not need to consider these. However, with
the Newton-Euler method, these forces need to be included. If we were
to allow for a class which took in a system definition and could
return equations of motion using a variety of methods, I think bad
things could happen.
One example would be people forming their system with Lagrange's (or
Kane's) Method in mind, and do not include internal forces. If they
then generate equations with one of those, and with the Newton-Euler
method, the equations will not match (the latter will be wrong).
Alternatively, the user could be forced to include all of these forces
somehow, which would negate some of the advantages of the other
methods. In any case, I don't think it's a good idea for a class to
return both correct and incorrect equations depending on what Method
is used.
I'm also not sure if code duplication is a major concern. People who
use each of these methods have their own conventions, notations, and
ways they like to represent their systems. For example, Kane's Method
uses generalized speeds, which are not necessarily compatible with
Lagrange's Method. I would imagine making one class which had to
handle all of these potentially different use cases would have more
code (which would be more complicated) than 3 separate classes.
I'm not saying that a System class is a bad idea, but I think it
requires more consideration than just using one class to define
dynamic systems and having multiple equation output methods.
Perhaps an useful alternative would be to ensure that the classes for
each Method have interfaces which are as simple and consistent as
possible?
-Gilbert