The preconditioner is a mathematical technique for improving the speed of the solver when the fluid flow is slow compared to the speed of sound. Use of the preconditioner does not alter the final converged solution produced by the solver. The preconditioner factor is used to improve the robustness of the solver in regions of very low speed.

'unsteady':{# Total time in seconds'total time':1.0,# Time step in seconds'time step':1.0,# Dual time step time accuracy (options: 'first' or 'second' order)'order':'second',# Number of pseudo time (steady) cycles to run before starting dual timestep time accurate simulation'start':3000,},

'scheme':{# Either 'runge kutta' or 'lu-sgs''name':'runge kutta',# Number of RK stages 'euler' or 1, 4, 5, 'rk third order tvd''stage':5,# Options: 'local timestepping' for steady state or dual time step time accurate# 'global timestepping' for time accurate'kind':'local timestepping'},

The mesh is automatically coarsened by merging cells on successive layers in order to accelerate solver convergence. This does not alter the accuracy of the solution on the finest (original) mesh. Advanced users can control the number of geometric multigrid levels and the ‘prolongation’ of quantities from coarse to fine meshes.

The polynomial basis on which the solution is computed can be successively coarsened, thus allowing the solution to be evolved quicker due to weakened stability restrictions at lower polynomial orders. This does not alter the accuracy of the solution on the highest polynomial order.

The Courant-Friedrichs-Lewy (CFL) number controls the local pseudo time-step that the solver uses to reach a converged solution. The larger the CFL number, the faster the solver will run but the less stable it will be. The default values should be appropriate for most cases, but for lower-quality meshes or very complex geometries it may be necessary to use lower values (e.g. CFL of 1.0). In such cases it may also be helpful to turn off Multigrid (above) by setting the maximum number of meshes to 0.

For steady-state simulations, the number of pseudo time cycles is the same as the number of steps that the solver should use to reach a converged solution. Note that the solver uses local pseudo time-stepping (the time-step varies according to local conditions) so any intermediate solution is not necessarily time-accurate.

For unsteady (time-accurate) simulations, zCFD uses ‘dual time-stepping’ to advance the solution in time. For unsteady simulations, the number of pseudo time cycles determines the number of inner iterations that the solver uses to converge each real time step.

# Governing equations to be used (options: RANS, euler, viscous)'equations':'RANS',

Compressible Euler flow is inviscid (no viscosity and hence no turbulence). The compressible Euler equations are appropriate when modelling flows where momentum significantly dominates viscosity - for example at very high speed. The computational mesh used for Euler flow does not need to resolve the flow detail in the boundary layer and hence will generally have far fewer cells than the corresponding viscous mesh would have.

The viscous (laminar) equations model flow that is viscous but not turbulent. The Reynolds number (http://en.wikipedia.org/wiki/Reynolds_number) of a flow regime determines whether or not the flow will be turbulent. The computational mesh for a viscous flow does have to resolve the boundary layer, but the solver will run faster as fewer equations are being included.

The location of the DG solution points can be changed from the default using the following entry. The definitions first need to be imported by including this import statement at the start of the control dictionary

Dynamic (shear, absolute or molecular) viscosity should be defined at the static temperature previously specified. This can be specified either as a dimensional quantity or by a Reynolds number and reference length

For internal flows there is greater dependence on Reynolds number as the largest eddies in the flow are limited
by the characteristic lengths of the geometry (e.g. The height of the channel or diameter of the pipe). Typical values are:

'profile':{'field':'inflow_field.vtp',# Localise field using wall distance rather that z coordinate'local profile':'true',},

Note

The conditions in the VTK file are specified by node based arrays with names ‘Pressure’, ‘Temperature’, ‘Velocity’, ‘TI’ and ‘EddyViscosity’. Note the field will override the conditions specified previously therefore the user can specify only the conditions that are different from default.

Certain conditions are specified relative to a reference set of conditions

zCFD will automatically detect zone types and numbers in a number of mesh formats, and assign appropriate boundary conditions. The type tags follow the Fluent convention (wall = 3, etc), and if present no further information is required. Alternatively, the mesh format may contain explicitly numbered zones (which can be determined by inspecting the mesh). In this case, the user can specify the list of zone numbers for each boundary condition ‘type’ and ‘kind’ (see below).

'temperature':{# Temperature field specified as a VTK file'field':'temperate.vtp',},

Note

The temperature at each boundary face is set by finding the nearest point to the face centre on the supplied VTK file with the temperature
value looked up in a node based scalar array called ‘Temperature’

The forest height at each boundary face is set by finding the nearest point to the face centre on the supplied VTK file with the forest height value looked up in a node based scalar array called ‘Height’