[zebu83]

Good morning everybody.

In this days I try to simulate a channel with the tutorial "channelOodles". Every goes well, but when I try to calculate some quantities (u_rms, v_rms, w_rms, Umean, uv) with "postChannel" I find that they are underestimated.
I gonna look into the "postChannel" directory and I understand that the utility calculate first the time average and then the spatial average.
This is an error!

I can't make correlation like this, because when I calculate, for example u_rms, I need local Umean, not time average Umean especially if I am simulating turbulent case. At every time step first I have to estimate spatial average, then I can make time average of all time step spatial average.

This is what I understand, but if I am wrong please tell me ( I have a lot of data that in this moment I can't use for this reason).

Best regards

MT

[fs82]

Hi,

for my understanding postChannel works correctly. postChannel is like the name already states a postprocessing tool. The time averaging is done by the solver. The only thing postChannel does it to collapse the fields, e.g. UMean to a line. This is done by a spatial average in streamwise and spanwise direction. This helps you to reduce the averaging time for a channel which is periodic in streamwise and spanwise direction. For my understanding this is correct and I use this postChannel tool every day and my results are in good agreement with other papers.

kind regards,
Fabian

[zebu83]

Yes it's correct how it works, but it is not correct how it uses time averaging (because if you don't calculate Umean with the function fieldsAverage).
It's quite different to collapse first in streamwise and in spanwise direction U, then makes time average of U to have Umean, instead to calculate Umean at each time step and then collapse in stramwise and spanwise direction.

I reformulate my post:
you can not use the time averaging done by the solver to calculate with postChannel the flow statistics.
It is mathematically correct to invert time and spatial averaging if we reach the stability. For example if we have U signal that changes between 3 to 7, of course time averaging is 5 and I can calculate the u_rms (for example) using Umean done by the solvers.
But if I have a not stationary flow or a flow that don't reach yet the stationarity there are some difference!
For example from time step 0 to time step 10 U changes between 3 to 7 (then Umean is 5), then from time step 10 to time step 20 it changes between 10 to 20 (then Umean is 15), total U mean is 10. So if i want right statistic, like u_rms, I have to do: u_rms_timestep5 = (sqrt(U_timestep5 - Umean_timestep5))^2; that produces a different results from: u_rms_timestep5 = (sqrt(U_timestep5 - Umean))^2 that is what postChannel do!

To have right statistics you must first collapse U in streamwise and in spanwise direction, for each fields, then do time averaging.

A possible solution, if it is correct what I wrote, is that the solver doesn't calculate

[zebu83]

Yes it's correct how it works, but it is not correct how it uses time averaging (because if you don't calculate Umean with the function fieldsAverage postChannel doesn't work:

Collapsing fields for time 4040
No UMean field
end

).

It's quite different to collapse first in streamwise and in spanwise direction U, then makes time average of U to have Umean, instead to calculate Umean at each time step and then collapse in stramwise and spanwise direction.

I reformulate my post:
you can not use the time averaging done by the solver to calculate with postChannel the flow statistics.
It is mathematically correct to invert time and spatial averaging if we reach the stability. For example if we have U signal that changes between 3 to 7, of course time averaging is 5 and I can calculate the u_rms (for example) using Umean done by the solvers.
But if I have a not stationary flow or a flow that don't reach yet the stationarity there are some difference!
For example from time step 0 to time step 10 U changes between 3 to 7 (then Umean is 5), then from time step 10 to time step 20 it changes between 10 to 20 (then Umean is 15), total U mean is 10. So if i want right statistic, like u_rms, I have to do: u_rms_timestep5 = (sqrt(U_timestep5 - Umean_timestep5))^2; that produces a different results from: u_rms_timestep5 = (sqrt(U_timestep5 - Umean))^2 that is what postChannel do!

To have right statistics you must first collapse U in streamwise and in spanwise direction, for each fields, then do time averaging.

A possible solution, if it is correct what I wrote, is that the solver doesn't calculate time averaging, so it can implement postChannel to collapse first in streamwise and in spanwise direction, then calculate time averaging.

What are my errors?
Am I wrong?

Thank you in advance.

MT

[fs82]

