aiaa 2004–4480 - stanford universityaero-comlab.stanford.edu/papers/alonso.aiaa.04-4480.pdf ·...

AIAA 2004–4480pyMDO: A Framework forHigh-Fidelity Multi-DisciplinaryOptimizationJuan J. Alonso, Patrick LeGresley, Edwin van der WeideStanford UniversityStanford, CA 94305, U.S.A.

Joaquim R. R. A. MartinsUniversity of TorontoToronto, Ontario, Canada, M3H 5T6

James J. ReutherNASA Ames Research CenterMoffett Field, CA 94035, U.S.A.

10th AIAA/ISSMO Multidisciplinary Analysis and OptimizationConference

August 30 – September 1, 2004, Albany, New York

For permission to copy or republish, contact the American Institute of Aeronautics and Astronautics1801 Alexander Bell Drive, Suite 500, Reston, VA 20191–4344

pyMDO: A Framework for High-FidelityMulti-Disciplinary Optimization

Juan J. Alonso∗, Patrick LeGresley†, Edwin van der Weide‡

Stanford UniversityStanford, CA 94305, U.S.A.

Joaquim R. R. A. Martins§

University of TorontoToronto, Ontario, Canada, M3H 5T6

James J. Reuther¶

NASA Ames Research CenterMoffett Field, CA 94035, U.S.A.

This paper presents a new approach to the software architecture of a high-fidelitymultidisciplinary design framework that facilitates the reuse of existing components, theaddition of new ones, and the scripting of MDO procedures. As a first step towards thisgoal, we implement the necessary components of a high-fidelity aero-structural design en-vironment for complete aircraft configurations, and demonstrate them with two separateaero-structural analyses: a supersonic jet and a launch vehicle. At the core of the frame-work is an aero-structural solver that uses high-fidelity models for both disciplines as wellas an accurate coupling procedure. The Euler or Navier–Stokes equations are solved forthe aerodynamics and a detailed finite-element model is used for the primary structure.Rather than focusing on the actual design method and results, this paper emphasizes therole that sound software development environments can play in the creation of complexhigh-fidelity design optimization applications. In particular, we describe lessons learnedduring the course of this experience using the Python programming language, the devel-opment cost incurred in comparison with a traditional, Fortran 90/95, C, or C++ baseddevelopment method, and the impact that this type of approach can have on both theestablishment of high- and multi-fidelity design environments and in the productivity ofresearch groups in academic settings.

Introduction

THE engineering research and industrial communi-ties often underestimate the importance of sound

software design practices when developing large-scaleintegrated simulations. The underlying thought inmany cases is that code efficiency and accuracy of theresults are the most important, and therefore ease ofuse and maintainability are sacrificed. A lack of neces-sary resources is often quoted as the excuse to ignorewell-established software development practices.

It has become clear that a large majority of the re-maining challenges in aerospace engineering are suchthat they require the understanding of the complex in-teractions between multiple disciplines. The behaviorof each of these disciplines is usually described usingseparate software modules which have been writtenby engineers and scientists with widely different back-

∗Associate Professor, AIAA Member†PhD Candidate, AIAA Member‡Research Associate, AIAA Member§Assistant Professor, AIAA Member¶Research Scientist, AIAA Associate FellowCopyright c© 2004 by the authors. Published by the American

Institute of Aeronautics and Astronautics, Inc. with permission.

grounds. For a small subset of these problems theintegration task has been managed by highly skilledindividuals; what has often been called the “hero pro-grammer” approach. As more complex problems aretackled, this approach is not only likely to lead to highcosts and schedule delays, but it may also make it im-possible to complete the final goal. In our experience,these problems are largely due to two main reasons:the need for a thorough understanding of all of the par-ticipating modules in a large framework, and the lackof well-defined interfaces between software packagesthat force programmers to make changes to softwarethat was written by somebody else.

The ceaseless increase in computational hardwarecapability has only exacerbated this problem, as en-gineers and researchers struggle with the use and de-velopment of computer programs that have becomeincreasingly more complex in order to fully utilize theavailable computational power. The advent of paral-lel computing has only added to this complexity andtherefore, well-designed, easy-to-use software is harderto achieve.

The development of software with a well-defined in-

1 of 18

American Institute of Aeronautics and Astronautics Paper 2004–4480

terface — application program interface (API) — is acommonly used practice in software development. Infact, it is the only way in which such programs can becarried out simultaneously by a large number of pro-grammers who are responsible for different portions ofthe project. It is this fundamental idea that is beingpursued in this work: large-scale engineering projectsrequire the same high-level thought given to the overallarchitecture of the system, and proper interfaces haveto be defined so that additional flexibility is providedfor the interaction of the various software modules. Inaddition, the choice of a suitable environment for in-tegrating the modules can help achieve the proposedtasks by leveraging additional functionality that mayhave been developed for entirely different purposes.

New technologies have the potential to greatly in-crease the functionality of existing software and aid inthe development of sophisticated computational algo-rithms. Grid computing, for example, is one of thesetechnologies that provides an infrastructure for thesteering and data exchange between a set of heteroge-neous computer systems, some of which could be largeparallel computers.13 This enables the collaborationbetween different research institutions in disparate ge-ographical locations. In collaborations with industry,where proprietary software might be involved, gridcomputing provides a way of running a simulation overthe network in the company computer. The grid com-puting infrastructure also constitutes a good solutionfor steering a large simulation on parallel machines andvisualizing the results from a desktop computer in astraightforward manner. This should not be under-stood as an endorsement of the current implementa-tion of Grid ideas, but, rather, an agreement with someof the basic principles on which the Grid infrastructureis based. In our work we have made the conscious de-cision to avoid the use of the Globus Toolkit becausewe have found that it lacks functionality and perfor-mance, and it leads to an unnecessary level of overheadthat can make some of our work impossible.

Our efforts so far have focused on a frameworkfor high-fidelity aero-structural design. This frame-work combines a computational fluid dynamics (CFD)solver, a computational structural mechanics solver(CSM), and a geometry engine that comprise a pack-age for high-fidelity aero-structural analysis. In addi-tion to this, a method for coupled-sensitivity analy-sis was implemented and used in conjunction with agradient-based optimizer to develop a framework foraero-structural design optimization of aircraft.17,18

Although the framework produced the desired re-sults, successfully optimizing a supersonic business jetconfiguration, its monolithic program structure andthe exclusive use of Fortran as the programming lan-guage proved to be cumbersome when the use of differ-ent solvers or packages was required, such as a CADprogram to handle the geometry or a more sophisti-

cated structural solver.9 Moreover, new research ideasthat we are interested in pursuing involve additionaldisciplines, multi-fidelity modeling, advanced responsesurface fitting techniques, that would require extensivemodifications to the existing monolithic infrastructure.

The successful implementation of a multidisci-plinary design environment depends not just on thealgorithms for each component that comprises the air-craft or spacecraft analysis and design, but also onthe ability to provide an interface between existingcodes for straightforward coupling and scripting, mak-ing it easy to implement various multidisciplinary ap-proaches.

The need to couple analyses of different disciplinesrevealed the additional inconvenience of “gluing” andscripting different codes that have been written indifferent programming languages (Fortran 77/95, C,C++, Java.) In addition to differing in the language,these codes also have unique interfaces and data struc-tures. For example, an aeroelastic optimization codemight utilize an existing CFD code written in Fortran90/95 for the aerodynamic analysis, Nastran for thefinite-element analysis of the structure, an optimiza-tion code written in Fortran 77, and a data visualiza-tion program written in C or C++ with its own APIfor displaying the results.

