p1_space_2d=bempp.function_space(grid_2d,‘P’,1, include_boundary_dofs=True)
p1_space_3d=bempp.function_space(grid_3d,‘P’,1, include_boundary_dofs=True)

I think they just forgot to put u_cone in the function u_total_callable, but you can set it as @Kevin did. Easiest thing is to multiply the results with the velocity of the cone. You won’t need to re-compute the BEM if you decide to change your speaker parameters.

I made a toolbox that automate the process (definition of domains and computation at evaluation points) combined to a lumped-element solver. It is mostly aimed at speaker design, but if it can be of any help: https://electroacpy.readthedocs.io

I came to the same question trying to adapt this example to my needs (open baffle directivity).

There is another post suggesting to apply the cone velocity on the BEM solver results : @tchoum using-bempp-to-calculate-far-field-sound-pressure-around-a-hollow-cube-with-imported-surface-velocities

Did you get some answers or did you come to a conclusion on it?

I am trying to make BEM calculations for a classic Laplace problem with an electrostatic lens that I meshed with NETGEN (NgSolve). In a previous project, I used BEMPP with a mesh generated only by gmsh. Thus, I was wondering if it was possible to use BEMPP with a mesh imported from NETGEN instead of using gmsh.

from mpi4py import MPI

import bempp_cl.api

from bempp_cl.api.external import fenicsx

from dolfinx import mesh

L = 6.0

mesh_size = 0.4

N = int(round(L/mesh_size))

comm = MPI.COMM_WORLD

# Create a DolfinX mesh

domain = mesh.create_box(comm=comm, points=[[0.0, 0.0, 0.0], [L, L, L]],n=[N, N, N], cell_type=mesh.CellType.tetrahedron)

tdim = domain.topology.dim

fdim = tdim - 1

domain.topology.create_connectivity(fdim, tdim)

domain.topology.create_connectivity(tdim, 0)

domain.topology.create_connectivity(fdim, 0)

# Print number of boundary facets and number of boundary nodes per rank

boundary_facets = mesh.exterior_facet_indices(domain.topology)

# print(f"Rank {domain.comm.rank}: Number of boundary facets = {len(boundary_facets)}", flush=True)

local_has_zero = int(len(boundary_facets) == 0)  # 1 if true, 0 otherwise

all_has_zero = comm.allgather(local_has_zero)       # everyone receives list of 0/1 flags for all ranks

if comm.rank == 0:

ranks_with_zero_facets = [rank for rank, flag in enumerate(all_has_zero) if flag == 1]

print(f"Ranks with 0 boundary facets = {ranks_with_zero_facets}", flush=True)

# Create the boundary mesh grid for BEMpp from the DolfinX mesh

bempp_grid, bempp_boundary_dofs = fenicsx.boundary_grid_from_fenics_mesh(domain)

# print('Rank {}: BEMpp Number of elements on boundary {}'. format(comm.rank, bempp_grid.number_of_elements), flush=True)

# print('Rank {}: BEMpp Number of vertices on boundary {}'. format(comm.rank, bempp_grid.number_of_vertices), flush=True)

bempp_space = bempp_cl.api.function_space(bempp_grid, "P", 1)

bempp_operator = bempp_cl.api.operators.boundary.laplace.double_layer(

bempp_space, bempp_space, bempp_space)

print(f"Rank {comm.rank}: Created BEMpp grid with {bempp_grid.number_of_vertices} vertices and {bempp_grid.number_of_elements} elements.", flush=True)

the code runs in parallel up to the point where 1 or multiple ranks do not have any node on the boundary. If this happens (for instance for this particular mesh, by requesting 50 ranks), it fails with:

File “XX/miniconda3/envs/fenicsx/lib/python3.12/site-packages/bempp_cl/api/grid/grid.py”, line 57, in init
self._enumerate_edges()
File “XX/miniconda3/envs/fenicsx/lib/python3.12/site-packages/bempp_cl/api/grid/grid.py”, line 508, in _enumerate_edges
self._edges, self._element_edges = _numba_enumerate_edges(self._elements, edge_tuple_to_index)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
IndexError: getitem out of range

