Key points are not available for this paper at this time.
The discrete dipole approximation (DDA) is a widely used and versatile numerical method for solving electromagnetic scattering by arbitrarily shaped objects. Despite its popularity, quantitative comparisons between independent implementations remain challenging due to differences in linear-system conventions, solver settings, and default numerical parameters. In this work, we introduce a unified software-assisted methodology for cross-verification and benchmarking of three major open-source DDA solvers: DDSCAT , ADDA , and IFDDA . We demonstrate how machine-precision agreement can be achieved across implementations by aligning all free parameters and provide practical equivalence tables enabling reproducible and interoperable simulations. Using this methodology, we perform systematic CPU and GPU performance comparisons covering OpenMP, MPI, and CUDA/OpenCL parallelization. Beyond benchmarking, our approach serves as a practical guide for configuring consistent DDA simulations and for understanding how precision, solver choice, and hardware architecture affect runtime, scalability, and accuracy in computational light-scattering studies. The software package also supports regression testing and bitwise reproducibility verification for future code releases. PROGRAM SUMMARY Program Title: dda-bench CPC Library link to program files: https://doi.org/10.17632/vzfy32vfn7.1 Developer's repository link: https://doi.org/10.5281/zenodo.18836855 Licensing provisions: GPLv3 Programming language: Python Nature of problem: Independent implementations of the discrete dipole approximation (DDA), such as DDSCAT , ADDA , and IFDDA , are widely used for electromagnetic scattering by arbitrarily shaped objects. However, quantitative cross-code comparisons and fair performance benchmarks remain difficult because the codes may differ not only in linear-system conventions, but also in default numerical parameters, solver settings, polarizability and interaction formulations, and output conventions or units. Small mismatches can modify iterative convergence histories and lead to discrepancies that mask genuine algorithmic or hardware effects. Users and developers therefore lack a practical and reproducible way to (i) verify that two codes are solving the same numerical problem, (ii) assess the number of matching digits that should be expected when specific parameters differ, and (iii) benchmark runtimes without confounding accuracy differences. Solution method: The presented software provides a lightweight, command-line–based framework to compare numerical DDA implementations through their executables. The user specifies, in a dedicated input file, the command-lines to be tested for each code or code version. The Python wrapper automatically executes the specified commands, collects the generated output files, and extracts the physical quantities selected by the user for comparison. The extracted data are converted automatically into consistent definitions and units when necessary. Agreement between simulations is quantified using a matching-digits metric, which directly reflects floating-point consistency. This approach enables straightforward comparison between different DDA codes or between multiple versions of the same solver, thus supporting regression testing, cross-verification, and fair benchmarking once equivalent configurations are enforced. Additional comments including restrictions and unusual features: The software is limited to DDA implementations that provide a command-line interface and assumes that the user has already installed and compiled the corresponding codes. The framework itself acts as a Python wrapper that operates on the generated executables. This design choice facilitates the practical use of the framework as a lightweight Python package that can be installed and imported easily, while allowing users to track and compare different releases of the same code and to freely choose which executable versions are used in a given comparison.
Argentin et al. (Thu,) studied this question.