# Settling Sphere by Michael Alletto

Go back to Collection by authors.

Go back to Meshing.

# Sphere settling under the influence of gravity

You can download the case file [1] here.

## Introduction

This tutorial has two main objectives:

• The first objective is to show how to set up an overset simulation with OpenFOAM. The overset methods (also know as chimera method) is very useful if large body motions have to be simulated. It consists in a fixed background mesh and one or more disconnected mesh regions which are subject to large displacements. In order to couple the disconnected mesh regions, the flow variables are interpolated between the meshes. Inside each disconnected mesh region, the solution is calculated by means of the usual finite volume discretisation. The different mesh regions are usually not subject to topological changes which allows to maintain the original mesh quality.
• The second objective is to validate the overset methodology implemented into OpenFOAM with experiments. This is a mandatory step to estimate the uncertainty of a given simulation method. The uncertainty of a tool is connected to the risk not meeting a design criteria when this tool is employed in an industrial context.

For this purpose the experimental setting by [1] was chosen to be simulated. The experimental settings consists in a rectangular box with dimensions of 100x100x160mm (in x-,y- and z-coordinate direction). Gravity points in negative z-direction. The lower part of the sphere was hanging 120mm from the bottom wall. The sphere had a diameter of 15mm and a density ρ_s of 1120 kg/m^3. Different Re-numbers based on the free falling velocity were measured (Re: 1.4, 4.1, 11.6 and 32.2). For this tutorial the lowest Re number was chosen. The variation of the Re-number in the experiments was achieved by choosing fluids with different fluid viscosities μ_f. The same can be done here if other Re-numbers have to be simulated. The setup can be seen in the figure to the right.

## Simulation set up

In this section the set up of the simulation is shown step by step and the choice of the parameters employed is tried to be justified whenever it is possible.

### Mesh generation

As in every CFD simulation the first step is to decide the domain extension and how to generate an adequate mesh which guarantees a desired solution quality. In this case the extension of the domain is obvious since the experimental setting is bounded by six walls. Figures to the right show the two meshes generated for the sphere (on the left) and for the background mesh (on the right). The figures show a slice through the mid plane of the mesh.

The mesh around the sphere was generated with snappyHexMesh adding a few layers close to the wall. The fine resolution of the boundary layer is necessary to correctly predict the viscous and pressure forces which are later use to displace the sphere in the domain. The outer boundary should not be chosen to be too close to the sphere wall. The reason is to avoid that the errors generated by interpolating the solutions between the two meshes are affecting the boundary layer close to the sphere. However the outer boundary should not be chosen too far away in order to avoid the contact of the mesh around the sphere with the domain boundaries. Note that when generating the meshes which are displacing in the domain the outer boundaries have to be assigned to the type overset.

The background mesh was generated with blockMesh and refining the mesh additionally with refineMesh in the domain centre where the mesh around the sphere is supposed to translate. The refinement is performed to reduce the interpolation errors between the background mesh and the mesh around the sphere. The interpolation errors are usually proportional to the cell size difference of the interpolation partners.

After generating the two distinct meshes the meshes can be merged by mergeMesh. The result is shown in the figure to the right.

### Case set up

Before starting the simulation one has to ensure the a field named zoneID has to be present in the 0 folder. Each cell zone should have a different zone id starting with 0. In our case there a two zones: one is the background mesh and the other is the mesh surrounding the sphere (see also Figure to the right). As mentioned before, it is also necessary for the overset method to work that the outer boundaries of the meshes which are moving in the domain are declared as type overset.

Another field which is necessary for the mesh around the sphere to move is the one called pointDisplacement. For this field the sphere walls should be declared as type calculated. The reason is that the displacement of the sphere walls will be calculated by the motion solver.

The way to tell OpenFOAM that the mesh is changing is to have a file called dynamicMeshDict in the constant folder. There the settings for the motion solver have to made. The dynamicMeshDict is shown below. The displacement of the sphere (the patch named sphere) is calculated by the sixDoFRigidBodyMotion solver. It integrates the viscose and pressure forces over the patch to get the forces acting on the sphere. The displacement is than calculated by applying Newton's second law. Note that the mass has to be reduced by the Buoyancy since the overPimpleDyMFoam solver does not consider the hydrostatic pressure. In order to get a good agreement of the temporal evolution of the displacement and velocity of the sphere this is necessary.

motionSolverLibs ( "libsixDoFRigidBodyMotion.so" );

dynamicFvMesh dynamicOversetFvMesh;

dynamicOversetFvMeshCoeffs

{ // layerRelax 0.3; }

solver sixDoFRigidBodyMotion;

accelerationRelaxation 0.4;

sixDoFRigidBodyMotionCoeffs

{

patches (sphere);

innerDistance 100.;

outerDistance 101.;

accelerationRelaxation 0.4;

accelerationDamping 0.4;

// mass reduced by Buoyancy: (rhosolid - rhofluid ) * VolumeSphere

mass 2.65E-04;

centreOfMass ( 0 0 0 );

momentOfInertia ( 4.45E-08 4.45E-08 4.45E-08);

rho rhoInf;

rhoInf 970;

g (0 0 -9.81);

report on;

reportToFile on;

solver{ type Newmark;}

constraints{}

}

// ************************************************************************* //

After having made this settings, everything is ready to start with the simulation. Note that the maximum Courant number is changed during the simulation (it is done automatically by the timeActivatedFileUpdate function object). This is done in order to reduce the simulation time. In the beginning of the simulation a small maximum Courant number is required in order to keep the simulation stable. The reason is probably that the sudden movement of the sphere generates pressure oscillations which lead also to oscillations in the sphere displacement. This mutual coupling can destabilize the simulation.

### Simulation results

Finally the comparison with the experiments is shown in the figures below.

It is evident that good agreement could be achieved with the reference experiment until the mesh surrounding the sphere overpasses the bottom wall. Unfortunately than the simulation crashed. However the good agreement between the simulation and the experiments (at least for this case) helps to get confidence regarding the reliability of the overset method implemented in OpenFOAM.

[1] Ten Cate, A Nieuwstad, CH Derksen, JJ Van den Akker: Particle imaging velocimetry experiments and lattice-Boltzmann simulations on a single sphere settling under gravity, Physics of Fluids, 14(11), AIP, p. 4012-4025, 2002