[ngj]

Hi all

I have been looking at the procedure of calculating mean quantities in lesInterFoam and oodles. The procedure is correct as long as the time step is constant, but as soon as the time stepping is based on a Courant number and therefor variable time stepping, the procedure breaks down.

This is the case, since the size of the time step is not taken into account when making the average - instead it is purely based on the number of time steps included in the average. see /solvers/multiphase/lesInterFoam/averaging/calculateAverages.H.

I am planning to make the correction myself at some point within a reasonable time, as I need this deltaT-based procedure. It will become available by then.

Best regards,

Niels

[maka]

This is true also in ChannelOodles. I used to use automatic time stepping 2 years ago. In that case, I used to write the solution with a "constant" (to avoid that issue) sampling period (of order integral time scale). After that I postprocess them with modified postChannel that calculates the averages from the existing folder and then collapse them which used to consume hard desk space.

Modifying the averaging procedure within the solver is off course better choice. One way is to multiply the solution with the current time step before summing and then divide by total time (this weights the average by the the time step). All you need is to look at the average as integral and since time step is not constant, as you noticed, it can not go outside the integral which make the arithmetic average _not_ equivalent to time average. The same note applies when you are collapsing fields in horizontal directions (if you are using channelOodles together with postChannel) if your dx and dz is not uniform.
Best regards,
Maka.

[maka]

An after thought: in case of channelOodles it is not a bug since the solver is written with constant time step and postChannel have clear comment that clarifies that it is written for uniform horizontal spatial resolution.

/Maka.

[ngj]

Hi Maka

Thanks for the insight, even though your method sounds straight forward, I am looking at surface waves of periods >>> the turbulent time scale, thus the amount of data produced in that way cannot be stored on anything I can put my hands on.
As it is right now, I have made an averaging procedure more or less exactly as the one you have outlined above. Though there is a minor detail which bothers me, because I would rather use something as the trapezoidal integral procedure, i.e. each field is weighted with half the old and half the new time step. As there is N time steps but N+1 fields, the way it is done now, one field has to go - in my case that is the initial conditions. But if you use the trapezoidal integral procedure the time steps in either end of the simulation is used "half" a time step.

My question to you is: Is it possible in the same way as you can get the old time step (runTime.deltaT0().value()) to get the field for the previous time step? I have been looking in the IOObject-source, but haven't been lucky... It aught to be there, since a second order time derivative is available!?!

Thanks for your help and best regards,

Niels

[maka]

I tried to think where in the code we could find an example. I looked in backwardDdtScheme.C . I noticed that there is a member function of GeometricField Class Template here, it seems to return the old field. Did you check that? If it does not work then try to read more in the code to find an example or may be a person with better experience can help. Have a nice day!

Best regards,
Maka.

[ngj]

Thanks, that helped me a lot.
Browsing trough the forum, I found that it is simply to state: "p.storePrevIter()" before the iteration and these old data is then accessed in the averaging procedure by "p.prevIter()".

I simply come to love OF when things become this elegant

When done, the new averaging procedure will be uploaded here.

Best regards

Niels

[ngj]

Hi all

As promised: here is the modified files from lesInterFoam to be used when time averaging the results during runtime using variable time steps.

averagingFiles.tar.gz

I have changed the setup in the averaging procedure a bit. The following changes has been made:

1. Two pieces of information are read from a dict called averagingProperties. These are averagingStartTime which tells when to initialize the averaging. E.g. say that the first 20 seconds of your run is used to start the calculation and make the system reach the state you are interested in. The state startTime to be having the value 20. This furthermore implies that no results are written before time=20! Look in the calculateAverages_TimeStep.H.
The other information is simply called "averaging". This tells which method of averaging to be used. Three options are available:
- 0: No averaging.
- 1: Averaging using current field with current time step.
- 2: Averaging using a trapezoidal approach.

2. The possibility of specifying averaging=0 raises a problem, which I am not capable (due to my lack of C++ experience) to handle. The thing is, that since the IOObjects are declared inside a if-statement, a pointer, UmeanPtr, is declared outside, which then points to the IOObejct declared inside the if-statement and finally the field which is used throughout the rest of the program is set by volVectorField & Umean = *UmeanPtr.
As I understand that references are preferred my question is if there is some way to get rid of both the reference, Umean, and the pointer UmenaPtr (delete?). I would use delete on the pointer, but that would yield a reference to no-where, which is illegal!?! So could anyone help me please (I might not have been utterly clear, but as averaging = 0 no averaging is performed and the fields become unnecessary, and they just take of a lot of memory for no reason at all).

By the way, have fun with the new averaging procedure.

Best regards,

Niels