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
Optimize particle generation #12931
Optimize particle generation #12931
Conversation
80441ca
to
cf37c2d
Compare
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.
This looks good to me.
@@ -270,6 +287,20 @@ namespace Particles | |||
const Particle<dim, spacedim> &particle, | |||
const typename Triangulation<dim, spacedim>::active_cell_iterator &cell); | |||
|
|||
/** | |||
* Insert a particle into the collection of particles given all the | |||
* properties necessary for a particle. This function is used internally to |
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.
Could you slightly expand on what the user should think of the word internally here, given that the function is now public? It would also be good if particle_index
is explained more clearly in terms of the expectations from outside.
/rebuild |
Thanks for the review. I updated the documentation. |
These are some backwards compatible changes that make particle generation around 30-40% faster (in a test model in ASPECT).
Changes:
reserve
function. This avoids reallocation and movement of the vectors that store the data. We dont have an easy way to do the same for the vectors storing the handles into the property pool, but they are smaller, and at least we can pre-allocate 4 vectors (position,reference position, id, properties) of the 5 vectors (+handle into pool).ParticleHandler::insert_particle
function that does not take a particle objectpublic
. This avoids creating/copying/destroying a particle object if none is needed. Adjust the generators to use this function where possible.Generators::random_location_in_cell
function. Previously the function would give up creating locations in the real cell after a number of unsuccessful tries and throw an exception. Now it falls back to creating locations in the unit cell, which always succeeds. If there are badly deformed cells it is more important to find any possible location at all rather than preserve perfectly randomly distributed particles within this cell.Possibly relevant for @kronbichler @peterrum @blaisb