Computational Fluid Dynamics (CFD) modelling is the process of creating a computer model to solve an engineering problem involving fluid flows. The CFD model is a representation of the fluid dynamics in a specific application, which are solved using a numerical algorithm to obtain the flow velocity, the pressure and other engineering quantities of interest as a result.

## What are the main phases of CFD modelling?

The CFD modelling workflow usually starts from the definition of the **geometry** to be simulated. The geometry is then included in a computational domain and discretised into a computational grid (**mesh**). In order to calculate the solution of the problem, physical and numerical models need to be **setup** together with initial conditions and boundary conditions that fully defined the problem to be solved. Once the simulation has been setup, the **solution** is obtained running the numerical algorithm. Finally, the results are analysed in the **post-processing** phase. The typical CFD modelling phases are described in more detail in the next sections.

Our CFD modelling software SimWorks can be used to perform a CFD simulation from geometry to post-processing, all within an integrated GUI.

Often, a CFD simulation is part of a design loop and the results of the simulation can be used to evaluate the performance of the geometry and give indications about the changes required to improve it. Our CFD modelling software SimWorks is designed with the CFD process in mind and let you quickly setup and run CFD simulations of different design iterations and compare the results directly to evaluate the best design.

### Geometry definition and computational domain

The first step of the CFD modelling process is to define the geometry of the problem to be solved, which generally comes from a CAD model or a simplified representation. The geometry can be included in a computational domain.

**The computational domain is the portion of space where the solution is required**. In external flow problems, the computational domain is typically a volume around the geometry of interest which should have adequate dimensions. The image below shows an example of the computational domain surrounding a motorbike model. In this case the domain is a box approximately 15 times longer than the motorbike, with a space of 5 times the motorbike length in front of it and 10 behind it, and 5 times wider than the motorbike. In internal flows instead, the computational domain is represented by the confines of the geometry itself. A more extensive discussion about the computation domain requirements for a CFD simulation can be found here.

### Computational mesh

In order to solve the flow with a numerical algorithm, the computational domain and geometry requires to be discretised to create the computational mesh. Typically **the meshing process consists in dividing the volume within the computation domain**, but outside the simulated object, into** small volumes or “mesh cells”**. Within every cell, the equations of fluid flows will be solved to calculate flow properties like velocity and pressure. These properties are carried by flow across the entire domain affecting the solution at every cell.

### Simulation setup

We need to select the CFD models that best represent the physics of the problem we need to solve. Typically, we can choose to simulate a flow where we expect the solution to vary only in space and be independent of physical time. In this case, we aim to obtain a so called steady-state solution of the flow. Alternatively, when the time evolution of the flow is important, we can run a transient simulation. Generally,** transient simulations are required when we are interested in capturing the unsteady nature of a flow field**, or whenever we have temporal variations in the onset flow or moving parts of the geometry. The CFD simulation might require additional physics models to correctly describe the physical problem we want to solve. For example, we might need to decide whether the flow is compressible or not, whether we want to consider the temperature (energy) among the variables of interest and most importantly we might want to use a model to take into account the effect of turbulence on the solutions depending on the Reynolds number. An overview of turbulence modelling in CFD is given in this article.

In order to obtain a solution of the flow, boundary conditions must be assigned to the surfaces representing the computational domain and the geometry and an initial value must be assigned to the flow variables (velocity, pressure, etc.) in each cell. The initial and boundary conditions are mathematical representations of the actual flow conditions present in real problem. In the example of the motorbike shown above, typically a constant inlet flow velocity equal to the desired motorbike speed is assigned to the upstream face of the computational domain. This way the relative velocity between the motorbike and the flow will be equal to the required speed.

