The setup is exactly the same as described in our flow-over-heated-plate tutorial.
- OpenFOAM (buoyantPimpleFoam). For more information, have a look at the OpenFOAM adapter documentation.
- OpenFOAM (laplacianFoam). For more information, have a look at the OpenFOAM adapter documentation.
The solvers are currently only OpenFOAM related. For information regarding the nearest-projection mapping, have a look in the OpenFOAM configuration section.
Running the Simulation
Open two separate terminals and start each participant by calling the respective run script.
cd fluid-openfoam ./run.sh
cd solid-openfoam ./run.sh
You can also run OpenFOAM in parallel by
./run.sh -parallel. If you are using OpenFOAM v1712 / 5.x or older have a look in the
fluid-openfoam/system/controlDict file and set the appropriate solver name.
Changes in the Simulation Setup
As we are defining two meshes for each participant, we need to define them in the
preciceDict configuration files. Additionally, we need to enable the
connectivity switch for the adapter.
In order to map from face nodes to face centers, both meshes need to be specified. The nodes-based mesh uses the write data and the centers-based mesh uses the read data. Have a look in the given
precice-config.xml in this tutorial. Example:
Temperature is calculated by the
Fluid participant and passed to the
Solid participant. Therefore, it is the write data of the participant
Fluid and the read data of the participant
Solid. This results in the following two meshes for this data:
<mesh name="Fluid-Mesh-Nodes"> <use-data name="Temperature"/> </mesh> <mesh name="Solid-Mesh-Centers"> <use-data name="Temperature"/> </mesh>
All further changes follow from this interface splitting. Have a look in the given config files for all details.
Notes on 2D Cases
From the preCICE point of view, the simulation here is in 3D, as opposed to the original 2D case, as is often the case with 3D solvers (such as OpenFOAM). In such cases, we recommend keeping the out-of-plane thickness of the domain small and comparable to the in-plane cell size. Otherwise, the face centers will have a large distance to the face nodes, which might trigger a preCICE warning and preCICE may even filter out one of the meshes, especially in parallel simulations.
Have a look at the flow-over heated-plate tutorial for the general aspects of post-processing.
Since we now defined mesh connectivity on our interface, we can export the coupling interface with the tag
<export:vtk directory="preCICE-output" /> in our
Visualizing these files (e.g. using ParaView) will show a triangular mesh, even though you use hexahedral meshes. This has nothing to do with your mesh and is just caused by the way the connectivity is defined in preCICE. As described above, the function
setMeshTriangles is used to define the connectivity. Hence, every interface cell/face is represented by two triangles. The following image should give you an impression of a possible triangulated coupling mesh, which consists purely of hexahedral cells:
Connectivity is defined on meshes associated with mesh nodes, which are named respectively e.g.
Fluid-Mesh-Nodes. In this case, you could directly see the interface without applying filters by loading the
.vtk files. In order to visualize additionally center based meshes, where no connectivity is provided, select a Glyph filter in ParaView. Furthermore, it makes a difference, on which participant the
<export... tag is defined in your
precice-config.xml file. Each participant exports interface meshes, which he provides or receives. The receiving participant filters out mesh parts that it does not need (for the mapping). Hence, a received mesh might look incomplete.