Provide OpenFOAM consistent output interval

[davidscn]

As discussed, the time output is currently defined by using a fixed number of time steps. This differs from OpenFOAM. @MakisH could you specify, what would be the best solution here/ how it is commonly defined in OpenFOAM?

[MakisH]

In our tutorials, we write every e.g. 0.1s of simulated time (and OpenFOAM will perform a smaller time step just before the write time, so that it writes exactly at that time). For example:

https://github.com/precice/tutorials/blob/b3f92fc54738fd1d006e9ee444d5127b2668cbd5/FSI/flap_perp_2D/OpenFOAM-deal.II/Fluid/system/controlDict#L26-L28

In the same example, deal.II writes every 10 time steps (of 0.01s). Assuming that the time step size remains constant, the two results should be synchronized.

https://github.com/precice/tutorials/blob/b3f92fc54738fd1d006e9ee444d5127b2668cbd5/FSI/flap_perp_2D/OpenFOAM-deal.II/Solid/linear_elasticity.prm#L9-L13

What actually seems to confuse ParaView (5.8.0) is that it reads the actual time from OpenFOAM, but the number of output file from deal.II. So, we essentially would need a way to write the time to the VTK files.

[davidscn]

Hm, we could simply enable synchronization by using openfoams foamToVTK tool, which results in output numbers similar to the one used in deal.II currently, right?

[MakisH]

Why not change the naming in the deal.II adapter?

https://github.com/precice/dealii-adapter/blob/c332050b5770bf99459b8be596fd6e41f3401a26/linear_elasticity/linear_elasticity.cc#L706-L710

Then we don't need the user to do anything and the OpenFOAM part remains consistent with the rest of the tutorials (where we don't see this problem at the moment, but we also don't visualize the structure in ParaView).

[davidscn]

Why not change the naming in the deal.II adapter?

Because this will not work. ParaView just counts the number of vtk files and does not read the actual naming. In our case, the numbering is just the order in which paraView shows the results. Hence, naming a file according to the current time step will not have the effect you are thinking of.

[MakisH]

But in any case, ParaView currently does not have any information about the time of the results. Can't we add this information inside the vtk files?

As I wrote above, there seems to be a way for this:

So, we essentially would need a way to write the time to the VTK files.

[davidscn]

So, deal.ii provides this feature https://www.dealii.org/developer/doxygen/deal.II/structDataOutBase_1_1VtkFlags.html#a8944cf4f29e449a73c11c6f348b86c20 and I just tried it, but similar to an annotation, this just adds the time and cycle as a separate field. We don't get any synchronization here (or I am doing it wrong). Have you just looked yourself or ever tried this?

Let me know, if you want me to push it anyway.

[MakisH]

I don't really have much experience with writing VTK files, but maybe I can prepare some dummy files and see afterwards how we can produce them from deal.II.

This is not a priority in any case. Let's just keep documenting ideas here and we can address this later.

[davidscn]

In case you want to get to know, what vtk (the link you posted) does, it is sufficient to add the following:

diff --git a/linear_elasticity/linear_elasticity.cc b/linear_elasticity/linear_elasticity.cc
index 8be277a..822e4fd 100644
--- a/linear_elasticity/linear_elasticity.cc
+++ b/linear_elasticity/linear_elasticity.cc
@@ -677,6 +677,8 @@ namespace Linear_Elasticity
     // Note: There is at least paraView v 5.5 needed to visualize this output
     DataOutBase::VtkFlags flags;
     flags.write_higher_order_cells = true;
+    flags.time                     = time.current();
+    flags.cycle                    = time.get_timestep();
     data_out.set_flags(flags);

I think another aspect would be to allow the user to specify an absolute time value instead of time step numbers in the parameter files. Should simplify things, right? I thought this was also your initial intention.

[MakisH]

Even though this does modify the VTK files:

# vtk DataFile Version 3.0
#This file was generated by the deal.II library on 2020/7/29 at 12:59:18
ASCII
DATASET UNSTRUCTURED_GRID

FIELD FieldData 2
CYCLE 1 1 int
20
TIME 1 1 double
0.2
POINTS 1350 double

ParaView 5.8 still displays time as 2 for this example (with only the deal.II results loaded):

Any clue why? Does this actually work for you? The solution should be either this or something in this direction anyway.

I think another aspect would be to allow the user to specify an absolute time value instead of time step numbers in the parameter files. Should simplify things, right? I thought this was also your initial intention.

If we want to do things in a general way, yes. The time step size of a structure simulation would probably not adapt over time, so simply improving the VTK writing should be enough.

[davidscn]

Any clue why? Does this actually work for you? The solution should be either this or something in this direction anyway.

This is, what I mentioned above

this just adds the time and cycle as a separate field. We don't get any synchronization here (or I am doing it wrong). Have you just looked yourself or ever tried this?

Maybe it is just possible for visit (where your link points to) and not for paraView. Anyway, I have no idea, how to fix it. OpenFOAM has its own format. I still guess the simplest synchronization would be foamToVTK.

[MakisH]

Then let's leave this open for now. foamToVTK also did not improve the situation in my case.

[davidscn]

foamToVTK also did not improve the situation in my case.

So, you get the synchronization from the Fluid side, since the OpenFOAM vtk files work similarly to the deal.II vtk files with a time index rather than an absolute time value. Therefore, both are numbered with integers.

[davidscn]

@MakisH How to proceed here? Do you expect any change in the deal.II codes?

[uekerman]

Not sure if this is of any help, but for the OpenFOAM-Nutils cases the time sync in vtks work. https://github.com/precice/tutorials/tree/master/CHT/flow-over-plate/buoyantPimpleFoam-nutils

Maybe we could borrow some ideas from there?

[MakisH]

@MakisH How to proceed here? Do you expect any change in the deal.II codes?

If we have a post-processing solution that works (just foamToVTK did not work for me, maybe some ParaView filter that I have not yet discovered?), then it is enough to document it. But yes, if we can "fix" it in the deal.II side, let's do it.