GSoC 2022 Blog

Final Overview

2022-10-03T10:00:00+00:00

This will be my last post with a full overview of all my contributions during GSoC 2022.

Project Synopsis

The aim of this project was to further develop the construction of systems from bodies and joints. This was done in three phases with a preparation on beforehand. The first phase focused on fixing existing bugs and adding documentation in order to make the joints framework ready for the upgrades. The second face consisted of implementing the intermediate frames in combination with a joint axis, which allows for more complex joint definitions. In the third phase multiple new joints were added, namely the cylindrical joint, planar joint and at last the spherical joint.

Contribution Overview

This section discusses my GSoC 2022 related contributions to SymPy. The contributions are split in four parts: (0) Preparation phase of GSoC. (1) Improved documentation. (2) Enhanced joints definition. (3) New joints. In order to make the overview more clear the following color coding is used: open issue, open PR and merged/closed PR or issue.

GSoC preparation

During the application progress of GSoC I have done the following contributions, which were mainly focused on fixing existing bugs and issues:

Raised and closed issue #23358 on the incorrect velocity calculation of Point.vel with merged PR #23362.
Opened draft PR #23359 proposing a zero velocity check to the velocity and acceleration theorems.
Raised issue #23382 which advises to compute the velocity in the Point.vel method in a recursive way.
Closed issue #22956 on incorrect PinJoint velocity with merged PR #23392.
Raised and closed issue #23393 which was a discussion on what the definition of a velocity in a frame is.

Improved Documentation

In the first official phase of GSoC the focus lay on improving the documentation together with fixing existing bugs. The major contributions during this phase was writing documentation of the joints framework in general including images explaining the joints. One of the main issues I ran into during this phase was the sub-optimal definition of a joint in general, which became the main focus of phase 2. Below is a list of all contributions during phase 1.

Participated in the still open issue #21964 on making the Body analogous to ReferenceFrame.
Reviewed still open PR #23580 on returning kinematic equations implicitly in KanesMethod.
Merged PR #23628 which enhances the Point.acc method to also compute the acceleration if the velocity is not yet defined.
Merged PR #23705 adding the four-bar-linkage example using the joints framework.
Raised issue #23706 on the visibility of images when using the new dark theme.
Closed issue #21705 on the need of a figure explaining the Joint arguments with merged PR #23730.
Raised issue #23741 discussing how ReferenceFrame and Point should go about saving states.
Merged PR #23890 converting the joint images introduced in #23730 to svg.

Enhanced Joint Definition

During phase 1 I ran into a suboptimal definition in the Joint class. Namely, that a so called parent_axis and child_axis were used to almost magically create an intermediate frame from which the joint was defined.

In the by my mentors advised paper by Seth et al. a mobilizer definition is proposed. One of the notable differences between the mobilizer definition and the joint definition in SymPy at the time is the use of intermediate frames for both the parent body and child body. So after some discussing it was chosen to implement these intermediate frames (abbreviated interframes) in the Joint class. However one of the major advantages of the parent_axis and child_axis was there intuitive and simple use. In order to keep this advantage, the options that one can supply a vector to an interframe argument was added. If done so the interframe is oriented such that its X axis aligns with this provided vector.

Below is again a list of all contributions during phase 2.

Raised and closed issue #23913 on the problem that the use of temporary relationships between ReferenceFrames in the Joint class can lead to deleting correct relations with merged PR #23920.
Merged PR #23920 changing the definition of a Joint to use intermediate frames.
Raised and closed issue #23933 on the unnecessary dependency of test_pinjoin_arbitrary_axis on test_functions.py with merged PR #24028.
Merged PR #23981 adding an optional frame argument to RigidBody.parallel_axis and implementing Body.parallel_axis.
Merged PR #23982 changing Body to always have an inertia, also when representing a Particle. This partially solves issue #23269.

New Joints

In this final phase the main contributions were the implementation of the CylindricalJoint, PlanarJoint and SphericalJoint. One notable other change was reverting the in phase 2 introduced JointAxisMixin.

