computational science and engineering (international ... · computational science and engineering...
TRANSCRIPT
Computational Science and Engineering(International Master’s Program)
Technische Universität München
Master’s Thesis
A general OpenFOAM adapter for thecoupling library preCICE
Gerasimos Chourdakis
Computational Science and Engineering(International Master’s Program)
Technische Universität München
Master’s Thesis
A general OpenFOAM adapter for the coupling librarypreCICE
Author: Gerasimos Chourdakis1st examiner: Univ.-Prof. Dr. Hans-Joachim Bungartz2nd examiner: Univ.-Prof. Dr. rer. nat. habil. Miriam MehlAssistant advisor: Dr. rer. nat. Benjamin UekermannSubmission Date: October 29, 2017
I hereby declare that this thesis is entirely the result of my own work except where otherwiseindicated. I have only used the resources given in the list of references.
October 29, 2017 Gerasimos Chourdakis
Acknowledgments
First and foremost, I would like to deeply thank my supervisor, Benjamin Uekermann, forhis support. His vivid interest on the topic and his very helpful advices made my thesis avery pleasant learning experience.
Additionally, I would like to thank Lucía Cheung Yau, whose excellent work I had thechallenging mission to continue. Her aid in the beginning of my Thesis was invaluable. Ialso want to thank Babak Gholami for kindly providing us with the results of Lucía’s thesis,which was written in cooperation with SimScale GmbH.
The tools I used in my thesis, mainly preCICE and OpenFOAM, are developed asfree/open source software. They are also based on other free software projects, includ-ing the Doxygen documentation generator. Projects like these make me feel very glad ofthe free software community and I hope that my contribution will also be useful.
The TUM English Writing Center helped me improve my understanding of the Englishlanguage and the clarity of my prose. I am very thankful for the time they devoted to meduring the Thesis Writers’ Workshop, as well as to our individual appointments.
My Master’s studies were financially aided by a scholarship from the German AcademicExchange Service (DAAD) and I am very grateful of their support.
Finally, I owe my deepest gratitude to my friends and family, whose endless support wascrucial for my studies. Special thanks go to my parents and to my friend Myrto, who werethere when their support was needed the most.
vii
Abstract
Simulating multiple interacting phenomena at the same time can help us predict their effectsmore precisely. It is possible to perform a multi-physics simulation by coupling pieces ofsingle-physics simulation software with preCICE, a free library for black-box, partitionedsurface coupling. An adapter connects a solver to preCICE, allowing preCICE to accessthe required data elements and steer the coupled simulation. Individual solvers of thecomputational fluid dynamics simulation software OpenFOAM have been adapted in thepast, but there is still a need for a flexible adapter that would be ready to work with anyOpenFOAM solver, in order to eliminate the duplication of development effort and improvethe user experience.
This thesis presents a general, solver-agnostic preCICE adapter for OpenFOAM, whichrequires no changes in the individual solvers. The adapter can be loaded at runtime using theexisting controlDict configuration file. A wide variety of standard solvers are supported,while the proposed design makes the adapter compatible with any similar in-house solver.While we focus on conjugate heat transfer, the adapter is extensible to other types ofproblems, such as mechanical fluid-structure interaction.
The adapter is an OpenFOAM function object: a shared library whose methods are calledfrom predefined points in a solver’s code. The boundary conditions are general and do notbind to specific solvers, but support a wide range of compressible or incompressible flowsolvers, as well as basic solvers. The required fields and parameters are drawn from theobject registry or provided in a separate adapter configuration file. This thesis continuesprevious work on solver adaptation to preCICE and the proposed adapter is validatedagainst the (already validated) previous adapters.
ix
Contents
Acknowledgements. vii
Abstract. ix
Contents. xi
1. Introduction. 1
2. Tools . 52.1. preCICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Equation coupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2. Data mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1.3. Communication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.5. Application programming interface. . . . . . . . . . . . . . . . . . . . 132.1.6. Available adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2. OpenFOAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.1. Structure of a solver. . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.2. A language for equations . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.3. Manipulating fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.4. Creating new applications . . . . . . . . . . . . . . . . . . . . . . . . . 212.2.5. Injecting code at runtime: function objects . . . . . . . . . . . . . . . 212.2.6. The registry of objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.2.7. Physical models and solvers of interest. . . . . . . . . . . . . . . . . . 24
3. Conjugate heat transfer. 293.1. Mechanisms of heat transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2. Parameters of heat transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3. Coupling approaches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4. Previous work. 334.1. Available OpenFOAM adapters for preCICE . . . . . . . . . . . . . . . . . . . 33
4.1.1. Previous CHT adapters . . . . . . . . . . . . . . . . . . . . . . . . . . 334.1.2. Previous FSI adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.1.3. Other adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
xi
Contents
4.2. Other approaches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.2.1. MpCCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.2.2. The OpenFOAM CHT solvers. . . . . . . . . . . . . . . . . . . . . . . 384.2.3. SimpleFsi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5. Implementation. 415.1. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.1.1. Objectives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.1.2. Proposed solution and challenges. . . . . . . . . . . . . . . . . . . . . 425.1.3. Reused elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2. The function object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.3. The adapter’s core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.1. Interfaces and Coupling data users . . . . . . . . . . . . . . . . . . . . 435.3.2. Steering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.3.3. Adjusting the solver’s time step . . . . . . . . . . . . . . . . . . . . . . 455.3.4. Checkpointing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.3.5. Error handling and output . . . . . . . . . . . . . . . . . . . . . . . . 47
5.4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.4.1. Activating the adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.4.2. The adapter’s configuration file . . . . . . . . . . . . . . . . . . . . . . 505.4.3. Optional parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.5. The CHT module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.5.1. Coupling data users for CHT . . . . . . . . . . . . . . . . . . . . . . . 515.5.2. Additional parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.6. Designed with extensibility in mind . . . . . . . . . . . . . . . . . . . . . . . . 55
6. Validation. 576.1. Flow over a heated plate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.1.1. buoyantPimpleFoam – laplacianFoam coupling . . . . . . . . . . . . . 586.1.2. buoyantBoussinesqPimpleFoam – laplacianFoam coupling . . . . . . . 616.1.3. buoyantSimpleFoam – CalculiX coupling . . . . . . . . . . . . . . . . . 63
6.2. Tube-and-shell heat exchanger. . . . . . . . . . . . . . . . . . . . . . . . . . 65
7. Conclusions. 69
Appendix. 70
A. Compatible OpenFOAM versions. 71A.1. Porting to a different OpenFOAM version. . . . . . . . . . . . . . . . . . . . 72A.2. Known differences among OpenFOAM versions. . . . . . . . . . . . . . . . . 73
A.2.1. OpenFOAM v5 – OpenFOAM v4 . . . . . . . . . . . . . . . . . . . . . 73
xii
Contents
A.2.2. OpenFOAM v4 – OpenFOAM v3 . . . . . . . . . . . . . . . . . . . . . 73A.2.3. Older versions of OpenFOAM and other variants. . . . . . . . . . . . 74
B. OpenFOAM function objects - details. 75
C. Previous CHT adapters - details. 81C.1. Implementation details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81C.2. Using case files prepared for the old adapters . . . . . . . . . . . . . . . . . . 81
Bibliography. 85
xiii
1. Introduction
Multiple phenomena take place in nature simultaneously, yet we often simulate every prob-lem as if it were driven only by the laws of fluids, the laws of solids, or the laws of chemistry.The moment you turned the previous page, its shape changed and its movement caused aflow of air. This stream may have affected the temperature of your skin, which is contin-uously warmed by the blood flowing underneath. The scientific community has investeddecades in creating a multitude of robust tools that can precisely simulate each individualphenomenon. But composite scenarios like the aforementioned require us to consider allthe dominant phenomena at the same time. One way to do this is to build new, monolithictools for each combination. One alternative is to couple the existing ones, so that they canwork together.
The coupling library preCICE [6.] (Precise Code Interaction Coupling Environment) pro-vides a “black-box” approach to combining simulations that only need to exchange informa-tion on the shared boundaries of their domains. In order to couple two different simulationtools, we need some additional “glue-code”: a preCICE-adapter for each, which enablesaccess to the required data and control elements (Figure 1.1.). For example, preCICE needsto be able to read and write variables on the specified boundaries, as well as to controlthe time step so that both simulations (“participants”) synchronize when required. WhilepreCICE manages more aspects of the coupling, such as the data mapping between non-conforming meshes, the point-to-point communication among the parallel processes, or theactual equation coupling schemes that provide a stable and fast solution, these are invisibleto the adapter.
Figure 1.1.: An overview of the components that form a coupled simulation using a com-putational fluid dynamics (blue) and a computational structure mechanics (or-ange) solver [17.]. An adapter for each solver gets access to the solver’s requiredelements and uses methods from the preCICE library (green). preCICE man-ages the communication between the solvers, the data mapping between theirmeshes and the coupling scheme.
1
1. Introduction
OpenFOAM1. (Open-source Field Operation And Manipulation) is a collection of free
(libre) tools, primarily (but not exclusively) used for Computational Fluid Dynamics prob-lems [20.]. Each “solver” included in OpenFOAM is a stand-alone application that solvesa set of equations on a specified grid. Different solvers may share existing code but theycan vary significantly among one another. The original approach for coupling OpenFOAMsolvers with preCICE [7.] was to couple each solver with its own, special adapter, whichinherited from an abstract adapter class and was tailored to the specific solver. This ap-proach was shown to work and to give good results. Nevertheless, it was not suitable for aproduction environment, since every adapter needed to be maintained separately and newsolvers needed additional work in order to prepare for coupling.
The main example of multi-physics problems that was addressed in the previous work,and which we are also working with, is conjugate heat transfer (CHT). In particular, theair flow above a heated thick plate was simulated as a validation case. For this scenario,we need two different simulations in two domains. In the lower domain, we solve the heat-transfer equations for a solid, whereas in the upper domain, we solve the mass, momentumand heat-transfer equations for a fluid. Before solving the two sets of equations, we need tospecify the temperature or the heat flux on the interface between the two domains. As thetemperature on the interface appears in both sets of equations, we need to make sure thatboth participants are using the same, jointly decided values or sufficient approximations.Moreover, a different number of grid points may exist on the corresponding boundaries ofthe two domains, or they may be located in different positions. Therefore, we need to mapthe nodes of the one domain to the other, without violating the physics of the problem beingstudied. For example, if the interchanged quantity was forces, we would need to ensure thatthe total force on both sides of the interface was the same.
The aforementioned tasks are handled efficiently by preCICE, even for more than twocoupled simulations. Other multi-physics problems targeted by preCICE are, for exam-ple, fluid-structure, fluid-structure-acoustics or fluid-fluid (multi-model) interaction, andother [6., 1.]. While other coupling tools exist, preCICE is free software, offers a wide rangeof features and is not specific to any problem type or solver.
An OpenFOAM adapter for preCICE needs to keep these useful properties: to not bespecific to any solver or problem type. An end user should be able to easily plug-in preCICEinto any OpenFOAM solver, in order to solve any kind of multi-physics simulations thatpreCICE supports. In this thesis we transform the previous set of (validated) adapters forconjugate heat transfer into one flexible adapter that end users will easily be able to use fortheir own needs. Our goal is to create a general adapter that will not depend on the solver,that will require no changes to the solver’s source code and that will be loaded at runtime.We also want an adapter that will be compatible with multiple OpenFOAM versions andvariants.
These goals raise several challenges. First of all, how can we adapt a solver withoutchanging its code? Second, how can we use the same adapter for all the solvers, when the
1Throughout this thesis we refer to https://openfoam.org/.. For more details, see Appendix A..
2
solvers are so different from each other, working with different models and fields? Andfinally, how can we keep the same code working among different OpenFOAM version, whensolvers from different versions and variants are often incompatible? The answer lies deepinside the OpenFOAM class hierarchy, into which we need to dig to identify the commonpatterns between the solvers. By starting from the assumption that no changes in thesolvers are allowed, we can move our attention from the solver, to the underlying elements.
The solution we propose is mainly based on two features of OpenFOAM. The first oneis the OpenFOAM function objects, shared libraries that can be connected to any solver atruntime and get their methods executed during specific phases of a simulation. We buildour adapter as such a function object. Since the function object’s methods need to havea specific public interface, we cannot directly access all the data elements that we wouldlike to. For this, we use another feature, called the registry of objects. We cherry-pickthe objects that we need from the registry, or directly from the solver’s configuration files,without the need for manual configuration. A third aspect of OpenFOAM also affects ourdesign. We found that solvers that could be used in a conjugate heat transfer scenario,are mainly grouped into three categories: compressible, incompressible, and basic solvers.While the implementation differs significantly among the three categories, it is very similarfor solvers of the same category. We take advantage of this classification to support a widerange of solvers with the same code. In the case the adapter fails to put a solver in oneof the above categories, the user can specify this manually. In case a solver uses differentnames for the required fields, these are also configurable.
An adapter that carries the weight of being general already in its name automaticallyraises many questions about its suitability for specific kinds of problems or its compatibilitywith specific solvers. Our approach is to provide a general, solver- and problem-agnosticdesign for the core of the adapter, a core that can be extended to support other problems.“Modules” bundle together the solver-specific operations, providing boundary conditionclasses (“coupling data users”) and managing any problem-specific configuration. We cur-rently provide a module for conjugate heat transfer, allowing the exchange of temperature,heat flux, heat transfer coefficient, and sink temperature. This is the same set of featuresalready provided in the previous CHT adapters [7.], but redesigned to be solver-agnostic.
Our proposed solution was tested against the previous adapters and it was found to bein good agreement with them, producing identical results in most of the cases. Moreover,all the features are now available to every solver, since every solver uses the same adapter.
This thesis does not aim to extend the set of features to other problem types, such asmechanical fluid-structure interaction or acoustics, but to create a solid base that will allowit to be easily extended to any kind of problems. This is the necessary key that unlocksthe potential towards combining OpenFOAM and preCICE for any kind of multi-physicsapplications, without the need to write special code for every OpenFOAM solver.
3
1. Introduction
Structure of the thesisIn the next chapter, we present the two tools that we are working with. Section 2.1. ex-plains the features of preCICE that the adapter needs to support and Section 2.2. gives anintroduction to OpenFOAM, explaining also the function objects, the registry of objects,and the solvers of interest. In Chapter 3., we give a quick recapitulation of conjugate heattransfer, focusing on the terminology that we will use throughout this thesis. Chapter 4.
presents the related work, and Section 4.1.1. focuses on the previous CHT adapters, whichwe based our work onto. The rest of the chapter presents other adapters that influencedour design. Chapter 5. presents the most important elements of the adapter and explainsthe adapter’s configuration file. Chapter 6. proves that the design changes did not affect thenumerical results significantly and shows the range of features that the adapter supports.Chapter 7. summarizes the most important conclusions of this work.
The reader is also encouraged to look at the appendices, as they contain importanttechnical details. Appendix A. is of interest to both users and developers, as it gives anoverview of the supported versions of OpenFOAM and a first step-stone towards portingthe adapter to any other version. Appendix B. helps to understand the implementation offunction objects in more details, an overview of which is given in Figure 2.4.. Appendix C.
presents the previous adapters in more details, highlighting the potential for improvement.It also gives instructions on porting case files prepared for the previous adapters to the newadapter. Finally, the reader is referred to the README.md file that comes with the adapter.That document gives additional information on starting with the adapter, for users anddevelopers.
In case you are already familiar with the conjugate heat transfer and with the tools athand, you are welcome to proceed directly to Chapter 4.. However, when presenting theimplementation at Chapter 5., a basic understanding of the function objects and the objects’registry, presented in Sections 2.2.5. and 2.2.6., is assumed. Chapters 2. and 3. can be read inarbitrary order.
4
2. Tools
In this chapter we present the tools that we are using throughout the thesis. We explainthe preCICE features that the OpenFOAM adapter needs to support, we give a shortintroduction into OpenFOAM, and we present the features of OpenFOAM that we aregoing to use in Chapter 5., namely the function objects, the registry of objects and thesolvers of interest.
2.1. preCICE
preCICE1. is a library that provides all the necessary components to bind multiple tradi-
tional single-physics solvers and create a plug-and-play, partitioned multi-physics simula-tion. It provides numerical methods to couple the individual equations, methods to mapdata between non-matching meshes and methods to enable the (peer-to-peer) communi-cation among the participating processes. preCICE is mainly targeting surface coupling(where the individual simulations affect each other through their shared interfaces) butcomponents of it can also be used for volume coupling [6.].
Being able to interchange the single-physics solvers brings several advantages for the user,as she can immediately work with the tools she trusts, and it provides the flexibility to easilymigrate to newer, better or more suitable solvers. The solvers are treated as “black-boxes”by preCICE, in the sense that it does not need to know anything about their internaloperations. Essentially, preCICE only affects the input and observes the output of theparticipating solvers, without changing the equations that each participant solves or havingany information about them. The required data and control elements are accessed using anadapter, i.e. a “glue code” that attaches to the solvers and allows preCICE to manipulatethe required elements. Because of preCICE’s high-level application programming interface,the changes that are required in the solver’s code are kept to a minimum.
The “black-box” partitioned approach raises some challenges in coupling the individualequations, as no discretization or Jacobian information is known. However, this results inhigher flexibility and lower “time-to-solution”, i.e. the time required for developing the nec-essary components in order to set up a first multi-physics simulation. The extreme oppositeis the fully monolithic coupling approach, in which one multi-physics software solves thecomplete system of equations and is tailored to a specific problem. Both approaches havebeen shown to be appropriate for massively parallel simulations [16.].
1preCICE: http://www.precice.org/..
5
2. Tools
In a preCICE-coupled simulation, the solver processes that participate are distributedand communicate with one another directly, using either MPI or TCP/IP sockets. Thisallows for better performance scalability in comparison to other coupling tools that followthe client-server approach, in which the processes exchange messages through a centralserver instance.
This section summarizes the most important elements of preCICE, as described in itspresentation article [6.].
2.1.1. Equation couplingIn an interface multi-physics coupling, a boundary is shared between different simulations.In order for the simulation to make sense and to be numerically stable, the values of thephysical fields defined or computed on both sides of the interface need to be in agreement.Since the output values of the one simulation are used as input values for the other (and theopposite), an iterative method is required to solve this fixed-point equation until conver-gence. This scheme is called implicit coupling. A simpler and faster, but rather less precisescheme, is called explicit coupling and executes a fixed number of iterations, without anyconvergence checks or other effect on the exchanged values.
During each of these iterations, the solver needs to update its output values, using asinput the values it received from the other solver. In the case it uses the updated valuesfrom the other solver for this time, the coupling scheme is called serial (or sequential orstaggered or Gauss-Seidel iteration) and the solvers need to alternately wait for each other.In the case both solvers use the old values for this time, the coupling scheme is called parallel(or vectorial or Jacobi iteration) and the solvers do not need to wait for each other. Thisis called inter-field parallelism and should not be confused with the parallelism inside thesolver.
Let’s see these in more details. We assume two solvers, S1 and S2, which map elementsbetween vector spaces X1 and X2. The input of the one solver is the output for the other:
S1 : X1 7→ X2 and S2 : X2 7→ X1. (2.1)
As an example, imagine S1 being a fluid solver, which computes the pressures (forces)acting on a deformable boundary and S2 being a structure solver, which uses these forcesto compute the displacement and velocity of the boundary. This is a common mechanicalfluid-structure interaction scenario. In the case of conjugate heat transfer, imagine that thefluid solver would compute the temperature on the boundary and the solid solver would usethat to compute the heat flux.
Explicit coupling schemes can be either serial or parallel. In a serial-explicit (orconventional staggered) coupling scheme, the solver S1 uses the old time step’s boundaryvalues x
(n)1 to compute the values of x2 for the next time step (x(n+1)
2 ):
x(n+1)2 = S
(n)1
(x(n)1
). (2.2a)
6
2.1. preCICE
In the meantime, the solver S2 waits for the S1 to complete and then it uses these updatedvalues of x2 to update also the values of x1 for the next time step:
x(n+1)1 = S
(n)2
(x(n+1)2
). (2.2b)
Notice that in Equation 2.2a., S1 uses the values from time n, while in Equation 2.2b., S2
uses the values from time n+ 1.In order to minimize the waiting time, the two solvers can both use the values from time
n and communicate only when both are complete (parallel-explicit scheme), i.e. we compute
x(n+1)2 = S
(n)1
(x(n)1
)(2.3a)
andx(n+1)1 = S
(n)2
(x(n)2
)(2.3b)
in parallel. The two explicit schemes are shown schematically in Figures 2.1a. and 2.1b..This procedure is executed multiple times during the simulation. The simulated time
interval between two coupling executions n and n+ 1 is called coupling time step. A solveris allowed to perform multiple smaller steps in time before it exchanges information again.In this case, the solver is subcycling. This is shown in Figure 2.2..
Explicit coupling can create numerical instabilities, a problem that cannot always besolved by reducing the coupling time step size [18.]. In order to cure these instabilities,several coupling iterations must be executed every time the coupling is executed, until thevalues on both sides of the interface converge.
Implicit coupling schemes perform such fixed-point iterations and additionally modifythe results, in order to stabilize and accelerate the solution, using additional methods (“post-processing” in preCICE nomenclature).
The Equations 2.2a. and 2.2b. for the serial-explicit coupling scheme in the form of afixed-point iteration are written as:
x(n+1),i+12 = S
(n)1
(x(n+1),i1
)(2.4a)
andx(n+1),i+11 = S
(n)2
(x(n+1),i+12
). (2.4b)
Notice that in this case both equations use the values for the time n+1, but Equation 2.5a.
uses the values of x1 from iteration i, while Equation 2.5b. uses the values of x2 from iterationi+ 1.
The Equations 2.3a. and 2.3b. for the parallel-explicit coupling scheme in the form of afixed-point iteration are written as:
x(n+1),i+12 = S
(n)1
(x(n+1),i1
)(2.5a)
7
2. Tools
(a) Serial-explicit scheme.
(b) Parallel-explicit scheme.
(c) Serial-implicit scheme. Acc refers to the post-processing step. After every non-converged itera-tion, the latest stored state of the solver (checkpoint) is reloaded. When the solution converges,increase n.
(d) Parallel-implicit scheme. Acc refers to the post-processing step. After every non-convergediteration, the latest stored state of the solver (checkpoint) is reloaded. When the solutionconverges, increase n.
Figure 2.1.: Flowcharts of the available coupling schemes.
8
2.1. preCICE
Figure 2.2.: Coupling time step, solver time step and subcycling. In the case of implicit cou-pling, reading a checkpoint reverts the participants’ states to the last completedcoupling time step.
andx(n+1),i+11 = S
(n)2
(x(n+1),i2
). (2.5b)
The two implicit schemes are shown schematically in Figures 2.1c. and 2.1d..When converged, it will hold for the serial scheme:
x(n+1)1 = S
(n)2
(x(n+1)2
)= S
(n)2
(S(n)1
(x(n+1)1
))(2.6)
and therefore we need to solve the following fixed-point equations in an implicit couplingscheme:
x(n+1)1 = S
(n)2 ◦ S(n)
1
(x(n+1)1
)(2.7a)
(serial or Gauss-Seidel) or (x(n+1)1
x(n+1)2
)=
(0 S
(n)2
S(n)1 0
)(x(n+1)1
x(n+1)2
)(2.7b)
(parallel or Jacobi) or, in general, we need to solve the fixed-point equation
x = H (x) ⇔ R (x) := H (x)− x!= 0 (2.8)
where, in this case, H = S2 ◦ S1. We denote x̃n = H (xn) (“Picard iterate”)When using an implicit coupling scheme, preCICE asks the solver to store the current
state of its fields as a checkpoint before advancing the coupling. When an iteration forcomputing xn+1
1 and xn+12 does not converge, preCICE needs to try again, using different
values for the boundary conditions. In the meantime, the internal field values of all thesimulated variables have been affected by wrong boundary conditions, since preCICE uses
9
2. Tools
the solvers themselves to evaluate H (xn). Therefore, the internal field values from thelatest checkpoint need to be reloaded, which correspond to the time of the latest completedcoupling step. Any intermediate, subcycling steps are simulated again (see Figure 2.2.).
In preCICE, we can choose from a variety of methods to solve Equation 2.8.. One way is(iterative) under-relaxation:
xi+1 = H(xi)+(ωi − 1
) (H(xi)− xi
), ωi ∈ R. (2.9)
The value of ωi can either be user-defined (constant under-relaxation) or it can change forevery iteration. For adaptive ωi, preCICE offers the Aitken underrelaxation. These methodsare well-suited for easy, stable problems, but they are outperformed by more sophisticatedquasi-Newton coupling schemes [16.].
We can also reformulate Equation 2.8. in the following form:
R̃ (x̃) := x̃−H−1 (x̃)!= 0. (2.10)
and solve Equation 2.10. using a Newton step:
xn+1 = H (xn)− J−1R̃
(H (xn)− xn) , (2.11)
if only we knew the inverse Jacobian J−1R̃
. Because preCICE treats the individual solvers as“black boxes”, this information is not available. What is available, however, is the historyof the coupling iterations. This can be used to compute an approximate Jacobian andtherefore solve Equation 2.10. using a quasi-Newton step. Two variants of this method areoffered in preCICE: the classical interface quasi-Newton (IQN-ILS) and the multi-vectorquasi-Newton (IQN-IMVJ). The reader can find more information about these methods inthe presentation article of preCICE [6.]. A comparison between them has been publishedby Lindner et al. [11.]. In the preCICE-terminology, this additional step for improving thestability and accelerating the convergence is called “post-processing”.
To summarize, preCICE offers four coupling schemes: serial-explicit, parallel-explicit,serial-implicit, and parallel-implicit. The serial schemes execute the solvers sequentially (theone solver after the other, irrelevant of their internal parallelization) and the second solveruses the updated information from the first one. The parallel schemes execute the solvers inparallel, without updating their input before both solvers complete. In an explicit scheme,the solvers only exchange information once or a fixed number of times. This is simple andfast, but also unstable. An implicit scheme modifies the result of the fixed-point iteration,by solving a fixed-point equation until convergence, either with an under-relaxation or witha more sophisticated quasi-Newton method. In the preCICE terminology, this is called“post-processing” and, together with “checkpointing” are important in an implicit couplingscheme. Please note that, although we refer here to two solvers, preCICE is also capable ofcoupling multiple solvers at the same time.
10
2.1. preCICE
(a) Consistent mapping of temperatures.
(b) Conservative mapping of forces.
Figure 2.3.: Examples of mapping data between non-conforming meshes: consistent (a) andconservative (b) schemes.
2.1.2. Data mappingA challenge in partitioned coupling is to map the required data between non-conformingmeshes. The mapper not only needs to find the closest available mesh point, but also to notdisrupt the mass and energy balances. Therefore, preCICE maps variables between mesheseither in a consistent or in a conservative form. In the consistent mapping, the value of anode at the one grid is the same as the value of the corresponding node at the other grid.The consistent form simply reproduces the values from the one mesh to the other. Theconservative form, on the other hand, makes sure that the integral values are preserved.For example, forces are mapped in a conservative fashion, since the sum of forces on bothsides of an interface needs to be the same. On the contrary, fields such as temperatures orvelocities are mapped consistently. An example is shown in Figure 2.3..
The following mapping methods are implemented in preCICE [6.] (in their consistentvariant):
• Nearest neighbor: Finds the closest point on the source mesh and uses its value.It does not require any topological information and is first-order accurate.
• Nearest projection: Projects the target mesh points on the mesh elements of thesource mesh, performs linear interpolation on them and assigns the interpolated values
11
2. Tools
back on the target mesh. Because of the usually small distance between two meshes(normal to the interface), in relation to the size of the elements, this method is second-order accurate.
• Radial Basis Function: Requires no topological information, and it does not searchor project any points. It constructs an interpolant on the source mesh, using radial ba-sis functions centered at the grid points and evaluates it on the target mesh. preCICEoffers a wide variety of basis functions, but Gaussian and thin plate splines are themost widely used. A cut-off radius bounds the support of these functions and allowsto keep the communication in a parallel environment local. In preCICE, the RBFmapping uses the PETSc library2
. [2., 16.].
All the respective conservative mapping methods are also available.
2.1.3. CommunicationThe individual participants need to communicate with each other, in order to exchangeinformation. The participants may be executed in multiple processes, possibly running ondifferent nodes of a supercomputing system. The simulation software may not use MPI andmay not be open-source. However, these are no obstacles for preCICE, since it allows forcommunication using either MPI ports (MPI 2.0), or TCP/IP sockets (implemented withBoost.Asio3
.), which are lower-level and allow to couple closed-source software as well.In each parallel solver, one “master” process is chosen to manage the steering of the sim-
ulation. However, no central instance (“server”) is required in preCICE. The participat-ing processes use asynchronous point-to-point (M:N) communication. The communicationchannels are static and set in the beginning of the coupled simulation. This currently poseslimitations in using preCICE with dynamically adaptive meshes or immersed boundaries,limitations that are going to be surpassed in future releases [6., 16.].
2.1.4. ConfigurationIn order to start a multi-physics simulation with preCICE, all the participating, adaptedsolvers are started normally, in arbitrary order. Two configuration files are expected:
• Adapter’s configuration file: Normally this is a YAML file and contains informa-tion about the boundaries that are used for the coupling, the kinds of exchanged data,the name of the used mesh and the name of the common preCICE configuration file.It may also contain other parameters, special to each adapter.
• preCICE configuration file: This is an XML file and it is shared among all theparticipants. It defines the coupling interfaces between the participating solvers, the
2PETSc: https://www.mcs.anl.gov/petsc/index.html..3Boost C++ Libraries: http://www.boost.org..
12
2.1. preCICE
meshes over which coupling data is exchanged, the kinds of exchanged data, the waythese data are mapped from the one mesh to the other and it provides all the necessaryoptions for the respective coupling scheme.
The OpenFOAM adapter’s configuration file is described in Section 5.4.. For the configu-ration of preCICE, the reader is referred to the wiki of preCICE for the latest informationand detailed tutorials4
..
2.1.5. Application programming interface
Each participating solver needs to be modified to link to the preCICE library and callmethods from its application programming interface. Usually, the calls to the API aregrouped together in a preCICE adapter. While preCICE is written in C++, it provides anAPI also for C, Fortran and Python. An excerpt from the C++ API is shown in Listing 2.1.,as drawn from the preCICE source code documentation5
..A coupling consists of a configuration and an initialization phase, multiple coupling ad-
vancements and a finalization phase. First, a SolverInterface object needs to be created.The constructor expects the rank of the process and the size of the communicator in theparallel execution environment. The configure() method sets the name of the preCICEconfiguration file, reads and validates it and sets up the communication inside the solver.
The methods that follow in Listing 2.1. are called “steering methods”. The initialize()method sets up the data structures and communication channels to other participants. Herethe first communication happens, as the participants exchange meshes and, if necessary,re-partition them. It returns the maximum time step size that the solver is allowed toexecute next. It is followed by the initializeData(), which is optional and transfers anyinitial non-zero coupling data values among participants. The equation coupling, the datamapping and the communication are all hidden inside the advance() method. This methodalso returns the maximum time step size allowed. The last method to call is finalize(),which destroys the data structures and closes the communication channels.
The solvers need to define their interface meshes. Only some of the methods for meshdefinition are listed in Listing 2.1.. Each mesh and each node on the mesh are assigned aninteger ID. The getMeshID() gets the ID of the mesh over which the coupling data of thespecific kind are exchanged. The setMeshVertex() creates a vertex on the specified meshand position and returns the id of the vertex. For performance reasons, multiple verticescan be defined at once with setMeshVertices(). Additionally, topological information,such as edges or triangles can be passed to preCICE with additional methods which are notlisted here.
After defining the meshes, they need to be assigned data values. This is done by methodswith names write*Data(), which fill the “buffers” with data from the solver’s mesh or
4preCICE wiki on GitHub: https://github.com/precice/precice/wiki..5preCICE source code documentation: https://ipvs.informatik.uni-stuttgart.de/sgs/precice/doc/ .,
branch develop, produced by Doxygen on 13/10/2017.
13
2. Tools
1 class SolverInterface2 {3 public:4 SolverInterface(5 const std::string& solverName,6 int solverProcessIndex,7 int solverProcessSize);8
9 void configure(const std::string& configurationFileName);10
11 double initialize();12 void initializeData();13 double advance(double computedTimestepLength);14 void finalize();15
16 int getMeshID(const std::string& meshName);17 int setMeshVertex(int meshID, const double* position);18 void setMeshVertices(int meshID, int size, double* positions, int* ids);19
20 void writeScalarData(int dataID, int valueIndex, double value);21 void writeVectorData(int dataID, int valueIndex, const double* value);22 void writeBlockScalarData(23 int dataID,24 int size,25 int* valueIndices,26 double* values);27
28 bool isCouplingOngoing();29 bool isReadDataAvailable();30 bool isWriteDataRequired(double computedTimestepLength);31 bool isTimestepComplete();32
33 bool isActionRequired(const std::string& action);34 void fulfilledAction(const std::string& action);35
36 // ...37 };
Listing 2.1.: Excerpt from the C++ API of preCICE
14
2.1. preCICE
with methods read*Data(), which read data from the buffers into the solver’s mesh. SincepreCICE distinguishes between scalar and vector data, both kinds of methods are avail-able. Again, for performance reasons, blocks of data can be processed together using therespective writeBlock*Data() and readBlock*Data(). Please note that these data arenot communicated among participants before the next advance() (or initializeData()).
A number of auxiliary methods allow to access information important for the coupling,such as whether the coupled simulation is still running, if writing or reading data is expectedor if the current coupling time step has finished successfully. The solver can also inquire ifit is required to execute a specific action (e.g. to write or to read a checkpoint) and it caninform preCICE that it fulfilled these tasks [16.].
An example of an adapted solver is shown in Listing 2.2., as published in the presentationarticle of preCICE [6.]. A more detailed example is presented in the wiki of preCICE6
..
2.1.6. Available adaptersThis thesis presents an OpenFOAM adapter for preCICE. It is based on previous work andit considers other available adapters for specific solvers that use or are part of OpenFOAMor foam-extend. These adapters are described in Chapter 4..
OpenFOAM is only one of the simulation software packages that preCICE supports.Official adapters are currently available for several other free solvers, inluding CalculiX,Code-Aster and SU2 [17.]. Closed-source software is also supported, including COMSOLand Fluent. The adapters are available in their own repositories, under the umbrella of thepreCICE organization on GitHub7
.. A detailed list, including several third-party adapters,can be found in the website of preCICE8
.. Adapting an in-house solver is also possible andmore, unpublished adapters are known to exist [5.].
6preCICE wiki, “Adapter Example”: https://github.com/precice/precice/wiki/Adapter-Example ..7preCICE organization on GitHub: https://github.com/precice..8Official website of preCICE: http://www.precice.org/..
15
2. Tools
1 precice::SolverInterface precice("SolverName", solverRank, solverThreadSize);2 precice.configure("precice-config.xml");3 int dataID = precice.getDataID("DataName");4 int[] dataIndices = precice.setMeshVertices(meshID, dataSize, coordinates);5
6 // setup solver data structures7
8 double preciceMaxDt = precice.initialize();9
10 // time loop, originally with a different condition11 while (precice.isCouplingOngoing()) {12 dt = min(preciceMaxDt, solverDt);13
14 // compute solver time step using dt15
16 precice.writeBlockVectorData(dataID, dataSize, dataIndices, data);17 preciceMaxDt = precice.advance(dt);18 precice.readBlockVectorData(dataID, dataSize, dataIndices, data);19 }20
21 precice.finalize();22
23 // tear down solver data structures
Listing 2.2.: Example of a solver, adapted for preCICE. The comments refer to the originalcode of the solver. This example does not show the checkpoint managementor the computation of derived fields, such as forces on the boundary of a flowdomain in a mechanical FSI scenario. This example is drawn from the presen-tation article of preCICE [6.] (with minor modifications).
16
2.2. OpenFOAM
2.2. OpenFOAMOpenFOAM9
. (Open-source Field Operation And Manipulation) is a collection of tools forcomputational continuum mechanics [20.]. It offers a multitude of (parallel) solvers forcomputational fluid dynamics, as well as for other kinds of problems, such as heat trans-fer, combustion, particle tracking, molecular dynamics, electromagnetics, stress analysis ofsolids, and finance. In terms of flow problems, it supports incompressible and compressibleflows, laminar and turbulent flows, multiphase flows, and buoyancy-driven flows. A set ofgeneric solvers also extends its suitability to other kinds of partial differential equationsproblems. Additionally, it includes several utilities for pre- and post-processing [14., Sec-tion 3.5]. It is written in C++, and its code is publicly available on GitHub, under theGNU General Public License v3.010
..No graphical user interface is currently provided with OpenFOAM, although this lack
is addressed by related projects11.. The user executes each tool as a separate application
using the operating system’s command line interface. She can configure the tools using“dictionaries”, i.e. text files that are included in a “case directory”, and she receives theresults in files which she can later process with external tools, such as ParaView12
.. Anexample case directory is shown in Listing 2.3..
2.2.1. Structure of a solverIt is important to note that OpenFOAM is not one solver, but rather a framework on whichseveral, stand-alone solvers are built. These can be either included in the OpenFOAMdistribution, or they can be third-party solvers. The official solvers follow, however, somecommon patterns. In Listing 2.4. we show an excerpt from the solver icoFoam, which is atransient solver for incompressible, laminar flow of newtonian fluids [14., Section 3.5].
This solver is a stand-alone C++ program, as can be seen from the main() function.Before the time loop begins, the solver is being set up. The respective procedures are in-lined from separate files, a pattern often encountered in OpenFOAM. These files may bedefined globally or they may be specific to the solver. In this case, they are usually locatedin the same directory as the solver’s main source code file.
The time loop evaluates the while-condition runTime.loop() in the beginning of everytime step. This method hides additional functionality, which we will discuss in Section 2.2.5..The runTime object, of type Foam::Time13
. is an important object, as it carries not onlythe current time value and time step size, but also references to every registered object.Through this, several operations are being carried, such as the control of the time loop andthe output of the results.
9OpenFOAM: https://openfoam.org/..10GitHub - Official OpenFOAM Repository: https://github.com/OpenFOAM..11OpenFOAM Wiki, article “GUI”: https://openfoamwiki.net/index.php/GUI..12ParaView: https://www.paraview.org/..13OpenFOAM C++ Source Code Guide, version 5 [15.], https://cpp.openfoam.org/v5/classFoam_1_
1Time.html..
17
2. Tools
1 cavity2 ├── 03 │ ├── p4 │ └── U5 ├── constant6 │ └── transportProperties7 └── system8 ├── blockMeshDict9 ├── controlDict
10 ├── fvSchemes11 └── fvSolution
Listing 2.3.: Example of an OpenFOAM case directory contents. No mesh or result filesare shown here, but only the configuration files that are required to producethe mesh and run the simulation. The 0/ is the time directory for the initialstate and includes the initial and boundary conditions for the pressure and ve-locity. Similar directories are produced during the simulation. The constant/includes the model properties and the system/ includes the configuration filesthat control the numerical methods. This is from the lid-driven cavity tutorialof the icoFoam solver of OpenFOAM v.5.0.
18
2.2. OpenFOAM
What is inside the time loop is the core and the unique characteristic of each solver. Inthis loop, equations are defined and solved and the results are being written. The numericalmethods, including the implementation of the parallelization, are hidden from the developerof the solver inside the solve().
Since one solver usually solves multiple, often coupled equations, special algorithms arerequired to solve them all together. icoFoam follows the pressure-implicit with splittingof operators (PISO) algorithm in order to solve the Navier-Stokes equations in transientproblems. Relevant algorithms are the steady-state semi-implicit method for pressure-linkedequations (SIMPLE) and the PIMPLE, which allows to solve transient problems with biggertime steps than PISO. These are described in the OpenFOAM User Guide [14., Section 4.5.3].A detailed description of icoFoam and the aforementioned algorithms can be found in the(unofficial) OpenFOAM wiki14
..
2.2.2. A language for equationsOpenFOAM provides a high-level language (a set of C++ methods and overloaded op-erators) to solve equations. For example, Equation 2.12. is represented as shown in List-ing 2.5. [14., Section 3.1.3] and is solved inside the icoFoam solver. U represents the velocity,t the time, ν the kinematic viscosity and p the pressure, divided by a reference density (acommon practice in incompressible solvers). ϕ denotes the mass flux in the case of com-pressible solvers or the flux of velocity on the cell faces for constant-density flows (likehere). [14., Section 4.4.3].
∂U∂t
+∇ · ϕU −∇ · ν∇U = −∇p. (2.12)
2.2.3. Manipulating fieldsPhysical quantities, such as pressure or velocity, are not only a set of values, but theyare of a special type (e.g. scalarField, vectorField, tensorField), accompanied bydimensional units. This feature protects the programmer from writing equations that arenot dimensionally correct.
The units are defined by a set of scalar powers, e.g. in the form [kg m s K mol A cd]for the SI units system. For example, the units m/s are written as [0 1 -1 0 0 0 0].The units are assigned to the complete field and not to the individual cells, minimizing thememory overhead. [14., Section 4.2]
Furthermore, the boundary values on each “patch” of the boundary can be set and ac-cessed separately from the internal cell values. For example, P.boundaryField()[patch]returns a constant reference to the pressure values on the cells of the patch of the boundarywith index patch. This allows for easy iteration on the boundary cells, e.g. in order toextract the required data from the coupling interface.14OpenFOAM wiki - IcoFoam: https://openfoamwiki.net/index.php/IcoFoam..
19
2. Tools
1 int main(int argc, char *argv[])2 {3 #include "setRootCase.H"4 #include "createTime.H"5 #include "createMesh.H"6 // ...7 while (runTime.loop())8 {9 Info<< "Time = " << runTime.timeName() << nl << endl;
10
11 #include "CourantNo.H"12
13 // Momentum predictor14
15 fvVectorMatrix UEqn16 (17 fvm::ddt(U)18 + fvm::div(phi, U)19 - fvm::laplacian(nu, U)20 );21
22 if (piso.momentumPredictor())23 {24 solve(UEqn == -fvc::grad(p));25 }26
27 // --- PISO loop28 while (piso.correct()) { /* ... */ }29
30 runTime.write();31 }32 return 0;33 }
Listing 2.4.: Example of an OpenFOAM solver: excerpt from the transient, incompressiblelaminar flow solver icoFoam. This stand-alone C++ program contains a timeloop with the while-condition runTime.loop(). Note the high-level represen-tation of equations in the construction of UEqn and the call to solve().
20
2.2. OpenFOAM
1 solve2 (3 fvm::ddt(U)4 + fvm::div(phi, U)5 - fvm::laplacian(nu, U)6 ==7 - fvc::grad(p)8 );
Listing 2.5.: Example of an equation representation in OpenFOAM (Equation 2.12.).
2.2.4. Creating new applications
In order to create a new application, or to modify the behavior of a provided one, the userdoes not need to change the existing code. Instead, she can edit and build her code inher user directory. This is possible because OpenFOAM looks for an application in theuser’s directories before it looks for it in the global installation directory. In order to buildOpenFOAM applications and libraries, the provided tool wmake is used. [14., Section 3.2]
2.2.5. Injecting code at runtime: function objects
The user can use OpenFOAM function objects in order to execute additional code duringevery iteration of the time loop, independent of the solver. These are meant to be post-processing tools that the user can load at runtime. A variety of function objects are providedand she can select them or provide her own code in the controlDict configuration file15
..A list of the provided function objects can be found in the OpenFOAM User Guide [14.,Section 6.2.1]. This includes calculation of derived fields, probing of data, visualizationtools, system tools, a “pluggable” scalar transport solver and other.
An example of a function object configuration is shown in Listing 2.6.. Every functionobject has a name and a type. It may either include precompiled libraries, or it maybe coded inside the controlDict. Some function objects also accept additional options.Multiple function objects may be defined inside functions{} and their respective methodsare executed one after the other, in the same order that the function objects appear insidefunctions{}.
We can also create our own function objects, in addition to the long list of providedfunction objects. A tutorial for creating a custom function object can be found in the book“The OpenFOAM Technology Primer” [12.], one of the few textbooks on programmingwith OpenFOAM. The code presented there is not immediately compatible with current15 OpenFOAM C++ Source Code Guide, version 5 [15.] codedFunctionObject Class Reference:
https://cpp.openfoam.org/v5/classFoam_1_1codedFunctionObject.html..
21
2. Tools
1 functions2 {3 an_example_systemCall // name4 {5 type systemCall; // type6 libs ("libutilityFunctionObjects.so");7 // Executed at the end of every iteration (additional options)8 executeCalls9 (
10 "echo \*\*\* The iteration completed. \*\*\*"11 );12 // Executed after the executeCalls13 writeCalls14 (15 "echo \*\*\* Is it time to write results? \*\*\*"16 );17 // Executed at the end of the last iteration18 endCalls19 (20 "echo \*\*\* The final iteration completed. \*\*\*"21 );22 }23 }
Listing 2.6.: Example of an OpenFOAM function object configuration: systemCall. This isplaced at the end of the system/controlDict case configuration file and it ex-ecutes the specified system commands at specific points during every iteration.This example can be used in any OpenFOAM case, as it is.
OpenFOAM versions, but a template compatible with your version can be found in the$FOAM_ETC/codeTemplates/functionObject/ directory (or in a different directory insidethe $FOAM_ETC/ for earlier versions).
As the example from Listing 2.6. hints, there are specific hooks where we can injectcode. Since the function objects are linked at runtime, they need to have the expectedpublic interface. A list of the functions that we can re-define is shown on the right side ofFigure 2.4., as drawn from the source code of OpenFOAM 5.016
..When and how are these methods called? OpenFOAM keeps a list of the specified function
objects and executes their respective functions inside methods such as the Time::loop()16OpenFOAM C++ Source Code Guide, version 5 [15.] Foam::functionObject Class Reference:
https://cpp.openfoam.org/v5/classFoam_1_1functionObject.html..
22
2.2. OpenFOAM
that we found inside icoFoam (Listing 2.4.). As an example, let’s see how the execute()method is called. For this, you may follow Figure 2.4. or look for more details in Appendix B..icoFoam calls Time::loop(), which involves a call to the Time::run(). The latter triggersthe methods start(), execute(), and end() on the object functionObjects_ of typeFoam::functionObjectList, depending on the current time value. While most of the list’smethods are translated to the respective methods for every function object, a call to thelist’s start() calls each object’s read() and a call to the list’s execute() calls each object’sexecute(), followed by its write().
The rest of the methods are triggered whenever special events happen. The user caninquire that OpenFOAM uses a dynamic time step, by enabling the adjustTimeStep op-tion in the controlDict configuration file. Solvers that support this behavior usuallyinclude the file setDeltaT.H inside their time loop, before advancing to the next timestep using runTime++. This contains a call to the Foam::Time::setDeltaT() inside anif(adjustTimeStep){}. At the end of this method, the adjustTimeStep() of the func-tion object list is triggered. Similarly, whenever the mesh is updated or its points are moved,the respective methods are called.
Figure 2.4.: OpenFOAM function objects: call flow.
23
2. Tools
2.2.6. The registry of objects
Each solver handles different fields. For example, while most of the fluid solvers process avelocity and a pressure field, some solvers will add turbulence-related fields and a thermalsolver will add a temperature field. These fields are usually created inside a solver-specificcreateFields.H file, as well as in the constructors of turbulence or other models.
OpenFOAM keeps account of all the fields and its model and mesh properties in anhierarchical database. The Foam::polyMesh class inherits from Foam::objectRegistryand therefore the solver’s mesh object is also a registry of objects. We can inquire thenames of all the registered objects using mesh.names() inside the solver. The registeredobjects in the case of icoFoam are:
points, neighbour, faces, U, fvSchemes, faceZones, fvSolution, phi, owner,data, cellZones, boundary, p, pointZones, transportProperties
An objectRegistry also carries the type of each object. We can restrict the above listto only objects of e.g. type volScalarField using mesh.names<volScalarField>(). Thisallows us to know that the only registered volume scalar field is p. Similarly we know thatthe only volVectorField available is U and the only surfaceScalarField is phi.
In order to retrieve a (constant) reference to a registered object whose name we know, wecan use the method lookupObject<Type>(name). Notice that we need to know the type ofthe object in advance. In case the object does not exist, the application will crash. To pre-vent this, we can first check if the requested object exists, using foundObject<Type>(name).We can also retrieve a HashTable with references to all the registered objects of a specifictype using lookupClass<Type>(). You may find more about the registry of objects in theDoxygen documentation of OpenFOAM17
. or at the OpenFOAM wiki18..
2.2.7. Physical models and solvers of interest
OpenFOAM provides several classes for physical models, an overview of which can be foundin the OpenFOAM User Guide [14., Chapter 7]. The models are mainly distributed intothree categories: turbulence models, transport models, and thermophysical models. Wedescribe here the relations between physical model classes in OpenFOAM versions 4 and 5.See Appendix A. for notes on previous versions.
Turbulence models describe the turbulent part of the flow, and provide the turbulentviscosity, the turbulent kinetic energy, and other properties. The Foam::turbulenceModelclass has two children: the compressibleTurbulenceModel for compressible, and theincompressibleTurbulenceModel for incompressible solvers.
17OpenFOAM C++ Source Code Guide, version 5 [15.], Foam::objectRegistry Class Reference:https://cpp.openfoam.org/v5/classFoam_1_1objectRegistry.html..
18OpenFOAM wiki - article objectRegistry:https://openfoamwiki.net/index.php/OpenFOAM_guide/objectRegistry..
24
2.2. OpenFOAM
Transport models provide the viscosity of the fluid. Two separate base classes of transportmodels are defined: Foam::transportModel, used by incompressible turbulent solvers, andFoam::compressibleTransportModel, for compressible turbulent solvers.
Thermophysical models “are concerned with energy, heat and physical properties” andthey use a pressure-temperature system, in order to derive other properties. The baseclass for thermophysical models is Foam::basicThermo and it provides virtual methods foraccessing the temperature, pressure, density, thermal diffusivity, and other properties. Twoother abstract classes inherit from this: solidThermo and fluidThermo, which are furtherspecialized by other classes. The reader is referred to the source code documentation ofOpenFOAM for more details, starting from the fluidThermo class19
..
Compressible turbulent flow
The class fluidThermo also inherits from the class compressibleTransportModel, there-fore the derived from it models refer to compressible flows. A separate, templated classThermalDiffusivity<BasicTurbulenceModel> defines the abstract thermal diffusivity-and conductivity-related methods, equipping compressible turbulence solvers with ther-mal transport models. This provides a method kappaEff(), which returns the effective(laminar plus turbulent part) conductivity for the fluid.
The special type Foam::compressible::turbulenceModel connects a fluidThermo classto a compressible turbulence model and thermal diffusivity, as shown in Listing 2.7.. Thistype can be specialized for RAS or for LES turbulence models, creating a concrete com-pressible turbulence model, which provides access to all of the parent classes’ functionality.However, the type compressible::turbulenceModel is enough for accessing the thermaltransport properties. These types are defined in the turbulentFluidThermoModel.H file,which is included by every compressible turbulent solver that can support heat transfer.
Standard OpenFOAM solvers of interest in this category (i.e. solvers which include theturbulentFluidThermoModel.H file) are [14., Section 3.5]:
• In the section “Heat transfer and buoyancy-driven flows”:– buoyantPimpleFoam: Transient solver for buoyant, turbulent flow of compress-
ible fluids for ventilation and heat-transfer.– buoyantSimpleFoam: Steady-state solver for buoyant, turbulent flow of com-
pressible fluids, including radiation, for ventilation and heat-transfer.– thermoFoam: Solver for energy transport and thermodynamics on a frozen flow
field.– The CHT solvers chtMultiRegionFoam and chtMultiRegionSimpleFoam.
• All the solvers in the section “Compressible flow”.19OpenFOAM C++ Source Code Guide, version 5 [15.], Foam::fluidThermo Class Reference:
https://cpp.openfoam.org/v5/classFoam_1_1fluidThermo.html..
25
2. Tools
1 namespace Foam2 {3 namespace compressible4 {5 typedef ThermalDiffusivity<CompressibleTurbulenceModel<fluidThermo>>6 turbulenceModel;7
8 typedef laminarModel<turbulenceModel> laminarModel;9 typedef RASModel<EddyDiffusivity<turbulenceModel>> RASModel;
10 typedef LESModel<EddyDiffusivity<turbulenceModel>> LESModel;11
12 template<class BasicCompressibleTurbulenceModel>13 autoPtr<BasicCompressibleTurbulenceModel> New14 (15 const volScalarField& rho,16 const volVectorField& U,17 const surfaceScalarField& phi,18 const typename BasicCompressibleTurbulenceModel::transportModel&19 transport,20 const word& propertiesName = turbulenceModel::propertiesName21 );22 }23 }
Listing 2.7.: Excerpt from the turbulentFluidThermoModel.H file, included by every com-pressible turbulent solver that can support heat transfer. The fluidThermoinherits from the basicThermo and compressibleTransportModel. Note thatnames that start with an uppercase character refer to templates.
• Most of the solvers in the section “Combustion”.
• Several solvers in the section “Particle-tracking flows”.
These solvers expect the thermophysicalProperties and turbulenceProperties con-figuration files.
Incompressible turbulent flow
The incompressible solvers do not use the thermophysical library of OpenFOAM. Theyonly specify a turbulence and a transport model, using the classes Foam::transportModeland Foam::incompressibleTurbulenceModel. The solvers of this type include the file
26
2.2. OpenFOAM
turbulentTransportModel.H. There, the type incompressible::turbulenceModel is de-fined as IncompressibleTurbulenceModel<transportModel>.
Any support for thermal transport is implemented specifically for the solver. The onlyincompressible turbulent solvers that we found to support heat transfer were the transientbuoyantBoussinesqPimpleFoam and its steady-state equivalent. These solvers create aturbulent thermal diffusivity field alphat and they compute the effective thermal diffusivityalphaEff while solving their temperature equation (TEqn.H).
Therefore, these solvers do provide an effective thermal diffusivity but, since they do nothave any information about the fluid’s density or heat capacity, they cannot provide theconductivity.
Standard solvers of interest that follow this approach are [14., Section 3.5]:
• buoyantBoussinesqPimpleFoam: Transient solver for buoyant, turbulent flow of in-compressible fluids.
• buoyantBoussinesqSimpleFoam: Steady-state solver for buoyant, turbulent flow ofincompressible fluids.
These solvers expect the transportProperties and turbulenceProperties configura-tion files.
Basic solvers
OpenFOAM provides also a few generic solvers, which can be used to solve any equa-tion. These solvers do not use any physical model classes, but they define all the requiredequations in their own files. When provided with the necessary parameters (namely theconductivity), they can be used in coupled simulations.
Standard solvers of interest in this category are [14., Section 3.5]:
• laplacianFoam: Solves a simple Laplace equation, e.g. for thermal diffusion in asolid.
• scalarTransportFoam: Solves the steady or transient transport equation for a passivescalar.
These solvers expect the configuration file transportProperties.
27
3. Conjugate heat transfer
Although the core of our adapter has been designed to be solver- and problem-agnostic, someoperations are specific to the problem type and are delegated to dedicated “modules”, classesthat read the problem-specific configuration and provide the respective boundary conditionclasses. In the context of this thesis, we provide a module for conjugate heat transfer (CHT).The previous adapters were developed and validated for this type of problem, therefore wechose this as an application area. In order to better understand the problems discussedin the next chapters, we give here a quick recapitulation of the dominant models andterminology discussed in the thesis of Cheung Yau [7.], who developed the previous adaptersfor conjugate heat transfer and studied this problem in depth.
3.1. Mechanisms of heat transfer
Conjugate (convective) heat transfer studies the heat transfer between a solid and a run-ning fluid in contact. In this thesis, we consider only the mechanisms of conduction andconvection, ignoring radiation.
The heat conduction is explained by the motion of molecules, where energy is transferredfrom molecules with higher internal energy to molecules with lower internal energy. Twobodies in contact exchange heat following Fourier’s law of heat conduction:
q = −k∇T , (3.1)
where energy flows from the body with higher temperature into the body of the lowertemperature. q is the heat flux density, ∇T is the temperature gradient and k is thematerial’s thermal conductivity [W/(m ·K)]. This parameter can be temperature-dependentand therefore different on each point of the body.
Convection happens both because of the molecular movement (diffusion), but also becauseof the bulk motion of the fluid (advection). It can be described by Newton’s law of cooling:
dQ
dt= hA (Ts(t)− T∞) , (3.2)
where Q is the thermal energy, Ts is the temperature of the solid body, and T∞ is theenvironment temperature, far away from the solid. A is the contact area and h is the heattransfer coefficient, with units e.g. W/(m2 ·K). This parameter is not a material property,but it depends in several factors, including the geometry of the body.
29
3. Conjugate heat transfer
3.2. Parameters of heat transferWe already met two parameters important for the heat transfer analysis:
• The thermal conductivity k [W/(m·K)], which describes how easily a material conductsheat.
• The heat transfer coefficient h [W/(m2 · K)], which describes how easily heat flowsbetween a (solid) body and its environment.
Throughout this thesis, we also refer to the following parameters:
• The specific heat capacity cp [J/(kg ·K)], which describes how much energy is requiredin order to raise the body’s temperature by 1 K.
• The thermal diffusivity α [m2/s], which describes the thermal inertia of the material.
The conductivity and the diffusivity are connected:
k = αρcp , (3.3)
where ρ is the density of the material. In turbulent flows, we refer to the effective conduc-tivity:
keff = αeffρcp = (α+ αt) ρcp =
(ν
Pr+
νtPrt
)ρcp , (3.4)
where ν is the kinematic viscosity of the fluid. Pr = ν/α is the (dimensionless) Prandtlnumber, which is the ratio of momentum to the thermal diffusivity. νt and Prt are theturbulent parts of the respective parameters.
3.3. Coupling approachesIn order to couple heat transfer simulations on their interface, we use one of the followingtwo approaches: Dirichlet-Neumann coupling, or Robin-Robin coupling.
In the Dirichlet-Neumann coupling, we assume the continuity of the temperature and theheat flux on the fluid-solid interface ΓFS, i.e.:
Ts = Tf on ΓFS (3.5)
andks∂Ts∂n
= −kf∂Tf∂n
on ΓFS . (3.6)
This is also called conjugate boundary condition.In the Robin-Robin coupling, we assume that Newton’s law of cooling applies:
q = h(T − T∞) (3.7)
30
3.3. Coupling approaches
and we assume the energy balance on the interface:
q1 = h2(T − T∞2) (3.8)
withh2 =
k2∆x2
and T∞2 = T2. (3.9)
∆x2 refers to the distance of the point where T∞2 is measured from the interface. The indices1 and 2 refer to the domains on the two sides of the interface. In a Robin-Robin coupling,both simulations need to know the heat transfer coefficient and the sink temperature of theother side.
Now that we refreshed the basic concepts and terminology of our application example,let’s proceed to an overview of the previous adapters for this problem and of other relatedwork, in Chapter 4..
31
4. Previous work
In this chapter, we give an overview of other adapters that shaped our work. Section 4.1.1.
presents the previous OpenFOAM adapters for conjugate heat transfer with preCICE,adapters which we built on. Section 4.1.2. gives an example of coupling foam-extend withpreCICE for mechanical fluid-structure interaction. Section 4.1.3. introduces other attemptsof coupling OpenFOAM with preCICE.
Defined already in this thesis’ title, preCICE is the only coupling library we are goingto work with. However, other coupling tools exist, which also support OpenFOAM. Onealternative is MpCCI, whose OpenFOAM-adapter was a useful point of reference duringour adapter’s development and therefore is also presented here, in Section 4.2.1..
Finally, two other examples of using OpenFOAM for multi-physics simulations are pre-sented in Sections 4.2.2. and 4.2.3..
4.1. Available OpenFOAM adapters for preCICE
This thesis extends Lucia Cheung Yau’s work [7., 9., 8.], in which she developed and validatedpreCICE-adapters for OpenFOAM, CalculiX, and Code-Aster for conjugate heat transfer.Her results showed that preCICE can successfully couple specific solvers of these packages,increasing further our development interest. Kevin Rave [13.] also adapted foam-extendsolvers for CHT.
Mechanical fluid-structure interaction is also possible using preCICE and OpenFOAM.In particular, David Blom [3.] developed such adapters and solvers for foam-extend.
A goal of our work is to reduce this duplication of development effort.
4.1.1. Previous CHT adapters
The direct ancestors of our proposed adapter are the conjugate heat transfer adaptersdeveloped by Cheung Yau for OpenFOAM 3.0. In Figures 4.1. and 4.2. we show the structureof these CHT adapters.
A main class Adapter provides the methods that are explicitly called from the modifiedsolvers. While some of these methods are just wrappers to the preCICE API functions,other methods bundle together additional functionality and checks. The methods of thisclass handle the following tasks:
• they initialize the coupling (initialize()),
33
4. Previous work
• they make each registered Interface extract the required data from the OpenFOAMfields and write them into a coupling buffer (writeCouplingData()),
• they make each registered Interface read the available data from the buffer and storethem into the OpenFOAM fields (readCouplingData()),
• they adjust the time step of the solver (adjustSolverTimeStep()),
• they write and read checkpoints (writeCheckpoint(), readCheckpoint(), togetherwith the addCheckpointField()),
• they perform the coupling (exchange of data, mapping, post-processing) by callingthe advance method of preCICE (advance()).
Each solver needs its own adapter, which inherits from the class Adapter, defines the ab-stract method createInterfacesFromConfigFile in order to create the appropriate cou-pling data readers and writers. The adapted buoyantSimpleFoam and buoyantPimpleFoamfollow this approach. On the other hand, buoyantBoussinesqPimpleFoam and a modifiedversion of the laplacianFoam are also provided, but they use the abstract class Adapterand define the missing method in their bodies. To summarize, the following solvers havebeen adapted:
• buoyantPimpleFoam: Transient solver for buoyant, turbulent flow of compressible flu-ids for ventilation and heat-transfer [14., Section 3.5.7]. The adapted solver supportsexchanging temperature and heat flux (Dirichlet-Neumann coupling), or sink temper-ature and heat transfer coefficient (Robin-Robin coupling). In order to compute theheat flux, it uses Equation 3.1., where the (effective) conductivity keff is provided bythe turbulence model (turbulence->kappaEff()).
• buoyantSimpleFoam: Steady-state solver for buoyant, turbulent flow of compressiblefluids, including radiation, for ventilation and heat-transfer [14., Section 3.5.7]. Interms of coupling data, it supports exchanging sink temperature and heat transfercoefficient.
• buoyantBoussinesqPimpleFoam: Transient solver for buoyant, turbulent flow of in-compressible fluids [14., Section 3.5.7]. A modified version of this solver is used, whichrequires the user to provide values for the density and heat capacity of the material.The additional parameters are read from the transportProperties configuration fileby the solver’s createFields.H source file. The adapted solver supports exchangingtemperature and heat flux data. In order to compute the heat flux, it computes theeffective conductivity using Equation 3.4.. The turbulent thermal diffusivity at andthe Prandtl number Pr are provided by the solver (alphat, Pr), the laminar viscosityν is provided by the turbulence model (turbulence->nu()) and the density ρ andheat capacity cp are read as rho and Cp.
34
4.1. Available OpenFOAM adapters for preCICE
Figure 4.1.: Simplified call flow from the adapted buoyantPimpleFoam to preCICE. In thisfigure, the solid arrows signify accesses to the pointed object’s elements.
• laplacianFoam: The original solver computes a simple laplacian equation, suchas the thermal diffusion on a solid [14., Section 3.5.1] and it expects the thermaldiffusivity in its configuration. For CHT simulations, a modified version of thissolver is used, which requires the user to provide values for the conductivity, den-sity, and heat capacity of the material instead. These parameters are read from theconstant/transportProperties configuration file by the solver’s createFields.Hsource file. It supports exchanging temperature and heat flux. In order to computethe heat flux, it uses the same, user-defined value of conductivity for all the cells.In the laplacian equation, the diffusivity parameter is computed from the providedparameters as k/(ρcp).
As an example, Figure 4.1. shows how the adapted buoyantPimpleFoam solver accessespreCICE. It constructs a buoyantPimpleFoamAdapter object, which defines and calls themethod createInterfacesFromConfigFile(). The rest of the adapter’s methods are in-herited from the Adapter class. These create and access a preCICE solver interface andthey make changes to the solver’s runTime object. For details, see Appendix C..
The adapter uses the ConfigReader class to read a YAML configuration file and createinterfaces. This file is shared with the adapters of other solvers and a list of participantsis provided. Therefore, each solver is modified to receive an extra argument, which informsthe adapter of the respective participant’s name in the preCICE configuration.
Each Interface contains the parameters and objects for each set of exchanged data, forexample the preCICE SolverInterface instance, the OpenFOAM patches names and IDs,and the data buffers. The mapping between the data buffer and OpenFOAM fields is doneby children of the CouplingDataReader and CouplingDataWriter classes. These extract
35
4. Previous work
the boundary values, set the boundary conditions and compute derived quantities, such asheat flux, using a different equation, depending on the variables available to each solver.
Each solver-specific adapter adds interfaces with different kinds of coupling data readersand writers. While some solvers treat the same kinds of fields, they access some propertiesin a different way. Therefore, a specific adapter is needed for each solver because each solverworks with different variables and classes.
The adapters were originally created for OpenFOAM 3.0. In the context of this thesis,those adapters were also ported to OpenFOAM 4.0/4.1 and 5.01
.. The main differencesbetween the aforementioned versions are described in Appendix A.. The solvers were adaptedagain, starting from the pure solvers of the respective versions.
4.1.2. Previous FSI adapters
Conjugate heat transfer is not the only application area in which preCICE has been adaptedfor OpenFOAM. In particular, foam-extend 3.2 has been adapted for preCICE, in order tosolve fluid-structure-acoustics interaction problems [3., 4.].
In that work, Blom developed fluid and solid solvers for preCICE, based on standardsolvers of foam-extend. Those solvers support a wide range of coupling features, includingimplicit coupling with a wide variety of post-processing methods, consistent first and secondorder time integration schemes, and an efficient mesh motion solver, using radial basisfunction interpolation.
The main components of that project are the adapted solvers for solid and fluid simu-lations, the adapters for solids and fluids, as well as the standard solvers. The preCICE-adapted solver fsiSolidFoam creates an object of the PreciceSolidSolver class, whichuses one of the solvers ElasticSolidSolver, SolidSolver, or SteadyStateSolidSolver.Similarly, the fsiFluidFoam creates an PreciceFluidSolver object, which uses one of theCoupledFluidSolver, FluidSolver, SteadyStateFluidSolver, orCompressibleFluidSolver solvers.
This project was not preferred over the previous conjugate heat transfer adapters as astarting point, for the following reasons: First of all, the fact that this project is built onfoam-extend limits significantly the compatibility with other OpenFOAM variants. Second,this project is much more than a preCICE adapter, since it demonstrates several additionalmethods. It would be difficult to examine all the available features and at the same timebuild a more general adapter.
However, this project serves as a well-tested adapter for fluid-structure-acoustics inter-action. Our proposed adapter can be extended to cover also this kind of problems, eventhough without maybe the full set of features presented in FOAM-FSI. Such an extensionwould, nevertheless, require additional time in order to be done properly, as also additionalvalidation should be performed.
1 Previous CHT adapters, ported to newer OpenFOAM versions:https://gitlab.lrz.de/gchourdakis/openfoam-adapter-legacy..
36
4.1. Available OpenFOAM adapters for preCICE
Figure 4.2.: UML class diagram of the previous CHT adapters.
37
4. Previous work
4.1.3. Other adapters
There is also other work which adapts OpenFOAM solvers for preCICE. The most recentthat we know of is the thesis of Rave [13.], in which he adapted the foam-extend 3.2 solverslaplacianFoam and icoScalarTransportFoam for preCICE, in order to use them for sim-ulating conjugate heat transfer. The adapted icoScalarTransportFoam was also coupledto the deal.II finite element library2
.. In this study, only Dirichlet-Neumann coupling wasstudied. The approach was again to modify the solvers’ source code.
4.2. Other approaches4.2.1. MpCCI
MpCCI3. is one of the first and well-established tools for coupling, an alternative to preCICE.
However, in comparison to preCICE, it is a commercial, closed-source project, while it alsodiffers in the features it offers.
MpCCI comes also with an OpenFOAM adapter4.. This adapter supports both conju-
gate heat transfer and fluid-structure interaction [10.]. In terms of boundary conditions, itsupports the exchange of temperature, heat flux, heat transfer coefficient, and sink temper-ature. It also has boundary conditions for wall forces, velocity, positions, mass flow rate,and pressures.
Its approach is to provide a function object, which also uses the objects’ registry to accessthe required fields. It also supports looking for fields with different names. It distinguishesbetween transient and steady-state solvers and it guesses the type of the solver accordingto the keywords in its name. It also distinguishes between compressible and incompressiblesolvers, and it accesses the respective turbulence models. For the latter, it requires the userto provide a reference density and a reference specific heat. For some FSI scenarios, it alsorequires specifying a reference pressure. It comes together with the MpCCI Grid Morpherfor smoothing the grid.
It supports OpenFOAM versions from 1.7 and up to the latest release from openfoam.com.
4.2.2. The OpenFOAM CHT solvers
OpenFOAM provides its own, monolithic solvers for conjugate heat transfer: the tran-sient chtMultiRegionFoam, and the steady-state chtMultiRegionSimpleFoam. These aredescribed as solvers for “buoyant, turbulent fluid flow and solid heat conduction with con-jugate heat transfer between solid and fluid regions.” [14., Section 3.5]. They solve all thedefined fluid and solid regions, the one after the other, in the same time loop. The previousadapters have been also validated against these solvers [7.].
2deal.II – an open source finite element library: https://www.dealii.org/..3MpCCI - Multiphysics Interfaces: https://www.mpcci.de/..4MpCCI (Download Area): https://www.mpcci.de/en/mpcci-download-area.html..
38
4.2. Other approaches
4.2.3. SimpleFsiThe community of OpenFOAM has shown interest into simulating fluid-structure interac-tion with OpenFOAM, and related projects appear in conferences and workshops throughthe years. One example is the training course “Simple fluid-structure interaction”, hostedin the wiki of openfoam.com5
.. This example also builds a function object and uses theforces function object to compute the forces on the boundaries.
5Simple fsi: https://wiki.openfoam.com/Simple_fsi_by_Sergei_Strijhak..
39
5. Implementation
Having researched the previous attempts to couple OpenFOAM with preCICE (Chapter 4.),and having studied the models of conjugate heat transfer (Chapter 3.), which is our appli-cation example, we can now use the OpenFOAM features which we discussed in Chapter 2.,in order to implement a general OpenFOAM adapter for preCICE.
In Section 5.1. we set our objectives and we present the main concepts of our proposedsolution, together with the challenges that we had to overcome for a general OpenFOAMadapter for preCICE. In Section 5.2. we see the adapter from the perspective of OpenFOAM,and we describe why a function object is a good solution to the problem of having a solver-independent adapter. Next, in Section 5.3., we dive deeper into the implementation of theadapter. We present the main code elements and the novelties that the proposed adapterbrings, compared to the previous implementation. In Section 5.4., we describe the mainconfiguration of the adapter. In Section 5.5. we describe the problem-specific CHT moduleand in Section 5.6. we explain how the proposed adapter can be extended to cover otherproblem types.
5.1. DesignIn order to build a general adapter, we had to rethink the design. After setting our ob-jectives, we decided to change several parts of the previous design, in order to face therespective challenges. However, parts of the previous implementation, which already de-coupled the problem-specific classes from the main adapter, were re-used. We present themain concepts of the new design here.
5.1.1. ObjectivesThe first objective that we set for our new design is to not make any changes in the solvers’source code. The adapter should be able to be loaded and configured at runtime.
Moreover, the provided features should be solver-agnostic. Accessing elements of a solveris allowed, but the name of the solver should not be used by the adapter, so that we allowusers to couple their own OpenFOAM-based solvers. Only one adapter should be providedfor all the solvers, without any code changes. Additionally, it should not be specific to oneproblem type.
Since we want the adapter to be general, it should also support the full spectrum ofpreCICE features. Users that develop their own adapters may sometimes omit some featuresthat they don’t need. This should not be the case with such a general adapter.
41
5. Implementation
Finally, since there is not only one version or variant of OpenFOAM used widely, we needto support multiple versions and variants. Porting the adapter to different versions is notin the scope of this thesis, however we try to design the adapter in such a way that willallow for portability.
5.1.2. Proposed solution and challengesThe solution we propose is an adapter in the form of an OpenFOAM function object. Aswe saw in Section 2.2.5., function objects can be linked at runtime, without being bound toany specific solver. However, this raises some challenges.
One challenge is that we only have specific points to inject code at runtime. For recentOpenFOAM versions, these are:
1. In the beginning of the first iteration of the time loop.
2. During every iteration of the time loop.
3. At the end of the last iteration of the time loop.
4. Every time the solver’s time step is adjusted.
5. Every time the mesh is updated or the mesh points are moved.
Moreover, older versions of OpenFOAM do not offer all of the above points. Therefore, weneed to group together the necessary calls and inject them into these points.
Since the function object’s methods are called only once per iteration of the time loop,the adapter needs to prevent the solver from exiting before an implicit coupling completes.As soon as the solver reaches the end time, it exits after executing the function object’smethods execute() and end(), as shown in Listing B.3.. In order to overcome this difficulty,we set the solver’s end time to infinity and we control the end of the simulation using theinformation from preCICE.
Additionally, we cannot access all the necessary elements of the solvers directly. Forthis, we use an available reference to the mesh of the solver, in order to access the objects’registry. Through this, we are able to access most of the elements that we need. Methodslike the templated lookupClass<>() allow us to get a list of all the available fields of aspecific type, useful for checkpointing the complete state of the solver.
Each solver not only defines a different set of fields, but also objects of different type.The most important obstacle that we faced was the different ways to access the thermalconductivity object, if this was even defined. In order to overcome this, we isolated thecomputation of the conductivity in separate classes, specific to the three categories of solversidentified in Section 2.2.7.. We determine this type automatically, according to the availabledictionaries, and we allow the user to override this automation and provide her own type.
Since we cannot modify the solver’s code, we cannot change the command-line argumentsit accepts. As a solution, we move all the configuration options into a configuration file,
42
5.2. The function object
which is always assumed to have the same name. The solvers are started normally, withoutany additional arguments, and the adapter reads the required file.
5.1.3. Reused elementsSeveral elements of the previous implementation remained unchanged. We found the dis-tinction between an adapter, interfaces, and coupling data users to be useful. Therefore,the Interface class remained the same. The CouplingDataUser class is still used and wemerged the previous “boundary values” and “boundary conditions” to inherit directly fromthis class. The new “coupling data users” provide both the write() and read() methods.
5.2. The function objectThe function object was created using the template for function objects that can be foundin the $FOAM_ETC/codeTemplates/functionObject/ directory of the installation. The filepreciceAdapterFunctionObject.C defines the function object and is only a wrapper tothe main methods of the adapter. This was done so that the function object can be easilyportable to other OpenFOAM versions, which change the available virtual methods.
An overview of the most important methods is shown in Listing 5.1.. The read() methodis called in the beginning of the first time iteration, and it calls the adapter’s configure().An important note is that the call to the read() method of any function object is encap-sulated into a try...catch structure, which degrades any error to a warning. Therefore,an error in the configure() would destroy the function object and the simulation wouldcontinue without it. In order to bypass this behavior, we manually check for errors in thisphase. If an error occurs, we catch it and the adapter keeps running. In the first execute()call, the adapter notices that something went wrong and throws an error, which is reportednormally.
As described in Section 2.2.5., the execute() method is called in the beginning of everytime iteration, after the first one, while the end() is executed at the end of the last iteration.The adjustTimeStep() applies only to the case that an adjustable solver time step is used,and it is called every time the time step is adjusted, e.g. before solving the next iteration.
5.3. The adapter’s coreThe adapter is distinguished in two parts: the core and the problem-specific modules. Thecore manages the configuration, steers the coupling, adjust the time step, and manages thecheckpointing, and it is presented here.
5.3.1. Interfaces and Coupling data usersAlready since the previous implementation, the adapter was decoupled from the problem-specific boundary conditions. Previously, interfaces between the solvers were created and
43
5. Implementation
1 bool Foam::functionObjects::preciceAdapterFunctionObject::2 read(const dictionary& dict)3 {4 adapter_.configure();5 return true;6 }7 bool Foam::functionObjects::preciceAdapterFunctionObject::execute()8 {9 adapter_.execute();
10 return true;11 }12 bool Foam::functionObjects::preciceAdapterFunctionObject::end()13 {14 adapter_.end();15 return true;16 }17 bool Foam::functionObjects::preciceAdapterFunctionObject::adjustTimeStep()18 {19 adapter_.adjustTimeStep();20 return true;21 }
Listing 5.1.: The public methods of the adapter’s function object are only a wrapper to therespective main methods of the adapter. This design allows to easily port theadapter to different OpenFOAM versions, which have a different interface forthe function objects.
44
5.3. The adapter’s core
they defined meshes, over which data were exchanged using preCICE. The actual datawriting and reading was handled by “coupling data users”, which were further divided into“boundary conditions” and “boundary values”, as shown in Figure 4.2. (page 37.). Having alist of all the coupling interfaces allowed to simply iterate on them and trigger the respectivewriteCouplingData() and readCouplingData() methods of each interface.
The Interface class was adopted without any design changes. The CouplingDataUserclass is still used, but it is not divided into boundary conditions and values anymore. Allthe respective subclasses inherit from the CouplingDataUser and provide both a write()and a read() method.
For more details on the coupling data users for conjugate heat transfer, read Section 5.5..
5.3.2. SteeringThe execute() method of the adapter is shown in Listing 5.2.. In this method, the steps weshow in the example of Listing 2.2. (page 16.) are implemented in the OpenFOAM adapter.The advance() method makes a call to the preCICE’s advance(). At the end of thesimulation, finalize() is called, which closes the communication channels. The respectiveinitialize() is called during the configuration phase of the adapter.
5.3.3. Adjusting the solver’s time stepAfter an advance(), the solver receives a new time step from preCICE. The solver can usea smaller time step, if it wants, in which case it is subcycling. However, it cannot use atime step that is bigger than the one allowed by preCICE.
There is a problem when OpenFOAM uses a fixed time step and is forced by preCICEto use a smaller time step once. Because the solver assumes that the time step is constant,it will not try to read it again. Therefore, whenever the solver uses a fixed time step,the adapter stores it at the first iteration and tries, at every iteration, if this time step isallowed. This does not handle the case when the user manually updates a fixed time stepduring the simulation.
The time step is updated by invoking the setDeltaT() on the reference to the solver’srunTime object. The method’s second, optional argument is set to false, so that thefunction object’s adjustTimeStep() is not called again. A const_cast<>() is required inthis case.
Note that in Listing 5.2., the call to adjustSolverTimeStep() is wrapped inside anif(!adjustableTimestep_). This happens because, in a dynamic time step case, the timestep would be updated already from the function object’s adjustTimeStep() method.
5.3.4. CheckpointingDuring an implicit coupling, the solver needs to store checkpoints of its state, meaningthe time value and its inner fields for the specific time. We re-use the methods for addingfields into a list of checkpointed fields, according to their type. These lists previously
45
5. Implementation
1 void preciceAdapter::Adapter::execute()2 {3 writeCouplingData();4
5 advance();6
7 if (isReadCheckpointRequired())8 {9 readCheckpoint();
10 fulfilledReadCheckpoint();11 }12
13 readCouplingData();14
15 // for fixed timestep16 if (!adjustableTimestep_) adjustSolverTimeStep();17
18 if (isWriteCheckpointRequired())19 {20 writeCheckpoint();21 fulfilledWriteCheckpoint();22 }23
24 if (!isCouplingOngoing())25 {26 finalize();27 const_cast<Time&>(runTime_).setEndTime(runTime_.value());28 if (preventEarlyExit_)29 {30 const_cast<Time&>(runTime_).functionObjects().end();31 }32 }33 return;34 }
Listing 5.2.: Simplified excerpt from the adapter’s execute() method. This method isexecuted in the beginning of every iteration of the time loop, starting fromthe second iteration. Therefore, the writeCouplingData() is called after theprevious iteration has been solved.
46
5.3. The adapter’s core
1 wordList objectNames_ = mesh_.lookupClass<volScalarField>().toc();2
3 forAll(objectNames_, i)4 {5 if (mesh_.foundObject<volScalarField>(objectNames_[i]))6 {7 addCheckpointField8 (9 const_cast<volScalarField&>
10 (11 mesh_.lookupObject<volScalarField>(objectNames_[i])12 )13 );14 }15 }
Listing 5.3.: Excerpt from the setupCheckpointing() method: the adapter automaticallytracks all the fields of type volScalarField into the checkpoints. The samefor volVectorField and their surface field equivalents. Previously, the fieldsto checkpoint were specified in the solver’s source code.
supported volScalarField, volVectorField, and surfaceScalarField types and nowthey are extended to surfaceVectorField types.
The required fields were previously specified in the adapted solvers’ source code. In thisimplementation, we use the lookupClass<>() templated function to request the names ofall the available fields of a specific type from the objects’ registry. In this way, we canautomatically keep a copy of all the fields of a solver, without knowing them a priori. Thisis shown in Listing 5.3..
Another feature that we extended from the previous implementation was the re-evaluationof the boundaries after reading a checkpoint. It was previously found that correcting thealphat boundaries after reading a checkpoint improved the stability of buoyantPimpleFoam.This is now done automatically for every checkpointed field, in every solver. In case anyproblems are encountered, this behavior can be disabled at the configuration file. This isshown in Listing 5.4..
5.3.5. Error handling and output
The printed messages and the errors of the adapter are managed by a special methodadapterInfo(), in most of the cases. This method formats the messages and forwardsthem to the Info, WarningInFunction, and ErrorInFunction streams of OpenFOAM.
47
5. Implementation
1 // Reload all the fields of type volScalarField2 for (uint i = 0; i < volScalarFields_.size(); i++)3 {4 // Load the volume field5 *(volScalarFields_.at(i)) == *(volScalarFieldCopies_.at(i));6 // Evaluate the boundaries, if supported7 if (evaluateBoundaries_)8 {9 try{
10 volScalarFields_.at(i)->correctBoundaryConditions();11 } catch (Foam::error) {12 DEBUG(adapterInfo("Could not evaluate the boundary for"13 + volScalarFields_.at(i)->name(), "warning"));14 }15 }16 }
Listing 5.4.: Excerpt from the readCheckpoint() method: the adapter tries to evaluatethe boundaries for all the volume fields, after reading a checkpoint. This waspreviously done only for alphat, only for buoyantPimpleFoam.
48
5.4. Configuration
1 functions2 {3 preCICE_Adapter4 {5 type preciceAdapterFunctionObject;6 libs ("libpreciceAdapterFunctionObject.so");7 }8 }
Listing 5.5.: In order to enable the adapter, place these lines in your case’s controlDictconfiguration file.
This is closer to the way that OpenFOAM handles its output than using the Boost logger.Several debug messages are defined in the adapter, which can be switched on by defining
the -DADAPTER_DEBUG_MODE flag in the build script or inside Utilities.C.In case any errors occur during the configuration phase of the adapter, they are caught
and thrown from the execute() method, as explained in Section 5.2..
5.4. Configuration
The adapter is configured by an adapter configuration file, in the YAML format, namedprecice-adapter-config.yml. Some of the options are read by the core of the adapter andare described here. Some options are problem-specific and are read by the CHT module,described in Section 5.5..
5.4.1. Activating the adapter
In order to activate the adapter, the user needs to specify a function object of typepreciceAdapterFunctionObject in the case’s controlDict configuration file, and to in-struct the solver to link to the libpreciceAdapterFunctionObject.so shared library.The name of the function object is not important. The required lines to add are shown inListing 5.5..
Other function objects may also be defined inside functions{}. However, they shouldbe placed before the adapter, as the adapter may instruct the solver to end the simulationduring a call to the execute(). In that case, other function objects’ end() methods aretriggered explicitly by the adapter.
49
5. Implementation
1 participant: Fluid2
3 precice-config-file: /path/to/precice-config.xml4
5 interfaces:6 - mesh: Fluid-Mesh7 patches: [interface]8 write-data: Temperature9 read-data: Heat-Flux
10
11 # Optional, use in special cases12 #13 # preventEarlyExit: No # Default: yes14 # evaluateBoundaries: No # Default: yes15 # subcycling: No # Default: yes16 # disableCheckpointing: Yes # Default: no
Listing 5.6.: Example for the adapter configuration file.
5.4.2. The adapter’s configuration file
The adapter’s YAML configuration file must be named precice-adapter-config.yml andbe placed in the case directory (at the same level with the time directories). An exampleconfiguration file is shown in Listing 5.6..
In this file, the participant must be one of the defined in the precice-config-file.The interfaces is a list, and every interface expects the name of the mesh for the in-terface, the OpenFOAM patch names that form the interface, as well as the names of thewrite-data and read-data defined in the precice-config.xml. These are read by theCHT module (or any other available modules).
If you want to use case files prepared for the previous CHT adapters, refer to Ap-pendix C.2..
5.4.3. Optional parameters
A few additional switches allow to control the adapter’s behavior. The preventEarlyExitcan stop the adapter from setting the solver’s end time to infinity. The evaluateBoundariescan disable the calls to correctBoundaryConditions() after reading a checkpoint anddisableCheckpointing can trick preCICE by not adding any fields to the checkpointedlist. subcycling can disallow the subcycling. These options are meant for developing anddebugging purposes.
50
5.5. The CHT module
5.5. The CHT module
Previously, the problem-specific classes were decoupled from the adapter. We continued thisapproach by grouping together all of the conjugate heat transfer related functionality intoone “module”. We do this in order to prepare the adapter for accepting different modules.
The CHT module reads additional configuration options from the YAML file, determinesthe solver type, and adds appropriate coupling data readers to the adapter’s interfaces.
Here we present the CHT-specific coupling data users, the parameters required for in-compressible and basic solvers, and the additional parameters that increase the flexibilityof this module.
5.5.1. Coupling data users for CHT
The previous “boundary conditions” and “boundary values” are now gathered in “couplingdata users” and each of them provides both the read() and write() methods. Furthermore,we now have only one file for each type of coupling data user, which contains the code for allthe three cases that we identified in Section 2.2.7.: compressible, incompressible, and basicsolvers. The CHT module determines the solver type automatically, using the availabledictionaries, or can get this information from the user.
No solver-specific users are used, like the buoyantPimpleHeatFluxBoundaryCondition.The heat flux and the heat transfer coefficient need to access the thermal conductivity of thesolver. Since each solver provides this in a different way, we delegate this to three differentclasses, KappaEff_Compressible for compressible solvers, KappaEff_Incompressible forincompressible solvers and KappaEff_Basic for basic solvers. These are the same for heatflux and for heat transfer coefficient, both for the reading and the writing of data.
We process the buffer element-by-element. Since also the basic solvers can only provideone scalar for the conductivity (instead of a field), we retrieve the conductivity element-by-element for all types of solvers, after pre-computing it, as shown in Listings 5.7. and 5.8..
For the compressible solvers, the effective conductivity is obtained directly from the tur-bulence model, as described in Section 2.2.7.. For the incompressible solvers, it is computedaccording to Equation 3.4.. In this case, the density and specific heat are expected in thetransportProperties file. For the basic solvers, the conductivity is expected in the samefile. These required properties are shown in Listing 5.9..
5.5.2. Additional parameters
The CHT module can read additional parameters from the adapter’s configuration file,which allow the adapter to cooperate with solvers that use different names for the expectedfields. Typical examples would be multi-phase solvers or in-house solvers of any kind. Theuser can also help the CHT module use the correct solver type. These parameters are shownin Listing 5.10..
51
5. Implementation
1 void preciceAdapter::CHT::HeatFlux::write(double * buffer)2 {3 int bufferIndex = 0;4 // For every boundary patch of the interface5 for (uint j = 0; j < patchIDs_.size(); j++ )6 {7 int patchID = patchIDs_.at(j);8 // Extract the effective conductivity on the patch9 extractKappaEff(patchID);
10 // Get the temperature gradient boundary patch11 scalarField gradientPatch12 =13 refCast<fixedValueFvPatchScalarField>14 (15 T_->boundaryFieldRef()[patchID]16 ).snGrad();17 // For every cell of the patch18 forAll(gradientPatch, i)19 {20 // Copy the heat flux into the buffer21 // Q = - k * gradient(T)22 buffer[bufferIndex++]23 =24 -getKappaEffAt(i) * gradientPatch[i];25 }26 }27 }
Listing 5.7.: Example of a coupling data user’s write() method. This method extracts theconductivity for all the cells, finds the appropriate patch, and computes thegradient on it. After computing the heat flux, it stores it in the coupling databuffer.
52
5.5. The CHT module
1 void preciceAdapter::CHT::KappaEff_Compressible::extract(uint patchID)2 {3 // Extract kappaEff_ from the turbulence model4 kappaEff_ = turbulence_.kappaEff() ().boundaryField()[patchID];5 }6
7 scalar preciceAdapter::CHT::KappaEff_Compressible::getAt(int i)8 {9 return kappaEff_[i];
10 }
Listing 5.8.: The effective conductivity is first extracted and stored, and later processedelement-by-element. This is done because we want to use the same write()and read() methods for all the types of solvers. While kappaEff_ in this caseis a field, it is only one scalar in basic solvers, the same for every cell.
1 // Additional parameters for incompressible solvers2 rho rho [ 1 -3 0 0 0 0 0 ] 50;3 Cp Cp [ 0 2 -2 -1 0 0 0 ] 5;4
5 // Additional parameters for basic solvers6 k k [ 1 1 -3 -1 0 0 0 ] 100;
Listing 5.9.: For incompressible and for basic solvers, the adapter requires additional mate-rial properties to be specified in the transportProperties dictionary.
53
5. Implementation
1 # Temperature field2 nameT: T3 # transportProperties dictionary4 nameTransportProperties: transportProperties5 # thermal conductivity6 nameKappa: k7 # density8 nameRho: rho9 # heat capacity for constant pressure
10 nameCp: Cp11 # Prandtl number12 namePr: Pr13 # turbulent thermal diffusivity14 nameAlphat: alphat15
16 # Manual configuration of the solver's type17 solverType: compressible
Listing 5.10.: The adapter can also support solvers with different names for the requiredfields. You may specify any of these options in the configuration file. In casethe solver type is not correctly determined, you may also manually specifythis here.
54
5.6. Designed with extensibility in mind
5.6. Designed with extensibility in mindThe adapter was designed with extensibility in mind, since the beginning. In order to keep itcompatible with more OpenFOAM versions, the function object interface was kept separatefrom the main adapter. Instructions in Appendix A. aim to assist in porting the adapter toa different version.
The problem-specific operations were also isolated in “modules”, which can define theirown additional classes and read additional configuration. We currently provide only aconjugate heat transfer module, but we describe in the comments of the code what wouldbe needed in order to create an additional module. Look for comments with the “NOTE:”mark to guide you through the process. You may also find more information in the adapter’sREADME.md file.
55
6. Validation
The previous OpenFOAM adapters for conjugate heat transfer have been extensively vali-dated against experimental data and against the monolithic CHT-solvers of OpenFOAM [7.].The proposed adapter should not affect the numerical results and this section compares theproposed and the previous adapters for a number of cases.
Each case tests a different set of features and solvers. In Section 6.1., we simulate the flowover a heated plate: a forced convection scenario previously validated against experimentaldata. In Section 6.1.1., we use the transient, compressible solver buoyantPimpleFoam forthe fluid and the basic solver laplacianFoam for the solid. We perform a serial-implicitcoupling with Dirichlet-Neumann boundary conditions. In Section 6.1.2., we replace the flowsolver with the incompressible buoyantBoussinesqPimpleFoam. In Section 6.1.3., we usethe steady-state solver buoyantSimpleFoam for the fluid and we perform a serial-explicitcoupling to CalculiX (a different simulation software) for the solid. We also test the Robin-Robin coupling. Section 6.2. presents a more complex scenario (tube-and-shell heat ex-changer) with multiple participants, parallel-explicit coupling and parallel execution.
All the cases were simulated using the same OpenFOAM version, in order to avoid anydifferences in the results originating from OpenFOAM itself. For this, the previous adaptersand solvers were ported to compile against version 5.0. In the case of the previous adapters,the adapted and modified variants of the solvers are used. For the proposed adapter, theoriginal solvers are used.
The results of the proposed adapter were identical to the results of the previous adapters,or with a relative difference in the order of 10−6, in most of the cases.
Section Fluid Solid Coupling BC Other features6.1.1. BPF LF implicit D-N compressible, basic, subcycling6.1.2. BBPF LF implicit D-N incompressible, checkpointing6.1.3. BSF CCX explicit R-R steady-state, other software6.2. BSF CCX explicit R-R multiple interfaces, parallel
Table 6.1.: Overview of the validated cases. Abbreviations: BPF: buoyantPimpleFoamsolver, LF: laplacianFoam, BBPF: buoyantBoussinesqPimpleFoam, BSF:buoyantSimpleFoam, CCX: CalculiX, D-N : Dirichlet-Neumann, R-R: Robin-Robin.
57
6. Validation
Figure 6.1.: Geometry and boundary conditions of the heated plate scenario. The width ofthe solid is set to b = L/4. [7.]
6.1. Flow over a heated plate
The previous adapters have been validated against the flat plate scenario described byVynnycky et al. [19.]. This scenario describes a flow inside a channel that is in contact witha thick solid. The bottom boundary of the solid is maintained at a constant temperature,while the fluid is also injected with a constant, lower temperature. The rest of the wallsare adiabatic. As for the velocity, the bottom boundary is set to slip before the plateand to no-slip everywhere else. The geometry and the boundary conditions are shown inFigure 6.1..
This case has previously been validated for 12 different combinations of the Reynoldsnumber, the Prandtl number and the conductivity ratio k = ks/kf. We considered onecombination to be enough to validate the proposed adapter against the previous adapters.We chose the first combination, which refers to Re = 500, Pr = 0.01, and k = 1.
In the flow region above the plate, the fluid is heated. A non-dimensional temperature isused to describe this change:
θ =T − T∞Ts − T∞
. (6.1)
6.1.1. buoyantPimpleFoam – laplacianFoam coupling
We start the validation process by using OpenFOAM solvers for both the fluid and thesolid. The solver buoyantPimpleFoam is used for the fluid, while the laplacianFoam isused for the solid.
In this setup, Dirichlet-Neumann boundary conditions are used: The fluid participantwrites temperatures and reads heat fluxes, while the solid participant expects the opposite.A serial-implicit coupling scheme is demonstrated, with classical interface quasi-Newton(IQN-ILS) post-processing and consistent nearest-neighbor mapping for both coupled fields.Both participants are executed in serial.
Both the fluid and the solid solvers are using a time step of 0.01 s, the same as the couplingtime step. The maximum simulated time is 10 s.
58
6.1. Flow over a heated plate
1 <coupling-scheme:serial-implicit>2 <timestep-length value="0.01"/>3 <max-time value="10"/>4 <max-iterations value="200"/>5 <participants first="Fluid" second="Solid"/>6 <exchange data="Temperature" mesh="Fluid-Mesh" from="Fluid" to="Solid"/>7 <exchange data="Heat-Flux" mesh="Fluid-Mesh" from="Solid" to="Fluid"/>8 <relative-convergence-measure limit="1.0e-6" data="Temperature"9 mesh="Fluid-Mesh" suffices="0"/>
10 <extrapolation-order value="2"/>11 <post-processing:IQN-ILS>12 <data mesh="Fluid-Mesh" name="Heat-Flux" />13 <initial-relaxation value="0.01" />14 <max-used-iterations value="80" />15 <timesteps-reused value="10" />16 <filter type="QR1" limit="1e-8" />17 </post-processing:IQN-ILS>18 </coupling-scheme:serial-implicit>
Listing 6.1.: Excerpt from the preCICE configuration file for the flat plate scenario withbuoyantPimpleFoam and laplacianFoam: Configuration of the serial-implicitcoupling scheme.
The serial-implicit coupling scheme uses IQN-QLS post-processing, with the configurationshown in Listing 6.1., and 2nd order extrapolation.
The mesh is created with blockMesh and it consists of 293× 41× 2 hexahedral cells forthe fluid and of 32 × 16 × 16 hexahedral cells for the solid. Mesh stretching is applied onthe fluid mesh, near the interface with the plate. The mesh is shown in Figure 6.2..
The overview of the temperature results is shown in Figure 6.3.. As the temperaturedistributions in both cases seem to be the same, let’s take a closer look on the result files.
OpenFOAM can write results using its own, ASCII or binary format. When using thehuman-readable (ASCII) format, we can specify the precision of the results by adjusting theparameter writePrecision. By default, the results are written with 6 significant digits.Afterwards, the user may convert the results to the (ASCII or binary) VTK format1
.. TheASCII VTK files are written with 6 significant digits.
In the case we simulated, writePrecision was set to 7. Examining the results at t = 10 s(i.e. after 1000 time steps), they are almost identical. In particular, we noticed sporadicdifferences in the last digit of the temperature, as well as to other fields. Increasing
1Human-readable VTK files can be produced with the command foamToVTK -ascii.
59
6. Validation
Figure 6.2.: Mesh for the buoyantPimpleFoam – laplacianFoam flat plate simulation.
(a) Proposed adapter.
(b) Previous adapters.
Figure 6.3.: Flat plate scenario using buoyantPimpleFoam – laplacianFoam: temperaturedistributions for the proposed (a) and for the previous (b) adapters. The erroris less than 10−6. (Re = 500, Pr = 0.01, and k = 1)
60
6.1. Flow over a heated plate
writePrecision to 12, we see that the errors are even smaller, in which case the tem-perature values are identical in the VTK files. The relative errors on the temperaturegradient and velocity per x and y are in the order of 10−6. Larger errors appear in thetemperature gradient and velocity per z. However, this is not considered to be relevant inthis case, since only two cells are defined per z-dimension. A possible explanation for thedifferences could be the re-evaluation of the boundaries for all the checkpointed fields afterreading a checkpoint. Previously, this was done only for the turbulent thermal diffusivity,which is not used in this case.
We tested this case also for subcycling. The fluid participant was adjusted to use a timestep of 0.003 s, while the solid participant and the coupling used 0.010 s. The solver’s timestep was adjusted to 0.001 s whenever approaching a coupling time. The checkpointingworked seamlessly with subcycling, reloading the correct time and data. The adapter alsoworked correctly with adjustable time step.
We can conclude that no significant errors were introduced in this case, which used acompressible and a basic solver for Dirichlet-Neumann implicit coupling, since the relativeerrors per x and y in this 2D case are either zero, or in the order of the results’ precision.
6.1.2. buoyantBoussinesqPimpleFoam – laplacianFoam coupling
In this section, we test the incompressible flow solver buoyantBoussinesqPimpleFoam. Weperform again a serial-implicit coupling to laplacianFoam with Dirichlet-Neumann bound-ary conditions, but in this case, the fluid participant writes heat fluxes and reads tempera-tures, while the solid participant expects the opposite.
The density and heat capacity are set to ρ = 1 kg/m3 and Cp = 5000 m2/(s2K), respec-tively. The viscosity and Prandtl number are set again to ν = 2 × 10−4 m2/s and Pr = 0.01.This corresponds again to the first combination of Re, Pr, and k.
We use nearest-neighbor mapping again and Aitken underrelaxation post-processing, withinitial relaxation factor of 0.1. Both participants use a time step of 0.01 s, the same as thecoupling time step, and both participants are executed in serial.
The temperature distributions are not different from the ones shown in Figure 6.3.. Thetemperature differences are in the order of 10−6. However, larger differences appear inthe region around the interface for the velocity and temperature gradient, as shown inFigure 6.4.. The maximum relative differences are in the order of 10−2. This hints thatthere is a problem with the checkpointing: the coupled variables are correct, but the stateof the solver is different. The errors propagate into the domain during the coupling steps,but they are not corrected afterwards.
Taking a closer look to the previously adapted buoyantBoussinesqPimpleFoam solver,we observe that checkpointing is not fully implemented: no fields are added into the check-points. We repeat the simulation, after adding the available fields to the list of checkpointedfields, and the results of the previous adapter are the same to the results of the porposedadapter.
61
6. Validation
Relative errors in the solid
Rel
ativ
e er
ror
0
0.0005
0.001
0.0015
0.002
y0 0.05 0.1 0.15 0.2 0.25
Error in gradTxError in gradTyError in T
(a) Differences of the temperature and tem-perature gradient in the solid.
Relative errors in the fluid
Rel
ativ
e er
ror
0
0.02
0.04
0.06
0.08
0.1
y0.25 0.3 0.35 0.4 0.45 0.5 0.55 0.6 0.65 0.7 0.75
Error in UyError in UxError in T
(b) Differences of the temperature and veloc-ity in the fluid.
Figure 6.4.: Initial relative differences for the solid (a) and fluid (b), compared to the pre-vious adapters, at x = 0.5 m and t = 10 s (Re = 500, Pr = 0.01, and k = 1).The buoyantBoussinesqPimpleFoam and laplacianFoam solvers are used inthis case. The differences are higher near the interface (y = 0.25 m). Thiseffect originates from the incomplete implementation of checkpointing in thepreviously adapted buoyantBoussinesqPimpleFoam solver and the differencesdisappear when we enable checkpointing for the available fields in the previousimplementation. Although that problem was fixed, this figure emphasizes theneed for checkpointing in implicit coupling.
62
6.1. Flow over a heated plate
Figure 6.5.: Mesh for the OpenFOAM - CalculiX flat plate simulation.
We can conclude that the proposed adapter introduced no significant errors for the tem-perature in this case, which used an incompressible and a basic solver for Dirichlet-Neumannimplicit coupling. Although relative differences of up to the order of 10−2 were initially ob-served for the temperature gradient and velocity near the interface, these differences werefound to be caused by a problem in the previous implementation and disappeared after thisbug was fixed.
6.1.3. buoyantSimpleFoam – CalculiX couplingIn this section we test the compressible, steady-state flow solver buoyantSimpleFoam andthe coupling with another simulation software for the solid. We use CalculiX 2.12, with itsofficial preCICE adapter2
..We perform a serial-explicit coupling, with Robin-Robin boundary conditions (both par-
ticipants write and read heat transfer coefficients and sink temperatures) and nearest-neighbor mapping.
We simulate again the combination Re = 500, Pr = 0.01, and k = 1. The height of theflow domain is set to 1.25 m and its mesh is shown in Figure 6.5..
The result VTK files are exactly identical for all the fields and times. The non-dimensionaltemperature on the interface, as well as on a line at x = 0.5 m from the leading edge of theplate, after 500 coupling iterations, are shown in Figure 6.6..
We can conclude that the new adapter introduced no significant errors in this case, whichused a compressible steady-state solver for Robin-Robin explicit coupling.
2Official preCICE adapter for CalculiX [7.]: https://github.com/precice/calculix-adapter ..
63
6. Validation
θ-temperature on the interface
θ
0.35
0.4
0.45
0.5
0.55
0.6
0.65
x0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Previous adaptersProposed adapter
(a) θ on the Fluid-Solid interface. The twolines are identical.
θ-temperature at x=0.5
θ
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
y-distance from the interface0 0.2 0.4 0.6 0.8 1 1.2
Previous adaptersProposed adapter
(b) θ in the fluid per distance from the plate.The two lines are identical.
Figure 6.6.: Non-dimensional temperature for the flat plate scenario, using buoyantSimple-Foam (steady-state) and CalculiX, after 500 iterations (Re = 500, Pr = 0.01,and k = 1). The results are identical.
64
6.2. Tube-and-shell heat exchanger
6.2. Tube-and-shell heat exchangerIn this section, we validate a more complex scenario, with multiple participants: a shell-and-tube heat exchanger. This device transfers heat between two fluids, which are separated bythe exchanger’s solid walls. The geometry of the device is shown in Figure 6.7.. The onefluid enters from the left and flows inside the tubes (inner fluid). The other fluid enters fromthe top and flows in the volume between the tubes and the outer shell. Barriers (“baffles”)are used to redirect the flow, in order to increase the contact time. We are interested inthis scenario, as this is a potential application of the adapter in industrial problems.
In this case, parallel-explicit coupling is used, with Robin-Robin boundary conditions andnearest-neighbor mapping. Three participants are used: one for the flow inside the tubes(inner fluid), one for the solid, and one for the flow between the tubes and the shell (outerfluid). Two coupling interfaces are defined: one between the inner fluid and the solid, andone between the solid and the outer fluid, as shown in Figure 6.8.. All the participants areexecuted in parallel.
In the simulated scenario, the inner fluid at the inlet has temperature 283 K and velocity0.002 m/s, while the outer fluid is inserted at 353 K, with 0.0037 m/s. The outer walls ofthe shell are considered adiabatic. The mesh is shown in Figure 6.9.. More informationabout this case can be found in the thesis of Cheung Yau [7.], where the previous adaptersare validated against the steady-state CHT solver of OpenFOAM.
The results after 500 coupling iterations are shown in Figure 6.10.. Again, all the resultfiles of the proposed adapter are identical to the ones of the previous adapters, at all theexported times. We conclude that the adapter did not introduce any significant results inthis case, which involved a complex geometry, multiple participants, and parallel execution.
Figure 6.7.: Geometry of the heat exchanger case [7.].
65
6. Validation
Figure 6.8.: Coupling of the participants in the heat exchanger case. Three participantsare used (inner fluid, solid, outer fluid). Each fluid participant is connected tothe solid participant, but the two fluid participants are not connected to eachother.
Figure 6.9.: Mesh of the heat exchanger case (clip) [7.].
66
6.2. Tube-and-shell heat exchanger
(a) Temperature distribution.
(b) Temperature distribution with streamlines.
(c) Midplane cut.
Figure 6.10.: Temperature distribution in the heat exchanger case, for the proposed adapter,using buoyantSimpleFoam and CalculiX. The results are identical to ones fromthe previous adapters. The solid is omitted.
67
7. Conclusions
In this thesis, we designed, developed and validated a general adapter for OpenFOAMto enable multi-physics simulations with the coupling library preCICE. Our study wasbased on a set of solver-specific adapters for conjugate heat transfer previously developedby Lucia Cheung Yau at the Technical University of Munich, in cooperation with SimScaleGmbH. The adapter that we propose applies to a wider set of OpenFOAM solvers, is moreconfigurable, and can be plugged in at runtime without requiring any modifications to thesolver’s source code – an extra step that previously raised difficulties for the user.
In order to overcome the need for solver-specific adapters, we identified the elements thatare shared between them and integrated these elements into the adapter. One such elementwas the turbulence model implementation, as this was affecting the way the heat transfercoefficient was calculated, a coefficient necessary to convert the exchanged heat fluxes totemperatures on the boundaries. This calculation was previously handled by (in some casessolver-specific) boundary condition classes, classes that we have unified and simplified.
Our proposed adapter not only allows for higher compatibility, but also makes the prepa-ration stage easier because it can simply be “plugged-in” at runtime. Up to now, thisrequired additional changes in the solver’s source code. This was achieved by wrapping theadapter into a function object, a pattern also used by bundled post-processing tools.
Our adapter is also more flexible. The solver-specific parameters are read from theOpenFOAM configuration files (dictionaries) and the user does not need to specify themelsewhere. The boundary conditions on the interfaces are configured through the adapter’sconfiguration file (YAML) and have been extended to support more solvers. The adaptercan now directly read any additionally required material properties from the case files,instead of requiring modifications to the solver to read them. In case a solver uses differentnames for the required fields, these are also configurable.
Some features were extended and generalized. The proposed adapter automatically check-points all the registered fields and corrects the values on the boundary faces for all the fieldsafter reading a checkpoint. This was previously implemented only for buoyantPimpleFoam,for the field alphat, as it had been found to help the stability of the solution.
We validated the proposed adapter with multiple solvers, for two scenarios. The firstone was a flow over a heated plate, described in [19.]. In most of the cases, the result filesusing the proposed adapter were identical to the files that were produced using the previousadapters. In some cases, sporadic errors in the order of the results’ precision were observed.In the case of the buoyantBoussinesqPimpleFoam, a problem was discovered and correctedin the previous implementation, which was an example for the need for checkpointing inimplicit coupling. The second scenario was a shell-and-tube heat exchanger, a complex
69
7. Conclusions
geometry problem with multiple participants. We simulated this case with the steady-statefluid solver buoyantSimpleFoam and CalculiX running in parallel and the result files wereidentical to the files obtained with the previous adapters.
The following features were examined in the validation cases:
• explicit coupling,
• implicit coupling,
• checkpointing and subcycling,
• dynamic solver’s time step,
• Dirichlet-Neumann and Robin-Robin coupling,
• serial and parallel execution,
• coupling to other simulation software,
• coupling with multiple participants,
• compressible, incompressible and basic solvers.
All the scenarios were validated using nearest-neighbor mapping. We did not extend the pre-vious implementation to nearest-projection mapping. We also did not extend the read/writefunctionality to vector data, a feature that can be developed and tested in the future, inthe context of developing a module for mechanical fluid-structure interaction. This modulewas not developed in this thesis, as considerable amount of time should be devoted intosetting up appropriate validation cases and comparing to experimental data.
This work makes preCICE compatible with a wide range of OpenFOAM solvers usedwidely in both academia and industry. This brings preCICE not only closer to users butalso to developers. Being designed with extensibility in mind, our proposed adapter couldbe equipped with additional boundary conditions for mechanical fluid-structure interactionor other computational fields, making multi-physics simulations more accessible. In thisdirection, the adapter could be ported to older versions and other variants of OpenFOAM.Test cases should be developed, in order to make the continuous development of the adapterfor multiple OpenFOAM versions easier. Additionally, tutorials would help to reach newusers. In order to convince the OpenFOAM community, examples that highlight the ad-vantages of preCICE over the monolithic OpenFOAM solvers for conjugate heat transfershould be presented. Developing additional modules for mechanical fluid-structure interac-tion or acoustics would help to establish preCICE and OpenFOAM as standard componentsof multi-physics simulations, leading to benefits for both communities.
70
A. Compatible OpenFOAM versions
OpenFOAM is a project with a long history and several forks. In this thesis, we workedwith the latest stable version developed by the OpenFOAM Foundation1
.. We refer to thisas “the main OpenFOAM”. This was previously developed by the ESI Group, the companythat owns the OpenFOAM trademark and that still develops its own variant, often referredto as OpenFOAM+2
.. More companies and institutions have also been part of the project’slineage. The origin of the project is attributed to researchers of the Imperial College, inthe late 80’s. Widely known is also the fork foam-extend3
., a project that is based on olderversions of OpenFOAM and that includes additional community contributions. Althoughpartially compatible, the different variants and major versions are often incompatible withone another. Our adapter was designed with this problem in mind.
The proposed adapter is designed for OpenFOAM 5.0, the latest stable version at thetime. However, the same code has been tested and works also for OpenFOAM 4.1 and for thelatest OpenFOAM-dev build dev-c2ea77a4b856 (24/10/2017). It also compiles successfullyagainst OpenFOAM v1706 (openfoam.com).
We focused on the OpenFOAM variant from the OpenFOAM Foundation for severalreasons. Providing a reduced but stable set of features, it is the best starting point fordeveloping a general adapter that can be supported also by other variants. The OpenFOAMvariant from the ESI-OpenCFD team usually adopts the core changes of openfoam.org,making the two projects compatible. On the other hand, foam-extend follows behind, stillbeing based on older OpenFOAM versions. The version 4.0 of foam-extend is not compatiblewith the version 4.0 of openfoam.org. Moreover, it incorporates many community-providedcontributions, which usually do not find their way into the other projects.
The three projects have also other important differences. OpenFOAM provides its codefreely available on GitHub4
., while OpenFOAM+ uses its own GitLab server5., which requires
a user to create a (free) account in order to get access to it. The foam-extend project ishosted at SourceForge6
., while an unofficial mirror on GitHub also exists7.. The quality of the
documentation for each project is also different. OpenFOAM and OpenFOAM+ providesources of similar quality, while foam-extend seems to lack in this aspect.
1OpenFOAM: https://openfoam.org/..2OpenFOAM+: http://openfoam.com/..3foam-extend: http://wikki.gridcore.se/foam-extend ..4OpenFOAM on GitHub: https://github.com/OpenFOAM..5OpenFOAM+ GitLab server: https://develop.openfoam.com/..6foam-extend on SourceForge: https://sourceforge.net/projects/foam-extend/ ..7foam-extend on GitHub: https://github.com/Unofficial-Extend-Project-Mirror ..
71
A. Compatible OpenFOAM versions
The proposed adapter is not currently compatible with older versions of OpenFOAM orwith foam-extend, but it can be ported to these versions and variants. Read more aboutthis in Section A.2.3.. Table A.1. shows a summary of the compatible OpenFOAM versions.
OpenFOAM version Compiles Tested NotesOpenFOAM-dev (.org) Yes Yes build dev-c2ea77a4b856 (24/10/17)OpenFOAM 5.0 (.org) Yes YesOpenFOAM 4.1 (.org) Yes YesOpenFOAM 3.0.1 (.org) No No can be ported toOpenFOAM 2.2.x No No can be ported toOpenFOAM 1.7.x No No can be ported to (with limitations)OpenFOAM v1706 (.com) Yes Nofoam-extend 4.0 No No can be ported to (with limitations)
Table A.1.: Compatibility of the provided adapter with OpenFOAM versions and variants.
A.1. Porting to a different OpenFOAM version
The user may want to use OpenFOAM with preCICE in a version not listed here. Theadapter may also become incompatible with future OpenFOAM releases. This sectionprovides some initial instructions on porting it to a different version. In any case, the useris encouraged to contribute by opening issues or pull requests in the adapter’s repository8
..In order to resolve compilation errors in another OpenFOAM version, the first step should
be to read the release notes of the versions in between. Look for terms such as “backwardscompatibility”, “redesigned”, or “rewritten”. If this doesn’t help, the next step should beto search the commits on GitHub for relevant keywords.
Another approach that could help is to compare relevant source files (e.g. solvers) betweenthe two versions. Diff tools such as Meld9
. could help.Other useful resources are the C++ Source Code Guide10
. (i.e. Doxygen documentation)and user forums such as the CFD Online11
.. While searching, it may help to specify thesearch date range to start after the new version was released.
8preCICE on GitHub: https://github.com/precice..9Meld: http://meldmerge.org/..
10OpenFOAM C++ Source Code Guide, version 5 [15.].11CFD Online: https://www.cfd-online.com/ ..
72
A.2. Known differences among OpenFOAM versions
A.2. Known differences among OpenFOAM versionsA.2.1. OpenFOAM v5 – OpenFOAM v4Between these versions there are no changes that are known to affect the adapter. Thesame source code builds and runs successfully in both versions.
In the case of the adapted solvers used in the previous CHT adapters, the solversbuoyantPimpleFoam and buoyantSimpleFoam need a small change in their EEqn.H file. Inparticular, the call radiation->Sh(thermo, he) is replaced by radiation->Sh(thermo)in order for the code to build successfully. For the complete list of changes in these solvers,compare the source files of their non-adapted variants.
A.2.2. OpenFOAM v4 – OpenFOAM v3The following changes between versions 3 and 4 are known to affect the adapter. A fewchanges in the adapter’s source code are needed for it to work with version 3.
Access to the boundaryField, internalField
The way to access the boundaryField data changed in OpenFOAM 4.0. In the releasenotes12
. it is stated:
Robust data handling: new convention for const and non-const reference func-tions of fields where the non-const function uses …Ref(); for example, whereboundaryField() provides the const reference to the boundary field,boundaryFieldRef() provides a non-const reference. for tmp objects, non-const access uses a ref() function rather than the () dereferencing operator.
The OpenFOAM-dev commit a4e2afa . on GitHub explains this in more detail. The accessalso to internalField data has changed13
..
Turbulence models
The turbulence models class structure changed in version 4.0, introducing the templatedlibrary TurbulenceModels. More information can be found in the description of theOpenFOAM-4.x commit 93732c8..
Function objects
The code structure of function objects was redesigned and simplified in version 4.0, asdescribed in the OpenFOAM-4.x commit 91aba2d.. Having this in mind, the adapter’sfunction object was defined in the file preciceAdapterFunctionObject.C, separately from12OpenFOAM 4.0 release notes: https://openfoam.org/release/4-0/ ..13OpenFOAM Issue Tracking, issue 2134: https://bugs.openfoam.org/view.php?id=2134..
73
A. Compatible OpenFOAM versions
the main adapter methods, in order to make it easy to minimize the effects of a change inthe function objects structure. The preciceAdapterFunctionObject.C serves only as awrapper to the main adapter. In order to port it to a different version, convert this file (andits respective header) to the target version, according to the template found in $FOAM_ETC/.It is suggested that you start from this template and call the respective (few) main methodsof the adapter.
A.2.3. Older versions of OpenFOAM and other variantsThe main concepts (function objects, object registry) date back to at least versions 2.2.x14
..Function objects are also supported in previous releases (at least versions 1.7.x15
. ), but donot provide the same variety of public methods. In particular, the method adjustTimeStep()is not available in either OpenFOAM 1.7.x or foam-extend 4.0, limiting the support to fixedtime step only. However, this functionality could also be implemented in the execute()method if needed. Two other missing methods are the updateMesh() and movePoints(),which are not used in the current implementation, but would be needed in an FSI module.The object registry also dates back to at least OpenFOAM 1.7.x.
14OpenFOAM 2.2.x repository on GitHub: https://github.com/OpenFOAM/OpenFOAM-2.2.x ..15OpenFOAM 1.7.x repository on GitHub: https://github.com/OpenCFD/OpenFOAM-1.7.x ..
74
B. OpenFOAM function objects - details
The function objects are a very important OpenFOAM feature for our adapter, since theyallow us to link any solver to the adapter during runtime, without modifying or rebuildingthe solver’s code. In order to better understand the way their respective methods are called,we list here excerpts from the involved classes. An overview is shown in Figure 2.4. (page 23.).
Listing B.1. shows the methods that we define. Listing B.2. shows how these methods arecalled in the context of the list of specified function objects and Listing B.3. shows how theexecute() method of the list is called whenever the time loop evolves. Finally, Listings B.4.
and B.5. show what happens when the time step size or the mesh nodes are modified.
75
B. OpenFOAM function objects - details
1 class functionObject2 {3 // ...4
5 public:6
7 // ...8
9 //- Read and set the function object if its data have changed10 virtual bool read(const dictionary&);11
12 //- Called at each ++ or += of the time-loop.13 // postProcess overrides the usual executeControl behaviour and14 // forces execution (used in post-processing mode)15 virtual bool execute() = 0;16
17 //- Called at each ++ or += of the time-loop.18 // postProcess overrides the usual writeControl behaviour and19 // forces writing always (used in post-processing mode)20 virtual bool write() = 0;21
22 //- Called when Time::run() determines that the time-loop exits.23 // By default it simply calls execute().24 virtual bool end();25
26 //- Called at the end of Time::adjustDeltaT() if adjustTime is true27 virtual bool adjustTimeStep();28
29 //- Update for changes of mesh30 virtual void updateMesh(const mapPolyMesh& mpm);31
32 //- Update for changes of mesh33 virtual void movePoints(const polyMesh& mesh);34 };
Listing B.1.: Excerpt from the Foam::functionObject class. Function objects definethese methods, which are triggered from the Foam::functionObjectListclass. The comments are also drawn from the source code. Note that theexecute() and write() are called inside the Time::run() and not inside theTime::operator++() or Time::operator+=(), as stated in the comments.
76
1 bool Foam::functionObjectList::start()2 {3 /* Calls each object's read() */4 return read();5 }6
7 bool Foam::functionObjectList::execute()8 {9 /* Calls each object's execute() and write() */
10 bool ok = true;11 if (execution_)12 {13 if (!updated_) read();14 forAll(*this, objectI)15 {16 ok = operator[](objectI).execute() && ok;17 ok = operator[](objectI).write() && ok;18 }19 }20 return ok;21 }22
23 bool Foam::functionObjectList::end()24 { /* Calls each object's end(), in the same way */ }25
26 bool Foam::functionObjectList::adjustTimeStep()27 { /* Calls each object's adjustTimeStep(), in the same way */ }28
29 void Foam::functionObjectList::updateMesh(const mapPolyMesh& mpm)30 { /* Calls each object's updateMesh(mpm), in the same way */ }31
32 void Foam::functionObjectList::movePoints(const polyMesh& mesh)33 { /* Calls each object's movePoints(mesh), in the same way */ }
Listing B.2.: Excerpt from the Foam::functionObjectList class. Notice where each func-tion object’s read(), execute(), and write() are called. The methods ofFoam::functionObjectList are triggered from the Foam::Time or from theFoam::polyMesh classes. The comments are not present in the source code.
77
B. OpenFOAM function objects - details
1 bool Foam::Time::run() const2 {3 bool running = value() < (endTime_ - 0.5*deltaT_);4 if (!subCycling_)5 {6 if (!running && timeIndex_ != startTimeIndex_)7 {8 functionObjects_.execute();9 functionObjects_.end();
10 }11 }12 if (running)13 {14 if (!subCycling_)15 {16 const_cast<Time&>(*this).readModifiedObjects();17 if (timeIndex_ == startTimeIndex_)18 {19 functionObjects_.start();20 }21 else22 {23 functionObjects_.execute();24 }25 }26 running = value() < (endTime_ - 0.5*deltaT_);27 }28 return running;29 }30 bool Foam::Time::loop()31 {32 bool running = run();33 if (running) operator++();34 return running;35 }
Listing B.3.: The Foam::Time::run() and loop() methods. The subCycling_ flag tem-porarily skips the execution of the function objects methods. After the func-tion objects are executed, running is re-evaluated. At the end time, runningbecomes false, the time loop exits and the function objects are not called again.
78
1 void Foam::Time::adjustDeltaT()2 {3 bool adjustTime = false;4 // ...5 if (writeControl_ == wcAdjustableRunTime)6 {7 adjustTime = true;8 // ...9 }
10 if (adjustTime)11 {12 // (adjust the time step) ...13 }14 functionObjects_.adjustTimeStep();15 }
Listing B.4.: Excerpt from the Foam::Time::adjustDeltaT() method. Notice the calls tomethods of the functionObjects_ list.
1 void Foam::polyMesh::updateMesh(const mapPolyMesh& mpm)2 {3 // (Updating addressing and (optional) pointMesh/pointFields) ...4
5 const_cast<Time&>(time()).functionObjects().updateMesh(mpm);6 }7
8 Foam::tmp<Foam::scalarField> Foam::polyMesh::movePoints9 (
10 const pointField& newPoints11 )12 {13 // (moving points for the current time) ...14
15 const_cast<Time&>(time()).functionObjects().movePoints(*this);16 // (output and return) ...17 }
Listing B.5.: Excerpt from the Foam::polyMesh::updateMesh() and movePoints() meth-ods. Notice the calls to methods of the functionObjects_ list.
79
C. Previous CHT adapters - details
C.1. Implementation detailsIn order to better understand the structure of the previous CHT adapters, we presenthere excerpts from the most important source files. In Listing C.1., the adapted solverbuoyantPimpleFoam is listed. The original parts of the solver are replaced by comments.
The adapted solver constructs an object of the class BuoyantPimpleFoamAdapter, whichcalls its createInterfacesFromConfigFile() (Listing C.2.) inside its constructor. Thissolver-specific adapter is a subclass of the Adapter class (Listing C.3.), which provides therest of the methods. This is shown schematically in Figure 4.1. (page 35.).
C.2. Using case files prepared for the old adaptersCases prepared for the previous adapters can be ran with the proposed adapter, afterapplying the following changes:
1. The original, non-adapted solvers must be used. Adjust any run scripts to usei.e. laplacianFoam instead of laplacianFoam_preCICE. Additionally, remove the-precice-participant, -config-file, or -disable-checkpointing options.
2. The original laplacianFoam solver expects the DT parameter to be defined in thetransportProperties and a rule for DT in the laplacianSchemes options of thefvSchemes file. DT has dimensions [ 0 2 -1 0 0 0 0 ] and can be computed ask / rho / Cp. The rho and Cp can be removed.
3. The configuration file needs to be named precice-adapter-config.yml and to bepresent in the case directory. The old file, usually named config.yml, can be keptfor other adapters.
4. The precice-adapter-config.yml must provide the participant (instead of theparticipants) and precice-config-file nodes. Only one interfaces node isexpected (since no other participants need to read this file) and it needs to be top-level. No other changes are required. In case additional options are provided, whichare not described in Section 5.4.2., they are ignored.
5. Follow the instructions described in Section 5.4.1. to enable the adapter.
81
C. Previous CHT adapters - details
1 // additional arguments for the precice config and participant name...2
3 adapter.addCheckpointField( U );4 // add more checkpointed fields...5 adapter.initialize();6
7 while( adapter.isCouplingOngoing() )8 {9 // compute time step size (as in the original solver)...
10
11 adapter.adjustSolverTimeStep();12 if( adapter.isWriteCheckpointRequired() )13 {14 adapter.writeCheckpoint();15 adapter.fulfilledWriteCheckpoint();16 }17
18 runTime++;19
20 adapter.readCouplingData();21
22 // solve (as in the original solver)...23
24 adapter.writeCouplingData();25 adapter.advance();26
27 // Read checkpoint if required (similarly to write)...28 // For this solver, additionally, for stability:29 // turbulence->alphat() ().correctBoundaryConditions();30
31 if( adapter.isCouplingTimeStepComplete() )32 {33 runTime.write();34 }35 }
Listing C.1.: Excerpt from the previously adapted buoyantPimpleFoam solver. Calls to theadapter’s methods are added before the time loop, as well as before and afterthe equations are solved. The adapter.isCouplingOngoing() replaces theoriginal solver’s while-condition.
82
C.2. Using case files prepared for the old adapters
1 void BuoyantPimpleFoamAdapter::createInterfacesFromConfigFile(...)2 {3 ConfigReader config( configFile, participantName );4
5 for( /* all the interfaces */ )6 {7 Interface * interface =8 new Interface( *_precice, _mesh, /* mesh and patch names */ );9 _interfaces.push_back( interface );
10
11 for( /* all the coupling data writers */ )12 {13 std::string dataName = config.interfaces().at(i).writeData.at(j);14
15 if( dataName.compare( "Temperature" ) == 0 )16 {17 TemperatureBoundaryValues * bw =18 new TemperatureBoundaryValues( _thermo.T() );19 interface->addCouplingDataWriter( dataName, bw );20 }21 else if( dataName.compare( "Heat-Flux" ) == 0 )22 {23 BuoyantPimpleHeatFluxBoundaryValues * bw =24 new BuoyantPimpleHeatFluxBoundaryValues( _thermo.T(),25 _thermo, _turbulence );26 interface->addCouplingDataWriter( dataName, bw );27 }28 // Similarly for "Heat-Transfer-Coefficient" and "Sink-Temperature",29 // using "find" instead of "compare", to handle multiple interfaces.30 }31 // Similarly for all the coupling data readers...32 }33 }
Listing C.2.: Excerpt from the buoyantPimpleFoamAdapter class (previous CHT adapters).This method is called by the constructor. Notice that the heat fluxes arecomputed by a solver-specific class BuoyantPimpleHeatFluxBoundaryValues,which requires references to the turbulence and thermophysical models, andthat temperature is accessed via the thermophysical model. This is differentfor e.g. laplacianFoam.
83
C. Previous CHT adapters - details
1 adapter::Adapter::Adapter( /* arguments... */ ) : /* initializations... */2 {3 adapter::ConfigReader config( configFilename, participantName );4 _precice = new precice::SolverInterface( participantName,5 _getMPIRank(), _getMPISize() );6 _precice->configure( config.preciceConfigFilename() );7 }8 void adapter::Adapter::initialize()9 {
10 _preciceTimeStep = _precice->initialize();11 // Write initial data if required (also calls writeCouplingData())...12 _precice->initializeData();13 }14 void adapter::Adapter::writeCouplingData()15 {16 for ( uint i = 0 ; i < _interfaces.size() ; i++ )17 {18 _interfaces.at( i )->writeCouplingData();19 }20 }21 void adapter::Adapter::adjustSolverTimeStep()22 {23 double solverDeterminedTimeStep = _runTime.deltaT().value();24 if( solverDeterminedTimeStep < _preciceTimeStep )25 {26 if( !_subcyclingEnabled )27 {28 _solverTimeStep = _preciceTimeStep;29 }30 // else throw error...31 }32 // else if solverDeterminedTimeStep > _preciceTimeStep...33 // else...34 _runTime.setDeltaT( _solverTimeStep );35 }
Listing C.3.: Excerpt from the previous Adapter class. Notice the accesses to the preCICEsolver interface and to the solver’s runTime object. More methods are defined.
84
Bibliography
[1] Atanas Atanasov, Benjamin Uekermann, Carlos Andres Pachajoa Mejia, Hans-JoachimBungartz, and Philipp Neumann. Steady-state anderson accelerated coupling of latticeboltzmann and navier-stokes solvers. Computation, 4(4):1–19, October 2016. (Citedon page 2..)
[2] Satish Balay, Shrirang Abhyankar, Mark F. Adams, Jed Brown, Peter Brune, KrisBuschelman, Lisandro Dalcin, Victor Eijkhout, William D. Gropp, Dinesh Kaushik,Matthew G. Knepley, Lois Curfman McInnes, Karl Rupp, Barry F. Smith, StefanoZampini, Hong Zhang, and Hong Zhang. PETSc users manual. ANL-95/11 - Revision3.7, Argonne National Laboratory, 2016. (Cited on page 12..)
[3] David Blom. Fluid-structure interaction solvers for foam-extend (FOAM-FSI). https://github.com/davidsblom/FOAM-FSI ., 2016. GitHub repository, commit 5f43c09.(Cited on pages 33. and 36..)
[4] David Blom. Efficient numerical methods for partitioned fluid-structure interactionsimulations. Dissertation, Delft University of Technology, March 2017. (Cited on page36..)
[5] David Blom, Thomas Ertl, Oliver Fernandes, Steffen Frey, Harald Klimach, VerenaKrupp, Miriam Mehl, Sabine Roller, Dörte Sternel, Benjamin Uekermann, Tilo Winter,and Alexander van Zuijlen. Software for Exascale Computing – SPPEXA 2013-2015,volume 113 of Lecture Notes in Computational Science and Engineering, chapter Parti-tioned Fluid-Structure-Acoustics Interaction on Distributed Data: Numerical Resultsand Visualization, pages 267—-291. Springer, Heidelberg, Berlin, September 2016.(Cited on page 15..)
[6] Hans-Joachim Bungartz, Florian Lindner, Bernhard Gatzhammer, Miriam Mehl,Klaudius Scheufele, Alexander Shukaev, and Benjamin Uekermann. preCICE - a fullyparallel library for multi-physics surface coupling. Computers and Fluids, pages 1–9,2016. (Cited on pages 1., 2., 5., 6., 10., 11., 12., 15., and 16..)
[7] Lucia Cheung Yau. Conjugate heat transfer with the multiphysics coupling librarypreCICE. Master’s thesis, Institut für Informatik, Technische Universität München,December 2016. (Cited on pages 2., 3., 29., 33., 38., 57., 58., 63., 65., and 66..)
85
Bibliography
[8] Lucia Cheung Yau. Conjugate Heat Transfer with the Multiphysics Coupling LibrarypreCICE - Documentation of Adapters, 2016. SimScale GmbH, internal report. (Citedon page 33..)
[9] Lucia Cheung Yau. Coupling of OpenFOAM, CalculiX and Code_Aster for Con-jugate Heat Transfer, using the multi-physics coupling library preCICE (CHT-preCICE). https://github.com/ludcila/CHT-preCICE ., 2016. GitHub repository,commit 4b419cc. (Cited on page 33..)
[10] Fraunhofer Institute for Algorithms and Scientific Computing SCAI. MpCCI 4.5.0-1 documentation. https://www.mpcci.de/content/dam/scai/mpcci/documents/MpCCIdoc-4_5_0.pdf ., March 2017. Part VI Codes Manual. Last accessed: 29/10/2017.(Cited on page 38..)
[11] Florian Lindner, Miriam Mehl, Klaudius Scheufele, and Benjamin Uekermann. Acomparison of various quasi-newton schemes for partitioned fluid-structure interaction.In Coupled Problems, Venice, Italy, 2015. (Cited on page 10..)
[12] T. Maríc, J. Höpken, and K. Mooney. The OpenFOAM Technology Primer. sourcefluxUG, 2014. (Cited on page 21..)
[13] Kevin Rave. Kopplung von OpenFOAM und deal.II Gleichungslösern mit preCICE zurSimulation multiphysikalischer Probleme. Master’s thesis (unpublished), Lehrstuhl fürStrömungsmechanik, Universität Siegen, January 2017. (Cited on pages 33. and 38..)
[14] The OpenFOAM Foundation. OpenFOAM User Guide. https://cfd.direct/openfoam/user-guide/ .. Version 5. Last accessed: 29/10/2017. (Cited on pages17., 19., 21., 24., 25., 27., 34., 35., and 38..)
[15] The OpenFOAM Foundation. OpenFOAM v5.0 C++ Source Code Guide. https://cpp.openfoam.org/v5/.. Last accessed: 29/10/2017. (Cited on pages 17., 21., 22.,24., 25., and 72..)
[16] Benjamin Uekermann. Partitioned Fluid-Structure Interaction on Massively Paral-lel Systems. Dissertation, Institut für Informatik, Technische Universität München,October 2016. (Cited on pages 5., 10., 12., and 15..)
[17] Benjamin Uekermann, Hans-Joachim Bungartz, Lucia Cheung Yau, Gerasimos Chour-dakis, and Alexander Rusch. Official preCICE adapters for standard open-sourcesolvers. In Proceedings of the 7th GACM Colloquium on Computational Mechanicsfor Young Scientists from Academia, October 2017. (Cited on pages 1. and 15..)
[18] E. H. van Brummelen. Added mass effects of compressible and incompressible flowsin fluid-structure interaction. Journal of Applied Mechanics, 76(2):021206–021206–7,2009. (Cited on page 7..)
86
Bibliography
[19] M. Vynnycky, S. Kimura, K. Kanev, and I. Pop. Forced convection heat transfer froma flat plate: the conjugate problem. International Journal of Heat and Mass Transfer,41(1):45 – 59, 1998. (Cited on pages 58. and 69..)
[20] H. G. Weller, G. Tabor, H. Jasak, and C. Fureby. A tensorial approach to computationalcontinuum mechanics using object-oriented techniques. Comput. Phys., 12(6):620–631,November 1998. (Cited on pages 2. and 17..)
87