GSoC: Week 2 : Reference Frames

This is an update for the second week of my GSoC coding period. Its been long and quite tedious (though very interesting at times), as far as the code was concerned. Got a lot of stuff done in the commits this week, and I guess the major components of the reference frame class are now in place. Well, I can't be sure whether its perfect till Gilbert reviews it, but all that we discussed is more or less there. The things that got done this week-

• The initializer for the MovingRefFrame class. Its huge and dense as I had said earlier, but it gets the job done well, and prevents any 'special cases' from wreaking havoc while at the same time giving all the needed functionality. As mentioned in the last week, the functions for boundary conditions have now been implemented in a file of their own, and they get called in this class' 'init' function. There were some other issues as well, like allowing velocities to be defined in frames that don't 'exist' yet, etc. But thankfully, they got solved after some thinking(read: thinking hard).
• I rewrote the tree algorithm for finding relative motion parameters, since the one I had implemented earlier went via the global frame everytime- something that made the whole process very inefficient(and computationally impractical) at times. To get an idea of what I am talking about, imagine a 100 reference frames, each defined at some orientation/position wrt its predecessor. Now I want to know the motion of the 98th frame wrt the 96th. Earlier, I would find the motion of the 98th wrt the first(global) frame, do the same for 96th, and then 'process' the info to get the required motion params. Some tests with the current framework made me realise how stupid that was. So now, it just goes this way - 98th->97th->96th, the way its supposed to be.

A small mock SymPy session with the use of this class is shown below-

The conditions are-

1) A frame R1

2) A frame R2 defined wrt R1, such that it initially coincides with R1, but has angular velocity of k̂ wrt it

3) A frame R3 defined wrt R2, such that it has a constant position vector of  î  wrt it.

Since R2 is rotating wrt R1, R3's position vector wrt R1 will be a function of time, as expected. Heres the working-

 >>> from sympy.physics.mechanics import MovingRefFrame  
 >>> R1 = MovingRefFrame('R1', parentframe=None)  
 >>> R2 = MovingRefFrame('R2', parentframe = R1, ang_vel = R1.basis(2))  
 >>> R3 = MovingRefFrame('R3', parentframe = R2, pos_vector = R2.basis(0))
 >>> R1.express(R3.pos_vector_in(R1))  
 - cos(t)*R1.basis(0) - sin(t)*R1.basis(1)  

Thats all for now. You can have a look at the PR if you wish. The coming week will majorly be spent fine-tuning my current code and making it perfectly compatible with Prasoon's API, adding a few other helper functions if needed, and writing unit tests/example docs for all that's implemented so far.
Have a great week :-)