Thus in order to create a flexible framework for high-fidelity aircraft design, we found it necessary to mod-ularize the existing components and redesign the waythese components are coupled. The objective is not toduplicate the efforts that produced existing analysiscodes, but rather, to generate a common interface sothat data can be exchanged between programs. Witha consistent interface, we can treat the various CFDsolvers, structural analysis, and optimization codes asmodules which can be easily combined in various ways,rearranged, and exchanged.

In an academic setting, we find the developmentof such flexible frameworks to be of paramount im-portance to our mission, since high-fidelity multi-disciplinary design environments are still in theirinfancy and fast progress in research can only beachieved if a number of different ideas can be triedin quick succession. With traditional software ap-proaches it takes a long time to implement a new idea,resulting in very slow progress. In addition, contri-butions by graduate students in our programs can bemuch more effective if they can work on pieces of largerprograms without the need for a deep understanding ofthe unimportant details of some of the software com-ponents. This has not been the case until recently, andhas hindered our research programs.

In order to create such a modular, flexible, and easyto use environment, we decided to provide an object-oriented interface to our Fortran and C software bywrapping each of the disciplines with a higher-levelprogramming language. For this purpose, we consid-

2 of 18


ered a number of programming languages and selectedPython.7 The selection of Python and its advantagesrelative to other programming languages are discussedin the next section.

Since Python is an interpreted language, it canbe used to generate interfaces between various dif-ferent modules more easily than compiling a singleexecutable out of a large number of libraries: the com-ponent modules themselves are compiled into sharedobjects and an interpreted Python script is used tojoin them.

This approach, however, still limits the ability ofa non-expert user to use a large number of modules,since that would still require the knowledge of theunique interface and data structures for each mod-ule. In this way, using Python is no different fromusing Fortran 90/95 to couple all the component li-braries together: it is simply a high-level “glue”. Withthis in mind, MDO research would not be significantlyeasier because the process of rearranging the flow ofinformation among disciplines would still be tedious.Fortunately, Python has the capability to solve thisproblem.

To accommodate the ability to utilize modules rep-resenting a wide range of disciplines (or multiple codesthat attempt to simulate the same discipline with dif-ferent methods) without overwhelming the user weabstract these modules and represent them with ob-jects that are closely tied to what they simulate: flowsolution objects, mesh objects, structural models, etc.Each code represented by a particular type of objecthas the same interface, although internally the Pythoninterface to the lower level language is unique. For ex-ample, every flow solution object representing differentflow solvers has the same interface for returning thesurface pressure. In this way modules are interchange-able and the user only needs to know one interface foreach discipline or task.

Although these are primarily computer science andinformation transfer and storage issues, they areequally important to the successful implementationof an MDO environment. The work presented inthis paper is based on a CFD code written mainlyin Fortran 90/95, with a few utility subroutines writ-ten in C, and MPI for parallel computing. This codewas wrapped using a tool that automatically builds aPython module that can access Fortran subroutinesand data. Similar procedures were carried out forthe finite element code, FEAP, written in Fortran 77;SNOPT, an optimization code also written in For-tran 77; WARP-SOLID a mesh perturbation algorithmthat uses Fortran 90/95 and incorporates FEAP, andCSM-CFD, a FORTRAN 90/95 module that handlesthe load and displacement transfers between structuraland CFD models.

In the next section we discuss the selection ofPython as the “glue” language for our framework,

and describe this language and the Python tools thatwe use. We then describe the disciplinary modulesthat are part of the framework as well as the classesthat were designed to wrap these modules. A sepa-rate section is dedicated to the aero-structural analysismodule, which represents the first multidisciplinarymodule that uses the framework components. Wethen show results of aero-structural analysis for twodifferent problems: the aero-structural analysis of asupersonic business jet at its cruise condition, andthe load transfer for an aero-structural analysis of alaunch vehicle. Finally we conclude with some remarksregarding the usability and effectiveness of this new en-vironment, and with our view of the potential futureuse of this framework.

Why Python?As mentioned in the introduction, most of our high-

fidelity analysis and optimization programs are writtenin Fortran. Large-scale scientific computing requiresthe use of a compiled language for acceptable floating-point performance, and for this reason, Fortran is thelanguage of choice for many numerical applications.

While Fortran 90/95 features such as dynamic mem-ory allocation and data structures are welcome ad-ditions (we use them extensively in our programs),Fortran lacks some of the features of other current lan-guages, such as object-oriented programming.

C++ is a powerful, object-oriented language thatcan have similar floating-point performance to For-tran. It is possible to wrap Fortran routines with C++and create an object-oriented interface, and we brieflyexperimented with this approach. However, it quicklybecame obvious that the interface would still be rela-tively difficult to learn and would not be as interactiveas we would like.

We had a similar experience with Java, since it alsorequired compilation, although only “halfway compila-tion” to machine independent bytecode. Java has expe-rienced a tremendous growth, which can be attributedto its simpler syntax for object-oriented programmingrelative to C++, as well as its platform independenceand web browser support to run applications on eitherthe client or server sides.

Modern scripting languages such as Python and Perlprovide a powerful and easy-to-use alternative to tra-ditional compiled languages. Perl is one of the mostpopular scripting languages. Python is another script-ing language that is becoming increasingly popular,with a significant following in the scientific computingcommunity. Although Perl supports object-orientedprogramming, the syntax is rather convoluted, sincePerl was designed before the advent of object-orientedprogramming.

Matlab was the only commercial alternative thatwe considered. It is in some ways similar to Python,but it is not as suitable for scripting and — at least

3 of 18


in our opinion — has a particularly bad syntax forobject-oriented programming. However, in principle,Matlab has many of the characteristics that have madeus choose Python: a straightforward to use scriptinglanguage, the ability to run modules (through MEXfiles) that execute with high performance, and porta-bility to a number of different platforms. Perhaps thebiggest shortcomings of Matlab, at the moment, arethe lack of commercial offerings for parallel computingand for distributed computing.

Python uses a concise syntax that results in pro-grams that are easy to read and has all the featuresof a modern object-oriented language without the an-noyances of a compiled language.

A variety of basic data types are available inPython: numbers (integers, floating point, complex,and unlimited-length long integers), strings (bothASCII and Unicode), and container objects (lists anddictionaries). Lists are similar to arrays, but moreflexible since they do not have a fixed size and canbe nested. A dictionary is a list whose elements areassociated to a keyword, rather than indices.

Like Matlab, Python is interpreted and can be runin interactive mode. This mode makes it easy totest short snippets of code and learn by experience.Another feature that Python shares with Matlab isdynamic typing. Variables are not declared; an assign-ment statement associates a name to an object, andthe object can be of any type. If a name is assigned toan object of one type, it may later be assigned to anobject of a different type.

Python is also strongly typed, since data types arestrictly enforced and there are no loopholes or unsafecasts. Mixing incompatible types (attempting to add astring and a number, for example) causes an exceptionto be raised. The language also supports user definedraising and catching of exceptions, resulting in cleanererror handling.

Python runs on many different computers and op-erating systems (Windows, Mac-OS, many brands ofUnix, OS/2) and provides a large standard library thatsupports many common programming tasks such asconnecting to web servers, regular expressions, and filehandling.

Perhaps a more important feature of Python is goodsupport for compiled libraries. One of the disadvan-tages of scripting languages is that they are slow com-pared to compiled programs. That is fine for smallprojects, but can be a problem for larger projects.Instead of moving the whole project to a compiledlanguage like C++ or Fortran, one can re-write justthe computationally intensive parts to compiled code.This approach results in much faster development thana compiled language alone: you get the robustnessof a scripting language with the speed of a compiledprogram. This is also a good way to utilize existingFortran subroutines without writing the whole pro-

