adda icon indicating copy to clipboard operation
adda copied to clipboard

Change of lambda parameter does not make change to Qext

Open marenanna opened this issue 2 years ago • 6 comments

Hi,

We just started to use ADDA and tried to run it simply with lambda from 2.5 to 25 um parameters. We found that it always outputs almost the same Qext values, while we would expect to see different ones. We have tried both versions: v1.4.0 and v1.3b4 the outputs are the same. We also tried to have different grid parameter like grid=32 and in this case Qext is drastically different.

So we tried to run the following commands:

./adda -lambda 2.5 
Qext = 3.791149621
./adda -lambda 4.5
Qext = 3.791149602
./adda -lambda 25
Qext = 3.791149593

./adda -lambda 2.5 -grid 32
Qext = 2.324349022
./adda -lambda 4.5 -grid 32
Qext = 2.324349477

Here is a plot of Qext for the range of lambdas from 2.5 to 25.5

image

Are we doing something wrong?

marenanna avatar Sep 23 '22 12:09 marenanna

You should also specify the size of your particle, with -size .... Otherwise, the size of the particle is guessed by ADDA, and this guess scales with the wavelength. The latter results in constant Qext.

myurkin avatar Sep 24 '22 15:09 myurkin

Thank you for your reply!

We we have now perfomed the calculations successfully. However, when comparing with analytical results, the extinction efficiency has relatively large error for short wavelengths. The calculations were performed with default number of dipoles and increasing the number of dipoles did not result in better accuracy. We are wondering if this the best we can achive with ADDA?

Please see the attached figure.

MicrosoftTeams-image (1)

marenanna avatar Oct 11 '22 08:10 marenanna

I believe that ADDA should converge to the Lorenz-Mie results with refining discretization for any particle size or wavelength. Please specify the specific command lines that you use (for the largest x).

myurkin avatar Oct 11 '22 09:10 myurkin

This is the code we ran: rm qext.txt; for i in $(seq 2.5 0.1 25.5); do echo $i $(./adda -lambda $i -size 10 -dir output | tail -n 3 | head -n 1) >> qext.txt; done

We have also tried to increase the number of dipoles. For lambda=2.5, Exact Mie gives 2.5947 ADDA: Grid 16: 1.695 Grid 30: 2.462 (automatic) Grid 34: 2.447 Grid 40: 2.441

marenanna avatar Oct 21 '22 12:10 marenanna

Indeed, this case is not that easy for ADDA (-lambda 2.5 -size 10), due to significant size parameter 12.57 (your size factor seems to be 1/100 of that) combined with moderate refractive index (1.5). However, the default grid is 60 (not 30), so the value falls into an overall converging trend. I've tried increasing the grid to 120 (adding -grid 120 to the command line), it leads to Qext = 2.542. So the convergence is present, albeit relatively slow.

I have also tried the FCD formulation (adding -int fcd -pol fcd to the command line), it does improve the results. Qext = 2.551 and 2.584 for grid = 60 and 120, respectively. I am not sure, whether FCD will always help, but it has helped previously in a few similar cases.

myurkin avatar Oct 22 '22 16:10 myurkin

Hi,

Thank you for your reply. When looking in the manual, we were not able to find the definition of the size parameter. Could you please indicate where this can be found? We have followed the definition of the size parameter from Mie theory (= 2pir/lambda), so apologies for the confusing x-axis in our previous figure. However, from the ADDA manual (figure 1), it looks like it should still be fine for ADDA with size parameter 12 and refractive index 1.5.

Will this say that we can not expect more accurate results for this combination of size parameter and refractive index, without increasing the dopoles considerably? We tried also with 75, and it's still not very accurate

marenanna avatar Oct 26 '22 09:10 marenanna

The (volume-equivalent) size parameter x is defined in section 6.2 "The computational grid". But it is defined exactly as you mentioned, which for r=5 um (D = 10 um) and lambda = 2.5 um leads to x = 12.57.

Concerning Fig.1 the issue is with different interpretation of "fine". The white region on Fig.1 is fine in the sense that the iterative solver converges without too much trouble (several hundred of iterations is still much better that several hundred thousands). And the satisfactory accuracy can be achieved by refining discretization (which has almost no effect on the required number of iterations). But this comes at the expense of the simulation time. Still, it is still the case where good accuracy can be obtained on a laptop (even if taking up to hours) rather than on a large supercomputer (as will probably be needed for x=40 with m=1.5, note however, that relatively small absorption can greatly improve the performance).

Concerning, the possibility of accurate results for this case, I think I answered it in my previous comment. In particular, FCD with grid=120 results in only 0.4% error of Qext.

myurkin avatar Oct 26 '22 22:10 myurkin