The perpendicular-flap model using OpenFoam

I am a newbie to OpenFoam. I am posting here to check if there is any naive issue for the following problem:

  1. We are developing a coupling functionality using Precice. We want to run some benchmark models, for example the perpendicular-flap model. Our solver handles the solid and OpenFoam handles the fluid. Precice handles the coupling between them.
    https://github.com/precice/tutorials/tree/master/perpendicular-flap

image

  1. OurSolver-Precice-OpenFoam is running. But from the very beginning, OpenFoam sends the following force (arrows in the following figure) to our solver. Especially, the green arrow and the red arrow on the top of flap are pointing towards the upstream. They caused weird deformation of the flap.
    Intuitively, they should point to the downstream.
    I wonder roughly speaking, if you have any suggestion on this issue?
    My understanding of the the perpendicular-flap model is that the OpenFoam solver should be pimpleFoam:

image

  1. Internally, we have a dummyfluid model, OurSolver-Precice-dummyFluid. The dummyfluid only sends back a constant force on the front surface as below. This models works good.
    image

Thank you
Hongwu

I guess that you may use different reference systems (x,y,z).
Try exporting the preCICE meshes and visualizing them in ParaView, maybe you find out that they are geometrically not fitting:

Hi, Makis,
Thanks a lot. it is a good point. I attached the exported mesh files here. It appears the openFoam mesh/nodes is/are very coarse. There are only 33 nodes in openFoam VS the 494 solid nodes. And the openFoam nodes are located only in the middle of the flap/fluid-channel. I am still learning how to use ParaView. I wonder if there is any obvious mistake.

Thanks again
Hongwu

image

exportPreciceMesh.zip (2.8 KB)

The orientations seem to be fine, but all data values are zero. Is this over all timesteps? Do you actually write data to preCICE?



Hi, Makis,
Thanks a lot for your help. The zeros are at the beginning of the calculation, i.e. zero forces and zero displacements are exchanged between the 2 participants. To show the exchanged non-zero data, for both participants, I set <export:vtu every-iteration=“true” />. The attached exportPreciceMeshEveryIter.zip contains 5 files:

  1. precice-config.xml (it is almost the same as the original file from your tutorial of perpendicular-flap)
  2. openFoam log file: openfoam.log
  3. our solver log file: os.log
  4. participant openfoam .vtu files: Fluid-Mesh-Fluid.tar.gz (contains 6 files)
  5. participant our solver .vtu files: solidinterface.tar.gz (contains 127 files)

One strange thing is on the openfoam .vtu files:

  1. Fluid-Mesh-Fluid.it2.vtu shows the max “Force” is about 109.727.
  2. SolidInterface-Fluid.it2.vtu shows the max “Force” is about -9643.34.
    I wonder how Precice maps OpenFoam forces from “Fluid-Mesh” onto “SolidInterface” in such as way?
    If we check from our solver side, for example SolidInterface-OptiStruct.it62.vtu, it also shows this large “Force”.

From the log files, we can see that the time-window-size is 0.01 and there are 2 Precice iterations already for this 1st time window (implicit coupling). For each Precice iteration, our solver has about 60 its own iterations. The coupling calculation errors out at the end because of the distorted solid element which makes our own solver’s time increment size tend to zeros.

Thanks again
Hongwu

exportPreciceMeshEveryIter.zip (536.5 KB)

Hi, Makis,

Actually, for the previous runs I showed here, I changed to . I don’t know exactly what “Determines the spatial dimensionality of the configuration” means here.

But if I ran the original , I got the following error:

Thanks
Hongwu

Are you using preCICE in 2D or 3D mode? Check the beginning of your precice-config.xml.

