Introduction to Computational Fluid Dynamics (CFD)
This introduction will give you a high-level overview of Computational Fluid Dynamics (CFD). We will therefore leave out most of the fine-print and concentrate on broad concepts assuming little or no familiarity with fluid mechanics. The introduction is intended for people who do not run simulations themselves, but do require some basic understanding of the topic, especially with regard to its application in industrial environments. Therefore, the target audience for this text consists of CTOs, project managers, R&D managers, persons that fulfill similar functions, or technical-minded managers who want to learn about the topic from a technical/economic or project management perspective. While we don’t dive too deep into the actual CFD, we have tried to cover the use case of CFD extensively in the text below.
CFD: A concise introduction
Definitions aside (see the CFD article Wikipedia for that), CFD is a method to predict the behaviour of fluids using only calculations as opposed to experiments. A fluid in this respect can be a liquid, a gas, or even particles and mixtures thereof. To calculate the behavior, theories about fluid dynamics are needed; central to that are the Navier-Stokes Equations and a plethora of more refined models based on them. Together, these mathematical theories describe how a given fluid will behave in certain situations (e.g. exposed to mechanical force, heated, evaporated, …). For real-world problems, the equations need to be solved millions of times to yield results with acceptable accuracy, which is where the “computational” comes into Computational Fluid Dynamics.
Once you have some idea about the properties of your fluid (density, viscosity, …), know the mathematical model for how it will behave in a dynamic situation, and have a framework to do the actual calculations, you can go about the business of predicting something using CFD. This “something” can basically be any prediction you wish to make about some kind of fluid flowing through or around objects. Some typical aspects that can be tackled with CFD are:
- Lift and drag of aircrafts
- Hydrodynamics of watercrafts
- Combustion in engines and turbines
- Flow in diffusers and compressors
- Heating and cooling with fluids
- Mixing and separation
- Wind and water loads on structures (houses, sea-platforms)
- Flow and flooding of rivers and oceans
- Distribution of pollutants (fluids, particles)
- Movement of particles in fluids
- Chemical reactions in moving fluids
- Indoor heating, ventilation and cooling
- Biomechanical flow (e.g. blood flow through stent)
- Evaporation and drying of liquids
- Microclimate and human comfort
- Weather prediction
- Fire safety calculations
This broad range of applications alone already hints at the complex know-how needed to make accurate predictions with CFD. In the following sections, we will not dig into any of these fields specifically (although I will mention examples where appropriate), but outline in broad terms under which circumstances CFD calculations make (economic) sense and how the typical work-flow looks like.
When to use CFD - and when not to
Given the list above, it is tempting to think that basically any problem involving movement of a fluid can be simulated using CFD techniques. While this is mostly true, just because a certain problem can be simulated it does not mean that it should be. The question is rather: under what circumstances is it efficient and effective to use CFD? To answer the question, let’s see CFD as a “virtual experiment” competing with the costs and quality of its real-life counterpart. Here are some dimensions to compare these on:
|Cost||Mostly staff||Staff and hardware|
|Time||Depends on complexity||Depends on hardware|
|Scale||Any/arbitrary||Lab scale only|
Depending on the exact problem at hand, either physical experiments or simulations have clear advantages. But in a large number of cases, simulation is very cost-effective vs. experiments, either by avoiding costs for physical hardware completely, or by greatly reducing the number of experiments required.
Let’s go over each of these dimensions briefly:
The overall cost of a simulation vs. an experiment will, in many cases, be one of the bigger influencing factors when deciding which way to go. While CFD simulation was indeed very expensive only a decade ago, advances in computer science and increasing computation power are constantly lowering the cost. These days (2016), a large chunk of the cost of a CFD simulation is the cost for well-educated and experienced engineers. On top of that, there is infrastructure cost, cost for software, and energy cost for the actual computations. Considering all that, you can get a month’s worth of CFD simulation for as little as 20 k USD (18 k EUR), with smaller projects starting at around 2 weeks’ duration. Depending on the hardware needed, the costs for an actual physical experiment will be higher in most cases.
With respect to the time needed to run CFD simulations, there is a broad range. In many cases, the time needed for a complete CFD project will depend on two major factors: (1) whether the simulation is transient or not (i.e. time-dependent - see below for details) and (2) how many optimization re-runs are planned/necessary. CFD simulations can be run parallel on a massive scale on many CPUs at the same time. In many cases, simulations running on 64 CPU-cores can be computed overnight, but depending on the actual problem, a simulation can take a couple of days or even weeks. With modern hard- and software, the sweet spot between accuracy and computation time is often around 2-3 days for a simulation run. During that time, the simulation is monitored but does not need direct intervention, so that the engineer running it is mostly free for other tasks. Conversely, physical experiments might take a lot longer, especially when the measurement set-up must be designed, ordered and built before the actual work can start.
Scale is an area where simulation really shines. For the virtual experiment, it makes little difference if you simulate the tip of a syringe or an entire city block, while this can obviously be a big hurdle for physical experiments. In many cases, physical experiments need to be scaled down, making assumptions about scaling effects. You might be able to scale down your skyscraper to wind-tunnel size, but are you able to account for the pressure, temperature and speed differential that occur in real-life wind? In small scales, an experiment might be all but impossible - how do you accurately measure the flow-field of a syringe tip? So whenever you are dealing very large or very small geometries, computational fluid dynamics has a very clear advantage over experiments.
There is also a big difference between experiment and simulation when it comes to information. The spatial and time resolution as well as the number of variables are much higher in the simulation. A 3-dimensional CFD simulation can easily have more than a million cells (so called “voxels” - small volumetric elements that the simulation space is split into), and for each of those, the simulation will give you any type of physical information included in the mathematical models (speed, direction, temperature, pollutants, shear forces, vorticity, …) - literally hundreds of values for each cell in some simulation types. Simulations are also very flexible with respect to information frequency. You can select your time steps depending on how fast or slow the phenomenon that your are simulating changes, and therefore easily adapt the information density on the time scale. In physical experiments, this is much harder: you can only cover so many measurement points, frequency is restricted by sensor speed, and no sensor can measure as many properties as the computational model will generate. A simulation will almost certainly give you more information about the system in question, when compared to an experiment.
Obviously, safety is not an issue for simulations, while it can cause considerable overhead in experiments that require the use of dangerous substances. Closely related to this are costs of consumables during experiments, which are not an issue for water, but very much an issue for - let’s say - human plasma.
Accuracy can be a tricky thing to handle in both simulations and physical experiments. Even when measurements are tricky, physical experiments are usually a bit more straight-forward than simulations in terms of accuracy. This is due to the fact that simulations can behave sensitive to small errors. A mistake in setting up boundary conditions or even during meshing (the process of splitting the 3-dimensional simulation space into discrete volume cells, the aforementioned voxels) can cause issues in the simulation. Many experienced simulation engineers therefore use techniques like plausibility checks, mathematical quality checks and zero-state simulations (simulating an existing system before making changes) to keep results accurate. For many problems, CFD is very exact - in HVAC simulations, for example, the accuracy is often better than what standard temperature sensors can measure. In practice, we see cases with temperature deviations of simulation vs. experiment of less than 0.2°C, smaller than what common sensors measure reliably.
CFD Workflow - from problem definition to result
Now that we have an overview of what CFD is good for and when it makes sense to use it, we can dig a bit deeper and have a look at major phases of a CFD simulation, and what to watch out for in each of theses phases in practice.
Before diving into the text proper, have a look at the following video, which shows some real-life footage of a CFD simulation workflow:
In this phase, a number of preparation tasks need to be carried out before the actual simulation can be run. Many of the tasks here require skill and experience by the executing engineer.
The most basic task in this phase is to determine the actual problem that needs to be solved. While this sounds quite straight forward, it can take some time and discussion with the client to arrive at a sound problem definition. Often, this phase starts with a statement along the lines of “We want it to work better!” and ends up with something like “We want you to do a time-dependent simulation including heat exchange effects using a single fluid phase, optimizing the geometry, but not the inlet conditions”. A thorough understanding of the actual question to be answered helps tremendously, in order to pick the best underlying scientific theory to get exactly the answer needed without unnecessary calculation overhead. This is by no means trivial, as calculation models can easily differ by factors of 10 or even 100 in terms of calculation speed.
Once the basic task has been clarified, the next job is to set up the 3-dimensional simulation space (in rare cases, 2-dimensional simulation space). In practice, this often starts with an existing 3d drawing that is provided by the client. Frequently, this needs some manual re-drawing, to make sure there are no gaps in the geometry, different materials are properly grouped, excessive details are removed and so on. If there are no drawings available, they are either generated from scratch or on basis of a 3d laser scan.
The next step for the geometry is the so called “meshing”. In order to solve the mathematical model equations with sufficient accuracy over the whole spatial extent of the model, it needs to be split into small volumetric parts (voxels) or simply cells. This is a little bit like Minecraft or Lego, where each brick fills up part of the empty space through which the fluid moves. For most simulation frameworks, the cells do not need to be cubes, but can also take more complicated shapes. In all cases, though, each cell needs to conform to certain quality parameters (e.g. no gaps or overlaps to other cells, angles not too small, …). Doing this by hand can be a very tedious task, especially since there are typically a couple of hundred thousands cells in a simulation space. Often, advanced software (“meshers”) are used to do this job, but even those need to be carefully used, since the distribution of cells is often crucial to the quality of the simulation result. There should - for example - be an increase of smaller cells in regions of the geometry where the fluid moves fast, or where some parameter changes fast. In fact, asking your CFD engineer to show you the mesh is an easy quality check: if the mesh is not noticeably denser at walls, edges and regions with a lot of change, this is an early warning sign.
Just as important as the meshing is the set-up of so-called boundary conditions. These are “settings” for the simulation that become starting conditions for the mathematical models and are not changed themselves. Sometimes, these conditions are quite simple - for example, you can specify that a wall must have a certain temperature. But setting an unrealistic boundary condition can give completely unrealistic results, since the computer will calculate “as if” they were true. Again, it takes some experience in order to define boundary conditions in a way that allows realistic, robust simulation. If you as a client want to check with a CFD provider, ask about the uniformity of boundary conditions with questions like “Is the temperature of this wall really uniform and does not change with time?”, or “Is the volume flow the same over the entire inlet area?”.
With the problem defined and the simulation set up, the actual calculation part can start. This part requires relatively little human intervention once it is under way. Simulations are frequently parallelized, i.e. the calculation is split over a number of computing cores, all working in parallel to speed up the process. This means that most simulations will usually run on 8-128 cores simultaneously (though thousands of cores have also been used). Unfortunately, there is a caveat: the more processors you use, the more overhead you generate when the individual calculation jobs do their necessary data exchange. This is why the marginal speed increase becomes smaller and smaller the more processors you run in parallel. The sweet spot is often between 8 and 128 cores and usually requires computer clusters.
Depending on the software used, you might pay per core - which can become very expensive - easily a couple of orders of magnitude. In other cases, there is no such restriction and the cost of the simulation does not increase significantly when adding more cores. As a CFD client, you can ask your provider how pure calculation time factors into the project costs.
When the simulation is done - there are mathematical criteria to judge this - it is time to look at the results. This sounds straight forward enough, but also requires some IT skills. A transient simulation can easily generate a couple of terabytes of data, turning the handling of the results into a task for experienced engineers. Usually, the generated data are shown graphically using special visualization software, but there might be some calculation needed to compute derivative values: for example, in order to extract information about sound, a FFT (Fast Fourier Transformation) of the pressure data needs to be done. Once the relevant information has been prepared (e.g. moisture levels), it can be explored 3-dimensionally and finally documented using screenshots and videos. Typically, this will result in design recommendations of the CFD engineer to alleviate the initial problem and to optimize the performance of the system in question.
As a client, you might ask your CFD provider to not only provide a report of the findings, but to also keep the simulation files, so that you can follow up in the future if needed.
Contact us! We are happy to take a look at your project. The first consultation is always free!