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:
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.
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 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:
precice-config.xml (it is almost the same as the original file from your tutorial of perpendicular-flap)
Fluid-Mesh-Fluid.it2.vtu shows the max “Force” is about 109.727.
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.
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.
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:
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.
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.
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.
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.