dalerxli / a-dda

Automatically exported from code.google.com/p/a-dda
0 stars 0 forks source link

Radiation forces #14

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Completely rewrite calculation of radiation forces using FFT. Add its
memory requirements to -prognose estimates, and perform other integration
into the code.

Original issue reported on code.google.com by yurkin on 26 Nov 2008 at 8:18

GoogleCodeExporter commented 9 years ago
Currently calculation of radiation forces is very unstable (crashes adda on 
Win32
from time to time). Further investigation is required to understand why (and 
from
which version) this happens. Then a fix is required (without rewriting the 
code).

Original comment by yurkin on 25 May 2010 at 2:54

GoogleCodeExporter commented 9 years ago

Original comment by yurkin on 7 Jun 2010 at 5:47

GoogleCodeExporter commented 9 years ago
Random crashes, described in comment 1, were fixed by r972.

Original comment by yurkin on 10 Sep 2010 at 9:43

GoogleCodeExporter commented 9 years ago
It is also desirable to make output of total optical torques (additionally to 
the total force). It was proposed in 
http://groups.google.com/group/adda-discuss/browse_thread/thread/620b7f91e053678
1# .

Original comment by yurkin on 12 Jan 2011 at 8:18

GoogleCodeExporter commented 9 years ago

Original comment by yurkin on 12 Jan 2011 at 8:18

GoogleCodeExporter commented 9 years ago
A workaround for computing Cpr (if only it is needed) without computing the 
radiation force at all is discussed in
http://groups.google.com/group/adda-discuss/browse_thread/thread/f2de36035198e3c
a/6f353589944a0518

Original comment by yurkin on 29 Jun 2011 at 5:11

GoogleCodeExporter commented 9 years ago
Can any one tell me the unit of the force on each dipole found at the file 
VisFrp?

Original comment by besirat...@gmail.com on 15 Sep 2011 at 4:18

GoogleCodeExporter commented 9 years ago
ADDA internally uses Gaussian-CGS system. So if incident field amplitude is 1 
in this system and all length variables are measured in cm, the unit of the 
force (for values in file VisFrp) will be dyne. However, if particle dimensions 
are specified in um (typical) then the units of force will be 10^-4 dyne. 

If you prefer SI units, then for incident field amplitude equal to 1 V/m and 
particle dimensions specified in um, the unit of force is approximately 
1.11*10^-18 N.

Finally, I encourage one to check the above statements for some test problem, 
since this feature of ADDA (in its current form) was implemented long ago and 
was not well documented. And I personally have almost no experience with it.

Original comment by yurkin on 17 Sep 2011 at 8:16

GoogleCodeExporter commented 9 years ago
thanks Yurkin,

I have one more question, how is the incident field amplitude defined in ADDA?

Original comment by besirat...@gmail.com on 19 Sep 2011 at 7:30

