Note that in case of any changes in the SIZE file, a recompilation is necessary.
Suppose you wish to simulate flow through an axisymmetric pipe, of radius and length . You estimate that you will need 3 elements in radial () direction, and 5 in the direction, as depicted in Fig. 4.1. This would be specified by the following input file (called pipe.box) to genbox:
Suppose you wish to have the mesh be graded, that you have increased resolution near the wall. In this case you change ratio in the -specification of the element distribution. For example, changing the 3 lines in the above genbox input file from
yields the mesh shown in Fig. 4.2.
You can also specify your own, precise, distribution of element locations. For example, another graded mesh similar to the one of the preceding example could be built by changing the genbox input file to contain:
Here, the positive number of elements for the direction indicates that genbox is expecting Nely+1 values of positions on the -element distribution line. This is the genbox default, which explains why it corresponds to Nely 0. The corresponding mesh is shown in Fig. 4.3.
For complex shapes, it is often convenient to modify the mesh direction in the simulation code, Nek5000. This can be done through the usrdat2 routine provided in the .usr file. The routine usrdat2 is called by nek5000 immediately after the geometry, as specified by the .rea file, is established. Thus, one can use the existing geometry to map to a new geometry of interest.
For example, suppose you want the above pipe geometry to have a sinusoidal wall. Let denote the old geometry, and denote the new geometry. For a domain with , the following function will map the straight pipe geometry to a wavy wall with amplitude , wavelength :
In nek5000, you would specify this through usrdat2 as follows
Note that, since nek5000 is modifying the mesh, postx will not recognize the current mesh unless you tell it to, because postx looks to the .rea file for the mesh geometry. The only way for nek5000 to communicate the new mesh to postx is via the .fld file, so you must request that the geometry be dumped to the .fld file. This is done by modifying the OUTPUT SPECIFICATIONS, which are found near the bottom of the .rea file. Specifically, change
The result of above changes is shown in Fig. 4.4.
An updated version of genb6, known as genb7, is currently under development and designed to simply/automate the construction of cylindrical annuli, including basic transition-to-Cartesian elements. More sophisticated transition treatments may be generated using the GLOBAL REFINE options in prenek or through an upgrade of genb7, as demand warrants. Example 2D and 3D input files are provided in the nek5000/doc files box7.2d and box7.3d. Figure 4.5a shows a 2D example generated using the box7.2d input file, which reads:
An example of a mesh is shown in Fig. 4.5a. The mesh has been quad-refined once with oct-refine option of prenek. The 3D counterpart to this mesh could joined to a hemisphere/Cartesian transition built with the spherical mesh option in prenek.
In nek5000/tools, there is a code n2to3.f that can be compiled with your local fortran compiler (preferably not g77). By running this code, you can extend two dimensional domains to three dimensional ones with a user-specified number of levels in the z-direction. Such a mesh can then be modified using the mesh modification approach. Assuming you have a valid two-dimensional mesh, n2to3 is straightforward to run. Below is a typical session, upon typing n2to3 the user is prompted at the command line
In this context CEM stands for computational electromagnetics, a spin-off of the original Nek5000 code.
The domain in which the fluid flow/heat transfer problem is solved consists of two distinct subdomains. The first subdomain is that part of the region occupied by fluid, denoted , while the second subdomain is that part of the region occupied by a solid, denoted . These two subdomains are depicted in Fig. 1.1. The entire domain is denoted as . The fluid problem is solved in the domain , while the temperature in the energy equation is solved in the entire domain; the passive scalars can be solved in either the fluid or the entire domain.
We denote the entire boundary of as , that part of the boundary of which is not shared by as , and that part of the boundary of which is shared by . In addition, are analogously defined. These distinct portions of the domain boundary are illustrated in Fig.1.1. The restrictions on the domain for Nek5000 are itemized below.
Fully general three-dimensional meshes generated by other softwares packages can be input to PRENEK as import meshes.
If the imposed boundary conditions allow for motion of the boundary during the solution period (for example, moving walls, free-surfaces, melting fronts, fluid layers), then the geometry of the computational domain is automatically considered in Nek5000 as being time-dependent.
For time-dependent geometry problems, a mesh velocity w is defined at each collocation point of the computational domain (mesh) to characterize the deformation of the mesh. In the solution of the mesh velocity, the value of the mesh velocity at the moving boundaries is first computed using appropriate kinematic conditions (for free-surfaces, moving walls and fluid layers) or dynamic conditions (for melting fronts). On all other external boundaries, the normal mesh velocity on the boundary is always set to zero. In the tangential direction, either a zero tangential velocity condition or a zero tangential traction condition is imposed; this selection is automatically performed by Nek5000 based on the fluid and/or thermal boundary conditions specified on the boundary. However, under special circumstances the user may want to override the defaults set by Nek5000, this is described in the PRENEK manual in Section 5.7.1 If the zero tangential mesh velocity is imposed, then the mesh is fixed in space; if the zero traction condition is imposed, then the mesh can slide along the tangential directions on the boundary. The resulting boundary-value-problem for the mesh velocity is solved in Nek5000 using a elastostatic solver, with the Poisson ratio typically set to zero. The new mesh geometry is then computed by integrating the mesh velocity explicitly in time and updating the nodal coordinates of the collocation points.
Note that the number of macro-elements, the order of the macro-elements and the topology of the mesh remain unchanged even though the geometry is time-dependent. The use of an arbitrary-Lagrangian-Eulerian description in Nek5000 ensures that the moving fronts are tracked with the minimum amount of mesh distortion; in addition, the elastostatic mesh solver can handle moderately large mesh distortion. However, it is the responsibility of the user to decide when a mesh would become "too deformed" and thus requires remeshing. The execution of the program will terminate when the mesh becomes unacceptable, that is, a one-to-one mapping between the physical coordinates and the isoparametric local coordinates for any macro-element no longer exists.
The boundary conditions for the governing equations given in the previous section are now described.
The boundary conditions can be imposed in various ways:
The general convention for boundary conditions in the .rea file is
Since there are no supporting tools that will correctly populate the .rea file with the appropriate values, temperature, velocity, and flux boundary conditions are typically lower case and values must be specified in the userbc subroutine in the .usr file.
Two types of boundary conditions are applicable to the fluid velocity : essential (Dirichlet) boundary condition in which the velocity is specified; natural (Neumann) boundary condition in which the traction is specified. For segments that constitute the boundary , see Fig. 1.1, one of these two types of boundary conditions must be assigned to each component of the fluid velocity. The fluid boundary condition can be all Dirichlet if all velocity components of are specified; or it can be all Neumann if all traction components , where is the identity tensor, is the unit normal and is the dynamic viscosity, are specified; or it can be mixed Dirichlet/Neumann if Dirichlet and Neumann conditions are selected for different velocity components. Examples for all Dirichlet, all Neumann and mixed Dirichhlet/Neumann boundaries are wall, free-surface and symmetry, respectively. If the nonstress formulation is selected, then traction is not defined on the boundary. In this case, any Neumann boundary condition imposed must be homogeneous; i.e., equal to zero. In addition, mixed Dirichlet/Neumann boundaries must be aligned with one of the Cartesian axes.
For flow geometry which consists of a periodic repetition of a particular geometric unit, the periodic boundary conditions can be imposed, as illustrated in Fig. 1.1.
|Identifier||Description||Parameters||No of Parameters|
|P||periodic||periodic element and face||2|
|W||wall (no slip)||-||0|
|E||Interior boundary||Neighbour element ID||2|
|v||user defined Dirichlet velocity|
|t||user defined Dirichlet temperature|
|f||user defined flux|
The open(outflow) boundary condition ("O") arises as a natural boundary condition from the variational formulation of Navier Stokes. We identify two situations
For a fully-developed flow in such a configuration, one can effect great computational efficiencies by considering the problem in a single geometric unit (here taken to be of length L), and requiring periodicity of the field variables. Nek5000 requires that the pairs of sides (or faces, in the case of a three-dimensional mesh) identified as periodic be identical (i.e., that the geometry be periodic).
For an axisymmetric flow geometry, the axis boundary condition is provided for boundary segments that lie entirely on the axis of symmetry. This is essentially a symmetry (mixed Dirichlet/Neumann) boundary condition in which the normal velocity and the tangential traction are set to zero.
For free-surface boundary segments, the inhomogeneous traction boundary conditions involve both the surface tension coefficient and the mean curvature of the free surface.
The three types of boundary conditions applicable to the temperature are: essential (Dirichlet) boundary condition in which the temperature is specified; natural (Neumann) boundary condition in which the heat flux is specified; and mixed (Robin) boundary condition in which the heat flux is dependent on the temperature on the boundary. For segments that constitute the boundary (refer to Fig. 2.1), one of the above three types of boundary conditions must be assigned to the temperature.
The two types of Robin boundary condition for temperature are : convection boundary conditions for which the heat flux into the domain depends on the heat transfer coefficient and the difference between the environmental temperature and the surface temperature; and radiation boundary conditions for which the heat flux into the domain depends on the Stefan-Boltzmann constant/view-factor product and the difference between the fourth power of the environmental temperature and the fourth power of the surface temperature.
|Identifier||Description||Parameters||No of Parameters|
|I||insulated (zero flux) for temperature||0|
where is the normal vector and the tangent vector. If the normal and tangent vector are not aligned with the mesh the stress formulation has to be used.
The boundary conditions for the passive scalar fields are analogous to those used for the temperature field. Thus, the temperature boundary condition menu will reappear for each passive scalar field so that the user can specify an independent set of boundary conditions for each passive scalar field.
In the spatial discretization, the entire computational domain is subdivided into macro-elements, the boundary segments shared by any two of these macro-elements in and are denoted as internal boundaries. For fluid flow analysis with a single-fluid system or heat transfer analysis without change-of-phase, internal boundary conditions are irrelevant as the corresponding field variables on these segments are part of the solution. However, for a multi-fluid system and for heat transfer analysis with change-of-phase, special conditions are required at particular internal boundaries, as described in the following.
For a fluid system composes of multiple immiscible fluids, the boundary (and hence the identity) of each fluid must be tracked, and a jump in the normal traction exists at the fluid-fluid interface if the surface tension coefficient is nonzero. For this purpose, the interface between any two fluids of different identity must be defined as a special type of internal boundary, namely, a fluid layer; and the associated surface tension coefficient also needs to be specified.
In a heat transfer analysis with change-of-phase, Nek5000 assumes that both phases exist at the start of the solution, and that all solid-liquid interfaces are specified as special internal boundaries, namely, the melting fronts. If the fluid flow problem is considered, i.e., the energy equation is solved in conjunction with the momentum and continuity equations, then only the common boundary between the fluid and the solid (i.e., all or portion of in Fig. 1.1) can be defined as the melting front. In this case, segments on that belong to the dynamic melting/freezing interface need to be specified by the user. Nek5000 always assumes that the density of the two phases are the same (i.e., no Stefan flow); therefore at the melting front, the boundary condition for the fluid velocity is the same as that for a stationary wall, that is, all velocity components are zero. If no fluid flow is considered, i.e., only the energy equation is solved, then any internal boundary can be defined as a melting front. The temperature boundary condition at the melting front corresponds to a Dirichlet condition; that is, the entire segment maintains a constant temperature equal to the user-specified melting temperature throughout the solution. In addition, the volumetric latent heat of fusion for the two phases, which is also assumed to be constant, should be specified.
For time-dependent problems Nek5000 allows the user to choose among the following types of initial conditions for the velocity, temperature and passive scalars:
A tabulated summary of the compatibility of these initial condition options with various other solution strategies/parameters is given in the appendix.
Genmap is spectral graph partitioning tool, similar to e.g. METIS, which partitions the graph associated to the mesh to assure optimal communication time in HPC applications. Let us consider a simple mesh such as the one in Fig. 4.6. The vertices are distributed in a random fashion, which is the way they may be provided by some mesh generator. Let us assume the vertices are here given as
The geometry is already stored in the .rea file by the point coordinates, and not vertex numbers
Let us a regard the mesh in Fig. 4.6 as a graph of vertices and edges, . We define the Laplacian matrix associated to a graph as . We define as the degree of a node the number of incident edges, e.g. in Fig. 4.6 and .
The main ides of the spectral bisection algorithm is
The eigenvectors and eigenvalues are computed using Lanczos’s algorithm. These steps are repeated recursively on each of the two branches of the graph . This is possible since according to Fiedler’s theorems the graph is connected, connected only if no , and for each subgraph the algebraic connectivities satisfy .
To run the genmap code be sure that the Nek tools are up-to-date and compiled. At command line type: genmap NOTE-If the executables for the tools were not placed in the bin directory(default), include the path to the genmap executable. We give here the output for the .rea file in the Kovasznay example
The user is prompted for .rea file name and should enter only the prefix of the .rea file. The user is prompted for mesh tolerance value. Typically a value of .05 is sufficient. Increasing or decreasing this value should make very little difference in the mesh generation. However, if given an error from genmap, the tolerance may need to be made slightly more generous.
A successful genmap run will produce a .map file with the proper processor decomposition.
NOTE: For large element counts, it is not uncommon for genmap to be produce a few disconnected sets. These sets are typically under 7 elements large and will not affect optimization of the NEK5000 run. If a disconnected set is produced, genmap will output the following warning to stdout.
Here, N0 is the number of elements disconnected from the set of NEL elements, Nsets is the counter of disconnected sets found, and Nlarge sets is the number of sets greater than 64 elements in size. Nlarge sets should always be 0. If not, please contact someone on the developer team so we can be sure to have a more optimal partition of your mesh.
Genmap outputs an ordered set of numbers which are organized as follows Line number 1 contains the header nel, nactive, depth, d2, npts, nrank, noutflow
For the Kovasnay flow on an 8 element mesh with periodic boundary conditions we have 8 12 3 8 32 12 0
Next we have the data (one line per element, listed in order of global element number) ==== 6 12 11 6 5
This means that elemnt one (since we are on the first line) belongs to group 6, and this element is given by vertices in unique ordering. The vertices are ordered in symmetric ordering (starting at 1)
3 - 4 | | 1 - 2
To distribute amongst processors, one just takes as many consecutive processors as one wants.
1This manual is old may soon be deprecated