WIP: First version where particles that collide can be removed

This is the first version.

In the class p2p_merge_collisions, when two particles are close, we save the larger index in a vector.

This vector of indexes can then be accessed using reset_merge_list.

Then, it can be passed to delete_particles_from_indexes of particles_system.

The particles that have the corresponding indexes will be deleted. However, to avoid global communication, it is considered that the given indexes to delete belong to the given process or a direct neighbor.

So if we ask process p1 to delete particle of index i, then i must belong to p0, p1, or p2 (which is expected to be always true I guess).

@clalescu While doing it, I realized that particles cannot be "moved" in the particle interaction kernel. This makes sens I guess, because the iterative process is to first update the RHS, then move all the particles, etc.

Moreover, moving a particle during the particle interaction stage would be impossible (then, what about the interaction that were already computed with a given particle, etc.).

But then, please, think carefully about it and let me know if something is missing somewhere to having it work.

added 1 commit

• 922db8ba - Update the interface and set use

Compare with previous version

I couldn't think of a way to remove the particles during the interaction either. I can imagine a test for this, please let me know if it makes sense to you:

1. I write a class that performs the actions of both p2p_ghost_collisions and p2p_merge_collisions.
2. I set up a DNS where the particles don't move.
3. I count the collisions in one pass, and in the second pass there should be no collisions.

Would this be enough?

Separately: It's not clear to me whether there is any mechanism in the code already that will keep track of the original labels. I assume not. I know that you keep track of the global particle index (otherwise transmissions of particles would not work), but is it possible to access this data in any way? In the sense of being able to read and write the labels at checkpoints.

Right now all labels are implicit, and given by the array index of the initial condition. But for a changing number of particles we need explicit labelling of particles.

PS: I realize that my proposed text will fail when there are 3-particle collisions (or even more). @toba assures me we will look at sparse distributions of particles where such events are extremely unlikely.

Yes I think this is a good test. And I think that it will work even with 3 particle collisions. Lets say a, b and c collide. The p2p kernel will be call with (a,b) (a,c) (b,c). The particle with the largest index will be removed, so this will be (b,c). A will have been updated by (a,b) (a,c). But it is true that the order might not be valid and thus if (b,c) is called first, then when (a,b) will be called it will already contains c contribution.

When I remove particle, I do not change the indexes. If we have particle, a,b,c,d, and that I remove c, then I keep a,b,d with their own indexes. (that might throw an error in the output, because maybe I am asserting that all particles are here and unique).

Note; I currently do not keep track of which particle was merged with which other particles (I simply provide a way to remove them). I you want such information, you could keep this information in the class p2p_merge_collisions and then save it as you like, I think (to be confirmed).

@bbramas : we're currently getting an MPI error when trying to run the p2p_ghost_collisions test against the latest commit here. Here is the output:

[tolima:26641] *** An error occurred in MPI_Irecv
[tolima:26641] *** reported by process [3886940161,1]
[tolima:26641] *** on communicator MPI_COMM_WORLD
[tolima:26641] *** MPI_ERR_BUFFER: invalid buffer pointer
[tolima:26641] *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
[tolima:26641] ***    and potentially your MPI job)

I tried to dig it out myself, but I can't find the piece of code that generates this problem.

This error is seen when running "test_GC.py" from the latest version of https://gitlab.mpcdf.mpg.de/clalescu/turtle_collision_counter

added 1 commit

• 630e7e8a - Debug (forgot to allocate the right array for indexes)

Compare with previous version

Solved the (first) bug.

@bbramas : Thanks, I ran the test "test_GC.py" again: MPI error is indeed solved. @clalescu will have a look at the HDF5 error, which appears now.

added 1 commit

• 395528bd - adds hdf5 single value write method

Compare with previous version

remaining HDF5 issue was just HDF5 issue, the code (https://gitlab.mpcdf.mpg.de/clalescu/turtle_collision_counter/commit/b98f836381c6ba62e97d76bf0b142e15d61b34e5) runs without error for 1 thread per process. @bbramas : the code fails for multiple threads per process. Please don't do anything about it for now. I will try to figure out a simpler test that still fails, and if I cannot fix it myself I will ask for your help. Thanks again.

@bbramas : First, please notice that I merged this into feature/collisions, because @toba continued to use that branch for collision stuff. Secondly, a question: within the compute_interaction methods do we receive any precomputed information on periodicity etc? Details: particles are in a periodic box, if they are close to the edge of the box they may collide with the periodic copy of one another. In the detailed calculation, it would help if we already have the shifted coordinates available, and I would guess that the "shift_coeff" method parameters contain exactly this information, but please confirm (and also please let us know whether the shift applies to particle 1 or particle 2).

Thank you.

@clalescu if I am correct the PBC are already managed, and thus two particles at the opposite corners will interact, and the given distance in method compute_interaction is the one that takes PBC into account, and as you wrote, the shift_coef will indicate the shift that has been applied to the second particle (see compute_distance_r2 in class p2p_distr_mpi).

However, I feel that the shift coef is added to the position of particle 2.

Sounds perfect, thank you. @josea will be playing with the cylinders over the next few days, and we'll let you know when we have a test we're happy with. @toba is in the meantime working on storing information on pairs of colliding particles, so that we can actually compute the collision rate.

I will close this pull request, and we'll open further issues/pull requests as required.

Thanks again.

closed