I noticed a weird phenomena while using the sampler plugin. I am running a case with std rk4 time stepping and dt = 0.00125. I want to sample a bunch of points every 1000 steps. Some configurations are showed as following:
formulation = std
scheme = rk4 ; tvd-rk3
controller = none
tstart = 0.0
tend = 30000
dt = 0.00125
nsteps = 1000
samp-pts=[a lot of points]
format = primitive
file = point-data.csv
header = true
However, when I check sample result, time t is showing something different:
From the 5th output, it shows it samples 999 steps rather than 1000. And it will accumulate error: till t = 36.24125 it missed 7 steps. Do you have any idea about this? I couldn’t see something odd from the source code. Is that because I have sampled too many points?
This is expected behaviour. Certain plugins (most notably the solution writer) have specific output times. In order to hit these times within a prescribed tolerance, PyFR will vary dt as required. Often these variations can be somewhat non-intuitive due to floating point round-off error.
Case in point, if you run the included Euler vortex example and dump the stats file at
t = 100 you’ll see that it takes
nsteps = 20005 to get to
t = 100 with a
dt = 0.005.
Floating point math is often non-intuitive. For example:
which would cause anything scheduled to happen at
t = 2.5 to overshoot. Thus, if you have a plugin scheduled to run at this time PyFR will take a smaller step than usual to ensure we don’t overshoot.
Ok. This will cause problems when restarting the program and do spectral analysis with data sampled. I slightly changed time step and it seems sampling at the frequency I want. Thanks for the explain.
You can simply put a cubic spline through the sampled data and then use the spline to resample as appropriate.