Also:

• from what I understood from the documentation, bempp handles the distributed matrix vector multiplication on its backend.
• if so, it is unclear to me how to construct the vector phi0_boundary (is it a distributed vector where each rank has its own part or do I need to gather everything into a global one)?
• I’m not sure how to handle the same vector if there are ranks that do not have nodes on the boundary.

many thanks and thank you for your work!!

I am observing a strange behaviour when using the GridFunction method to project a function onto a 2D mesh.

In the example below, I project the same function onto a 2D square mesh and onto a 3D cube mesh. In theory, the square mesh should coincide with the bottom face of the cube. However, the projection on the 2D square mesh appears to be shifted or incorrect along the boundary, as shown in the attached image.

Does anyone know why this might be happening, and how to avoid or correct this issue?

Thank you in advance — I look forward to your advice.

EDIT: I think it’s to do with P1 function space as DP1 and DP0 were fine. Can we still use P1 for 2D mesh?

import bempp_cl.api as bempp
import numpy as np

x,y,h=1,1,0.1
freq=50
omega = 2*np.pi*freq
c=340
k = omega/c

d = np.array([1., 1., 1])
d /= np.linalg.norm(d)

@bempp.complex_callable
def u_inc(x, n, domain_index, result):
    result[0] = np.exp(1j * k * np.dot(x, d))

grid_2d=bempp.shapes.screen(np.array([[0,0,0],[0,y,0],[x,y,0],[x,0,0]]),h=h)
grid_3d=bempp.shapes.cube(1,[0,0,0],h=h)

p1_space_2d=bempp.function_space(grid_2d,'P',1)
p1_space_3d=bempp.function_space(grid_3d,'P',1)
pd_2d=bempp.GridFunction(p1_space_2d,fun=u_inc)
pd_3d=bempp.GridFunction(p1_space_3d,fun=u_inc)
pd_2d.plot()
pd_3d.plot()

My question is Can Bempp import grids with result data?
I would like to skip the process of solving the BIE and directly import previous surface calculation results for far-field acoustic radiation computation and post-processing.
I have attempted the code below, but it appears to only import grids without result data.

phi_cal = bempp.api.import_grid(“result.msh”)

When using version Bempp3.3.4 to solve the scattering field of a cube, I encountered ‘nan’ values in the computed scattered electric field on the surface. However, when running the following code multiple times:

points_values = -ME*sol

num_nan = np.sum(np.isnan(points_values))     print(num_nan)

the number of ‘nan’ values varies each time, and I am unsure why this occurs. I hope someone can provide a solution to this issue. In the latest version, bempp-cl 0.4.2, this ‘nan’ problem does not occur, but it lacks the feature for local mesh refinement (I mainly need the local mesh refinement functionality. Can bempp-cl0.4.2 achieve this, or can it be implemented through other packages?). Therefore, I would greatly appreciate it if anyone knows how to resolve this problem. The specific code is as follows.

import bempp.api
import numpy as np
from bempp.api.operators.boundary import maxwell
from bempp.api.operators.boundary.sparse import identity as ident

polarization = np.array([1.0, 0, 0.0])
direction = np.array([0.0, 0, 1.0])
def incident_field(point):return polarization * np.exp(1j * k * np.dot(point, direction))
@bempp.api.complex_callable#(jit=False)
def tangential_trace(point, n, domain_index, result):
value = polarization * np.exp(1j * k * np.dot(point, direction))
result[:] = np.cross(value, n)
grid = bempp.api.shapes.cube(length=1, origin=(0, 0, 0), h=0.1)
grid.plot()  

rwg_space = bempp.api.function_space(grid, “RWG”, 0)
snc_space = bempp.api.function_space(grid, “SNC”, 0)

Id = ident(rwg_space, rwg_space, snc_space)
tan_inc = bempp.api.GridFunction(rwg_space, fun = tangential_trace, dual_space = snc_space)

