GitLab

Add -funroll-loops as a standard GCC optimization

SWIFT is faster with this.

Fixes #244.

See merge request !283

SWIFT is faster with this

Improve readability of active/inactive condition

This, as is, is rather minor but it's on the way towards improving the time-stepping. 

I have replaced all explicit checks that a particle or cell is active by calls to inlined functions. No change in functionality thus far.

The plan is to slowly introduce a better time-stepping mechanism where the particles carry less information (lower footprint) and make the whole time-step limiter problem easier. With this merge request in then I only need to make the changes in one single location (file active.h) and not everywhere. 

See merge request !279

Conflicts:
	src/runner.c

When not drifting because the cell has already drifted this step, keep the h_max and dx_max, don't reset to zero

Only one argument now

Makes sure that the hierarchical tasks get timed properly even when they recurse

Corrects #239 

See merge request !280

Check whether particles or cells are active via an inlined function rather than via a direct read of engine->ti_current

In stats_collect_part_mapper in statistics.c, we don't collect gpe if gpart does not exist



See merge request !278

Remove the fixdt policy. fixdt can be achieved by setting dt_min and dt_max to the same value.



See merge request !277

No task mask

Implementation of #235. There is no such thing as a task mask any more. All tasks in the scheduler get enqueued and executed provided they have not had their skip flag set.

For the special case of the 0th time-step (where we don't compute forces nor kick) there is an extra function in the engine that will set these tasks to be skipped.

See merge request !276

Conflicts:
  src/scheduler.c

New h max definition

Since `h_max` was always an annoyance, here is a better definition. 

There is a new parameter now called `max_top_level_cells` that allows you to set the (cube root of the) maximal number of top-level cells you want. So instead of referring to it as a maximal smoothing length you directly give the number of cells.
Of course if the physics requires larger cells, the parameter is ignored. This default to 12 if unspecified, giving 1728 top-level cells. 

The only reason you would want more top-level cells is for simulations on large systems to obtain a finer MPI decomposition.

I also force a rebuild after time-step 0 now to make sure we have good grid and set of tasks even if the original mesh was based on garbage smoothing lengths values entered by the user.

What do you think ?

See merge request !275