gram in Fortran. In a later section we discuss theexisting tools for automatically wrapping codes writ-ten in Fortran, C, and C++. The existence of suchtools is a welcome addition to Python as they enablethe use, within the Python environment, of existingsoftware. This, of course requires a small amount ofdevelopment overhead to build proper interfaces andcreate the wrapping code.

Python ToolsIn addition to the useful features we just described,

Python also provides a number of tools that are veryuseful in our work. The scientific computing module,Numeric, the parallel computing module, pyMPI, andthe automatic Fortran wrapper, f2py are the threeessential tools that make Python even more attractivefor our purposes.

Scientific Computing

Numeric is a popular and powerful compiled libraryfor Python. It can provide math operations on largematrices at speeds close to those of the compiled lan-guages. For many scientific users, Numeric will fillmost of their needs without having to use Fortran orC. In fact, the power of the Numeric module is oneof the reasons Python is rapidly gaining popularity inthe scientific computing community. One can do op-erations on large arrays quickly, and with very simpleprogram syntax. In addition, Numeric includes a largenumber of common matrix operations. In this sense itmakes the use of Python very similar to Matlab.

Parallel Computing

The ability to introduce parallel computing codesinto the pyMDO framework is essential to realize thevision of a high-fidelity, integrated design environment.pyMPI is an MPI enabled Python interpreter thatprovides parallel programming support on distributedparallel machines.19 It allows the simultaneous execu-tion of Python interpreters on multiple processors andprovides an object-oriented MPI infrastructure thatenables these instances of the Python interpreter tocommunicate with each other at the interpreter level,and by the compiled code that is used by the inter-preter. In our work we use pyMPI, but most of theMPI communication calls are executed from withinthe Fortran or C programs that were using them in thefirst place, and that were wrapped to become Pythonmodules.

Wrapping Fortran with Python

As mentioned in the previous section, Python pro-vides good support for compiled libraries. Pythonitself is written in C, and extending Python to accesscode written in C and C++ is easy to do by hand andeven easier with tools, such as SWIG,10 that automatethe process.

Since it is possible to wrap Fortran programs with

4 of 18


Makefile-foo

foomodule.c

f2py

foomodule.tex

foo.pyf

bar1.f bar2.f bar3.f

Python module

foomodule.so

Fig. 1 The wrapping process with f2py.

C, we can also create libraries whose source code iswritten in Fortran, but that can be imported into thePython interpreter as a module. Doing this by handis a laborious task that is prone to errors.

Fortunately, there are automatic interface genera-tors for Fortran that require the programmer to havelittle or no knowledge of the coding details necessaryto transfer data and to call functions between Pythonand Fortran. There are two such tools: Pyfort12 andf2py.20,21

We decided to use f2py since its features are bet-ter suited to our efforts. Since f2py provides directaccess to common block and module variables, thereis no need to change the Fortran source, making thewrapping process even easier.

The way f2py works is summarized in Figure 1.Given a set of Fortran source files, f2py generatesa signature file with extension pyf that contains allinformation about the data, functions and their argu-ments in the Fortran source. This file can be editedby the user for better control, and f2py can be in-structed to just read this file, rather than generate itautomatically.

Given this signature file, f2py then creates the Ccode wrappers and compiles the final module (.so file)that can be directly imported into the Python inter-preter.

We simplified the process of wrapping Fortran pro-grams even further by developing pymdobuildutil,a utility that has a similar interface as Python’sdistutils. The developer of an extension moduleonly needs to write a file which defines various aspectsof the module and how to build it: the name or asignature file, locations of source code, and which li-braries are necessary to link. Some knowledge of howf2py works is necessary but pymdobuildutil auto-mates many of the routine tasks. This utility compilesthe Fortran source, calls f2py to create the wrappersand then compiles the Python module, all with a singlecommand.

Other tools

There are a few other Python tools that we currentlydo not use — but might be very useful in our futurework — that have also influenced our decision to usePython as the integration language.

The PYthon REsearch environment (pyre) ofAivazis8 allows for automation of complex tasks forlarge-scale parallel simulations, such as handling unitconversions, launching and monitoring jobs on clus-ters, and real time visualization of results. Recentefforts are geared to the addition of Python-based,distributed computing capability that would be veryuseful in our pyMDO framework.

There are several toolkits that aid the developmentof a graphics user interface (GUI). PyGTK is one ofthe most popular ones and is a wrapper for the GTK+library for use in Python programs.1 PyGTK handlesmany of the boring details such as managing memoryand type casting. GTK+ is a GUI toolkit for devel-oping graphical applications that run on systems suchas Linux, Windows and Mac-OS X.2

To produce scientific plots, we can use matplotlib,3 aPython 2D plotting library which produces publicationquality figures as files or in interactive GUI environ-ments, including PyGTK. There are also many otherPython interfaces to visualization tools, such as theVisualization Toolkit (VTK), and OpenDX.

Grid computing is an emerging technology that webelieve will have a useful application in our framework.The Globus Toolkit 2.4 Grid Services environment hasbeen wrapped into a Python module, the result ofwhich is pyGlobus.15

Software Design of the DisciplinaryModules

After generating Python modules for each Fortranapplication by running pymdobuildutil, we can im-port these modules into a Python program and accessthe subroutines and data that we have chosen to wrap.This interface is not very user friendly, since it is sim-ilar in form to a Fortran call and is limited by theoriginal source code.

To provide an object-oriented interface to oursolvers that is as easy to use as possible, we designedthe Python interfaces discussed in this section. Theinterfaces are conceived in such a way that each disci-pline can either be used on its own for single disciplineanalysis and optimization or be imported as a mod-ule by a higher-level class or script that performs amultidisciplinary task.

Since we are interested in performing analysis andoptimization of aircraft we have created the followingmain modules: aerodynamics, structures, geometryand mesh perturbation, and optimization.

For each of these modules, the class definitions arespecific to the discipline and are independent of theparticular solver. This means that different solvers

5 of 18


can be used for a given discipline without changingthe higher-level Python interface.

Optimization

The optimization software that we usually use isSNOPT14 a gradient-based optimizer that solves large-scale nonlinear constrained optimization problems.SNOPT uses the sequential quadratic programming(SQP) approach, which obtains the search directionsby solving a sequence of quadratic programming sub-problems.

We wrapped the SNOPT Fortran source and cre-ated a module that we called snopt. This moduleis then imported in the Optimization class and hid-den from the end user. This class is described inFigure 2, which follows the convention for unified lan-guage model (UML) class diagrams: attributes (data)are shown in the box below the name of the class,and methods (functions) are listed in the box belowthat. The line with a diamond-shaped end means thatthe Optimization contains at least an object of typeObjective, for example.

This class contains the elements that make an opti-mization problem: an objective, the design variables,and the linear and non-linear constraints. There aremultiple instances of the design variables and con-straints and they are stored in Python dictionaries.Each instance of DesignVariable represents a vectorof variables. For any optimization problem we canthen store all the design variables in one instance, butin many cases it might be convenient to separate thedesign variables into groups, especially in multidisci-plinary problems. In aero-structural optimization, wecould, for example, have one group in a member ofthe dictionary filed under the “aerodynamic” keyword,and another under “structural”. The same concept ap-plies for the dictionary of constraints.

Suppose you want to solve a simple optimizationproblem, such as

minimize A = x1x2

wrt x1, x2

subject to x21 + x2

2 = 1

To solve this problem using the optimization class,you would write the program listed below.

# load the Optimization classimport optimizationproblem = optimization.Optimization(’Max Area’,’coords’:2,’circle’: 1)# Set the starting guess for the optimization (defaults to zero)problem.variables[’coords’].value[:] = 0.01# Set the lower bounds for the design variables# (defaults are -inf and +inf respectively)problem.variables[’coords’].lower[:] = 0.# Set the lower and upper bounds for the constraintsproblem.constraints[’circle’].lower[0] = 1.problem.constraints[’circle’].upper[0] = 1.# Define the objective and constraint functions as well