E = maxwell.electric_field(rwg_space, rwg_space, snc_space, k)
H = maxwell.magnetic_field(rwg_space, rwg_space, snc_space, k)

vertices = grid.leaf_view.vertices
elements = grid.leaf_view.elements

points = vertices[:, elements[ 1 , : ]]

points = ( vertices[:, elements[ 0 , : ]] + vertices[:, elements[ 1 , : ]] + 
vertices[:, elements[ 2 , : ]] ) / 3

ME = bempp.api.operators.potential.maxwell.electric_field(rwg_space, points, k)
points_values = -ME*sol
num_nan = np.sum(np.isnan(points_values))
print(num_nan)

The number of NaN is different each time.

I am a graduate student specializing in boundary integral equations. While reading the Bempp book, I found that the explanation regarding the treatment of singularities in boundary integral operators is only partial: “The Green’s function will have a singularity when x=y, so internally Bempp will use appropriate singular quadrature rules to handle this.” I would like to understand the specific treatment methods in Bempp for these cases or the literature on these methods, including the handling of singularities in the Green’s functions for Laplace, Helmholtz, and especially Maxwell. I would be very grateful if anyone could provide information.

Thank you in advance for your time, and I am looking forward to your advice.

I have read most of the relevant articles on BEMPP and noticed that Matthew’s doctoral thesis provides a detailed description of BEMPP. However, when I try to implement the direct EFIE, indirect EFIE, MFIE, and CFIE from the thesis using bempp, I consistently encounter issues with either non-convergent results or incorrect outcomes (Only the indirect EFIE format converges.).

I would be grateful if you could advise on whether there might be problems in my code or in the theoretical implementation process. Please find the original text and my implementation process below:

The code is as follows:

import bempp_cl.api
import numpy as np
from bempp_cl.api.operators.boundary import maxwell

frequency = 3e8
eps0 = 8.854187817e-12
mu0 = 4 * np.pi * 1e-7
zf0 = np.sqrt(mu0/eps0)
k = 2*np.pi*frequency*np.sqrt(eps0*mu0)

polarization = np.array([-1.0, 0, 0])
direction = np.array([0, 0, -1.0])

def incident_field(point):
    return polarization * np.exp(1j * k * np.dot(point, direction))

@bempp_cl.api.complex_callable#(jit=False)
def tangential_trace(point, n, domain_index, result):
    value = polarization * np.exp(1j * k * np.dot(point, direction))
    result[:] = np.cross(value, n)

@bempp_cl.api.complex_callable    
def neumann_trace(point, n, domain_index, result):
    value = np.cross(direction, polarization) * 1j * k * np.exp(1j * k * np.dot(point, direction))
    result[:] = 1.0 / (1j * k) * np.cross(value, n)
grid = bempp_cl.api.shapes.regular_sphere(4)
grid.plot()  

tan_inc = bempp_cl.api.GridFunction(rwg_space, fun = tangential_trace, dual_space = snc_space)
neu_inc = bempp_cl.api.GridFunction(rwg_space, fun = neumann_trace, dual_space = snc_space)

E = maxwell.electric_field(rwg_space, rwg_space, snc_space, k)
E_ik = maxwell.electric_field(rwg_space, rwg_space, snc_space, 1j*k)
H = maxwell.magnetic_field(rwg_space, rwg_space, snc_space, k)
Id = bempp_cl.api.operators.boundary.sparse.identity(rwg_space, rwg_space, snc_space)

rwg_space = bempp_cl.api.function_space(grid, "RWG", 0)
snc_space = bempp_cl.api.function_space(grid, "SNC", 0)

The following is the format of the algorithm in the paper

