sfstoolbox/sfs-python

WFS focused source 2.5D fails

hagenw opened this issue · 8 comments

hagenw commented

Please execute the following code:

import sfs
import numpy as np

xs = 0, 0.5, 0  # position of source
ns = 0, -1, 0  # direction of source
omega = 2 * np.pi * 1000  # frequency
xref = 0, 0, 0  # 2.5D reference point
array= sfs.array.circular(200, 1.5)
grid = sfs.util.xyz_grid([-1.75, 1.75], [-1.75, 1.75], 0, spacing=0.02)
d, selection, secondary_source = \
    sfs.mono.wfs.focused_25d(omega, array.x, array.n, xs, xref)
twin = sfs.tapering.tukey(selection, .3)
p = sfs.mono.synthesize(d, twin, array, secondary_source, grid=grid)
print(p)

For me p is 0 and I get the following warning:

/home/hwierstorf/git/sfs-python/sfs/util.py:340: RuntimeWarning: invalid value encountered in true_divide
  return x / np.linalg.norm(x)
/home/hwierstorf/git/sfs-python/sfs/util.py:613: RuntimeWarning: invalid value encountered in greater_equal
  return inner1d(ns, ds) >= default.selection_tolerance

while calculating it.

This worked with the old syntax in sfs 0.4.0.

fs446 commented

adding ns
sfs.mono.wfs.focused_25d(omega, array.x, array.n, xs, ns, xref)
is probably what you're looking for.
This parameter is new due to the changes in driving function handling introduced in
d4ac310

fs446 commented

I don't know if one can state a meaningful default, but if so we might think of a default ns.
Derived from source position into center or something like that.

hagenw commented

Ah, I my fault, thank you for pointing the missing ns out. Now everything works fine.
I don't think we can provide a meaningful default, and there is also no reason why we should do as a focused source has to have a direction.

fs446 commented
narahahn commented

A default ns vector could be defined from xref and xs.
When we determine ns, we already have a xref in mind.
IMO, it would be more convenient/intuitive to give xref as an argument
and let the toolbox compute the ns vector.

Although we don't have xref in 2/3D WFS driving functions,
we can add it, if it's a desirable feature.

... and now I see @fs446 's comment.

hagenw commented

We (mis)used xref before in the sfs-matlab, but it is not that intuitive as xref is conceptual unrelated to the direction of the focused source. Now the user is required to provide a direction for the focused source.

In summary, I still see no need to provide a default value for ns.

fs446 commented

I'm fine with not having a default for ns.

mgeier commented

I guess we can close this issue.