- Generated on Sun Jun 16 2024 23:45:17 for MAIA by
1.9.5
|
MAIA bb96820c
Multiphysics at AIA
|
The m-AIA framework has its own tool for the parallel generation of hierarchical Cartesian meshes which are used by the FV, FVMB, LB, DG, and the LS solver. Like the m-AIA solver environment the grid generator receives the required information from a property.toml-file. To tell m-AIA to run the grid generator instead of the solver environment set the following properties to:
In general, it is wise to use specific property files for the grid generator and the solver setup to avoid an excessive amount of properties that make it difficult to create a concise setup. In the following we will go through the various functionalities of the grid generator and the corresponding properties.
To define the directory the generated grid is written to the property outputDir can be set accordingly. The name of the grid file can be defined setting the property gridOutputFileName. The name of the geometry.toml-file containing information on the files providing the geometry itself (and the according boundary conditions) is given by geometryInputFileName Note that all file paths refer to the base directory of the setup. An examplary setup for these properties could be:
Some parameters specifiying the allocation of the memory required for the grid generation have to be determined in theproperty file. Heap memory is specified by the property scratchSize. Based on experience for the grid generation scratchSize = 5.0 is sufficient in most cases. Additionally, the cell collector has to be allocated by defining the property maxNoCells which specifies the maximum number of cells per rank. Keep in mind that up to the minLevel no partitioning of the grid is performed. Therefore, every rank must be able to generate least all cells at the minLevel. We will elaborate further on the meaning of the various cell levels below. More details on the parallelization procedure are given here.
Details on the files providing the actual geometry are given in the geometry.toml-file. The geometry of the computational domain is provided via ASCII .stl-files for a 3D setup and simple coordinate sequences in 2D. The paths to these files are given by setting the incremented property filename.i where i refers to the i-th file. For every new boundary condition applied to a part of the geometry a new file has to be provided. The total number of files is then given in noSegments. An example for a 3D domain the boundaries of which are given by three segments and which contains an additional cylinder which is given by a fourth file could look as follows:
The given segment files can be summarized to the the domain boundaries and, e.g, bodies within the computational domain by listing the increments of the files in a respective field of the property body_segments:
Eventually, boundary conditions are assigned to each boundary defined by the segment files by setting BC.i to the ID of the desired boundary condition for the .stl with the respective increment i. For the example given above, this could look as follows:
Now all geometries are defined and have been assigned a boundary condition. With the given information the geometry.toml-file is now complete.
The mesh generation is based on the sequential subdivision of a base cube/rectangle (from now on simply refered to as cube) with the edge length \(L_0\). The edge length \( L_0 \) is given by the largest dimension of the provide geometry segment files, such that the geometry fits entirely into the base cube. The cell length at a given level \( l \) is then given by:
\begin{align} L_{l} = L_0 \left( \frac{1}{2} \right)^{l} \end{align}
The uniform refinement of the mesh is defined by the properties minLevel and maxUniformRefinementLevel.
minLevel: defines the refinement level up to which the grid generation runs serially. In the most simple case the partitioning of the grid takes place on the minLevel both in the solver and in the mesh generator. A high minLevel can be desirable to achieve a well balanced partitioning. The mesh generation of such grids can, however, require large amounts of memory as no parallelization is done before the minLevel is reached. More details on the parallelization are given here.maxUniformRefinementLevel: defines the level up to which the complete mesh is refined uniformely. Must be equal to or larger than the minLevel.Additional local refinement can be applied during mesh generation to properly resolve relevant parts of the computational domain. The maximum refinement level can be defined by setting the property maxRfnmntLvl accordingly. Adaptive mesh refinement strategies that are applied at runtime of the simulation are described here. For the purpose of a-priori mesh refinement two options are available:
To enable the use of these refinement methods the property localRfnMethod offers the following options:
localRfnMethod | Description |
|---|---|
| no local mesh refinement is applied | |
| only patch refinement is applied | |
| only boundary refinement is applied | |
| both patch and boundary refinement is applied |
In the following we will go through the different options.
Various options of differently shaped patches are available to refine the mesh within the patch region. The geometric shape of the patch is defined by providing the according token in the property localRfnLvlMethods. The required geometric paramters to define the shape of the patch are provided as comma-separated values in the property localRfnLevelProperties. An overview of the available patch geometries and the required parameters are given in in the following table:
| Shape | localRfnLvlMethods | Parameters |
|---|---|---|
| Box | \( x_{min},\, y_{min},\, z_{min},\, x_{max},\, y_{max},\, z_{max} \) | |
| Sphere | \( x_{c},\, y_{c},\, z_{c},\, r\) | |
| Cylinder | \( x_{c,min},\, y_{c,min},\, z_{c,min},\ x_{c,max},\ y_{c,max},\, z_{c,max},\ r \) | |
| Tube | \( x_{c,min},\, y_{c,min},\, z_{c,min},\ x_{c,max},\ y_{c,max},\, z_{c,max},\ r_{outer},\, r_{inner} \) | |
| Cone | \( x_{tip},\, y_{tip},\, z_{tip},\, x_{c,base},\, y_{c,base},\, z_{c,base},\, \varphi,\, r\) | |
| Hat (hollow cone) | \( x_{tip},\, y_{tip},\, z_{tip},\, x_{c,base},\, y_{c,base},\, z_{c,base},\, \varphi,\, r,\, t \) | |
| Sliced cone (aligned) | \( x_{c,1},\, y_{c,1},\, z_{c,1},\, x_{c,2},\, y_{c,2},\, z_{c,2},\, r_1,\, r_2 \) | |
| Sliced cone (non-aligned) | \( x_{c,1},\, y_{c,1},\, z_{c,1},\, x_{c,2},\, y_{c,2},\, z_{c,2},\, r_1,\, r_2,\, n_{1,x},\, n_{1,y},\, n_{1,z},\, n_{2,x},\, n_{2,y},\, n_{2,z} \) | |
| Angled rectangular cuboid | \( x_{c,min},\, y_{c,min},\, z_{c,min},\, x_{c,max},\, y_{c,max},\, z_{c,max},\, h,\, w,\, \) | |
| Cartesian cylinder segment | \( x_{c,min},\, y_{c,min},\, z_{c,min},\, r,\, l,\, dir,\, \varphi_{min},\, \varphi_{max} \) |
Refinement patches can be combined arbitrarily by simply listing their corresponding tokens in localRfnLvlMethods. Multiple patches are grouped according to their refinement level. The individual groups for the particular levels are separated by a hyphen. The corresponding geometric parameters are simply listed consecutively in localRfnLevelProperties. The following example will refine one box-shaped region and one sphere-shaped region by one refinement level. An additional box-region nested in the first box is refined once more.
The boundary refinement allows the refinement of the interfaces between the fluid domain and embedded bodies or domain boundaries. The interface is automatically refined up to the level specified by maxBoundaryRfnLvl. The control of the thickness of the cell layers at the individual levels is done through the property localBndRfnMethod. Three options are available:
localBndRfnMethod | Description |
|---|---|
The thickness of the layer at the maxBoundaryRfnLevel is specified by the property localMinBoundaryThreshold. The thickness all of intermediate layers is given by the property smoothDistance. Both properties are specified in number of cells at the maxUniformRefinementLevel. Thus, individual layers can not be thinner than a single cell at the maxUniformRefinementLevel | |
The thickness of the layer at the maxBoundaryRfnLevel is specified by the property localMinBoundaryThreshold and is specified in fractions of a cell at the maxUniformRefinementLevel. The thickness of all intermediate layers is given by the property smoothDistance and is specified in number of cells at the respective level. | |
The thickness of the layer at the maxBoundaryRfnLevel is specified by the property localBndRfnDistance and is given in non-dimensional length units. The thickness of all intermediate layers is given by the property smoothDistance and specified in number of cells at the respective level. |
During mesh generation so-called cut-off boundaries can be created. These are not defined by a geometry, instead the mesh is cropped according to specified parameters. The resulting boundaries are treated separately from the ghost cell approach that is applied to regular boundaries. Details on the numerical background of cut-off boundaries is given "here". To create a cut-off boundary the appropriate cut-off mode has to be chosen first be specifying the cutOff-property. The available options are given in the table below.
cutOff | Description |
|---|---|
| No cut-off is applied. | |
Cut-off is applied at the minLevel. | |
Cut-off is applied at all levels <= minLevel. | |
Cut-off is applied at all levels >= minLevel. | |
| Cut-off is applied at all levels. |
The geometric shape at which the cut-off is applied can be specified by the property cutOffMethod. The corresponding geometric limits are then given by the property cutOffCoordinates. Additionally, a number of cell layers that protrude these limits can be specified by the property 'cutOffNmbrLayers' depending on the chosen cutOffMethod. The available options for these properties are summarized in the following table.
| Shape | cutOffMethod | cutOffCoordinates | cutOffNmbrLayers |
|---|---|---|---|
| Plane cut-off | \( x,\, y,\, z,\, n_x,\, n_y,\, n_z \) | requires \( 1 \) value. | |
| Box cut-off | \( x_{min},\, y_{min},\, z_{min},\, x_{max},\, y_{max},\, z_{max} \) | requires \( 2\cdot nDim \) values. | |
| Inverse box cut-off | \( x_{min},\, y_{min},\, z_{min},\, x_{max},\, y_{max},\, z_{max} \) | requires \( 2\cdot nDim \) values. | |
| Cylinder segment on \(x\)-axis | \( y_c,\, z_c,\, \Delta\varphi,\, \varphi_c \) | requires 1 value. |
Multiple cut-off methods can be combined arbitrarily. The respective tokens in cutOffMethod are separated by a hyphen. The required numerical parameters in cutOffCoordinates and cutOffNmbrLayers are consecutevily listed separated by commas.
One might be tempted to not care much about the geometry files defining the outer domain boundaries when using cut-off boundaries. However, it is advisable not to use excessively large geometries even if the domain is trimmed down using a cut-off as the grid generator will fill the complete geometry with cells at the desired level before the cut-off is applied. Therefore, this practice can create a huge memory overhead that might exceed the limitations of the available hardware.
Before the generated mesh is written to the output directory the grid generator will check the mesh on suitability for use with the Lattice-Boltzmann solver. This check will detect cells that have more than one level jump to their edge- or space-diagonal neighbors. If any such cells are detected the grid generator will issue a warning and the user is advised to check the generated grid carefully and if necessery adjust the employed refinement strategy.
In the following some advanced concepts are presented that allow to fine-tune the grid generation concept. These concepts can help to improve the performance of the grid generation, the subsequent simulation and enable the full potential of m-AIA's multi-solver approach.
As we saw before the cell size is restricted to subdivisions of the base cube with the edge length \( L_0 \) and therefore bound to the bounding box defined by the provided geometry. Sometimes, however, it is desirable to adjust the cell size more precisely. For that purpose the reductionFactor-property is introduced, which can take values between \( 1 \) and \( 2 \). The reduction factor is multiplied to the base length \( L_0 \) and thereby alters the edge length of the base cube. The cell size of all higher level cells is affected accordingly.
To enable the full potential of m-AIA, namely the coupling of multiple solvers, it is possible to generate multi-solver grids by setting the property multiSolverGrid = true. The number of solvers is then given by the property noSolvers. Properties of the individual solvers \(X\) are then addressed by adding the suffix .X to the corresponding property name. If properties are defined for specific solvers it is necessary to also prvide a default value with the suffix .default that will be used by all other solvers without a specified value.
Embedded bodies can also be initialized from a level-set function later during the simulation. Nevertheless, these bodies have to be specified in the geometry file. To tell m-AIA to ignore the specified bodies during the mesh generation set the property GFieldInitFromSTL = true. The exact bodies from the geometry file can then be specified by their boundary condition by listing the according boundary condition IDs in the property bodyBndryCndIds.
Fundamentally, the partitioning of the grid takes place at the minLevel. If the grid contains a wide range of refinement levels it can be difficult to achieve a well-balanced partitioning. The introduction of the so-called partition level shift allows to locally partition the grid on a higher refinement level. The threshold at which a partition level shift is triggered can be specified by setting the properties partitonCellOffspringThreshold and partitionCellWorkloadThreshold.
Often, regions of mesh refinement are restricted to only small parts of the computational domain and refined cells, which are outside of the domain are deleted. In the course of the parallel grid generation this can lead to a high concentration of cells on only a few ranks. Enabling the dynamic load balancing algorithm allows the repartitioning of the computational domain during the refinement process. The dynamic load balancing can be activated by setting dynamicLoadBalancing = true.
1.9.5