Closed antbonomo closed 4 years ago
Hi. Thank you for the report. There are two different issues here:
1.) You are defining the point p as int64 type (since 1000) is an Integer. If you specify p = np.vstack([0, 0, 1000.0]) OpenCL and Numba give the same results. This is an edge case we should check for. 2.) The FMM gives the wrong results because the expansion order is not sufficient. The Exafmm library that we interface is highly performant for low-frequency problems, but not suitable at high-frequencies. Because of the large distance of your evaluation there are many evaluations between the domain and the eval point, which the FMM does not capture properly. You can see this by setting bempp.api.GLOBAL_PARAMETERS.fmm.dense_evaluation = True. In this mode it uses a direct evaluation of all point to point interactions instead of just approximations for the far-field as the FMM usually does. We have built this in for debugging purposes to check FMM results (it is too slow for larger problems). But using this parameter the result becomes immediately correct.
Thank you for reporting this. I will create a separate bug report for the int64 issue and then close this bug report.
Have created bug report #58. Closing this one.
@tbetcke Thank you very much for your prompt response. Keep up the great work!
Using bempp-cl 0.2.0, I obtain different answers for the radiated sound pressure level depending on the assembler used (FMM, OpenCL, or Numba). Below is some code that illustrates the issue. Only the Numba-assembled potentials give pressure levels in good agreement with the analytical solution.