Tim, More interspersed below:
On Friday, April 6, 2012 9:56:15 PM UTC-7, Tim Lahey wrote: > > 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 Vector class which is implemented does embed frame(s) as part of the vector. If you check out the Vector class design you will see that it contains the both scalars and reference frames. Keep in mind that Vectors can be defined with respect to multiple frames and the current formulation allows that. > 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). > See below. > 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. > I feel like the dynamic symbol could surely be expanded to be a function of space and time, ultimately allowing for flexible bodies. Or some other spatial symbol introduced. I'm sure there is a solution that will work within the framework we've set up. But the reality is that it was not designed from the ground up for flexible bodies and that may be an issue. Probably not surmountable though. > > > > 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. > I don't think the the current inertia structure precludes this at all. There is nothing stopping anyone from writing a method which returns the inertia matrix from the Inertia object with respect to a reference frame. You can then do all the matrix operations on it that you want. I could imagine some thing like: I = inertia(N, 1, 2, 3) # create inertia dyadic rotI = A.dcm(N).transpose() * I.matrix(N) * A.dcm(N) # rotI is just a matrix where I.matrix(N) returns the matrix form of the inertia with respect to a given reference frame. but why do that when you can already simply type: I.express(A) for the same result. or I.matrix(A) if we add this new matrix method. Another option would be to allow the add, subtract, multiply, etc operators for the inertia class interact with a matrix in the way you are asking. But careful attention will be needed by the user to keep track of the which reference frame the inertia is define with respect to as matrices do not contain this information. Just because we have an inertia dyadic built in that is recognized by the RigidBody class and is inter-operable with reference frames and vectors doesn't necessarily mean you can't work with matrices instead. > > > 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. > Adding new examples is also encouraged. Especially those from others' perspectives. > > > > > 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. > This can be done, it would just be a simple case of the general vector construction that we have implemented. A vector function could be written to do that. For example: v = vector(frameA, (a, b, c)) # would create a vector in frame A with a, b and c as the i, j, k measure numbers. Keep in mind that our more general formulation allows one to create vectors from components defined in as many reference frames as you want. v = a * N.x + b * A.y + c *H.z + d * N.y > > 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? > No idea. At one point it didn't have the theory part on it. I'm not sure why it changed. You can git blame the code to see who changed it. > > 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. > Awesome. > 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 view this discussion on the web visit https://groups.google.com/d/msg/sympy/-/tvu6TKpVaCIJ. 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.
