WFS 2.5D point source driving function error

[hagenw]

I have tested the 2.5D WFS driving function for a point source with a more complicated array and got the following result. As the array is completely symmetrical and the point source placed in the center, I would suspect the sound field to be symmetrical as well, but this is not the case.

import numpy as np
import matplotlib.pyplot as plt
import sfs
plt.rcParams['figure.figsize'] = 8, 4.5  # inch
xs = 0, 2.5, 0
omega = 2 * np.pi * 700
xref = 0, -3, 0
# loudspeaker array
N = 100
radius = 1
# start with a circle and split it
x0_circle, n0_circle, a0_circle = sfs.array.circular(N, radius)
assert N % 2 == 0
upper_x, lower_x = np.split(x0_circle, [N//2 + 1])
upper_n, lower_n = np.split(n0_circle, [N//2 + 1])
# reverse order of upper loudspeakers
upper_x = np.flipud(upper_x)
upper_n = np.flipud(upper_n)
# reverse direction of lower loudspeakers
lower_n = -lower_n
# put all together
x0 = np.row_stack((
    lower_x - [6 * radius, 0, 0],
    upper_x - [4 * radius, 0, 0],
    lower_x - [2 * radius, 0, 0],
    upper_x,
    lower_x + [2 * radius, 0, 0],
    upper_x + [4 * radius, 0, 0],
    lower_x + [6 * radius, 0, 0],
))
n0 = np.row_stack((
    lower_n,
    upper_n,
    lower_n,
    upper_n,
    lower_n,
    upper_n,
    lower_n,
))
a0 = sfs.array.weights_midpoint(x0, closed=False)
grid = sfs.util.xyz_grid([-9, 9], [-10, 2], 0, spacing=0.02)
d = sfs.mono.drivingfunction.wfs_25d_point(omega, x0, n0, xs, xref)
a = sfs.mono.drivingfunction.source_selection_point(n0, x0, xs)
twin = sfs.tapering.tukey(a,.3)
p = sfs.mono.synthesized.generic(omega, x0, n0, d * twin * a0 , grid,
    source=sfs.mono.source.point)
normalization = 4
sfs.plot.soundfield(normalization * p, grid);
sfs.plot.secondarysource_2d(x0, n0, grid)

[trettberg]

The driving function is fine, but tapering does not work with multiple regions of active sources.
The resulting window is not symmetric.

This will not happen with convex arrays, so I think it's okay.

[hagenw]

OK, that's fine with me. I would propose that we don't change anything and you can close this issue.

[mgeier]

I guess it would be possible to raise an error in sfs.tapering._windowidx() if there are gaps within the active sources, right?

[trettberg]

Sure, but secondary source selection is also not guaranteed to work for non-convex arrays.

[mgeier]

Can this be detected reliably?
If yes, we might also want to raise an error there ...

[trettberg]

For arrays in 3D it will take some extra effort, I think.

[hagenw]

That is correct. In sfs-matlab we also lack a solution for 3D at the moment, but there was already a discussion on what might be a solution, see sfstoolbox/sfs-matlab#21

[trettberg]

Surely a custom array could be tested for convexity.
We'd do this once after creation and not each time during source selection.

But personally I would not like it because it seems over-protective to me.