Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

WIP: P3M improvements notes #4847

Closed
RudolfWeeber opened this issue Jan 9, 2024 · 0 comments
Closed

WIP: P3M improvements notes #4847

RudolfWeeber opened this issue Jan 9, 2024 · 0 comments

Comments

@RudolfWeeber
Copy link
Contributor

In preparation for performance portable electrostatics.

ESPResSo interaciton

  • Theere is still some immedaite dependent on ESPResSo data structures in the P3M code, e.g.,

    • the System class
    • BoxGeometry and LocalGeometry
      This is in the initialization and for event triggers such as on_boxl_change()

  • Some function signatures still rely on Espresso types, e.g. ParticleRange for assign_charges.

Data structures general

  • some quantities are scale dby the box length, but of type double. This is ambigious for non-cubic boxes. E.g. alpha_L

Patterns wich micht be replaced by an algorithm

  • There are a lot of places, where something is done on all mesh siztes, so in essence this is a for_each with an enumerate, just that we have 3d indices rather than a linear one. This appears several times in the k-space kernels for electrostatics and dipolar p3m.

Abstraction of of meshes and fft

  • mesh accesses for real and k space might be abstracted away, particular since the storage order is changed by the fft.
  • Fht fft details need to be abstracted away.
  • Iteration boundaries depending on details of the fft such as p3m.fft.plan[3].new_mesh[2] need to be abstracted away
@jngrad jngrad mentioned this issue Jun 14, 2024
Merged
kodiakhq bot added a commit that referenced this issue Jun 25, 2024
@kodiakhq
Modernize core (#4931)
d9a7d2b 
Fixes #4846
Partial fix for #4847

Description of changes:
* migrate to C++20 in both C++ and CUDA code
   * CUDA 12+ is required
   * a recent C++ compiler is required, recommended: GCC 11+, Clang 18+, AppleClang 15+
* use STL containers
   * use `std::optional` instead of `boost::optional`
   * use `std::numbers` instead of `Utils::numbers`
   * use `std::span` instead of `Utils::Span`
   * use `std::ranges` and ranged-based algorithms instead of `boost::ranges` and `boost::algorithm`
   * cannot use `std::array` instead of `Utils::Array`, because its `constexpr` methods don't have the `__device__` qualifier ("calling a constexpr `__host__` function from a `__host__ __device__` function is not allowed")
* reduce dependency on Boost
   * remaining: `boost::mpi`, `boost::serialization`, `boost::unit_test`, `boost::algorithm` (for C++26 features)
* migrate to lbmpy/pystencils 1.3.3 and to the most recent version of the waLBerla development branch
* rewrite CMake by following best practices
   * the `object-in-fluid` module is now also installed when the `espressomd` module is installed
   * C++ and CUDA source files are now treated separately and no longer share the same compiler flags
   * CUDA shared objects are now properly linked against instrumentation tools (e.g. Caliper, UBSAN)
   * CUDA objects now generate code coverage information for host code
   * Boost unit tests can now be written in a CUDA source file
* rewrite P3M nested loops that operate on 3D grids
   * a utility function wraps the nested loops and takes a kernel as argument that operates on the grid
   * intermediate values are now systematically cached
   * the analytic cotangent sum kernel was inlined
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@RudolfWeeber