On Sun, Mar 25, 2012 at 11:17 PM, Tim Lahey <[email protected]> wrote: > Hi, > > 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 <[email protected]> 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.
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 > > -- > 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.
