In 2020, CFD Direct were tasked to develop multicomponent diffusion modelling in OpenFOAM with funding from the Process Engineering Consortium. The Consortium need models, e.g. Maxwell-Stefan, that represent complex diffusion of species in fluid mixtures, affecting both specie concentration and energy. As part of the work, we created a new ThermophysicalTransportModels library for the new complex models with new interfaces for: fluxes of heat, q() and divq(); and fluxes of mass, j() and divj(). The code redesign is typical of our strategy for sustainable development of OpenFOAM, supported by dedicated maintenance funding from OpenFOAM supporters.
Benefit of Redesign
An unexpected but welcome consequence of the new interface was that heat transfer became consistent across applications, boundary conditions and data processing. Problems reported with heat transfer via the OpenFOAM Issue Tracking System, should now be resolved by using the development line of OpenFOAM (OpenFOAM-dev). This experience demonstrates the importance of redesign to improve robustness while making the code easier to extend in the future. It is why we resolutely advocate redesign over “hacking” into existing code frameworks. The work requires a core team with vast experience, ability and commitment, which requires funding.
Calculating Heat Flux
The work on multicomponent diffusion involves the thermophysicalModels library in OpenFOAM, which includes models for thermodynamics, equation of state and transport, for mixtures of gas or liquid species — and more. The design of the library is suited to flows dominated by turbulence, reflecting the interest in combustion engines of its creator Henry Weller. In OpenFOAM v7 released in 2019, in the reactingFoam combustion solver, the diffusion term in the energy term is:
- fvm::laplacian(turbulence->alphaEff(), he)
This term corresponds to a heat flux vector q = – αeff ∇e (or – αeff ∇h) where:
- e is the specific internal energy (or enthalpy h) [J/kg];
- αeff = α + αt is the effective thermal diffusivity represented by the
alphaEff()function; - α is a laminar thermal diffusivity [kg/(m·s)];
- αt is the turbulent diffusivity associated with temperature fluctuations using the Boussinesq hypothesis.
The Need for Redesign
The expression for q, represented by the code above, has significant limitations. First, it is completely insufficient for multicomponent diffusion since it does not include heat transfer due to diffusing species. Secondly, the expression only represents the simplest conduction model, Fourier’s Law q = – κ ∇T (where thermal conductivity is κ = c α [W/(m·K)]) when the specific heat capacity c is constant.
Furthermore, the heat flux q is calculated not only in applications, e.g. reactingFoam, but also in other parts of the code, e.g. boundary conditions, fluid-solid interfaces and data processing (function objects). Those parts of the code duplicate the flux calculations. Creating new applications with different flux calculations, e.g. for multicomponent diffusion, would require further code duplication across OpenFOAM. Further duplication increases the risk of error, to a point when it becomes inevitable.
The New Interface
A sustainable solution is to represent q by the function q() with the new interface in the ThermophysicalTransportModels library. The diffusion term in the energy equation in reactingFoam is, since the release of OpenFOAM v8 in 2020:
+ thermophysicalTransport->divq(he)
Here, the divq() function represents the divergence ∇•q. Each thermal diffusion model, e.g. the Fourier model based on ∇T, defines its own q() and divq() functions. These functions replace relevant code within applications, boundary conditions and data processing to ensure consistent heat transfer across OpenFOAM.
There is an equivalent interface for mass diffusion using j() and divj() functions. This interface is adopted throughout OpenFOAM to ensure consistency. The interface makes it relatively simple to implement new diffusion models; so far models such as Fickian are included with more complex phenomena such as thermophoresis.
Conclusions
- An existing software design may not support new functionality.
- Sustainable development then requires redesign of code with suitable interfaces.
- Funding is essential for a core maintenance team with the experience, ability and commitment to redesign code.
- The core maintainers need the freedom and support to imagine and execute the redesign work.