Enh/liquid-motors-linear-algebra - #364
Conversation
phmbressan
left a comment
There was a problem hiding this comment.
Overall great enhancements, really straight to the point code to speed up simple linear algebra operations vs numpy. I still have some testing to do and left some comments, I will approve it after it.
MateusStano
left a comment
There was a problem hiding this comment.
Hey, so tried to debug the new EOM to find where the the difference was coming from.
What I did was I ran two debugs in the getting_started.ipynb (without wind) in two different VScodes simultaneously. I compared the results of "standard" uDot and the "NumpyFree" uDot vector in the first step of the uDot phase. The results of uDotRail1 were the same in both cases (as expected).
Here is what I found:
-
I_11_dot(fromuDotVariableMassNumpyFree) is different fromTiDot(from standarduDot). From what I understand, these two should be the same, or am I wrong? -
The resulting
uDotfrom "standard" is:- [0.0, 2.248419533601745, 25.699552867618234, 0.0, 8.656902256438004, 89.14219557097906, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
-
The resulting
uDotfrom "NumpyFree" is:- [0.0, 2.248419533601745, 25.699552867618234, 0.0, 8.59772619988504, 89.14312454809829, 0.0, 0.0, 0.0, 0.0, 0.48555730861286195, 0.0, 0.0]
-
The differences are in
ay,az, and specially inw1w1's differences come from:I_CM,T20andT21- It seems that the biggest factors for difference (on both
T20andT21) come fromweightBandr_CMinvolving factors.
- It seems that the biggest factors for difference (on both
Overall I'd recommend to check weightB, r_CM and all the T's. Seems the difference is deriving from there one way or another
|
Great debugging work @MateusStano. I'll attempt to use your observations to fix the trajectory difference and get back to you ASAP. I'll first review the motor mass PR and then get back to this. |
|
Pending TO-DOs:
|
|
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
For a moment, I agreed with your hypothesis. But it is not true because
I have verified that the implementation is in fact correct. The logic is: where Since, for the equations of motion, the origin is fixed back to the I believe this settle the debate about the weird mass multiplication and division in the code. With all EOMs doubts addressed, @MateusStano, feel free to review my last commits and merge. |
MateusStano
left a comment
There was a problem hiding this comment.
Hey! Seems we have a lot of issues with the tests. Some are broken due to the Inertia changes, but there are many problems with tests that have asserted value.
|
Seems like I had an issue before with the beta v1 merge (user error). Just merged it again, and the liquid motor branch as well. Everything working perfectly now, with all tests passing. No code changes, in the scope of this PR, were needed. @MateusStano, please skim through and merge when you feel ready. Let me know if you have any questions. For reviewing porpuses, I would recommend reviewing each commit individually. |
Pull request type
Please check the type of change your PR introduces:
Pull request checklist
Please check if your PR fulfills the following requirements, depending on the type of PR:
ReadMe, Docs and GitHub maintenance:
Code base maintenance (refactoring, formatting, renaming):
black rocketpy) has passed locally and any fixes were madepytest --runslow) have passed locallyCode base additions (for bug fixes / features):
black rocketpy) has passed locally and any fixes were madepytest --runslow) have passed locallyWhat is the current behavior?
Enter text here...
What is the new behavior?
Enter text here...
Does this introduce a breaking change?
Other information
Enter text here...