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.
Thank you and best regards, Piotr 2016-04-28 11:11 GMT+02:00 Vincent, Peter E <[email protected]>: > Hi Piotr, > > Thanks for the feedback. > > We can add a note indicating nsteps > 1. But I don’t think nsteps has to > be even? > > Cheers > > Peter > > Dr Peter Vincent MSci ARCS DIC PhD > Senior Lecturer and EPSRC Early Career Fellow > Department of Aeronautics > Imperial College London > South Kensington > London > SW7 2AZ > > email: [email protected] > web: www.imperial.ac.uk/aeronautics/research/vincentlab/ > twitter: @Vincent_Lab <https://twitter.com/#!/Vincent_Lab> > > On 28 Apr 2016, at 09:28, Piotr Prusiński <[email protected]> > wrote: > > 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ł: >> >> Hi Piotr, >> >> On 27/04/2016 05:06, Piotr Prusiński wrote: >> > 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. >> >> Regards, Freddie. >> >> > -- > You received this message because you are subscribed to the Google Groups > "PyFR Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/pyfrmailinglist. > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "PyFR Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send an email to [email protected]. Visit this group at https://groups.google.com/group/pyfrmailinglist. For more options, visit https://groups.google.com/d/optout.