Raised issue #1929 in the symengine on the problem of stackability of null Matrices.
Raised and closed issue #24005 on the problem that a CI slow test 2 failed due to a timeout. However due to irreproducibility this issue was also closed.
Merged PR #24028 implementing a generic coordinate generation helper.
Merged PR #24037 implementing the CylindricalJoint.
Merged PR #24046 implementing the PlanarJoint.
Merged PR #24053 implementing the SphericalJoint in which #24098 is also fixed.
Merged PR #24080 reverting the JointAxisMixin for simplicity, which was introduced in #23920.
Merged PR [#24085], which simplifies the angular velocity computation in orient_body_fixed and orient_space_fixed, while also fixing closed issue #23075.

Conclusions

When comparing the contributions to the initial proposal, it is fair to say that the proposed contributions have been met. However the number of implemented examples is a bit lower than anticipated, but at the same time there has also been chosen for a more flexible implementation than the quaternion support for the parent_axis and child_axis. The final implementation actually uses a ReferenceFrame, which can be created by using for example a quaternion. Furthermore there have also been multiple smaller contributions, which are outside the original scope of the proposal.

Future Work

Generalize the abstract class for method, i.e. _Method
Refactor the design of how bodies and loads are used \begin{itemize}
- Deprecate Body, instead create a abstract _Body for RigidBody and Particle
- Create classes for the loads, e.g. _Load, Force, Torque \end{itemize}
Implement a more easy method to add constraints in the joints framework
Implement a kdes_choice = 'efficient' argument for the joints, which uses the most ideal choice of the generalized coordinates based on the paper of Mitiguy and Kane.
Add more examples on using the joints framework

Acknowledgments

This project would not have been possible without my mentors, who reviewed most of my PRs and helped me to make lots of design decisions. I would like to thank Jason K. Moore specifically for his push to always keep thinking about backwards compatibility. Sudeep Sidhu I would like to thank for providing the good initial setup of the joints framework. And Sam Brockie for his quick replies and the many reviews and discussions on what would be the best way to implement a certain feature. At last I would also like to thanks all contributors to SymPy for helping getting started, finding bugs, reviewing and so on.

Week 37

2022-09-16T16:00:00+00:00

Here is a short overview of the PRs merged and the ones opened:

Merged PR #24028 implementing a generic coordinate generation helper, which is ready for merging.
merged PR #24037 implementing the CylindricalJoint, which will be ready for review as soon as #24028 is merged.
Opened PR #24046 implementing the PlanarJoint, which is almost ready for merging. Currently a decision should be made what inputs for defining the rotation_axis and planar_vectors will be supported
Opened draft PR #24053 implementing the SphericalJoint, which will be ready for review as soon as #24046 is merged.

As for what is next, I am almost finished with what is in my GSoC proposal. So now, I’m researching what I will focus on during my thesis, which I’d like to couple to SymPy.

Week 36

2022-09-09T16:00:00+00:00

Decided to make my posts on Friday, so it is more of a reflection of past week (in this case a little more). Besides that I’m also gonna try to keep using the format of my midterm overview. So what has happened:

Merged PR #23981 adding an optional frame argument to RigidBody.parallel_axis and implementing Body.parallel_axis.
Merged PR #23982 changing Body to always have an inertia, also when representing a Particle. This will partially solve issue #23269.
Merged PR #23920 changing the definition of a Joint to use intermediate frames. Something that was specifically added last week was the support for supplying an axis with which the interframe should align its X axis. Something which surprisingly gives the exact same results as parent_axis and child_axis did (means that those rotations were actually chosen more logical than I thought).
Closed issue #23913 on the problem that the use of temporary relationships between ReferenceFrames in the Joint class can lead to deleting correct relations. Was also fixed in #23920.
Raised issue #1929 in the symengine on the problem of stackability of null Matrices.
Raised and closed issue #24005 on the problem that a CI slow test 2 failed due to a timeout. However due to irreproducibility this issue was also closed.
Opened PR #24028 implementing a generic coordinate generation helper, which is ready for merging.
Opened draft PR #24037 implementing the CylindricalJoint, which will be ready for review as soon as #24028 is merged.

As you can see from the list above, quite a few things have happened and I’m happy with the progress. A lot of this progress is also due to the help in reviewing and conceptual problem solving I got from Sam Brockie, who is now also able to work full time on SymPy. Next week I also hope to publish the PRs of the PlanarJoint and SphericalJoint. And probably also finish of that state saving issue #23741 by just going for the easy solution, namely leaving almost everything as is and just removing the to aggressive relation deletion of ReferenceFrame._dcm (#23913).

Midterm overview

2022-08-29T12:35:00+00:00

It seemed good to me to make a midterm overview of what I have done. It would have been better if I would have done this a week earlier, before my midterm, but this will in the end also be helpful for the final evaluation.

GitHub references

Below I summarize the issues and PRs that I’ve worked on. The following color coding has been used: merged/closed PR or issue, open issue and open PR.

In preparation of GSoC:

Raised and closed issue #23358 on the incorrect velocity calculation of Point.vel with merged PR #23362.
Opened draft PR #23359 proposing a zero velocity check to the velocity and acceleration theorems.
Raised issue #23382 which advises to compute the velocity in the Point.vel method in a recursive way.
Closed issue #22956 on incorrect PinJoint velocity with merged PR #23392.
Raised and closed issue #23393 which was a discussion on what the definition of a velocity in a frame is.

During GSoC period:

Participated in issue #21964 on making the Body analogous to ReferenceFrame.
Reviewed still open PR #23580 on returning kinematic equations implicitly in KanesMethod.
Merged PR #23628 which enhances the Point.acc method to also compute the acceleration if the velocity is not yet defined.
Merged PR #23705 adding the four-bar-linkage example using Joints.
Raised issue #23706 on the visibility of images when using the new dark theme.
Closed issue #21705 on the need of a figure explaining the Joint arguments with merged PR #23730.
Raised issue #23741 discussing how ReferenceFrame and Point should go about saving states.
Merged PR #23890 converting the joint images introduced in #23730 to svg.
Raised issue #23913 on the problem that the use of temporary relationships between ReferenceFrames in the Joint class can lead to deleting correct relations.
Opened PR #23920 changing the definition of a Joint to use intermediate frames.
Raised issue #23933 on the unnecessary dependency of test_pinjoin_arbitrary_axis on test_functions.py.
Opened PR #23981 adding an optional frame argument to RigidBody.parallel_axis and implementing Body.parallel_axis.
Opened PR #23982 changing Body to always have an inertia, also when representing a Particle. This will partially solve issue #23269.

Short reflection

Overall I’m quite happy with this list. Multiple things have been improved (green), for which I also have to thank my mentors. Especially the advise of reading this paper was really good, partially because it also lead to #23920 and maybe more. And there are also some open PRs ready for review (blue), so still work in progress :)

Recommendation

When going over the list a few things can be noticed.

Firstly a decision how to go around with state saving should be made. Since this affects: #23741, #23913, #23359 (follow up of #12322), #23382 and probably also some other issues and PRs from the past. Personally I would like a system, where only methods used by the user to create a relationship (e.g. Point.set_vel) may store a state in the state dicts (e.g. _dcm_dict). While the other methods, which compute a requested relationship (e.g. Point.vel) store the states in a separate cache dict (e.g. _vel_cache). Overwriting a state in the state dict results in resetting all cache dicts to be the same as the state dicts, while in the state dicts only the edited state will be updated. So, if the user did use the previous state to save another state, than this state will not be affected.

A second more like set of problems, which is not entirely notable in this list, is that the Body class is currently underdeveloped. Namely a clear decision should be made and executed on how analogous a Body should be to a ReferenceFrame. This mainly affects: #21964, which has multiple open PRs: #21974, #22926. Another problem is that Body is currently not fully compatible with KanesMethod and LagrangeMethod (#23269). However this is mainly a problem that should be fixed within _Method (#21772).

Lastly, there is also still a need for more joint types, so that is also where I’m currently working on.

Week 34

2022-08-29T06:22:00+00:00

This week I finally set this PR on intermediate frames as ready to review. Besides that I have also created a PR, which adds the optional frame argument to RigidBody.parallel_axis and also implements the parallel_axis method for the Body class. As well as a PR which partially fixes the issue of KanesMethod not being compatible with Body objects, which represents a Particle. This is done by changing the inertia of a Body representing a Particle to zero. Besides that this PR also adds a central inertia setter to RigidBody. As a last thing I have been working on is the implementation of new joint types, mainly the SphericalJoint. However I have not yet published a PR for this, since my implementation is currently dependent on the PR on intermediate frames.

Issues and PRs I’m working on:

This PR which switches the Joint definition to use intermediate frames.
This PR which implements the parallel_axis method for the Body class.
This PR which changes the inertia of a Body representing a Particle to zero.
Raised issue about the dependency between test_pinjoin_arbitrary_axis and test_functions.py.
Raised issue about a problem that defining a new joint in a certain way can lead to a deletion of a previous joint.
Raised issue about the inconsistency in storing velocity and acceleration data in the Point class.
My comment on how we could make the Body class more analogous to a ReferenceFrame.

Some other opened issues an PRs, which I have open, but am not currently working on:

PR I reviewed (awaiting changes)
Issue about image readability in the new dark theme.
Issue about using a recursive calculation of the velocity in the Point.vel method
Draft PR which adds a check on the velocity and acceleration theories as mentioned in the old PR
- Needs a decision as mentioned in this comment
- An issue I’m participating in, which is about making the KanesMethod compatible with the Body class.

Week 33

2022-08-22T13:45:00+00:00

Still working this draft PR, which is now close to ready to really get reviewed. Besides the change to the intermediate frames. This PR now also proposes to replace the parent_joint_pos and child_joint_pos arguments by parent_point and child_point, since that is way more intuitive. Besides that I’ve also opened this issue, which is about a dependency between two tests (an easy fix).

Issues and PRs I’m working on:

This draft PR which switches the Joint definition to use intermediate frames.
Raised issue about the dependency between test_pinjoin_arbitrary_axis and test_functions.py.
Raised issue about a problem that defining a new joint in a certain way can lead to a deletion of a previous joint.
Raised issue about the inconsistency in storing velocity and acceleration data in the Point class.
My comment on how we could make the Body class more analogous to a ReferenceFrame.

Some other opened issues an PRs, which I have open, but am not currently working on:

PR I reviewed (awaiting changes)
Issue about image readability in the new dark theme.
Issue about using a recursive calculation of the velocity in the Point.vel method
Draft PR which adds a check on the velocity and acceleration theories as mentioned in the old PR
- Needs a decision as mentioned in this comment
- An issue I’m participating in, which is about making the KanesMethod compatible with the Body class.

Week 32

2022-08-15T09:55:00+00:00

Just before I went on vacation the documentation PRs, i.e. PR about adding a four bar linkage example and the PR explaining the joints framework using figures were merged. Also the PR, which improves the Point.acc method, was merged. However, after my holiday I heard the request of making these figures a bit smaller in filesize. So, this last week I converted them to SVGs in this already merged PR. After this I mainly did some reading up and investigating how we could introduce a Mobilizer joint as described in this paper by Seth, A., Sherman, M., Eastman, P., & Delp, S.

This lead to raising this issue. But the main thing I started working on is this draft PR, which changes the definition of a Joint to be a bit more general. Where we were first using a parent_axis and child_axis to describe an intermediate frame and the joint axis. It is now changed to use a given intermediate frame for the parent as well as the child. And for the joint axis we use a separate argument joint_axis. I would love to write and explain a lot more about this PR, but if you are interested you’d better just visit it.

Issues and PRs I’m working on:

this draft PR which switches the Joint definition to use intermediate frames.
Raised issue about a problem that defining a new joint in a certain way can lead to a deletion of a previous joint.
Raised issue about the inconsistency in storing velocity and acceleration data in the Point class.
My comment on how we could make the Body class more analogous to a ReferenceFrame.

Some other opened issues an PRs, which I have open, but am not currently working on:

PR I reviewed
Issue about image readability in the new dark theme.
Issue about using a recursive calculation of the velocity in the Point.vel method
Draft PR which adds a check on the velocity and acceleration theories as mentioned in the old PR
- Needs a decision as mentioned in this comment
- An issue I’m participating in, which is about making the KanesMethod compatible with the Body class.

Week 28

2022-07-14T18:15:00+00:00

This is a short post, since I was busy this week with my last exam and preparing for my vacation next few weeks. This also means that I won’t make posts for the next few weeks. As for now I am currently focused partially on making the Body class better integrated within the mechanics, while awaiting reviews on some documentation PRs.

Issues and PRs I’m working on:

PR, which adds a four bar linkage example using the joints framework.
This issue about creating a figure to explain the joint parameters is being solved in this PR
The PR, which would reduce Point.acc dependency on computed velocities.
Raised issue about the inconsistency in storing velocity and acceleration data in the Point class.
My comment on how we could make the Body class more analogous to a ReferenceFrame.

Some other opened issues an PRs, which I have open, but am not currently working on:

PR I reviewed
Issue about image readability in the new dark theme.
Issue about using a recursive calculation of the velocity in the Point.vel method
Draft PR which adds a check on the velocity and acceleration theories as mentioned in the old PR
- Needs a decision as mentioned in this comment
- An issue I’m participating in, which is about making the KanesMethod compatible with the Body class.

Week 27

2022-07-08T18:15:00+00:00

This is finally the first week that I could work full time on GSoC. Started this week with reviewing a PR for the first time. Furthermore I mostly focused this week on documentation. You already saw the draft of the four bar linkage example last week. During which I ran into various other things. First of the amazing dark theme available in the SymPy dev documentation causes some images to be barely readable (raised #23706). Another thing I already new I wanted to do is that there should be a real guide on the Joints Framework. So I made a draft PR about implementing a real guide on the Joints Framework in the physics/mechanics module (checkout the image below for a quick preview). Yesterday, I presented this to my mentors and got positive feedback. We also had a discussion about consistency within the code which raised this issue. Also the planning is to have either next week or after my holiday a discussion about what we actually have within the Mechanics module and what we actually want.

Issues and PRs I’m working on:

The PR I’m reviewing
PR, which adds a four bar linkage example using the joints framework.
This issue about creating a figure to explain the joint parameters is being solved in this PR
The PR, which would reduce Point.acc dependency on computed velocities.
Raised issue about the inconsistency in storing velocity and acceleration data in the Point class.

Some other opened issues an PRs, which I have open, but am not currently working on:

Issue about image readability in the new dark theme.
Issue about using a recursive calculation of the velocity in the Point.vel method
Draft PR which adds a check on the velocity and acceleration theories as mentioned in the old PR
- Needs a decision as mentioned in this comment

Week 26

2022-06-29T18:15:00+00:00

Hi again, this is a quick post about my schedule for this GSoC. Made after meeting my mentors for a kickoff meeting, which was great by the way. As I already mentioned a bit in my first post is there a slight change. I will still be working on the documentation these first few weeks ‘till July 14. August 8 I hope to start working on the kinematic loops for which I will have to research some other solutions for as well. At last I hope to implement add some more joints. The part which I will probably skip is adding option to define the orientation of a joint using quaternions. But overall I think it is going to be a nice fun challenge.

Issues and PRs I’ll be working on:

Opened a draft PR adding four bar linkage example which uses the joints framework.
While working on the PR above I raised an issue on the visibility of images when using the new dark theme.
This week and next week I expect to work on the issue about creating a figure to explain the joint parameters.
Hope that this PR, which would reduce Point.acc dependency on computed velocities, can be merged.

Some other opened issues an PRs, which I have open, but am not currently working on:

Issue about using a recursive calculation of the velocity in the Point.vel method
Draft PR which adds a check on the velocity and acceleration theories as mentioned in the old PR
- Needs a decision as mentioned in this comment