TorchGDM: A GPU-Accelerated Python Toolkit for Multi-Scale Electromagnetic Scattering with Automatic Differentiation

1. Addresses a timely need in the community for a modern, open-source, and GPU-accelerated electromagnetic solver that supports automatic differentiation for inverse design and optimization problems.

2. The code is open-source, installable, and its utility is well-supported by a variety of practical examples that highlight its features.

The authors describe a new numerical toolkit for auto-differentiable nano-photonical simulations, coined “torchGDM”. The presented subject matter, technical depth, and open-source (GLP licenced) ethos align well with the explicit mission of SciPost Physics Codebases. torchGDM addresses a clear and timely need within the computational physics community for precise and GPU-accelerated electromagnetic solvers to enable inverse design and optimization in computational photonics. The hybrid modeling approach offers a powerful solution for multi-scale problems where near-field accuracy is required for specific components within a larger, complex environment.

I have particularly enjoyed reading section 4 highlighting a handful of practical examples. The application examples effectively showcase the unique features of the toolkit. The diffractive metalens optimization using AD (Figure 12) is a potent demonstration of this power by showcasing how the toolkit can be used to design complex photonic devices by directly optimizing a physical objective function with respect to geometric parameters. The simulation of complex, multi-scale systems using the hybrid discretization method (Figures 13, 14) is also compelling.

Lastly, I was able to install torchGDM on my own system and successfully reproduce some of the presented results. Consequently, I believe that the manuscript is a strong candidate for publication in SciPost Physics Codebases after minor revisions outlined below.

Detailed comments:

1. The major current issue of the manuscript lies in contradictory wording about differentiability. The manuscript makes strong claims that the toolkit is "entirely implemented in PyTorch" and thus "any simulation entirely differentiable". These claims are directly contradicted by the authors' own admission that core functionalities for generating effective models from Mie theory or T-Matrices rely on an external, non-differentiable library (“treams”). This dependency breaks the automatic differentiation chain for specific workflows. A similar case is presented for field gradients, which are computed via finite differences instead of AD. I believe that the manuscript could be improved by summarizing these limitations and explaining which potential workflows will be affected. Right now, these limitations are mentioned in fairly remote places of the manuscript instead of in a unified paragraph.

Furthermore, some readers might be interested in a rigorous justification for using numerical finite differences for field gradients, including a quantitative benchmark comparing its performance (speed and memory) and accuracy against a properly formulated AD-based gradient calculation using PyTorch's backward() or forward-mode AD.

1. In equation (10), in the digital PDF version of the manuscript, the “3” in d^3 in the denominator is a hyperlink to the literature citations. Is this a LaTeX hyperref package artifact?

2. The manuscript states: "A phased-array scanning method can be used to decompose the dipole field in periodic contributions, but also then, the local light source needs to be sufficiently far from the array". However, the cited Capolino et al. paper (reference 17) actually concludes the opposite. It introduces the "array scanning method" (ASM) and demonstrates that it is more efficient than the direct plane-wave expansion method (PWM) precisely when the dipole source is close to the periodic structure.

3. The description of the GPM inverse problem (Section II.B) could be augmented with a discussion of its numerical conditioning to emphasize the importance of diverse illuminations for particularly ill-posed cases.

4. In section 4.B Benchmarks, the authors mention an upper limit of 10000–15000 dipoles on an RTX 4090. Is there the potential to double this number when halfing the precision at a negligible cost in simulation accuracy?

5. The title of reference 8 in the bibliography is not properly rendered (\$T\$).

6. Is the first equation in (13) missing a (n_env)^2 factor in the denominator?

Ask for minor revision

The authors present a general framework for multiscale electromagnetic simulations. It is based on the python toolkit pyGDM using the Green's dyadics method, which is combined with pyTorch, a GPU-based automatic differentiation framework. This allows for a number of interesting applications in the field of nanophotonics, and I believe that the toolkit will be of interest to many researchers. For this reason, I think that both the software and the manuscript are timely and of interest to the nanophotonics community, and I recommend publication in SciPost. Below I add a few comments and suggestions that the authors might like to consider.

As a first comment, it is interesting to see that recent years have seen the appearance of several open-source computational Maxwell solvers. For a long time the field has been dominated by electrical engineering and most of the software has been either commercial or only used in the respective research groups. There now seems to be a different attitude in the field of nanophotonics, which is aiming for open source and community driven solutions that are available to a broad community. I think that this is a very positive development.

The torchGDM toolkit is part of this development and combines several approaches that have been found successful in nanophotonics, including T-matrices, effective models (coupled dipoles), and more first-principles based approaches, such as GDM. This is nicely captured in Fig. 3. In my opinion this unifying approach should be stressed more strongly and explicitly, as it seems to suggest that in the future several complementary Maxwell solvers could be combined under a single umbrella. Could torchGDM be used as a generic Maxwell solver framework, which provides interfaces also for other software solutions? A discussion regarding this point would be helpful.

In this respect, I also suggest expanding the discussion in Sec. 1A regarding other software solutions. I assume that in addition to T-matrices also BEM and DDA could be coupled to torchGDM (as they account for scatterers embedded in free space, contrary to FEM or FDTD). An issue that should be also discussed more rigorously in Sec. 1A is numerical accuracy and stability. For Galerkin based schemes convergence can be demonstrated mathematically (by the way, the authors might also like to refer to the site https://ngsolve.org/), for most other techniques (including GDM) the situation is more complicated and adverse. I suggest expanding the discussion and to be a little more explicit about the strengths and weaknesses of the different approaches.

Personally, I would have liked to see before the formalism presented in Sec. 2 some appraisal of what can be done with the present software. What are the typical problems? When is it useful to have automatic differentiation at hand? Where do the authors see room for future developments? I think that such an outlook (and maybe even showing results in the form of some gallery) would help the readers to have a clearer picture of what can be done with the software before entering all the code technicalities. Personally I found the code description in Sec. 3 somewhat hard to read, maybe the authors might like to reconsider whether a mere listing of code elements (which can be also found in the documentation) really makes sense.

Other points.

• Does torchGDM allow for the consideration of substrates and stratified media (which would be highly beneficial for many applications)?

• Why cgs units?

• The last sentence on page 3 (Note that it has been demonstrated ...) is unclear, the discussion should be expanded.

• Why not embedding treams into pyTorch? Could this be done in the future?

• Can shape optimizations be performed with automatic differentiation? I have the impression that this is somewhat difficult with the GDM method.

Ask for minor revision