TypeError: All viewed matrices must belong to the same allocation

Errors
1

I have a mesh consisting of prisms and tetrahedra, generated in Pointwise and elevated to Q3. It was partitioned with METIS using the balanced argument. When I try to run PyFR with order = 0, I receive a “No suitable quadrature rule found”, despite having the appropriate [solver-interfaces-{tri,quad}] and [solver-elements-{pri,tet}]. If I run it with order = 1 or 2, I receive “TypeError: All viewed matrices must belong to the same allocation”.

In type.py, this error is raised during the “Validate the matrices” step:


 # Validate the matrices
        if any(not isinstance(m, mattypes) for m in self._mats):
            raise TypeError('Incompatible matrix type for view')

        if any(m.basedata != self.basedata for m in self._mats):
            raise TypeError('All viewed matrices must belong to the same '
                            'allocation extent')

I can’t say I understand what is going on here, but I expect this is an issue with the mesh. The grid looks fine in Pointwise (prior to elevation) and when I load it in Tecplot (after elevation) I’m not seeing any glaring problems. Could anyone suggest a way to troubleshoot this?
Thanks,
Brian

2

Can you post your full configuration file along with the .msh file.

Regards, Freddie.

3

Hi Freddie,
I’ve posted the .msh file here: Dropbox - SMC000 - Simplify your life

And my configuration below:

# Set Point 3
# NPR = 1.197, NTR = 1.0

[backend]
precision = double
rank-allocator = linear

[constants]
gamma = 1.4
mu = 0.00111
Pr = 0.71
# Custom
NPR = 1.197
NTR = 1.0
Ps = 101325
Ts = 288
Rhos = 1.225
Cp = 1006

[solver]
system = navier-stokes
order = 2
#viscosity-correction = sutherland
viscosity-correction = none


[solver-time-integrator]
formulation = std
#scheme = euler 
#scheme = rk34
scheme = rk45
#controller = none
controller = pi
atol = 1e-5
rtol= 1e-5
tstart = 0
tend = 1.00 
dt = 1e-9

[solver-interfaces]
riemann-solver = rusanov
ldg-beta = 0.5
ldg-tau = 0.1

[solver-interfaces-tri]
flux-pts = alpha-opt

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

[solver-elements-tet]
soln-pts = alpha-opt

[solver-elements-pri]
soln-pts = alpha-opt~gauss-legendre-lobatto

[soln-ics]
rho = Rhos
u = 3.0
v = 0.0
w = 0.0
p = Ps

[soln-bcs-ext_inflow]
type = char-riem-inv
rho = Rhos
u = 3.0
v = 0.0
w = 0.0
p = Ps

[soln-bcs-farfield]
type = char-riem-inv
rho = Rhos
u = 3.0
v = 0.0
w = 0.0
p = Ps

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

[soln-bcs-inflow]
type = sub-in-ftpttang
pt = NPR*Ps
cpTt = NTR*Ts*Cp
theta = 0.0
phi = 90.0

[soln-bcs-outflow]
type = sub-out-fp
p = Ps

[soln-plugin-writer]
dt-out = 0.000005
basedir = .
basename = soln-{t:.6f}

[soln-plugin-residual]
nsteps = 10
file = residual.csv
header = true
4

Looking through the mesh it does not appear as if there are any fluid elements:

$PhysicalNames
6
3 6 "vc-2"
2 1 "ext_inflow"
2 2 "farfield"
2 4 "inflow"
2 3 "outflow"
2 5 "visc"
$EndPhysicalNames

On my system this gives an import error when I try to convert the mesh to .pyfrm.

The quadrature rule error is expected at p = 0. In particular if you look at the list of triangular rules known to PyFR in PyFR/pyfr/quadrules/tri at develop · PyFR/PyFR · GitHub you’ll see there is no alpha-opt rule with one point (which is what p = 0 corresponds to). Switching to williams-shunn will resolve the issue, however. A similar line of reasoning holds for the tet element solution points.

Regards, Freddie.

5

Sorry Freddie, I forgot that I had modified the mesh after transferring it to my HPC to fix the import error: sed -i 's/"vc-2"/"fluid"/g' 240522_SMC000_sp3_re1e4.msh
This renames “vc-2” to “fluid” and allows for import.

I did look through the quadrules and switched to “flux-pts = williams-shunn” for [solver-interfaces-tri] and “soln-pts = shunn-ham” for [solver-elements-tet], which did allow me to run p = 0. Interestingly, this also seemed to fix the TypeError I was receiving from running p = 2. Thanks for your help.