Integer timeline

This modified the way we do multiple time-steps. The time-steps are now placed on an integer timeline and can take values from 0 to 2^29 where 0 corresponds to the starting point of the simulation and 2^29 is the end point of the simulation. This effectively limits the number of time-steps that can be performed and sets an absolute minimal time-step size. If need be we can later on extend the number of time-steps allowed by switching to a long long but I have not seen this being necessary in any EAGLE or other simulations we ran. However, it prevents the assignment of 0-sized time-steps that occur in the current version of the code when using a final time which is not of the form 2^n (n positive or negative integer). This hence fixes issue #87 (closed). Quite a lot of changes scattered across the code but the only non-trivial ones are in runner_dokick() and engine_init().

While working on it I have corrected the count of number of particles updated in a given time-step. This is now correct. Fixes issue #89 (closed).

Finally, I have also added a message at start-up displaying which version of SPH we run.

Added 1 commit:

• 3bae89ae - Code formatting

Added 1 commit:

• 34a46475 - Reverted earlier removal of a tick counter necessary in MPI mode.

Added 1 commit:

• 4511d85d - Less verbose engine_init() in MPI mode

Title changed from Integer timeline to [WIP] Integer timeline

Made it "WIP" as it occasionally segfaults in MPI mode.

Added 1 commit:

• dee26e62 - Fixed segfault in MPI mode.

Title changed from [WIP] Integer timeline to Integer timeline

Ok, that's fixed. Note that it does not solve the bug leading to negative time-steps.

Added 1 commit:

• a2804267 - ti_current is an int and not a float in runner_dokick()

So I see, caught these in MPI mode:

[000] space_regrid: h_max is 4.545e-03 (cell_max=0.000e+00).
[000] engine_exchange_strays: sent out 4 particles, got 438 back.
[001] engine_exchange_strays: sent out 438 particles, got 4 back.
[001] engine_print: task counts are [ none=0 sort=432 self=226 pair=5410 sub=0 init=113 ghost=113 drift=6981 kick=113 send=752 recv=654 grav_pp=0 grav_mm=0 grav_up=0 grav_down=0 psort=2 split_cell=0 rewait=0 skipped=220078 ]
[001] engine_print: nr_parts = 783472.
[000] engine_print: task counts are [ none=0 sort=779 self=226 pair=7350 sub=0 init=113 ghost=113 drift=7419 kick=113 send=654 recv=752 grav_pp=0 grav_mm=0 grav_up=0 grav_down=0 psort=2 split_cell=0 rewait=0 skipped=231856 ]
[000] engine_print: nr_parts = 240656.
78 9.521484e-03 -6.103516e-04 412 1964.599
79 9.765625e-03 2.441406e-04 1 325.006
80 1.000977e-02 2.441406e-04 1 492.428

and

[000] engine_redistribute: node 0 now has 245917 parts in 7449 cells.
[001] engine_redistribute: node 1 now has 778211 parts in 6951 cells.
[000] space_regrid: h_max is 4.545e-03 (cell_max=0.000e+00).
[000] engine_exchange_strays: sent out 0 particles, got 0 back.
[001] engine_exchange_strays: sent out 0 particles, got 0 back.
[001] engine_print: task counts are [ none=0 sort=432 self=248 pair=5620 sub=0 init=124 ghost=124 drift=6951 kick=124 send=634 recv=634 grav_pp=0 grav_mm=0 grav_up=0 grav_down=0 psort=2 split_cell=0 rewait=0 skipped=218747 ]
[001] engine_print: nr_parts = 778211.
[000] engine_print: task counts are [ none=0 sort=748 self=218 pair=7214 sub=0 init=109 ghost=109 drift=7449 kick=109 send=634 recv=634 grav_pp=0 grav_mm=0 grav_up=0 grav_down=0 psort=2 split_cell=0 rewait=0 skipped=232848 ]
[000] engine_print: nr_parts = 245917.
103 5.493164e-03 -7.324219e-03 517 2414.209

so both times after a space_regrid(). This latter time fails as it now requires that the top-level cells are grown.

Yes, so this merge request is unrelated to this issue. I need to figure out where in the proxys particles get lost.

mentioned in commit 62ceefee

Status changed to merged

Seems to pass obvious tests, so accepting. OK to remove branch?

Thanks. Let's keep if for now. I am not yet 100% confident about the 'git rebase' I made this afternoon.