loosely coupled method
TRANSCRIPT
-
8/2/2019 Loosely Coupled Method
1/18
Transonic wing flutter predictions by a loosely-coupled method
Xiang Zhao a, Yongfeng Zhu b,c, Sijun Zhang d,
a School of Engineering and Technology, Alabama A&M University, 4900 Meridian Street, Normal, AL 35762, USAb School of Aeronautic Science and Engineering, Beihang University, Beijing 100191, Chinac The First Aircraft Institute, Aviation Industry Corporation of China (AVIC), P.O. Box 72, Xian 710089, Chinad ESI CFD, Inc., 6767 Old Madison Pike, STE 600, Huntsville, AL 35806, USA
a r t i c l e i n f o
Article history:
Received 18 February 2010
Received in revised form 10 August 2011
Accepted 3 January 2012
Available online 13 January 2012
Keywords:
Aero-elasticity
Fluid-structural interactions
Computational Fluid Dynamics (CFD)
Computational Structural Dynamics (CSD)
Loosely-coupled method
Wing flutter
a b s t r a c t
This paper presents transonic wing flutter predictions by coupling Euler/NavierStokes equations and
structural modal equations. This coupling between Computational Fluid Dynamics (CFD) and Computa-
tional Structural Dynamics (CSD) is achieved through a Multi-Disciplinary Computing Environment
(MDICE), which allows several computer codes or modules to communicate in a highly efficient fashion.
The present approach offers the advantage of utilizing well-established single-disciplinary codes in a
multi-disciplinary framework. The flow solver is density-based for modeling compressible, turbulent
flow problems using structured and/or unstructured grids. A modal approach is employed for the struc-
tural response. Flutter predictions performed on an AGARD 445.6 wing at different Mach numbers are
presented and compared with experimental data.
2012 Elsevier Ltd. All rights reserved.
1. Introduction
The use of CFD within the aerospace industrys loads and
dynamics groups continues to increase as improvements in
computational power make coupled CFD/CSD simulations more
feasible from a practical standpoint. At the same time, flutter
certification is becoming an increasingly challenging task as engi-
neers have to understand and quantify the aeroelastic behaviors
of advanced aircraft designs in the transonic regime. This situation
has created a strong need for validation efforts and for the gener-
ation of know-how regarding various computational-aeroelasticity
simulation methodologies [1].
Broadly, there are three approaches in computational aeroelas-
ticity: fully coupled, loosely coupled and closely coupled analyses.
In the fully coupled model, the governing equations are reformu-
lated by combining fluid and structural equations of motion, which
are then solved and integrated in time simultaneously. While using
a fully coupled procedure, one must deal with fluid equations in an
Eulerian reference system and structural equations in a Lagrangian
system, This leads to the matrices being orders of magnitude stiffer
for structure systems as compared to fluid systems, thereby mak-
ing it virtually impossible to solve the equations using a monolithic
numerical scheme for large-scale problems. In the class of loosely
coupled methods, unlike the fully coupled analysis, the structural
equations are solved using two separate solvers. This can result
in two different computational grids, which are not likely to coin-
cide at the boundary. This requires an interfacing technique to be
developed to exchange information back and forth between the
two modules. The loosely coupled approach has only external
interaction between the fluid and structure modules; or the infor-
mation is exchanged at each physical time step interval without
occurring in pseudo-time or sub-iteration. The closely coupled
approach is similar to the loosely coupled one in most procedures.
Different solvers for fluid and structure models are exploited, but
coupled in a tighter fashion thereby making it better accuracy for
time-dependent problems. In this approach, the fluid and structure
equations are solved separately using different solvers but coupled
into one single module with exchange of information taking place
at the interface or the boundary via an interface module. The infor-
mation exchanged here is the surface loads, which are mapped
from CFD surface grid onto the structure dynamics grid; and the
displacement field, which are mapped from structure dynamics
grid onto CFD surface grid. The major drawback of the closely
coupled method is much lower efficiency compared to the loosely
coupled method, since the information exchange is made in each
sub-iteration within every physical time step.
Many engineers and companies have an interest in constructing
loosely-coupled simulation methods based on in-house or com-
mercially available tools [2], which may or may not be designed
to work together. There are obvious advantages to retain and lever-
age the expertise and functionality of the best-in-class tools, as
0045-7930/$ - see front matter 2012 Elsevier Ltd. All rights reserved.doi:10.1016/j.compfluid.2012.01.002
Corresponding author. Tel.: +1 256 713 4729; fax: +1 256 713 4799.
E-mail address: [email protected] (S.J. Zhang).
Computers & Fluids 58 (2012) 4562
Contents lists available at SciVerse ScienceDirect
Computers & Fluids
j o u r n a l h o m e p a g e : w w w . e l s e v i e r . c o m / l o c a t e / c o m p fl u i d
http://dx.doi.org/10.1016/j.compfluid.2012.01.002mailto:[email protected]://dx.doi.org/10.1016/j.compfluid.2012.01.002http://www.sciencedirect.com/science/journal/00457930http://www.elsevier.com/locate/compfluidhttp://www.elsevier.com/locate/compfluidhttp://www.sciencedirect.com/science/journal/00457930http://dx.doi.org/10.1016/j.compfluid.2012.01.002mailto:[email protected]://dx.doi.org/10.1016/j.compfluid.2012.01.002 -
8/2/2019 Loosely Coupled Method
2/18
opposed to developing monolithic applications. The key issue
initially was data transfer. Numerous toolkits, frameworks and
techniques have emerged to tackle that issue. For example, MDICE
[3] allows users to couple arbitrary applications by defining a pro-
tocol and library that enable each application to define objects rel-
evant to the problem at hand, and to define functions that can be
remotely-invoked; it further provides a script language and script
interpreter to specify and drive the simulation. But this problem
of data transfer can be considered solved, i.e., there are now many
techniques and tools for allowing process to communicate.
Going beyond the data communication issue, there are several
important numerical issues for applying the loosely coupled meth-
odology for aeroelastic simulations. One of these is the representa-
tion of the structure and the associated interpolation tactics that
are necessary to make sure that structural deflections are trans-
ferred to the fluid mesh in an energy-conserving way [4], at least
globally. We have largely diverted this question by requiring that
a structural mesh representing the outer skin of the structural
model be supplied, even in the case of modal analysis. Then conser-
vation and consistency can be obtained with a sufficient refined
pair of surface meshes. There is no requirement that the fluid
and solid-side surface meshes match; one may be unstructured
and the other structured.
Another key part of the solution technique is the application of
the structural boundary deformations to the fluid mesh. The flow
solver in CFD-FASTRAN uses a conservative density-based finite-
volume approach and incorporates grid-deformation terms into
the formulation. The mesh deformation utilizes a 3-D transfinite
interpolation procedure on the boundary displacements to deter-
mine internal displacements of the 3-D fluid mesh after the bound-
ary deformations are received from the structural solver. This
procedure is in fact an identical implementation of the transfinite
interpolation (TFI) method deployed in CFD-GEOM (the mesh gen-
erator of the CFD-FASTRAN software); this choice was important to
ensure that null deformations would not change a grid that had
been smoothed. Also it is a very robust method compared to mov-
ing the grid by a spring analogy.In this work the performance and issues associated with a
loosely-coupled CFD/CSD approach are explored for transonic flut-
ter predictions using a commercially available off-the-shelf CFD
tool, CFD-FASTRAN. The purpose of the investigation is to explore
the numerical and method-related uncertainties in simulations of
transonic flutter using CFD-FASTRAN, and also to validate (estab-
lish the limits and expected accuracy) the use of the tool for this
application area on a common benchmark case. Although the gen-
eral capabilities of this tool have been demonstrated previously for
prediction of limit-cycle oscillation and tail buffeting [5,6], these
prior works involved research versions of the software and in the
commercialization process we ended up doing some things a bit
differently. Most notably, the modal solver for the structure is no
longer a hand-written code but is instead taken from CFD-ACE+;also, the method of fluid/structure interpolation is different.
2. Fluid structural coupling methodology
Aeroelastic phenomenon is involved in interaction between
several physical and numerical disciplines. The physical disciplines
are the fluid dynamics of the flow field and the structure dynamics
of the flexible surfaces. The numerical disciplines are the computa-
tional fluid dynamics, the computational structural dynamics, the
grid deformation and the fluidstructure interface coupling. In this
study, the interface coupling between the fluid and structure is ap-
plied in a manner that ensures conservation of forces, moments,
and virtual work. In order to ensure synchronization of data trans-fer between the different modules, the multi-disciplinary modules
are integrated into MDICE. This gives us the flexibility in choosing
different methods for any particular system. For example, many
different fluid solvers are available to choose for specific applica-
tions regarding the related physics and affordable computing
times. Moreover, there are a wide range of options for structural
modules from in-house codes, public domain structural solvers to
commercial ones. MDICE enables the engineering analysis modules
to run concurrently and cooperatively on a distributed network of
computers to perform multi-disciplinary task. Next, the particular
sets of analysis modules used in the current investigation are
outlined.
2.1. Flow solver
The flow solver used for the current study is CFD-FASTRAN. It is
a density-based flow solver for modeling compressible, turbulent
flow problems using structured and/or unstructured grids. The
salient strength of FASTRAN lies in its high accuracy for simulating
hypersonic flows. With the recent enhancement of low Mach num-
ber preconditioning techniques, it has been extended to deal with
low speed flows [7]. The Reynolds-averaged NavierStokes equa-
tions are solved using an implicit finite-volume upwind scheme
with Roes flux-difference splitting (FDS), Van Leers flux vector
splitting (FVS) or Lius advection upstream splitting method
(AUSM) for spatial differencing. Temporal differencing is based
on RungeKutta scheme, point-implicit scheme or a fully implicit
scheme. Very recently, dual-time stepping algorithm was imple-
mented into FASTRAN for efficient computations of unsteady fluid
dynamics [8]. Turbulent flows can be simulated using different
models such as BaldwinLomax, ke, kx, Menters SST kx, Spal-artAllmaras and DES/DDES models. CFD-FASTRAN is instru-
mented with the famous overset Chimera methodology and
6DOF analysis [9,10], the unsteady fluid flows involving multiple
moving bodies are resolved efficiently and accurately. Fluid struc-
tural interaction (FSI) for aero-elastic applications is achieved by
FASTRAN in a loosely coupled fashion [11]. The thermal and chem-
ical non-equilibrium models are implemented to allow the finiterate chemical reactions and consider vibrational/electron energy
for hypersonic ionizing air flows [12].
The system of integral conservation equations for mass,
momentum and energy is expressed in vector notation for an arbi-
trary control volume dV shown in Fig. 1 with differential surface
area dA as follows:
@
@t
Zcv
QdV
Ics
~FQ ~GQ ~ndA
Zcv
SQdV 1
Fig. 1. Typical arbitrary control volume (cell).
46 X. Zhao et al./ Computers & Fluids 58 (2012) 4562
http://www.elsevier.com/locate/compfluidhttp://www.elsevier.com/locate/compfluidhttp://www.elsevier.com/locate/compfluid -
8/2/2019 Loosely Coupled Method
3/18
The conserved variable vector Q is
Q q qu qv qw qe T 2
The inviscid flux vector ~FQ is
~FQ qU quU p~i qvU p~j qwU p~k qeU pUh iT
qU quU p~i qvU p~j qwU p~k qhU
h iT
3
The viscous flux vector ~GQ is
~GQ 0 ~sx ~sy ~sz ~s U~q T 4
where
~sx sxx~i sxy~j sxz~k 5
~sy sxy~i syy~j syz~k 6
~sz sxz~i syz~j szz~k 7
~s U
sxxu sxyv sxzw~i
sxyu syyv syzw~j
sxzu syzv szzw~k
8
~q K@T
@x~i
@T
@y~j
@T
@zk
9
In above equations,q is the density, u, v and w are the Cartesianvelocity components in x, y and z directions, respectively, p is the
static pressure, e is total energy per unit mass, and h is total enthal-
py per unit mass. S(Q) is the source vector, Uis the velocity vector,
s is the surface stress tensor, q is the heat flux, Kis heat conductiv-ity. The over arrow denotes the vector, i, j and k are the unit vector
in x, y and z directions, respectively.
The shear stress components can be written as
sxx 2l@u
@x
2
3lr U 10
sxy syx l@v
@x@u
@y
11
sxz szx l@w
@x@u
@z
12
syy 2l@v
@y
2
3lr U 13
syz szy l@w
@y@v
@z 14
szz 2l@w
@w
2
3lr U 15
However, Eq. (1) does not reflect moving boundaries or grids.
Using Leibnizs Theorem, a generic governing equation may be ex-
pressed as
@
@t
Zcv
QdV
Ics
F*
cmQ ~GQ ~ndA
Zcv
SQdV 16
where
F*
cmQ F*
Q UgQ 17
For a grid that is comprised of discrete volumes and areas, thegeneric equation above is transformed to:
@QV
@tXNfacef1
~Fcm ~Gn1f ~nfDA
n1f S
n1DVn1 18
Note n + 1 represents the next time level which means that
the above discretized equation is valid for implicit schemes.
where
cm convective-moving~n the cell face normal
DAf the cell face area
DV the cell volume
The flux and source vector must be linearized to estimate the
fluxes and sources at n + 1. This gives:
Fn1
f Fnf
@Ff@Q
f
DQ
Sn1cell S
ncell
@S
@Q
cell
DQ
dQV Vn1
DQn QndVn
The@F=@Q and@S=@Q are the flux Jacobian and source Jacobian,
respectively.
Rearranging terms gives:
DQ
DtDVn1
XNfacef1
@F*
cm
@Q
n
f
@F*
D
@Q
n
f
0B@
1CADQ n_nfDAnf
264
375 DVn @Sn
@QDQ
SnDVn XNfacef1
Fnf n_
nfDA
nf Q
n dVn
rt19
For explicit schemes, the second and third terms of the left hand
side are not required. For non-moving grids
dVn 0
DVn1 DVn
DAn1
DAn
The flux vector and flux Jacobian must be evaluated. CFD-FAS-
TRAN is based on the idea of upwind schemes for convective-mov-
ing fluxes. In particular, two different flux schemes are selected.
The first scheme is based on Roes approximate Riemann solver
and is usually called as the flux difference scheme. The second ap-
proach is based on Van Leers scheme and is considered to be the
flux vector splitting algorithm. Both Roes and Van Leers schemes
are first order spatially accurate. However there are several meth-
ods to improve the accuracy of these schemes. For example, use of
flux limiters, together with an appropriate high resolution scheme,
such as MUSCL scheme, can achieve second order or above spatial
accuracy.
Three limiters are considered: Minmod, monotonic Van Leer
and OsherChakravarthy. Note that the minmod and monotonic
Van Leer limiters are symmetric. Minmod and Van Leer limiters al-
low up to second order accuracy and discussed together. The
OsherChakravarthy limiter is up to third order spatially accurate
and is discussed separately.
The minmod limiter is
wr max0; min1; r 20
The Van Leer monotonic limiter is
wr r jrj
1 r 21
X. Zhao et al. / Computers & Fluids 58 (2012) 4562 47
-
8/2/2019 Loosely Coupled Method
4/18
Finally, the OsherChakravarthy limiter is presented as
wr 1
21 j minmodb; r 1 j minmod1; br 22
where
b min3 j1 j
;3 j1 j
The value ofr determines the accuracy. For r = 1/3, the Osher
Chakravarthy limiter is third order spatially accurate.
The physical boundary conditions assume that the flow field is
in undisturbed free stream state at an infinite distance from the
aircraft surfaces in all directions. On the solid surfaces, the no-slip
and no-penetration conditions are enforced, that is the relative
velocity equals to zero. The normal pressure gradient equals to
zero on stationary surfaces. The temperature is enforced at the so-
lid surfaces using adiabatic boundary conditions. At the grid inter-
face boundaries, the solution is interpolated across the boundaries
using conservative interpolation. Conservative interpolation seeks
to conserve the forces and moments between two adjacent cells.
2.2. CSD model
The structural dynamics response due to fluid flow actions is
analyzed using direct finite-element analysis. The aeroelastic equa-
tions of motion of the solid bodies are given by
MfYg Cf _Yg KfYg fFg 23
where {Y} is the displacement vector, [M] is the mass matrix, [C] is
the damping matrix, [K] is the stiffness matrix, and {F} is the force
vector due to the aerodynamic loads and shear stresses. The equa-
tions of motionof thesolidbodies aresolvedusing thefinite-element
stresscodeFEM-STRESS [13]. FEM-STRESS is a structuraland thermal
deformation solverfeaturingfiniteelement and modal analysis tech-
niques. It is used to analyze linearstatics, lineardynamics, and mate-
rial non-linear problems. The shell elements have five degrees offreedom per structural node. These are the three Cartesian displace-
ments plus two in-plane rotational motions. The module uses the
degenerated shell type element with eight nodal points to discretize
the structure system. This element geometry is interpolated using
the midsurface nodal point and midsurface nodal point normal. It
is assumed that lines that are originally normal to the midsurface
of the shell remainstraight duringthe element deformation andthat
no transverse normal stress is developed. FEM-STRESS solves the
structural mechanics equations, in finite element form, derived from
theprincipal of virtual work.For eachelement, displacements arede-
fined at the nodes and obtained within the element by interpolation
from the nodal values using shape functions.
The motion Eq. (23) of the structure can be solved using modal
approach. On the basis of modal decomposition of the structure mo-
tion with the eigenvector of the vibration problem, the displace-
ment, velocity and acceleration can be transformed to generalized
displacement, velocity and acceleration using a transformation ma-
trix, which can expressed as the following:
fYg UfZg; f _Yg Uf _Zg; fYg UfZg 24
Here [U] is the mode shape matrix containing the eigenvectors,
orthonormalized with the mass matrix, and fZg; f _Zg; and fZg are
the generalized displacement, velocity and acceleration vectors,
respectively. The eigenvectors are orthogonal to both mass and
stiffness matrixes and if Rayleigh damping is assumed, it is also
orthogonal tot the damping matrix. Pre-multiplying Eq. (24) by
[U]T, we get
fZg UTCUf _Zg UTKUfZg UTfFg 25
where
UTMU 1
Eq. (15) can be written as n individual equations, one for each
mode, as follows
zi 2nixi _zi x2i zi ri
r U
T
i fFg( ) i 1;2; . . . ;n 26
Here xi is the natural frequency for the ith mode ni is the corre-sponding damping parameter for that mode. The solution to Eq.
(26) can be obtained for each mode using direct integration
algorithm.
2.3. Interfacing between CFD and CSD grids
MDICE facilitates a variety of methods to perform data ex-
changes between various computational grids. These computa-
tional grids belong traditionally to the computational fluid
dynamics, structural, or thermal domains. When these domains
are coupled in one coupled engineering analysis, one needs to be
able to exchange data from one grid to the other. The grids usually
have a different density, data may reside cell-centered or on thenodes, and/or the grids may not coincide. The interpolation library
currently supports a variety of interpolation methods, including:
FASIT methods (function matching).
Laplacian Interpolation (function matching).
Flux interpolation (flux conserving interpolation for fluidfluid
interfaces).
Consistent interpolation. (conservative and consistent interpo-
lation for fluidstructure interfaces).
2.3.1. FASIT method
FASIT methods employ geometrical-based surface fitting of val-
ues on the interface. Available methods:
Thin plate spline.
Multi-quadrics.
Infinite plate spline.
The original FASIT system was limited to structured grids and
the FASIT gui required the end-user to manually align grids (these
limitations have been removed in MDICE computational formula-
tion). This technology has been adopted from the FASIT software
with some modifications.
2.3.2. Laplacian interpolation
MDICE Laplacian interpolation algorithms provide excellent
matching of analytical functions based upon a multi-dimensional
least-squares algorithm. The relevant features of Laplacian interpo-lation algorithms are:
100% accurate for the interpolated of linear functions.
2D and 3D interface grids are supported.
Zooming (2D3D, Axi-3D) is supported.
Mixing plane interfaces are supported.
Weighting factors are only computed once (therefore interpola-
tion is fast).
All grid alignment is automatic (accomplished by using fast geo-
metrical searching algorithms).
Unstructured and structured grids are supported.
Data can be cell-centered or vertex-based.
The basic algorithm is as follows (described for center-basedcodes):
48 X. Zhao et al./ Computers & Fluids 58 (2012) 4562
-
8/2/2019 Loosely Coupled Method
5/18
Face centered values of a given function are interpolated to the
nodes using a Laplacian operator in the node normal plane
expressed as:
Lq Xni1
wiqi q0
where the weights are determined using a multi-dimensional least
squares algorithm, the Laplacian interpolation stencil is shown in
Fig. 2
Nodal values are used to obtain a gradient (also using a multi-
dimensional least squares fit).
The nearest local face is found for each opposing face as shown
in Fig. 3.
The opposing face is projected into the local face normal plane.
Opposing interface face centered values are interpolated using
the local face center value and gradient along with the opposing
projected face centroid as:
qopposing qlocal rq fDs1;Ds2g
2.3.3. Laplacian interpolation-zooming
The MDICE interpolation library currently supports zooming
(2D3D or axi-symmetric to 3D). Zooming is implemented as
follows:
All geometry is entered in 2D Alternative Digital Tree (ADT)
search trees. For the case of axi-3D, the nodal coordinates are
converted to cylindrical cords before enrollment in the ADT
tree.
Face centered data and gradient are constructed using Laplacian
interpolation.
For interpolating 2D data to a 3D grid, the search tree is used to
find and interpolate data from the nearest 2D face to an oppos-
ing 3D face (ignoring the third dimension). For interpolating 3D data to a 2D grid, the search tree is used to
find and average data from all 3D faces which are near to the
2D face.
2.3.4. Laplacian interpolation-circumferential averaging
Circumferential averaging is implemented by:
Creating a phantom axisymmetric grid.
Interpolating local 3D data to the local axisymmetric grid
(zooming).
Interpolating the local axisymmetric values to opposing 3D
interface (zooming).
2.3.5. Flux-conserving interpolation
MDICE flux conserving interpolation method uses geometrical
clipping to distribute fluxes from one interface to another. The rel-
evant features of the flux-conserving interpolation method are:
The division of flux between a given local face and multiple
opposing faces is determined using geometrical clipping of
opposing faces (SutherlandHodgman clipping algorithm).
A high order distribution of flux is obtained using the Laplacian
interpolation algorithm.
The interpolation is fast (clipping and weighting functions are
only computed once).
All local flux is projected into the opposing interface (100% fluxconserving).
The basic algorithm is described below:
First, face centered flux and gradients of flux are computed
using the Laplacian interpolation algorithm.
All nodes from the local interface are then projected into the
opposing interface as shown in Fig. 4. This assures that all of
the local geometry will reside within the remote interface.
The SutherlandHodgman clipping algorithm is then used to
determine the intersection geometry between each local face
and multiple remote faces as shown in Fig. 5 (all computations
are performed in the two dimensional space defined by the
local face normal plane). The local face flux is divided out to each of the opposing faces by
evaluating the value of flux (local face value + Laplacian gradi-
ents) at each of the clipped centroids as shown in Fig. 6.
This process is repeated for all local faces.
2.3.6. Fluidstructure interpolation
The fluidstructure interface algorithm is used to project the
forces and moments from the fluid flow to the flexible-body struc-
ture and to feed back the aeroelastic deflections of the structure to
Fig. 2. Laplacian interpolation stencil.
Fig. 3. Opposing face and local face. Fig. 4. The projection from local face to remote face.
X. Zhao et al. / Computers & Fluids 58 (2012) 4562 49
-
8/2/2019 Loosely Coupled Method
6/18
the flow field. The interfacing is formulated in the most general
sense for maximum flexibility. There are no inherent assumptions
that the fluids grid is matched with the structure grid, either
through different mesh densities, mesh architecture, or through
physical separation between the interfaces as seen with thick shell
finite-element models. This means that interpolation and extrapo-
lation are key components of the interfacing methodology. Interpo-
lation/extrapolation techniques typically fall into two basiccategories: function matching interfaces and conservative inter-
faces. In functionmatching interfaces, the intention is to provide
the most esthetically-pleasing match betweendata on two grid sys-
tems. The typical test of a functionmatching algorithm is to apply
an analyticalfunction to a donor grid and test theerror in thesame
analytical functionafter interpolation to a mismatchedgrid. Conser-
vative algorithms aimto conserve a relevant property. In thecase of
fluidstructure interpolation, the goal is to typicallyconserve forces
and moments in the interpolation between two code modules. Con-
sistency or virtual work conservation is also a desired property of
fluidstructure interpolation. In order for an algorithm to be consis-
tent, the weighting factors for the interpolation of forces and mo-
ments from the fluids grid to the structural grid must be
preserved in the interpolation of deflection from the structural gridto the fluid grid, in which infinite plate spline is employed with the
adjustment for force and moment conservation. The result is that
the virtual work seen on both the fluids interface and the structural
interface is equivalent (consistent). The MDICE fluidstructure
interpolation method utilizes 3 guiding principles based on Brown
[4]. They are that interpolation should be conservative and consis-
tent, the fluid face pressure is the only correct pressure, and the
structural nodal deformation is the only correct deformation. These
guiding principles dictate a rigorous method for fluidstructure
interface interpolation. The current simulation uses a conservative
and consistent interface, adapted from Brown [4]. Conservative
interfaces aimto conserve theforces and moments in theinterpola-
tion process betweentwo grids. In this case, thesumof allforces and
moments on the fluid interface is equivalent to the sum of all forcesand moments on the structure interface.
Xfluid faces
Ffluid X
solidnodes
Fsolid
Xfluidfaces
Mfluid X
solidnodes
Msolid
Consistency, or virtual work conservation, requires that the vir-
tual work performed by the solid interface is equivalent to the vir-
tual work performed by the fluid interface.Xfluidfaces
Wfluid X
solidnodes
Wsolid
Wfluid Ffluid Drcenter
where
Drcenter fxcen;n xcen;o;ycen;n ycen;o;zcen;n zcen;og
Wfluid Ffluid Dx Msolid -solid
The above equalities apply only to the degree of freedom of the
structure dynamics equations. In order to apply the fluidstructure
interface, the fluid nodal forces are first translated to the solid
nodes using finite element shape function as shown in Fig. 7 (notethat projection of fluid nodes introduces moment on the solid grid)
Fsolid node i Ffluid node 1Ninfluid;1;gfluid;1
Msolid node i r1 Ffluid node 1Ninfluid;1;gfluid;1
The remaining parameters are determined by enforcing consis-
tency. For example, finite element shape functions give the deflec-
tion of fluid node 1 as:
Dxfluid;1 X
solid nodes
Ninfluid;1;gfluid;1Dxsolid;i r1 -solid;i
The final step is to determine the method for interpolation from
fluid face pressures to fluid node forces. For consistency, we must
find nodal weighting factors which result in an accurate approxi-mation of the new face centroid position. The Lapacian interpola-
tion provides an excellent approximation:
Dxcen X
fluid nodes
wiDxnode i
where wi is Laplacian node to center weight
Fnode i wiDFcen:
The conservative-consistent interpolation method relies on pro-
ject off nodes from one interface to another. MDICE currently sup-
ports two projects types: projection to nearest node and projection
to nearest face. Nodal projection can be applied to once at the
beginning of the simulation or at each time step (user-controlled).
2.4. Moving/deformation grid system
The inertial effect of the motion of the distorting solids is fed
into the flow field through the boundary conditions at the solid
interface, and through deformation of the flow field grid. The
CFD grid is deformed at every fluidstructure data exchange
accommodating the deformed shape of solid bodies. The six outer
boundary surfaces of the deformed grid block are kept fixed. The
grid is deformed using TFI. The advantages of using TFI are that
TFI is an interpolation procedure that deforms grids conforming
to specified boundaries and it is very computationally efficient.
The spacing between points in the physical domain is controlled
by blending functions that specify how far into the original grid
the effect of the new position of the flexible body surfaces is car-ried. The grid points near the surface of the tails are moving with
Fig. 5. SutherlandHodgman clipping.
Fig. 6. Laplacian interpolation after clipping.
50 X. Zhao et al./ Computers & Fluids 58 (2012) 4562
-
8/2/2019 Loosely Coupled Method
7/18
the deflections of the tail. The deformation of the grid points de-
creases as you go far from the boundary in all directions, and van-
ishes at the outer boundary of the deformed block. The TFI routine
is invoked automatically when a fluidstructure interface is ex-changed between application modules.
2.5. Multi-disciplinary computing
In general, there are three basic approaches to assembling a
core multi-disciplinary software package: (1) creating of mono-
lithic codes which encompass all disciplines within a single soft-
ware package, (2) coupling independent disciplinary codes using
output/input methods, and (3) connecting independent disciplin-
ary codes into modules in an object-based environment. The first
method becomes prohibitive as the number of disciplines in-
creases. The second one is inefficient and frequently limiting be-
cause the codes are not tightly synchronized. The third one is
efficient and extensible, and forms the basis of the MDICE system.MDICE is a distributed object oriented environment which is made
up of several major components. It includes a central controlling
process that provides network and application control, serves as
an object repository, and coordinates the execution of the several
application programs via a MDICE specific script language. The sec-
ond component is a collection of libraries, each containing a set of
functions callable by the application programs. These libraries pro-
vide low level communication and control functions that are hid-
den from the application programs, as well as more visible
functionality such a object creation and manipulation, interpola-
tion of the data along interfaces, and safe dynamic memory alloca-
tion services. Finally, the environment also encompasses a
comprehensive set of MDICE compliant application programs.
Themulti-disciplinary modules used in the current investigationare integrated into the MDICE [14]. MDICE is a distributed object
oriented environment for parallel execution of multi-disciplinary
modules. There are many advantages to the MDICE approach. Using
MDICE environment one can avoid giant monolithic codes that at-
tempt to provide all modules in a single large computer program.
Such large programs are difficult to develop and maintain and by
their nature cannot contain up-to-date technology. MDICE allows
the reuse of existing, state-of-the-art codes that have been
validated. The flexibility of exchanging one application program
for another enables each engineer to select and apply the technol-
ogy best suited to thetaskat hand. Efficiencyis achievedby utilizing
a parallel-distributed network of computers. Extensibility is pro-
vided by allowing additional engineering programs and disciplines
to be added without modifying or breaking the modules or disci-plines already in the environment.
CFD-FASTRAN fully embeds MDICE for aeroelastic simulations;
users do not see it at all. The solution procedure is loosely coupled
and involves communication of two completely separate soft-
wares. First, the structural solver advances one time-step using a
2nd-order Newmark scheme, then the deformations (possibly re-
laxed) are communicated to the flow solver which deforms its
meshes then advances the flow solution one time-step using a
1st-order backward-Euler scheme. Fluid pressures are communi-
cated to the structural solver and the loop repeats itself. The struc-
tural model may be an actual FEM model comprised of various
element types or a generalized linear modal solver can be used.
Modal analysis is the norm, because the cost of using a nonlinear
and detailed structural model is impractical. The mode shapes
and frequencies can be calculated by CFD-FASTRAN or externally
input, e.g. from NASTRAN output.
2.6. MDICE architecture
Major features of MDICE include the ability to synchronize
application programs, manipulate objects, handle events, carry
out remote procedure calls, an execute, and a script written in an
MDICE script language. MDICE also provides for parallel execution
of participating application programs and has a full Fortran inter-
face for those codes written in Fortran 77 or in Fortran 90 (of
course, C and C++ are supported as well).
MDICE is broken down into several major components. The first,
MDICE proper, is a central controlling process that provides the
features described above. Users interact with this central process
via a graphical user interface. The second is a library of functions
that application programs use to communicate with each other
and with MDICE. The environment also encompasses a compre-
hensive set of MDICE complaint application programs.
2.6.1. Application control
The MDICE Graphical User Interface includes facilities for the
control of application programs, a drawing area where a visual rep-
resentation of the simulation is rendered, an object clipboardwhere information about the various objects created and manipu-
lated by the application programs is displayed, a script editor that
allows the engineer to dictate how the simulation should be run,
and a status window displaying run-time system messages or
warnings.
The graphical user interfaces is used by engineers to set up a
simulation. Application programs are selected; for each, the com-
puter on which the program is to be run is chosen. Other informa-
tion is provided, such as specifying a directory to run the program
in and any command line arguments the program might require.
Once the simulation has been set up, it is run and controlled
using MDICE. The script panel used to achieve this control. The
script used by MDICE contains all the conveniences found in most
common script languages. In addition, the MDICE script supportsremote procedure calls and parallel execution of the application
programs being used for a given simulation. These remote proce-
dure calls are the mechanism by which MDICE controls the execu-
tion and synchronization of the participating applications. Each
application posts a set of available functions and subroutines.
These function are invoked from the MDICE script, but are exe-
cuted by the application program who posted the function.
2.6.2. Objects
MDICE supports objects at several levels. On the lowest level,
objects are simply named collections of scalar data, arrays, and
other objects. These objects are called data objects, array objects,
and general objects, respectively. An application program can cre-
ate an object using one of the creation functions provided byMDICE. An integer handle to the object is returned by the creation
Fig. 7. The node projection from fluid face to solid face.
X. Zhao et al. / Computers & Fluids 58 (2012) 4562 51
-
8/2/2019 Loosely Coupled Method
8/18
function. These handles are used in all subsequent operations on
the object.
Each object is completely self describing. It may be assigned a
group name, user name, and application name at creation time.
In the case of data and array objects, a data type is assigned, and
for array objects the length of the array is specified. Using these
features, applications may examine a new object that is sent to it
from an external application to determine how to deal with it.
For many, the recipient application may a query an incoming
grid object to determine whether the object contains blanking
information, or it may query on incoming flow data object to
see which flow variables are included.
Applications may convert data and array objects from one type
to another, or provide updated values for the scalar data or array
elements. In this way, an application may convert a newly received
array object from double to single precision. Any subsequent re-
ceives of this object are automatically converted into single preci-
sion regardless of the type being used by the sending application.
Since objects may contain other objects, a hierarchical object
tree may be built by an application. Once constructed, the object
tree may be registered with MDICE, making the object available
for transmission to another application. When an application reg-
isters an object, the structure of the object tree (but not the data
associated with data or array objects) is sent to the MDICE GUI.
Applications may themselves create and access the low level
objects (data, array, and general objects). However, the preferred
method of operation is to define a set of higher level objects such
as grid objects, flow data objects, and interface objects and place
functions that create, access, and manipulate these objects into a
library. MDICE provides such a high level library (described in
the MDICE Libraries section); applications may create these high
level objects using MDICE-provided convenience functions without
concerning themselves with the low level objects they are com-
posed of. In either case, the application simply receives a handle
to the object for use in subsequent operations.
2.6.3. Event handlingMost window-based programs are event drive programs. These
include graphics or design programs that run on UNIX worksta-
tions as well as word processors and spreadsheets that run on per-
sonal computers. These event driven programs spend most of their
time waiting for the user to do something interesting, such as
pressing a button, choosing an option from a menu, or moving or
clicking the mouse.
Programs integrated into MDICE must become event driven.
Subroutines will be called from an MDICE script rather than from
PROGRAM MAIN. Object related events such as create, send, re-
ceive, and destroy must be handled.
2.6.4. Remote procedure calls
Remote procedure calls are the mechanism by which MDICE in-vokes subroutines or functions that are executed by a participating
application program. The user of the system writes such a function
call using the MDICE script editor.
In order to carry out the remote procedure call, MDICE evalu-
ates each expression in the functions argument list and packs
the result of the expression into a message buffer. This is called
marshalling the arguments. Next, the message buffer is transmit-
ted to the application, which has previously called MDICEs special
control function and is in its event loop waiting for something to
happen, such as an object related event or (as in this case) an
incoming remote procedure call command. The MDICE library
intercepts the incoming message, unpacks the arguments, and calls
the applications function. After the function completes, the return
value (in this example, a boolean value that indicates whether thesolution has converged yet) is packed into a new message buffer
and sent back to MDICE. MDICE places the return value of the func-
tion into the expression containing the original function call, and
the script resumes.
The internal processing required by MDICE to make these re-
mote procedure calls work is rather complex. First, MDICE must
know about the procedures that the application programs wish
to make available. This requires that a detailed type system be
implemented. MDICE must also be able to call procedures that
are internal to an application without knowing a priori what the
type signature of the procedures are. This requires that MDICE call
wrapper functions whose type MDICE does know. These wrapper
functions must be linked with the particular application whose
procedure is being invoked. In order to spare the application pro-
grammer from writing them, MDICE provides a stubber that auto-
matically generates these wrappers.
2.6.5. MDICE script
MDICE allows full user control by means of a script. The MDICE
script language is easy to learn yet powerful, making full custom-
ization of multi-disciplinary simulations possible.
The language allows all the standard conveniences found in
most script languages: local and global variables, a rich set of datatypes including integers, real numbers, strings, objects, and arrays
of these base types, decisions (i.e. if statements), and loops. In addi-
tion, the MDICE language provides for remote procedure calls (dis-
cussed in the previous section), execution of portions of the script
in parallel (discussed in the next section), application control in
form of run and kill commands, and debugging tools such as print
(which prints a string to the MDICE status window) and pause
(which pauses the script until the continue button is pressed).
Unlike most shell script languages, the MDICE script is a com-
piled language. It is read in its entirety, converted into internal data
structures (e.g. an abstract syntax tree, control flow graph, and
symbol table are all built by MDICE), and the resulting code is exe-
cuted. Space for variables and the results of expressions are allo-
cated before a script is run and freed when it is complete.The script is strongly typed. Each expression is fully checked for
compatibility of its operands before the script begins running. The
return value of each function is also checked, statically if the func-
tion has been posted by the named application before script execu-
tion (in which case MDICE already knows the type of the return
value), dynamically if the function is posted during the run.
2.6.6. Parallelism
An additional complexity is introduced by the requirement that
MDICE must be able to call distinct procedures simultaneously.
MDICE solves this problem by implementing the notion of threads.
Since threads are not implemented on all the platforms that we
wish to run MDICE on, this is implemented directly inside MDICE.
Neither application programs nor users need be aware that this istaking place. MDICE has a thread class that represents a portion of
the script to be executed in parallel with other portions. A list of
runnable threads is maintained by MDICE. When one thread blocks
(when a remote procedure is being called, for example), the thread
is placed on a list of blocked threads and a new runnable thread is
selected. If no more runnable threads remain, MDICE simply waits
for one or more remote procedure calls to complete.
As results (i.e. return values) from the remote procedure calls
are delivered to MDICE, the appropriate blocked thread is moved
from the blocked list to the runnable list. Each remote proce-
dure call is tagged with a reference number to match these incom-
ing return values with the thread that called the function in the
first place. When no more incoming messages are left, one of the
runnable threads is chosen for execution (using a round-robinscheduling algorithm) and the script resumes.
52 X. Zhao et al./ Computers & Fluids 58 (2012) 4562
-
8/2/2019 Loosely Coupled Method
9/18
For example, if several CFD flows solvers are being used to solve
a problem, it is necessary that each perform an iteration over the
flow domain concurrently. Each remote procedure to be called
simultaneously is carried out by a separate thread. Of course, the
end user need not be aware that this is taking place. Using a special
parallel script command, one can write blocks of code, each of
which is executed simultaneously. Within a given block, each
statement is executed in parallel.
A shorthand notation is available if each block contains a single
expression. This shorthand uses MDICEs semicolon operator. This
operator is similar to the comma operator in the C programming
language in that each semicolon-separated expression is evalu-
ated; the value of the entire expression is the value of the
rightmost expression. The difference is that each expression (i.e.
all the remote procedure calls) are evaluated simultaneously. The
entire expression completes when all the function calls complete.
Table 1
Free stream conditions for ONERA M6 wing.
u1 277.06 m/s
v1 14.810 m/s
p1 1.0447 105 N/m2
T1 272 K
k1 0.1 m2/s2
e1 15J/kg sM
10.8395
AOA (angle of attack) 3.06
Fig. 8. Pressure coefficients on the ONERA M6 wing surface at different cross section.
X. Zhao et al. / Computers & Fluids 58 (2012) 4562 53
-
8/2/2019 Loosely Coupled Method
10/18
2.6.7. Fortran interface
The MDICE libraries are written in the C programming language.
In order to call the functions from a Fortran program, a complete
Fortran interface is provided. This interface allows all the common
Fortran data types, including integers, single and double precision
reals, character strings, and arrays to be passed into the library
functions.
2.6.8. MDICE libraries
MDICE provides four libraries of functions that application pro-
grams may be linked with when they are integrated into the com-
puting environment. These are
1. A low level MDICE library. This library implements low level
objects (data, array, and general objects), communication
(sending and receiving messages between applications or
between applications and MDICE), and control (event handling
and remote procedure calls) mechanisms.
2. An object library containing a rich set of predefined objects.
These objects include:
Arrays (double and single precision reals, integers, strings,
etc.). Grids (structured, unstructured, and polyhedral.
Flow data (scalar and vector field data).
Domains (a combination of grids and flow data).
Boundary conditions.
Interfaces (fluidfluid and fluidstructure interface
couplings).
Plotting data (line data and point data).
3. An interpolation library that provides interpolation of flow field
data between different CFD flow solvers or between a CFD flow
solver and a structural analysis code. This interpolation library
is a critical feature of MDICE. It facilitates a general coupling
between flow solvers, i.e., a 3D3D coupling, a 2D2D coupling,
a 2D3D coupling (zooming), arbitrarily matched grids (both
structured and unstructured), and circumferential averaging
for mixing plane treatment. The fluidstructure interface fea-
tures a set of interpolation methods, including a fully conserva-
tive (forces, moments) and consistent interface. Provisions are
in place to provide automatic grid, data, and unit conversions
within MDICE.
4. A memory allocation library that can be used to dynamically
check the correctness of the applications use of dynamically
allocated memory.
3. Results and discussion
ONERA M6 model is designed for studies of three-dimensional
flows from low to transonic speeds at high Reynolds numbers.
Fig. 9. Computational mesh used in this study (mesh on the symmetry plane along
the root chord and the wing surface are shown).
Fig. 10. The treatment for unmatched grid with quite large gap.
Structure-side surface mesh Fluid-side surface mesh
Fig. 11. Surface meshes on the structure side and fluid side of the upper wing surface (a one-to-one match is not necessary).
54 X. Zhao et al./ Computers & Fluids 58 (2012) 4562
-
8/2/2019 Loosely Coupled Method
11/18
M6 wing is chosen first for validating the flow solver by comparing
predicting Cp over several sections of the wing to the experimental
data.
3.1. Steady state transonic ONERA M6 wing
The selected test case corresponds to Test 2308 from the paper
by Schmitt and Charpin [15]. These corresponds to a Reynolds
number 11.72 106 based on mean aerodynamic chord of
0.64607 m and a Mach number of 0.8395. The free-stream flow
conditions at the Mach number and Reynolds number are listed
in Table 1.
Validation data consists of pressure coefficients at section along
the span of the wing obtained in the experiment [15]. The pressure
coefficients are compared along the lower and upper surfaces of
the wing at each of the sections. The spanwise location of the sec-tions is specified with respect to the wing span, b.
The results presented in the paper are obtained with the third
order scheme, Roe flux differencing with OsherChakravarthy flux
limiter. A comparison of experimental and predicted pressure coef-ficients, Cp, for sections 1 through 6 is shown in Fig. 8.
3.2. AGARD wing flutter
The case used for validation is the well-known AGARD configu-
ration I wing 445.6, weakened model 3, a wall-mounted 45
swept half-wing with an aspect ratio of 1.65 and a taper ratio of
0.6576. The cross-section of the wing is a thin NACA 65A004 airfoil
section. The experimental data [16] cover a range of Mach numbers
from 0.499 to 1.141 and there is a clear transonic dip in the flutter
boundary well captured by several data points around Mach 0.9.
The authors published mode shapes and frequencies for the first
five modes and suggested a value for structural damping. The ac-tual model was constructed of laminated mahogany with holes
x/c
Cp
0 0.2 0.4 0.6 0.8 1
-0.2
-0.1
0
0.1
0.2
0.3
0.4
0.5
0.6
Span = 90%
x/c
Cp
0 0.2 0.4 0.6 0.8 1
-0.2
-0.1
0
0.1
0.2
0.3
0.4
0.5
0.6
Span = 95%
x/c
Cp
0 0.2 0.4 0.6 0.8 1
-0.2
-0.1
0
0.1
0.2
0.3
0.4
0.5
0.6
Span = 75%
x/c
Cp
0 0.2 0.4 0.6 0.8 1
-0.2
-0.1
0
0.1
0.2
0.3
0.4
0.5
0.6
Span = 50%
x/c
Cp
0 0.2 0.4 0.6 0.8 1
-0.2
-0.1
0
0.1
0.2
0.3
0.4
0.5
0.6
Span = 25%
x/c
Cp
0 0.2 0.4 0.6 0.8
-0.2
-0.1
0
0.1
0.2
0.3
0.4
0.5
0.6
Span = 0%
Fig. 12. Steady-state pressure coefficient on the upper side of the AGARD wing.
X. Zhao et al. / Computers & Fluids 58 (2012) 4562 55
-
8/2/2019 Loosely Coupled Method
12/18
drilled in it and filled with foam. This case has been used for vali-
dation of transonic flutter by other CFD/CSM codes in loosely andfully coupled time-domain approaches [17,18], but results for
CFD-FASTRAN have not been previously reported. Also, due to
the compute-intensive nature of such simulations, more investiga-
tions are still needed to improve the practical utility of this ap-
proach. The present study contributes to that need as well.
A relatively coarse grid labeled as baseline grid was used for
these initial studies. The grid used for Euler simulations in this
study is shown in Fig. 9. The grids for both fluid and structural
computations do not have to match one-to-one at the fluid/struc-
ture boundary, but their boundary points should lie along the same
lines or curve so that neither mesh extends beyond the other.
Otherwise, the accuracy of the pressure/displacement interpola-
tion procedure will be reduced. Fig. 10 illustrates a case where
the structural mesh is slightly shorter than the fluid mesh. The fig-ure compares the surface grid at the root-chord line for a structural
mesh against a fluid mesh. The three points illustrated by the sym-
bol of ball in the fluid mesh are beyond the leading edge of the
structural mesh. It would have been better to extend the structural
mesh so that it was tip-to-tip identical to the fluid mesh. The pres-
ent coupling method can handle such situation as the fluid nodes
will still receive displacements from the calculated deformation
of the structure.
The surface meshes on the upper wing wall in the structural do-
main and the fluid domain are shown in Fig. 11. The flow domain
had 114,660 nodes with 1550 nodes on the wing surface. The wing
section itself had 1323 nodes with 1134 nodes on the surface. The
meshes do not have a one-to-one match. However, the leading and
trailing edges of the wing of both the structural and fluid domains
lie along the same boundary and do not extend over the other. The
mass of the wing was 1.86 kg. The material properties were ob-
tained from experiments and other coupled computational studies
[16,19]. The Youngs modulus was 3.15 GPa along the elastic axis
(E1) and 0.4162 GPa along other orthogonal coordinates (E2 = E3).
The shear modulus (G) was 0.4392 GPa and the Poissons ratio (m)was 0.31.
3.2.1. Computational procedure
Several methods have been employed historically to identify
flutter boundary. More recently, time accurate CFDCSD methods
are being increasingly employed. Such studies start with a steady
solution and the growth and transport of energy in and between
different modes is monitored. In this study, a similar time-march-
ing approach to identifying flutter boundary was used. The wing
was let go at t= 0 and the time-accurate response of the structural
system at different freestream dynamic pressures for a given Mach
number is monitored over the period of a few cycles. The overall
procedure for carrying out computational aeroelastic computa-
tions can be divided into following major steps.
1. Constructing the geometry for aeroelastic computations and
also set appropriate boundary conditions and initial conditions.
2. Perform steady-statecomputationto obtain initialguess or providean initial solution for starting coupled unsteady computations.
3. Conduct unsteady CFD computations using steady state results
as initial guess and obtain necessary aerodynamic forces on the
surface of the wing.
4. Map aerodynamic forces onto the structural mesh.
5. Carry out CSD computation to obtain the deformation of the
geometry.
6. Map the displacements onto CFD surface grid.
7. Re-mesh CFD grid based on the deformation obtained from CSD
calculations using the moving grid module.
8. Repeat steps 37 using current solution as the initial guess for
the subsequent steps.
The response is then classified as damped, neutral or divergingand the flow condition is changed to the next step by increasing/
decreasing the dynamic pressure. An undamped neutral response
indicates the flutter boundary. The dynamic pressure is changed
independent of the Mach number and mass ratio.
3.2.2. Static solutions
Prior to conducting flutter analyses, the steady state fluid flow
around the wing was evaluated. This steady state solution could
also be used later as an initial guess for the unsteady simulation.
The steady state pressure coefficient for a freestream Mach number
of 0.96 is shown in Fig. 12. The free stream dynamic pressure, den-
sity and temperature are chosen to represent the experimental
flutter boundary point at M= 0.96 published by Yates [16]. Com-
parison of Cp values along different sections of the wing spanshows that the present mesh predicts very similar steady state
Fig. 13. Regions of supersonic flow over the AGARD wing.
Fig. 14. Convergence of total force (Fy) and displacement.
56 X. Zhao et al./ Computers & Fluids 58 (2012) 4562
-
8/2/2019 Loosely Coupled Method
13/18
surface pressure distribution as finer meshes. The grid indepen-
dence is discussed at the following section. Areas of supercritical
flow (M> 1) shown in Fig. 13 also compares well with similar stud-
ies. The contour levels resolve Mach number values above 1. Re-
gions with Cp values less than the supercritical Cp are also shownin Fig. 13. Supersonic flow can be observed over a large portion
of the wing. A strong compression can also be observed on the in-
board portion of the wing. These results qualitatively indicate that
the present mesh is capable of capturing major aerodynamic fea-
tures of the flow and deemed sufficient for an initial analysis.
In addition to the steady state flow simulation, the static deflec-
tion of the AGARD wing under the influence of surrounding steady
fluid flow was studied. The wing was modeled structurally by the
first six vibrational modes. This simulation illustrates the coupling
of an Euler flow solver with a structural solver that employs modal
superposition technique. Fluid structure interfacing was achieved
by interpolating original mode shapes on a structural grid to thefluids grid and then using the interpolated mode shape on the
Fig. 15. Shape and displacements of the first five modes of the AGARD 445.6 wing from both of the present work and Ref. [11].
Table 2
Modal frequencies of AGARD wing.
FASTRAN 9.2 39.1 48.1 94.4 120.5 145.6
Yates 9.6 38.2 48.3 91.5 118.1 140.2
X. Zhao et al. / Computers & Fluids 58 (2012) 4562 57
-
8/2/2019 Loosely Coupled Method
14/18
fluids grid. For steady-state simulations, fluidstructure coupling
took place every 10 cycles in order to allow the flow to develop.
For transient simulations, the coupling took place at every time
step. The convergence history of the steady state simulation could
be observed through the wing displacement and the total aerody-
namic force (Fy) and are shown in Fig. 14. The solution reaches a
steady state within 200 cycles (20 fluidstructure exchange) for
displacement and a little longer for the forces. FASTRAN predicted
shape and displacements of the wing for the first five modes are
shown in Fig. 15. In Fig. 15 the scaling factors in x, y and z direc-tions are 1.0, 1.5 and 1.0, respectively. The modal deflections from
Ref. [16] are shown in Fig. 15, too. The predicted frequencies are
compared with results from Ref. [16] and are shown in Table 2.
The predicted frequencies compare well with experimental results.
At higher modes, the difference becomes larger.
3.2.3. Transient solutions and dynamic flutter
Time marching analysis was performed to identify flutter
boundary points and to compare them with experimental data.
Since, the experimental data is known, initial tests were conducted
at these experimental boundary points. From the experimental
data available in Ref. [16], four freestream Mach numbers
(M= 0.499, 0.678, 0.96 and 1.141) were chosen. Based on the re-
sponse at these conditions, different flutter speed indexes weretested around the experimental flutter boundary points by varying
the dynamic pressure and to arrive at the FASTRAN predicted flut-
ter boundary. The flutter speed index (V) is given by the relation
V = U1/(bsl0.5xa) where U1 is the freestream velocity, bs is the
streamwise semichord measured at the wing root, l is the mass ra-tio and xa is the natural circular frequency of wing in first uncou-pled torsion. Fig. 16 shows the transient response as observed
through the actual displacement at a particular grid point. The ac-
tual displacement of the wing is used in all the results presented in
this work. All results were based on a flow time step of 5.e4 s and
one fluidstructure coupling per step. This limitation will also beremoved in the future. Fig. 16 shows the diverging, neutral and
damped behavior of the system for different speed index ratios.
Similar procedures were used for all four Mach numbers presented
in this paper.
Fig. 17 compares the predicted flutter speed index and fre-
quency ratio with the experimental values, in which the results
on fine mesh is also presented and will be discussed in the follow-
ing Section 3.3. At subsonic speeds, the flutter boundary point is
well predicted in terms of frequency, frequency ratio and the speed
index. At M= 0.96, the speed index closely matches with the exper-
iments. However, the predicted frequency is approximately 1 Hz
lower than the experiments. At M= 1.141, the flutter speed index
is significantly overpredicted. Similar results have been observed
in several other studies. Many researchers have attempted to in-clude viscous effects in order to get a better prediction for this
Fig. 16. Dynamic response of the structural system for varying dynamic pressures at M1 = 0.96.
58 X. Zhao et al./ Computers & Fluids 58 (2012) 4562
-
8/2/2019 Loosely Coupled Method
15/18
Mach number. However, no attempt was made to include the ef-
fects of viscosity in this initial investigation to get a better predic-
tion of the flutter boundary at higher Mach numbers. A limited
study was undertaken to observe the effect of different viscous
models on the structural response. Instead of evaluating the flutter
boundary, the effect of different viscous models at one flow condi-tion was observed. The chosen case was M= 0.96 and
V=Vexp 1.
3.3. Sensitive study
This study conducts a sensitivity analysis of the proposed
loosely-coupled method for aero-elastic simulation. The main
objectives of the sensitivity study are to address the effects of phys-
ical model, initial condition and grid resolution on the accuracyand
results.
3.3.1. Fluid flow model
Fig. 18 showsthe displacement forthree modelsviz: Euler (Invis-
cid), Laminar NavierStokes and Turbulent NavierStokes with theBaldwinLomax model. The frequencies remain identical on all
three cases. The displacements generally show an increase in the
growth rate with highest growth rate for the laminar case followed
by the turbulent one. Since the present mesh do not have enough
resolution to capture the boundary layer profile properly, it is not
possible to make any definite conclusions. However, these results
indicate that the affects of viscosity on flutter characteristics.
3.3.2. Initial condition
Different initial conditions could in theory determine the growth
rate of perturbations and hence the flutter. To investigate, two cases
were studied. In the first case, a steady-state solution with a static
deflection imposed on the wing was used. The second case was ini-
tialized with uniform flow conditions and the wing present at theneutral (zero displacement) position. This was the same initial
conditions used in the steady-state simulation. Fig. 19a shows the
actual displacements andthe locationof the peaks on the upper side
of thecurve. Analysis of this data shows that the frequency remains
the same in both cases. The amplitude levels are different between
the two cases. Fig. 19b shows that even though thesolution startsatdifferent conditions, the growthrate reachesthe same levels in both
Fig. 17. Comparison of the flutter frequency ratio and the speed index for the
AGARD wing.
Fig. 18. Effect of the viscous model on the structural response at M1 = 0.96 and
V=Vexp 1.
X. Zhao et al. / Computers & Fluids 58 (2012) 4562 59
-
8/2/2019 Loosely Coupled Method
16/18
cases (see figure after 0.3 s) and theactual displacements just reflect
the initial perturbation levels. These cases were notrunlong enough
to observe any limit cycle oscillation(LCO) behavior. But it would be
veryinterestingto compare the amplitude levels if theyreach such a
stage. Fig. 19c and d shows the generalized displacements for con-
stant initial conditions andsteady-statesolution conditions, respec-
tively. It can be seen they are in similar trends as that in Fig. 19a.
3.3.3. Grid resolution
Grid independence is associated withthe accuracy or evenratio-
nality of numerical results. To demonstrate the grid independence
of the above results predicted by the proposed coupled method,
two more sets of meshes are generated on the wing geometry, they
arelabeled as coarse grid and fine grid, respectively. The coarse grid
is the half of the number of grid points in each direction within the
baselinegrid.The numberof thefine grid points is twicethat in each
direction within the baseline grid. Fig. 20 shows the transient re-
sponse as observed through the actual displacement at particular
grid point. In Fig. 20, the computed time histories of the actual
displacements of the grid point at M1 = 0.96 and V/Vexp = 1.00
areplottedfor three sets of mesh. The plots correspondsto thebase-line grid, coarse grid and fine grid responses, respectively. The
amplitude of the actual displacements deceases in time correspond-
ingto thecoarse grid response as shown in Fig. 20b, this is attributed
to the poor solution accuracy on the coarse grid. It can be seen the
amplitudes for both baseline grid and fine grid increase with the
time matching, indicating the grid resolution at baseline and be-
yond is sufficient to obtain the solution accuracy for the present
wing flutter simulations. The amplitudes for the fine grid grow fas-ter than that for the baseline grid. Fig. 21 shows the computed time
histories of the generalized displacements for the first three modes
with thethree sets of grid. Theyare generallyin thesimilar trends as
that in Fig. 20. Fig. 17 compares the predicted flutter speed index
and frequency ratio on the fine grid with the experimental values.
It can be seen that the increase of grid resolution can improve the
accuracy of computational results.
FASTRAN requires parallel processing for flows with fluid
structure interactions. These cases were run in parallel with two
nodes, one for the fluid domain and the other for the stress solver.
For each case, five flutter cycles are needed to make a decision as to
whether the response is diverging, damped or neutral. Each run of
five flutter cycles took about 6 h of CPU time. Since the experimen-
tal flutter boundary was known, the search operations were mini-mized around these points. However, in a case where values are
(a) (b)
(c) (d)
Fig. 19. Effect of initial condition on the structural response. (a) Displacement curve. (b) Location of peaks on the displacement curve from (a). (c) The generalized
displacement for constant initial conditions. (d) The generalized displacement for steady-state solutions initial conditions.
60 X. Zhao et al./ Computers & Fluids 58 (2012) 4562
-
8/2/2019 Loosely Coupled Method
17/18
unknown, it might be better to start at a lower speed index and fol-
low an optimized path to the flutter boundary in order to keep
computational costs to a minimum. Scaling up the parallel run
Fig. 20. Effect of grid resolution on the structural response at M1 = 0.96 and
V=Vexp 1. (a) Baseline grid. (b) Coarse grid. (c) Fine grid.
(a) Baseline grid
(b) Coarse grid
(c) Fine grid
Fig. 21. Time history of the generalized displacements of the first three modes at
M1 = 0.96 and V=Vexp 1.
X. Zhao et al. / Computers & Fluids 58 (2012) 4562 61
-
8/2/2019 Loosely Coupled Method
18/18
should cut down the wall clock time required to arrive at the flut-
ter boundary. This has been deferred to a future study.
4. Conclusions
An integrated fluid structural interaction simulation tool has
been developed in a loosely coupled fashion through MDICE. The
MDICE systems modular treatment of computational codes provedversatile enough to easily and accurately couple different flow
solvers and various structural solvers. The computed flutter bound-
ary of AGARD wing 445.6 for free stream Mach numbers ranging
from 0.499 to 1.141 is presented and compared well with experi-
mental data. The transonic dip phenomenon is well captured.
The availability of multi-disciplinary modules and the seamless
integration made available to the present loosely coupled fluid
structure methodology have been shown to be well suited for
dynamic flutter predictions. The present studies are in the
preliminary phase. Future work will concentrate on dynamic flut-
ter approach frameworks to obtain faster and accurate predictions
through the choice of viscous/turbulence models, grid sensitivity
analysis and frequency of fluidstructure coupling.
References
[1] Bennett RM, Edwards JW. An overview of recent developments in
computational aeroelasticity. AIAA Paper 98-2421.
[2] Huttsell L, Schuster D, Volk J, Giesing J, Love M. Evaluation of computational
aeroelasticity codes for loads and flutter. AIAA Paper 2001-0569.
[3] King GM, SiegelJM, Harrand VJ,Lawrence C, Luker J. Development of themulti-
disciplinary computing environment (MDICE). AIAA Paper 98-4738.
[4] Brown SA. Displacement extrapolation for CFD and CSM analysis. AIAA Paper
97-1090.
[5] Sheta EF, Huttsell LJ. Numerical analysis of F/A-18 vertical tail buffeting. AIAA
Paper 2001-1664.
[6] Sheta EF, Harrand V, Thompson D, Strganac T. Computational and
experimental investigation of limit cycle oscillations of nonlinear aeroelastic
systems. J Aircraft 2002:3913341.
[7] Zhang, SJ, Meganathan A. Preconditioning methods in CFD-FASTRAN. AIAA
Paper-2008-0701; 2008.[8] Zhang SJ, Meganathan, A. Implicit time accurate method for unsteady
computations. AIAA Paper-2009-0166; 2009.
[9] Zhao X, Richards PG, Zhang SJ. A dynamic mesh method for unstructured grids.
Comput Fluid Dyn J 2004;12(4):58093.
[10] Zhang SJ, Zhao X. Computational studies of stage separation with an
unstructured chimera grid method. AIAA Paper-2007-5409; 2007.
[11] Zhang SJ, Meganathan A. Development and validation of transonic flutter
prediction methodology using CFD-FASTRAN. AIAA Paper-2007-2015; 2007.
[12] Zhang SJ, Zhao X, Lei J. Hypersonic non-equilibrium computations for ionizing
air. AIAAPaper-2009-1591; 2009.
[13] Yang HQ, Wang ZJ. Interaction of shock wave with a flexible structure. AIAA
Paper 94-0362; 1994.
[14] Siegel J, Parthasarathy V, Kingsley G, Dionne P, Harrand V, Luker J. Application
of a multi-disciplinary computing environment (MDICE) for loosely coupled
fluid-structural analysis. AIAA 98-4865.
[15] Schmitt V, Charpin F. Pressure distributions on the ONERA-m6-wing at
transonic mach numbers. Tech. rep. AGARD AR 138, AGARD; May 1979.
[16] Yates Jr EC. AGARD standard aeroelastic configurations for dynamic response I
Wing 445.6. AGARD. Report No. 765; September 1985.
[17] Liu F, Cai J, Zhu Y, Tsai HM, Wong AS. Calculation of wing flutter by a coupled
fluid-structured method. J Aircraft 2001;38:33442.
[18] Chen XG, ZhaGC, Yang MT. Numerical simulation of 3-Dwing flutterwith fully
coupled fluid-structural interaction. Comput Fluids 2007;36:85667.
[19] Lee-Rausch E, Batina J. Calculation of AGARD wing 445.6 flutter using Navier
Stokes aerodynamics. AIAA Paper 93-3476.
62 X. Zhao et al./ Computers & Fluids 58 (2012) 4562