Unexpected results visualization

[Luca_P]

Hi PyFR Forum!
I was running a simple case of NACA0012 Airfoil at M = 0.2 Re = 1e6 and different angles of attack. Although my simulation is completed, something strange happens near the leading edge of the profile and the problem persists even if I change my mesh. Can this be linked to some Paraview’s settings or to the configuration of my simulation?
In Paraview I already tried different filters suggested by this forum and paraview forum in related topic. I also exported using the two different options -k and -d but the problem is still there.
I also tried different order for the simulation and double precision but nothing changes.
This is the .ini file that I used.

[backend]
precision = single
[constants]
gamma = 1.4
mu = 1.8e-5
Pr = 0.72
M = 0.2
p = 101315
[solver-time-integrator]
scheme = euler
controller = none ;pi
tstart = 0.0
dt = 1e-7
tend = 3
;atol = 0.000001
;rtol = 0.000001
;safety-fact = 0.5
;min-fact = 0.3
;max-fact = 1.2
;dt-max = 1e-5
;errest-norm=l2
[soln-plugin-writer]
dt-out = 1e-2
basedir = sol
basename =n0012_{t:.2f}
[solver]
system = navier-stokes
order = 3
[solver-interfaces]
riemann-solver = roe
ldg-beta = 1
ldg-tau = 1
[solver-interfaces-line]
flux-pts = gauss-legendre
quad-deg = 11
quad-pts = gauss-legendre
[solver-interfaces-quad]
flux-pts = gauss-legendre
quad-deg = 11
quad-pts = gauss-legendre
[solver-elements-quad]
soln-pts = gauss-legendre
quad-deg = 11
quad-pts = gauss-legendre
[solver-interfaces-tri]
flux-pts = williams-shunn
quad-deg = 11
quad-pts = williams-shunn
[solver-elements-tri]
soln-pts = williams-shunn
quad-deg = 11
quad-pts = williams-shunn
[soln-bcs-inlet]
type = sub-in-frv
rho = 1.0
u = 20.0
v = 3.0
[soln-bcs-outlet]
type = sub-out-fp
p = 101315
[soln-bcs-wall]
type = no-slp-adia-wall
[soln-ics]
rho = 1.0
u = 20
v = 3
p = 101315
[soln-plugin-fluidforce-wall]
nsteps = 10000
file = wing-forces.csv
header = true
quad-deg = 6
morigin = (0.0, 0.0)
[soln-plugin-residual]
nsteps = 10000
file = residual.csv
header = true
norm = inf
[soln-plugin-nancheck]
nsteps = 90

I share also residuals trend which do not converge to a near-zero value. I have already read this comment but i did not understand it.
https://pyfr.discourse.group/t/about-residual-convergence/1044/3

I also tried an higher order mesh.

[fdw]

@Luca_P

ldg-beta = 1
ldg-tau = 1

On what basis did you select these values? They are somewhat extreme.

Regards, Freddie.

[tdzanic]

Also, is your high-order mesh actually curved or is it just the linear mesh elevated to a higher order space?

[Luca_P]

I tried also rk45 method with lower values but results are the same. Then I used euler which required an higher value to have stability. Why ldg-beta or ldg-tau should be associated to this problem? Moreover, I simulated on a different mesh and with lower Re and the problem is still here, for this reason i thought it was linked to the mesh or to the first cell height.

[Luca_P]

I don’t know how to answer this question (I wish it had been curved), because it seems like the nodes follow the geometry only on the airfoil, but not in the first cells. Do you know how to generate a curved mesh in GMSH? I I haven’t found anything online regarding this, and any help would be greatly appreciated.

[tdzanic]

It does appear to be a high-order mesh. I would first try Freddie’s suggestion and change the LDG parameters to the defaults

ldg-beta = 0.5
ldg-tau = 0.1

Then, I would also try refining in the wall-normal direction (decreasing the wall-normal spacing of the first element). It appears your mesh is a bit coarse so this effect could be due to under-resolution.

[boundaryconditions]

Try using the Rusanov Riemann solver, though if it solves the issue, it probably did so because it is a bit diffusive.

[Luca_P]

I changed those values as you and @boundaryconditions suggest and I repeated the simulation on a finer mesh but the result is the same

[boundaryconditions]

Can you share the gmsh mesh and the file used to generate it (.geo or .py)?

[tdzanic]

Looking at it qualitatively it looks like it’s primarily at the first wall-normal elements’ boundaries. Two things I recommend trying: 1) this could be a visualization quirk, can you check that you’re doing high-order visualization in Paraview (Nonlinear Subdivision Level > 1)? I would also assume a CleanToGrid filter would help here but that’s just dealing with the symptoms and not the cause. 2) if (1) doesn’t change anything, can you try enabling anti-aliasing (flux and surf-flux) in the solver options?

I agree also sharing the config/mesh files would be helpful.

[Luca_P]

n0012_pyfr.ini
n0012_finer.msh
Mesh_for_PyFR

[Luca_P]

Here the config file:
n0012_pyfr.ini

I tried different filters on Paraview but I think it is not a visualization quirk.