Tim, I can try and explain why a few of these things are the way they are.
As we have learned to deal with inertias for multibody systems, it has made the most sense to use dyadics, as they are reference frame independent (as Jason stated). I understand your confusion with the RigidBody example not showing the inertia function, changing this probably could help to make things more clear. I would also recommend that you look through the documentation online: http://docs.sympy.org/dev/modules/physics/mechanics/index.html The implementation of the Parallel Axis Theorem is indeed hidden inside the Kane class; there are multiple reasons for this. One is that the inertia of a rigid body will obviously be different around different points, as the mr^2 term has to be added. When dealing with a dyadic which represents the inertia, we don't have the mass of the associated rigid body, and cannot compute the new inertia dyadic. By putting this within Kane, this operation happens at a point in time where we have both the mass and inertia dyadic for the rigid body. If you want to do it outside of Kane, you can either repurpose the code which is within Kane, or a function could be written. At the time, I decided that if people were going to be doing operations on inertia dyadics they would be comfortable doing the dyadic manipulations in their script, or that they would have a known inertia dyadic about another point, did not want to have to think about this, and could just supply things that way. The kinematic_equations function is used to relate whatever generalized speeds and generalized coordinates you are using which are involved in the orientation of reference frames. They are indeed hard coded for a variety of rotation types, mainly those using Euler angles or Euler parameters. Obviously, more work could be done here; Rodrigues parameters are obviously not included but could be, or rotations about an arbitrary axis. The point of this function was to remove the need for the user to look up these kinematic differential equations; more functionality could be added if desired. dyanmicssymbols simply produces undefined functions of time. You could certainly make your own undefined functions of time and coordinates. I also have to admit I'm not sure which examples you have been looking at; letting me know which ones have deficiencies allows me to improve them. I understand that the implementation of everything in this module might not be to your taste. I would, however, implore you to do two things to help with this, if you would like to see improvements: submit issues for the problems you've found, as Jason said, where things are not clear or need more explanation; and please share (in electronic form) some references and examples which illustrate the ways in which you do dynamics and in which you have taught dynamics. I do not think simply ignoring everything in here and writing your own approach will be very a good use of your time or will be beneficial for everyone. It does not give us a chance to improve what is here so it can be more accessible to more people. -Gilbert On Apr 6, 9:56 pm, Tim Lahey <tim.la...@gmail.com> wrote: > Jason, > > Responses interleaved below, > > On Fri, Apr 6, 2012 at 8:15 PM, Jason Moore <moorepa...@gmail.com> wrote: > > > I would beg differ. The equation of motion derivation is completely separate > > from the kinematic and kinetic definitions. As is stands, any method of > > equation of motion derivation can be used to solve classical multi-body > > dynamics with the currently defined classes. We haven't written any examples > > for methods other than Kane's yet due to sparse resources to do so. We also > > haven't implemented automated classes for any other methods yet, for the > > same reason. One GoSC code applicant hopes to remedy both of those issues > > this summer. > > True, you can use any approach for the kinematic definitions and still > derive the equations of motion using a different approach. That said, > what I'm saying is that the mechanics package's approach for the > kinematics is very different than what one would use if it was based > upon a different text. The approach to a vector illustrates this. The > approach I learnt for advanced dynamics embeds the frame as part of > the vector. Both approaches aren't wrong, just different. > > The problem I have is that a lot of decisions have been fixed so > there's little flexibility. I'll probably have to ignore the whole > thing and write my own. For example, the decision representing the > inertia as a dyad rather than a matrix or a tensor. By choosing a > dyad, I can't just pull the matrix out and use matrix algebra tools > with it (e.g., matrix multiplication for rotations). The same problem > occurs with the use of "dynamicsymbol" which assumes that the symbol > is only a function of time. This precludes flexible bodies. This alone > means I can't use it. > > > > > We have a dyadic class to handle inertia. Dyadics are typically not as > > popular as tensor formulations but they have the advantage of being basis > > independent (unlike tensors). We probably need more functionality to expose > > the dyadics as tensors so that they folks who don't want to learn about > > dyadics may have an easier time working with them. The current inertia > > function is one such function that does that. It allows you to define an > > inertia dyadic with a tensor like formulation. > > I understand about inertia dyads, but they have limitations of their own. > > > > > We don't have an explicit parallel axis method or function. Here is an > > example of how you can write the parallel axis function with dyadic > > notation: > >https://github.com/angadhn/sympy/blob/a368bc0c871a75cbea0ffe1a2efc553... > > > We'd love for someone to formalize this into some functions that follow the > > more traditional ideas for ease of understanding. > > This is one of the problems of using an inertia dyad. Most texts will > present an inertia matrix (or tensor) and give the parallel axis > theorem as a matrix. Plus, rotation of the inertia matrix can be > handled easily using rotation matrices. Given good matrix support, > this can be more efficient. > > > > > As with all open source projects, the documentation is sometimes weak. > > Please submit issues with regards to missing documentation and we all can > > try to remedy it. > > The problem is that there's a lot of problems with the documentation. > I only pointed out the problems with just the first example. I > shouldn't be the one to fix the issues since I only have a partial > understanding of the examples and I don't want to introduce errors. > > > > > We have a Vector class that, by design, was not intended to be generated > > explicitly. The approach is to create a reference frame and specify vectors > > using the basis of the reference frame. > > > It would be relatively easy to add vector creation functions/methods as you > > suggest that interact with the Vector class, giving a different view on the > > creation and manipulation of vectors. > > I don't have a problem with creating a reference frame, it's just I > can't see why one couldn't just pass a reference frame to a vector > constructor along with components that multiply the basis vectors. > > > v2pt and a2pt are helper methods to define velocities of points on the same > > rigid body. You don't have to use them if you don't want to. > > I don't have a problem with them (except the names), but the example > doesn't explain what's happening when they're being called. Why the > _theory suffix, it seems unnecessary? > > > We'd love to see some pull requests implementing features that you've > > suggested. We'd also gladly fix and improve and documentation errors or > > clarity issues that you find. The easy way to keep track of that would be > > submitting them as issues. > > It will take some time, but I'll try and put together some issues to > help fix the documentation. > > Cheers, > > Tim. > > -- > Tim Lahey > PhD Candidate, Systems Design Engineering > University of Waterloohttp://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 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.
