Description Mesh Block Connectivity in G3D::Flow

Standard Block Interface

interface between mesh blocks

Periodic Block Interface

periodic interfaces between mesh blocks

Mixing Plane

rotor stator interface

Sliding Grid

The Sliding Grid interface can be used to couple rotor-rotor or rotor-stator domains to perform transient turbomachinery simulations.

The following features are still under construction and are not yet available

1. Support for Harmonic Balance Solver
2. Completely arbitrary A and B side interface topologies (GGI functionality)
3. Calculation of diffusive fluxes over interface (only convective flux contribution)

Below, the functionality of the Sliding-Grid interface is explained in more detail.

Nomenclature

A Sliding Grid interface consists of two faces, one belonging to the upstream rotor/stator and one belonging to the downstream rotor/stator. As with turbomachinery calculations in general with G3D::Flow, it is assumed that the axis of rotation is the \(x\)-axis. The face belonging to the upstream rotor/stator is denoted the A-side and the face of the downstream rotor/stator is denoted the B-side. This distinction must be made for two reasons:

1. The code handles the A and the B side differently, the code essentially goes through all B-side faces to find intersections with a A-side face, not the other way around.
2. The orientation of the A and B side face is determined based on the assumption that the A side normal is in positive \(x\)-direction, and the B-side normal is in the negative \(x\)-direction. If this condition is not satisfied, the code will not be able to build up the internal memory structure needed to store the interface correctly.

A polygon is here referred to as a ordered set of n vertices, connected by n straight edges. All polygons referred hereafter are furthermore assumed to be convex. Ax example of a convex and non convex polygon are presented below.

It follows that any cell face in G3D::Flow, which works on structured hexahedral grids, is a 4 sided polygon according to the definition given above.

A node is referred to as the corner of a face, or cell, and can hence also be seen as the vertex of a polygon.

The pitch angle is the angle spanned by the rotor/stator domain, and is naturally given by \(2\pi/N_b\), where \(N_b\) is the number of blades in the rotor/stator row. It is denoted by \(\theta_s\).

If a block in the mesh has one side as part of the Sliding Grid interface, this face is referred to as a patch. If \(N\) blocks are part of the Sliding Grid interface, it must then follow that the interface is built up of \(N\) patches.

Interface Topology

The Sliding-Grid interface utilizes a complex polygon clipping algorithm to find the overlapping area between cell faces on the A and B side of the interface. It is through this common area that the code later will calculate the flux contribution to the A and B side cell. Since the polygon clipping algorithm does not depend on the shape of the polygons and how they are oriented towards each other, it is possible to handle fairly arbitrary mesh topologies. The currently supported topology for the Sliding Grid interface is outlined below

1. A and B side span the same pitch angle
2. Min and max radius of A and B side are the same
3. A and B side may be leaned differently in tangential direction, see figures below.
4. A and B side may be swept forward or backward, giving different axial coordinates at different radial locations. The sweep must however be the same for both sides.
5. Nodes must lie on constant radial spans on A and B side. The radial coordinates of the nodes on A and B side does however not have to match, see figures below.
6. The axial length of the first cell layers on both sides should be close to equal to ensure that the general criteria of modest grid stretching is satisfied across the interface.
7. The cells in the first cell layers on both sides should preferably be oriented in the same direction to improve numerics for calculating flux over interface.

An example of and A side, a B side and how the overlap are presented below

As can be seen, they both span the same pitch angel, have the same min and max radius, different lean in the tangential direction and different number of nodes in the radial direction. It can also be noted that the nodes still lie on constant radial spans, a restriction that will be removed in future implementations of a GGI interface.

The interface also allows the domains to be swept, as illustrated below

Finally, the patches that make up the interface on the A and B side may be completely arbitrarily distributed across the interface, and there is no requirement that the patch topology is equal on both sides as long as the resulting grid satisfies the aforementioned criteria. An valid patch topology is depicted below

Flux Calculations

The flux calculations across the interface are described in this section. The flux calculation is divided into three major steps

1. Perform flux calculations over cell faces on step in from interface
2. Find intersection between A and B side
3. Perform flux calculation through overlapping areas found in step 2.

Flux Calculations one Step in from Interface

The flux calculations require a four cell long stencil, with two cells on each side of face. Hence, for the cells situated on step in from the Sliding Grid Interface, the last or first cell in the stencil will lie outside the A and B side domains respectively. Preferably, a value for this cell can be found by finding the appropriate neighbor in the connecting domain. In the current implementation, interpolation across the Sliding Grid interface is however omitted, and zero-order extrapolation is used to set a value for this cell instead, as illustrated by the blue arrow in the picture below

After this, the flux calculations are performed in the same way as in the rest of the domain. Since the cells and nodes needed to calculate both diffusive and convective fluxes are available after the extrapolation, they are consequently both computed as well.

