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.

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

Spherical harmonics as incident beam #329

Open
myurkin opened this issue Jan 30, 2024 · 1 comment
Open

Spherical harmonics as incident beam #329

myurkin opened this issue Jan 30, 2024 · 1 comment
Assignees
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

Comments

@myurkin
Copy link
Member

myurkin commented Jan 30, 2024

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.

@myurkin myurkin added feature Allows new functionality comp-Logic Related to internal code logic pri-Medium Worth assigning to a milestone maintainability Simplifies further code development (standardization, robustness) labels Jan 30, 2024
@myurkin myurkin added this to the 1.6 milestone Jan 30, 2024
@myurkin myurkin self-assigned this Jan 30, 2024
@myurkin
Copy link
Member Author

myurkin commented Jan 30, 2024

Another factor is the specific normalization (definition) of VSWF. For instance, we may use the one that is employed at https://github.com/tfp-photonics/tmatrix_data_format

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
None yet
Development

No branches or pull requests

1 participant