Skip to content

Project Ideas

Jump to bottom
Markus Mühlhäußer edited this page May 7, 2024 · 48 revisions

Project Ideas

This page lists Project Ideas that may or may not be pursued. If you want to work on something, have a plan on how to expand a listed idea, or want to suggest a completely new idea contact the project owners.

How to read this document:

  • If something is marked as [POSSIBLE THESIS] the topic is more or less open for grabs.
  • If the topic is [RESERVED] it is currently reserved for someone.
  • Anything else needs further input.

Performance modeling

Algorithms

Container

  • Sorted Neighbor Algorithms:

    • ToDo: Check what is already implemented in AutoPas
    • Reference Containers: Sort particles by cells or similar. When sorting happens in-place memory allocation should be ok-ish-er
    • Pseudo Verlet Lists paper -> Cell-based, sort for cell interaction, for every particle store start/stop index
    • Look at different sorting algorithms
    • in-place sorting
    • Issues can be found here

  • [MORE INPUT NEEDED] Verlet Lists via Bitmask

    • Based on Linked Cells
    • Instead of neighbor lists have a bitmask which neighbors are "within the list (cutoff + skin)"
    • Advantage: contiguous memory access on all particles
    • Tradeoff: needs to iterate over all particles (like LC) but distance calculations need to be only done for things marked by the bitset (like VL)

  • [MORE INPUT NEEDED] Other Tree based container

    • There already exists a working Octree Container
    • Optimize existing Octree implementation
    • Ball Tree -> How to find "dimension of greatest spread" efficiently?
    • M-Tree

  • [MORE INPUT NEEDED] Reference Container style for all containers

    • Could lead to more efficient conversion between containers
    • Depends on further investigation of LCR

  • [MORE INPUT NEEDED] Performance analysis and optimization

    • for_each instead of iterators -> #434
    • Look for arbitrary inefficiencies and resolve them
    • Issues: #434 #321

  • [POSSIBLE THESIS] Investigation into Verlet-Cluster-Lists (VCL)

    • Performance analysis
    • Build clusters via (Oct)ree?
    • Issues: #396 #574 #437

Parallelization

Vectorization

  • [RESERVED] Vectorisation of 3-body potentials

  • [POSSIBLE THESIS] Functor as lambda

    • Might need some previous thought on how to actually do that.
    • replace iterators with AutoPas::for_each Done
    • SoA generation from AoS on the fly by shuffling. Relevant article
    • Permutations
    • Multi-centered Molecules

  • [RESERVED] Performance Portable functors

    • Current functors are hardcoded to some specific vector instruction
    • Rewrite using Google Highway
    • There is a big question of what amount of particles to interact from each SoA. For example
      • With AVX512, we have 8 doubles in vector registers
      • Do we interact one particle from SoA 1 with 8 other particles from SoA 2 (denote 1x8)? Or 2x4 or 4x2 or 8x1?
      • We might not get the optimal results from filling the entire register: Consider also 1x4
      • We might get optimal results by repeating the filling by applying permutations. E.g. 8x8 with the second register being rotated 8 times
    • There are so many options, how do we do the above systematically? Is there existing works on this problem? Is an optimal solution to the above transferable between SoA Single, Pair, and Verlet (and cluster lists)?
    • They may be some pipelining benefits to manually overlapping some loops (see LJFunctorSVE.h). Invesitgate if there is benefit to doing this and if this should also be tuned.
    • Implement or extend a microbenchmarking tool to tune the above and trial this out on several different architectures.

AutoTuning

  • [MORE INPUT NEEDED] Precision Comparisons-> Tuning?

  • [POSSIBLE THESIS] Hierarchical tuning

    • Simple version: First, test one configuration of every container, then fix that and go to the next parameter.
    • Create a tuning strategy that represents configurations as a hierarchical structure
    • Tuning via decision Trees
    • Fuzzy logic (?)
    • If applicable map the hierarchical format on existing strategies.
    • Issues: #557 #426

  • [MORE INPUT NEEDED] More sophisticated extrapolation algorithms

    • Currently predictive-tuning uses regression or some form of Newton or Lagrange polynomial.
    • Look at things like e.g. Richardson Extrapolation
    • Analyse behavior in different changing scenarios: linear (e.g. Spinodal Decomposition), chaotic (exploding liquid), oscillating (???)

  • [RESERVED] Develop microbenchmarking framework to tuning some components of AutoPas that shouldn't be tuned during the simulation (e.g. use of sorting in Linked Cells)

  • [POSSIBLE THESIS] Descion Trees / Random Forests as tuning strategy

    • Descion Trees which learn relationships from scenario based components to optimal algorithms.
    • As a start, the live info can be used as the input. But potentially other inputs would be better
    • The big difficulty is not learning a DT/RF but how to design the data for the input

Software Design

MD-Flexible / Molecular Dynamics Library

  • [Possible Thesis] New N-Body Simulation Types

    • Extend MD-Flexible to SPH -> other functors and particles
    • Extend MD-Flexible to DEM -> new functors and particles
    • Other time integration methods
    • Generate an executable for each simulation type from one code-base

  • [Reserved] Smoothed Lennard-Jones and Argon simulation

    • Add the smoothed lennard-jones functor
    • Profile and optimise the smoothed LJ functor
    • Create the cooling/super-cooling Argon simulation from the MD Lab course and add to md-flexible inputs
    • Trial AutoPas' tuning on this simulation
    • Probably best to split the normal and the smoothed parts into separate vectorised loops for SoA variants.

  • [Reserved] Implement the electrostatic (& Dipole/Quadrupole) forces

    • Implement these forces for simple single-site molecules
    • Optimise these force kernels
    • Extend the forces to multi-site molecules
Clone this wiki locally