GoogleCodeExporter commented 9 years ago
For a plane wave, the incident field amplitude is given by |e^0| in Eq.(12) in 
Section 9 ("DDA formulation). It is assumed to be equal to one. For Gaussian 
beam the amplitude is its value in the beam focus - see Section 8.2 ("Beam 
types) of the manual.

Original comment by yurkin on 19 Sep 2011 at 11:23

GoogleCodeExporter commented 9 years ago
Hallo,

I did not get how you got those numbers because, the force is proportional to 
the product of square of electric field and Cpr, thus if every thing is in cgs 
and the dimension is in µm the force will be 10^-8 dyne (because Cpr is 
expressd in µm^2)similarly the force will be 4 X 10^-15 N (where every thing 
is defined in cgs).

besira

Original comment by besirat...@gmail.com on 27 Sep 2011 at 3:47

GoogleCodeExporter commented 9 years ago
Besira, sorry for delay with answer. 

I agree that I made a mistake in comment 8. I thought that electric field is 
not affected by change of linear dimension, while it does (as cm^-0.5). This 
can be easily checked by running ADDA with "-size 1 -lambda 1" and "-size 
0.0001 -lambda 0.0001" and comparing the output. The latter is 10^8 times 
smaller. So indeed the unit of force for unity amplitude of electric field (in 
Gaussian-CGS system, 1 statV/cm) and µm dimensions is 10^-8 dyne.

Concerning the SI units, 1 V/m corresponds to 0.33*10^-4 statV/cm (see e.g. 
http://en.wikipedia.org/wiki/Gaussian_units ) and force is proportional to 
electric field squared. So the latter coefficient should be squared, multiplied 
by 10^-8 and 10^-5 (from dyne to N). Finally, for incident field amplitude 
equal to 1 V/m and particle dimensions specified in µm, the unit of force is 
approximately 1.11*10^-22 N.

Please let me know if you agree with the last paragraph.

Original comment by yurkin on 9 Oct 2011 at 5:57

GoogleCodeExporter commented 9 years ago
Hallo,
nice to see your reply.
I still has to disagree with the second part. Because if we want to express the 
force in dyne then the electric field has to be expressed in statvolt/cm and 
distance in cm. Now F(dyn)= 1/8pi X E(statvol/cm)X Cpr(cm). Since you menitoned 
that ADDA by default works with cgs units(1 statvolt/cm of E should be rather 
assumed), we can express force in dyne and change it to SI unit at the end,
F(dyn)= (proportional to) 1 statvolt/cm X 10e-8 µm2 = 10e-8dyne= 10e-13 N,
if one include 1/8pi constant F(N)= 4 x 10e-15 N. Thus the force obtained in 
calculation has to be multiplied by 10e-13 N to express them in SI unit. 

Besira

Original comment by besirat...@gmail.com on 10 Oct 2011 at 7:49

Attachments:

GoogleCodeExporter commented 9 years ago
Dear Yukrin,
I have attached a document with the previous comment and I would be very happy 
if you have time to see it. 
besira

Original comment by besirat...@gmail.com on 10 Oct 2011 at 7:51

GoogleCodeExporter commented 9 years ago
After discussion with Besira, we concluded that expressions given in comment 12 
are correct.

Also I have summarized this discussion and earlier comments in the manual. Now 
the latter contains a meaningful section on radiation forces. It will be 
available with release 1.1.

Original comment by yurkin on 14 Oct 2011 at 8:35

GoogleCodeExporter commented 9 years ago
Bonjour,
I would like to raise question on radiation force on each dipole with focused 
laser beam. As expressed in the article of Hoekstra et al 
(J.Opt.Soc.Am.A/Vol.18/August 2001), a plane wave is considered and it is 
mentioned that it also works for other incident beams but the expression for 
<Finc, i> (section 4) need to be adapted. I was wondering how ADDA works when I 
choose a gaussian beam and calculate the force, does it use the adapted version 
of the <Finc,i>?

Original comment by besirat...@gmail.com on 28 Oct 2011 at 8:42

GoogleCodeExporter commented 9 years ago
Besira, you are right, ADDA works wrong with respect to <Finc,i> for Gaussian 
beams - see issue 135. Until this issue is addressed it is hard to get 
reasonable results from ADDA for this case. The only possible workaround is by 
some manual correction of the produced fields on each dipole.

There is also another relevant problem for Gaussian beams - see issue 134.

Original comment by yurkin on 2 Nov 2011 at 10:32

GoogleCodeExporter commented 9 years ago
Hallo,
it is bad news for me!!
Can I ask you to explain how to correct it manulally and whether it address the 
problem address in issues 134 or not?

Thanks in advance

Original comment by besirat...@gmail.com on 2 Nov 2011 at 12:29

GoogleCodeExporter commented 9 years ago
Unfortunately, issue 134 and issue 135 should be handled separately, since they 
required different properties of the (complex) Gaussian beams. I have added 
information about possible workarounds as comments to these issues. Completely 
fixing any of this issue requires significant effort, so I am not sure how long 
it will take.

Original comment by yurkin on 2 Nov 2011 at 4:40

GoogleCodeExporter commented 9 years ago
It seems that MPI version of radiation forces calculation was not working at 
all. With r1083, it is almost as good (or bad) as the sequential code. The only 
remaining difference is generation of VisFrp files, which is incomplete in 
parallel (MPI) mode.

Original comment by yurkin on 22 Nov 2011 at 6:39

GoogleCodeExporter commented 9 years ago
The problem mentioned in previous comment was fixed by r1142.

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

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago

Original comment by yurkin on 25 Sep 2013 at 10:28