GSoC Blog Post

August 4, 2012

So, in last week’s post I had said that the Lagrange class had neared completion. By mid-week I had it functional, so I opened a discussion on the mailing list asking for suggestions to improve the class. Several people in the group suggested that it’d be better to supply all the parameters on initialization. At first I was loath to make this change. This was for the following few reasons-

My primary concern was that I felt it was taking away from the clarity in generating the equations of motion. I have spoken about that in some detail in the conversation on the group page about how I feel dynamicists would probably prefer typing an extra couple lines as long as the procedure to obtain the equations of motion feel similar to the work done by hand. I’m a a fan of the (possibly false) sense of security that comes from bookkeeping even whilst on a computer. Of course, I had to accede that it made no sense to have so many methods when everything could be passed at initialization. The argument that users would essentially have to memorize a sequence or procedure was a good one.

The other thing was that I felt was that this was making the structure of the ‘Lagrange’ class tremendously different from the ‘Kane’ class. But after discussions with Luke, Jason and Gilbert it became pretty apparent that even they felt that it might not have been the best way to implement that class. At one point I too felt like it was little weird that I was creating so many little methods which could’ve been merged into the initialization of the class itself. But I was just concentrating on staying true to the current structure of things in the mechanics package.

And the final reason for my apprehension was that I would have to revamp the whole method after having spent quite some time on it.

But it was very clear after a point that things had to change. So, I spent a good chunk of time making the required changes.

Also, we decided on, what I feel is, a more appropriate name for the class changing it from ‘Lagrange’ to ‘LagrangesMethod’. Most of the equation derivation techniques in dynamics have the ‘Method’ attached to the founder’s name. It made even more sense for this class because Lagrange’s contributions are numerous so just calling a class ‘Lagrange’ could lead to some ambiguity.

Rewriting the class also helped me hone my Python skills some more. I had come across the keyword arguments construct several times in my preparation for the summer of code but I was a little reluctant to use it. It was probably because it was something that felt so alien to me as I have never seen something like that in my fledgling programming career. But with great explanations on the groups message (linked above), things were made clearer as to how it should be done.

So having rewritten the class, I added the docstrings for it. I’m not too pleased with that part right now, but I’m confident it will get better with more input on the PR discussion.

So having opened that PR, I thought I would get back to working on the documentation as I had planned. But I ended up going off on a tangent with the discussion that was sparked on PR 1407 which is the stuff that I have added on the energy functions. I spent a good chunk of time going through that and almost completely changing the way the ‘kinetic_energy’ function works.

On that same PR, there was a discussion about how a more readable error should be generated if a user calls the ‘potential_energy’ property for either a Particle or RigidBody without having first set the potential energy using the ‘set_potential_energy’ method. What at the time seemed an innocuous thing to repair became a little interesting challenge for me. Without going into too many more details, I was pleased to have found a relatively simple fix with the ‘callable’ function in Python with the help of the online forum ‘Stack Overflow’.

Having handled most of the recommendations on PR1407, I decided to skip on the documentation for the time being and returned to “complete” what would be the most important part relatied to the “LagrangesMethod” class- the test! While writing the class, I had written a little dummytest to check for the little tihngs but I hadn’t subjected a real dynamical system to the ultimate test (pun intended). I decided to test the well known ‘disc rolling down an inclined plane’ problem. Not to generate any suspense, but I would like to point out that in my proposal I had said that I would only concentrate on unconstrained systems. But Gilbert and I spent a little more time to make the ‘LagrangesMethod’ class more useful and complete. The class should now be able to handle any system i.e. constrained or unconstrained. A lot of the credit goes to Gilbert for helping me through the numerous confusions I had with the implementation of the constrained systems. But back to the test. I picked that system because it has a configuration constraint and we handle configuration constraints a little unconventionally in this class. I was a little anxious about how the results for this would turn out but ti worked like a charm. With the one test that I have written, which I think is a pretty good system to test, it appears that the ‘LagrangesMethod’ class works like a charm.

Anyhow, it’s now time to get some shuteye and more importantly rest the leg as I have been a little cavalier with it in the last couple of days. Until next week.

Share this:

Like this:

Related

Nice work on all this! Especially making the extra effort for the constrained systems. You are going to be proud that you went through all that and even these rewrites that you loath come the end of the summer. One thing a programmer can’t be shy about is overwriting code that took a long time to write…sometimes there is just better ways to do it. I’m sure every programmers has tons more tossed code than what they have in production use. It is just the nature of the game.