OpenFOAM® v2006: New and improved numerics
Improved Arbitrary Mesh Interface (AMI)
The AMI code has undergone significant refactoring and extended to include optional topological changes.
AMI code refactoring
The AMI core has been updated to enable greater control and easier code maintenance, whilst maintaining userlevel backwards compatibility. AMI controls are now exposed and can be specified in the constant/polyMesh/boundary file, e.g.
{
type cyclicAMI;
inGroups 1(cyclicAMI);
nFaces 2880;
startFace 276288;
matchTolerance 0.0001;
transform noOrdering;
neighbourPatch AMI2;
// Exposed entries
AMIMethod faceAreaWeightAMI;
restartUncoveredSourceFace yes;
}
Additional improvements:
 The directAMI method has been deprecated; the new nearestFaceAMI method offers equivalent functionality at a lower cost.
 The face matching procedure used by the faceAreaWeightAMI method can now ’walk’ through baffles, providing more complete addressing and weights.
AMI with topological changes
Note: this is betalevel code that has been reasonably tested and shown to be robust; please expect to see new functionality and further improvements in future releases!
This release adds topological change capabilities to the cyclicAMI and cyclicACMI patches, whereby the AMI’s manytomany addressing is used to construct 1to1 face matching between faces on either side of the coupled patches, using the approach described by Aguerre et al. (see References).
Topological changes are activated when selecting the new motion solver in the constant/dynamicFvMeshDict file:
The effect is to ensure conservation across the AMI patches, and to remove numerical noise in the pressure leading to improved force and moment predictions:
Known issues
 restart is not currently supported for topological change.
 Source code
 $FOAM_SRC/meshTools/AMIInterpolation
 Tutorial
 $FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/mixerVesselAMI2D/mixerVesselAMI2DtopologyChange
 References
 H.J. Aguerre, S. Marquez Damian J.M. Gimenez, N.M.Nigro, Conservative handling of arbitrary nonconformal interfaces using an efficient supermesh, Journal of Computational Physics 335(15)2149. 2017. https://doi.org/10.1016/j.jcp.2017.01.018
 Acknowledgements
 Many thanks to Horacio Aguerre and Santiago Marquez for bringing the methodology to our attention and for many useful discussions and testing throughout these developments.
New OpenQBMM community module
The OpenQBMM module comprises quadraturebased moment methods for population balance modeling and multiphase flows. OpenQBMM implements methods to describe polydisperse multiphase flows, from the simplest size evolution of noninertial particles in a carrier fluid to more complex cases with bubbles in a gasliquid system and inertial particles in a gasparticle flow. These capabilities are implemented in a suite of solvers, among which:
 pbeFoam solves a population balance equation in a single control volume. This solver is useful to test kernel functions in the population balance equation and to solve spatially homogeneous problems. Example cases can be found in OpenQBMM/validation/pbeFoam, which shows the validation cases discussed in E. MadadiKandjani, A. Passalacqua, An extended quadraturebased moment method with lognormal kernel density functions, Chemical Engineering Science. 131 (2015) 323339. https://doi.org/10.1016/j.ces.2015.04.005.
 pbeTransportFoam allows a frozen flow field to be used to solve a population balance equation with preimposed flow motion. A validation case is available in OpenQBMM/validation/pbeTransportFoam/serraTaylorCouette and discussed in A. Passalacqua, F. Laurent, E. MadadiKandjani, J.C. Heylmun, R.O. Fox, An opensource quadraturebased population balance solver for OpenFOAM, Chemical Engineering Science. 176 (2018) 306318. https://doi.org/10.1016/j.ces.2017.10.043.
 buoyantPbePimpleFoam allows a transient flow with the population balance equation to be modeled.
 polydisperseBubbleFoam is a specialized solver for gasliquid flows with the evolution of the bubble size due to coalescence and breakup. Bubbles can have a velocity distribution, also accounting for polycelerity, with bubbles with different sizes in the same control volume allowed to have different velocities. Example cases are available in OpenQBMM/validation/polydisperseBubbleFoam while the implementation is discussed in the article J.C. Heylmun, B. Kong, A. Passalacqua, R.O. Fox, A quadraturebased moment method for polydisperse bubbly flows, Computer Physics Communications. 244 (2019) 187204. https://doi.org/10.1016/j.cpc.2019.06.005.
 denseAGFoam implements an anisotropic Gaussian model for dense gasparticle flows. Implementation details are discussed in B. Kong, R.O. Fox, A solution algorithm for fluidparticle flows across all flow regimes, Journal of Computational Physics. 344 (2017) 575594. https://doi.org/10.1016/j.jcp.2017.05.013.
 The solvers in the velocityDistribitionTransport implement quadraturebased moment methods for velocity distributions. These methods are suitable to describe dispersed flows with nonequilibrium velocity distributions, such as crossing jets of particles or droplets. The diluteVdfTransportFoam solver implements the quadraturebased velocity distribution transport algorithm for a disperse phase, not coupled to a carrier fluid. Oneway coupling between the disperse phase and the carrier fluid is implemented oneWayCoupledVdfTransportFoam. In both solvers, the particle size can evolve in space and time, and particles can interact through collisions.
