Wrong write time for functionObjectProperties in OpenFOAM.com

[MakisH]

Issue reported by @derekrisseeuw, affecting at least OpenFOAM+ v1712 and v1806, but not affecting OpenFOAM 5.x or 6.

tl;dr: Empty entries in the results output are shown as "flickering" animation in ParaView.

The problem occurs when running a coupled implicit simulation where the openfoam write interval is larger than the coupling timestep. OpenFOAM will not only write a time at the defined 'write interval', but also at: time = write interval - coupling time

The only field that is written that time is uniform/functionObjects

Which contains the attached file, with no further information.

In terms of simulation this does not pose a problem, but for postprocessing it can be inconvenient. Also, I am not sure where this functionobject is written, but the fact that the time there is not updated might also be incorrect.

I actually first noticed this problem when running the CHT tutorial. Here the coupling time is 0.01s, and the writeInterval is 0.2s. Therefore I have timefolder 0, 0.19, 0.2, 0.39, 0.4, ... etc.

Even if this seems to be version-specific, maybe there is something wrong in the adapter, as well.

[MakisH]

Some observations, while I am trying to fix this:

• This only occurs in implicit coupling and any simulation, leading to "blinking time animation" effect in ParaView.
• The "weird" additional file is [time]/uniform/functionObjects/functionObjectProperties. In the heated plate tutorial, the weird file is created for time 0.19, while the normal write is at 0.20.
• This only occurs for openfoam.com, due to this commit from 10/2015.

In case you cannot acccess their GitLab repositories, the key method is Foam::functionObjectList::createStateDict() in the file src/OpenFOAM/db/functionObjects/functionObjectList/functionObjectList.C. Compare also the method Foam::Time::run() between .org/.com. If I understand correctly, they want to keep track of any changes in the configuration of the functionObjects during the simulation, making such a file necessary. However, I still have to understand why it is written at the wrong time in our case.

Commenting out this line didn't help:

openfoam-adapter/Adapter.C

Line 419 in df2e48d

const_cast<Time&>(runTime_).writeNow();

Edit: Here are the respective Release Notes of OpenFOAM v3.0+. See the section "Function objects updates".

[MakisH]

As Derek mentioned, the additional file is written at time = write interval - coupling time step. The time is not dependent on the solver time step. It is also written at the normal time.

Apparently, this file is only written at the last coupling time step before writing (and at the times it is expected to be written). I was looking at the files during the simulation.

Consider the heated plate tutorial, with implicit coupling, and the following time steps:

• solver's time step: 0.001s
• coupling time step: 0.01s
• write time interval: 0.1s

While the time directories 0 0.2 0.4 0.6 0.8 1 are expected, the directories 0 0.19 0.2 0.39 0.4 ... 0.99 1 are written.

I guess that at the coupling time step from t=0.199 to t=0.20 (or maybe t=0.20 to t=0.201), OpenFOAM enables a writeTime or similar switch. After reloading the checkpoint and the time value to t=0.19 with our hacky approach, the functionObjectProperties file is written at t=0.19. This must be the beginning of the solver's time step from t=0.190 to t=0.191.

Keeping in mind that the function object is technically triggered at the beginning of the next time step, instead of the end of the current one, I am pretty sure the problem is in this series of events. I will look at it again later. The answer lies somewhere in Foam::Time::run() or in preciceAdapter::Adapter::execute().

[MakisH]

Additional thoughts and observations:

• The following line is the cause that functionObjectPropertiesis also written at the normal times. If we ommit this line, it is only written at time = write interval - coupling time step.

openfoam-adapter/Adapter.C

Line 419 in df2e48d

const_cast<Time&>(runTime_).writeNow();

• Ommiting reseting the time "bypasses" the problem:

openfoam-adapter/Adapter.C

Line 702 in df2e48d

const_cast<Time&>(runTime_).setTime(couplingIterationTimeValue_, couplingIterationTimeIndex_);

This is of course undesired and wrong, but it supports my aforementioned theory.

• Apart from this strange object, everything else is written when we want to (temperature, velocity, etc). Therefore, I start thinking that this may be an issue of inconsistency in OpenFOAM. But usually this is not the case.

[MakisH]

I think I found the speciality of this object, in the method Foam::functionObjectList::execute():

     // Force writing of state dictionary after function object execution
     if (time_.writeTime())
     {
         label oldPrecision = IOstream::precision_;
         IOstream::precision_ = 16;
 
         stateDictPtr_->writeObject
         (
             IOstream::ASCII,
             IOstream::currentVersion,
             time_.writeCompression(),
             true
         );
 
         IOstream::precision_ = oldPrecision;
  }

So, the series of events is the following:

1. t = 0.20
2. runTime.run(), which triggers the adapter's execute()
3. Our execute() at some point reloads the time to t = 0.19, reads the coupling data, adjust the time step, and lets the solver continue
4. After all these steps, Foam::functionObjectList::execute() sees that time_.writeTime() is true and writes the functionObjectProperties state dictionary.

Two cross-related questions:

A. Why, after we reset the time, time_.writeTime() is true? Can we force-set it to false?
B. Why is functionObjectProperties written at t=0.19 (which is not write-time) and not at t=20 (which is)?

[MakisH]

I give up for now, as any solution for this would again be quite hacky. I think we are writing results correctly and we know the specific reason that only this object is written out of place. This only affects some versions of OpenFOAM and this file seems to be useless in most of the cases.

I suggest the following workaround for our tutorial scripts:

# Delete all [case]/[time]/[uniform]/functionObjects directories
rm -rfv */*/*/functionObjects

# Delete all empty directories
find . -type d -empty -delete

@derekrisseeuw what do you think of this workaround?

Apparently, paraFoam uses any directory with a numerical value as name to add time stamps. Or maybe the issue is that ParaView itself needs an option to only consider non-empty time sets when plotting a specific variable. I will open an issue/PR for this upstream.

[derekrisseeuw]

This could work, but only for runs which don't use any other function objects.

I used a similar script
removeObsoleteFolders.sh in my tutorial cases which is called automatically after the simulation. This file removes all the time folders which don't include a U file, since every simulation with FSI would save the velocity field.

[MakisH]

This could work, but only for runs which don't use any other function objects.

Do you have any example in mind where this could break? Maybe deleting all the functionObjects directory is overkill, deleting just the functionObjectProperties would be enough. For all the tutorials we have, it is empty (and it doesn't exist for the OpenFOAM Foundation versions).

To be honest, I have not really understood what this dictionary is meant for, as I have not encountered it in practice.

I think I will replace the removeObsoleteFolders.sh script with this, as more targeted and general (works also for laplacianFoam, for example).

[MakisH]

I actually think your script is better for our use case. I extended it so that it also looks for T and to not delete the 0.orig directories.

I consider this closed, as soon as the respective commit gets merged into master.

[precice-bot]

This issue has been mentioned on preCICE Forum on Discourse. There might be relevant details there:

https://precice.discourse.group/t/openfoam-adapter-branch-for-version-8-and-solution-frequency/537/2