loosely coupled method

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


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


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


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):



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.



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.



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.



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.



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.



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).



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.



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.



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



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.



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.



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.



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.



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.


loosely coupled method

Documents