Getting the exact time steps in OpenFOAM and preCICE

Official adapters and tutorials
1

Hello,

I’m running rather long FSI simulations using OpenFOAM and preCICE. Although I use the adjustableRunTime in the OpenFOAM configuration, OpenFOAM starts to name the solution directories according to an accumulated time step, e.g., 8.100000000001 instead of 8.1. Also, the time precision is with 12 already selected rather high in OpenFOAM. Is there an opportunity to prevent this?
Background: I use a script to postprocess my data and the unexpected naming destroys the functionality of the script.

I also noted that preCICE writes the time to a precision of 16 digits in my watchpoint file. Here, the time is also not exactly the specified time-window-size, i.e., 0.0810000000000001 instead of 0.081. I know that preCICE has the option to specifiy <time-window-size valid-digits="" time-window-size\> in the config file. But what is the impact. Does it just affect the writing of data or could it lead an undesired subcycling of participants due to truncated time-step sizes?

Thanks in advance!

2

Could you please upload your controlDict? Also, which OpenFOAM version are you using?

I assume you are using implicit coupling. When we repeat a timestep, we need to force OpenFOAM to rewrite results, and this may be related. But this behavior could also be version-specific, as there are a few changes in the behavior of function objects in the past few years.

3

The file is essentially very similar to the tutorial files, I’m using OpenFOAM 1912 and yes, the coupling is implicit.

FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    system;
    object      controlDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

// Note: With OpenFOAM v1806 and OpenFOAM 6, the DyM solvers
// were marked deprecated and merged into their respective standard solvers.
application         pimpleFoam;    // OpenFOAM v1806, OpenFOAM 6, or newer
//  application         pimpleDyMFoam; // OpenFOAM v1712, OpenFOAM 5.x, or older

 libs ( "libgroovyBC.so" ) ;

startFrom           startTime;

startTime           0;

stopAt              endTime;

endTime             15;

deltaT              1e-3;

writeControl        adjustableRunTime;

writeInterval       0.1;

purgeWrite          0;

writeFormat         ascii;

writePrecision      10;

writeCompression    off;

timeFormat          general;

timePrecision       12;

functions
{
    preCICE_Adapter
    {
        type preciceAdapterFunctionObject;
        libs ("libpreciceAdapterFunctionObject.so");
    }
}
4

I am not sure I understand the question. You already set a high timePrecision, which is only for the result files. Wouldn’t simply reducing the time precision help? Do you really need to look into so high time precision?

I understand that you have two questions:
First question: Why at high precision you start getting rounding errors. I guess you are operating in the limits of machine precision and after a while, the error starts accumulating. We could analyze all the involved variables in preCICE and the OpenFOAM adapter, but I would not do that unless there is a clear use case.

Second question:

To this, maybe @uekerman knows more. Our XML Reference does not seem to help in this case.

5

Ok, there was a misinterpretation on my side. I thought it would affect the precision of the time handling in general for the whole computation, not for the writing procedure. Choosing a high precision should then prevent inaccuracies.
Lowering it will likely solve the problem here to some extend. Running the simulation longer will lead to the same issue at some time though.

6

This option is too prevent too small timestep sizes when subcycling.

  • Say the time window size is 1.0 and the valid digits is 2.
  • Within one time window, a participant uses the following timestep sizes: 0.5, 0.4, 0.05, 0.045.
  • Then, the accumulated time is 0.995 and the remaining time in the time window 0.005, which is smaller than 0.01 = 10 ^ - (valid digits).
  • Now preCICE does not give back 0.005 as next maximum timestep size, but already advances to the next time window.

Long story short: not the droids you’re looking for. The option has no influence on the writing precision in, for example, the watch point file.

7

Does this also mean that the next coupling time will be at 1.995, or will it happen “normally” at 2.0?

8

Good point. As I see next coupling time will be at 1.995 then.