Calculation of Averages in lesInterFoam Erroneous Procedure

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

 April 9, 2008, 04:45 Hi all I have been looking #1 Senior Member   Niels Gjoel Jacobsen Join Date: Mar 2009 Location: Deltares, Delft, The Netherlands Posts: 1,759 Rep Power: 29 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.

 April 9, 2008, 07:29 This is true also in ChannelOo #2 Senior Member   Maka Mohu Join Date: Mar 2009 Posts: 305 Rep Power: 11 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.

 April 9, 2008, 07:33 An after thought: in case of c #3 Senior Member   Maka Mohu Join Date: Mar 2009 Posts: 305 Rep Power: 11 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.

 April 14, 2008, 12:11 Hi Maka Thanks for the insi #4 Senior Member   Niels Gjoel Jacobsen Join Date: Mar 2009 Location: Deltares, Delft, The Netherlands Posts: 1,759 Rep Power: 29 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.

 April 15, 2008, 02:57 I tried to think where in the #5 Senior Member   Maka Mohu Join Date: Mar 2009 Posts: 305 Rep Power: 11 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.

 April 15, 2008, 06:03 Thanks, that helped me a lot. #6 Senior Member   Niels Gjoel Jacobsen Join Date: Mar 2009 Location: Deltares, Delft, The Netherlands Posts: 1,759 Rep Power: 29 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.

 April 15, 2008, 13:21 Hi all As promised: here is #7 Senior Member   Niels Gjoel Jacobsen Join Date: Mar 2009 Location: Deltares, Delft, The Netherlands Posts: 1,759 Rep Power: 29 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.

 Thread Tools Display Modes Linear Mode

 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 OffTrackbacks are On Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post Ryan FLUENT 3 February 8, 2008 16:55 smillerhh FLUENT 1 November 8, 2006 08:54 vaishali FLUENT 0 August 13, 2006 13:21 zonexo Main CFD Forum 9 July 10, 2006 12:14 John McKelliget FLUENT 0 December 13, 1999 10:39

All times are GMT -4. The time now is 06:35.