Slicing a MatrixBank?

General
1

Running compressible NS, a matrix_bank is created at line 208 in file pyfr/solvers/base/elements.py scal_upts_inb,

    # pyfr/solvers/base/elements.py scal_upts_inb (line 208)
    self.scal_upts_inb = inb = backend.matrix_bank(self._scal_upts)

Later, at line 65 in file pyfr/solvers/navstokes/elements.py, this bank gets passed as an arg to self._slice_mat(…)

    # pyfr/solvers/navstokes/elements.py (line 65)
    u = lambda s: self._slice_mat(self.scal_upts_inb, s)

If I run this sim from a command line, all is ok. Likewise, when run as a Visual Studio 2019 project, all is ok. But when stepping through with the VS debugger, I get stopped at line 159 in file pyfr/backends/base/types.py,

    # pyfr/backends/base/types.py (line 158)
    if isinstance(mat, MatrixBank) and any('bank' in m.tags for m in mat):
        raise TypeError('Nested MatrixBank objects can not be sliced')

If I comment out this check, then the sim runs fine under the debugger. Which got me wondering if this restriction on slicing a MatrixBank still applies?

Below is the .ini file I’m using:

[backend]
precision = single
rank-allocator = linear

[backend-cuda]
device-id = local-rank

[constants]
gamma = 1.4
Pr    = 0.72
mu    = 1e-5
uin   = 0.2

[solver]
system = navier-stokes
order = 4
anti-alias = none

shock-capturing = artificial-viscosity
[solver-artificial-viscosity]
kappa = 5.0
max-artvisc = 5.0e-5
s0 = 7e-4

[solver-time-integrator]
scheme   = rk45
controller = pi
atol = 1.0e-6
rtol = 1.0e-6
min-fact    = 0.3
safety-fact = 0.80
max-fact    = 1.20

dt      =  1.0e-5
dtmin   =  1.0e-10

tstart =  0.0
tend  =  1.0

[solver-interfaces]
riemann-solver = hllc

ldg-beta = 0.5
ldg-tau = 0.1

[solver-interfaces-line]
flux-pts = gauss-legendre

[solver-elements-quad]
soln-pts = gauss-legendre

[solver-elements-tri]
soln-pts = williams-shunn

[soln-plugin-nancheck]
nsteps = 100

[soln-plugin-dtstats]
flushsteps = 100
file = dtstats.csv
header = true

[soln-plugin-writer]
dt-out = 0.5
basedir = .
basename = ns_{n:03d}

[soln-bcs-inflow]
type = char-riem-inv
rho = 1.0
u = uin
v = 0.0
p = 1.0

[soln-bcs-wall]
type = no-slp-adia-wall

[soln-ics]
rho = 1.0
u = uin
v = 0.0
p = 1.0

thanks - Nigel

2

The limitation is with nested matrix bank objects, so a matrix bank where one of more of the entries is itself a matrix bank. These are not something which are found anywhere in PyFR and so the check should never trigger.

The limitation itself is in place due to how slices are cached. Specifically, the following method (using OpenCL as an example) is not safe if the thing being sliced is a bank of banks:

If in this function, mat (an entry in the matrix bank), is itself a bank then it will be sliced based off of its currently active bank. The slice, however, will not update if the active matrix in this bank is changed, hence why the check is needed in order to avoid a bug.

Regards, Freddie.

3

Thanks Freddie for the clear explanation!
Nigel