6.1. General comments
In CFD the human factor plays an important role, as the results depend to a large extent on the com-petence and expertise of the user. It is worthwhile spending a few words on this rather embarrassing aspect of CFD, as it is one of the prime causes of uncertainty in the results of CFD simulations. This may help to avoid some, if not all, of the most easily avoidable mistakes in the future. Several factors may give rise to user errors:
• Lack of attention to detail, sloppiness, carelessness, mistakes and blunders.
• Too optimistic and uncritical use of CFD, thanks to the high accessibility through simple interactive graphical user interfaces in commercial software, and the convincing and seductive power of the colourful visualisations.
• Lack of experience so that the user is unaware of a technical difficulty or unaware that critical in-formation is missing.
• Unfamiliarity with a particular CFD code or code version, and the tacit assumption that certain pa-rameter settings are equivalent to those in a code or code version with which the user is more fa-miliar.
While the first two points are associated with the user’s attitude and personal disposition the remaining points refer to the question of experience and training.
6.2. Control of the working process
Many mistakes are made by mere lack of attention to detail, or because the user is not aware of fac-tors that can give rise to them. The best way to deal with these issues is for the user to have a clear checklist of issues that can arise which helps to ensure that all relevant problem areas have been dealt with. This becomes most important if the user has limited experience.
A formal management Quality Assurance (QA) system with checklists can help to support the inexpe-rienced user to produce quality CFD simulations. It has been noted by Roache [1998], however, that a CFD project can meet all formal QA requirements and still be of low quality (or flatly erroneous). On the other hand high quality work can be done without a formal QA system.
The guidelines given below provide examples of the sorts of issues that should be dealt with in a for-mal QA management system. The issues covered are based on the process of carrying out a CFD simulation as outlined in chapter 2.
6.2.1. Guidelines on problem definition
¾ Give careful thought at the outset of a CFD project to the requirements and objectives of the simu-lation. The following points should be considered:
• Are the objectives of the simulation clearly defined?
• Is a CFD simulation really appropriate or is a simple analysis or an experiment needed? Cir-cumstances where CFD is generally considered appropriate are when the flow physics or ge-ometry are sufficiently complex that simpler modelling approaches are invalid, or where ex-perimental data is lacking and cannot be obtained because it is too costly, dangerous or im-practical.
• What local/global quantities are needed from the simulation?
• What are the requirements on accuracy?
• What level of validation is necessary? Is this a routine application, where validation and cali-bration has already been carried out on similar flow fields, and where only relatively small changes can be expected from earlier similar simulations? Or is it a non-routine application, where little earlier validation work has been done?
• What are the important flow physics involved (heat transfer, radiation, steady, unsteady, com-pressible, single phase, laminar, turbulent, transitional, internal, external, etc.)?
• What is the area of primary interest (domain) for the flow calculation?
• Is the geometry well defined, and can symmetry or periodic boundary conditions be applied?
• Are the inlet and outlet boundary conditions clearly specified?
• What sensitivity tests should be carried out to assess the accuracy of the simulation?
• What level of computational resources is needed for the simulation (memory, disk space, cpu time, serial or parallel run because of time requirement) and are these available?
• What are the documentation/reporting requirements?
6.2.2. Guidelines on solution strategy
¾ Translate the problem definition into a solution strategy involving issues and questions that have been addressed in this document, such as:
• Mathematical and physical models, numerical schemes.
• Solution algorithm, pressure or density based solution method.
• Turbulence and other physical models.
• Available code/solver.
• Grid design and computational mesh.
• Boundary conditions.
• Convergence criterion.
• Validation and sensitivity test requirements.
6.2.3. Guidelines on user errors in the code-handling
¾ Try to minimise errors in the handling of the code by the use of a formal check list or by letting an-other CFD analyst check through the code input data. This will minimise the potential source of user errors when implementing the solution strategy with a particular code. The types of questions which should be considered are:
• Is the correct version of the code being used?
• The default parameter settings or alternatives should be reviewed. Have default parameters been changed which may affect the solution?
• Are the user defined routines or other software coupled to the code compatible with the cur-rent version of the code?
• Have the boundary conditions not only been properly defined, but also properly applied?
• Has the appropriate system of units been used?
• Is the geometry correct?
• Are all parts of the mesh correctly matched and not overlapping, especially after importing grid parts from different sources?
• Are the correct physical properties specified?
• Have the intended physical and mathematical models been used (e.g. gravity forces, rotation, user defined functions)?
• Have the specified models been changed from those in an earlier code version?
• Have any user-defined subroutines been used, and have these been checked with regard to programming errors, units, and references to pre-defined variables?
• Has the appropriate convergence criterion been defined and used?
• Is there a reasonable maximum iteration number defined, especially in connection with a cpu-time limit for batch jobs?
• Have any warnings been generated by the software, and have they been properly understood and acted upon?
• Have the necessary files from other computer systems been transferred correctly?
6.2.4. Guidelines on interpretation
¾ Make full use of the wide variety of visual tools available in modern CFD packages to interpret the flow-field that has been calculated. A good physical understanding of the application and experi-ence with similar simulations are the best guide as to which plots to make. Options include:
• Contours of parameters on arbitrary cross-sections through the flow.
• Contours of parameters on wetted surfaces in flow, such as wall pressures.
• Special plots involving projections for specific applications, such as blade-to-blade or merid-ional views in turbomachinery blade rows.
• Line diagrams of parameters.
• Three-dimensional plots of streamlines.
• Vector plots.
• Three-dimensional views of iso-surfaces, such as regions of low pressure or high mach num-ber.
• Surface streak lines.
• Use of identification methods to visualise vortical structures, such as line integral convolution (LIC)
• Video sequences of unsteady simulations.
¾ Produce plots of parameters that are relevant to the physical understanding of the flow (such as pressure fields, velocities, entropy, losses, wall shear stresses, regions of reverse flow, etc.), and also of parameters that might help in the interpretation of the quality of the simulation (such as the ratio of turbulent to laminar viscosity, grid skewness, grid aspect ratio, residuals, etc.).
¾ Don’t be seduced into believing that the solution is correct just because it has converged and pro-duced high-quality colour plots (or even seductive video presentations) of the CFD simulations.
Make sure that an elementary interpretation of the flow-field explains the fluid behaviour and that the trends of the flow analysis can be reconciled with a simple view of the flow.
¾ Be aware of the possible errors from bugs in the pre- and post-processors (interpolation, extrapo-lation, averaging, etc.). Make sure that the mean values of engineering parameters derived from the simulation are computed consistently (e.g. mass-average values, area-average values, time-average values). Calculation of local and mean engineering parameters with external post-processing software may be inconsistent with the solution method of the code used (e.g. calculat-ing shear stresses from the velocities, calculatcalculat-ing shear stresses uscalculat-ing nodal values instead of wall functions). Check that any test data used for comparison with the simulations is also com-puted in the same way as the data from the simulation.
¾ Consider whether the interpretation of the results, and any decisions made on the basis of them, are within the accuracy of the computation.
6.2.5. Guidelines on documentation
¾ Keep good records of the simulation with clear documentation of assumptions, approximations, simplifications, geometry and data sources.
¾ Organise the documentation of the calculations so that another CFD expert can follow what has been done.
¾ Be aware that the level of documentation required depends strongly on the customer's require-ments as defined in the problem definition.
6.3. Training requirements for CFD users
The growth in the use of CFD codes and the trend for them to become rich packages with lots of alter-native modelling options, steadily increases the risk of user errors. This trend is reinforced by the ease of use of modern computer codes with simple graphical user interfaces making them available for in-experienced users. Although efforts taken to simplify the usage of CFD codes are most welcome, careful training with realistic exercises should still be considered as the starting point of any user’s CFD career. The theoretical part of the training should focus on fundamental modelling features, their underlying assumptions and their limitations. The same information is also a central part of a good user documentation. Unlike linear finite element stress analysis, CFD still requires expertly trained us-ers for good results. In situations where non-experienced usus-ers have to be used, some restriction on their freedom to adjust critical parameters might be advisable, and they should be limited to simula-tions of routine types.
Depending on the CFD software, additional training on grid generation may be advisable.
6.3.1. Guidelines on the training of CFD users
¾ A CFD user for non-routine applications should have good training and knowledge in classical fluid mechanics (including experimental, analytical and computational aspects), a broad understanding of numerical methods as applied to fluid flows, and detailed knowledge of the application being examined. This means that the user should be able to understand the limitations of the models used (e.g. turbulence, radiation, buoyancy driven flows, numerical models, etc.) and be aware of their relevance when being applied to a particular problem.
¾ The training and education requirement for more routine applications can be less stringent, pro-vided that clear guidelines or procedures have been established for the use of the code being used. An example of a routine application would be the simulation of a standard component in a design environment where many previous designs have been calculated and only relatively small changes in geometries and boundaries conditions occur.
¾ In both routine and non-routine applications, training on the use of the specific CFD code with the solution of realistic exercises is needed.
¾ Training should be repeated regularly, and the user should frequently read the release notes and manuals issued by the code supplier, as these are a good source of educational information.