enabling PBC and Regularization at the same time increases error

[mumairsadiq]

Regularization and PBC work well when only one of them is selected.

Results are incorrect when both of the options are selected,

[mumairsadiq]

Regularization and PBC work well when only one of them is selected.

Results are incorrect when both of the options are selected,

Hi @jooooow , I have found the error I think,

Currently, I have tested some examples where the fix works well. I will test it further and then create a pull request.

[jooooow]

@mumairsadiq
Yes you're right.
As written in the README.md,

WARNING : currently, enable PBC and Regularization at the same will increase the error

When regularization is used, the cells are extended to contain some extra regularized bodies.
These regularized bodies are used to compute the multipole and local expansion, as well as the non-regularized bodies.
The existance of regularized bodies ensures the correctness of regularization, but also introduce large error when i>0.
When i>0, cells are copied and put arround the original box recursively.
Consequencely, some extra regularized bodies will also be added to the outermost edge, which result in a large error.

Recently, I'm working on fixing this problem(on branch 3-ewald-fmm) and found it's not an easy job.
But ofcause, i will apprecriate it if you can fix it.

[mumairsadiq]

Actually, I tried a tactic,

So far it is producing correct result when we run with combined regularization and PBC setting

Let me test it futher and see if the solution works correct for all scenarios.

[jooooow]

I invited you to a previous repo.
You can take a look at issue-1 for some reference.

[mumairsadiq]

Sure, thank you.

[mumairsadiq]

Hi @jooooow ,

Sorry, I was busy on other things,

I got a chance to recheck this error; I was curious about this magic number, 2.95, in the following three places. Can you explain how it make sense.

1. exafmm-r/3drpp_appx/src/kernel.cpp

   Line 342 in 6a87f18

   std::vector<vec3r> x_check = get_surface_points(P, cell_src.r * 2.95, cell_src.x);

2. exafmm-r/3drpp_appx/src/kernel.cpp

   Line 1474 in 6a87f18

   std::vector<rtfmm::vec3r> x_equiv = get_surface_points(P, cell_tar.r * 2.95, cell_tar.x);

3. exafmm-r/3drpp_appx/src/kernel.cpp

   Line 1663 in 6a87f18

   std::vector<vec3r> x_check_up = get_surface_points(P, r0 * 2.95);

Also, at all three places, I tried adding regularization alpha (e.g., 0.01) to the radius because applying regularization increases the cell size,
and it reduced the error massively in all cases when I tested it.

for example, first line can be changed to
std::vector<vec3r> x_check = get_surface_points(P, (cell_src.r + 0.01) * 2.95, cell_src.x);
assuming regularization alpha is 0.01

I tested with the following command along with other commands

./test/test_reg -n 2100 -P 6 -m 16 -a fd -r 0.01 -i 2

So, I was thinking that maybe the problem is not direct interactions (p2p) itself; the problem may be in other phases of FMM when we use both regularization and PBC.

On note: I have not got much knowledge of this kernel-independent implementation; maybe I am wrong about what I am trying,

Please try the above and let me know what you think...

[jooooow]

@mumairsadiq
The magic numbers 1.05 and 2.95 are the sizes of equivalent charge surface and potential check surface from the kernel-independent FMM paper. These two values is a convention.

Also, if you increase the radius in get_surface_points, the two surfaces will be extended, which may improve the covergence slightly. But the essential puropose of regularization is to smooth the potential. So to verify the regularization, checking if the potential/force is continued around the cell's border is more important.

KIFMM paper : A kernel-independent adaptive fast multipole algorithm
in two and three dimensions

[mumairsadiq]

Hi,

I see, thank you for the clarification.