Cartesian Error with Multipole Order

[pizzooid]

In cartesian multipole expansion the error should be (\alpha/2)^P with the multipole order P.

Using exafmm with configuration ./configure --enable-assert --enable-float --enable-avx CXXFLAGS=-O2 CC=gcc CXX=g++ -DEXAFMM_EXPANSION=3..5 (examples/Makefile.am) make laplace_cartesian gives following results.

ORDER Rel. L2 Error (pot)

3 2.8357316e-03 4 2.8172146e-03 5 2.8788317e-03

Is this intended behaviour? Best Pietro

[rioyokota]

Changing Makefile.am doesn't change Makefile unless you reconfigure. You can change Makefile directly. I have confirmed that this work in the latest version.

[pizzooid]

actually I compiled with make laplace_cartesian -B which calls reconfigure

how did you confirm the error?

[rioyokota]

I directly changed the -DEXAFMM_EXPANSION in examples/Makefile to 3,4,5 and did make clean run_laplace_cartesian and saw the error go down at the expected rate.

[rioyokota]

Make sure to check the compiler message to see if it is actually using the EXAFMM_EXPANSION value you expect

[pizzooid]

ok, thank you now the error gets smaller i will look into the convergence next week

[pizzooid]

I now compared the results to fmmtl and the error shows a slower convergence for higher multipole order. (see image)

[rioyokota]

The Cartesian and Spherical kernels in fmmtl are originally from exaFMM. At some point I seem to have broken the ones in exaFMM. You could go back the revision tree to see where it broke. It could be a few years ago...

[jcharris]

Perhaps it is not a kernel issue, but the use of single precision (--enable-float, in the first post)? To the best of my knowledge the kernel itself is fine; I use an old version at the moment to avoid other issues I haven't resolved, but a "diff -b" with commit e7c8afd (a long time ago when a parallelization bug was fixed) shows that there hasn't been a change except for the namespace.

I also can confirm that the error seems to decrease (at least out to P=12) with editing the examples/Makefile (admittedly not the most elegant solution) and then "make run_laplace_cartesian" approach. However, I also get a plateau with single-precision, as one might expect.

[rioyokota]

Jeff is right. There are a few factors that would limit the maximum accuracy in exaFMM. The use of floats and AVX/SSE will have this effect. You can turn these features off by not using --enable-float and using --disable-simd. exaFMM is in desperate need for a unit test that checks the convergence of each expansion, not just for kernel.cxx but also serial.cxx and parallel.cxx in /examples. Once I write such unit tests and configure buildbot to run these for various configure options, these kinds of discussions should become necessary.