|
| 1 | +--- |
| 2 | +title: Flow over heated plate nearest projection |
| 3 | +permalink: tutorials-flow-over-heated-plate-nearest-projection.html |
| 4 | +keywords: OpenFOAM, nearest-projection, CHT |
| 5 | +summary: This tutorial introduces an example simulation setup for a nearest-projection mapping. At the moment, it only contains an example with the OpenFOAM adapter. The demonstrated "flow over a heated plate" scenario is exactly the same as in the `buoyantPimpleFoam-laplacianFoam` tutorial. |
| 6 | +--- |
| 7 | + |
| 8 | +## Setup |
| 9 | + |
| 10 | +The setup is exactly the same as described in our [flow-over-heated-plate tutorial](tutorials-flow-over-heated-plate.html). |
| 11 | + |
| 12 | +## Available solvers |
| 13 | + |
| 14 | +Fluid participant: |
| 15 | + |
| 16 | +* OpenFOAM (buoyantPimpleFoam). For more information, have a look at the [OpenFOAM adapter documentation](adapter-openfoam-overview.html). |
| 17 | + |
| 18 | +Solid participant: |
| 19 | + |
| 20 | +* OpenFOAM (laplacianFoam). For more information, have a look at the [OpenFOAM adapter documentation](adapter-openfoam-overview.html). |
| 21 | + |
| 22 | +The solvers are currently only OpenFOAM related. For information regarding the nearest-projection mapping, have a look in the [OpenFOAM configuration section](adapter-openfoam-config.html). |
| 23 | + |
| 24 | + |
| 25 | +## Running the Simulation |
| 26 | + |
| 27 | +Open two separate terminals and start each participant by calling the respective run script. |
| 28 | + |
| 29 | +``` |
| 30 | +cd fluid-openfoam |
| 31 | +./run.sh |
| 32 | +``` |
| 33 | +and |
| 34 | +``` |
| 35 | +cd solid-openfoam |
| 36 | +./run.sh |
| 37 | +``` |
| 38 | + |
| 39 | +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. |
| 40 | + |
| 41 | +## Changes in the Simulation Setup |
| 42 | + |
| 43 | +As we are defining two meshes for each participant, we need to define them in the `precice-config.xml` and `preciceDict` configuration files. Additionally, we need to enable the `connectivity` switch for the adapter. |
| 44 | + |
| 45 | +### Changes in `precice-config.xml` |
| 46 | +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: |
| 47 | +``` |
| 48 | +<mesh name="Fluid-Mesh-Nodes"> |
| 49 | + <use-data name="Temperature"/> |
| 50 | +</mesh> |
| 51 | +<mesh name="Solid-Mesh-Centers"> |
| 52 | + <use-data name="Temperature"/> |
| 53 | +</mesh> |
| 54 | +``` |
| 55 | +All further changes follow from this interface splitting. Have a look in the given config files for all details. |
| 56 | + |
| 57 | +### Notes on 2D Cases |
| 58 | + |
| 59 | +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. |
| 60 | + |
| 61 | + |
| 62 | +## Post-processing |
| 63 | + |
| 64 | +Have a look at the [flow-over heated-plate](tutorials-flow-over-heated-plate.html) tutorial for the general aspects of post-processing. |
| 65 | +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 `precice-config.xml`. |
| 66 | +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: |
| 67 | + |
| 68 | + |
| 69 | + |
| 70 | +Note: 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. |
| 71 | + |
| 72 | +{% include disclaimer.html content="This offering is not approved or endorsed by OpenCFD Limited, producer and distributor of the OpenFOAM software via www.openfoam.com, and owner of the OPENFOAM® and OpenCFD® trade marks." %} |
0 commit comments