I run an explicit time simulation using compressible solver and the pi controller. i have some problems with the tavg output file merge feature.
For example, if the writer plugin’s dtout input is 0.0001, together with that of the tavg plugin, i don’t get the averaged file output at the end of the simulation. Probably because tavg’s nsteps is greater than 1 and the time step is adaptive, which means, tavg and writer don’t easily meet at the final output. what i do to get an tavg output at the end is that I change my tend=0.0020 to 0.00200001, for example. However, i can’t use the tavg’s merge tool anymore because the time intervals of the mean flow files overlap with each other.
Do I understand things correctly? If yes, the only solution to this problem would be use of a constant time step size. Since I don’t want to use a safely small time step size for the entire simulation, the dual time stepping would be the best solution, isn’t it?
Using this setting, I restarted from t=0.50 and set the simulation end to be tend = 0.51 and the writer’s dt-out = 0.01. tavg does not create an average file, whereas writer creates the solution output.
I was wrong previously: tavg does not create the average file even if i set nsteps = 1. However, if i set a simulation end of tend = 0.5101, for example, tavg creates the output at t=0.5101, whereas writer’s output happens to be at t = 0.51. Unfortunately, subsequent tavg outputs created like this cannot be merged using the merge tool because they overlap with each other.
Could this be a bug? or am i doing something embarrassingly wrong?
Actually, I have ignored this issue so far. Instead, i averaged the windowed tavg outputs on Paraview. However, working on a far larger simulation, i thought using the merge tool would be very efficient by all means.
I prepared an easier-to-reproduce case based on 3d-trianglular-aerofoil test case. PyFRv2.1 is used. The ini file is below (tavg is added only):
[backend]
precision = single
rank-allocator = linear
[constants]
gamma = 1.4
mu = 0.0003333333333333333
Pr = 0.71
[solver]
system = navier-stokes
order = 4
[solver-time-integrator]
scheme = rk45
controller = pi
atol = 1e-5
rtol= 1e-5
tstart = 0
tend = 0.02
dt = 6e-05
[solver-interfaces]
riemann-solver = rusanov
ldg-beta = 0.5
ldg-tau = 0.1
[solver-interfaces-quad]
flux-pts = gauss-legendre
[solver-elements-hex]
soln-pts = gauss-legendre
[soln-plugin-nancheck]
nsteps = 50
[soln-plugin-fluidforce-airfoil]
nsteps = 10
quad-deg = 4
file = airfoil-forces.csv
header = true
[soln-plugin-writer]
dt-out = 0.01
basedir = .
basename = triangular-aerofoil-{t:.2f}
[soln-plugin-tavg]
nsteps = 5
dt-out = 0.01
mode = windowed
tstart = 0.0
basedir = average
basename = averageField-{t:.8f}
avg-p = p
avg-rho = rho
[soln-bcs-inlet]
type = char-riem-inv
rho = 1
u = 1
v = 0
w = 0
p = 31.74603174603175
[soln-bcs-outlet]
type = char-riem-inv
rho = 1
u = 1
v = 0
w = 0
p = 31.74603174603175
[soln-bcs-horizontal]
type = char-riem-inv
rho = 1
u = 1
v = 0
w = 0
p = 31.74603174603175
[soln-bcs-airfoil]
type = no-slp-adia-wall
[soln-ics]
rho = 1
u = 1
v = 0
w = 0
p = 31.74603174603175
[solver-plugin-turbulence]
avg-rho = 1.0
avg-u = 1.0
avg-mach = 0.15
turbulence-intensity = 2
turbulence-length-scale = 0.075
sigma = 0.7
centre = (-1.0,0.0,0.15)
y-dim = 1.5
z-dim = 0.3
rot-axis = (0,0,1)
rot-angle = 0.0`
Interestingly, when run from t=0, it gracefully produces the average file at t=0.02. However, when restarted from t=0.01, the average file is not produced at t=0.02.
So when running for the first time tout_last is set to 0, but when restarting from 0.01 it is actually set to 0.01 + the first dt which means you won’t get a file written out at exactly 0.02.
We could either run the plugins before the first time step is taken when restarting (but this could cause duplicated values in other plugins csv files) or add some logic to the tavg constructor to check if we are restarting and passed tstart then set tout_last / call itself. @fdw if you have a preferred fix I am happy to open a PR for this?
We try to avoid calling plugins on restart as it typically leads to unwanted results. Extra entries in CSV files is one issue, but the bigger one comes with things like the solution writer which can try to rewrite the solution file you are restarting from.
I think we probably just want some logic in the constructor to handle these issues.
thanks again for the fix!
i wanted to try this out with my already existing simulation files and wanted to restart from the existing solution file. it seems, the mesh/partitioning format has been changed since v2.1.0, and there is backward incompatibility. is that correct?
That is correct. The current develop version of PyFR — where the fix has been applied — uses a new file format which is not compatible with the previous format.