-
Notifications
You must be signed in to change notification settings - Fork 77
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
MeshAdaptor performance #265
Comments
That's terrible. 14M nodes is not even that much... |
So is it following piece of code that is the culprit? |
I'm not sure. I did a quick profiling, but map operations didn't stand out there. The code you mention should run O(N*log(N)), so I doubt that this is the cause. As a test, you could use any sufficiently large 3D Gmsh msh file and load it in parallel. |
Adding some more debug comments, it became clear that most time is actually spent in fix_node_ranks, i.e.: |
Okay, I will soon have a look |
1 similar comment
Okay, I will soon have a look |
This routine looks indeed quite expensive and candidate for optimisation. Did it matter how many cores you threw at it? |
I didn't really check with the large case, but it seemed to take longer as the number of cores increased. I think that would be consistent with the way the communication happens in that part of the code. |
Partitioning a 3D tetrahedral mesh with 14M nodes on 64 cores, the step
is taking almost a day so far. We should look into improving the performance.
The text was updated successfully, but these errors were encountered: