This shouldn't be necessary when we are drifting all, we have just repartitioned or the particles are just being initialised (before the first step)

Drifting them afterwards can result in some cells having inconsistent particle lists, so this must be done first

Pack the task types and re-arrange the task structure to go from 80 bytes to 64 bytes.



See merge request !238

Only relink parts and gparts when we actually have parts and gparts

Any reason not do this ? We spend some time linking things even when we don't have anything to link. That would speed up `space_rebuild()` and `cell_split()` in the cases without gravity, the latter of those to two being a scalar part of the code this could be quite important.

See merge request !234

Stop integer overflows in scheduler

Fix a couple of integer overflows and stop no gravity particles being considered
as valid.

See merge request !237

fix : missing include file in hydro_iact.h

Compiling on our clusters with the following configure line : 
```
$ ../sources/configure CC=mpicc CFLAGS=-I/ssoft/spack/lafnetscha/opt/spack/x86_E5v2_IntelIB/gcc-5.3.0/metis-5.1.0-zg7ap5yg7nqhkgsu7njnivar7lz3oy4z/include --prefix=/home/culpo/SWIFT/build/../install --enable-optimization --enable-parallel-hdf5 --enable-mpi --with-metis=/ssoft/spack/lafnetscha/opt/spack/x86_E5v2_IntelIB/gcc-5.3.0/metis-5.1.0-zg7ap5yg7nqhkgsu7njnivar7lz3oy4z
```
we get the following compilation error : 
```
libtool: compile:  mpicc -DHAVE_CONFIG_H -I. -I../../sources/src -I.. -DTIMER -I/ssoft/spack/lafnetscha/opt/spack/x86_E5v2_IntelIB/gcc-5.3.0/szip-2.1-luyic7zykee3mod772n6nixm3ki3ok2o/include -I/ssoft/spack/lafnetscha/opt/spack/x86_E5v2_IntelIB/gcc-5.3.0/zlib-1.2.8-2febcaqqgk6rskb6kw7vljlxjg5dra32/include -I/ssoft/spack/lafnetscha/opt/spack/x86_E5v2_IntelIB/gcc-5.3.0/hdf5-1.8.16-phuidcem3zjts6cynahfbqs3p3zerual/include -I/ssoft/spack/lafnetscha/opt/spack/x86_E5v2_IntelIB/gcc-5.3.0/metis-5.1.0-zg7ap5yg7nqhkgsu7njnivar7lz3oy4z/include -O3 -fomit-frame-pointer -malign-double -fstrict-aliasing -ffast-math -march=ivybridge -mavx -Wall -Wextra -Wno-unused-parameter -Werror -MT libswiftsim_la-runner.lo -MD -MP -MF .deps/libswiftsim_la-runner.Tpo -c ../../sources/src/runner.c  -fPIC -DPIC -o .libs/libswiftsim_la-runner.o
In file included from ../../sources/src/hydro.h:35:0,
                 from ../../sources/src/drift.h:29,
                 from ../../sources/src/runner.c:46:
../../sources/src/./hydro/Gadget2/hydro_iact.h: In function ‘runner_iact_vec_force’:
../../sources/src/./hydro/Gadget2/hydro_iact.h:644:26: error: implicit declaration of function ‘max’ [-Werror=implicit-function-declaration]
     pi[k]->force.v_sig = max(pi[k]->force.v_sig, v_sig.f[k]);
                          ^
```
This small PR seems to fix the issue.

See merge request !239

Get master building for now

Replaced all calls to fminf and fmaxf by macros

As the Intel compiler can't handle these properly, here is a replacement of all calls to `fmaxf` and `fminf` by a macro that just encapsulates the ternary. This produces assembly call to `vmaxpss` and `vminpss` as expected. 

Any reason not to do this ?

See merge request !235

Stop integer overflow in do_sub test and make sure no particles are considered as a no-op not a trigger.

Fix a trivial scaling bug in the task weights (could also overflow)

Documentation of the space and new names for the cells

Some small improvements (hopefully !) to the code documentation and variable descriptions. Implements #208.

See merge request !231

Replaced all calls to fminf and fmaxf by the macros that was added for the integer min/max functions.

cell->super for gravity-related business

I think we need to do this to make sure the gravity tasks are hooked at the right place. Given that the particles and g-particles can be distributed in a different fashion, we should not use the same `super` pointer as tasks might be defined at a different level in the tree. 

What do you think ?

See merge request !226

GCC 5x doesn't like this now we have -Wextra, if offends make count size_t as well

Only drift the particles that need drifting

Here is an algorithmic speed-up. The plan is to drift only the cells that contain an active particles and the cells that have at least one neighbour with an active particle. 

 - If this condition is not met then `runner_do_drift()` just returns without performing any operation. 

 - If the condition is met, `runner_do_drift()` moves all particles (as before) from the last point in time where a drift was performed. 

We record for each cell the last time a drift was done such that we now by how much to drift things when needed.

Two exceptions to this rule: before reconstructing and before duping a snapshot,  we drift all particles as we need correct position information at these two stages.

Note that I have made this an engine policy to ease the testing. Drifting all particles can be restored by setting the right flag.

@nnrw56  could you check that the function `cell_is_drift_needed()` makes sense and fully does what it says it does ? Also could you let me know whether you also agree with the whole logic and implementation.


See merge request !225

Avoid recursion in the tasks if no particle is active.

Does exactly what it says. We don't want to go through all the cells recursively just to find the handful that need this task to act upon. 

Big improvements when added to the `kill_drift` branch on the EAGLE_25 case. 

See merge request !230

Make the entry affinity pointer a static variable in a function rather a global

Here is what I hinted to in #204. I find this clearer to read. Do you agree with that change ?

See merge request !229