Hi, I've responded below.
On Sat, Apr 7, 2012 at 1:58 AM, Gilbert gede <[email protected]> wrote: > 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 I've been looking at the documentation, but part of the problem is that documentation assumes a lot on the part of the reader. > > 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. Having it as part of the Kane class is a bad idea since it leads to duplication of code. I don't think it makes sense to have an inertia outside of a rigid body. If you contain it in a rigid body, then you have all the information you need. Plus, if you associate it with a frame and not just a point, you can handle the rotation of the inertia to a new frame or translation to another frame by telling it to switch the inertia to a different frame. Based upon the relationship between the frames, you'd apply parallel axis theorem or rotations as appropriate. > > 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. I was wondering about the hard-coding aspect rather than deriving them directly. It just seemed like a lot of unnecessary work over a derivation approach. Plus, since the symbols aren't explained anywhere in the docstring, it's a bit hard to read. > > dyanmicssymbols simply produces undefined functions of time. You could > certainly make your own undefined functions of time and coordinates. It's not clear how to do that since dynamicsymbol is kind of throughout the code. > > 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 was looking at the Rolling Disc first example. > > 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. The text I learnt dynamics from doesn't exist in electronic (or printed form) yet. My supervisor and his co-author are working on it for Cambridge University Press (I think). They originally learnt it at UTIAS (University of Toronto Institute for Aerospace Studies). It's well suited to computational implementation and has nice compact notation. Another grad student I know implemented it using Matlab's symbolic toolbox. That said, the approach the mechanics module is using is different from a lot of texts I've read. > > 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. The problem is that a lot of assumptions are built-in (e.g., the dynamics symbol business and how inertia is handled) and it's likely faster for me to just write my own rather than work around them. I'm not going to do it in the short term since I already have a working package in Maple that meets my needs. It's not as automatic, but I prefer that so I don't have to worry as much about possible errors in a code black box. I want to peek inside to make sure everything is correct. 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.
