-
Notifications
You must be signed in to change notification settings - Fork 1
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
Quick fix to multithreading issue by refining specialization of contravariant vectors #62
Quick fix to multithreading issue by refining specialization of contravariant vectors #62
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #62 +/- ##
==========================================
- Coverage 89.46% 89.45% -0.01%
==========================================
Files 20 20
Lines 1803 1802 -1
==========================================
- Hits 1613 1612 -1
Misses 190 190 ☔ View full report in Codecov by Sentry. |
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 fix. Thanks a lot @tristanmontoya !
I am not super familiar with this either, but obviously your specialization works and it contains NDIMS
as well as NDIMS_AMBIENT
, so it cannot interfere with Trixi's function anymore. The only concern would be that the type is too specific now and does not cover all your cases. If this not an issue, we could go for it.
Thanks! It covers all the cases we use now, and doesn't have a significant impact on performance. We can look for another solution if needed later on. |
It would be great to add some CI tests running an example with multiple threads to ensure that the bug does not occur anymore |
This is an attempt to fix the problem @benegee noted in #61, in which the cases which use "standard" Trixi.jl solvers (i.e. not those for PDEs on surfaces) return an error when multiple threads are used, due to TrixiAtmo.jl's specialized
get_contravariant_vector
method forPtrArray
types being called inadvertently. I'm not super familiar with the workings ofPtrArray
, but looking at the StrideArraysCore.jl code, I was able to figure out what type parameters would be associated with a 2D mesh in 3D space, and therefore hard-coded the dispatch for those dimensions. With this change, the issues in #61 are no longer encountered.