Jason, Responses interleaved below,
On Fri, Apr 6, 2012 at 8:15 PM, Jason Moore <[email protected]> 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/a368bc0c871a75cbea0ffe1a2efc553fced1cbd6/sympy/physics/mechanics/kane.py#L471 > > 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 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.