These RBF errors referring to dead-axis usually mean that you give two layers of nodes (e.g., front and back in an OpenFOAM simulation. Remember that OpenFOAM is 3D, so to simulate such 2D problems, you need to only give one plane to preCICE.

Check also your solver for the mesh you are defining.

And try to visualize both meshes from your solvers (as I did with the preCICE exports above) and see that they are geometrically in the same location, lengths, etc.

The tutorial example originally uses solver-interface dimensions=“2”. I want do the simulation in 3D. so I changed it to solver-interface dimensions=“3”. I think both OpenFoam and our solvers are 3D solvers.

Probably this is the problem: the OpenFoam has only one layers of nodes. How can I change OpenFoam to have two layers of node, i.e. front and back, to do a 3D simulation?

Dose your original tutorial example “perpendicular-flag” work if solver-interface dimensions=“2” is changed to “3”? Or in another words, does calculix support dimensions=“2” such that locations=faceCenters?

If I understand correctly, dimensions=“2” means that there will be one layer in the z-direction. And both participants for FSI need to project their solutions onto the same x-y plane. Then, Precice will do the mapping within the x-y plane since both participants can have different meshing on the x-y plane, right?

locations = faceNodes is not supported for FORCE according to the following error:
—[precice] I am participant “Fluid”
→ FOAM Warning :
From void adapterInfo(std::string, std::string)
in file Utilities.C at line 50
Error (deferred - will exit later) in the preCICE adapter:
Error in the preCICE adapter:
“locations = faceNodes” is not supported for the data “Force”. Please select a different location type, a different data set or provide additional connectivity information.

If you want to simulate a 3D problem, then you also need to provide more cells per z-direction.

See the configuration of the 3D FSI example from the OpenFOAM-preCICE paper (download the case files): OpenFOAM-preCICE: Coupling OpenFOAM with External Solvers for Multi-Physics Simulations | OpenFOAM® Journal

The adapters support 2D modes (they read the dimensions from preCICE), and then only give one layer of nodes. But both OpenFOAM and CalculiX are 3D solvers.

If you want to use the RBF mapping with 3D data that has duplicate layers (pseudo 2D), then you need to specify a dead axis: Mapping configuration | preCICE - The Coupling Library

The usual OpenFOAM solvers store the force on cell centers, that’s why we only support face centers.

I am not sure I understand 100% (a bit tired at the moment), but yes, correct.

Pseudo 2D is what I want. I will try that.

Our case is a general 3D coupling, i.e. 3D data that has duplicate layers (pseudo 2D).

rbf with z-dead doesn’t work for me. I tried both dimension=“2” and “3”. I also tried both z-dead=“0” and “1”.

Is maybe the distance between the two layers in the z-direction too big compared to the cell size in the active planes?

It appears the openFoam mesh/nodes is/are very coarse. There are only 33 nodes in openFoam VS the 494 solid nodes

From this thread I learned that for a conversative mapping the fluid mesh should be finer than the solid mesh, otherwise it leads to instabilities: Spatial oscillations occur when using conservative interpolation from coarse to fine mesh

Did you try to make the fluid mesh finer?

1 Like

This mesh is the mesh given by Precice Tutorial of Perpendicular Flag, “fluid-openfoam” co-simulating with “solid-calculix”. I think Precice team has successfully run this openfoam-calculix. The openfoam mesh seen in paraView is:
image

The calculix mesh seen in our view is:

I don’t run Precice Tutorial of Perpendicular Flag using fluid-openfoam and solid-calculix by myself. Our idea is to replace solid-calculix with our own solver adapter we developed.

But I just ran it using fluid-openfoam and solid-openfoam as below. But apparently this mesh for the solid is much coarser than the mesh for the solid-calculix.

The solidForce is not symmetric on the front surface and the back surface for the flap. Is this a concern ? When I ran this tutorial, I changed dimensions=“2” to “3” and didn’t change anything else. And the results look good. The rbf-thin-plate-splines mapping works well here.

Hi @hongwuw :wave:

Would implementing a 2D mode in your solid adapter be an option? For quasi-2D cases.
Meaning that if the preCICE dimension is 2, you only give 2D vertices (x and y) to preCICE and do the averaging in z etc. always yourself in the adapter.

The CalculiX adapter does the same:

It is always tricky to have a well-defined and well-conditioned 3D mapping problem for a quasi-2D case. It is possible, but you need to carefully define the meshes in the third direction in such a case.

Hi, @uekerman,

thanks a lot for your information. I thought about the possible Precice 2D and 3D differences. If we use 3D models and fix the z direction dof, the solid would be a plain-strain condition while for a simple Newtonian fluid, there is no Poisson effect. For 2-layes of nodes in z direction, we need to project the 2 layers solutions onto a plane first (like what you said of averaging the 2 layers). After we are on the same 2D plane, we can do projections of fields on this plane from solid to fluid or vice versa. So I guess that Precice dimesions=“2” requires the fluid/solid solvers to pass the reduced solutions of 2 dimensions for psuedo-3D. We don’t have this yet. But thanks for your confirmation.

Hongwu

I used the mesh in your solid-openfoam directory as the mesh for our solver. And I used nearest-neighbor mapping. Then we can get good results as below.

The following is the comparison of the flap tip between your results and ours. The left figure shows yours result in your images directory. The blue curve in the right figure is our solver’s result (as your can see, I tried to make the Y scale the same). The red curve in the right figure is the run I made by using your solid-openfoam directory. I am not sure why this red curve is off from other results.