def funobj(mode, x, f_obj, g_obj):f_obj[0] = x[0]*x[1]

g_obj[0] = x[1]g_obj[1] = x[0]return

def funcon(mode, njac, x, f_con, g_con):f_con[0] = x[0]**2 + x[1]**2g_con[0,0] = 2.*x[0]g_con[0,1] = 2.*x[1]return

# Run the optimizerproblem.Optimize(funobj, funcon)

Since this is a very simple example, the two de-sign variables are in one dictionary entry named coordand the constraint dictionary also has only one entry,circle, for the single constraint. The objective andconstraint functions defined by funobj and funcon arein this case very simple, but they could just as easilycall the aero-structural solver that we present herein.

At the moment we have only wrapped one optimizerbut we plan to use others. For other optimizers, re-gardless of the type that is used, we will still be able touse the Optimization class as a base class that has theattributes and functions that are common to all opti-mization problems. The various optimizers will havedifferent implementations for the functions, but the in-terface will be nearly identical. It would not be exactlythe same because while basic functions such as theOptimize function would have the same form, thereare always options specific to each optimizer. Theseoptions, however, can be handled automatically byPython as optional arguments that are implementedonly for specific optimization software.

It might also be a good idea to have two otherbase classes that inherit from the optimization baseclass: one for gradient-based optimizers and anotherfor gradient-free optimization algorithms. At the mo-ment, this is work in progress.

Aerodynamics

For aerodynamic analysis we use TFLO2000. Thissolver has been recently developed at Stanford un-der the scope of the Department of Energy’s (DoE)ASC (Advanced Simulation and Computing) program.TFLO2000 is a state-of-the-art flow solver that con-tains much of the functionality of our old, Fortran77 multiblock flow solver, FLO107-MB.22 TFLO2000contains extensions for turbomachinery applicationsneeded for the Stanford ASC project6 and includessubstantial new capabilities in the pre-processor, par-allel implementation, turbulence models, and baselinealgorithms. The numerical algorithm for the solu-tion of the mean flow equations is very similar tothat of FLO107-MB: it uses a finite-volume formu-lation, a modified Runge–Kutta scheme, a central-difference discretization augmented with artificial dis-sipation terms, and the multigrid solution procedureto enhance convergence to a steady state. A number ofimproved numerical capabilities, such as better artifi-cial dissipation schemes and low-speed preconditioningare also included in TFLO2000.

TFLO2000 incorporates a number of turbulence

6 of 18


Optimization

+num_vars: Integer

+num_constraints: Integer

+objective: Objective

+variables: DesignVariable Dictionary

+constraints: Constraint Dictionary

+Optimize(funobj:String,funcon:String)

+ReadSpecsFile(filename:String)

+CheckOption(name:String,out ivalue:Integer)

+GetInformText(out inform:String)

+GetVariables(key:String,out values:Real Array)

+GetConstraints(key:String,values:Real Array)

Objective

+name: String

+value: Real

+sensitivity: Real Array

Constraints

+name: String

+num: Integer

+values: Real Array

+lower_bounds: Integer Array

+upper_bounds: Integer Array

+sensitivity: Real Array

DesignVariables

+name: String

+num_vars: Integer

+values: Real Array

+lower_bounds: Real Array

+upper_bounds: Real Array

+optimum: Real Array

pysnopt

Fig. 2 UML diagram for the Optimization class.

models including Spalart–Allmaras, k − ω, SST, andv2 − f . The turbulence equations are solved usingthe quasi-linear form of the additional equations in asegregated fashion (from the mean flow). A DD-ADI(Diagonally-Dominant Alternating Direction Implicit)approach is used to converge the turbulence equationsand no multigrid is used for these. TFLO2000 usesa vorticity-based production term, which is differentfrom the standard production term in FLO107-MB.TFLO2000 also uses the CGNS standard for I/O pur-poses and can be run on a variety of parallel computerswith demonstrated scalability up to thousands of pro-cessors.

The Python interface to TFLO2000 is provided bya class called FlowSolution. The class was designedas a base class that can wrap any type of CFD solver.A new class, TFLOSolution inherits all the data andmethods from the superclass, but redefines and ex-tends the class in order to specialize it for the specificcase of TFLO2000. The flow solver and the additionalclass definitions are encapsulated in a module we callpytflo2000.

This is an important feature of our method for cre-ating modules: base classes are defined such that dif-ferent solvers can be interchanged for a given disciplinewithout requiring a change in the master script.

The FlowSolution contains one object: the com-putational mesh that is an object of the Mesh class.A diagram representing this hierarchy, attributes andmethods for this class is shown in Figure 3.

Methods in the flow class include those used forthe initialization of all the class components ( initfunctions, which are not shown in UML diagrams),as well as methods that write the current solution to

a file. In addition, we have added methods to thisclass that allow us to retrieve surface loads, store de-flected and perturbed surface shapes, and that canbe used to advance the flow solution for a speci-fied number of iterations. As new integrated ap-plications are constructed, additional functionality isadded to these classes (which may require modifi-cations/enhancements to the baseline Fortran 90/95code). At the time of this writing, a number of addi-tional methods were already available for these classes.

Structures

The structural analysis program we use is the Fi-nite Element Analysis Program (FEAP), written byProf. Taylor at UC Berkeley,25 and is a general pur-pose finite-element package for the analysis of com-plex structures. The program includes the capabilityto construct arbitrarily complex finite-element modelsusing a library of one-, two-, and three-dimensionalelements for linear and nonlinear deformations. In ad-dition, a number of material models (such as isotropic,orthotropic, plasticity) are available to model the con-stitutive properties of the materials that are present inthe structure. Once the model is assembled, a numberof solution procedures are available for linear, nonlin-ear, and time-accurate problems. In addition, for verylarge nonlinear structural models, interfaces are avail-able for external parallel sparse solvers that can greatlyimprove the calculation turnaround times. A numberof advanced time-accurate integration algorithms arealso included with FEAP, which are of interest in thecomputation of aeroelastic responses and constraints.

The general class that we created for structuralanalysis is Structure. As detailed in Figure 4, aStructure object contains a Mesh and a dictionary of

7 of 18


FlowSolution

+mesh: Mesh

+GetSurfaceCoordinates()

+GetSurfaceLoads()

+RunIterations(num_cycles:Integer)

+WriteCGNSFile(filename:String)

+GetConvergenceHistory(name:String)

Mesh

+

+GetSurfaceCoordinates(family:String)

+GetSurfaceIndices(family:String)

+WriteMeshFile(filename:String)

+SetCoordinates(blocks:Integer Array,ranges:Integer Array,xyz:Real Array)

+GetNumberBlocks()

+GetFamilyNames()

+GetFilename(out filename:String)

Fig. 3 UML diagram for the FlowSolution class.

Structure

+num_nodes: Integer

+num_dofs: Integer

+num_elems: Integer

+mesh: Mesh

+load_cases: LoadCase Dictionary

+SolveDisplacements(load_case:String)

+ComputeStresses(load_case:String)

+GetSurface()

+SetLoads(load_case:String)

+GetPoint()

+GetTransferWeights()

+ComputeWeight()

+Write()

+GetdWdx()

LoadCase

+displacements: Real Array

+stresses: Real Array

+forces: Real Array

+KS: Real

+adjoint: Real Array

+SetLoads()

+SetDisplacements()

Mesh

+coordinates: Real Array

+connections: Integer Array

+Write()

DesignVariables

+value: Real Array

+scale: Real Array

+gradient: Real Array

