Add another communication sub-type for the gparts. Send the gparts when these tasks get enqueued.

This follows suit with the addition of task sub-types for the communications. I have added one to ship the gparts between nodes.

This also allows to send/recv the gparts instead of the parts at enqueuing time. Note that the gpart communications are currently unused since I never pushed the support for gravity over MPI to the master.

It also allows to only loop over the relevant bits we received and not over the whole particle zoo to construct the time information on the receiving side.

This merges into the new_timeline_mpi branch and not in master as it is yet another MPI bug/feature fix.

Note that I made this in a separate branch for you to look at as you may have a different opinion on how this should be done.

Added 1 commit:

• 139fe38b - Only need to update h_max on the receiving side if the cell is active.

It looks good! I am a bit uneasy though submitting this without having any code that uses/tests it, but since it shouldn't break anything else, I'm OK with it :)

Reassigned to @pdraper

Added 1 commit:

• c1e5b26a - No need to check for received unactive cells for the rho communication sub-type.…

Part of it is untestable at the moment (with the master branch) but the fact that runner_do_recv_cell() loops over both part and gpart when only part is being sent is wrong and leads to inappropriate values of ti_end_min to be set on the receiving side.

I merge this into our MPI debugging branch since it is fixing the gpart bug.

Status changed to merged

mentioned in commit fbd6aac8