Merged gravity M-M tasks

Merge the M-M tasks between two cells into one single M-M task that will perform all the operations on the pair's progenitors.

Additional changes are:

• Delay the drifting of the multipole to the task instead of the unskip.
• Use the CoM at rebuild time in cell_can_use_pair_mm_rebuild() as the name indicates.
• Add extra timers to engine_maketasks()
• Use the list of local cells (instead of all cells) in space_regrid() to infer the maximal smoothing length.
• Fix the plotting scripts for matplotlib 2.x.
• Change the task flag to a long long instead of int.

This is the branch I have been using in all my latest tests.

The last change I have listed is the one I worried about since it affects the field of the task structure that we use to store the MPI tags.

Ran this with the undefine sanitizer switched on and it said:

scheduler.c:927:38: runtime error: left shift of 1 by 63 places cannot be represented in type 'long long int'
runner_doiact_grav.h:1338:28: runtime error: left shift of 1 by 63 places cannot be represented in type 'long long int'

I guess that means this should be an unsigned value, so the question is do we use as signed?

We do have:

 if (t->flags < 0)

twice in scheduler.c, so maybe, but I cannot see where it is deliberately assigned to a negative value.

I can replace what I did by code that does not rely on the full 64 bits if you think there is a danger here.

I can replace what I did by code that does not rely on the full 64 bits if you think there is a danger here.

changed title from Merged mm tasks to Merged gravity M-M tasks

changed the description

No danger, just not happy to live with a warning. Still haven't found where the assignment to less than zero happens, I wonder if it is true at all.

It may have been to protect the code against a segfault when accessing the sid_scale[] array?

In any case, it seems to me that we always assign positive values to the flag:

• 0-12 for the hydro pairs/sub-pairs
• MPI tags for the communications

We also do not perform any arithmetic on the flags directly. There could be some long long to int and back conversions but I think these are safe.

That's what I concluded. Would take those '< 0' sections out and see what happens, but snowed under with COSMA5 for the moment.

No rush. I am swamped with improvements to the physics anyway.

added 1 commit

• 3f49741e - Moved the check of negative flags for hydro pairs to the debug code. That never…

Compare with previous version

added 1 commit

• f45ad952 - Moved the check of negative flags for hydro pairs to the debug code. That never…

Compare with previous version

I have tried running it without the check for negative flags and everything runs smoothly.

Also, the big box I showed the pie chart for was run with this branch.

Thanks, this all looks good to go, along with a code tidy-up! I'll accept.

merged

mentioned in commit 19caade8