sol= bempp_cl.api.linalg.lu(E, (0.5 * Id + H) * tan_inc)   #direct EFIE 
#sol= bempp_cl.api.linalg.lu(E, tan_inc)   #indirect EFIE
# sol= bempp_cl.api.linalg.lu((H + 0.5 * Id), -E * tan_inc)   #direct MFIE
# sol= bempp_cl.api.linalg.lu((H - 0.5 * Id), tan_inc)   #indirect MFIE
# sol= bempp_cl.api.linalg.gmres(-E_ik * E + 0.5 * Id + H, -E_ik*(0.5 * Id + H) * tan_inc)   #direct CFIE

# Number of points in the x-direction
nx = 300

# Number of points in the y-direction
ny = 300

# Generate the evaluation points with numpy
# x, y, z = np.mgrid[-3 : 3 : nx * 1j, -3 : 3 : ny * 1j,  0 : 0 : 1j     ] #xoy
x, y, z = np.mgrid[-3 : 3 : nx * 1j,  0 : 0 : 1j     , -3 : 3 : ny * 1j] #xoz
# x, y, z = np.mgrid[ 0 : 0 : 1j     , -3 : 3 : nx * 1j, -3 : 3 : ny * 1j] #yoz面
points = np.vstack((x.ravel(), y.ravel(), z.ravel()))

# Compute interior and exterior indices
all_indices = np.ones(points.shape[1], dtype="uint32")

interior_indices = np.sum((points) ** 2, axis=0) < 1 ** 2
exterior_indices = ~interior_indices

ext_points = points[:, exterior_indices]
int_points = points[:, interior_indices]

ME = bempp_cl.api.operators.potential.maxwell.electric_field(rwg_space, ext_points, k)
MH = bempp_cl.api.operators.potential.maxwell.magnetic_field(rwg_space, ext_points, k)

exterior_values = MH * tan_inc - ME * sol                      #dirct EFIE & direct MFIE & direct CFIE
#exterior_values = -ME * sol                                  #indirct EFIE
# fexterior_values = -MH * sol                                 #indirct MFIE

Thank you for your time and assistance. I look forward to your reply and wish you all the best.

It is always a good idea to verify code with a different methodology or package. While it’s challenging to pinpoint your exact problem, there is one thing that caught my attention.

Bempp uses the convention of extracting an e^{-\imath \omega t} time component to obtain the Green’s function G(x,y) = \frac{e^{\imath k |\mathbf{x} - \mathbf{y}|}}{4\pi |\mathbf{x} - \mathbf{y}|} for the harmonic wave propagation. This means that a plane wave has the form e^{\imath k \mathbf{x} \cdot \mathbf{d}}. I notice that you use a negative sign in the exponent of the incident plane wave.

I suggest double-checking all signs in your formulation.

I hope that helps you debugging your code.

Best,
Elwin

import bempp_cl.api
import numpy as np
bempp_cl.api.enable_console_logging()

grid = bempp_cl.api.shapes.regular_sphere(3)

frequency = 3e8  # 300Mhz  #PEC
eps0 = 8.854187817e-12
mu0 = 4 * np.pi * 1e-7
zf0 = np.sqrt(mu0/eps0)
k = 2np.pifrequencynp.sqrt(eps0mu0)

#polarization = np.array([0, 0, -1.0]) 
#direction = np.array([-1.0, 0, 0])
polarization = np.array([-1.0, 0, 0])  
direction = np.array([0, 0, -1.0])
def plane_wave(point):
   return polarization * np.exp(-1j * k * np.dot(point, direction))

@bempp_cl.api.complex_callable
def tangential_trace(point, n, domain_index, result):
  value = polarization * np.exp(-1j * k * np.dot(point, direction))result[:]                 
  =np.cross(value, n)   

div_space = bempp_cl.api.function_space(grid, “RWG”, 0)
curl_space = bempp_cl.api.function_space(grid, “SNC”, 0)

from bempp_cl.api.operators.boundary import maxwellelec = bempp_cl.api.operators.boundary.maxwell.electric_field(div_space, div_space, curl_space, k)
trace_fun = bempp_cl.api.GridFunction(div_space, fun = tangential_trace, dual_space = curl_space)

from bempp_cl.api.linalg import lu
lambda_data = lu(elec, trace_fun)

