Implement replicas and dipole field tracking to DipolarDirectSumGpu

[stekajack]

---

Dipole Field Tracking & Replica Support for DipolarDirectSumGpu

Summary

This pull request introduces GPU support for dipole field tracking in the DipolarDirectSumGpu class, and adds a parameter to control the number of replicas for the GPU-based dipolar direct sum method. The changes improve consistency between CPU and GPU implementations. Replicas offset the limitations inherent to the minimal image convention typically used with direct summation. This is a very "brute force" approach, but it works and is fast on modern GPUs.

Particularly useful if one wants to dynamically update the dipoles on particles in a way that modifies the magnitude (would trip up p3m for example)

Changes

• Added dipole field tracking on the GPU (DIPOLE_FIELD_TRACKING). The CUDA kernel now accumulates and transfers dipole fields for each particle when field tracking is enabled.
• Updated CUDA kernels, host/device memory management, and data scattering logic to handle dipole fields. All relevant host/device communication and memory allocation functions have been adapted to support the new field.
• Added property/host/device management for dipole fields in GpuParticleData.
• Extended DipolarDirectSumGpu to accept an n_replicas parameter, supporting image summation for periodic boundary conditions.
• Updated tests for both CPU and GPU dipole direct summation, including consistency checks for various n_replicas values.
• Improved error handling and parameter validation for n_replicas.
• Extended Python tests for dipole field tracking and direct summation (CPU & GPU).
• Verified consistency between CPU and GPU results for both forces and torques.
• Confirmed correct dipole field computation and transfer across MPI nodes.

Notes

-The GPU dipole field tracking implementation is inconsistent the CPU implementation.
-The GPU implementation piggybacks on the force calculation.
-The corresponding observable implementation is missing.
-I am of the oppinion that CPU path has to be refractured. The current implementation is not optimal and would force us to make difficult choices to bring the rest of the actors to feature parity.

---

[stekajack]

Commit 793faaf solves Issue #5095.

• The call path of the CPU and GPU direct sum calculations is now the same (calc triggered from the long range force calculation when the feature is compiled in).
• dip_fld is removed as an analysis routine because it doesn’t fit conceptually as an analysis routine.
• The Observable works for both the CPU and GPU implementation.
• This opens the door for a consistent p3m implementation.

[stekajack]

Notes for improvement:

1. The GPU makes a copy of all particles in the system. This can be a huge performance bottleneck (particularly with elaborate rigid particle arrangements).

• One could expand the functionality of ParticleRange, so that a filtered range can be made based on any property.
• A ParticleRange can be initialized from a filtered view.
• If this is done, the GPU copy only magnetic particles with minimal to no method code modification.

2. As a side-effect of point 1, if there are overlapping particles (for example, it is possible to have virtual particles inside real particles), the method fails. Implementing the proposed solution for point 1 will solve point 2 also.

[jngrad]

Thanks a lot!