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

Calculate as many cross section as possible when it is fast #133

Open
GoogleCodeExporter opened this issue Aug 12, 2015 · 5 comments
Open
Assignees
Labels
comp-UI Related to user interface (command line, input files) feature Allows new functionality pri-High Of higher priority, but no guarantees surf In the presence of (semi-infinite) substrate usability Makes using code more convenient
Milestone

Comments

@GoogleCodeExporter
Copy link

Currently, ADDA calculates only Cext and Cabs by default (at almost no extra 
time), while Csca requires significant extra simulations (integration of the 
scattered field over the solid angle). At the same time, the manual explains 
that Csca can be obtained as Cext-Cabs with no extra simulations. The same 
applies to different ways to calculate Cpr.

The idea is to divide ADDA simulations into three phases: internal fields, 
scattered fields (over a large grid of angles), and radiation forces. Whenever, 
one of this is triggered by command line options, all possible quantities 
should be calculated. For example, if only internal fields are simulated 
(always), calculate Cext, Cabs, and Csca. If scattered fields are integrated 
over solid angle, calculate Csca,g,g*Csca,Cpr. If radiation force is 
calculated, calculate Cpr and possibly g.

Different ways to calculate Csca or Cpr may lead to different accuracies. 
First, comparing these values may be used as consistency check. For instance, 
Csca will lead to test of convergence of the iterative solver and accuracy of 
integration over the solid angle. Second, it would be nice to estimate the 
accuracy of each of the ways (due to internal reasons, and not due to the DDA 
discretization itself) and provide it to the users. The latter should help a 
user to decide whether, e.g., a fast simulation of Csca is sufficient or slower 
method is required.

Original issue reported on code.google.com by yurkin on 15 Oct 2011 at 10:12

@GoogleCodeExporter
Copy link
Author

It should also be possible to calculate Csca by some integration over the 
particle volume, similar to Cext and Cabs, since Csca.g can be obtained from 
integral of the "scattering" component of the radiation force.

Then after acceleration of radiation forces, need for integration over the 
scattering solid angle can be removed at all.

Original comment by yurkin on 22 May 2012 at 5:21

  • Added labels: Priority-High
  • Removed labels: Priority-Medium

@GoogleCodeExporter
Copy link
Author

A related aspect is to calculate radiative decay rate enhancement (for 
point-dipole incident field) through a direct calculation of scattered power 
(including the emitting dipole itself). Similarly, it can be compared to the 
way that is used currently (total - nonradiative), but generally has little 
added value for users.

Additional benefit of such approach may appear for particles above metallic 
surfaces - there total nonradiative part is hard to calculate directly 
(requires one to assess the power absorbed in the substrate). So calculating 
the total scattered power into the upper hemisphere may be a way to go.

Original comment by yurkin on 29 Jul 2014 at 10:11

@GoogleCodeExporter GoogleCodeExporter added OpSys-All pri-High Of higher priority, but no guarantees comp-UI Related to user interface (command line, input files) usability Makes using code more convenient labels Aug 12, 2015
@myurkin myurkin added feature Allows new functionality and removed Type-Enhancement labels Aug 13, 2015
@myurkin myurkin self-assigned this Nov 12, 2015
@myurkin myurkin added the surf In the presence of (semi-infinite) substrate label May 18, 2018
@myurkin myurkin added this to the 1.5 milestone Jul 10, 2018
@myurkin
Copy link
Member

myurkin commented Dec 11, 2020

To be more specific, an interesting idea is to try to account for absorption in the substrate through some integral over the particle volume (using the reflected Green's tensor). Not clear, if that is fundamentally possible.

@myurkin
Copy link
Member

myurkin commented Dec 11, 2020

Moreover, the issue seems to be related to #22

@myurkin
Copy link
Member

myurkin commented Apr 23, 2021

/cc @alkichigin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
comp-UI Related to user interface (command line, input files) feature Allows new functionality pri-High Of higher priority, but no guarantees surf In the presence of (semi-infinite) substrate usability Makes using code more convenient
Projects
None yet
Development

No branches or pull requests

2 participants