Finding Intersection between A and B side

The algorithm for finding overlapping areas for flux calculations is divided into several steps. Before the search can begin, the rotation of both A and B side must be determined, which is given by the rotational speed of the domain times the physical time that has passed in the simulation, i.e.

$$\Delta \theta_i = \Omega_i \cdot t$$

The value of dTheta is restricted to \((-2\pi, 2\pi)\) by adding or subtracting integer multiples of \(2\pi\) to the calculated value. This is done to ensure that later calculations based on this rotation angle does not give inaccurate results. After this, a loop through all cell faces on the A side of the interface is performed. For each cell face on the A side, the following steps are then performed to find intersecting cell faces on the B side

1. Rotate nodes spanning A side face according to \(d\theta\) around \(x\)-axis
2. Calculate min and max radius among all nodes that span A side face
3. Start loop through B side cell faces
4. For each B side cell face, do the following
1. Calculate min and max radius among all nodes that span the face
1. If these radii does not overlap the min and max radius of A side cell face, continue loop on next B side face
2. If radius overlap, continue loop
2. Calculate min and max theta among all nodes that span the face, taking rotation of domain into account
1. If these angles does not overlap the angle of the A side face, continue loop on next B side face
2. If angles overlap, continue loop
3. Call polygon intersection algorithm to find overlapping area between A and B side (description below).
1. If overlapping area found, save area and pointer to B side cell
2. If no overlap found, continue loop
5. End loop through B side cell faces

The polygon intersection algorithm is based on the paper "Reentrant Polygon Clipping" by Sutherland and Hodgman. It starts by taking the vertices of the A and B side faces and project the coordinates onto the r-theta plane. This is equivalent to representing the face only by its \(y\) and \(z\) coordinates. This step is done since the intersection of two polygons are easier to perform in 2D rather than 3D, and in the case of swept interfaces the \(x\)-coordinate of all vertices are not the same. The algorithm will then successively clip the A side polygon with each edge of the B side polygon, each step producing a smaller, or equally large, A side polygon. After it is finished, the resulting A side polygon represents the intersection between A and B side, since all other parts of the A side face have been cut away. The result is schematically depicted by the orange area below

The area of the intersecting polygon is saved, as indicated in the outline above, together with pointers to the B side cell.

Perform Flux Calculations over Interface

After the loop over all B side cell faces is completed for a specific A side face, the flux calculations can be performed. The flux is computed in the absolute frame of reference, and the resulting flux is then converted to the relative frame of reference of both A and B side domain before it is applied to the cells in question. The algorithm for calculating the flux is outlines below

1. Convert A side conservative and primitive variables to absolute frame of reference
2. Start loop through all B side cells that overlap A side cell
3. For each B side cell, do the following
1. Convert conservative and primitive variables to absolute frame of reference
2. Compute convective flux over the overlapping area, using the standard four cell stencil (description below).
3. Convert computed flux into relative frame of reference for both A and B side
4. Apply flux to A and B side cells in relative frame of reference
4. End loop through all B side cells

The conversion of variables and fluxes from a relative to an absolute frame of reference is relatively straightforward, and will not be discussed here. The flux calculation will however be described in greater detail.

The flux calculation uses the same four cell stencil for convective fluxes as the rest of the code does. The main simplification made is that this stencil also is valid when the two cells on each side of the interface are shifted relative to each other both in the radial and tangential direction. It can be argued that its more correct to first interpolate the B side variables in space to obtain ghost cells values which perfectly cover the A side face. This would however have two drawbacks. First, the flux calculation would have to be done twice, first for flux contributions to the A side cell using spatially interpolated B side values and then vice versa for flux contributions to the B side cell using interpolated A side values. Another drawback would be that he interface no longer would be conservative, since the fluxes through the A side and B side face are computed differently.

Using the A and B side cells, albeit shifted relative to each other, the standard flux routines in G3D::Flow may be used without any large modifications. To begin with, the code calculates the flux using the area of the A side face, together with the A side values and the shifted B side values. After this, the flux is simply scaled with the fraction

$$f_{Flux} = \frac{A_{I}}{A_{P}}$$

Here, \(A_I\) is the area of the overlap in the \(y-z\) plane and \(A_P\) is the area of the A side face after being projected onto the \(y-z\) plane. After this has been accomplished, the flux may be converted to each domain's relative frame of reference and applied to the cells in question. It should be noted that the diffusive flux across the interface are not yet included in the calculation. This would require gradient calculations across the interface to be performed, or alternatively extrapolation of values. This is an issue that still is being worked on.

Guidelines

Here, some general guidelines on using the Sliding Grid interface are presented.

---

Other documentation pages