+Set()

+SetScale()

Fig. 4 UML diagram for the Structure class.

LoadCase objects. As we mentioned before, Pythonsupports dictionaries, which are lists of objects of anytype, each of which is associated with a keyword. Thisenables us to handle multiple load conditions, and re-fer to them as “cruise” or “maneuver”, for example.For each load case, the displacement field, the stressesand the loads are stored in the LoadCase class. Thisis a capability that the underlying Fortran code doesnot have.

The functions provided by the Structure class arewhat one would expect from a structural analysis pro-gram: solve the displacements, compute the stresses,and set loads. There are also functions that are neededfor aero-structural coupling, such as getting the surfaceof the finite-element mesh, and the transfer weights.

Other data and functions are design oriented. Themain class contains design variables and provides afunction that computes gradients with respect to thosedesign variables using an adjoint method. Each loadcase contains the corresponding adjoint vector and sen-sitivity of stresses with respect to the design variables.

Geometry

The aircraft is surrounded by fluid which is sep-arated from the structure by the fluid-structure in-terface. Therefore, there is a well-defined surface inthree-dimensional space which constitutes the outer-mold line (OML). This surface is not only importantfor aero-structural analysis but for design optimizationas well, since some of the design variables we use are

perturbations to the OML.Because of the importance of the OML, a separate

utility, Aerosurf, is used to generate and manage it.Aerosurf was specifically created for the analysis anddesign of aircraft configurations17,23

The baseline geometry of an aircraft configuration isgiven to Aerosurf in the form of separate components,each one being described by a series of point-wise cross-sections. These components can be fuselages, pylons,nacelles, and wing-like surfaces. An example of thesesurfaces for the Raytheon Premier I business jet isshown in Figure 5.

After lofting the sections that define each compo-nent using a bi-cubic spline method, Aerosurf inter-sects these components and divides the resulting sur-face into a series of patches. At this stage, Aerosurfcreates a parametric description of each patch andthen distributes points on their surface, forming a finestructured watertight mesh. Thus, the set of pointsformed by the grids of all patches represents a water-tight discretization of the OML within Aerosurf. Theintersected geometry is shown in Figure 6.

In addition to providing a high-fidelity descriptionof the aircraft geometry, Aerosurf also has a role inthe aero-structural analysis and design. During anal-ysis, any information that needs to be exchangedthrough the fluid-structure interface — such as aero-dynamic pressures and structural displacements — isinterpolated onto the OML points. Changes in theOML shape can be due to either structural displace-

8 of 18


Fig. 5 Un-intersected components of a transonicbusiness jet configuration.

Fig. 6 Intersected components forming theouter-mold line (OML).

ments during aero-structural analysis or changes inshape design variables between design cycles. Whilethe OML changes due to structural displacementsare transferred directly to the OML points, changesdue to shape design variables are applied to the un-intersected components first and then these compo-nents are re-intersected, creating a new discretizedrepresentation of the OML.

The Geometry class provides the data and function-ality of Aerosurf. It contains both the original un-intersected surfaces each formed by a list of sections,as well as the parametric description of the aircraftsurface. The main functions provided by this class arethe generation of the patches and perturbation of thethe geometry. The class that defines the OML designvariables is a specialization of the DesignVariablesclass.

Note the dual role of Aerosurf: on the one hand itserves as the engine for the parametric modificationof a baseline geometry (to be used for design pur-poses), while, on the other, it is a home-built CADengine that takes care of constructing geometry fromun-intersected components.

We are also exploring another option for the han-dling of the modifications to the OML using a trueCAD-based geometry engine. A direct interface to aCAD package is not easy to accomplish. It also repre-sents a large investment in a CAD package that maylater turn out to not provide all of the design func-tionality that is required for MDO. For this reason,we decided to use the CAPRI interface of Haimes,4

which allows for the development of CAD-neutral in-terfaces. Again, once we have this new geometryengine in place, we can use a specialization of theGeometry class to wrap this. In fact, the user doesnot need to know which underlying geometry engine(home-built or CAD-based) is being used at the time.Control over this choice is exercised by importing theappropriate geometry module into the Python class.

Although the interface to the user is identical, theunderlying infrastructure is not. In particular, theway in which our traditional Aerosurf package and theCAD-based one handle their two roles (shape parame-terization and geometry intersection) is quite different.Once again, this is one of the major advantages of con-structing classes in Python that shield the user fromthe specific details of an implementation.

Visualization

For the visualization of our multidisciplinary anal-yses and design results we mostly use OpenDX, apowerful software package for the visualization of sci-entific and engineering data.5,24 OpenDX is the opensource version of the former IBM product Visualiza-tion Data Explorer.

This software is very flexible because it can be eas-ily programmed by connecting blocks in a GUI thatshow the processing of the data and images from theraw data file to the final image. The images shownin the results section are all produced with OpenDX.Although OpenDX can read any type of data file byusing the right options and blocks, it reads data filesin DX native format without need for translation.

To facilitate the writing of DX data files, we createda Python module that defines the classes shown in Fig-ure 8. The object-oriented design follows the structureof the DX format closely: a DX file may contain sev-eral fields, each of which has a number of positions,and might have data associated with positions or con-nections. The positions might be connected or not,and the connections might be regular or irregular.

Multi-block Mesh Perturbation

For both aero-structural analysis and design appli-cations, the need arises to construct deformed meshesthat conform to the actual shape of the OML at ev-ery point in a calculation. Given that our flow solver,TFLO2000, uses body-fitted multi-block meshes, and

9 of 18


Geometry

+num_surf: Integer

+surface: Surface Dictionary

+num_patches: Integer

+patches: Patch List

+des_vars: OMLDesignVariables

+GeneratePatches()

+Perturb()

Patch

+num_i: Integer

+num_j: Integer


Surface

+num_sections: Integer

+sections: Section List

Section

+num_points: Integer

+coordinate: Real Array

OMLVariables

Fig. 7 UML diagram for the Geometry class.

DXFile

+fields: Field Dictionary

+Write()

+AddField()

Field

+name: String

+positions: Positions

+connections: Connections

+data: Data

+Write(file_name:String)

Positions


+num: Integer

+Write(file:File)

Connections

+name: String

+type: String = regular_2D, regular_3D, lines, triangles, quads

+is_regular: Logical

+Write(file:File)

Data

+name: String

+num: Integer

+values: Real Array

+dependency: String

+Write(file:File)

Fig. 8 UML diagram for the DXFile class.

that these meshes have to be constructed by hand(with the aid of mesh generation software such asPointwise’s Gridgen), it becomes infeasible to regen-erate these meshes from scratch every time that asurface perturbation is desired. For several years wehave been working on an inexpensive yet robust meshperturbation procedure that can generate, automati-cally, perturbed meshes given both a perturbed surfacegeometry (e.g the deformed shape of a wing) and abaseline mesh of reasonable quality for the undeformedgeometry. In the past we have developed an algorithmcalled WARP-MB,22,23 that is based on fast algebraicmethods. WARP-MB is a multi-block wrapper on theWARPBLK program that carries out the deformationof a single block in a multi-block mesh.

WARPBLK is quite robust ad produces high-qualitymeshes, even for very large perturbations of the ini-tial geometry. WARPBLK has been used extensivelyin the past for both Euler and Navier–Stokes meshes.Given a structured, body-fitted block, WARPBLK re-quires as inputs the geometry of the initial block andthe perturbations to the mesh points that lie on theexternal surfaces of the block. Some or all of these

surface points can be provided to WARPBLK. If onlysome of the deformed surface points are provided,WARPBLK uses quasi-1D and quasi-2D versions ofthe warping algorithm to construct the deformed sur-face of the block. Then, the full three-dimensionalversion of WARPBLK perturbs the mesh in the inte-rior of the block to achieve its final result.

