Aither CFD

Dissociating Shock Tube

Fri, 15 Jun 2018 14:00:00 +0000

Problem Description

Version v0.9.0 of Aither added a finite rate reacting flow capability. To test this capability and to compare the effect of finite-rate chemistry to frozen chemistry and equilibrium chemistry, a test case for dissociating $O_2$ in a shock tube was added to the Aither testCases/dissociation directory. The simulation follows the description in Luke [1].

Initial Conditions

The shock tube is initialized with two separate flow states. The left side is initialized with a high temperature, high pressure, equilibrium mixture of $O_2$ and $O$ . Within this state there is already a significant amount of dissociation. The right state is intialized with a low temperature, low pressure, equilibrium mixture. This state has comparatively minimal dissociation. The flow states are shown below.

left: pressure=1e6 Pa, temperature=3000 K, mass fractions=[O2=0.9824, O=0.0176]
right: pressure=1e5 Pa, temperature=2000 K, mass fractions=[O2=0.9997, O=0.0003]

Chemistry Mechanisms

The shock tube simulation was run with three separate chemistry mechanisms for comparison. A frozen chemistry model, a finite-rate model, and an equilibrium model were used. Each of these models are present in Aither as of v0.9.0.

Frozen Chemistry

For the frozen chemistry simulation, no reactions were present. This is the default chemistry model for Aither. In can be explicitly selected by setting the chemistryModel to none or frozen in the input file as shown below.

chemistryModel: none

Finite-Rate Chemistry

The finite-rate reacting chemistry model can be selected by setting the chemistryModel to reacting in the input file. This simulation used a two species, two reaction chemistry mechanism (O2_2s2r) that comes with Aither. All chemistry mechanisms that come with Aither are installed to the ${AITHER_INSTALL_DIRECTORY}/chemistryMechanisms folder. This model and mechanism can be selected as shown below.

chemistryModel: reacting
chemistryMechanism: O2_2s2r

The chemistry mechanism is defined in Luke [1], but the rates have been converted to use $mol$ instead of $kmol$ . The two reactions used in the mechanism are shown below.

2 O2 <=> 2 O + O2
O2 + O <=> 3 O

Equilibrium Chemistry

Aither doesn’t contain an explicit equilibrium chemistry model, but equilibrium chemistry can be simulated by increasing the reaction rates. The setup for the equilibrium chemistry simulation is identical to the the setup for the finite-rate simulation as shown below.

chemistryModel: reacting
chemistryMechanism: O2_2s2r

The reaction rates are increased by three orders of magnitude by copying the ${AITHER_INSTALL_DIRECTORY}/chemistryMechanisms/O2_2s2r.mch file into the run directory and increasing the C parameter in the Arrhenius fit by three orders of magnitude. Aither will first look for the mechanism file in the run directory before checking the installation directory, so this altered mechanism takes precedence over the version that comes with Aither.

Results

The simulations were run in a time accurate manner using a time step of 2e-7 seconds for a total time of 2.4e-4 seconds. The plots below show the temperature and degree of dissociation in the shock tube at the end of the simulation. For this simple mechanism the degree of dissociation is just the mass fraction of $O$ present. The temperature plot clearly shows the effect of finite-rate chemistry in the region behind the shock. The plots also show that the finite-rate solution is bounded by the frozen and equilibrium solutions. These results from Aither show excellent agreement with those in Luke [1].

Temperature in shock tube for frozen, finite-rate, and equilibrium chemistry mechansims.

Degree of dissociation in shock tube for frozen, finite-rate, and equilibrium chemistry mechansims.

References

[1] Luke, E. A. “A Rule-Based Specification System for Computational Fluid Dynamics”. Ph. D. Thesis. 1999.

Reacting Flow

Mon, 21 May 2018 08:00:00 +0000

Finite Rate Chemistry in Aither

As of v0.9.0 Aither has a finite rate reacting flow capability. This post will detail how the chemistry source terms are calculated in Aither. The governing equations for multispecies reacting flow are given below.

$\frac{\partial}{\partial t}\int_V W\,dV\ + \int_{A} \left[ \frac{\partial F_i(W)}{\partial x_j} - \frac{\partial F_v(W)}{\partial x_j} \right]\,dA\ = \int_V S\,dV\$

In order to calculate the source term $S$ due to chemical reactions, some information about each species in the simulation is needed. In Aither the fluid database specifies the enthalpy of formation $h_f$ , molar mass $M$ , vibrational temperatures $T_v$ , and the linear component of internal energy $n$ . The fluid database also supplies reference properties for pressure $p_{ref}$ , temperature $T_{ref}$ , and entropy $s_{ref}$ . It is possible to add to Aither’s fluid database by specifying these properties for a new species. This information can be found in a variety of sources, including the NIST Chemistry WebBook.

Chemistry Source Terms

Reacting flow simulations differ from nonreacting simulations in that the species mass equations have a source term, $S_s$ . This source term is calculated via the law of mass action. In the equation below $\nu_{s,r}^{''}$ represents the stoichiometric coefficient on the product side of the reaction for species $s$ in reaction $r$ . Similarly, $\nu_{s,r}^{'}$ represents the stoichiometric coefficient on the reactant side of the reaction for species $s$ in reaction $r$ .

$S_s = M_s \sum_{r=1}^{NR} \left( \nu_{s,r}^{''} - \nu_{s,r}^{'} \right) \left[ k_{f,r} \prod_{i=1}^{NS} \left(\frac{\rho_i}{M_i} \right)^{\nu_{i,r}^{'}} - k_{b,r} \prod_{i=1}^{NS} \left(\frac{\rho_i}{M_i} \right)^{\nu_{i,r}^{''}} \right]$

