Parallel domain decomposition for particle methods: Part 4
12 minute read
Introduction
The Plimpton scheme of communicating ghost information between patches was described
in Part 3 of this series.
Let us now see how a similar approach can be used to migrate particles that have
moved across patches.
In the animation below we just move the particles within each patch randomly. To make
the identity of the particles clear, we have used solid circles for the patch particles and
three-quarter circle for the particles in the ghost regions. As you can see, some of the
particles have moved outside the patches and need either to be deleted (if they have
left the computational domain - assuming that the domain size remains unchanged) or they
need to be moved to adjacent patches.
Plimpton’s scheme for migrating particles
If we run Plimpton’s scheme in reverse order, we can move the particles to the appropriate
patches with only four communication steps in 2D and six in 3D. Notice in the animation
below that we start with a search region in the x-direction that contains the top and bottom
patches along with the right (or left) patch. We relocate particles in this region first and
then need to move particles only in the top and bottom patches. Note also that the ghost particles
have been moved back to their original locations, indicating that we can ignore these during the
migration process. Depending on the requirements of the problem, we may either delete particles
that have left the domain, introduce them back in a periodic manner, or extend the domain itself.
MPI implementation
The implementation of the migration process is similar to that for ghost exchange. A typical
migrateParticles function can have the following form:
In Part 2 we defined
a PatchNeighborComm struct and a Patch struct. We can keep the PatchNeighborComm
struct in the same form, with the possible addition of a method of two. However, the Patch
struct becomes considerably simplified as show below.
Patch struct
The Patch struct described in Part 3
now has a few more methods. Let us see how some of these new functions may be implemented.
The first new function is sendRecvMigrateXMinus which is the equivalent of sendRecvGhostXMinus
for th emigration process. Note that the only difference between these two function is the
definition of the search box.
The next new method is combineSentParticlesX which is defined as:
The combineSentParticles method in PatchNeighborComm is defined as
One also needs to delete the sent particles from the patch, using the method
deleteSentParticles; this is where the use of a hashmap becomes handy.
Finally, we add the received particles to the list of particles in the patch using
addReceivedParticles:
In some special cases, we will also need to remove particles outside the domain. One
approach is to use removeParticlesOutsidePatch, but this step is typically not recommended
in general as it is costly and often not necessary.
Remarks
In the next part of this series we will explore how information about forces can be communicated
across patches.
We have been translating a few Code-Aster verification test manuals into English.
The process is not just a straightforward translation of the text in the Fr...
The Code-Aster cooling tower modal analysis validation test
FORMA11c comes with a quadrilateral mesh provided by Code-Aster.
Tips on quadrilateral meshing wi...
In this article, I will discuss how elements can be selected from deep inside a 3D mesh
in the Salome-Meca environment and manipulated with Python scripts.
Introduction
One of the reasons I switched to cmake for my builds was the need to compile my
Vaango code on a BlueGene/Q system. The code was previously co...