Inverted grav depth logic

This might actually help with the MPI problems simply by reducing the number of gravity-related MPI communications.

It makes the depth of the gravity more uniform across the nodes and hopefully more balanced. Scheduler:cell_subdepth_grav could also be reduced further to help even more.

Do we know whether this helps? Or should I start a bunch of independent tests?

Sorry, meant to say what I'd done. I ran a full physics test for 20,000 steps three times, with depths of 4, 3 and 2. The results are not very different, other than 4 is a little faster than 2. However, I need to rerun these once more as the comparison to master doesn't look good, i.e. these are much slower. Think I'll merge in master and do the tests again.

Think it is the improvements in engine_collect_end_of_step once more. Reruns underways.

All looks more reasonable now. Here are plots for master against this branch (updated to the same revision anyway):

So not a lot in it, master is slightly faster than this branch.

Reducing the subdepth value to 2 doesn't look much different either:

So I guess this isn't the improvement we're after...

Thanks Peter. As usual not a gain... That's also not blatantly worse...

John has a bunch of gravity-only runs with variations on this theme that we may want to look at to see whether we can learn more here.

The run time of the Eagle L0100N1504 dmonly boxes seems to be almost completely unchanged if I use this branch, and there's very little difference between depths 3, 4 and 5.

closed