**This produces exactly the same results as having the motorbike ****moving**** at speed in stationary air.** This principle, called Galilean invariance is widely used in wind tunnel testing where the object to be tested is fixed and the air is blown at speed with a fan. This approach allows to better control and measure of the problem rather than having an object moving at speed in stationary air. The bottom face of the domain represents the ground, which in the relative reference frame is moving at the speed of the motorbike, but in the direction of the inlet flow. Therefore, a prescribed velocity tangential to the surfaces can be applied, whereas the pressure is unknown so we could assume instead that its gradient (variation) normal to the surfaces is zero. At rear faces of the domain, it is not possible to know in advance the velocity of the flow, which will need to be calculated instead. Therefore, it is common practise to assume a fixed value for the pressure, representing the ambient pressure, and we can set the gradient (variation) of velocity normal to those surfaces to zero. The same approach can be used for the sides and top faces of the domain. Alternatively, the far sides can be considered as walls of a wind tunnel. Clearly, these boundary conditions are a simplification of the real conditions of the flow, therefore it is important to define a computational domain with an adequate size to limit the impact of these assumptions on the solution around the simulated object.

The surface of the motorbike can be defined as a stationary walls to correctly simulate the relative speed between the flow and the object. It is important to highlight that as the wall is stationary, due to the viscosity of the fluid, the flow in proximity of the wall will progressively slow down creating a thin portion of slow moving flow next to the surface. This region is commonly known as boundary layer and it tends to grow over the wall distance along the flow direction. As the boundary layer is generally very thin, it requires a lot of mesh resolution to resolve it, therefore additional boundary conditions, called wall functions, are generally adopted near the walls.

### Solution

**solution is achieved with an iterative process and several iterations are generally required to converge the system of equations**. The solution starts from the initial conditions and evolves based on the boundary conditions, iteration by iteration. The rate of change of the solution in terms of flow variables (like pressure or velocity)

**is called**

**. During the simulation, the residuals of each equation should progressively reduce to a relative small number indicating that the flow solution is no longer changing significantly and it has its**

*residual***numerical converge**. The maximum number of iterations the solver will carry out needs to be decided before starting the simulation. As the correct number of iterations required to converge a simulation varies depending on many factors, like the complexity of the problem and the numerical schemes used, sometimes the solution is terminated before it has fully converged but

**it is possible to**

**adding further iterations to the existing solution. If on the other hand, it is recommended to**

*extend the computation***before the maximum number of iterations is reached if the simulation has already converged. This helps speed up the simulation and save computational resources. As it is not possible to know in advance the number of iterations required, the most common solution is**

*stop the simulation***to define convergence criteria**to stop the solving algorithm once the criteria are met. The convergence criteria can be defined on the residuals values and the simulation can be stopped once the residuals are lower than a predefined value. In addition, the convergence criteria can be defined on physical quantities of interest, like forces on bodies or mass flow rates through planes. The simulation can be stopped when those quantities no longer change. Sometimes the solution might still have small variations in the residuals, but the results are considered stable enough for convergence. In this case, it is common practice to average the solution over a range of the last iterations. As a practical example the plot of the Coefficient of Pressure \(C_p\) presented in the picture below is an average plot of the \(C_p\) values across the last 50 iterations out of 1000 which were necessary to complete the CFD simulation:

In transient simulations, the solution is advanced in physical time instead of iterations. The user defines the time window that needs to be simulated and a time step to march through time. At each time step, the solution needs to be fully converged. The choice of time step has important implications on the quality of the results and the stability of the solution.

### Post-processing

Once the simulation is completed, the CFD solution consists of knowing the values of the flow variables, like velocity and pressure, in every node of the computational grid. The raw numbers can be difficult to interpret, therefore these results are generally post-processed to obtain integral quantities, graphs and plots that the user can easily interpret and compare. **The goal of post-processing is to make the data and flow structures interpretation intuitive for the final user**. The values are usually presented in a graphical form with colours varying according to user’s defined settings. As an example, the converged solution of our motorbike model can be post-processed to create a plot of a relevant flow parameter in a specific area, like pressure field on the motorbike surface in the form of a coloured surface plot. In the image above, red indicates high pressure and blue represents suction. It is also possible to visualise the local flow patterns by plotting streamlines close to the motorbike nose and observe how the flow is diverted by the body shape. The streamlines can also be coloured by the local flow speed to understand where the flow is faster or slower compared to the inlet velocity. In the image below, the velocity increases from blue to red.

The plot with the streamlines shows that flow accelerates on the front nose cover of the motorbike, locally increasing the level of suction on the motorbike side. Post-processing is a vital part of the CFD modelling process as it allows to understand the flow physics and gain insights into the design. The post-processed results can be used to identify improvements to make to a design, as well as evaluating and comparing different designs in order to identify the best.

