I have just found out a curious thing that when changing the nstep value to 1 (unity) in [soln-plugin-residual] closure, the code does not produce residuals at all in the output file, a *.csv file is created but stays empty.
I have just found out a curious thing that when changing the nstep value
to 1 (unity) in [soln-plugin-residual] closure, the code does not
produce residuals at all in the output file, a *.csv file is created but
stays empty.
This is due to the design of the residual plugin which estimates the
residual through:
residual = (prev_soln - curr_soln) / delta_t
with the plugin itself having two phases: the first phase is run one
time step before we are due to save out the residual and its purpose is
to assign:
self._prev = curr
and then in the second phase (run on the next time step) we actually
compute an approximation to the residual itself.
The problem when nsteps = 1 is that in a single time step we have to
perform both phases. This confuses the code as it is currently written.
I can certainly update the plugin to support this. However, generally
speaking nsteps = 1 is extremely frequent in terms of residual output.
Usually, we would not run below nsteps = 50 given that with an explicit
code such as PyFR the time steps themselves are usually extremely small.
Ok, no question Anyway, such an information could be introduced somewhere in the manual that the nstep is in fact not an integer but rather an “even integer” starting from 2 and then wider explanation like yours.
Best regards,
Piotr
W dniu czwartek, 28 kwietnia 2016 00:11:45 UTC+2 użytkownik Freddie Witherden napisał:
Ok, now I got the point. The issue comes when the nsteps is equal to 1 and starts with the very first step as it cannot read a previous step. Now it’s clear So yes the “nsteps > 1” will be a clear definition of what is allowed.