Update AutoPas to Combined Tuning

[FG-TUM]

Description

Makes the necessary changes to support the new AutoPas version.

New AutoPas Features

• Rule-based Tuning
• Combination of tuning strategies
• Support for multi-site particles (not supported with ls1 yet!)
• Cleaner separation of library and application code

Fixed Bugs

• Duplication of particles moving from one MPI rank to another.

TODO

• freeze AutoPas version when all AutoPas PRs are merged:
  • Less Halo Halo Interactions AutoPas/AutoPas#787
  • Fix Compilers in Makefile Projects AutoPas/AutoPas#813
  • Fix CellBlock3D::getCellBoundingBox() AutoPas/AutoPas#824
  • Fix leaving particle collector halo boxes AutoPas/AutoPas#826
  • Fix Region Iterators AutoPas/AutoPas#830
  • Template Reduction AutoPas/AutoPas#814 -> increase parallelism in CI
• Update all examples where tuning strategies are selected

How Has This Been Tested?

• Simulations

[SamNewcome]

All good.

Can you elaborate on what you meant by " freeze AutoPas version when Less Halo Halo Interactions AutoPas/AutoPas#787 is merged."

But otherwise all good for merge from my side.

[FG-TUM]

All good.

Can you elaborate on what you meant by " freeze AutoPas version when Less Halo Halo Interactions AutoPas/AutoPas#787 is merged."

But otherwise all good for merge from my side.

This refers to the default AutoPas tag in autopas.cmake. During development of the branch it was set to some AutoPas branch name, so the actual version was changing when the branch was updated. Since this means we can accidentally break ls1 by updating AutoPas, the default tag in the master of ls1 should always be one specific commit.

[SamNewcome]

All good.
Can you elaborate on what you meant by " freeze AutoPas version when Less Halo Halo Interactions AutoPas/AutoPas#787 is merged."
But otherwise all good for merge from my side.

This refers to the default AutoPas tag in autopas.cmake. During development of the branch it was set to some AutoPas branch name, so the actual version was changing when the branch was updated. Since this means we can accidentally break ls1 by updating AutoPas, the default tag in the master of ls1 should always be one specific commit.

Okay makes total sense

[FG-TUM]

How I analyzed the duplication bug:

1. See CI fail
   -> rerun failing scenario locally.
2. Observe regular stdout
   -> see insane spike in energy
   -> assumption: two particles came too close
3. Look at ParaView
   • Identify a problematic particle
     -> color particles by force magnitude
     -> set color scale to include transparency
     -> only particles with super high forces visible
   • Get information about this particle
     -> activate "Hover on points" to see e.g. particle ID
     -> color by rank to see between which ranks it moves
     -> add pathlines to better understand the trajectory
4. Understand what happens in the code
   -> add print statements (with #pragma omp critical) to check which rank has the particle ID in question at which point
   -> use this information to understand in which step the duplication happens
   -> draw a big diagram to understand the convoluted mess of ls1
   -> run the scenario with gdb with breakpoints in questionable places
   -> step through questionable code locations
5. As soon as I narrowed it down to have a rough idea what the problem is:
   -> change the code to do things simpler even if less efficient to see if this fixes things and thus understand the nature of the bug better
   -> use the debugger line by line until I exactly understand what goes wrong
6. Write a unit test that reproduces the bug in a minimal environment.
   -> helps to understand the edge cases better
   -> prevents the bug from reappearing in the future
7. Fix the code until the test passes.
8. Confirm it also fixes the original scenario.

[amartyads]

Testing with this branch, and with the autopas version set to master, my earlier bug with region iterators is not occurring anymore. Particles in the ghost layers seem to be correctly deleted and not skipped. (issue #281 )