WARPBLK is quite robust since it simplifies to arigid body rotation/translation of the mesh in situ-ations where rigid body motions are applied to thesurface of the block. In addition, as the mesh deforms,the relative mesh spacings of the baseline mesh arepreserved. This feature avoids problems with crossededges in boundary layer meshes.

In a multi-block setting, the implementation ofWARPBLK and WARP-MB has been named pywarp.It is a complete re-write of our old version and it onlyre-uses the WARPBLK procedure. There is a short-coming of pywarp: we typically allow the surface of theobject (a wing, for example) being modeled to move,while we fix the external boundaries of the mesh blockthat come in contact with the object. For this rea-son, if the displacements of the surface of the object

10 of 18


exceed the physical dimensions of the block, WARP-MB is unable to produce a mesh without negativevolumes. This has catastrophic consequences for anaero-structural simulation, since the flow solver willstop abruptly.

An alternative that has been advanced in the litera-ture is the solution of a pseudo-structural problem forthe mesh deformation problem.16 In this approach,every cell in the mesh is replaced by a solid structuralelement. Displacements are applied, as required bythe problem, to the appropriate nodes on the surfaceof this pseudo-structural mesh and then, through thesolution of an elasticity problem, the motion of all ofthe nodes in the mesh can be computed. The stiffnessof each of the elements in the mesh can be changedaccording to the distance from the moving surface inorder to prevent the mesh from crossing. In principle,this is a generalization of the spring analogy that isoften used for mesh deformation.

Although this is a very useful approach, the cost ofmesh perturbation can become quite large as the num-ber of cells in the mesh grows. This is particularly trueof complete configuration viscous meshes with millionsof cells, for which the mesh perturbation problem canbecome more expensive than the actual flow solutionproblem.

