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

Reuse orientations #54

Open
GoogleCodeExporter opened this issue Aug 12, 2015 · 4 comments
Open

Reuse orientations #54

GoogleCodeExporter opened this issue Aug 12, 2015 · 4 comments
Assignees
Labels
comp-Logic Related to internal code logic performance Simulation speed, memory consumption pri-Medium Worth assigning to a milestone
Milestone

Comments

@GoogleCodeExporter
Copy link

Reuse calculated internal fields from one orientation for the similar ones
to speed up orientation averaging, as described by Okada. 

Original issue reported on code.google.com by yurkin on 24 Dec 2008 at 7:46

@GoogleCodeExporter GoogleCodeExporter added OpSys-All comp-Logic Related to internal code logic performance Simulation speed, memory consumption pri-Low Kept mostly for reference labels Aug 12, 2015
@GoogleCodeExporter
Copy link
Author

Similar ideas can be used for size averaging or calculating a spectrum of 
wavelengths (see issue 35).

#35

Original comment by yurkin on 6 Jan 2011 at 7:40

@myurkin myurkin added feature Allows new functionality and removed Type-Enhancement labels Aug 13, 2015
@myurkin myurkin self-assigned this Nov 12, 2015
@myurkin
Copy link
Member

myurkin commented Feb 9, 2016

In general, this can be optimized by block-iterative methods.

@myurkin
Copy link
Member

myurkin commented Jan 23, 2017

Another related idea is to use Compressive Sensing, which employs a more efficient basis for incident and scattered angles (instead of plane waves). A nice overview is given in L. Carin, D. Liu, W. Lin, and B. Guo, “Compressive sensing for multi-static scattering analysis,” J. Comput. Phys. 228, 3464–3477 (2009).

But it also seems analogous to the usage of the spherical-harmonics basis (#138) and T-matrix computation (#103). Right now it is not clear, which approach can be more efficient.

@myurkin myurkin added this to the 1.6 milestone Jul 10, 2018
@myurkin myurkin removed this from the 1.6 milestone Apr 24, 2021
@myurkin myurkin removed the feature Allows new functionality label Apr 24, 2021
@myurkin myurkin removed their assignment Apr 24, 2021
@myurkin
Copy link
Member

myurkin commented Oct 16, 2023

Konstantin Inzhevatrkin (@inzhevatkin) has implemented a preliminary solution to this issue on a development branch:
https://github.com/inzhevatkin/adda/tree/Bicg_block

It uses block conjugate gradient iterative solver (applicable to any variations of the incident fields, including particle orientations). Several tests show acceleration up to 2-3 times, but a convenient way to use the code (specify orientations) need to be devised.

@myurkin myurkin added pri-Medium Worth assigning to a milestone and removed pri-Low Kept mostly for reference labels Oct 16, 2023
@myurkin myurkin added this to the 1.6 milestone Oct 16, 2023
@myurkin myurkin self-assigned this Oct 16, 2023
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 performance Simulation speed, memory consumption pri-Medium Worth assigning to a milestone
Projects
None yet
Development

No branches or pull requests

2 participants