Spherical harmonics as incident beam #329
Labels
comp-Logic
Related to internal code logic
feature
Allows new functionality
maintainability
Simplifies further code development (standardization, robustness)
pri-Medium
Worth assigning to a milestone
Milestone
Certain applications, like #103, can benefit from the incident beam given by vector spherical wave functions. From the UI perspective, this can be a command line like
-beam vswf <type> <l> <m>
, but it is not clear whether two orthogonal polarizations can be defined as for other existing beam types. Maybe, these two polarizations can replace the two VSWF types, but overall that makes #30 more relevant.From a computational point of view, direct computation independently for each dipole is a viable option. It will take some time (especially for high orders) but should not be significant for most applications (as is now with Bessel beams). However, there are two ideas for optimization. The first one, is the inverse of that in #138, for instance some types of non-uniform Fourier transforms or VSWF translations.
Second idea (which is not solution of the described issue per se) is external calculation of incident fields for a whole set of VSWFs (up to certain Lmax), as is commonly required in applications. Then recurrent relations between the used special functions can be used to accelerate computations, as is done in classical T-matrix codes (e.g., that of Mishchenko). The same relations can be used for translation matrices, mentioned above, but again only if all orders are considered at once.
Thus, the final solution may potentially be an independent implementation of two above ideas. Make a single VSWF calculation (for a grid of dipoles) inside ADDA as fast as possible, but also to motivate use of external scripts for high-performance applications.
The text was updated successfully, but these errors were encountered: