Fire Simulation for Engineers/FDS/Computational Domain

= Computational domain =

Second, the computational domain is defined via the MESH namelist group.

All FDS calculations must be performed within a domain that is made up of rectilinear volumes called meshes. Each mesh is divided into rectangular cells, the number of which depends on the desired resolution of the flow dynamics. Some initial conditions are prescribed for the flow domain via the INIT namelist group.

Defining a mesh, MESH
MESH is the namelist group that defines the volume of the computational domain. For example,

&MESH IJK=10,20,30, XB=0.0,1.0,0.0,2.0,0.0,3.0 /

defines a mesh that spans the volume starting at the origin (0., 0., 0.) and extending 1 m in the positive x direction, 2 m in the positive y direction, and 3 m in the positive z direction.

The mesh is subdivided into uniform cells via the parameter IJK. In this example, the mesh is divided into 10 cm cubes: 10 cubes in x direction, 20 cubes in y direction, and 30 cubes in z direction.

Any obstructions or vents that extend beyond the boundary of the mesh are cut off at the boundary. There is no penalty for defining objects outside of the mesh, and these objects will not appear in Smokeview either.

Note that it is best if the mesh cells resemble cubes, that is, the length, width and height of the cells ought to be roughly the same.

Keep in mind that the Large Eddy Simulation technique (LES) is based on the assumption that the numerical mesh should be fine enough to allow the formation of eddies that are responsible for the mixing. In general, eddy formation is limited by the largest dimension of a mesh cell, thus shrinking the mesh resolution in one or two directions may not necessarily lead to a better simulation if the third dimension is large.

Because an important part of the calculation uses a Poisson solver based on Fast Fourier Transforms (FFTs) in the y and z directions, the second and third dimensions of the mesh should each be of the form $$2^{k}\times3^{m}\times5^{n}$$, where k, m and n are integers. For example, $$64 = 2^{6}$$, $$72 = 2^{3} \cdot 3^{2}$$ and $$108 = 2^{2} \cdot 3^{3}$$ are good mesh cell divisions, but 37, 99 and 109 are not.

The first number of mesh cell divisions (the I in IJK) does not use FFTs and need not be given as a product of small numbers.

Here is a list of numbers between 1 and 1024 that can be factored down to 2’s, 3’s and 5’s:

The following table summarizes some MESH parameters:

Multiple meshes
The computational domain can consist of many connected mesh. Each mesh must have its MESH namelist group.

For example,

&MESH IJK=32,32,16, XB=0.0,1.6,0.0,1.6,0.0,0.8 / &MESH IJK=32,32,16, XB=0.0,1.6,0.0,1.6,0.8,1.6 / &MESH IJK=32,32,16, XB=0.0,1.6,0.0,1.6,1.6,2.4 / &MESH IJK=32,32,16, XB=0.0,1.6,0.0,1.6,2.4,3.2 /

describes a domain composed of four connected meshes, as in the figure below.



The connections must always follow a simple rule of mesh alignment, an integer (1, 2, 3...) number of fine cells exactly abuts each coarse cell. Mesh alignment is depicted in the figure below:



The following rules of thumb should also be followed when setting up a multiple mesh calculation:

• Avoid putting mesh boundaries where critical action is expected, especially fire. Sometimes fire spread from mesh to mesh cannot be avoided, but if at all possible try to keep mesh interfaces relatively free of complicated phenomena since the exchange of information across mesh boundaries is not yet as accurate as cell to cell exchanges within one mesh.

• If a planar obstruction is close to where two meshes abut, make sure that each mesh sees the obstruction. If the obstruction is even a millimeter outside of one of the meshes, that mesh does not account for it, in which case information is not transferred properly between meshes.

• Experiment with different mesh configurations using relatively coarse mesh cells to ensure that information is being transferred properly from mesh to mesh. There are two issues of concern. First, does it appear that the flow is being badly affected by the mesh boundary? If so, try to move the mesh boundaries away from areas of activity. Second, is there too much of a jump in cell size from one mesh to another? If so, consider whether the loss of information moving from a fine to a coarse mesh is tolerable.

Conformity to the mesh
All geometric objects must conform to the rectangular mesh. If you create geometrical objects that do not precisely conform to the underlying mesh, FDS shifts them to the closest mesh cell as shown in the figure below



Choosing the right mesh dimension:a sensitivity study
The most important numerical parameter in FDS is the grid cell size. CFD models solve an approximate form of the conservation equations of mass, momentum, and energy on a numerical grid. The error associated with the discretization of the partial derivatives is a function of the size of the grid cells and the type of differencing used. FDS uses second-order accurate approximations of both the temporal and spatial derivatives of the Navier-Stokes equations, meaning that the discretization error is proportional to the square of the time step or cell size. In theory, reducing the grid cell size by a factor of 2 reduces the discretization error by a factor of 4. However, it also increases the computing time by a factor of 16 (a factor of 2 for the temporal and each spatial dimension). Clearly, there is a point of diminishing returns as one refines the numerical mesh. Determining what size grid cell to use in any given calculation is known as a grid sensitivity study.

In general, you should build an FDS input file using a relatively coarse mesh, and then gradually refine the mesh until you do not see appreciable differences in your results.

A point of diminishing returns is reached when the improvement in the quality of the results is outweighed by the cost of the computation. When this point is reached depends on the application. It also depends on the quantities that are of interest. Some quantities, like hot gas layer temperature or height, do not typically require as fine a numerical grid as quantities such as the heat flux to targets near the fire.

For simulations involving buoyant plumes, a measure of how well the flow field is resolved is given by the non-dimensional expression $$\mathrm{D}^{*}/\delta x$$, where $$\mathrm{D}^{*}$$ is a characteristic fire diameter and $$\delta x$$ is the nominal size of a mesh cell. $$\mathrm{D}^{*}$$ is defined as:

$$\mathrm{D}^{*}=\left(\frac{\dot{Q}}{\rho_{\infty}\, c_{p}\, T_{\infty}\,\sqrt{g}}\right)^{\frac{2}{5}}$$ where $$\dot{Q}$$ is the heat release rate of the fire in kW, $$\rho_{\infty}$$ air density (~1.2 kgm−3, cp air thermal capacity (~1 kJ kg−1K−1), $$T_{\infty}$$ ambient air temperature (~293 K), g gravitational acceleration (~9.81 m s−2).

The quantity $$\mathrm{D}^{*}/\delta x$$ can be thought of as the number of computational cells spanning the characteristic (not necessarily the physical) diameter of the fire. The more cells spanning the fire, the better the resolution of the calculation. It is better to assess the quality of the mesh in terms of this non-dimensional parameter, rather than an absolute mesh cell size. For example, a cell size of 10 cm may be adequate, in some sense, for evaluating the spread of smoke and heat through a building from a sizable fire, but may not be appropriate to study a very small, smoldering source.

As an example, in the mesh sensitivity study for [NUREG 1824], the $$\mathrm{D}^{*}/\delta x$$ values ranged from 4 to 16. These values were used to adequately resolve plume dynamics, along with other geometrical characteristics of the models as well. This range does not indicate what values to use for all models, only what values worked well for that particular set of models.

Initial conditions of the computational domain, INIT
At the start of any calculation, the temperature is ambient everywhere, the flow velocity is zero everywhere, nothing is burning, and the mass fractions of all species are uniform.

To change the starting ambient conditions within some volumetric region of the flow domain add lines of the form:

&INIT XB=0.5,0.8,2.1,3.4,2.5,3.6, TEMPERATURE=30. /

the initial temperature of the gas phase shall be 30 °C instead of the ambient within the prescribed volume. This construct can also be used for DENSITY or MASS_FRACTION(n).

The INIT construct may be useful in examining the influence of stack effect in a building, where the temperature is different inside and out.

For setting initial temperature of a solid obstruction see Subsection [sub:initial-temp-of-solid-obst].

Also the MISC namelist group can be used to set a variety of initial conditions.

An initial velocity on the domain can be prescribed via U0, V0, and W0 parameters. Normally, the initial values of the gas velocity in each of the coordinate directions are all 0 m/s, but there are a few applications where it is convenient to start the flow immediately, like in an outdoor simulation involving wind.

A different ambient temperature of the domain can be prescribed via the TMPA parameter.

To model a sloping roof or tunnel you can change the direction of the gravity vector. The GVEC parameter contains the 3 components of gravity, in m/s2. The default is GVEC=0,0,-9.81

For example,

&MISC U0=2., TMPA=25., GVEC=-0.114377,0.,-9.809333 /

generates an initial wind speed to 2 m/s in +x direction, sets ambient temperature to 25 °C, and bends the gravity vector in -x direction.

The following table summarizes some INIT parameters: