[henrik]

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

[eugene]

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.

[olesen]

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?

[henrik]

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]

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.

[eugene]

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.

[isabel]

Do you know what the line at the end of the solvers means: ?

return(0);

[henrik]

Isabel,

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

But here is the answer:

return(0)

exists the "main" function and returns the error code to the operating system. See also main's definition:

int main(int argc, char *argv[])
{
    // do something
}

There are special variables in the various Linux-shells to pick the return-value up.

Henrik

[gschaider]

Originally Posted by isabel

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