The source term depends on the forward and backward reaction rates. These rates are functions of temparature only. In Aither the forward reaction rate $k_f$ is calculated using an Arrhenius curve fit. The backward reaction rate $k_b$ is calculated from thermodynamic properties using the equilibrium rate $k_e$ . The units of the forward rate are $\frac{1}{s} \left( \frac{mol}{m^3} \right)^{1 - \sum_{s=1}^{NS} \nu_s^{'}}$ and the units of the backward rate are $\frac{1}{s} \left( \frac{mol}{m^3} \right)^{1 - \sum_{s=1}^{NS} \nu_s^{''}}$ .

$k_{f,r} = C T^{\eta} e^{\frac{T_a}{T}} \qquad k_{b,r} = \frac{k_{f,r}}{k_{e,r}}$

Calculation of Equilibrium Rate

The equilibrium rate of the reaction is calculated via the minimization of the Gibbs free energy [1]. For a thermally perfect gas using the vibrational equilibrium model in Aither, the Gibbs free energy for a given species is shown below. In the equations below $NV$ represents the number of vibrational modes for a given species.

$G_s = H_s - T S_s = h_{f,s} + \int_0^T c_{p,s} \left( t \right) dt - T \int_0^T \frac{c_{p,s} \left( t \right)}{t} dt - T s_{0,s}$ $G_s = h_{f,s} + \int_0^T R_s \left( n + 1 + \sum_{v=1}^{NV} \left[ \frac{T_{v,s}}{2 t \cdot sinh \left( \frac{T_{v,s}}{2t} \right)} \right] ^ 2 \right) dt - T \int_0^T \frac{R_s}{t} \left( n + 1 + \sum_{v=1}^{NV} \left[ \frac{T_{v,s}}{2 t \cdot sinh \left( \frac{T_{v,s}}{2t} \right)} \right] ^ 2 \right) dt - T s_{0,s}$ $G_s = h_{f,s} + R_s T \left( n + 1 \right) + R_s \sum_{v=1}^{NV} \frac{T_{v,s}}{e^{\frac{T_{v,s}}{T}} - 1} - R_s T \left( n + 1 \right) ln \left( T \right) - T R_s \int_0^T \sum_{v=1}^{NV} \left[ \frac{T_{v,s}}{2 t \cdot sinh \left( \frac{T_{v,s}}{2t} \right)} \right] ^ 2 dt - T s_{0,s}$

The remaining integral represents the vibrational contribution to the entropy term. It can be solved with integration by parts.

$\int_0^T \left[ \frac{T_v}{2 t \cdot sinh \left( \frac{T_v}{2t} \right)} \right] ^ 2 dt = \frac{1}{T} \frac{T_v}{e^{\frac{T_v}{T}} - 1} - \int_0^T \frac{T_v}{e^{\frac{T_v}{t}} - 1} \frac{-1}{t^2} dt = \frac{T_v}{T \cdot \left( e^{\frac{T_v}{T}} - 1 \right)} - ln \left( e^{\frac{T_v}{T}} - 1 \right) + \frac{T_v}{T}$ $\frac{T_v}{T \cdot \left( e^{\frac{T_v}{T}} - 1 \right)} - ln \left( e^{\frac{T_v}{T}} - 1 \right) + \frac{T_v}{T} = \frac{T_v}{T \cdot \left( e^{\frac{T_v}{T}} - 1 \right)} - ln \left( 1 - e^{\frac{-T_v}{T}} \right)$

Substituting this expression back into Gibbs free energy equation yields the following.

$G_s = h_{f,s} + R_s T \left( n + 1 \right) + R_s \sum_{v=1}^{NV} \frac{T_{v,s}}{e^{\frac{T_{v,s}}{T}} - 1} - R_s T \left( n + 1 \right) ln \left( T \right) - R_s \sum_{v=1}^{NV} \left[ \frac{T_{v,s}}{e^{\frac{T_{v,s}}{T}} - 1} - T ln \left( 1 - e^{\frac{-T_{v,s}}{T}} \right) \right] - T s_{0,s}$ $G_s = h_{f,s} + R_s T \left( n + 1 \right) \left[ 1 - ln \left( T \right) \right] - R_s T \sum_{v=1}^{NV} ln \left( 1 - e^{\frac{-T_{v,s}}{T}} \right) - T s_{0,s}$

Where $s_{0,s}$ is a constant to account for any difference between the given reference entropy of the species and the calculated entropy at the species’ reference temperature.

$s_{0,s} = s_{ref,s} - R_s \left( n + 1 \right) ln \left( T_{ref} \right) - \sum_{v=1}^{NV} \frac{T_{v,s}}{T_{ref} \cdot \left( e^{\frac{T_{v,s}}{T_{ref}}} - 1 \right)} - ln \left( 1 - e^{\frac{-T_{v,s}}{T_{ref}}} \right)$

From this the equilibrium rate can be calculated as shown below.

$k_{e,r} = \left( \frac{p_{ref}}{\tilde{R} T} \right) ^{\sum_{s=1}^{NS} \nu_{s,r}^{''} - \nu_{s,r}^{'}} e^{-\sum_{s=1}^{NS} \frac{G_s}{R_s T} \left( \nu_{s,r}^{''} - \nu_{s,r}^{'} \right)}$

Implicit Treatment

For the implicit solvers in Aither the chemistry jacobian and/or spectral radius of the jacobian are needed. The analytical chemistry jacobian is very complicated and somewhat expensive to calculate. For this reason Aither uses a numerical jacobian. The derivative of the chemistry source terms is needed with respect to $\rho_s$ and $\rho E$ . This is done by perturbing the conserved variable of interest by a small amount $\epsilon$ , while keeping the other conserved variables constant, and recalucuating the chemistry source terms.

$\frac{\partial S}{\partial \rho_s} = \frac{S\left( \rho_s + \epsilon \right) - S \left( \rho_s \right)}{\epsilon}$

For the scalar matrix implicit solvers in Aither (LU-SGS and DPLUR) only the spectral radius of the chemistry jacobian is needed. This is approximated using the procedure in [2] where only the negative terms that would increase the diagonal dominance of the implicit matrix are treated implicitly.

$\lambda_{chem} = min \left( \frac{S_s^{-}}{Y_s} \right)$ $S_s^{-} = M_s \sum_{r=1}^{NR} \left( \nu_{s,r}^{''} - \nu_{s,r}^{'} \right) \left[ - k_{b,r} \prod_{i=1}^{NS} \left(\frac{\rho_i}{M_i} \right)^{\nu_{i,r}^{''}} \right]$

References

[1] Luke, E. A. “A Rule-Based Specification System for Computational Fluid Dynamics”. Ph. D. Thesis. 1999.

[2] Savard, B. et al. “A Computationally-Efficient Semi-Implicit Iterative Method for the Time Integration of Reacting Flows with Stiff Chemistry”. Journal of Computational Physics. 2015.

Nonreflecting Outlet Boundary Condition

Sun, 27 Aug 2017 11:00:00 +0000

Subsonic Outflow

At a subsonic outflow there are four characteristics leaving the domain and one characteristic entering the domain. This means that the flow state on the boundary can be calculated from the interior cell’s state for four of the five primative variables. Typically density and the three components of velocity are calculated from the interior cell’s state. This leaves pressure to specified using other information supplied by the user. This user supplied data is used with the incoming characteristic to determine the pressure on the boundary. The incoming 1D characteristic equation, with characteristic variable $w$ is shown below.

$\frac{\partial w}{\partial t} = \frac{\partial u}{\partial t} - \frac{1}{\rho c} \frac{\partial p}{\partial t}$

Standard Pressure Outlet

With a standard pressure outlet, the implementation in most codes to to set the boundary pressure to a user defined value (shown below). This means that in the above characteristic equation $\frac{\partial p}{\partial t} = 0$ which shows that there is a reflection of intensity $\frac{\partial u}{\partial t}$ . This reflection can delay convergence as well as corrupt simulations where acoustic pressure fluctuations are important. Some such simulations would be aeroacoustic simulations and/or large eddy simulations.

$p_b = p_{ref}$

Nonreflecting Outlet

For a truly nonreflecting outlet $\frac{\partial w}{\partial t} = 0$ . However using this boundary condition can cause difficulty with setting the pressure on the boundary. When this boundary condition is used, the boundary pressure tends to float [1]. For this reason a relaxation coefficient $\kappa$ is typically used. Rudy and Strikwerda [2] suggested $\kappa$ in the form shown below where $M_{max}$ is the maximum Mach number on the boundary. The boundary condition proposed by Rudy and Strikwerda uses the locally one-dimensional inviscid (LODI) assumption. Many researchers have extended this approach to account for multi-dimensional flow at the outlet boundary by including the effect of transverse terms, $T$ [3]. The nonreflecting boundary condition is shown below where superscripts represent the time level of the variables.

$p_{b}^{n+1} = \frac{ p^n + \rho^n c^n \left( \overrightarrow{v}^{n+1} - \overrightarrow{v}^{n} \right) \cdot \overrightarrow{n} + \Delta t \kappa p_{ref} - \Delta t \beta T} {1 + \Delta t \kappa}$ $\kappa = \frac{\sigma c^n \left( 1 - M_{max}^{2} \right)}{l}$

The transverse terms are shown below. Here the subscript $t$ represents the transverse direction, and the subscript $n$ represents the boundary normal direction. For the $\beta$ calculation, the Mach number used is the average Mach number on the boundary.

$\beta = M_{avg}$ $T = -0.5 \left[ \overrightarrow{v}_{t}^{n} \cdot \left( \overrightarrow{\nabla}_{t} p^n - \rho^n c^2 \overrightarrow{\nabla}_{t} \overrightarrow{v}_{n}^{n} \right) + \gamma p^n \overrightarrow{\nabla}_{t} \cdot \overrightarrow{v}_{t}^{n} \right]$

Convecting Lamb-Oseen Vortex

A common test case for nonreflecting boundary conditions is a vortex convecting through an outlet boundary [1]. Ideally the vortex leaves the domain and there are no pressure waves reflected back into the domain. With a standard pressure outlet implementation, this will not be the case. Nonreflecting boundary conditions can significantly reduce the reflections at the boundary.

A test case was added to Aither for a convecting vortex corresponding to Case C in [1]. This simulation involves $N_2$ with a nominal pressure of 101300 Pascals and temperature of 288 Kelvin. The freestream flow is 100 meters per second with a Lamb-Oseen vortex with strength of 0.11 $\frac{m^2}{s}$ centered at the middle of the domain superimposed on the freestream flow. The radius of the vortex is one tenth the length of the domain. Results for the standard outlet and nonreflecting outlet are shown below in terms of the nondimensional pressure $p^{*}$ . Note that the $p^{*}$ used in the plot is the opposite that used in [1]. This is because it is more intuitive that the vortex core be shown as having low pressure.

$p^{*} = \left(p - p_{ref} \right) \frac{2 R^2}{\rho \Gamma^2}$

Comparison of standard pressure outlet with nonreflecting pressure outlet.

References

[1] Granet, Victor, et al. “Comparison of Nonreflecting Outlet Boundary Conditions for Compressible Solvers on Unstructured Grids”. 2010.

[2] Rudy, David and Strikwerda, John. “A Nonreflecting Outflow Boundary Condition for Subsonic Navier-Stokes Calculations”. Journal of Computational Physics. Vol 36, pp 55-70. 1980.

[3] Yoo, C. S. and Im, H. G. “Characteristic Boundary Conditions for Simulations of Compressible Reacting Flows with Multi-Dimensional, Viscous, and Reaction Effects”. June 29, 2006.

Version 0.7.0 Released

Tue, 13 Jun 2017 22:00:00 +0000

Release Notes

The 0.7.0 release of Aither is available on Github. This release adds a thermally perfect gas model, the ability to assign initial conditions from a cloud of points, and the AUSMPW+ inviscid flux scheme. These options can be invoked in the input file as shown below.

thermodynamicModel: thermallyPerfect
initialConditions: <icState(tag=-1; file=cloudOfPoints.dat)>
inviscidFlux: ausm

Features Added

Thermally perfect gas model
Ability to assign initial conditions from file
AUSMPW+ inviscid flux
Test cases
- Thermally perfect supersonic flow over ramp
- Uniform flow testing interblock orientations

Thermally Perfect Thermodynamic Model

Sat, 20 May 2017 17:00:00 +0000

Calorically Perfect Gas

The default thermodynamic model in Aither is the calorically perfect gas model. Calorically perfect gases have constant specific heats $\left( c_p, c_v \right)$ , and therefore a constant $\gamma$ . In general the calorically perfect gas model is a good assumption for air at lower temperatures. The molecules of a calorically perfect gas are assumed to be rigid so there is no vibrational component of internal energy. The equations below show the implementation of the calorically perfect gas thermodynamic model in Aither.

$e = e_{translational} + e_{rotational} + e_{vibrational} = c_v T$ $e_{translational} = \left( n - 1 \right) R T \,\,\,\,\,\,\, e_{rotational} = R T \,\,\,\,\,\,\, e_{vibrational} = 0$ $h = c_p T$ $c_v = n R \,\,\,\,\,\,\, c_p = \left( n + 1 \right) R \,\,\,\,\,\,\, \gamma = \frac{c_p}{c_v} = \frac{1}{n} + 1$

Thermally Perfect Gas

As the temperature of a gas increases the vibrational modes of its molecules are activated [1,2]. This means that some of the energy of the gas will move into these vibrational modes instead of raising the temperature of the gas. Therefore at higher temperatures where the vibrational modes are activated a thermally perfect gas will have a cooler temperature than a calorically perfect gas. The temperature at which the vibrational modes become significant is determined by the vibrational temperature $T_v$ of the gas. As the temperature of the gas approaches this value the vibrational component of internal energy becomes more and more significant.

The activiation of vibrational modes also means the the specific heats are no longer constant. Instead they are assumed to be functions of temperature only. The equations below show the implementation of the thermally perfect thermodynamic model in Aither.

$e = e_{translational} + e_{rotational} + e_{vibrational} = \int_0^T c_v \left( t \right) dt \,\,\,\,\,\,\, e_{vibrational} = \frac{R T_v}{e^{\frac{T_v}{T}} - 1}$ $h = \int_0^T c_p \left( t \right) dt$ $c_v = \frac{\partial e}{\partial t} = R \left( n + \left[ \frac{\theta_v}{sinh \left( \theta_v \right)} \right] ^ 2 \right) \,\,\,\,\,\,\, c_p = \frac{\partial h}{\partial t} = R \left( n + 1 + \left[ \frac{\theta_v}{sinh \left( \theta_v \right)} \right] ^ 2 \right) \,\,\,\,\,\,\, \theta_v = \frac{T_v}{2 T}$ $\gamma = \frac{c_p \left( t \right)}{c_v \left( t \right)}$

In Aither the thermally perfect thermodynamic model can be activated as shown below.

fluids: <fluid(name=air; n=2.5; molarMass=0.02897; vibrationalTemperature=3056)>
thermodynamicModel: thermallyPerfect

Example Problem

An example problem of when the thermally perfect model is needed is now a part of the test cases that come with the Aither repository. It is currently only available on the develop branch, but will be available on master after the next release. The test case involves hot supersonic flow over a 20 degree ramp. The freestream conditions of the flow are Mach 3, static temperature of 2000 K, and static pressure of 229,600 Pa.

Comparison of calorically perfect and thermally perfect thermodynamic models.

The results show that behind the shocks the thermally perfect gas model predicts a cooler flow than the calorically perfect gas model. This is expected as with the thermally perfect model some of the energy goes into the vibrational modes of the gas molecules.

References

[1] Lampe, Dietrich Rudolf. “Thermally Perfect, Calorically Imperfect Taylor-Maccoll Flow”. 1994.

[2] Anderson, John. “Hypersonic and High Temperature Gas Dynamics”. 2nd Edition. AIAA. 2006.

Version 0.6.0 Released

Mon, 01 May 2017 20:00:00 +0000

Release Notes

The 0.6.0 release of Aither is available on Github. This release adds periodic boundary conditions and wall functions for turbulent flow. Wall variables can now be output to Plot3D meta files as well. Additional test cases have been added for Couette flow and wall functions. The wall functions are available for the k- $\omega$ Wilcox, SST, SST-DES, and WALE turbulence models. The wall functions are implemented in the way described by Nichols & Nelson [1]. If the first cell off the wall is in the log layer, the wall shear stress is prescribed by the wall of the law.

$u^+ = \frac{1}{\kappa} ln \left( y^+ \right) + B$

If the first cell off the wall results in a $y^+$ less than 10, the boundary condition automatically switches back to the low Reynolds number formulation.

Wall variable output can be requested by assigning a list of variables to the wallOutputVariables input. Wall functions can be turned on by setting the wallTreatment option for a viscousWall to wallLaw as shown below.

wallOutputVariables: <yplus, heatFlux, shearStress, frictionVelocity>
boundaryStates: <viscousWall(tag=1; wallTreatment=wallLaw)>

Features Added

Periodic boundary conditions
Wall functions for turbulent flow
Wall variables output
Test cases
- Couette flow
- Flat plate wall functions

References

[1] Nichols, R. H. & Nelson, C. C. “Wall Function Boundary Conditions Including Heat Transfer and Compressibility”. AIAA Journal, Vol 42, No 6, June 2004.

Couette Flow & New Boundary Conditions

Sat, 04 Mar 2017 17:00:00 +0000

Couette Flow

Couette flow is viscous laminar flow between two parallel plates, one of which is moving relative to the other. Due to its simple nature and the existance of an analytical solution, it is a common validation case for CFD codes. An example validation case is shown in Hirsch [1]. Couette flow results in a constant shear stress which has a linear velocity profile and a parabolic temperature profile as shown below.

$v(y) = \frac{y}{L} v_{wall}$ $P_r E_c = \frac{\mu v^2_{wall}}{k \Delta T}$ $T(y) = T_{low} + \Delta T \frac{y}{L} \left[1 + \frac{1}{2} P_r E_c \left(1 - \frac{y}{L} \right) \right]$

Three of the newer features in Aither are periodic boundary conditions, moving walls, and isothermal walls. A couette flow simulation can make use of all of these features, so it makes a great addition to the test cases suite.

Problem Setup

The parallel plates are placed a distance of 0.001 meters apart. The bottom plate is held at a temperature of 288 K and is stationary. The top plate is held at a temperature of 289 K and is moving at 75.4 m/s. For this setup, the product of the Prandtl and Eckert numbers is 4. This means that for the temperature profile, the maximum temperature will not be at the plate, but in the flow instead. The exact solution dictates that the maximum temperature should be three fourths of the way between the cold and hot plates.

The CFD domain is a rectangular prism with the top and bottom modeled as viscous walls, the sides as slip walls, and the front / back as periodic. Isothermal walls can be specified in Aither by adding the temperature parameter to the boundary state list. Similarly moving walls can be specified by adding the velocity parameter. Periodic boundary conditions are specified by indicating which boundary condition tags should be paired as periodic. This is done through the startTag and endTag parameters. For each periodic boundary condition a transformation must be done to get from one periodic face to the other. Currently a translation can be specified by adding the translation parameter which is a vector specifying how the boundary at the startTag should be translated to get to the boundary at the endTag. Alternatively a rotation can be specified by using the axis, point, and rotation parameters. The axis parameter is a vector defining the axis of rotation. The point parameter is a vector defining a point about which to rotate. The rotation parameter is a scalar defining the rotation angle in radians. An example of these new boundary condition options is shown below.

boundaryStates: <periodic(startTag=4; endTag=5; translation=[0.01, 0, 0]),
                 viscousWall(tag=1; temperature=288),
		 viscousWall(tag=2; temperature=289; velocity=[75.4, 0, 0])>

Results and Summary

The results from Aither show a linear velocity profile and a parabolic temperature profile as expected. The results agree very well with the exact solution. These results can be reproduced by running the Aither code. The grid and input file for the couette flow case can be found in the testCases directory of the repository.

Velocity and temperature profiles for Couette flow.

References

[1] Hirsch, Charles. “Numerical Computation of Internal and External Flows”. 2nd Edition. Butterworth-Heinemann. 2006.

Sod's Shock Tube

Sun, 29 Jan 2017 17:00:00 +0000

Sod’s Shock Tube

Sod’s shock tube [1] is a 1D canonical problem used to test the accuracy of CFD codes. The problem consists of a fluid in a tube divided by a diaphragm. The fluid on the left side of the diaphragm is at a high pressure, and the fluid on the right side of the diaphragm is at a lower pressure. At time t = 0, the diaphragm is punctured and the fluid is allowed to mix. This results in a right moving shock wave and contact discontinuity, and a left moving expansion wave. Numerically this can be simulated by solving the Euler equations. The exact solution can be determined analytically and used to compare to the CFD simulation result. Anderson’s book [2] describes the process for computing the analytical solution.

Typically the flow variables are normalized by the high pressure state, so that the initial conditions of the simulation are as shown.

$Q_l = \left[ \begin{array}{c} \rho_l \\ v_{x_l} \\ v_{y_l} \\ v_{z_l} \\ P_l \\ \end{array} \right] = \left[ \begin{array}{c} 1.0 \\ 0.0 \\ 0.0 \\ 0.0 \\ 1.0 \\ \end{array} \right] ; Q_r = \left[ \begin{array}{c} \rho_r \\ v_{x_r} \\ v_{y_r} \\ v_{z_r} \\ P_r \\ \end{array} \right] = \left[ \begin{array}{c} 0.125 \\ 0.0 \\ 0.0 \\ 0.0 \\ 0.1 \\ \end{array} \right]$

Reconstruction Schemes

In the cell-centered finite volume method, the volume averaged flow variables are stored at the centroid of the cell. To calculate the fluxes at the cell faces, the flow variables are needed at the cell faces. The solution therefore must be reconstructed from the cell centroids to the cell faces. How this is done can greatly effect the accuracy of the simulation. The Sod’s shock tube problem was run using three of the reconstruction methods available in Aither: constant, thirdOrder (MUSCL), and weno.

Constant Reconstruction

Constant reconstruction is a zeroth order reconstruction that results in a first order accurate simulation. In this method the flow variables at the cell face are set equal to the flow variables at the adjacent cell center. While very robust, this method is quite dissipative. It typically results in a solution that is not accurate enough for engineering purposes, as important flow features such as shocks are smeared.

MUSCL Reconstruction

MUSCL schemes were originally developed by van Leer. The stencil for this family of schemes uses the flow variables at two cell centers upwind, and one downwind of the cell face. The MUSCL schemes vary the weights of the flow variables in the stencil via a parameter $\kappa$ . For most values of $\kappa$ the scheme results in a piecewise linear reconstruction which in turn results in a second order accurate simulation. However, when $\kappa$ is set equal to one third, the scheme results in a piecewise parabolic reconstruction that is third order accurate. However, due to the assumption that the flux is constant over the cell face, the simulation is still second order accurate. The solution error for a simulation with $\kappa$ equal to a third will typically be lower than for other values of $\kappa$ .

The MUSCL scheme by itself as with all higer order accurate schemes suffers from spurious oscillations around discontinuities. In practice the reconstruction is limited through the use of a slope limiter. This means that near discontinuities the order of accuracy of the reconstruction is dropped to avoid the spurious oscillations.

WENO Reconstruction

Weighted essentially non-oscillatory (WENO) schemes [3] were originally developed by Shu. The stencil for this family of schemes uses the flow variables at three cell centers upwind, and two downwind of the cell face. The WENO scheme uses the piecewise parabolic reconstruction of the MUSCL scheme with $\kappa$ equal to one third over three candidate substencils. The first of the three substencils consists of the three upwind cells. The second consists of two upwind cells and one downwind cell. The third substencil consists of one upwind cell and two downwind cells. These three substencils are then weighted and combined to produce a fifth order accurate reconstruction in smooth regions of the flow. In areas near discontinuties, the substencils containing discontinuities are weighted to not contribute to the reconstruction which drops the order of accuracy. Even though the reconstruction can be fifth order accurate, the simulation will still be limited to second order accuracy due to the assumption of a constant flux on the cell face.

Results

The results at nondimensionalized time t = 0.1 are shown below. Near the discontinuities, the excessive dissipation of the constant reconstruction can be seen. As expected, the MUSCL and WENO schemes do much better.

Shock tube results for constant, MUSCL, and WENO reconstructions.

It is tough to tell the difference between the MUSCL and WENO results, so a zoomed in view of the normalized density is shown below. In the picture below is can be seen that the WENO scheme does slightly better in that it is a bit sharper near the discontinuities. This is due to its higher order accuracy in the reconstruction.

Detail view of density showing expansion, contact, and shock waves.

Summary

The WENO scheme provides the most accurate simulation of Sod’s shock tube problem. The constant reconstruction method provides the most dissipative solution. These results can be reproduced by running the Aither code. The grid and input file for the shock tube case can be found in the testCases directory of the repository. The python script used to compare the results to the exact simulation can be found here.

References

[1] Sod, G. A. “A Survey of Several Finite Difference Methods for Systems of Nonlinear Hyperbolic Conservation Laws”, Journal of Computational Physics, Vol 27, pp 1-31. 1978.

[2] Anderson, J. “Modern Compressible Flow with Historical Perspective”. McGraw-Hill Education, 2002.

[3] Shu, C. “Essentially Non-Oscillatory and Weighted Essentially Non-Oscillatory Schemes for Hyperbolic Conservation Laws”. NASA CR-97-206253. ICASE Report No. 97-65. 1997.

New Input File Syntax: Vectors, States, & Lists

Mon, 26 Dec 2016 02:00:00 +0000

New Input File Syntax

There is a new input file syntax for Aither now in use in the develop branch of the code. This syntax makes it easy to specify initial conditions by grid block, and boundary conditions by boundary condtion tag. This is a huge upgrade in usability as it now allows for problems such as Sod’s shock tube to be simulated. It also allows for easy implementation of various viscousWall boundary conditions such as adiabatic, isothermal, and constant heat flux. The new input file syntax is based off of three new objects (vectors, lists, & states) which will be discussed in detail below.

Vectors

Vectors are now input in a comma separated list enclosed in brackets like below. Vectors must be defined entirely on one line in the input file.

velocityRef: [1.0, 0.0, 0.0]

Valid vector inputs have three components. If three components are not specified, Aither will throw and error. Vector inputs are now used wherever vector quantities are needed such as for velocity (above), or specifiying a direction as is done with the stagnationInlet boundary condition.

States

States are a group of properties that apply to an initial condition state or a boundary condtion state. States are identified by name, enclosed in parenthesis, and individual properties within a state are assigned with the equals operator and separated by semicolons. States must be defined entirely on one line in the input file. Below is an example of icState which is used to specify a flow state for initial condtions.

icState(tag=0; pressure=101325; density=1.225; velocity=[100, 0, 0])

The supported properties depend on the type of state. There are optional turbulence properities tubulenceIntensity and eddyViscosityRatio that may be specified for states used for inflow boundary conditions or icState. If either of the optional turbulence properties are specified, both must be specified. For icState the tag property is special. It refers to the block number in which the icState will be applied. A value of -1 functions as the default state in the event that there is not an icState with a tag pointing to a given block. An explicity specified tag takes precedence over the default state. For example for a four block grid with two icStates defined, one with a tag of -1, and another with a tag of 0, blocks 1-3 will use the default icState with tag -1, and block 0 will use the icState with the tag of 0.

In addition to initial conditions, states are used for boundary conditions that may require additional information. An example of each such boundary condition is shown below. For boundary conditions, the tag property in each state refers to the boundary surface tag that is specified in the boundary condition definition.

Inflow boundary conditions. These may optionally specify the turbulence properties.

characteristic(tag=0; pressure=101325; density=1.225; velocity=[100, 0, 0])

stagnationInlet(tag=0; p0=101325; t0=300; direction=[1, 0, 0])

supersonicInflow(tag=0; pressure=101325; density=1.225; velocity=[100, 0, 0])

subsonicInflow(tag=0; density=1.225; velocity=[100, 0, 0])

Outflow boundary conditions.

pressureOutlet(tag=0; pressure=101325)

subsonicOutflow(tag=0; pressure=101325)

Wall boundary condtions. One of heatFlux or temperature may be specified. The default behavior is zero velocity and zero heat flux which corresponds to a stationary adiabatic wall.

viscousWall(tag=0; heatFlux=100)

viscousWall(tag=0; temperature=400)

viscousWall(tag=0; velocity=[10, 0, 0])

Lists

Lists are a comma separated group of properties that are enclosed in angle brackets. Lists may be specified across multiple lines. Lists are most commonly used to specify the variables to output, the initial condition states, and the boundary condition states. Examples are shown below.

outputVariables: <density, vel_x, vel_y, vel_z, pressure, temperature, mach>

initialConditions: <icState(tag=0; pressure=101325; density=1.225; velocity=[0, 0, 0]),
                    icState(tag=1; pressure=10132.5; density=0.153125; velocity=[0, 0, 0])>

boundaryStates: <characteristic(tag=0; pressure=101325; density=1.225; velocity=[100, 0, 0]),
                 viscousWall(tag=1; velocity=[10, 0, 0])>

Summary

The new input syntax in Aither is more intuitive and now allows for a wider variety of problems to easily be simulated. All of the test cases in the develop branch have been updated to support this new syntax. Grab the develop branch from Github and try it out today. This will be merging into the master branch shortly.

Using Travis CI For Regression Tests

Sat, 03 Dec 2016 12:00:00 +0000

Why Use A Continuous Integration Service?

Continuous integration services allow code updates to be built and tested on a variety of platforms. This saves the developer a lot of time by not having to manually test the code. As Aither grows larger it becomes more and more beneficial to use a continuous integration service. For example, say a more efficient way to calculate the inviscid flux was found, and a new branch was created to refactor the invisicid flux code to use this new method. This change should result in the same solution, but should take less time to complete. To be thorough, before merging the code back into the develop branch, unit tests covering all of the code’s various functionality should be completed. These tests should still show that the solution is the same as it was prior to the refactor. It can be tedious and time consuming to manually run these tests, not to mention the tests should be run on different operating systems, and with different compilers as well. This is where continuous integration saves the day! A continuous integration service will automatically build the most updated code on a variety of operating systems with a variety of compilers, and can be made to run regression tests. This way it can easily be determined if the refactor introduced any bugs.

Aither’s Requirements For Continuous Integration

Ok, so it is clear that continuous integration is a good thing, but which service should be used? Ideally, a continuous integration service would provide the following:

Free (Aither is not a money making venture after all)
Testing on multiple operating systems (Aither is cross platform)
Testing with multiple compilers
Ability to use modern C++ (Aither uses C++14)
Support for required dependencies (Aither requires an MPI implementation and Cmake)
Ability to run regression tests in parallel
Easy to use within Github

After a brief survery of available options, Aither recently started using Travis CI for continuous integration. Travis CI meets all of the above requirements. It is free for open source projects, widely used in the Github community (i.e. SU2), and supports builds on Ubuntu and macOS.

Using Travis CI

Once an account has been created with Travis CI it is easy to integrate with Github. All that is required is to add a .travis.yml file to the repository. This file instructs Travis CI on how to build the code and run any regression tests. For Aither, a matrix of five builds is setup (Ubuntu/gcc-5, Ubuntu/gcc-6, Ubuntu/clang, macOS/gcc-6, macOS/clang). These builds are setup under the matrix data field of the .travis.yml file. An abbreviated build matrix is shown below; each of the builds is marked by the - os: line.

# set up build matrix
matrix:
  include:
    # build for Ubuntu/gcc-6
    - os: linux
      dist: trusty
      sudo: required
      compiler: gcc
      # add toolchains for newer, C++14 supporting gcc-6
      addons:
        apt:
          sources:
            - ubuntu-toolchain-r-test
          packages:
            - g++-6 gcc-6 libstdc++-6-dev
      # change default compiler to newer gcc-6
      env:
        - CXX_COMPILER=g++-6
        - C_COMPILER=gcc-6
    # build for macOS/clang
    - os: osx
      osx_image: xcode8
      compiler: clang
      # change defualt and homebrew compilers to clang
      env:
        - CXX_COMPILER=clang++
        - C_COMPILER=clang
        - HOMEBREW_CC=clang
        - HOMEBREW_CXX=clang++

Installing MPI

During the build matrix setup, environment variables for the C/C++ compilers are changed to reflect the newer C++14 supporting compiler to be used in the build. Travis CI only offers Ubuntu 14.04 as its newest linux offering. Since this version of the operating systems is a few years old, updated compilers are needed for the latest C++ standard. However, when the Ubuntu package manager is used, it installs binaries that were created with the system C/C++ compilers. For compatability purposes, it would be best if Aither used a version of MPI that was compiled with the same compiler that will be used to compile Aither itself. For this reason OpenMPI is compiled from source using the updated compilers.

For macOS, things are a little different. The macOS virtual machines from Travis CI come preinstalled with the homebrew package manager. With homebrew the HOMEBREW_CC and HOMEBREW_CXX environment variables control the compiler that new packages are built with. This means that installing MPI is easier because the package manager can do it automatically.

This means that the .travis.yml script has to tell Travis CI to install MPI in a different way depending on which operating system the build is happening on. This can easily be done with a simple bash script as shown below.

#!/bin/bash

# for macOS builds use OpenMPI from homebrew
if [ "$TRAVIS_OS_NAME" == "osx" ]; then
    cd openmpi
    # check to see if OpenMPI is cached from previous build
    if [ -f "bin/mpirun" ]; then
	echo "Using cached OpenMPI"
    else
        echo "Installing OpenMPI with homebrew"
	HOMEBREW_TEMP=$TRAVIS_BUILD_DIR/openmpi
        brew install open-mpi
    fi
else
    # for Ubuntu builds install OpenMPI from source
    # check to see if OpenMPI is cached from previous build
    if [ -f "openmpi/bin/mpirun" ] && [ -f "openmpi-2.0.1/config.log" ]; then
	echo "Using cached OpenMPI"
	echo "Configuring OpenMPI"
	cd openmpi-2.0.1
	./configure --prefix=$TRAVIS_BUILD_DIR/openmpi CC=$C_COMPILER CXX=$CXX_COMPILER &> openmpi.configure
    else
        # install OpenMPI from source
	echo "Downloading OpenMPI Source"
	wget https://www.open-mpi.org/software/ompi/v2.0/downloads/openmpi-2.0.1.tar.gz
	tar zxf openmpi-2.0.1.tar.gz
	echo "Configuring and building OpenMPI"
	cd openmpi-2.0.1
	./configure --prefix=$TRAVIS_BUILD_DIR/openmpi CC=$C_COMPILER CXX=$CXX_COMPILER &> openmpi.configure
	make -j4 &> openmpi.make
	make install &> openmpi.install
	cd ..
    fi
    # recommended by Travis CI documentation to unset these for MPI builds
    test -n $CC && unset CC
    test -n $CXX && unset CXX
fi

Caching Dependencies

Builds can be sped up on Travis CI by caching dependencies. Aither depends on MPI which can take a while to build from source. However, this really only needs to be done once if the MPI installation can be cached and retrieved from build to build. Fortunately, Travis CI allows this capability even for their free tier of services. To cache the MPI install directory is simple. Only the following few lines need to be added to the .travis.yml file. This caches the OpenMPI source code directory, as well as the installation directory.

cache:
  directories:
    - openmpi
    - openmpi-2.0.1

Regression Tests

Once the build completes Travis CI will run the Aither regression tests. The regression tests are located in the testCases directory of the repository. Travis CI will run each case for 100 iterations and compare the residuals to some “truth” values. If the residuals differ by less than a given ammount (1% for Aither), the test passes. The idea is that the regression tests cover most or all of the code’s functionality. On Ubuntu builds there are two processors available, so the tests are run in parallel. On macOS there is only one processor available, so the tests are run in serial. The Aither repository includes a python script to automate the running of these regression tests. After Travis CI builds the code, the script is invoked to run the tests.

Conclusion

Travis CI is now used by Aither to test builds on Ubuntu and macOS using gcc-5, gcc-6, and clang. Regression tests are run for all of Aither’s test cases to ensure that no existing functionality is broken with changes to the code. For more information on how the whole thing is set up, visit the repository and check out the .travis.yml and travis/installMPI files.