try:
   get_ipython().run_line_magic(“matplotlib”, “inline”)
   ipython = True
except NameError:
   ipython = False
from matplotlib import pyplot as plt
from mpl_toolkits.axes_grid1 import make_axes_locatable
from matplotlib.patches import Circle

number_of_angles = 400
angles = np.pi * np.linspace(0, 1, number_of_angles)
#unit_points = np.array([np.zeros(number_of_angles), np.cos(angles), np.sin(angles)])     #yz
unit_points = np.array([np.cos(angles), np.zeros(number_of_angles), np.sin(angles)])     #xz
#unit_points = np.array([np.cos(angles), np.sin(angles), np.zeros(number_of_angles)])   #xy平面

far_field = np.zeros((3, number_of_angles), dtype=“complex128”)

electric_field=bempp_cl.api.operators.far_field.maxwell.electric_field(lambda_data.space, unit_points, k)
far_field = -electric_field * lambda_data

plt.rcParams[“figure.figsize”] = (10, 8)  
# Resize the figure
cross_section = 10 * np.log10(4 * np.pi * np.sum(np.abs(far_field) ** 2, axis=0))
plt.plot(angles * 180 / np.pi, cross_section)plt.title(“Scattering Cross Section [dB]”)_ = plt.xlabel(“Angle (Degrees)”)
plt.show()

This is the result, but it is not the correct RCS for the plane wave.
Although the results below are correct, they correspond to the case where the polarization direction and the propagation direction are reversed.

The function trace_space, trace_matrix = fenicsx.fenics_to_bempp_trace_data(fenics_space) returns the variable trace_space, which is a bempp-cl FunctionSpace. You can access its grid with the attribute trace_space.grid.

Indeed, when extracting a surface mesh from a fenics mesh, the gmsh physical tags are not used, which you can check by accessing trace_space.grid.domain_indices. They are all zero.

For simple structures like cubes, you can find subsets of the grid manually, e.g., finding a face of a cube as face_elements = np.isclose(trace_space.grid.centroids[:,0], 0) to find the face at x=0, up to rounding errors.

With this information, you can overwrite the domain_indices attribute, create a new mesh, or create a new function space as face_space = bempp_cl.api.function_space(trace_space.grid, support_elements=face_elements, kind="DP", degree=0).

I hope these ideas will help you move forward.

Best,
Elwin

It seems I have multiple environments installed and some of them had older scipy. When I went through and updated them all it started working. Thanks!

Alan

The Generalized Minimum Residual (GMRES) algorithm is an iterative method to solve the linear system. The rtol argument is the relative tolerance for the termination criterion of GMRES. Check your version of scipy because legacy versions have the tol argument instead.

Also, notice that bempp-cl also has its own interface to the GMRES algorithm, with different function arguments. Check the documentation for the syntax of bempp_cl.api.linalg.gmres().

Best,

Elwin

I’m trying to familiarize myself with bempp by running the example scripts. I’m getting the following error related to the gmres solver:

For example, when executing line 72 of the reentrant cube capacitance example, I get the following error.

x, info = scipy.sparse.linalg.gmres(A_op, b_vec, rtol=tol, restart=restart, maxiter=maxiter, callback=callback)

TypeError: gmres() got an unexpected keyword argument ‘rtol’

Any feedback to resolve this issue would be appreciated.

Alan

I am currently exploring the use of Bempp-cl for thin shell simulations, where the BEM part of the computation requires considerable resources. In the legacy Bem++, hierarchical matrices were available. I am wondering if there are any plans to reintroduce H-matrix support in Bempp-cl, or to provide an interface with Fenicsx?

Thanks

You can access the interaction matrix of the MoM with the function bempp.api.as_matrix(), see bempp_cl.api — Bempp 0.4.2 documentation.

For example, use matrix = bempp_cl.api.as_matrix(operator.weak_form()), with operator a boundary integral operator.

The size of the matrix depends on the formulation and function spaces you use. For RWG functions, this would be the number of edges in the triangular surface mesh.

