Reorganizing the body classes

[tjstienstra]

This issue is coupled to the experimental mechanics development described in #24234. Feel free to comment down below and suggest improvements or even discuss a different approach.

Issue

The current implementation of the body classes follows the structure, where we have a RigidBody and a Particle class, which are both inherited by a Body class. This Body class can then be used to represent either a Particle or a RigidBody. The advantage of this Body class is that it has a same interface for both types of bodies, e.g. it has a frame. This Body class is used in the joints framework, as that requires a body to have a frame and a Particle does not have a frame. However there a several problems with this current implementation:

• In physics this inheritance is seen in the opposite way, a RigidBody and a Particle (also called a point mass` are both types of bodies.
• Double inheritance of two fully functional classes is messy.
• There are several compatibility problems, due to the fact that you have to handle a Particle, RigidBody and a Body differently. Body is not compatible with for example KanesMethod #23269 (note that these problems can be fixed).

Solution

A more logical structure would be an abstract body class, called BodyBase, from which both Particle and RigidBody inherit. This removes duplicated code, makes sure that they use the same interface and is also more logical from a physics point of view. The problem of a Particle not being compatible with the joints framework can be solved using the intermediate frames of the joints.

Implementation

The implementation of this reorganization in planned to be done in multiple PRs:

• [x] Update the bodies structure: BodyBase, Particle(BodyBase), RigidBody(BodyBase) (#24238)
• [x] Implement compatibility of Particle and RigidBody with Joint (#24550, #24699)
• [x] Deprecate Body
• [ ] Enhance bodies functionality:
  • [ ] Implement BodyBase.add_point and BodyBase.get_point
  • [ ] Implement RigidBody.as_thin_rod

[tjstienstra]

Do we want to keep a dcm, ang_vel_in, ang_acc_in in RigidBody or should someone just use RigidBody.frame.dcm? I thought I discussed this with someone some time ago and the conclusion was that it would be better to keep it really as composition.

[sujantkumarkv]

Hey @TJStienstra, we talked on the issue Make Body and ReferenceFrame analogous #21964 about implementing BodyBase and leaving Body & ReferenceFrame to composition. And, I see Body hasn't been deprecated yet.

Let me know the specifics to be done to solve this and/or to deprecate `Body'.

[tjstienstra]

Hey @sujantkumarkv, Good that you've read through the issue. I would like to deperecate Body and JointsMethod after implementing the currently implemented features in #24234. Therefore, I would not really recommend putting too much effort in Body. To give a little more inside in the planning: a current open PR implements the Inertia, next the Loads will be implemented (expect to open that one next week). If those are both merged I expect to open a PR implementing System, which will take some more time to get reviewed.

I don't have an immediate issue to point you at. What I would recommend is to experiment a little by solving a mechanics problem. In this process you will not only get some more experience with sympy.physics.mechanics, but you can also find bugs and inconveniences. This is a good reference if you need to know more about the mechanics used in SymPy.

P.S. There are currently also some issues/PRs mentioning that some parts of mechanics are a bit slow. Maybe looking into how for example KanesMethod can be made faster is also worth looking into.

[tjstienstra]

Another challenging but forgotten issue, which might be nice to look in is #23382. Note that this is an issue which might actually be a bit too tricky.