## Convergence history in CFD modelling

As mentioned above monitoring the residuals convergence of a CFD simulation is one of the most important steps in CFD modelling, since the validity of the results depend on the solution being converged. **The residuals are supposed to steadily decrease as the solution develops over the iterations until it no longer changes and the solution is converged.** The residuals evolution over the iteration number defines what is generally called the “convergence history”. The convergence history is heavily dependent on the CFD model definition, both in terms of mesh quality and numerical settings, and can often show local spikes, which means that for a few iterations the rate of change in the solution was actually increasing instead of reducing. A limited number of spikes in the residuals are acceptable, if the solution will eventually converge. Sometimes the residuals might stabilise at a very high level, indicating the the solution is unsteady or unstable, or in a worst case scenario they can increase, ultimately leading to a divergence in the solution and the algorithm to fail. If this is the case, the CFD simulation does not have a valid solution and will be flagged as a *diverging solution*. While it is easy to spot a *diverging solution* simply plotting the residuals, it is more complicated to understand the underlying cause. **To solve the problem affecting a CFD simulation,** it is necessary to plot the flow field a few iterations before the point at which the simulation actually diverged. The issue can be a *mesh issue* (for instance a badly defined cell, or a mesh too coarse in a region) or a *boundary condition problem* (for instance when the conditions imposed are not physical or incompatible for the problem to solve).

The post-processing is usually the best way to understand the reasons that are triggering the diverging behaviour, by looking at the flow field and identify regions where the results are not physically correct. Typically **it is easier to spot the issue before the simulation has actually diverged **since once the simulation has started to diverge, the whole flow field is affected and can be difficult to spot where the problem originated. It is worth mentioning that the solver will output a flow field only at certain iterations, specified by the user prior to starting the analysis. It is therefore common practise to re-run the simulation specifying in the solution settings that it is required to save the solution a few iterations prior to the start of the divergence. This way all the data to debug the issue will be available once the simulations has run (and crashed) for the second time.

Boundary conditions problems should always be resolved by applying the correct conditions for the problem, meanwhile mesh issues problems can sometimes be masked by changing the numerical settings of the solution. In general, this consists in reducing the order of accuracy of the numerical scheme or reducing the relaxation factors in the iterative solvers. Although this approach is a viable solution, it is always recommended to identify the root cause of the issue in the mesh and resolve it. This is even more important when similar CFD models need to be run and a similar mesh issue could be found in other simulations, impacting the efficiency of the design process.

## Level of details in CFD modelling

**Multiple CFD modelling techniques apply to a variety of physical problems.** In general, a CFD model is a simplification of the real physical problem and some assumption must be made in order to reduce its complexity.

The level of detail in terms of geometrical representation and physical phenomena included in the CFD model depend on the scope of the simulation. Therefore, before starting to setup a simulation, it is very important to decide what are the requirements of the CFD model so that all the relevant parameters and models are taken into account.

The example of the motorbike above is a typical example of an external aerodynamics simulation, where only the steady state solution of velocity and pressure was obtained. This is a simplification of the real world case. Often, it is required to take into account the energy of the flow, for example by means of including an equation for the temperature. As an example, in order to increase the fidelity of the motorbike model, one may consider the impact of radiators and hot exhaust in the flow.

The geometry of radiators are generally not included in the CFD model, as those are very complex and the aerodynamic characteristics of radiators can be obtained from the supplier technical data or evaluated with a specific CFD model.

Typically radiators are modelled with a porous media model, that is a region of the domain where the flow direction and pressure is affected as it the flow was passing through a dense porous region. The porosity coefficients of the porous region are generally calibrated using experimental data of the actual radiator or via a specific CFD model of the radiator itself, where all the geometrical details are considered.

**When considering the temperature and the flow density variation with temperature, the CFD model becomes more expensive from a computational viewpoint**. In general this is the case every time more geometrical details and physical models are added to the model. The engineers and designers can decide the required level of detail and accuracy and sometimes it is possible to use manual or empirical approaches to include multiphysics effects in a simplified CFD model.

The simple example above shows different levels of complexity achievable with different models simulating the same physical problem and gives an idea of the choices which are usually presented to the engineer defining the model.