This has been a slow week, with a lot of ups and downs, work-wise.
Firstly, my laptop's LAN card decided to stop working properly, keeping me busy talking to the Dell customer service and convincing them that something is wrong with the thing. After a lot of troubleshooting and failed tests on their part (they even tried remote desktop connection to see what was going wrong), they finally agreed that something needs to be done. I hope it gets fixed before I go back to campus.
As far as the GSoC work is concerned, firstly, I got the Particle code finalised on Tuesday after a review by Gilbert.
Next, I spent the whole of Wednesday hacking the old mechanics framework to act as the base to test my own code on. I felt the need to do this, as I was anxious to see whether my own work was functioning as I thought it would, and it would take some time before Prasoon could get his framework in a completely consistent state (thats natural, considering the complexity of the work involved). It took a lot of time, as I had to tweak the old framework to support coordinate variables, use substitution on them during re-expression and time-differentiation, and so on...
Finally, I got it to work and tested my own code. It worked perfectly! There were a few errors that had to be rectified for the tuple-args format to function, but the rest of it went smoothly.
This is a real SymPy session using the hacked module and my own work-
Line 3 means that frame F1 should have an initial position of O.x + O.y + O.z wrt O. Substituting t = 0 in the output at line 5 will confirm this. To put in the boundary conditions at some other value of time, user just has to enter the keyword arg 't'.
Line 21 adequately shows how complicated things can get after a while.
Line 19 is an example how a tuple argument can be used in the new framework to position/orient new frames wrt their parents. Line 19 essentially means that F5 will have a translational velocity of 1 * F5.z after being oriented as per the user's conditions.
(All these things are adequately explained in the docs)
This work with the old module convinced me that dynamicsymbols should also be a part of my own work, since it makes handling of time variables considerably simpler. Hence, I added the function in my last commit to the PR.
Last but not the least, I planned out some basic vector/scalar field functions for my E-M module. But more on that later.
Now that I have my entire workspace up and running on my old laptop (temporarily), I will continue with the following work in the coming time-
1) Enable users to enter initial orientation in the same way they enter the time-dependent orientation. As of now, they get to do so only by entering the initial rotation in terms of a vector. Awkward, I agree.
2) Write tests for the MovingRefFrame and Particle classes as well as all the helper functions. Now that I have a system to test these things on, it will be much easier to do so.
3) Start working on the last part of the new framework - dyadics.
Thats all for now.
Have a great week ahead :-)
Firstly, my laptop's LAN card decided to stop working properly, keeping me busy talking to the Dell customer service and convincing them that something is wrong with the thing. After a lot of troubleshooting and failed tests on their part (they even tried remote desktop connection to see what was going wrong), they finally agreed that something needs to be done. I hope it gets fixed before I go back to campus.
As far as the GSoC work is concerned, firstly, I got the Particle code finalised on Tuesday after a review by Gilbert.
Next, I spent the whole of Wednesday hacking the old mechanics framework to act as the base to test my own code on. I felt the need to do this, as I was anxious to see whether my own work was functioning as I thought it would, and it would take some time before Prasoon could get his framework in a completely consistent state (thats natural, considering the complexity of the work involved). It took a lot of time, as I had to tweak the old framework to support coordinate variables, use substitution on them during re-expression and time-differentiation, and so on...
Finally, I got it to work and tested my own code. It worked perfectly! There were a few errors that had to be rectified for the tuple-args format to function, but the rest of it went smoothly.
This is a real SymPy session using the hacked module and my own work-
1: >>> O = MovingRefFrame('O')
2: >>> F1 = MovingRefFrame('F1', trans_vel = 3 * O.x + 4 * O.y,
3: pos_vector_b = O.x + O.y + O.z, parentframe = O)
4: >>> F1.pos_vector_in(O)
5: (3*t + 1)*O.x + (4*t + 1)*O.y + O.z
6: >>> Q = Symbol('Q', positive = True)
7: >>> F2 = MovingRefFrame('F2', ang_vel = Q * O.z, parentframe = O)
8: >>> F3 = MovingRefFrame('F3', pos_vector = F2.x, parentframe = F2)
9: >>> F3.pos_vector_in(O)
10: F2.x
11: >>> O.express(F3.trans_acc_in(O))
12: - Q**2*cos(Q*t)*O.x - Q**2*sin(Q*t)*O.y
13: >>> P = Symbol('P')
14: >>> F4 = MovingRefFrame('F4', orient_type = 'Axis', orient_amount = [P * t, F1.x], \
15: parentframe = F1)
16: >>> F4.ang_vel_in(F3)
17: P*F1.x - Q*O.z
18: >>> F5 = MovingRefFrame('F5', orient_type = 'Axis', orient_amount = [Q, F1.x], \
19: trans_vel = ((0, 0, 1), 0), parentframe = F4)
20: >>> F3.express(F5.pos_vector_in(O))
21: (-t*sin(Q*t)*sin(P*t + Q) + 4*t*sin(Q*t) + 3*t*cos(Q*t) + sqrt(2)*sin(Q*t + pi/4))*F3.x + (-3*t*sin(Q*t) - t*sin(P*t + Q)*cos(Q*t) + 4*t*cos(Q*t) + sqrt(2)*cos(Q*t + pi/4))*F3.y + (t*cos(P*t + Q) + 1)*F3.z
22: >>> F5.pos_vector_in(F4)
23: - t*sin(Q)*F4.y + t*cos(Q)*F4.z
24: >>> F5.trans_vel_in(O)
25: (-P*t*cos(Q) - sin(Q))*F4.y + (-P*t*sin(Q) + cos(Q))*F4.z + 3*O.x + 4*O.y
Line 3 means that frame F1 should have an initial position of O.x + O.y + O.z wrt O. Substituting t = 0 in the output at line 5 will confirm this. To put in the boundary conditions at some other value of time, user just has to enter the keyword arg 't'.
Line 21 adequately shows how complicated things can get after a while.
Line 19 is an example how a tuple argument can be used in the new framework to position/orient new frames wrt their parents. Line 19 essentially means that F5 will have a translational velocity of 1 * F5.z after being oriented as per the user's conditions.
(All these things are adequately explained in the docs)
This work with the old module convinced me that dynamicsymbols should also be a part of my own work, since it makes handling of time variables considerably simpler. Hence, I added the function in my last commit to the PR.
Last but not the least, I planned out some basic vector/scalar field functions for my E-M module. But more on that later.
Now that I have my entire workspace up and running on my old laptop (temporarily), I will continue with the following work in the coming time-
1) Enable users to enter initial orientation in the same way they enter the time-dependent orientation. As of now, they get to do so only by entering the initial rotation in terms of a vector. Awkward, I agree.
2) Write tests for the MovingRefFrame and Particle classes as well as all the helper functions. Now that I have a system to test these things on, it will be much easier to do so.
3) Start working on the last part of the new framework - dyadics.
Thats all for now.
Have a great week ahead :-)
No comments:
Post a Comment