In order to avoid this high computational cost, wehave re-written pywarp to introduce a hybrid, pseudo-structural model concept. Instead of modeling eachcell in the mesh as a solid structural model, we havechosen to model each block of a multiblock mesh as asolid element. After solving a small elasticity problem(with a number of elements that is equal to the numberof blocks in the mesh (say, from 200 to 1000), ratherthan to the number of cells in the mesh (up to 106) weapply the WARPBLK procedure to each of the blocksin turn. In this way we can accommodate very largedisplacements, but, at the same time, we are able toproduce perturbed meshes at very low computationalcost. pywarp-solid, the new Python module that wehave created is therefore used in our aero-structuralwork.

Figures 18 and 19 below show the differences be-tween the perturbed meshes produced by pywarp andpywarp-solid for an outboard section of the wing of asupersonic business jet. The addition of the pseudo-structural elasticity problem can generate much higherquality meshes, especially for large displacements.

Aero-Structural Analysis andOptimization Framework

Having the long term goal of performing high-fidelity aircraft design, we have been first focusingon aero-structural optimization of aircraft configura-tions. To this end we had developed a framework thatwas programmed solely in Fortran. This frameworkincluded not only analysis, but also design optimiza-

tion, and featured a coupled-adjoint for computinggradients with respect to hundreds of variables veryefficiently.17,18

We now aim to build the same type of capability,now using the disciplinary modules described in theprevious section, and having the higher-level programswritten in Python, such that the framework is moreeasily reconfigured and re-used.

In aero-structural analysis, there is a clear interde-pendence between the equilibrium state of the twosystems: the flow solution depends on deflectionscalculated by the structures, and the structural so-lution depends on the loads calculated by the flowsolver. There are three important aspects of the high-fidelity coupling between the aerodynamic and struc-tural analyses: the OML and the transfer of loads anddisplacements. We have already described Aerosurf,the geometry engine that handles the OML. We nowdetail the procedures for transferring of displacementsand loads, which are based on work by Brown.11

Displacement Transfer

The displacements calculated by the structuralsolver are first transferred onto the OML grid, andthen onto the CFD surface mesh. Each OML pointis associated with a point on the surface of the finite-element model in a pre-processing step, as shown inFigure 9. The association is performed by locating thepoint on the structural model surface that is closest toeach OML point.

��

��

��

� �

rigid link

associated point

OML point

Fig. 9 Displacement extrapolation procedure.

During aero-structural analyses, the displacementof each associated point is computed by interpolatingthe node displacements of the element containing thatpoint. The displacement is then transferred onto theOML point using extrapolation functions that emulatea rigid link between the OML point and the associatedpoint on the surface of the structural model. For smallangular deflections we use the linear relationship

∆x = Nu, (1)

where N is a matrix of transfer weights and u is thevector of structural displacements.

Unlike the structural nodes, the CFD surface meshpoints are assumed to exist on the OML. Figure 10shows a representation of both the OML and CFDmeshes. The parametric coordinates of the CFD sur-face mesh points on the corresponding OML patches

11 of 18


v

u

CFD mesh point

OML point

Fig. 10 OML and CFD surface meshes on an Aero-surf patch.

are calculated in a pre-processing step via closest pointprojection. Therefore the patch number and the para-metric coordinates of the associated point uniquelydefine the transfer operator. The CFD points are as-sumed to be “tied” to these parametric locations andany displacement of the OML, due to either designvariable perturbations or structural displacements, istransferred to the CFD surface mesh points by evalu-ating their parametric locations on the correspondingAerosurf patches.

Once a perturbation is applied to the surface ofthe CFD mesh, it must be propagated throughout thewhole multiblock mesh. This volume mesh perturba-tion is achieved very efficiently by using WARP-MB.

Load Transfer

The load transfer procedure is responsible for trans-ferring the pressures calculated by the CFD algorithmto the structural nodes through the OML points.

In order to transfer the aerodynamic loads from theCFD surface mesh to the OML points, we first inte-grate the pressures in the CFD mesh to obtain a forcevector for each CFD surface node. We then identify, ina pre-processing step, the appropriate “donor cell” andthe parametric location of each OML point within thiscell. The forces at the OML points are then calculatedusing bilinear interpolation. The underlying assump-tion that ensures the accuracy of this simple transfer isthat the OML mesh is of comparable or higher fidelitythan that of the CFD surface mesh, and that the twosurface representations are consistent and contiguous.

In translating interpolated loads from the OML sur-face into finite-element forces, it is crucial that bothconsistency and conservation be maintained. Theproperty of consistency specifies that the resultantforces and moments due to the forces on the CFDsurface mesh, must be equal to the sum of the nodalforces and moments applied to the structural model.There are an infinite number of structural load vectorsthat satisfy this requirement. However, we also requirethat the load transfer be conservative. Conservationstipulates that the virtual work performed by the loadvector, fS , undergoing a virtual displacement of thestructural model, δuS , must be equal to the work per-formed by the CFD forces, undergoing the equivalentdisplacement of the OML mesh, δx. The virtual work

��

��

�

OML mesh

CSM mesh

Fig. 11 Transfer of the pressure on the OML pointsto the finite-element nodal forces

in the finite-element model is given by the dot product

δWS = fSδu, (2)

while the virtual work performed by the fluid actingon the surface of the OML mesh is given by

δWA = fAδx (3)

For a conservative scheme, δWA = δWS, and a consis-tent and conservative load vector then is given by

fA = NT fS (4)

where we used the linear relationship (1) for the virtualdisplacements δx. In Figure 11 we can see how thepressure field (which has been interpolated from theCFD mesh to the points on the OML) is integratedover an OML patch to produce a force vector thatis translated into the nodal forces of a finite elementusing equation (4).

As previously, the transfer matrix N is calculatedin a pre-processing step. This matrix plays a dualrole: it provides the appropriate weighting factors forboth the transfer of OML pressures to structural loadvectors (4) and the transfer of the structural displace-ments to OML point displacement (1).

Both the displacement and load transfer proceduresdescribed in this section have been implemented intoa Python module called pycfd-csm. The associationbetween the CFD surface mesh and the OML is con-tained in this module; in our past work it used to beperformed by a separate Fortran program called uv-map. The reconfigurability of the new Python modulesallows for the reuse of code that is used for similar,though different, purposes.

Aero-Structural Iteration

The aerodynamic and structural solvers are coupledby exchanging information at regular intervals during

12 of 18


CFD

CSM

Load transfe

r

Dis

pla

cem

ent t

ran

sfer

� ��

� ��

��

1

2

35

4

��

Fig. 12 The aero-structural iteration procedure.

the convergence process. This coupling is greatly sim-plified by the fact that, in this work, we only considerstatic aero-structural solutions, and hence time accu-racy is not an issue.

A diagram representing the aero-structural iterationis shown in Figure 12. The first time the flow solveris called, the displacement field of the structure is ini-tialized to zero. After N iterations of the flow solver,the surface pressures are translated into nodal forcesand the structural solver is called.

We usually do not update the displacements basedon the latest displacement field alone, since this oftenleads to oscillations of the structure which delay theconvergence of the aero-structural system. To preventthis, we use under-relaxation, which uses both the lat-est displacements field and the previous one, and canbe written as

u+ = u− + β(u− u−

), (5)

where β is the under-relaxation factor.The new displacement field is then translated to a

movement of the CFD mesh and N more flow solveriterations are performed. The process continues untilthe state of the flow and the structure have convergedas determined by the norm of the flow solver and struc-tural displacement residuals. In our case, N typicallycorresponds to 10 iterations.

Python Module

The aero-structural analysis module represents thefirst multidisciplinary application that uses the mod-ules described in the previous section. This moduledoes not wrap any Fortran code and is implementedpurely in Python.

The Aerostructure class, whose diagram is shownin Figure 13 represents the aero-structural analysisand contains a Geometry, a FlowSolution and aStructure. In addition, the class defines all the func-tions that are necessary to translate aerodynamic loadsto structural loads and structural displacements to ge-ometry surface deformations.

One of the main methods of this class is the onethat solves the aero-structural system. This methodis called once for each iteration, several of which areneeded to obtain an aero-structurally converged sys-tem. Within this method, self refers to an object ofthe Aerostructure class. This method is summarizedbelow:

Fig. 14 CFD mesh for the supersonic jet.

def RunIterations(self, num_iterations):self.flow.RunIterations(10)cfd_loads = self.flow.GetSurfaceLoads(’Wing’)csm_loads = self.TransferLoads(cfd_loads)self.structure.SetLoads(’test’, csm_loads)self.structure.CalculateDisplacements(’test’)csm_dispts = self.structure.load_cases[’test’].surf_displacementscfd_dispts = self.TransferDisplacements(csm_dispts)# Warp the mesh and pass the new coordinates to TFLOijk_blnum = self.flow.GetMesh().GetSurfaceIndices(’Wing’)cfd_xyz = self.xyz_wing_orig + cfd_disptsself.meshwarping.Warp(cfd_xyz, ijk_blnum[3,:], ijk_blnum[0:3,:])for n in range(1,self.flow.GetMesh().GetNumberBlocks()+1):

# Get the new coordinates from warp[blocknum,ijkrange,xyz_new] = self.meshwarping.GetCoordinates(n)blocknum = self.comm_world.bcast(blocknum)ijkrange = self.comm_world.bcast(ijkrange)xyz_new = self.comm_world.bcast(xyz_new)# Give them to TFLOself.flow.GetMesh().SetCoordinates(blocknum,ijkrange,xyz_new)

return

This is a very readable script, thanks to the cleansyntax of Python, and any high-level changes to thesolution procedure can be easily implemented. TheAerostructure class also contains methods that ex-port all the information of the current solution forvisualization, examples of which are shown in the nextsection.

Aero-Structural Analysis ResultsSupersonic Business Jet

One of the first test cases for our new framework isa supersonic business jet with cruise Mach number ofM = 1.5. The wing is the only surface that deflectsin this model. In Figure 22 we show the external ge-ometry of the configuration and the structural box ofthe wing. The skin, spars and ribs of this structureare modeled with plate finite elements that includerotational degrees of freedom and the spar caps aremodeled by frame elements.

The CFD grid, shown in Figure 14, is a point-to-point matched mesh with 234 blocks and a total ofapproximately 2.1 million nodes. For our calculations,this fine mesh was coarsened to one eight of its size.Calculations are run for a target CL = 0.1 at an alti-tude of 55,000 ft. This can be run with TFLO on anynumber of processors.

Figure 15 shows the association of the wing sur-face points with the structural surface. All links are

13 of 18


Aerostructure+flow: FlowSolution

+structure: Structure

+geometry: Geometry

+RunIterations(num_iterations)

+TransferDisplacements()

+TransferLoads()

-ComputeTransferWeights()

-CheckForceConsistency()

-CheckForceConservancy()

Geometry

Structure

FlowSolution

Fig. 13 UML diagram for the Aerostructure class.

Fig. 15 Association of the OML points to the surface of the structural model.

14 of 18


Fig. 16 Aerodynamic loads transferred to thestructural nodes.

perpendicular to the structural surface since they rep-resent the minimum distance between the two surfaces.As previously mentioned, these links will remain per-pendicular to the structural surface and will undergorigid body rotation in order to transfer the structuraldisplacements to the aircraft surface.

The result of the force transfer is shown in Figure 16.The forces at the leading and trailing edges are par-ticularly high due to the large non-structural surfacesthat lie ahead and behind the wing. At a given span-wise location, these large forces also produce a momentin the direction parallel to the front and rear of thewing box, again due to the aerodynamic loads on thenon-structural surfaces.

To evaluate the consistency between the forces onthe flow mesh and the loads on the structural nodeswe computed the L2 norms of the variations betweenthe two for both the forces and the resulting moments.These L2 norms were O

(10−9

)and O

(10−7

), respec-

tively. We also verified conservancy, noting that thework done by the flow forces matches the work doneby the structural loads to 12 significant digits.

The density residual of the flow during the aero-structural solution is plotted in Figure 20. The jumpsin the residual correspond to the wing displacementupdates. As expected, under-relaxation significantlyaccelerated the convergence of the aero-structural so-lution. For the under-relaxed case we used β = 0.25in the update (5).

We also show the maximum displacement of thewing for each aero-structural update, which alwaysoccurred at the wing tip in Figure 21. The benefitof using under-relaxation is obvious, as it eliminatesany oscillations of the wing during the aero-structuraliteration.

0 50 100 150 200 250 300 350 400 450−14

−12

−10

−8

−6

−4

−2

0

Multigrid Iterations

log(

Res

idua

l)

Under−relaxation factor 0.25No under−relaxation

Fig. 20 Residual history for the flow solver, withand without under-relaxation of the displacementtransfer.

5 10 15 20 25 300

0.2

0.4

0.6

0.8

1

Aero−structural Iterations

Max

imum

dis

plac

emen

t

Under−relaxation factor 0.25No under−relaxation

Fig. 21 Maximum displacement for each update,with and without under-relaxation.

The converged aero-structural solution of the super-sonic business jet is shown in Figure 22. The structureitself is not optimized and therefore exhibits a largerange of stresses.

As is typical of swept-back wings, the tip twistsdown under aerodynamic load because these are pre-dominantly positioned downstream of the flexural axisof the wing box.

Launch Vehicle

We now discuss the use of several of the modulespresented in previous sections to aid in the design ofa generic launch vehicle configuration. In the processof developing the tools described earlier, the opportu-nity arose to use them in order to compute flow andstructural solutions and to provide load scenarios fora generic launch vehicle geometry. This test case notonly provided an additional opportunity to test theversatility of the Python environment just described,

15 of 18


Fig. 17 Undeflected outboardsection of the supersonic jet.

Fig. 18 Mesh perturbed withpywarp.

Fig. 19 Mesh perturbed withpywarp-solid.

Fig. 22 Aero-structural solution for the supersonic business jet.

16 of 18


but it also provided us with the opportunity to debugand refine our tools in a situation that is rather differ-ent from the usual aircraft test cases that we are usedto dealing with.

In the design of launch vehicles (as is the case inthe aircraft industry) it is common practice to trans-fer the distributed loads on the surface of the vehicleto a “stick” model which runs along the axis of sym-metry of the vehicle and has the lumped mass andstiffness properties of the true vehicle. During thisprocess, valuable information about the distributionof the surface loads is lost. Given that the use of rel-atively simple finite element models of the structureis also commonplace in the industry, we decided totransfer the distributed pressure load from a viscousCFD calculation to the nodes in the structural finiteelement model. The task was assigned to a studentwho had no previous experience in CFD, structural fi-nite element modeling, or the Python language. In theshort span of about a week, the student was able togenerate structural models for the rocket, CFD solu-tions for the external flow, and a simple Python script(based on previous examples that existed in the lab)to transfer the distributed CFD surface loads conserva-tively and consistently to the surface of the CSM mesh.This exercise in managing complexity showcases thefeatures of the pyMDO framework that we wanted tohighlight: code/module reusability, quick turnaroundfor new applications, and the ability to contribute tolarge integration projects by taking off-the-shelf soft-ware components and adding new capabilities that canbe reused by others.

Figure 24 shows the structural model for the launchvehicle. The surface elements have been made semi-transparent to show the internal structure of the halfdomes for the fuel and oxidizer tanks. This structuralmodel is typical of the size that would be used in cal-culations. Figure 23 shows the result of a typical CFDcalculation around the surface of the vehicle for a freestream Mach number of 1.365 and an angle of attackof 10 degrees. Finally, Figure 25 shows several viewsof the surface loads of the CFD computation acting onthe structural mesh. These figures are simply repre-sentative of the kinds of results that can be obtainedwith a 20-line Python script.

ConclusionsThe modularization of solvers and optimizer has al-

ready proven to be extremely useful even at the singlediscipline level. Wrapping the modules with Pythonwas also invaluable as it enabled us to setup an aero-structural analysis with a short, readable script.

We presented results for aero-structural analysis andverified the consistency and conservancy of the loadtransfers. The new mesh warping procedure showedthat it can handle wing tip displacements of up to10% of the semi-span.

Fig. 23 CFD mesh for the launch vehicle.

Fig. 24 Structural model for the launch vehicle.

Fig. 25 Detail of the aerodynamic loads on thelaunch vehicle.

To achieve the goal of having the design optimiza-tion capability that we developed in the past in ournew framework we are currently developing modulesfor sensitivity analysis and extending the Python mainscript to compute coupled-adjoint gradients.

The new framework facilitates the interchangeabil-ity of different solvers for the same discipline as well asthe addition of new disciplines. It will be much easierto add other crucial modules such as mission analy-sis and aircraft weight estimates, and to try differentMDO architectures.

We also plan to extend this framework to handledistributed computing environments, which we expectwill drastically increase the complexity of the aircraftdesign problems that we can solve.

17 of 18


AcknowledgmentsAlonso, LeGresley and van der Weide would like to

acknowledge the support of the Department of En-ergy’s ASC project. All of the authors would liketo acknowledge the support from the NASA Lang-ley Research Center for research in supersonic design,which has had a significant impact in the conceptionof this framework. Martins is grateful for the supportof the Canada Research Chairs program and NSERC.Finally, we would also like to acknowledge the contri-butions of Pradipta Sahu and Thomas Taylor.

References1http://www.pygtk.org.2http://www.gtk.org.3http://matplotlib.sourceforge.net.4http://raphael.mit.edu/capri.5http://www.opendx.org.6Annual ASCI Report. http://cits.stanford.edu.7Python. http://www.python.org.8M. Aivazis. Pyre: An Integration Architecture.

http://www.cacr.caltech.edu/projects/geoframe/index.html.9J. J. Alonso, J. R. R. A. Martins, J. J. Reuther, and

R. Haimes. High-Fidelity Aero-Structural Design Using a Para-metric CAD-Based Model. AIAA Paper 2003-3429, June 2003.

10D. Beazley. SWIG (Simplified Wrapper and Interface Gen-erator). http://www.swig.org.

11S. A. Brown. Displacement Extrapolation for CFD+CSMAeroelastic Analysis. AIAA Paper 97-1090, Jan. 1997.

12P. Dubois. Pyfort Reference Manual. Programfor Climate Model Diagnosis and Intercomparison,Lawrence Livermore National Laboratory, August 2000.http://sourceforge.net/projects/pyfortran.

13I. Foster, C. Kesselman, and S. Tuecke. The Anatomy of theGrid: Enabling Scalable Virtual Organizations. International J.Supercomputer Applications, 15(3), 2001.

14P. E. Gill, W. Murray, M. A. Saunders, and M. H. Wright.User’s Guide for SNOPT 5.3: A Fortran Package for Large-scale Nonlinear Programming. Systems Optimization Labora-tory, Stanford University, California, 94305-4023, Dec. 1998.Technical Report SOL 98-1.

15K. Jackson. pyGlobus. http://www-itg.lbl.gov/gtg/projects/pyGlobus.

16E. Lund, H. MA ller, and L. A. Jakobsen. Shape DesignOptimization of Stationary Fluid-Structure Interaction Prob-lems with Large Displacements and Turbulence. Structural andMultidisciplinary Optimization, 25(5/6):383–392, 2003.

17J. R. R. A. Martins. A Coupled-Adjoint Method for High-Fidelity Aero-Structural Optimization. PhD thesis, StanfordUniversity, Stanford, California, Oct. 2002.

18J. R. R. A. Martins, J. J. Alonso, and J. J. Reuther. High-Fidelity Aerostructural Design Optimization of a SupersonicBusiness Jet. Journal of Aircraft, 41(3):523–530, 2004.

19P. Miller. pyMPI. http://sourceforge.net/projects/pympi.20P. Peterson. f2py Fortran to Python Interface Generator,

December 2000. http://cens.ioc.ee/projects/f2py2e/.21P. Peterson, J. R. R. A. Martins, and J. J. Alonso. Fortran

to Python Interface Generator with an Application to AerospaceEngineering. In Proceedings of the 9th International PythonConference, Long Beach, CA, Mar. 2001.

22J. Reuther, J. J. Alonso, A. Jameson, M. Rimlinger, andD. Saunders. Constrained Multipoint Aerodynamic Shape Opti-mization Using an Adjoint Formulation and Parallel Computers:Part I. Journal of Aircraft, 36(1):51–60, 1999.

23J. Reuther, J. J. Alonso, A. Jameson, M. Rimlinger, andD. Saunders. Constrained Multipoint Aerodynamic Shape Opti-mization Using an Adjoint Formulation and Parallel Computers:Part II. Journal of Aircraft, 36(1):61–74, 1999.

24VIS, Inc. OpenDX Paths to Visualization, 2000.25O. C. Zienkiewicz and R. L. Taylor. The Finite Element

Method, 5th Edition, Vol. I. Butterworth-Heinemann, 2000.

18 of 18


aiaa 2004–4480 - stanford universityaero-comlab.stanford.edu/papers/alonso.aiaa.04-4480.pdf ·...

Documents