CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Bugs

Calculation of Averages in lesInterFoam Erroneous Procedure

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   April 9, 2008, 05:45
Default Hi all I have been looking
  #1
ngj
Senior Member
 
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Copenhagen, Denmark
Posts: 1,900
Rep Power: 37
ngj will become famous soon enoughngj will become famous soon enough
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
__________________
Please note that I do not use the Friend-feature, so do not be offended, if I do not accept a request.
ngj is offline   Reply With Quote

Old   April 9, 2008, 08:29
Default This is true also in ChannelOo
  #2
Senior Member
 
Maka Mohu
Join Date: Mar 2009
Posts: 305
Rep Power: 18
maka is on a distinguished road
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 is offline   Reply With Quote

Old   April 9, 2008, 08:33
Default An after thought: in case of c
  #3
Senior Member
 
Maka Mohu
Join Date: Mar 2009
Posts: 305
Rep Power: 18
maka is on a distinguished road
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.
maka is offline   Reply With Quote

Old   April 14, 2008, 13:11
Default Hi Maka Thanks for the insi
  #4
ngj
Senior Member
 
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Copenhagen, Denmark
Posts: 1,900
Rep Power: 37
ngj will become famous soon enoughngj will become famous soon enough
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
__________________
Please note that I do not use the Friend-feature, so do not be offended, if I do not accept a request.
ngj is offline   Reply With Quote

Old   April 15, 2008, 03:57
Default I tried to think where in the
  #5
Senior Member
 
Maka Mohu
Join Date: Mar 2009
Posts: 305
Rep Power: 18
maka is on a distinguished road
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.
maka is offline   Reply With Quote

Old   April 15, 2008, 07:03
Default Thanks, that helped me a lot.
  #6
ngj
Senior Member
 
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Copenhagen, Denmark
Posts: 1,900
Rep Power: 37
ngj will become famous soon enoughngj will become famous soon enough
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
__________________
Please note that I do not use the Friend-feature, so do not be offended, if I do not accept a request.
ngj is offline   Reply With Quote

Old   April 15, 2008, 14:21
Default Hi all As promised: here is
  #7
ngj
Senior Member
 
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Copenhagen, Denmark
Posts: 1,900
Rep Power: 37
ngj will become famous soon enoughngj will become famous soon enough
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
__________________
Please note that I do not use the Friend-feature, so do not be offended, if I do not accept a request.
ngj is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Weighted Averages Disagree Ryan FLUENT 3 February 8, 2008 16:55
Radial averages smillerhh FLUENT 1 November 8, 2006 08:54
cicumferential averages vaishali FLUENT 0 August 13, 2006 14:21
Reason for erroneous solution when Re increases zonexo Main CFD Forum 9 July 10, 2006 13:14
Erroneous specific heat John McKelliget FLUENT 0 December 13, 1999 10:39


All times are GMT -4. The time now is 07:21.