Sometimes when comparing solutions across codes we use a time-average of the flow field. That time-average can be computed from instantaneous snapshot as a post-processing step. However, if we do that, we (i) are incurring a lot of I/O time to write instantaneous data, (ii) have to post-process into the time-averaged field, and (iii) are likely not going to save every single time step for a true time-average.
I suggest we add a time-average mechanism to FAST.Farm. The user should be able to specify the start and end time of the time-average, as well as windows. Getting averages usually involve carrying quantities defined at every grid point summed for all the prior time steps. Because of this sum, we are unable to perform a true sliding window of averaged and it results in a exponentially-weighted average. I suggest the average to be implemented in FAST.Farm to have a window parameter and the accumulation of quantities be reset at the beginning of this window. As an example, say we run a FAST.Farm simulation for 3600s and we want 600-s averages starting at 600s. For a 600-s window, that means we will have averages computed over the following intervals: (600,1200], (1200,1800], (1800,2400], etc. However, one caveat of having windows reset is if the user saves the averaged field at the instant t=1400 s, for example, it would not be a 600-s average, but rather the arithmetic mean of the interval (1200,1400]. I think this is a fair compromise to having true windowing averages.
Sometimes when comparing solutions across codes we use a time-average of the flow field. That time-average can be computed from instantaneous snapshot as a post-processing step. However, if we do that, we (i) are incurring a lot of I/O time to write instantaneous data, (ii) have to post-process into the time-averaged field, and (iii) are likely not going to save every single time step for a true time-average.
I suggest we add a time-average mechanism to FAST.Farm. The user should be able to specify the start and end time of the time-average, as well as windows. Getting averages usually involve carrying quantities defined at every grid point summed for all the prior time steps. Because of this sum, we are unable to perform a true sliding window of averaged and it results in a exponentially-weighted average. I suggest the average to be implemented in FAST.Farm to have a window parameter and the accumulation of quantities be reset at the beginning of this window. As an example, say we run a FAST.Farm simulation for 3600s and we want 600-s averages starting at 600s. For a 600-s window, that means we will have averages computed over the following intervals: (600,1200], (1200,1800], (1800,2400], etc. However, one caveat of having windows reset is if the user saves the averaged field at the instant t=1400 s, for example, it would not be a 600-s average, but rather the arithmetic mean of the interval (1200,1400]. I think this is a fair compromise to having true windowing averages.