-
Notifications
You must be signed in to change notification settings - Fork 226
Correct collision algorithm in RZ. #2510
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Correct collision algorithm in RZ. #2510
Conversation
|
input.txt BTW, a small bug is fixed in |
|
This pull request introduces 2 alerts when merging bb5a147 into 13f6e98 - view on LGTM.com new alerts:
|
|
This pull request introduces 2 alerts when merging 9453118 into 9341e09 - view on LGTM.com new alerts:
|
ax3l
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work! Tiny suggestions inline.
Source/Particles/Collision/BinaryCollision/ElasticCollisionPerez.H
Outdated
Show resolved
Hide resolved
Source/Particles/Collision/BinaryCollision/ElasticCollisionPerez.H
Outdated
Show resolved
Hide resolved
Source/Particles/Collision/BinaryCollision/ElasticCollisionPerez.H
Outdated
Show resolved
Hide resolved
Co-authored-by: Axel Huebl <[email protected]>
|
As suggested by @NeilZaim, the generalization for higher-order modes could be implemented by binning particles in |
| u1x[I1[i1]] = u1xbuf*std::cos(theta) - u1y[I1[i1]]*std::sin(theta); | ||
| u1y[I1[i1]] = u1xbuf*std::sin(theta) + u1y[I1[i1]]*std::cos(theta); | ||
| #endif | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why write to the backing arrays rather than just using local variables for these two values? This seems like pointless memory traffic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, so I see these are passed by reference, and updated inside UpdateMomentumPerezElastic. There's still an opportunity to do that write into a stack variable that won't be flushed to memory, and then only write it out once it's potentially been corrected by the following de-rotation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@PhilMiller Hi, thanks for you comments, could you provide more details how to improve the code, I'm not sure if I understand your point. Stack variables also work on GPUs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yin-YinjianZhao#2
Here's a PR against your branch with my suggestion
RemiLehe
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this PR. I added a request for the assert statement to be moved to another part of the code.
Source/Particles/Collision/BinaryCollision/ElasticCollisionPerez.H
Outdated
Show resolved
Hide resolved
Source/Particles/Collision/BinaryCollision/ElasticCollisionPerez.H
Outdated
Show resolved
Hide resolved
* Add rotation. * Fix a small bug * Add automated test. * rename inputs_rz * Add json * minor * add comment. * Apply suggestions from code review Co-authored-by: Axel Huebl <[email protected]> * Update analysis_collision_rz.py * Fix missing import * Change tolerance. * Add warnings * Apply suggestions from code review * Move assert. * fix end-of-Line whitespaces. Co-authored-by: Axel Huebl <[email protected]> Co-authored-by: Remi Lehe <[email protected]>
In this PR, we will try to do a particle momentum rotation before calling the collision function, such that different azimuth positions of particles are also taken into account.