Example of numerical simulation of a bubble column with the evolution of
the bubble size and reconstruction of the bubble size distribution. The
simulation was performed with polydisperseBubbleFoam.
 Source code
 $WM_PROJECT_DIR/modules/OpenQBMM
 Tutorials
 $WM_PROJECT_DIR/modules/OpenQBMM/tutorials
 Validation cases
 $WM_PROJECT_DIR/modules/OpenQBMM/validation
 Attribution
 Alberto Passalacqua and the OpenQBMM community
New densematrix eigendecomposition solver: EigenMatrix
The new EigenMatrix solver performs eigendecomposition on diagonalisable, dense, nonsymmetric, and real square matrices.
EigenMatrix decomposes matrices into their canonical forms, whereby a matrix can be represented in terms of its eigenvalues and eigenvectors.
The eigenvalue equation, i.e. eigenvalue problem, is written:
where:
 : a diagonalisable square matrix of dimension mbym
 : a (nonzero) vector of dimension m (right eigenvector)
 : a scalar corresponding to v (eigenvalue)
If is symmetric, the following relation is satisfied:
where
 : Diagonal real eigenvalue matrix
 : Orthogonal eigenvector matrix
If is not symmetric, becomes a block diagonal matrix wherein the real eigenvalues are present on the diagonal within 1by1 blocks, and complex eigenvalues within 2by2 blocks, i.e. with .
The columns of represent eigenvectors corresponding to eigenvalues, satisfying the eigenvalue equation. Even though eigenvalues of a matrix are unique, eigenvectors of the matrix are not. For the same eigenvalue, the corresponding eigenvector can be real or complex with nonunique entries. In addition, the validity of the equation depends on the condition number of , which can be illconditioned, or singular for invalid equations.
The minimum working example of this solver can be seen below:
const EigenMatrix<scalar> EM(A);
const DiagonalMatrix<scalar>& realEigenvalues = EM.EValsRe();
const DiagonalMatrix<doubleScalar>& imagEigenvalues = EM.EValsIm();
const SquareMatrix<scalar> eigenvectors(EM.EVecs());
const SquareMatrix<complex> complexEigenvectors(EM.complexEVecs());
 Source code
 $FOAM_SRC/OpenFOAM/matrices/EigenMatrix/EigenMatrix.C
 Tutorial
 $FOAM_APP/test/matrices/EigenMatrix/TestEigenMatrix.C
 Attribution

 This implementation is an integration of the OpenQBMM eigenSolver class (2019) without any changes to its internal mechanisms. Therefore, no differences between EigenMatrix and eigenSolver (2019) classes should be expected in terms of inputprocessoutput operations.
 The OpenQBMM eigenSolver class derives almost completely from the TNT/JAMA implementation, a publicdomain library developed by NIST and MathWorks from 1998 to 2012, available at http://math.nist.gov/tnt/index.html (Retrieved June 6, 2020). Their implementation was based upon EISPACK.
 OpenCFD would like to thank the contributors to OpenQBMM, particularly Dr. Alberto Passalacqua (Iowa State University) for the initial implementation of the functionalities.
New and improved adjoint optimisation tools
The adjoint library is enhanced with new functionality enabling the minimisation of an objective function qualitatively quantifying noise through the integral of the squared turbulent viscosity over a portion of the computational domain [1]. This objective function has successfully been used in the past for minimising noise using relatively cheap RANS simulations, in cases where optimisation using high fidelity DES transient simulations is too computationally demanding. Selected figures pertaining to the design of the side mirror of a passenger car showcase the use of this objective function (see references).
The volume used to define the objective function and parameterisation of
the side mirror
Turbulent viscosity corresponding to the baseline and optimised mirror
Additionally, the sensitivity derivatives contributions emerging from the differentiation of the positions of the face centres included in the rotatingWallVelocity primal boundary condition are now taken into consideration by introducing its adjoint counterpart, i.e. adjointRotatingWallVelocity. These are an indispensable part of computing the correct sensitivity derivatives when designing rotating components such as the rim of a bicycle wheel.
Shape evolution of the rim of a bicycle wheel targeting the weighted minimisation of the drag and side forces. The geometry is a courtesy of A. Kitselis & T. Theodoridis O.E.
Finally, executing writeActiveDesignVariables before performing an automated shape optimisation loop using adjointOptimisationFoam is no longer necessary, simplifying the optimisation workflow.
 References
 E.M. PapoutsisKiachagias, N. Magoulas, J. Mueller, C. Othmer, K.C. Giannakoglou: ’Noise Reduction in Car Aerodynamics using a Surrogate Objective Function and the Continuous Adjoint Method with Wall Functions’, Computers & Fluids, 122:223232, 2015
 Source code
 $FOAM_SRC/optimisation/adjointOptimisation/adjoint/objectives/incompressible/objectiveNutSqr