Good luck.

Elwin

I’m an undergraduate student trying to further my understanding of MoM and numerical electromagnetics and I would like to manipulate the underlying interaction matrix of structures I’m simulating in bempp to take out and add contributing Green’s functions to analyze the impact on the overall scattering response.

As I understand it, MoM solves for the interaction matrix, inverts it and then excites it with voltages and solves it for the currents. I’d like to access the underlying interaction matrix and manipulate it externally to bempp.

The interaction matrix I assume would be of size N x N, where N would be the number of meshes.

Please let me know how I can go about this. Thanks a lot!

I am trying to implement a vibroacoustics FEM-BEM coupled model using FEniCSx and Bempp.
The model is simplified to a box with only one surface vibrates to produce sound into the exterior (the rest is rigid), and I would like to model the box in FEM and the vibrating surface in BEM.
The FEM part is already implemented, but I am struggling to import the surface mesh into Bempp side.

fenicsx.fenics_to_bempp_trace_data would create a function space for the boundary of the mesh given, so I can’t directly give the 2D submesh of the vibrating surface created in FEniCSx.

Meanwhile, even if I give fenicsx.fenics_to_bempp_trace_data the whole cube to create a function space for the all 6 surfaces, I am under the impression that I would not be able to use gmsh Physical tags to selectively choose and access the vibrating surface.

Ideally, I would like to create the trace space specifically for this one vibrating surface without dealing with coordinates to identify which surface is which.

Does anyone have any idea of how I might be able to do this?

Thank you in advance for your time, and I am looking forward to your advice.

Thank you

“”"
Platform: osx-arm64
Collecting package metadata (repodata.json): done
Solving environment: failed

PackagesNotFoundError: The following packages are not available from current channels:

• bempp-cl
• “”"

1. def dirichlet_data(x, n, domain_index, res):
2. def neumann_data(x, n, domain_index, res):

Meanwhile a Neumann boundary condition on the boundary between two dielectrics is quite different: \epsilon_1 E_1 = \epsilon_2 E_2

Bempp currently only supports 3D targets, and it’s not really feasible to update the current code to support 2D, as 3 dimensions are hard coded in a lot of places.

We have some plans to allow the upcoming Rust-based bempp-rs to support 2D problems, but that feature is a long way off.

Key Points of Concern:

1. Lack of 2D Tutorials: Existing Bempp examples focus on 3D scenarios.
2. Green’s Function Differences: 2D and 3D Green’s functions have distinct formulations, and their integration into Bempp’s operator framework may vary.
3. Feasibility: Whether Bempp inherently supports 2D electromagnetic simulations despite its 3D-focused documentation.

Suggestions for Resolution:

• Check Bempp’s API or documentation for explicit 2D operator support.
• Adapt 3D tutorials to 2D by modifying boundary conditions and Green’s functions.
• Verify with simple 2D benchmarks (e.g., circular cylinder RCS) against analytical solutions.

For the Robin boundary condition, I am not sure how to obtain phi: does it get passed in as the solution to greens equation, or do I calculate it from the point coordinate? Once I have phi there is the left hand side of the BC: the derivative of phi wrt. the normal direction; and the right hand side: f(phi) = i, so do I need to define all of these terms in my RBC?

If I remember correctly, the formulation we ended up with was tidier than many other formulations for Robin conditions that we’d seen.

