Hi,
I have a problem regarding the mapping of forces when coupling with OpenFOAM. I don’t get how it works. I was thinking that on the structure side I should receive nodal forces. I am not a CalculiX expert and I am not able to read what it uses as loads. I Built a different adapter and used it with the vertical flap tutorial. My adapter uses nodal forces. Displacements are consistent within the solid and the fluid mesh, while with my configurations the forces are not. I made an experiment writing a dummy solid adapter which imposes the movement of the mesh and reads the nodal forces. The case is like this:
which are of course wrong. Nevertheless the mapping is right on the displacement side: if I impose a mesh movement the displacement of the two meshes are coherent. Is that I read cell forces? Or is it that the config file is wrong? precice-config.xml (3.6 KB)
Any help is much appreciated
Claudio
some aspects on forces calculation in OpenFOAM, which might help:
forces are calculated for each cell face, since OF uses finite volume methods, so you get one value, which corresponds to one face
this leads to the fact, that in case of 2d the out-of-plain direction i.e. the mesh ‘thickness’ matters. If your mesh is e.g. 0.1 thick, your forces are scaled by 0.1 as well
forces should be mapped conservative and therefore make sure you treat them in a conservative way in your structure solver
I am not sure what you mean by ‘nodal forces’. Forces are calculated from e.g. pressure, which always refers to some reference area, but this should not bother you on the structural solver side.
Hi David,
thank you for your answer. By ‘nodal forces’ I mean forces applied to the nodes of the structure. I understand that forces derive from pressure in the fluid and are calculated at the cell center. The OF side of the coupling defines 2 meshes, one considering cell centers and one considering nodes. If you see the images concerning the patch in the fluid domain regarding the interface I am plotting “node data” in paraFoam and they are pretty reasonable (also consistent with the corresponding “cell data”). The data seem to be calculated exactly at cells and nodes in the OF side of the coupling. The structure side of the coupling uses only node data but they differ from the OF data. I was suspecting that the coupling is between cell-faces and structure nodes: direction="write" from="Fluid-Mesh-Faces" to="Solid-Mesh" constraint="conservative"
but I can’t do direction="write" from="**Fluid-Mesh-Nodes**" to="Solid-Mesh" constraint="conservative"
Claudio
No, you can’t do that, because the node mesh is just used for the deformation and not for anything else in OpenFoam.
Do these data correspond now to different interface meshes exported using preCICE or do you just select different representations in paraView? What paraView shows you, when you select ‘node data’ for a ‘cell related’ data set is an interpolation done by paraView itself.
Yes, that is right, we map cell-face forces on the nodes and they might differ depending on different mesh resolutions and your selected mapping scheme, but your results look rather wrong.
How do you visualize your preCICE exported meshes? Could you apply a glyph filter on the node data? In this case, you can exactly see, where data is available and figure out, what might be wrong.
The data I plotted derive directly from paraview. I am not computing anything, they are just in the paraview output for the different patches, I agree that they should be paraview interpolations. They look pretty reasonable. I can extract the data on the Precice meshes (force on cell centers on the fluid side and forces on the nodes at the solid side) and the error in the mapping is clear:
See the images above. They are the Delauney surfaces of the structural mesh and the fluid cell centers. The mesh nodes of the structural mesh and the mesh of the fluid nodes are the same. The elements of the mesh with the fluid cells are the centers of each rectangle and the delaunay 2D surface results in a flat surface. The fact that the full-scale value is the same makes me think that data aren’t mapped from cells to nodes. I thought that Precice would take care of the mapping considering cells-to-nodes conversion. Should I do it myself? When coupling with SU2 directly receive node data, that is why I considered node data. Besides, If I receive cell data, the number of elements would differ.
Claudio
I agree there is some inconsistency.
Could you do the following, to see better, what is going on here:
add the <export-vtk…> tag in your precice-config
load the .vtk files into e.g. paraview and apply a glyph filter.
As a result, you can see the data precice gets form each participant and which data points are used during simulation.
precice doesn’t care, where your data locations are derived from i.e. faces or nodes. Values are just mapped conservative or consistent depending on your config.
Hi David,
Thank you for your suggestions. The images I was plotting were exactly the vtk files exported by PreCICE and loaded in paraview with Delaunay 3D filter.
I think I have found my mistake. The problem was due to a wrong setting in the convergence parameters for the forces. This is the reason why the solution converged too early to a wrong solution.
After that I computed the resultant forces and moments in OpenFOAM and on the structural side and they coincide.
Claudio
If I understood it correctly, the forces on the structure side must be distributed load. Therefore the nodal force received from OpenFOAM shall be used to integrate the surface load, much like how you treat the distributed load on the beam.
Hi @vryy, this depends on the structural solver. In my case I was using a solver which accepts forces on the nodes of the interface. The OpenFOAM adapter can send forces on cell centers or stresses, as far as I know. I needed to map the forces at cell centers with to the nodes.
It actually works: the goodness of the mapping depends on the convergence parameters and, in my experience, on the mapping configuration. For example rbf-compact-tps-c2 performs better than rbf-thin-plate-splines, greatly reducing the above problem.
Claudio
Hi @Claudio, I understood that mapping from cell center forces to nodes is equivalent with nodal pressure on node. @DavidSCN I need help to understand the forces mapping from OF correctly. For example, if we have a 3-node triangle cell with single integration point, and say the distributed pressure, defined at the cell center, at the fluid side is q. So the force that OF sends to structure side is F=qA or F=q?
let’s first agree on the terminology: by face centers we refer to the center of each cell on the coupling interface. By nodes we refer to the vertices of a coupling surface. Both are in the first place independent of the participant. This said, I don’t understand what you mean by
Do you want to map inside OpenFOAM or do you want to map cell center forces to structural nodes?
Let’s look at your example:
I guess with distributed pressure you mean that the pressure field is a (mostly) continuous field? The fluid load consists of two contributions: the pressure and the velocity gradient (due to friction). Your formula only considers the first contribution here. Also, note that the force is a vector so that we additionally need a normal vector. You can find the actual implementation (which is based on the OpenFOAM force functionObject here: https://github.com/precice/openfoam-adapter/blob/fcfca49c2ccf7a03b5f4a74f5a291e2d4fc90f3d/FSI/ForceBase.C#L156-L209
Still, the location of the load data is associated to the cell center, as you suggested. The load as coupling data comes in two flavors:
Force: integration (your multiplication with A) is performed in OpenFOAM (conservative data mapping, e.g. used by CCX),
Stress: integration is performed on solid side (consistent data mapping, e.g. used by our deal.II solvers).
@DavidSCN it actually helps. Look in dealii adapter it’s clear how forces are read and used. The Calculix adapter is a bit messy and outdated. I noticed that the OF-dealii coupling gives good results when the mapping from Fluid to Solid is conservative, and is totally off if it is consistent and the other side is conservative. Is the rule of thumb that the map from fine grid to coarse grid must be always conservative and vice versa?
Where have you noticed such a thing? The conservative Force reading has just been added for compatibility reasons and is not supported by the non-linear model. If it is totally off, there is probably something wrong in your config. However, there will be a major update today, which should catch any erroneous configuration. So if you still observe such things you should open up an issue.
IIRC your described case should be more accurate with a consistent mapping, since the RBF system is build on the fine mesh. For a conservative mapping, it would be build on the coarse side.
Well, I run exactly the perpendicular-flap example of the tutorial and it used conservative mapping on solid part. precice-config.xml (2.4 KB)
Maybe you’re right that there is something wrong in the config. I tried to modify the perpendicular-flap example using consistent mapping but without success. Can you help to look on this? OpenFOAM-dealii_consistent-neightbour-mapping.txt (80.2 KB) (This file is zip, please change extension from .txt to .zip)
However, there will be a major update today, which should catch any erroneous configuration. So if you still observe such things you should open up an issue
I’m looking forward to that
The conservative Force reading has just been added for compatibility reasons and is not supported by the non-linear model
The case looks fine. If you want to execute it in parallel you need to switch the write-mapping on the other participant (as it is done for the fsi3 tutorial). Still, I don’t get why you consider now these results as “totally off”?!
I think you use already the develop version of the dealii-adapter, so no further updates (we update from develop to master. It would be interesting to know how you evaluate the result quality.
