Speedup particle sorting #1167
Speedup particle sorting #1167
Conversation
gassmoeller
force-pushed
the
speedup_particle_sorting
branch
from
55b4780
to
50b8db5
Compare
| */ | ||
| Particle (const Point<dim> &new_location, | ||
| const Point<dim> &new_reference_location, | ||
| const types::particle_index &new_id); |
There was a problem hiding this comment.
Isn't particle_index just some plain old integer? If it's a scalar, just passing it by const value is fine, no need for a reference.
|
I must admit that I haven't really tried to understand the details of the algorithm, but it looks good to me with minor edits. Regarding data structure: If I understood this right, you are using the list because you need to delete elements from it, right? You could alternatively keep two vectors, with the second already sized to the size of the first but initially empty (via Constructor: Just remove the old constructor. |
gassmoeller
force-pushed
the
speedup_particle_sorting
branch
2 times, most recently
from
a61c6eb
to
de24eb5
Compare
gassmoeller
force-pushed
the
speedup_particle_sorting
branch
from
de24eb5
to
f790fda
Compare
|
Turns out even in this situation the vector is a few percent faster. I changed everything, and when the tester is happy this should be ready to merge. |
| * | ||
| * @param [in,out] particles_to_sort Vector containing all pairs of | ||
| * particles and their old cells that will be sorted into the | ||
| * 'particles' member variable in this function. |
There was a problem hiding this comment.
The [in,out] can't quite be true any more because the argument is const.
|
Looks good. Please address the final few comments and merge yourself. |
gassmoeller
force-pushed
the
speedup_particle_sorting
branch
from
54bea5d
to
c882204
Compare
Particles now also store their location in the
coordinate system of their current cell. This decreases the
number of times this location has to be computed by inverting
the mapping for the current cell, which is expensive.
On average this change will save 40-50% of the overall
particle computing time, while increasing the particle
memory footprint (which is usually small compared to the
system matrix).
The new algorithm relies on the fact that the reference location is set before the particles are advected. All implemented particle generators do that, but it is possible to use the old constructor to construct a particle without setting this location (e.g. in a user-written generator). What should I do about the old constructor? Remove? Deprecate? Add a sentence to the documentation that if using this constructor the user has to set the reference_location manually?