(Note that you’ll also need to do the update in [announcement] import bempp_cl.api - #2 before you can use the new normals)

I’ve just merged a PR that renames the Python module in bempp-cl from bempp to bempp_cl. The reason for this is so that bempp-cl can be more easily used alongside (the still very experimental) bempp-rs.

If you’re using bempp-cl, you’ll need to replace all instances of bempp.api with bempp_cl.api (eg import bempp.api becomes import bempp_cl.api) next time you update your Bempp version.

I had a copy of the example scripts from that paper, I’ve uploaded them here: https://www.dropbox.com/scl/fi/bdgciou6y1eqc98d7zlth/bempp-toms-examples.zip?rlkey=1sofquslquret6sh8wxtgk2q6&dl=0

Note that these scripts are unlikely to work any more unless you install a very old version of Bempp-legacy.

I’ll look into getting these hosted somewhere, and will then link to them from the web page, as even if they no longer work, I think it’s important that they’re available

I need to model the scattering from structures near a ground seen as a PEC plane.
I know that BEMPP only has functionality for free space Green’s functions and that half-space models are not currently supported (cf :
How can I define a MtE operator on a bounded plane?, and :
Accounting for ground effects in acoustic radiation).

In my case, modelling the soil as a finite screen or implementing the method of images would be too computationally expensive.
Does anyone know how I could implement this functionality in BEMPP, e.g. by using a half-space green function?
Thanks in advance.

sphere0 = bempp.api.shapes.cube(length = 0.4, origin=(-1.0, 0, -0.2), h=0.2)
sphere1 = bempp.api.shapes.cube(length = 0.4, origin=(1.0, 0, -0.2), h=0.2)

will get

The legacy bempp v.3 has H-matrix compression but bempp-cl has not. It has an interface to ExaFMM for fast matrix-vector products.

grid = bempp.api.Grid(vertices, elements)
space = bempp.api.function_space(grid,“P”,1) # piecewise linear
Lk = bempp.api.operators.boundary.helmholtz.single_layer(space, space, space, k)
Mk = bempp.api.operators.boundary.helmholtz.double_layer(space, space, space, k)
Lkout = bempp.api.as_matrix(Lk)
Mkout = bempp.api.as_matrix(Mk)

Any suggestions? Thanks again,

-S. Hambric

When creating a GridFunction, you create a function f(\mathbf{x}) = \sum_{i=1}^N \alpha_i g_i(\mathbf{x}) where g_i(\mathbf{x}) is a basis function and \alpha_i is its coefficient. In your case, g_i is a P1 function corresponding to grid node i and the \alpha_i values come from the complex_velocity array.

Indeed, at a grid node \mathbf{x}_j, we have f(\mathbf{x}_j) = \alpha_j so you can interpret the coefficients as the function value in the nodes. Inside each triangle, the function is a weighted average of three basis functions.

At the edges of a cube, the normal direction does not exist. At the same time, a basis function g_j for a grid node j at the cube’s edge has support on all surrounding triangles. The normal direction exists on each of these triangles, but is different depending on the cube’s face. When specifying an analytical function for the argument fun, Bempp will take this into account. When specifying the coefficients argument, you will have to specify correct values. One idea is to interpret the normal direction at the cube’s edge as an average of the connecting faces, but make sure to normalize the vector to unit length.

Regarding the potential operators: since you evaluate the field relatively near to the object, you should use operators.potential, which calculates the potential operators in the representation formula. The far-field operators in operators.far_field use the far-field approximation of r \to \infty with r the distance to the global origin. This approximation allows to simplify the calculations by eliminating higher-order terms in r. Hence, the far-field operators are less accurate for the near field. Since you evaluate at 200 mm away from a 25 mm cube, I would use the near field operators.

The normal vectors are calculated from the topology of the mesh elements, with the “right-hand rule” for the ordering of the three nodes of each triangular element. The meshes in the shapes module of Bempp use Gmsh to create the surface grid. Indeed, the grid bempp.api.shapes.cube() has all normals pointing outwards.

In the case of the FEM-BEM tutorial, the surface mesh is extracted from the volumetric mesh created by the Dolfin library of FEniCSx. This used to produce a surface mesh with outward pointing normals. However, I tested this with Dolfin’s latest version 0.9.0 and I can reproduce this issue. Half of the normals are pointing outwards and the other half inwards.

Wrongly oriented normals may produce incorrect results, depending on the specific BEM formulation. Since the double-layer operator is used, the results of the FEM-BEM algorithm are wrong with Dolfin 0.9.0.

Workarounds are downgrading the Dolfin version or manually swapping the inward pointing normals.