$FOAM_SRC/optimisation/adjointOptimisation/adjoint/adjointBoundaryConditions/adjointRotatingWallVelocity  Attribution
 The software was developed by PCOpt/NTUA and FOSS GP with
contributions from
 Dr Evangelos PapoutsisKiachagias,
 Professor Kyriakos Giannakoglou,
 Dr Andrew Heather.
 Integration
 The code has been integrated jointly by OpenCFD and NTUA.
 User guide
 A PDF guide prepared by NTUA is available here. The user guide has been updated with all features pertaining to an automated shape optimisation loop, including the volumetric BSplines morpher introduced in OpenFOAM v1912.
New distancetopatch calculation method
A new variant of meshWave distancetopatch calculation, i.e. directionalMeshWave has been introduced.
For a given point within a given mesh, the existing meshWave method provides the orthogonal distance to a specified patch. This can be problematic for meshes with very steep terrain, e.g. a hill of 90 deg.
The new directionalMeshWave method ignores the distance component in a userspecified direction, e.g. to enable the distancetopatch to be computed in the wallnormal direction only.
A comparative example between meshWave and directionalMeshWave output in terms of the wall distance can be seen below:
Wall distance field by meshWave
Wall distance field by directionalMeshWave
The minimum working example of this distancetopatch calculation method by using system/fvSchemes.wallDist can be seen below:
{
method directionalMeshWave;
n (0 0 1);
}
 Source code
 $FOAM_SRC/finiteVolume/fvMesh/wallDist/patchDistMethods/directionalMeshWave
$FOAM_SRC/meshTools/cellDist/directionalWallPoint  Tutorials
 $FOAM_TUTORIALS/mesh/moveDynamicMesh/SnakeRiverCanyon
 Extended code guide
 directionalMeshWave
New external solver module
This release provides a new module : externalsolver that contains an OpenFOAM interface to the PETSc linear solver library. Building this interface consists of two steps:
 building the PETSc library
 building the OpenFOAM interface
One way of building the PETSc library is inside the OpenFOAM ThirdParty directory. This will keep it separate from any systemwide PETSc libraries. A typical build order would be:
cd $WM_THIRD_PARTY_DIR
# Try and see if the PETSc source are there
./makePetsc
# If not it will print download instructions, e.g.:
wget http://ftp.mcs.anl.gov/pub/petsc/releasesnapshots/petsclite3.13.2.tar.gz
tar xzf petsclite3.13.2.tar.gz
# Again try building:
./makePetsc
The second part of the build is the OpenFOAM solver part. Get hold of the latest externalsolver module:
git submodule init
git submodule update
# Build
./Allwmake prefix=openfoam
# Update any OpenFOAM settings (not actually necessary for PETSc)
wmRefresh
Initializing PETSc
PETScbicg: Solving for Ux, Initial residual = 1, Final residual = 0.0165669, No Iterations 1
PETScbicg: Solving for Uy, Initial residual = 1, Final residual = 0.0143104, No Iterations 1
PETSccg: Solving for p, Initial residual = 1, Final residual = 0.0981241, No Iterations 154
time step continuity errors : sum local = 1.71696, global = 0.010057, cumulative = 0.010057
PETScbicg: Solving for epsilon, Initial residual = 0.199669, Final residual = 0.00505847, No Iterations 2
bounding epsilon, min: 1.45735 max: 1080.25 average: 48.855
PETScbicg: Solving for k, Initial residual = 1, Final residual = 0.0131958, No Iterations 3
ExecutionTime = 0.47 s ClockTime = 1 s
 Notes
 If the petsc4Foam solver is to be built with another version of PETSc just adapt the settings in the (local copy of) etc/config.sh/petsc and make sure to source those.
 Source code
 modules/externalsolver/src/petsc4Foam
 Tutorials
 modules/externalsolver/tutorials/incompressible/simpleFoam
 Attribution
 Developed under Governance: created by the HPC technical committee, involving Mark Olesen, Simone Bna, Stefano Zampini.