But you forget about a very important thing. For statistics your need the information about the velocity field for every timestep. But postChannel is a postprocessing tool. If you have long computational runs, you are not able to save every timestep and you will never get a correct statistic, because there are many informations lost between the timesteps which are written out. So for me it seems to be senceless, to make a time averaging with postChannel utility.
So in detail, if one averages between 3 to 7 and the velocity field changes from 10 to 20 non linear (chaotic) the averaging has to be done every timestep. Who says that your velocity field increases from 10 to 20 without a overshoot for example? It could go from 10 to 50 and back to 20. So time averaging with postChannel is senceless in my opinion and has do be done by the solver.

[zebu83]

[QUOTE][But you forget about a very important thing. For statistics your need the information about the velocity field for every timestep./QUOTE]

I agree with you!
It is for this reason that I wrote the post.
It is right how any solvers works and it is right how postChannel works, there are not mathematical errors, but the background is not right.

As I try to explain before if I have a chaotic flux to calculate statistics, like u_rms, v_rms, ... (different thing is for Umean), I must calculate then for each fields using the current field proprieties. I can't use time average Umean calculate from time step 0, until current time step.
The correct procedure is:
1) calculate U and p with the solver for each fields
2) collapse U in spanwise and streamwise direction to obtain Umean_spatial for each fields
3) calculate rms, like u_rms = ((sqrt(U-Umean_spatial))^2), for each fields
4) do time averaging of Umean_spatial, *_rms, ... to have global Umean, *_rms, ...

Now as it's implemented in OF (my version is 1.5.x) is:
1) calculate U and p with the solver for each fields
2) calculate time averaging Umean without spatial collapsing
3) use postChannel that collapses Umeans in streamwise and spanwise direction, and it calculate *_rms with a Umean that is global Umean and it is not the specific Umean for each fields
This is not correct for me for a chaotic flux! If you have a constant flux there are no problems. There are no problems also if we consider a flux with not a prevalent direction.

Best regards

MT

[fs82]

Allright, I am still not sure if I get what you mean. May be you should write it down carefully in a comprehensible way. I tested the time averaging many times and also the spatial averaging of postChannel and there is no bug in my opinion. If you do an LES of a channel or something else, you are interested in the time averaged value of velocity avg(u_i) and the reynolds stresses avg(u'_i u'_j). This is done by the solver correctly and prooved many times. PostChannel just collapse this to a single line. So if you need something else which have to be calculated during runtime you should have a look into fieldAverage.C and fieldAverageTemplate.C.
May be this helps you:
http://en.wikipedia.org/wiki/Standard_deviation
Have a look at the following section: Simplification of formula

You need the sum of values x_i and x_i^2 for calculation of the standard deviation or root mean square. But this isnt done in OpenFoam as I know. So you have to modify it anyway. May be somebody else knows more about root mean square values, sry :-D

[zebu83]

Your formula is what I try to wrote in the previous post.

I agree with you in everything except in a thing: what wikipedia write, or what you do, or what OF do, is correct if you are in a stationary case.

Time average in correct, spatial average is correct, but if I analyse a chaotic flux I have to calculate first spatial average, then time average.

Of course it is not a bug properly, but I think it is possible to implement it in a function or in a post processing.
I'm not able to modify OF, perhaps if the community thinks that this is a good reason to implement OF, or modify it, I'll be glad to contribute.

Best regards
MT

[eelcovv]

Hi Zebu83,

I agree with you: if you don't have a steady state solution over time it is not correct to first to a time average and than collaps the fields. This is only correct if a steady state flow flow field over the whole time range is used

I just started with doing the channel flow, and I am running in the same problem, that postChannel is complaining that there is no Umean. I tried just to copy the U field of the last time step to Umean and take the spatial average over the xz planes (if the numerical domain is large enough this will be the same a doing a time average, but that is not relevant at the moment). Unfortunately this does not work.

What I would like it taking the time average (postprocessing) over only the last time steps of my calculation (where a steady state has been reached), and than the xz average using postChannel. Have you already found out how to do this ?

Regards,

Eelco

[fs82]

You missed about one thing in my opinion. In a setup of a real configuration e.g. a wing or something like that, you will never have cyclic boundaries like in a channel, like in THIS channel tutorial of OpenFoam. Due to this two cyclic boundaries you are allowed to collapse the fields in the two cyclic directions and this will help you to reduce the necessary computing time for averaging. Because it is periodic the spatial averaging is equal to a time averaging. And by the way if you perform an averaging you have to check first if your solution reached a quasi stationary state and than start averaging over a appropriate long time. In a non cyclic case I think it is not usefull to collapse the field to a single line.