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

Variable deltaT and functionObjects

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

Reply
 
LinkBack Thread Tools Display Modes
Old   February 5, 2009, 11:55
Default Hi, on cases with variable
  #1
Senior Member
 
Henrik Rusche
Join Date: Mar 2009
Location: Braunschweig, Niedersachsen, Germany
Posts: 274
Rep Power: 8
henrik is on a distinguished road
Hi,

on cases with variable time stepping, I noticed that fvc::DDT and fvc::ddt evaluate to different values if called at the top level or within a function object.

I believe this is due to the fact that the time step is changed BEFORE runTime++ is called

# include "setDeltaT.H"
runTime++;

Changing the time step AFTER runTime++ works, but is only a proof concept rather than a solution.

My suggestion is to move the execution of function objects into runTime.write(). It sounds like the right place afterall. I am aware that this risks that users might disable or call function objects more than once by playing with runTime.write(). However, the latter could be dealt with ...

Is there a some other reason why the function objects are executed in runTime++?

Henrik
henrik is offline   Reply With Quote

Old   February 6, 2009, 07:06
Default Hi Henrik, function objects
  #2
Senior Member
 
Eugene de Villiers
Join Date: Mar 2009
Posts: 724
Rep Power: 11
eugene is on a distinguished road
Hi Henrik,

function objects are constructed when they are first called. In other words, the first runTime++ call includes the function object constructor. If you delay the first call to the function object to write(), then any regIOobjects created by the function object will not be available in the main section of the code which is unacceptable. Unfortunately, function objects cannot be constructed at the same time as runTime, because many function objects depend on the existence of regIOobjects created in createFields.H

In addition, if you move setDeltaT.H to after runTime++ then the timestep increment will be incorrect for that iteration.

The main advantage of tying function object updates to runTime++, is that it can be done transparently. I.e. most of the existing solvers require no updates to incorporate function object capabilities. While this is acceptable as default behaviour there will clearly be many instances where such a structure is not sufficient to solve the problem - as you (and I!) have discovered. At one stage I had to increment and then decrement time to get the correct behaviour. Not good.

However most of the required structures to make the function objects calls flexible are already in place. All that is required is a new function in Time to disable the default runTime++ behaviour so that no calls to functionObejcts_ is made, which is trivial.

You can then initialise and execute the function objects via the following calls:
Time.functionObjects().start()
and
Time.functionObjects().execute()

Of course this requires modification of the top level code, but you cant make an omelet without breaking some eggs.
eugene is offline   Reply With Quote

Old   February 6, 2009, 07:29
Default Hi Eugene, You raise an int
  #3
Senior Member
 
Mark Olesen
Join Date: Mar 2009
Location: http://olesenm.github.io/
Posts: 774
Rep Power: 17
olesen will become famous soon enough
Hi Eugene,

You raise an interesting point.
If functionObjectList had a enum (eg, OFF, ON, ON_DEMAND) instead of bool execution_, this might do the trick. What do you think?
olesen is offline   Reply With Quote

Old   February 6, 2009, 08:57
Default Hi, @Eugene: a) Why woul
  #4
Senior Member
 
Henrik Rusche
Join Date: Mar 2009
Location: Braunschweig, Niedersachsen, Germany
Posts: 274
Rep Power: 8
henrik is on a distinguished road
Hi,

@Eugene:

a) Why would you create objects in a function object and use in the top level? Anyway, such situation should be handled very differently - as Henry noted in Berlin.

b) I know my options - including the nasty ones, but I am looking for a general solution that enables all of us work without hacking the code too much.

@Mark:

Another alternative would be to have a second member that is called when runTime.write() is executed. Make is virtual with an empty default and nobody gets harmed.

Henrik
henrik is offline   Reply With Quote

Old   February 6, 2009, 09:14
Default There is another good reason t
  #5
Senior Member
 
Henrik Rusche
Join Date: Mar 2009
Location: Braunschweig, Niedersachsen, Germany
Posts: 274
Rep Power: 8
henrik is on a distinguished road
There is another good reason to call function objects from runTime.write() - You can then access objects that are instantiated within the while (runTime.run()) loop.
henrik is offline   Reply With Quote

Old   February 6, 2009, 10:00
Default Hi Mark, As always you mana
  #6
Senior Member
 
Eugene de Villiers
Join Date: Mar 2009
Posts: 724
Rep Power: 11
eugene is on a distinguished road
Hi Mark,

As always you manage to come up with a more elegant solution! Encapsulation of the functionObject execution rules within the functionObjectList class would of course be preferable. This would also mean you would have a single interface instead of having to add an additional slightly overlapping function to the Time class.

Henrik: function objects are the first operation that is executed by the runTime++ operator. This means that function objects are not called at the beginning of the time step, but rather at the end of the previous time step. This can lead to a lot of confusion. As such it would be inefficient to add a new execution call to write() which usually happens at the end of the timestep as well. However, should the execution of functionObjects in runTime++ be moved to the start of the time step, the addition of a post-execution object to write() makes a lot more sense. One would of course maintain the .start() constructor at its current location, but move the functionObjects_.execute() call to the end of the Time++ scope. You could then add functionObjects_.post() to Time.write().

This would solve the current problem where function objects are not called for the last time-step, which means they cannot be used to update result fields for the final file write.
eugene is offline   Reply With Quote

Old   July 22, 2009, 03:52
Default
  #7
Senior Member
 
isabel
Join Date: Apr 2009
Location: Spain
Posts: 167
Rep Power: 7
isabel is on a distinguished road
Do you know what the line at the end of the solvers means: ?

return(0);
isabel is offline   Reply With Quote

Old   July 22, 2009, 04:11
Post
  #8
Senior Member
 
Henrik Rusche
Join Date: Mar 2009
Location: Braunschweig, Niedersachsen, Germany
Posts: 274
Rep Power: 8
henrik is on a distinguished road
Isabel,

not quite sure how your question is related to the topic of this thread.

But here is the answer:

Code:
return(0)
exists the "main" function and returns the error code to the operating system. See also main's definition:

Code:
int main(int argc, char *argv[])
{
    // do something
}
There are special variables in the various Linux-shells to pick the return-value up.

Henrik
henrik is offline   Reply With Quote

Old   July 22, 2009, 04:11
Default
  #9
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,803
Rep Power: 38
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by isabel View Post
Do you know what the line at the end of the solvers means: ?

return(0);
Basically it means: "pick up a book about C++"

Sorry if this answer sounds awfully rude, but I think that basic questions about C++ are out of place in the Bugs forum
gschaider is offline   Reply With Quote

Reply

Thread Tools
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 On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Collection of simple functionObjects gschaider OpenFOAM 48 July 31, 2014 10:06
InterFoam stops after deltaT goes to 1e14 francesco_b OpenFOAM Running, Solving & CFD 8 July 31, 2013 02:29
OF15 functionObjects do not read LESProperties for incompressible flows aunola OpenFOAM Bugs 1 September 28, 2008 17:18
How does deltaT enter in icoFoam nadine OpenFOAM Running, Solving & CFD 0 July 24, 2008 09:15
How can I write and display div(gradT)=deltaT= d2/ Rid Main CFD Forum 0 February 1, 2006 22:13


All times are GMT -4. The time now is 20:12.