SetMaxTerms(-1) yields wrong results

[10110111]

I'm not sure what motivation for #23 was, but the following gives a test case that shows that current automatic determination of the number of required terms works incorrectly.

Consider the following calculation:

$ ./fieldnlay-mp -l 1 2 1.3 0 -p 1e-3 1e-3 1 1e-3 1e-3 1 -200 200 2000 | cut -d, -f3,4 > /tmp/field.csv

This gives us ℜ{Eₓ} vs z table. The result looks as follows:

This doesn't make much sense: we should see incident wave with a bit of interference due to the scattered wave, rather than the widely-changing envelope we actually got. Let's now explicitly set 100 terms in nearfield.cc:

diff --git a/src/nearfield.cc b/src/nearfield.cc
index e842115..a914248 100644
--- a/src/nearfield.cc
+++ b/src/nearfield.cc
@@ -235,7 +235,7 @@ int main(int argc, char *argv[]) {
       }
     }
 
-    nmie::nField(L, -1, x, m, -1, nmie::Modes::kAll, nmie::Modes::kAll, total_points, Xp, Yp, Zp, E, H);
+    nmie::nField(L, -1, x, m, 100, nmie::Modes::kAll, nmie::Modes::kAll, total_points, Xp, Yp, Zp, E, H);
 
     if (has_comment)
       printf("%6s\n", comment.c_str());

Now the results look much more sensible. The incident wave becomes visible much farther from the sphere, although it still goes wild at some distance:

Changing the maximum to 250 gives the good expected result:

[kostyfisik]

Are you using the latest master branch from Github? It should be printing a warning message if the convergence is poor. Note, Le Ru nmax estimate is correct for near field inside a bulk sphere an space about one radius away from it.

[10110111]

Yes, I'm using the latest master. As for the warning, I do get one, but I thought it was about the single failing point discussed in #42.

Is there any available way to estimate nmax for larger distance from the sphere?

[kostyfisik]

No, Le Ru seems to be the latest update on this. In general, near-field evaluation is a poorly investigated aspect of Mie theory. The next problem I would like to adress here, is to develop a more stable algorithm for near-field evaluation inside the sphere. As for the near-field outside the sphere it is way more stable than, e.g. in Matlab implementations, or some published results (wich are simply wrong). In the attached figre you can find Stratify result on the top left (note halo-type problem away from the sphere due to use of Wiscombe cutoff), our Scattnlay result on the right (with Le Ru cutoff), and published result in the background.

[10110111]

I think the problem here is that incident field is calculated from the spherical partial wave expansion, using the termination criterion that is designed for scattered field properties, but is inadequate for incident field. (Le Ru doesn't even discuss incident field.)

It may be more efficient (i.e. less demanding on number of terms) to calculate the incident field as an actual exp(ikz) function, instead of summing its expansion in spherical waves along with the scattered near field.

[kostyfisik]

@10110111 Good idea! Could you please plot separately the incident and scattered fields for some set of parameters, when it really helps? You can use https://github.com/ovidiopr/scattnlay/blob/master/src/nmie-nearfield.hpp#L402 as a blue-print for your code. Note, that we use the same summation cycle both for incident and scattered field incide and outside the particle https://github.com/ovidiopr/scattnlay/blob/master/src/nmie-nearfield.hpp#L330-L334 , we just set c and d expansion coefficients to be one https://github.com/ovidiopr/scattnlay/blob/master/src/nmie-nearfield.hpp#L107-L108

[10110111]

I've actually now implemented my idea using your pointers (see the patch here: 10110111@6c84064), and the results look the same as the last screenshot in #44 (comment) — i.e. ideally:

In case you still want to see the scattered field only, here it is (the parameters are the same as in the OP):

And here's the current master output for incident-only field (I just subtracted the scattered field from the full output):

[kostyfisik]

Great! Looks very promising. Still need some verification for a general case (there is still a possibility e.g. messing a sign in some direction); however, it looks like a way to go... I would like to finish with adding near- and far-field computations to the webapp and will work on this next...