MPI libraries offer affinity control so as a first guess we shouldn't attempt any control, this is really bad when running more than one rank on the same machine (threads pinned to same cores).

Corrected the Wendland C2 kernel.

Still needs checking. @jwillis, can you check whether the number of neighbours is sensible with this version ?

The definition of kernels is still not completely optimal so minor changes may appear at a later stage in the project when nothing more urgent needs attention.

See merge request !77

NUMA-aware affinity

Resolves #76. Yes, ```hyperthreads_present``` is bonkers - it's easy to detect whether the processor supports the technology, but this is the best I've found to tell whether it's enabled.

See merge request !78

* Alternative: does .../thread_siblings contain more than a single 1?
  n.b. May or may not contain a comma if so.

* This is not vectorisation-specific.
* There may be better trade-offs between HT and NUMA.
* Maybe print a warning when we require multiple NUMA nodes.
* Must also detect when Hyper-Threading is not present.
* Probably better as a configure flag, rather than conditional only upon
  the availability of libnuma.
* ~15-40% performance improvement on COSMA.

Include parallel sort tasks in task dump and add support for MPI dumps

Dumps multiple task/thread/rank files for multiple time steps and
provides scripting support to process these into graphics for
each rank and timestep.

Matthieu, reasonably uncontroversial as only small changes to main.c
to check. If you want to test use the new `-y 1` flag to dump thread
info files and use `process_plot_tasks_MPI` to create the graphics
and a web page to view them.

See merge request !70

Overlapping tasks

This is a back-port of some changes I made to QuickSched: instead of taking the first lockable task with the largest weight, look for a task that maximally overlaps with the previously executed task.

This is done to maximize cache re-use, i.e. tasks with similar priorities operating on similar data will be scheduled closer to each other. I was already trying to do this by favouring tasks with the same super-cell as the previous task, but that was a bit of a mess. This should work much better.

Peter, can you check this both for correctness and if it doesn't cause a performance regression? I don't really expect a measurable performance gain directly, but this will have a strong effect on some caching that @alepper is currently working on.

Cheers!

See merge request !75

Solved the bug ! h_max was uninitialized in the kick leading to no particle interaction in the next pairs.

conflict in src/scheduler.c.

init tasks and tasks_ind to make sure they're not freed.

Fixes the bungled push to master I did just recently.

See merge request !74

Print information about the libraries used in the greeting message

I had nothing better to do whilst sitting at the back of the room during the DEX workshop...

See merge request !72

Truncate output from MPI version call so that it fits on one line, try to do this tidely for known libraries

Fix some typos