Introduction

Computational Fluid Dynamics (CFD) is a computer simulation of a fluid within a domain--essentially, we are simulating a wind tunnel (the domain) with a car inside of it, and using the properties of the fluid to calculate aerodynamic properties such as lift and drag. This can be done with both 2D and 3D simulations, which makes it useful for developing and refining aero kits on the car.

This document will go through the basic CFD pillars, erring towards practical application instead of the underlying mathematics. However, an understanding of the governing equations and solver methods will make the learning curve much easier.

It is recommended to be familiar with FEA before learning CFD.

Structure Geometry

Because CFD is so big and complex, computation can often take a while. Therefore it is prudent, for any big simulations, to simplify the geometry such that critical structures are preserved and less important things are reduced to ease computation cost.

For example, many things in the rear of the car such as the powertrain, suspension, and accumulator, may be simplified. In these cases we are only looking for a “close enough”, and so the tradeoff is more than acceptable. However, the bodywork and wings, which are critical to the aerodynamic performance, retain their detail.

If you are familiar with FEA, then you know that simulations do not take kindly to sharp corners, and frequently show irregularly high stress concentrations there. Therefore, FEA models must have small filets on all sharp corners to avoid these concentrations and produce a more accurate result.

CFD experiences a similar issue. However, instead of producing inaccurate stress concentrations, sharp corners in CFD can skew results and cause the simulation to diverge. A hint that a geometry might have sharp corners is if a relatively coarse mesh takes a very long time to generate-the mesher is seeing the edge and scratching its head, unsure of what to do.

Domain

The domain is what we are simulating. As mentioned in the introduction, imagine the domain to be a wind tunnel. In a 2D case, this looks like a big rectangle with a cross-section of our structure (such as an airfoil) cut out of it. In a 3D case, imagine a rectangular prism with the outline of the car subtracted from it. A 2D domain for the front wing of 24A and a 3D domain is shown below.

We do not include the actual structure within the domain because the domain consists solely of what we are trying to calculate the properties of--the working fluid. We calculate properties of these structures by defining them in the geometry setup, and then using the properties of the surrounding air to find aerodynamic characteristics. For this same reason, meshes do not mesh the structure as in FEA, but rather the fluid domain. For example, we can look at the pressure distributions around an airfoil to calculate lift without ever meshing or calculating anything within the structure itself, as shown below.

The size of the domain is very important to the simulation. A small domain is similar to a small wind tunnel: the presence of the walls and ceiling will interfere with the airflow around the structure. A domain that is too big, however, will be very computationally expensive and take very long to solve. As with most things in CFD, we must work to find a balance between two extremes.

To find the smallest domain size without impacting solution accuracy, we can perform a domain study, in which we begin with a small domain and increase the size until the results are consistent.

The shape of the domain, too, also impacts the simulation. For straight line simulations, a rectangular domain is fitting, while a cornering simulation would include a curved domain. Therefore, the size and shape of the domain depend heavily on the simulated case and the size of the structure.

In order to obtain accurate solutions, however, a system must not have an adequate domain, it must also have a good mesh.

Mesh

Similar to FEA, a mesh is breaking up a complex geometry into many small, manageable cells whose properties can then be easily calculated. However, similar to how the domain only encompasses the fluid regions, meshes only mesh the fluid regions and not the structure itself.

Obtaining a good quality mesh is a mixture of the fineness and quality of the mesh. Fineness is synonymous with the “resolution” of the simulation: a finer mesh will yield greater detail and more accurate solutions, but take longer to solve. Coarser meshes sacrifice detail and accuracy in favor of faster computation times, similar to meshes in FEA.

Mesh quality, on the other hand, depends on a multitude of things, of which the primary factors are orthogonal quality and skewedness. Quality largely references the orientation of meshed cells relative to one another; proper orientation will translate to easier computation, while poor orientation will create skewedness and hurt computation time and accuracy.

The ANSYS Mesher offers a variety of tools to control the mesh fineness and quality. We can define regions of the domain where we wish the mesh to be finer, for example, the region close to an airfoil; likewise, we can confidently say that the regions far away from our structure do not need to be as fine. We can also define quality goals that the mesher will target when meshing, and refine our mesh afterwards to improve an existing mesh.

Ultimately, the mesh is of greater importance than anything else when determining the accuracy and quality of a simulation. It takes intuition and rigor to develop a quality mesh for a structure, using both experience and systematic domain and mesh studies to determine the optimum parameters.

Solver

Most fluid solvers are iterative and not analytical. By repeatedly guessing, solving the governing fluid equations, and then using the results to guess again, solvers can eventually get a very close approximation of fluid properties.

In order to determine a good guessing point, solutions must initialize. If we are performing a parametric study that modifies geometry, we must be careful as parametric designs tend to use the same initialization for every solution, leading to that converge but nonetheless are incorrect. If we are performing a big initialization, FMG initialization is also used in order to produce a more robust solution.

When solvers get very close to the answer, the guesses they make with each iteration grow closer and closer. Eventually, when they are close enough, we consider the answer “converged” and do a happy dance.

However, this also brings about an issue if the guesses do not grow closer and closer. If they instead grow farther and farther, the simulation has diverged, and we do not have a valid solution. This generally is an issue with the model geometry or mesh. This can also occur where the simulation oscillates around a fixed value without converging or diverging, and is usually indicative of a transient scenario rather than a steady state one.

In order to quantify how converged or diverged a solution is, simulations use convergence criteria to establish numerical values after which the solution is considered converged. There are various convergence criteria, but a sure way to qualitatively evaluate convergence is to see a plot of some output parameter with respect to the iterations. The above chart shows a converged solution; a diverged or nonconverged solution would have a line that does not settle as shown.

The stricter the convergence criteria, the closer the guesses have to be, and subsequently the more accurate the results. However, it also takes the solver longer to reach strict convergence criteria's.

ANSYS comes with various solvers, all suited for various simulation cases and with their own pros and cons. We generally use a k-epsilon model with curvature correction for a steady-state simulation, such as 2D wing geometry studies and overall car simulations. Each solver has many different controls that we can use to manipulate the characteristics of the solver, such as its sensitivity, initialization points, solver methods, etc. Don’t fuck with these unless you know what you’re doing.

Validation

Perhaps the most critical aspect of CFD is validation, as the simulations will be of no use if they are wrong, and it will be even worse if you use invalid CFD to guide your design. Most validation implies irl testing, such as wind tunnels, track tests, and similar tests that measure real life data. Track testing is the best type of validation because it accurately reflects the driving cases and can happen in parking lots, at competition, etc. By comparing validation testing and CFD data, we can determine to what degree we trust the simulation, and whether or not additional studies are required to reevaluate the quality and accuracy of the study.

Additionally, there are a few things we can try within the simulation to verify the quality and accuracy. There are the domain studies, in which we determine the appropriate size of the domain such that there is no impact on the solution; similarly, mesh studies, which determine the appropriate size of the mesh. We can test the stability of the solver by adjusting solver parameters and seeing how the solution changes (equivalent to smacking random things in a machine and seeing if it still works after).