NASA/TM–2014–218520

FUN3D Manual: 12.5

Robert T. Biedron, Joseph M. Derlaga, Peter A. Gnoffo, Dana P. Hammond,

William T. Jones, Bil Kleb, Elizabeth M. Lee-Rausch, Eric J. Nielsen, Michael A. Park,

Christopher L. Rumsey, James L. Thomas, and William A. Wood

Langley Research Center

Hampton, Virginia 23681

September 2014
NASA STI Program . . . in Profile

Since its founding, NASA has been dedicated

to the advancement of aeronautics and space

science. The NASA scientific and technical

information (STI) program plays a key part

in helping NASA maintain this important

role.

The NASA STI Program operates under the

auspices of the Agency Chief Information

Officer. It collects, organizes, provides for

archiving, and disseminates NASA’s STI.

The NASA STI Program provides access to

the NASA Aeronautics and Space Database

and its public interface, the NASA Technical

Report Server, thus providing one of the

largest collection of aeronautical and space

science STI in the world. Results are

published in both non-NASA channels and

by NASA in the NASA STI Report Series,

which includes the following report types:

• TECHNICAL PUBLICATION. Reports of

completed research or a major significant

phase of research that present the results

of NASA programs and include extensive

data or theoretical analysis. Includes

compilations of significant scientific and

technical data and information deemed to

be of continuing reference value. NASA

counterpart of peer-reviewed formal

professional papers, but having less

stringent limitations on manuscript length

and extent of graphic presentations.

• TECHNICAL MEMORANDUM.

Scientific and technical findings that are

preliminary or of specialized interest, e.g.,

quick release reports, working papers, and

bibliographies that contain minimal

annotation. Does not contain extensive

analysis.

• CONTRACTOR REPORT. Scientific and

technical findings by NASA-sponsored

contractors and grantees.

• CONFERENCE PUBLICATION.

Collected papers from scientific and

technical conferences, symposia, seminars,

or other meetings sponsored or

co-sponsored by NASA.

• SPECIAL PUBLICATION. Scientific,

technical, or historical information from

NASA programs, projects, and missions,

often concerned with subjects having

substantial public interest.

• TECHNICAL TRANSLATION. Englishlanguage translations of foreign scientific

and technical material pertinent to

NASA’s mission.

Specialized services also include creating

custom thesauri, building customized

databases, and organizing and publishing

research results.

For more information about the NASA STI

Program, see the following:

• Access the NASA STI program home page

at http://www.sti.nasa.gov

• E-mail your question via the Internet to

help@sti.nasa.gov

• Fax your question to the NASA STI

Help Desk at 443-757-5803

• Phone the NASA STI Help Desk at

443-757-5802

• Write to:

NASA STI Help Desk

NASA Center for AeroSpace

Information

7115 Standard Drive

Hanover, MD 21076–1320
NASA/TM–2014–218520

FUN3D Manual: 12.5

Robert T. Biedron, Joseph M. Derlaga, Peter A. Gnoffo, Dana P. Hammond,

William T. Jones, Bil Kleb, Elizabeth M. Lee-Rausch, Eric J. Nielsen, Michael A. Park,

Christopher L. Rumsey, James L. Thomas, and William A. Wood

Langley Research Center

Hampton, Virginia 23681

National Aeronautics and

Space Administration

Langley Research Center

Hampton, Virginia 23681

September 2014
The use of trademarks or names of manufacturers in this report is for accurate reporting and does not

constitute an offical endorsement, either expressed or implied, of such products or manufacturers by the

National Aeronautics and Space Administration.

Available from:

NASA Center for AeroSpace Information

7115 Standard Drive

Hanover, MD 21076-1320

443-757-5802
Abstract

This manual describes the installation and execution of FUN3D version 12.5,

including optional dependent packages. FUN3D is a suite of computational

fluid dynamics simulation and design tools that uses mixed-element unstructured grids in a large number of formats, including structured multiblock

and overset grid systems. A discretely-exact adjoint solver enables efficient

gradient-based design and grid adaptation to reduce estimated discretization

error. FUN3D is available with and without a reacting, real-gas capability.

This generic gas option is available only for those persons that qualify for its

beta release status.

1
2 

THIS PAGE INTENTIONALLY LEFT BLANK 
Contents

About this Document 9

Acknowledgments 10

Quick Start 11

1 Introduction 15

1.1 Primary Capabilities and Features . . . . . . . . . . . . . . . . 15

1.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.3 Grid Generation . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.4 Obtaining Fun3D . . . . . . . . . . . . . . . . . . . . . . . . 17

2 Conventions 19

2.1 Compressible Equations . . . . . . . . . . . . . . . . . . . . . 20

2.2 Incompressible Equations . . . . . . . . . . . . . . . . . . . . . 22

2.3 Generic Gas Equations . . . . . . . . . . . . . . . . . . . . . . 23

2.4 Unsteady Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 Boundary Conditions 25

3.1 X-Symmetry, Y -Symmetry, and Z-Symmetry . . . . . . . . . 27

4 Grids 28

4.1 File Endianness . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2 Supported Grid Formats . . . . . . . . . . . . . . . . . . . . . 28

4.2.1 AFLR3 Grids . . . . . . . . . . . . . . . . . . . . . . . 29

4.2.2 FAST Grids . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2.3 VGRID Grids . . . . . . . . . . . . . . . . . . . . . . 30

4.2.4 FieldView Grids . . . . . . . . . . . . . . . . . . . . . . 30

4.2.5 FELISA Grids . . . . . . . . . . . . . . . . . . . . . . . 31

4.2.6 Fun2D Grids . . . . . . . . . . . . . . . . . . . . . . . 31

4.3 Translation of Additional Grid Formats . . . . . . . . . . . . . 32

4.3.1 PLOT3D Grids . . . . . . . . . . . . . . . . . . . . . . 32

4.3.2 CGNS Grids . . . . . . . . . . . . . . . . . . . . . . . . 33

4.4 Implicit Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5 Flow Solver, nodet 35

5.1 Flow Solver Execution . . . . . . . . . . . . . . . . . . . . . . 35

5.2 Command Line Options . . . . . . . . . . . . . . . . . . . . . 35

5.3 Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.3.1 Flow Visualization . . . . . . . . . . . . . . . . . . . . 36

5.3.2 Flow Visualization Output From Existing Solution . . 37

3
6 Adjoint Solver, dual 38

6.1 Convergence of the Linear Adjoint Equations . . . . . . . . . . 38

6.2 Required Directory Hierarchy and Executing dual . . . . . . 38

6.3 rubber.data . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.4 Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

7 Grid Adaptation 40

7.1 Geometry Specification and Grid Freezing for refine . . . . . 40

7.1.1 No geometry, where the surface nodes are frozen. . . . 40

7.1.2 FAUXGeom for Planar Boundaries . . . . . . . . . . . 41

7.2 Performing Feature-Based Adaptation . . . . . . . . . . . . . 41

7.3 Performing Adjoint-Based Adaptation . . . . . . . . . . . . . 41

7.4 Scripting Grid Adaptation . . . . . . . . . . . . . . . . . . . . 42

7.4.1 Input File case specifics for f3d Script . . . . . . . 42

8 Design Optimization 45

8.1 Objective/Constraint Functions . . . . . . . . . . . . . . . . . 46

8.1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 46

8.1.2 Functional Form . . . . . . . . . . . . . . . . . . . . . 47

8.2 Some Details on Specific Objective/Constraint

Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

8.2.1 Lift-to-Drag Ratio (Keyword: clcd) . . . . . . . . . . 49

8.2.2 Rotorcraft Figure of Merit (Keyword: fom) . . . . . . . 49

8.2.3 Rotorcraft Propulsive Efficiency (Keyword: propeff) . 50

8.2.4 Rotorcraft Thrust (Keyword: rtr thrust) . . . . . . . 50

8.2.5 RMS of Stagnation Pressure (Keyword: pstag) . . . . 50

8.2.6 Near-field p/p∞ Pressure Target (Keyword: boom targ) 50

8.2.7 Coupled sBOOM Ground-Based Signatures, Noise Metrics, and Equivalent Areas (Keyword: sboom) . . . . . 52

8.2.8 Supersonic Mach Cut Equivalent Area Distribution

(Keyword: ae) . . . . . . . . . . . . . . . . . . . . . . 53

8.2.9 RMS of Pressure in User-Defined Box, Pointwise dp/dt,

dρ/dt (Keyword: press box) . . . . . . . . . . . . . . 54

8.2.10 Target Pressure Distributions (Keyword: cpstar) . . . 54

8.3 Geometry Parameterizations . . . . . . . . . . . . . . . . . . . 55

8.3.1 Surface Grid Extraction . . . . . . . . . . . . . . . . . 55

8.3.2 Access to Executables . . . . . . . . . . . . . . . . . . 56

8.3.3 Notes on Using Sculptor . . . . . . . . . . . . . . . . 56

8.3.4 Using Other Parameterization Packages . . . . . . . . . 57

8.4 Design Optimization Directory Structure . . . . . . . . . . . . 59

8.5 Contents of the ammo Directory . . . . . . . . . . . . . . . . . 59

8.5.1 ammo.input . . . . . . . . . . . . . . . . . . . . . . . . 59

8.6 Contents of the description.i Directory . . . . . . . . . . . 62

4
8.6.1 Geometry Parameterization Files . . . . . . . . . . . . 63

8.6.2 rubber.data . . . . . . . . . . . . . . . . . . . . . . . 65

8.6.3 ae target.dat (optional) . . . . . . . . . . . . . . . . 72

8.6.4 body grouping.data (optional) . . . . . . . . . . . . . 72

8.6.5 command line.options (optional) . . . . . . . . . . . . 73

8.6.6 cpstar.data.j (optional) . . . . . . . . . . . . . . . . 73

8.6.7 files to save.data (optional) . . . . . . . . . . . . . 73

8.6.8 machinefile (optional) . . . . . . . . . . . . . . . . . 74

8.6.9 pressure target.dat (optional) . . . . . . . . . . . . 74

8.6.10 transforms.i (optional) . . . . . . . . . . . . . . . . . 74

8.7 Contents of the model.i Directory . . . . . . . . . . . . . . . 75

8.8 Running the Optimization . . . . . . . . . . . . . . . . . . . . 75

8.8.1 Filesystem Latency Problems . . . . . . . . . . . . . . 76

8.9 Multi-objective Design . . . . . . . . . . . . . . . . . . . . . . 77

8.9.1 KSOPT . . . . . . . . . . . . . . . . . . . . . . . . . . 77

8.9.2 PORT, SNOPT . . . . . . . . . . . . . . . . . . . . . 77

8.10 Multi-point Design . . . . . . . . . . . . . . . . . . . . . . . . 77

8.10.1 Linear Combination of Objective Functions . . . . . . . 79

8.10.2 Combination of Objective Functions using the KreisselmeierSteinhauser Function . . . . . . . . . . . . . . . . . . . 79

8.10.3 Single-Point Objective Function with Off-Design Constraint Functions . . . . . . . . . . . . . . . . . . . . . 79

8.11 Optimization of Two-Dimensional Geometries . . . . . . . . . 80

8.12 Using a Different Optimization Package . . . . . . . . . . . . . 80

8.13 Implementing New Cost Functions/Constraints . . . . . . . . 81

8.14 Forward Mode Differentiation Using Complex

Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

References 83

A Installation 90

A.1 Extracting Files . . . . . . . . . . . . . . . . . . . . . . . . . . 90

A.2 Configure Introduction . . . . . . . . . . . . . . . . . . . . . . 90

A.3 Alternative Installation Path . . . . . . . . . . . . . . . . . . . 91

A.4 Fortran Compiler Option Tuning (FTune) . . . . . . . . . . . 91

A.5 Complex Variable Version . . . . . . . . . . . . . . . . . . . . 92

A.6 Internal Libraries . . . . . . . . . . . . . . . . . . . . . . . . . 92

A.6.1 KNIFE . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

A.6.2 REFINE . . . . . . . . . . . . . . . . . . . . . . . . . . 92

A.7 External Libraries . . . . . . . . . . . . . . . . . . . . . . . . . 92

A.7.1 MPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

A.7.2 ParMETIS . . . . . . . . . . . . . . . . . . . . . . . . . 94

A.7.3 SUGGAR++-1.0.10 or Higher . . . . . . . . . . . . . . 95

5
A.7.4 DiRTlib v1.40 or higher . . . . . . . . . . . . . . . . . 95

A.7.5 6-DOF . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

A.7.6 KSOPT . . . . . . . . . . . . . . . . . . . . . . . . . . 96

A.7.7 PORT . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

A.7.8 SNOPT . . . . . . . . . . . . . . . . . . . . . . . . . 97

A.7.9 NPSOL . . . . . . . . . . . . . . . . . . . . . . . . . 97

A.7.10 DOT/BIGDOT . . . . . . . . . . . . . . . . . . . . . 97

A.7.11 Tecplot . . . . . . . . . . . . . . . . . . . . . . . . . . 98

A.7.12 CGNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

A.7.13 sBOOM . . . . . . . . . . . . . . . . . . . . . . . . . . 98

B Fun3D Input Files 99

B.1 stop.dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

B.2 [project rootname].flow . . . . . . . . . . . . . . . . . . . . 100

B.3 remove boundaries from force totals . . . . . . . . . . . . 100

B.4 fun3d.nml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

B.4.1 &project . . . . . . . . . . . . . . . . . . . . . . . . . . 104

B.4.2 &raw grid . . . . . . . . . . . . . . . . . . . . . . . . . 105

B.4.3 &force moment integ properties . . . . . . . . . . . . . 107

B.4.4 &grid transform . . . . . . . . . . . . . . . . . . . . . . 108

B.4.5 &body transform . . . . . . . . . . . . . . . . . . . . . 110

B.4.6 &governing equations . . . . . . . . . . . . . . . . . . . 112

B.4.7 &reference physical properties . . . . . . . . . . . . . . 115

B.4.8 &noninertial reference frame . . . . . . . . . . . . . . . 117

B.4.9 &inviscid flux method . . . . . . . . . . . . . . . . . . 119

B.4.10 &turbulent diffusion models . . . . . . . . . . . . . . . 123

B.4.11 &spalart . . . . . . . . . . . . . . . . . . . . . . . . . . 126

B.4.12 &gammaretsst . . . . . . . . . . . . . . . . . . . . . . . 127

B.4.13 &code run control . . . . . . . . . . . . . . . . . . . . 128

B.4.14 &nonlinear solver parameters . . . . . . . . . . . . . . 131

B.4.15 &linear solver parameters . . . . . . . . . . . . . . . . 134

B.4.16 &boundary conditions . . . . . . . . . . . . . . . . . . 135

B.4.17 &two d trans . . . . . . . . . . . . . . . . . . . . . . . 149

B.4.18 &three d trans . . . . . . . . . . . . . . . . . . . . . . 151

B.4.19 &flow initialization . . . . . . . . . . . . . . . . . . . . 152

B.4.20 &component parameters . . . . . . . . . . . . . . . . . 154

B.4.21 &time avg params . . . . . . . . . . . . . . . . . . . . 157

B.4.22 &global . . . . . . . . . . . . . . . . . . . . . . . . . . 158

B.4.23 &volume output variables . . . . . . . . . . . . . . . . 160

B.4.24 &boundary output variables . . . . . . . . . . . . . . . 170

B.4.25 &sampling output variables . . . . . . . . . . . . . . . 182

B.4.26 &sampling parameters . . . . . . . . . . . . . . . . . . 194

B.4.27 &slice data . . . . . . . . . . . . . . . . . . . . . . . . 203

6
B.4.28 &overset data . . . . . . . . . . . . . . . . . . . . . . . 213

B.4.29 &rotor data . . . . . . . . . . . . . . . . . . . . . . . . 215

B.4.30 &adapt metric construction . . . . . . . . . . . . . . . 216

B.4.31 &adapt mechanics . . . . . . . . . . . . . . . . . . . . 221

B.4.32 &massoud output . . . . . . . . . . . . . . . . . . . . . 226

B.4.33 &sonic boom . . . . . . . . . . . . . . . . . . . . . . . 229

B.4.34 &sboom . . . . . . . . . . . . . . . . . . . . . . . . . . 231

B.4.35 &equivalent area . . . . . . . . . . . . . . . . . . . . . 239

B.4.36 &press box function . . . . . . . . . . . . . . . . . . . 240

B.4.37 &pstag function . . . . . . . . . . . . . . . . . . . . . . 242

B.4.38 &special parameters . . . . . . . . . . . . . . . . . . . 243

B.4.39 &vortex generator . . . . . . . . . . . . . . . . . . . . 244

B.5 moving body.input . . . . . . . . . . . . . . . . . . . . . . . . 248

B.5.1 &body definitions . . . . . . . . . . . . . . . . . . . . . 250

B.5.2 &forced motion . . . . . . . . . . . . . . . . . . . . . . 254

B.5.3 &observer motion . . . . . . . . . . . . . . . . . . . . . 258

B.5.4 &motion from file . . . . . . . . . . . . . . . . . . . . . 261

B.5.5 &surface motion from file . . . . . . . . . . . . . . . . 263

B.5.6 &sixdof motion . . . . . . . . . . . . . . . . . . . . . . 264

B.5.7 &aeroelastic modal data . . . . . . . . . . . . . . . . . 268

B.5.8 &composite overset mesh . . . . . . . . . . . . . . . . . 271

B.5.9 &body motion trim . . . . . . . . . . . . . . . . . . . . 272

B.6 rotor.input . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

B.6.1 Header . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

B.6.2 Actuator Surface Model . . . . . . . . . . . . . . . . . 277

B.6.3 Rotor Reference System . . . . . . . . . . . . . . . . . 278

B.6.4 Rotor Loading . . . . . . . . . . . . . . . . . . . . . . . 280

B.6.5 Blade Parameters . . . . . . . . . . . . . . . . . . . . . 280

B.6.6 Blade Element Parameters for Load Type=3 . . . . . . 281

B.6.7 Pitch Control Parameters for Load Type=3 . . . . . . 282

B.6.8 Prescribed Flap Parameters . . . . . . . . . . . . . . . 282

B.6.9 Prescribed Lag Parameters . . . . . . . . . . . . . . . . 283

B.7 tdata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

B.7.1 perfect gas Keyword . . . . . . . . . . . . . . . . . . 283

B.7.2 equilibrium air t Keyword . . . . . . . . . . . . . . 284

B.7.3 equilibrium air r Keyword . . . . . . . . . . . . . . 284

B.7.4 one Keyword . . . . . . . . . . . . . . . . . . . . . . . 284

B.7.5 two Keyword . . . . . . . . . . . . . . . . . . . . . . . 285

B.7.6 FEM Keyword . . . . . . . . . . . . . . . . . . . . . . . 285

B.8 species thermo data . . . . . . . . . . . . . . . . . . . . . . 286

B.9 kinetic data . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

B.10 species transp data . . . . . . . . . . . . . . . . . . . . . . 290

B.11 species transp data 0 . . . . . . . . . . . . . . . . . . . . . 291

7
B.12 hara namelist data . . . . . . . . . . . . . . . . . . . . . . . 291

C Troubleshooting 299

C.1 What if the solver has trouble starting or reports NaNs? . . . 299

C.2 What if the forces and moments aren’t steady or residuals don’t

converge to steady-state? . . . . . . . . . . . . . . . . . . . . . 299

C.3 What if the solver dies unexpectedly? . . . . . . . . . . . . . . 300

C.4 What if a segmentation fault occurs after “Calling ParMetis”? 300

C.5 What if the solver dies with an error like “input statement requires too much data” after echoing the wrong number of elements or nodes? . . . . . . . . . . . . . . . . . . . . . . . . . . 300

C.6 What if the solver dies with an error like “input statement requires too much data” after echoing the number of tetrahedra

and nodes for a VGRID mesh? . . . . . . . . . . . . . . . . . 300

C.7 What if the solver reports that the Euler numbers differ? . . . 300

C.7.1 Euler Number Description . . . . . . . . . . . . . . . . 301

C.7.2 Determining the Impact of an Euler Number Mismatch 302

8
About this Document

This manual is intended to guide an application engineer through configuration, compiling, installing, and executing the Fun3D simulation package. The

focus is on the most commonly exercised capabilities. Therefore, some of the

immature or rarely exercised capabilities are intentionally omitted in the interest of clarity. An accompanying document that provides example cases is

under development.

Release of the generic gas capability is restricted because of International

Traffic in Arms Regulations (ITAR), so Fun3D usually distributed with the

generic gas capability disabled. See section 1.4 for details. This manual describes Fun3D with and without the generic gas capability, denoted eqn type=

’generic’. Features that are specific to an eqn type are explicitly indicated.

This document is updated and released with each subsequent version of

Fun3D. In fact, a significant portion is automatically extracted from the

Fun3D source code. If you have difficulties, find any errors, or have any

suggestions for improvement please contact the authors at

Fun3D-Support@lists.nasa.gov

We would like to hear from you.

9
Acknowledgments

A large portion of this content originated as a web-based manual, which contained contributions from Jan-Renee Carlson, Karen Bibb, Bill Jones, Jeff

White, Eric Lynch, Dave O’Brien, Marilyn Smith, and Clara Helm. Sriram

Rallabhandi provided the description of sBOOM. The namelist documentation is parsed from Fun3D source code, which is written by the developers. Contributors to Fun3D include Ponnampalam (Bala) Balakumar, Karen

Bibb, Bob Biedron, Jan Carlson, Mark Carpenter, Peter Gnoffo, Dana Hammond, Bill Jones, Bil Kleb, Beth Lee-Rausch, Eric Nielsen, Hiroaki Nishikawa,

Mike Park, Chris Rumsey, Jim Thomas, Veer Vatsa, Jeff White, Alejandro

Campos, Rajiv Shenoy, Marilyn Smith, Joe Derlaga, Natalia Alexandrov, W.

Kyle Anderson, Harold Atkins, Bill Wood, Austen Duffy, Clara Helm, Chris

Cordell, Kyle Thompson, Hicham Alkandry, Shelly Jiang, Eric Lynch, Jennifer

Abras, Nicholas Burgess, Dave O’Brien, Tommy Lambert, Ved Vyas, Shatra

Reehal, Kan Yang, Andrew Sweeney, Brad Neff, Genny Pang, Gregory Bluvshteyn, Dan Gerstenhaber, Geoff Parsons, and Rena Rudavsky. And since

the release of the NASA TM manual with v12.4, the following people have reported bugs or suggested documentation improvements: Bill Sellers and Tim

Conners.

10
Quick Start

This section takes you from source code tarball to a rudimentary flow solution using single processor execution on a typical Unix-style environment

(e.g. Linux, Mac® OS) with a Fortran compiler and the GNU Make utility.

Fun3D is most commonly executed in parallel, but the intent here is to provide the most basic installation, setup, and execution of the Fun3D flow solver

without the complexity of any third-party libraries or packages.

See section 1.4 for instructions on obtaining the Fun3D source code tarball.

Once you have it, unpack the source code tarball, configure it for your system

(section A), compile it, and add the executables directory to your search path.

For C Shell, e.g.,

tar zxf fun3d-12.5-*.tar.gz

cd fun3d-12.5-*

mkdir _seq

cd _seq

../configure --prefix=${PWD}

make install

setenv PATH ${PWD}/bin:${PATH}

cd ..

For Bourne Shell, the setenv command is export PATH=${PWD}/bin:${PATH}.

The change to the PATH environment variable can be made permanently by

adding the setenv or export command to your shell start up file. Next, move

to the doc/quick start directory,

cd doc/quick_start

where you will find a very coarse 3D wing grid (inv wing.fgrid) intended for

inviscid flow simulation (section 4). Also in this directory are the associated

boundary conditions file inv wing.mapbc (section 3) and a Fun3D input file

fun3d.nml in Fortran namelist format (section B.4).

Execute the flow solver (section 5.1) by running the command

nodet

This should produce screen output similar to

1 FUN3D 12.5-71613 Flow started 09/16/2014 at 13:22:50 with 1 processes

2 Contents of fun3d.nml file below------------------------

3 &project

4 project_rootname = 'inv_wing'

5 /

6 &raw_grid

7 grid_format = 'fast'

8 data_format = 'ascii'

9 /

10 &governing_equations

11 viscous_terms = 'inviscid'

11
12 /

13 &reference_physical_properties

14 mach_number = 0.7

15 angle_of_attack = 2.0

16 /

17 &code_run_control

18 restart_read = 'off'

19 steps = 150

20 stopping_tolerance = 1.0e-12

21 /

22 &global

23 boundary_animation_freq = -1

24 /

25 Contents of fun3d.nml file above------------------------

26 rotor.input not found

27

28 moving_body.input not found

29 moving_body.input not found

30 ... opening inv_wing.fgrid

31 ... nnodesg: 6309 ntet: 35880 ntface: 1392

32

33 cell statistics: type, min volume, max volume, max face angle

34 cell statistics: tet, 0.38305628E-05, 0.14174467E+02, 143.526944837

35 cell statistics: all, 0.38305628E-05, 0.14174467E+02, 143.526944837

36

37 ... Constructing partition node sets for level-0... 35880 T

38 ... Edge Partitioning ....

39 ... Boundary partitioning....

40 ... Reordering for cache efficiency....

41 ... Write global grid information to inv_wing.grid_info

42 ... Time after preprocess TIME/Mem(MB): 0.72 98.72 98.72

.

.

.

197 76 0.459743875675293E-12 0.20881E-10 0.26803E+01 0.00000E+00 -0.62327E+00

198 Lift 0.809996568758631E-01 Drag 0.107734796873048E-01

199 77 0.347515632356081E-12 0.16460E-10 0.26803E+01 0.00000E+00 -0.62327E+00

200 Lift 0.809996568770187E-01 Drag 0.107734796873170E-01

201 78 0.264078581490539E-12 0.12961E-10 0.26803E+01 0.00000E+00 -0.62327E+00

202 Lift 0.809996568779106E-01 Drag 0.107734796873263E-01

203 79 0.201939553281957E-12 0.10194E-10 0.26803E+01 0.00000E+00 -0.62327E+00

204 Lift 0.809996568785974E-01 Drag 0.107734796873335E-01

205

206 Writing boundary output: inv_wing_tec_boundary.dat

207 Time step: 79, ntt: 79, Prior iterations: 0

208

209 Writing inv_wing.flow (version 11.8) lmpi_io 2

210 inserting current history iterations 79

211 Time for write: .0 s

212

213 Done.

If Fun3D completed successfully, a Mach 0.7 inviscid flow over a very

coarse representation of an ONERA M6 semi-span wing [1] at two degrees

angle of attack is available. If not, please refer to Troubleshooting on page 299.

With visualization software capable of reading Tecplot files, you can visualize various surface quantities with inv wing tec boundary.dat as shown by

the pressure contours in Fig. 1. Iterative convergence history can be plotted

from inv wing hist.dat as shown in Fig. 2. Histories of all five conservation

equation residual norms are denoted R 1–R 5, and the lift coefficient convergence history is denoted C L.

12
Figure 1: Mach 0.7 flow about a coarse ONERA M6 semi-span wing at 2

degrees angle of attack.

13
Figure 2: Iterative convergence history for coarse ONERA M6 wing.

14
1 Introduction

Fun3D began as a research code in the late 1980s. [2] The code was created

to develop new algorithms for unstructured-grid fluid dynamic simulations

of incompressible and compressible transonic flows. The project has since

grown into a suite of codes that cover not only flow analysis, but adjoint-based

error estimation, mesh adaptation, and design optimization of fluid dynamic

problems extending into the hypersonic regime. [3]

Fun3D is currently used as a production flow analysis and design tool to

support NASA programs. Continued research efforts have also benefited by the

improvements to stability, ease of use, portability, and performance that this

shift to simultaneous support of development and production environments has

required. These benefits also include the rapid evaluation of new techniques

on realistic simulations and a rapid maturation of experimental techniques to

production-level capabilities.

1.1 Primary Capabilities and Features

The primary capabilities of Fun3D are:

 Parallel domain decomposition with Message Passing Interface (MPI)

communication for distributed computing

 Two-dimensional (2D) and Three-dimensional (3D) node-based, finitevolume discretization

 Thermodynamic models: perfect gas (compressible and incompressible)

and thermochemical equilibrium, and non-equilibrium1

 Time-accurate options from first- to fourth-order with temporal error

controllers

 Upwind flux functions: flux difference splitting, flux vector splitting,

artificially upstream flux vector splitting, Harten-Lax-van Leer contact,

low dissipation flux splitting scheme, and others

 Turbulence models: Spalart-Allmaras, Menter k-omega SST, Wilcox komega, detached eddy simulation, and others, including specified or predicted transition

 Implicit time stepping where the linear system is solved using either

point-implicit, line-implicit, or Newton-Krylov (multigrid is also under

active development)

1The multi-species, thermochemical non-equilibrium capability requires the high-energy

physics library, which is only made available upon specific request and under certain conditions, see section 1.4 for details.

15
 Boundary conditions for internal flows and propulsion simulation including inlets, nozzles, and system performance

 Grid motion: time-varying translation, rotation, and deformation including overset meshes and six degrees of freedom trajectory computations

 Adjoint- and feature-based grid adaptation

 Gradient based sensitivity analysis and design optimization via handcoded discrete adjoint for reverse mode differentiation and automated

complex variables for forward mode differentiation

Before exploring more advanced applications (e.g., grid adaptation, moving

grids, overset grids, design optimization), the user should become familiar with

Fun3D’s basic flow solving capabilities and have appropriate computational

capability available as indicated in the next section.

1.2 Requirements

The Fun3D development team’s typical computing platform is Linux clusters;

so this is the most thoroughly tested environment for the software. A number

of users also run on other UNIX-like environments including Mac OS X; these

platforms are supported as well. Users have also run on other architectures

such as Microsoft Windows-based PC’s; however, the team cannot provide

explicit support for these environments.

The user will need GNU Make and a Fortran compiler that supports at

least the Fortran 95 standard. During configuration, the Fortran compiler is

tested, and any newer Fortran features or extensions are detected are used

to the greatest extent possible. A large number of compilers are tested by

an automated build framework, including Intel®, Portland Group®, NAG®,

Lahey/Fujitsu®, Cray®, Absoft®, IBM®, GFortran, and G95.

While the code can be compiled to run on only a single processor, as demonstrated in the Quick Start section, most applications will require compiling

against an MPI implementation and the ParMETIS domain decomposition

library to allow parallel execution.

The flow solver uses approximately 2.4 kilobytes of memory per grid point

for a perfect gas RANS simulation with a loosely-coupled turbulence model.

For example, a grid with one million mesh points would require approximately

2.4 gigabytes of memory. Memory usage will increase slightly with the increase in the number of processors because of the increasing boundary data

exchanged. Different solution algorithms and co-visualization options will also

require additional memory. Typically, one CPU core per 50,000 grid points is

suggested, where a 3D mesh of 20 million grid points would require 400 cores.

16
1.3 Grid Generation

Fun3D has no grid generation capability. For internal development at NASA,

the most common sources of 3D grids are VGRID (ViGYAN, Inc. and NASA

Langley), SolidMesh/AFLR3 (Mississippi State), Pointwise (Pointwise, Inc.),

and GridEx (NASA Langley).

For 2D grids, the development team normally uses the AFLR2 software

written by Prof. Marcum et al. at Mississippi State University Center for

Advanced Vehicular Systems (CAVS) SimCenter. Scripts are available to facilitate the use of this grid generator, but the generator itself must be obtained

from Prof. Marcum. BAMG [4] is also used for 2D grid generation and adaptation.

1.4 Obtaining Fun3D

Fun3D is export restricted and can only be given to a “U.S. Person,” which

is a citizen of the United States, a lawful permanent resident alien of the U.S.,

or someone in the U.S. as a protected political asylee or under amnesty. The

word “person” includes U.S. organizations and entities, such as companies or

universities, see 22 CFR §120.15 for the full legal definition. Release of the

high-energy, real-gas capability is further restricted because of International

Traffic in Arms Regulations (ITAR).

To request the Fun3D software suite, which will include the refine grid

adaptation and mesh untangling library and the knife cut-cell library, please

use the website request form available at

http://fun3d.larc.nasa.gov/chapter-1.html#request fun3d

or send an email to Fun3D-Support@lists.nasa.gov containing the following

information:

 “U.S. person” to put on agreement form, i.e., an institution or individual

 Point of contact (if “U.S. Person” is not an individual)

 Point of contact email address

 Phone number, extension

 FAX number (if available)

 Address (PO boxes not allowed)

 Proposed application2(optional)

 How did you discover Fun3D? (optional)

2The high-energy physics library that allows multiple species and non-equilibrium chemistry are only included upon specific request—be sure to note that you desire access to

this beta functionality as part of your application. Please include the phrase, “requesting

high-energy gas libraries”.

17
We will forward your email to initiate a review by Langley software release

authority (SRA) that verifies you qualify as a “U.S. Person.” Depending on

the SRA’s backlog, you will be sent a software usage agreement form in a

week or two. Once a completed usage agreement form is received and the

SRA notifies the Fun3D support team, the Fun3D support team will make

arrangements for transfer of the Fun3D software suite.

18
2 Conventions

This chapter discusses the coordinate system orientation and nondimensionalization used by Fun3D. The nomenclature for this section is

a = Speed of sound

C = Sutherland constant

e = Energy per unit mass

f = Frequency

h = Enthalpy per unit mass

k = Thermal conductivity

L = Length

M = Mach number

p = Pressure

R = Gas constant

Re = Reynolds number

t = Time

T = Temperature

u, v, w = Cartesian components of velocity

x, y, z = Cartesian directions

α = Angle of attack

β = Angle of sideslip

γ = Heat capacity ratio

μ = Viscosity

ρ = Density

where an asterisk (∗) denotes a dimensional quantity. A subscript ref denotes a reference quantity. For fluid variables, such as pressure, ref usually

corresponds to the value ‘at ∞’ for external flows or another condition for

internal flows. The units of various reference quantities must be consistent.

For example, if the reference speed of sound is defined in feet/sec, then the

dimensional reference length, L

∗

ref , must be in feet. In what follows, L

∗

ref is

the length in the grid that corresponds to the dimensional reference length;

Lref is considered dimensionless.

Fun3D’s angle of attack, sideslip angle, and associated force coefficients

are based on a body-fixed coordinate system:

 positive x is toward the back of the vehicle;

 positive y is toward the right of the vehicle; and

19
 positive z is upward

as shown in Fig. 3. This differs from the standard wind coordinate system by

a 180 degree rotation about the y axis. The α and β flow angle conventions

are shown in Fig. 4.

Figure 3: Fun3D body coordinate system.

Figure 4: Fun3D freestream flow angle definition.

2.1 Compressible Equations

x = x

∗/(L∗

ref /Lref )

y = y

∗/(L∗

ref /Lref )

z = z

∗/(L∗

ref /Lref )

t = t

∗a∗

ref /(L

∗

ref /Lref )

ρ = ρ

∗/ρ∗

ref ρref = 1

20
|V | = |V

∗

|/a∗

ref |V |

ref = Mref

u = u

∗/a∗

ref uref = Mref cos α cos β

v = v

∗/a∗

ref vref = −Mref sin β

w = w

∗/a∗

ref wref = Mref sin α cos β

p = p

∗/(ρ∗

refa

∗2

ref ) pref = 1/γ

a = a

∗/a∗

ref aref = 1

T = T

∗/T∗

ref Tref = 1

e = e

∗/(ρ∗

refa

∗2

ref ) eref = 1/(γ(γ − 1)) + M2

ref /2

To see how the nondimensional Navier-Stokes equations that are solved

in Fun3D are obtained from their dimensional counterparts, it is sufficient

to look at the unsteady, one-dimensional equations for conservation of mass,

momentum, and energy:

∂ρ∗

∂t∗

+

∂(ρ

∗u∗

)

∂x∗

= 0

∂(ρ

∗u∗

)

∂t∗

+

∂

∂x∗



ρ

∗u∗2 + p∗ −

4

3

μ

∗

∂u∗

∂x∗



= 0

∂e∗

∂t∗

+

∂

∂x∗



(e

∗ + p∗

)u

∗ −

4

3

μ

∗u∗

∂u∗

∂x∗

− k

∗

∂T∗

∂x∗



= 0

where k

∗

is the thermal conductivity. For a thermally and calorically perfect

gas, we also have the equation of state, the definition of the speed of sound,

and the specific heat relation:

T

∗ =

p

∗

ρ

∗R∗

a

∗2 = γR∗T∗

(γ = cp

∗

/cv

∗

)

cp

∗ + cv

∗ = R∗ R∗

/cp

∗ = (γ − 1)/γ

The laminar viscosity is related to the temperature via Sutherland’s law

μ

∗ = μ∗

ref

T

∗

ref + C

∗

T

∗ + C∗



T

∗

T

∗

ref 3/2

where C

∗ = 198.6◦R for air.

Substitution of the nondimensional variables defined above into the equation of state and the definition of the speed of sound gives:

T =

γp

ρ

= a

2

21
Sutherland’s law in nondimensional terms is given by

μ =

1 + C

∗/T∗

ref

T + C∗/T∗

ref

T

3/2

where C

∗

is the Sutherland constant (C

∗ = 198.6◦R for air) and where T∗

ref

is in degrees Rankine.

Substitution of the dimensionless variables into the conservation equations

gives, after some rearrangement,

∂ρ

∂t +

∂(ρu)

∂x = 0

∂(ρu)

∂t +

∂

∂x 

ρu2 + p −

4

3

Mref

ReLref

μ

∂u

∂x

= 0

∂e

∂t +

∂

∂x 

(e + p)u −

4

3

Mref

ReLref

μu

∂u

∂x −

Mref

ReLrefPr(γ − 1)μ

∂T

∂x 

= 0

where Pr is the Prandtl number (generally assumed to be 0.72 for air)

Pr =

c

∗

p μ

∗

k

∗

and where ReLref , the Reynolds number per unit length in the grid, corresponds to the input variable reynolds number in the fun3d.nml file. ReLref is

related to the Reynolds number characterizing the physical problem, ReL∗

ref

by

ReLref =

ρ

∗

ref |V

∗

|

ref (L

∗

ref /Lref )

μ∗

ref

=

ρ

∗

ref |V

∗

|

refL

∗

ref

μ∗

ref

1

Lref

=

ReL∗

ref

Lref

2.2 Incompressible Equations

x = x

∗/(L∗

ref /Lref )

y = y

∗/(L∗

ref /Lref )

z = z

∗/(L∗

ref /Lref )

t = t

∗

|V

∗

|

ref /(L

∗

ref /Lref )

|V | = |V

∗

|/|V

∗

|

ref |V |ref = 1

u = u

∗/|V∗

|

ref uref = cos α cos β

v = v

∗/|V∗

|

ref vref = − sin β

w = w

∗/|V∗

|

ref wref = sin α cos β

p = p

∗/(ρ∗

ref |V

∗

|

2

ref ) pref = 1

22
For incompressible flows, Fun3D does not model any heat sources. The

temperature T

∗

is constant and so is the viscosity μ

∗

. After dividing through

by a constant reference density, the one-dimensional continuity and momentum

equations are:

∂u∗

∂x∗

= 0

∂u∗

∂t∗

+

∂

∂x∗



u

∗2 +

p

∗

ρ

∗

ref

−

4

3

μ

∗

ref

ρ

∗

ref

∂u∗

∂x∗



= 0

The fundamental difference between the nondimensionalization of the compressible equations and the incompressible equations is that the sound speed

is used in the former and the flow speed in the latter. Substitution of the

dimensionless variables defined above into the conservation equations gives,

after some rearrangement,

∂u

∂x = 0

∂u

∂t +

∂

∂x 

u

2 + p −

4

3

1

ReLref

∂u

∂x

= 0

where, exactly the same as in the compressible-flow path, the Reynolds number

per unit length in the grid is

ReLref =

ρ

∗

ref |V

∗

|

refL

∗

ref

μ∗

ref

=

ReL∗

ref

Lref

2.3 Generic Gas Equations

The generic gas path requires all reference quantities (velocity, density, temperature) be entered in the meter-kilogram-second (MKS) system. The transport

property nondimensionalization includes the effects of rescaling using the grid

length conversion factor. The nondimensionalization of other flow variables

follows the practice used to derive the Mach number independence principle.

Neither Mach number nor Reynolds number can be used to define reference

conditions; these are derived from the fundamental reference quantities. The

derived Reynolds number is relative to a one meter reference length. Temperature is never non-dimensionalized; it always appears in units of degrees

Kelvin.

ρ = ρ

∗/ρ∗

ref ρ

∗

ref [kg/m3

]

u = u

∗/V ∗

ref V

∗

ref [m/s]

v = v

∗/V ∗

ref T

∗

ref [K]

w = w

∗/V ∗

ref L

∗

ref [m]

23
a = a

∗/V ∗

ref

p = p

∗/(ρ∗

refV

∗2

ref )

e = e

∗/V ∗2

ref

h = h

∗/V ∗2

ref

μ = μ

∗

(T

∗

)/ρ∗

refV

∗

refL

∗

ref

2.4 Unsteady Flows

One of the challenges in unsteady flow simulation is determining the nondimensional time step ∆t. The number of time steps at that ∆t necessary to

resolve the lowest frequency of interest will impact the cost of the simulation

and too large a ∆t will corrupt the results with temporal errors. Time is

non-dimensionalized within Fun3D by

t = t

∗a∗

ref /(L

∗

ref /Lref ) (compressible)

t = t

∗

|V

∗

|

ref /(L

∗

ref /Lref ) (incompressible)

where, as in the previous sections, quantities denoted with ∗ are dimensional.

In all unsteady flows, one or more characteristic times t

∗

chr may be identified. In a flow with a known natural frequency of oscillation (e.g., vortex shedding from a cylinder), or in situations where a forced oscillation is imposed

(e.g., a pitching wing), a dominant characteristic time is readily apparent. In

such cases, if the characteristic frequency in Hz (cycles/sec) is f

∗

chr, then

t

∗

chr = 1/f ∗

chr

In other situations, no oscillatory frequency may be apparent (or not known

a priori). In such cases, the time scale associated with the time it takes for

a fluid particle (traveling at a nominal speed of |V

∗

|

ref ) to pass the body of

reference length L

∗

ref is often used:

t

∗

chr = L

∗

ref /|V

∗

|

ref

The corresponding nondimensional characteristic time is therefore given by:

tchr = t

∗

chra

∗

ref /(L

∗

ref /Lref ) (compressible)

tchr = t

∗

chr|V

∗

|

ref /(L

∗

ref /Lref ) (incompressible)

Once the nondimensional characteristic tchr is determined, the user must

decide on an appropriate number of time steps (N) to be used for resolving

that characteristic time. Then the nondimensional time step may be specified

as:

∆t = tchr / N

The proper value of N must be determined by the user. However, a reasonable

rule of thumb for second-order time integration is to take N = 200. Note that if

there are multiple frequencies requiring resolution in time, the most restrictive

should be used to determine ∆t.

24
3 Boundary Conditions

This chapter discusses the boundary conditions available in Fun3D. Table 1

lists the integers used to specify Fun3D boundary conditions with a short

description. Each grid description subsection in section 4 indicates how these

integers are specified. Details of the boundary condition implementation are

provided by Carlson. [5] Details of symmetry boundary conditions are provided

in section 3.1. Some boundary conditions have required or optionally specified

parameters defined in the &boundary conditions namelist, see section B.4.16

for further boundary condition details.

25
Table 1: Fun3D boundary conditions.

BC Description Notes

−1 Overlap overset grid boundary

3000 Tangency zero normal velocity, specified via fluxes

4000* Viscous explicitly set the no-slip condition

5000 Farfield Riemann invariants

5026 Extrapolate supersonic outflow, variables extrapolated from the interior

5050 Freestream external freestream, specified via fluxes

5051* Back pressure specified static pressure (switches to extrapolation boundary

condition in the presence of supersonic flow)

5052* Mach outflow static pressure outflow boundary condition set via a specified

subsonic Mach number (not for boundary layer ingestion)

6021 Symmetry plane 1 symmetry enforced by replacing x-momentum with zero velocity normal to arbitrary boundary plane.

6022 Symmetry plane 2 symmetry enforced by replacing y-momentum with zero velocity normal to arbitrary boundary plane.

6023 Symmetry plane 3 symmetry enforced by replacing z-momentum with zero velocity normal to arbitrary boundary plane.

6100 Periodicity discrete periodicity, limited to nominally 2D grids extruded

across n planes in a third dimension

6661 X-symmetry plane enforces symmetry for x Cartesian plane

6662 Y -symmetry plane enforces symmetry for y Cartesian plane

6663 Z-symmetry plane enforces symmetry for z Cartesian plane

7011* Subsonic inflow subsonic inflow (pt,bc = ptotal,plenum/pstatic,f reestream,

Tt,bc = Ttotal,plenum/Tstatic,f reestream) for nozzle or tunnel

plenum ( Minf low < 1 )

7012* Subsonic outflow subsonic outflow (pbc = pstatic,inlet/pstatic,f reestream for inlet flow (does not allow for reverse or supersonic flow at the

outflow boundary face)

7021* Reaction control jet plenum models the plenum of a reaction control system (RCS) jet

7031* Mass flow out specification of massflow out of the control volume

7036* Mass flow in specification of massflow in to the control volume

7100* Fixed inflow fixed primitive variables in to control volume

7101* Fixed inflow profile specified profile

7103* Pulsed supersonic inflow pulsing supersonic flow

7104* Ramped supersonic inflow ramping supersonic flow

7105* Fixed outflow specified primitive outflow conditions

* See &boundary conditions namelist in section B.4.16 to specify auxiliary information and for

further descriptions.

26
3.1 X-Symmetry, Y -Symmetry, and Z-Symmetry

The symmetry condition in FUN3D enforces discrete symmetry. That is, if

the mesh were mirrored about the symmetry plane and run as a full-span

simulation, the residuals (and therefore the outputs, such as lift, drag, etc.)

will be identical. The FUN3D automated tests include a case were a mirrored

grid is compared to the symmetry boundary condition. Discrete symmetry is

also enforced where multiple symmetry condition intersect (i.e., a corner of

Y -symmetry and Z-symmetry).

Specifically, the condition enforces:

 Any points on a symmetry plane are first “snapped” to the average

coordinate for that plane. Many grid generators will have some small

amount of “slop” in their y-coordinates for points on a y-symmetry plane;

FUN3D immediately pops all of the points onto the exact same plane,

at least to double precision.

 The residual equation corresponding to the momentum normal to the

symmetry plane is modified to reflect zero crossflow (i.e., ρv = 0 on a

y-symmetry plane).

 The least squares system used to compute gradients for inviscid reconstruction to the cell faces is augmented to include symmetry contributions across the symmetry plane(s).

 All gradients of the velocity normal to the symmetry plane (v for a

y-symmetry plane) in the source terms for the turbulence models are

zeroed out. Gradients of the tangential velocities are zeroed out normal

to the symmetry plane (du/dy, dw/dy).

 No convective flux of turbulence normal to the symmetry plane.

 Grid metrics (e.g., areas, normals) are forced to be symmetric at symmetry planes.

27
4 Grids

This chapter explains how to supply the proper file formats to Fun3D, but

does not cover how to create a mesh. See section 1.3 for grid generation

guidance. Fun3D supports a direct reader for many grid formats. The format

of the grid is specified in the &raw grid namelist. In addition to the directly

read formats, translators are provided to convert additional grid formats into

a format that can be read directly, see section 4.3.

4.1 File Endianness

The ordering of bytes within a data item is known as “endianness.” If the

endianness of a file is different than the native endianness of the computer

then a conversion must be performed. The endianness of each grid file format

is described in section 4.2. If your compiler supports it, Fun3D will attempt

to open binary files with a open(convert=...) keyword extension. Consult the

documentation of the Fortran compiler you are using to determine if other

methods are available. For example, with the Intel® Fortran compiler, the endianness of file input and output can be controlled by setting the F UFMTENDIAN

environment variable to big or little.

4.2 Supported Grid Formats

Fun3D natively supports the grid formats summarized in Table 2.

Table 2: File extensions.

Format Grid files BC File

AFLR3 .ugrid .mapbc

FAST .fgrid .mapbc

FieldView .fvgrid fmt .mapbc

.fvgrid unf .mapbc

FUN2D .faces .mapbc

VGRID .cogsg, .bc .mapbc*

FELISA .gri, .fro .bco

* Same suffix, but GridTool format.

The standard Fun3D .mapbc file format contains the boundary condition

information for the grid. The first line is an integer corresponding to the number of boundary groups contained in the grid file. Each subsequent line in this

file contains two integers, the boundary face number and the Fun3D boundary condition integer; these numbers may optionally be followed by a character

string that specifies a “family” name for the boundary. The family name is

required if the patch lumping option (section B.4.2) is invoked to combine

28
patches into fewer patch families. Below is a sample .mapbc file illustrative for

all grid formats except GridTool/VGRID, FELISA, and FUN2D, which are

described later.

13

1 6662 box_ymin

2 5025 box_zmax

3 5050 box_xmin

4 5025 box_ymax

5 5025 box_zmin

6 5025 box_xmax

7 3000 wing_upper

8 3000 wing_lower

9 3000 wing_upper

10 3000 wing_upper

11 3000 wing_lower

12 3000 wing_lower

13 3000 wing_tip

4.2.1 AFLR3 Grids

AFLR3, SolidMesh, Pointwise, and GridEx can all produce this format and

Fun3D ships with translators that convert Plot3D and CGNS grids to AFLR3

format. The format is documented online at http://simcenter.msstate.edu/

docs/solidmesh/ugridformat.html

AFLR3 grid file format types are indicated by file suffixes. The formatted

(plain text) style has a .ugrid suffix while other types vary according to endianness (see section 4.1) and binary type as shown in Table 3. The boundary

Table 3: AFLR3 non-ASCII grid suffixes.

Type Little endian Big endian

Fortran Stream, C Binary .lb8.ugrid .b8.ugrid

Fortran Unformatted .lr8.ugrid .r8.ugrid

conditions are specified via the standard Fun3D .mapbc format.

4.2.2 FAST Grids

The .fgrid file contains the complete grid stored in ASCII FAST format.

The format is documented online at http://simcenter.msstate.edu/docs/

solidmesh/FASTformat.html The boundary conditions are specified via the

standard Fun3D .mapbc format.

29
4.2.3 VGRID Grids

The .cogsg file contains the grid nodes and tetrahedra stored in unformatted VGRID format. The VGRID cogsg files always have big endian byte

order regardless of the computer used in grid generation. See section 4.1 for

instructions on specifying file endianness.

The .bc file contains the boundary information for the grid, as well as a flag

for each boundary face. For viscous grids with a symmetry plane, VGRID

is known to produce boundary triangles in the .bc file that are incompatible

with the volume tetrahedra. Fun3D provides a repair vgrid mesh utility to

swap the edges of these inconsistent boundary triangles. If Fun3D reports

that there are boundary triangles without a matching volume tetrahedra, use

this utility.

VGRID has a different .mapbc boundary condition format. For each

boundary flag used in the .bc file, the .mapbc file contains the boundary type

information. The VGRID boundary conditions are described at the website:

http://tetruss.larc.nasa.gov/usm3d/bc.html. The Fun3D boundary condition integers can also be used in place of the VGRID boundary condition

integers. Internally, Fun3D converts the VGRID boundary condition integers to the Fun3D boundary condition integers as indicated in Table 4.

Table 4: Boundary type mapping between VGRID and Fun3D.

VGRID FUN3D

−1 −1

0 5000

1 6662

2 5005

3 5000

4 4000

5 3000

44 4000

55 3000

4.2.4 FieldView Grids

The .fvgrid fmt file contains the complete grid stored in ASCII FieldView

FV-UNS format, and the .fvgrid unf file contains the complete grid stored

in unformatted FieldView FV-UNS format. Supported FV-UNS file versions

are 2.4, 2.5, and 3.0. With FV-UNS version 3.0, the support is only for the

grid file in split grid and results format; the combined grid/results format

is not supported. Fun3D does not support the arbitrary polyhedron elements of the FV-UNS 3.0 standard. For ASCII FV-UNS 3.0, the standard

allows comment lines (line starting with !) anywhere in the file. Fun3D

30
only allows comments immediately after line 1. Only one grid section is allowed. The precision of the unformatted grid format should be specified by

the fieldview coordinate precision variable in the &raw grid namelist,

see section B.4.2. The boundary conditions are specified via the standard

Fun3D .mapbc format.

4.2.5 FELISA Grids

The .gri file contains the grid stored in formatted FELISA format. [6] The

.fro file contains the surface mesh nodes and connectivities and associated

boundary face tags for each surface triangle. This file can contain additional

surface normal or tangent information (as output from GridEx or SURFACE

mesh generation tools), but the additional data is not read by Fun3D. The

.bco file contains a flag for each boundary face. If original FELISA boundary

condition flags (1, 2, or 3) are used, they are translated to the corresponding

Fun3D 4-digit boundary condition flag according to Table 5. Alternatively,

Fun3D 4-digit boundary condition flags can be assigned directly in this file.

Table 5: Boundary type mapping between FELISA and Fun3D.

FELISA FUN3D

1 3000

2 6662

3 5000

4.2.6 Fun2D Grids

The .faces file contains the complete grid stored in formatted Fun2D format

(triangles). Internally, Fun3D will extrude the triangles into prisms in the

y-direction and the 2D mode of Fun3D is automatically enabled. Output

from the flow solver will include this one-cell wide extruded mesh.

Boundary conditions are contained in the Fun2D grid file as integers 0–

8. The mappings to Fun3D boundary conditions are given in Table 6. If

Fun3D does not detect a .mapbc, it will write a .mapbc file that contains the

default Table 6 mapping. If you wish to change the boundary conditions from

the defaults based on the .faces file, simply edit them in this .mapbc file and

rerun Fun3D. The boundary conditions in the .mapbc file have precedence

over the .faces boundary conditions. If you wish to revert to the boundary

conditions in the .faces file after modifying the .mapbc, you can remove the

.mapbc and rerun Fun3D.

31
Table 6: Boundary type mapping between Fun2D and Fun3D.

FUN2D FUN3D

0 3000

1 4000

2 5000

3 −1

4 4010

5 4010

6 5005

7 7011

8 7012

4.3 Translation of Additional Grid Formats

While Fun3D supports the direct read of multiple formats, utilities are provided to translate additional grid formats into a format that Fun3D can read.

4.3.1 PLOT3D Grids

The utility plot3d to aflr3 converts a PLOT3D structured grid to an AFLR3-

format hexahedral unstructured grid. The original structured grid must be

3D multiblock http://www.grc.nasa.gov/WWW/wind/valid/plot3d.html (no

iblanking) with the file extension .p3d for formatted ASCII or the the file extension .ufmt for Fortran unformatted. Only one-to-one connectivity is allowed

with this option (no patching or overset). The grid should contain no singular

(degenerate) lines or points. A neutral map file with extension .nmf is also required. This file gives boundary conditions and connectivity information. The

.nmf file is described at http://geolab.larc.nasa.gov/Volume/Doc/nmf.htm.

Note that the Type name in the .nmf file must correspond with one of

Fun3D’s BC types, plus it allows the Type one-to-one. If the Type is not

recognized, you will get errors like:

This may be an invalid BC index.

An example .nmf file is shown here for a simple single-zone airfoil C-grid

(5 × 257 × 129) with six exterior boundary conditions and one one-to-one

patch in the wake where the C-grid attaches to itself:

# ===== Neutral Map File generated by the V2k software of NASA Langley's GEOLAB =====

# ===================================================================================

# Block# IDIM JDIM KDIM

# -----------------------------------------------------------------------------------

1

1 5 257 129

# ===================================================================================

# Type B1 F1 S1 E1 S2 E2 B2 F2 S1 E1 S2 E2 Swap

# -----------------------------------------------------------------------------------

32
'tangency' 1 3 1 257 1 129

'tangency' 1 4 1 257 1 129

'farfield_extr' 1 5 1 129 1 5

'farfield_extr' 1 6 1 129 1 5

'one-to-one' 1 1 1 5 1 41 1 1 1 5 257 217 false

'viscous_solid' 1 1 1 5 41 217

'farfield_riem' 1 2 1 5 1 257

4.3.2 CGNS Grids

Fun3D is distributed with a utility cgns to aflr3 that converts CGNS files

http://cgns.sourceforge.net/ to AFLR3 grids. This utility will only be

built if Fun3D is configured with a CGNS library, see section A.7.12. Only

the Unstructured type of CGNS files are supported. The following CGNS

mixed element types are supported: PENTA 6 (prisms), HEX 8 (hexes), TETRA 4

(tets), and PYRA 5 (pyramids).

The CGNS file must include Elements t nodes for all boundary faces (type

QUAD 4 or TRI 3) to refer to the corresponding boundary elements. Otherwise,

the utility cannot recognize what boundaries are present because it currently

identifies boundaries via these 2D element types. The cgns to aflr3 utility

requires that the BC elements be listed either as a range or a sequential list.

It is also helpful to have separate element nodes for each boundary element

of a given BC type. This way, it is easier to interpret the boundaries, i.e., body

versus symmetry versus farfield. Visualization tools, such as Tecplot, can

easily distinguish the various boundary condition groups as long as each group

has its own node in the CGNS tree. Under BC t, cgns to aflr3 reads these

BC names, but ignores additional boundary data (e.g., BCDataSet, BCData).

Table 7: Boundary type mapping between CGNS and Fun3D.

CGNS FUN3D

BCSymmetryPlane 6661, 6662, or 6663 via prompt

BCFarfield 5000

BCWallViscous 4000

BCWall 4000

BCWallInviscid 3000

BCOutflow 5026

BCTunnelOutflow 5026

BCInflow 5000

BCTunnelInflow 5000

If the CGNS file is missing BCs (no BC t node), cgns to aflr3 still tries

to construct the BCs based on the boundary face Elements t information. If

these boundary element nodes have a name listed in Table 7, a .mapbc file

will be written that contains the Fun3D boundary condition numbers. If the

name is not recognized, you will see the message:

WARNING: BC type ... in CGNS file not recognized.

33
in which case you will need to fix it by by editing the .mapbc file manually.

Always check the .mapbc file after the utility has run, to make sure that the

boundary conditions have all been interpreted and set correctly. If a translation problem is observed, you should edit the .mapbc file before running

Fun3D.

4.4 Implicit Lines

The standard implicit solution relaxation scheme in Fun3D is a point-implicit,

which inverts the linearization of the residual at each node to compute an update to the solution. A line-implicit relaxation scheme can be used that inverts

the linearization of a line of nodes simultaneously. Typically, lines are constructed for the subset of nodes in the boundary layer to address the stiffness

inherent in the Navier-Stokes equations on anisotropic grids. Therefore, the

use of line-implicit relaxation may improve the convergence of viscous flow simulations. These lines are used in conjunction with the standard point-implicit

relaxation scheme. Detailed descriptions of both line and point relaxation

schemes are provided by Nielsen et al. [7] Currently, every viscous boundary

node must have one and only one associated implicit line. Lines of nodes

are specified in a formatted file with the suffix .lines fmt that contains the

definitions of lines emanating from viscous boundary nodes as a list of node

numbers. The format of the .lines fmt file is

[total number of lines] [total number of points in lines]

[min points in a line] [max points in a line]

[points in line 1]

[first node of line 1]

...

[last node of line 1]

[points in line 2]

...

34
5 Flow Solver, nodet

This chapter covers what is required to run an initial flow solution, how to

restart a flow solution, and how to specify what outputs the solver nodet

produces.

5.1 Flow Solver Execution

The grid and flow conditions are specified in the file fun3d.nml; see section B.4

for the file description. If you configured Fun3D without MPI, the executable

is named nodet. If you configured Fun3D with MPI, the executable is named

nodet mpi. Configuration and installation is explained in detail in section A.

The executable nodet can be invoked directly from the command line,

nodet [fun3d options]

but the MPI version nodet mpi will need to be invoked within an MPI environment. The most common method is via

[MPI run command] [MPI options] nodet_mpi [fun3d options]

The details of the MPI run command and MPI options will depend on the MPI

implementation. The MPI run command is commonly mpirun or mpiexec.

The MPI options may contain the number of processors -np [n], a machine

file -machinefile [file], or no local -nolocal. If a queuing system is used

(e.g., PBS) this command will need to be run inside an interactive job or a

script. See your MPI documentation or system administrator to learn the

details of your particular environment.

If you have provided a grid with boundary conditions and fun3d.nml, you

will then see the solver start to execute. If an unexpected termination happens

during execution, especially during grid processing or the first iteration, you

may need to set your shell limits to unlimited,

$ ulimit unlimited # for bash

$ unlimit # for c shell

A detailed description of the output files is given below.

5.2 Command Line Options

These options are specified after the executable. The majority of the command

line options are functionality under development and there is work underway to

migrate command line options to namelists. Namelists are the preferred input

method. Command line options should be avoided unless they are the only

way to activate the functionality you require. These commands are always

preceded by -- (double minus). More than one option may appear on the

35
command line (each option proceeded by a -- ). You can see a listing of the

available command line options in any of the codes in the Fun3D suite by

using the command line option --help after the executable name,

./nodet_mpi --help

The options are then listed in alphabetical order, along with a short description and a list of any auxiliary parameters that might be needed, and

then the code execution stops. Specific examples of the use of command line

options are found throughout this, and later, chapters.

5.3 Output Files

These are the output files produced by the flow solver, nodet.

[project rootname].flow This file contains the binary restart information and is read by the solver for restart computations. See the restart read

namelist variable in section B.4.13 to control restart behavior.

[project rootname] hist.dat This file contains the convergence history for the RMS residual, lift, drag, moments, and CPU time, as well as the

individual pressure and viscous components of each force and moment. The

file is in Tecplot format. See section B.4.20 for an improved method to track

forces and moments.

[project rootname] subhist.dat For time accurate computations only.

This file contains the sub-iteration convergence history for the RMS residuals.

The file is in Tecplot format.

[project rootname].forces This file contains a breakdown of all the

forces and moments acting on each individual boundary group. The totals for

the entire configuration are listed at the bottom. See section B.4.20 for an

improved method to track forces and moments.

5.3.1 Flow Visualization

There are four basic categories of output: boundary data, sampling data (on

entities such as planes, boxes and spheres), volumetric data, and slice data

controlled by the namelists in Table 8.

Each namelist has a corresponding frequency variable, A positive frequency

will cause the output to be generated every frequency time step/iteration. A

negative frequency will cause output to be written only at the end of a run. A

zero frequency (the default) with produce no output. See the corresponding

namelist descriptions for details.

36
Table 8: Solver output types.

Type Namelist

domain boundaries &boundary output variables section B.4.24

domain volume &volume output variables section B.4.23

boundary slices &slice data section B.4.27

various geometries &sampling parameters and section B.4.26 and

&sampling output variables section B.4.25

point &sampling parameters and section B.4.26 and

&sampling output variables section B.4.25

5.3.2 Flow Visualization Output From Existing Solution

If a Fun3D flow solution already exists, visualization files by setting steps

= 0 in the &code run control namelist within the fun3d.nml file and setting

the restart read variable to something other than ’off’. This will allow

generation of visualization output without having to do additional timesteps

or iterations.

37
6 Adjoint Solver, dual

This section describes how to execute the adjoint solver, dual, directly. Typically, dual is executed by scripts that manage the multiple steps required

for design optimization (section 8) or grid adaptation (section 7). However,

it may be necessary to run dual directly to diagnose problems or gain experience during setup including determining input parameters and termination

strategies. Fun3D is configured to compile dual by default. While the adjoint method is available for most commonly used Fun3D capabilities, only a

subset of Fun3D’s full capabilities are implemented in the adjoint solver.

6.1 Convergence of the Linear Adjoint Equations

The adjoint solution is dependent on the primal flow solution (and the convergence of the primal flow equations). While the primal solution may have

converged enough to give acceptable force and moment results, the flow residuals might still be large, which can cause the adjoint solution scheme to diverge. This divergence issue is most common in turbulent simulations. A

divergent adjoint scheme can be improved in some circumstances with the

--outer loop krylov command line option. It is critical to run the flow

solver and the adjoint solver with the same governing equations and boundary conditions.

The scaling of the adjoint residuals is different from the flow residuals

and is dependent on the choice of the adjoint cost functions. The number of

iterations steps and the residual tolerance stopping tolerance will need to

be adjusted, see section B.4.13. The sensitivities should converge at the same

rate as your functions (i.e., lift), but an adjoint with some algebraic error may

still provide reasonable sensitivities for design and grid adaptation.

6.2 Required Directory Hierarchy and Executing dual

The executable dual can be invoked directly from the command line,

dual [fun3d options]

but the MPI version dual mpi will need to be invoked within an MPI environment. The most common method is via

[MPI run command] [MPI options] dual_mpi [fun3d options]

Any [fun3d options] provided to nodet that control the flow solver residual

will also be required for the adjoint solver for a consistent adjoint solution and

solution scheme. See the flow solver execution instructions for more details,

section 5.1.

38
dual expects the cost function description ../rubber.data to be in the

parent directory of the directory from which it is invoked. The input and

flow restart files are shared with nodet in the directory ../Flow/. The flow

solver must be run to completion, to provide a flow restart file, before dual

is invoked. See Table 9 for the required files and locations.

Table 9: Adjoint solver dual directory hierarchy.

Relative Path Description

../Flow/[project rootname].flow Primal flow solution (restart)

../Flow/fun3d.nml Main input namelist file

../rubber.data Description of the adjoint cost function

6.3 rubber.data

The minimum required rubber.data for running the adjoint (and grid adaptation) can be written with the command

f3d function [cost function name]

Available cost function names are discussed in section 8.1 and listed in Table 10. See section 8.6.2 for complete details on this file format including the

information required for design. The rubber.data reader requires the exact

number of header lines. Be very careful when editing this file.

6.4 Output Files

The adjoint solver will export visualization files in the same manner as the

flow solver when requested, see section 5.3.1.

[project rootname].adjoint This file contains the binary restart information and is read by the and adjoint solver for restart computations.

[project rootname] hist.tec This file contains the convergence history for the RMS residual of the adjoint equations and CPU time. The file is

in the same Tecplot format as the flow solver produces. History information

is truncated when the adjoint solver is restarted.

39
7 Grid Adaptation

Fun3D implements metric-based adaptation, where grid adaptation is separated into two tasks. The first step is to construct a metric that describes the

desired size and anisotropy of the adapted grid elements. The second step is

to produce an adapted grid that is based on this metric.

Feature-based adaptation constructs the metric based on properties of the

flow solution. Adjoint-based adaptation constructs the metric from the flow

and adjoint solutions to reduce estimated errors in a specified output function.

The namelist &adapt metric construction (section B.4.30) for specifying details of the metric.

Fun3D supports a number of grid adaptation libraries. The namelist

&adapt mechanics (section B.4.31) specifies the grid adaptation library and

its options. The refine library is distributed and installed with Fun3D by

default.

7.1 Geometry Specification and Grid Freezing for refine

When adapting a grid with refine, all boundary faces must be specified as

frozen or a geometry definition mush be provided via FAUXGeom. Use the

default patch lumping=’none’ in the &raw grid namelist, as lumping will

change boundary patch indexes making it more difficult to specify geometry.

7.1.1 No geometry, where the surface nodes are frozen.

refine cannot preserve the high aspect ratio structures within viscous layers,

and so viscous layers must be frozen for a specified distance away from the

surface to maintain grid quality. This is invoked with the adapt freezebl

command within the &adaptation mechanics namelist, see section B.4.31 for

more details.

Additionally, specific surfaces that do not have a viscous boundary condition can be frozen by listing the surface numbers (one per line) in a file named

[project rootname].freeze. For example, [project rootname].freeze that

contains

5

7

will freeze points on boundary patches 5 and 7. This is also useful for boundary

surfaces that do not have an analytical definition handled by FAUXGeom.

40
7.1.2 FAUXGeom for Planar Boundaries

For viscous problems, where the mesh on the complex geometry of the body

is frozen, FAUXGeom can be used to provide an analytical definition of the

farfield boundary surfaces. This allows adaptation to occur on the planar surfaces of the mesh, even when the boundary layer mesh is frozen. This is a

particularly important capability for symmetry planes. At present, FAUXGeom can only handle planar surfaces.

FAUXGeom reads the file faux input. Here is an example file:

4

5 xplane -5.0

3 yplane -1.0

1 zplane 1.0

16 general_plane 2.0

0.707 0.707 0.0

The first line is how many faux surfaces are being defined. The subsequent

lines have a face number, type of face, and a distance associated with the

particular geometry. In this example, the first faux face defined corresponds

to surface 5 in the mesh and is a x = −5.0 constant plane. Faux faces are

similarly defined for the z and y planes of surfaces 3 and 1. Surface 16 is

a plane perpendicular to a (0.707, 0.707, 0.0) normal that is located 2.0 away

from the origin in the direction of the normal; the plane passes through the

point (1.414, 1.414, 0.0).

7.2 Performing Feature-Based Adaptation

The &adapt metric construction variable adapt feature scalar form defines the operator that is applied to the adapt feature scalar key to compute an adaptation intensity. This intensity is raised to the adapt exponent

power to produce a scaling of an isotropic element size estimate on the current grid. The anisotropy of the metric is introduced by the Hessian of the

adapt hessian key variable.

Set restart read=’on’ in section B.4.13 to read the flow solution. Run

nodet with the --adapt command line option in the directory with the flow

restart. The result will be a new grid and interpolated solution file with

the adapt project project name. After adaptation, the flow solver can now

be restarted with this new grid and interpolated solution by changing the

project rootname.

7.3 Performing Adjoint-Based Adaptation

Adjoint-based adaptation requires that a flow solution be calculated in the

Flow directory and an adjoint solution be calculated in the Adjoint directory.

41
See section 6 for more information on obtaining an adjoint solution. The

adjoint solution is based on the functional defined in rubber.data and this is

the same functional targeted for grid adaptation.

Adaptation is performed by executing dual with the command line options --rad --adapt. The adjoint solver reads the fun3d.nml in the ../Flow

directory), so this is the place to specify &adapt metric construction and

&adapt mechanics options. The freeze and FAUXGeom files are read in the

current directory, Adjoint.

The result will be a new grid and interpolated solution restart file in the

../Flow directory and an interpolated adjoint restart in the Adjoint directory.

The project name of these new files is adapt project.

7.4 Scripting Grid Adaptation

The Fun3D installation includes the f3d script. To find the other components

of the Fun3D suite, the f3d script expects to be in the bin directory of the

Fun3D installation. Don’t copy or link f3d from the bin directory. The input

file case specifics is described in section 7.4.1.

Execute the f3d script in a directory that contains all of the the input files

(e.g., grid, fun3d.nml, case specifics). The script will create the required

Flow and Adjoint directories to run the case. It has the following commands,

usage: f3d <command>

<command> description

--------- -----------

start Start adaptation

view Echo a single snapshot of stdout

watch Watch the result of view

shutdown Kill all running fun3d and ruby processes

clean Remove output and sub directories

function [name] write rubber.data with cost function [name]

The command start begins adaptation by launching a background job. The

commands view and watch allow the adaptation progress to be monitored.

(Use Ctrl-C to escape the watch command.) The shutdown command kills

all ruby (f3d) and Fun3D jobs. The clean command removes the Flow and

Adjoint subdirectories and the output log file. The function command with

argument creates the rubber.data file to define the adjoint cost function.

7.4.1 Input File case specifics for f3d Script

The f3d script has one input file, named case specifics. Here is an example

42
root_project ''

number_of_processors 2

mpirun_command 'mpiexec'

first_iteration 1

last_iteration 10

# Any text after a number sign is a comment.

where the defaults are listed. Adaptation will be performed from the first grid

adaptation iteration 1 to the last grid adaptation iteration 10. The string in

quotes next to root project is the project root name. A two digit iteration

number will be appended to it. The project name for the first adaptation will

be [root project]01 and the last will be [root project]10. All the files

required to run nodet and dual should be provided in the current directory

and the grid filename should include the root project name and iteration number, [root project]01. Flow and Adjoint subdirectories are created by the

script during execution, and the input files are placed in their correct location

by the script.

Command line options can be passed to the codes via,

all_cl ' '

flo_cl ' '

adj_cl ' '

rad_cl ' '

where all cl is provided to all codes, flo cl is provided to nodet, adj cl

is provided to dual during the adjoint solve, and rad cl is provided to dual

during error estimation and adaptation. For example, the line

adj_cl ' --outer_loop_krylov '

turns on Krylov projection wrapping to stabilize the adjoint solve.

The main input file fun3d.nml provided in the current directory can be

modified by the following commands

all_nl['variable']= value

flo_nl['variable']= value

adj_nl['variable']= value

rad_nl['variable']= value

where all nl changes fun3d.nml for all codes, flo nl for nodet, adj nl for

dual during the adjoint solve, and rad nl for dual during error estimation

and adaptation. An example is

adj_nl['steps']=500

adj_nl['stopping_tolerance']=1.0e-12

43
where the termination criteria of the adjoint solver can be specified separately

than the flow solver.

The case specifics is actually executable Ruby code. This allows values

to be computed or conditionally executed, but also require nested quotes for

character strings,

rad_nl['adapt_complexity'] = 5000*iteration

number_of_processors 128 if (iteration>5)

all_nl['flux_construction'] = "'vanleer'"

44
8 Design Optimization

The Fun3D design framework uses a gradient-based optimization procedure.

One potential approach to obtaining the required sensitivity derivatives is

a conventional forward mode of differentiation, such as finite-differencing,

complex-variable formulations, operator overloading, or direct differentiation.

Since the cost of these techniques scales directly with the number of input parameters, these methods are most efficient for problems where the number of

outputs is considerably larger than the number of inputs. For such problems,

Fun3D provides a complex variable formulation as described in section 8.14.

However, for most aerodynamic design problems, the converse is true; the

number of design variables is typically much larger than the number of objective functions and/or constraints. In this context, an adjoint, or reverse mode

of differentiation is preferred.

Fun3D provides a discrete adjoint capability to efficiently determine the

sensitivities required by a gradient-based design procedure. The adjoint approach enables the user to compute sensitivity derivatives of an output function

with respect to an unlimited number of design variables at a cost equivalent

to a single additional flow solution. For a general review of sensitivity analysis

techniques, see [8] and [9].

The adjoint approach used in Fun3D relies on discrete linearizations of the

relevant components of the flow solver. Most of Fun3D’s compressible perfect

gas and incompressible capabilities are accounted for within the adjoint-based

framework. Discretely consistent sensitivities have been demonstrated for both

steady and unsteady inviscid, laminar, and turbulent flows based on the oneequation model of Spalart and Allmaras. Grid topologies may contain any

combination of element types and may also contain overset grid discretizations.

Grids may be static, non-inertial, or may contain any combination of static,

rigidly-moving, or deforming overset component grids. Both compressible and

incompressible formulations are available. The most commonly-used boundary

conditions are implemented in the adjoint framework, and a broad range of objective/constraint functions is also available. However, the user is encouraged

to review the latest release notes or contact Fun3D-Support@lists.nasa.gov

to determine if a specific analysis capability is currently supported by the adjoint implementation. For a detailed overview of the adjoint-based procedure

used in Fun3D and examples of its use for design optimization, see [10] and

the references contained therein.

Users are encouraged to gain extensive experience using Fun3D for analysis purposes before attempting design optimization. This experience will aid

in properly setting up optimization cases, understanding the steps involved,

and interpreting the results.

The adjoint-based algorithms are very efficient, but a typical optimization

will still require the equivalent of O(20) typical analyses. Therefore, secur45
ing sufficient computational resources is critical to performing realistic highfidelity design. It should also be noted that the various optimization packages

supported by Fun3D may behave very differently for a given design problem;

moreover, the optimal algorithm is generally problem-dependent.

At this time, the documentation provided here is aimed at design optimization of steady flows. The extension to simulations involving unsteady

flows is available for general use (e.g., see [11]), but is not currently covered

here. Please contact Fun3D-Support@lists.nasa.gov if interested in using

this capability.

8.1 Objective/Constraint Functions

To perform a gradient-based optimization, the user must specify at least one

objective function to quantify the merit of the configuration. In the Fun3D

design infrastructure, such objective functions may take a very general form as

described here. Note that all of the supported optimization packages always

seek to minimize the chosen objective function. Care should be taken to pose

the objective function accordingly. Multiple outputs may be accounted for in

a variety of ways. Constraints may be included implicitly within the objective

function(s) as penalty terms. Explicit constraint functions may also be posed,

as either equality or inequality constraints.

Note that the primary limitation in posing the problem statement is the

general ability of the chosen optimization package to handle the design problem posed by the user. For example, the PORT optimization software does

not support the use of explicit constraints. KSOPT is the only supported optimization package that supports the use of more than one objective function;

however, Fun3D offers several approaches to scalarize multiple objectives for

other packages. Multi-point design is also supported in several forms. See

section 8.9 and section 8.10 for specific details on these capabilities.

The Fun3D flow and adjoint solvers do not distinguish between objective

functions and constraints. The solvers themselves merely provide function

values and their sensitivities for use during the optimization procedure. The

actual optimization packages are the only components in the design framework

that make a distinction between objective functions and constraint functions.

8.1.1 Terminology

It is useful to establish some basic terminology when composing the design

problem statement. Within the Fun3D design infrastructure, the user specifies one or more component functions based on typical solver outputs. These

component functions are then combined to form a single composite function.

Multiple component functions may be used to form composite functions, and in

turn, multiple composite functions may ultimately be specified. The user then

46
classifies each composite function, designating it either an objective function

or a constraint function. Again, this distinction is solely for the optimization algorithm; Fun3D simply evaluates and linearizes each of the composite

functions in a generic sense and provides them to the optimization scheme.

The adjoint formulation requires a separate adjoint solution for each composite function. For example, a drag-minimization problem with an explicit

lift constraint will generally require two adjoint solutions at each step of the

design procedure (one based on drag and one based on lift). Rather than performing separate adjoint executions for each function, Fun3D’s adjoint solver

is implemented such that multiple adjoint solutions may be computed simultaneously by cycling through a series of right-hand side vectors. In this manner,

much of the computational overhead associated with discretizing the adjoint

system is amortized over the collection of specified functions, and each additional function only increases the overall computational cost by approximately

40%. See [7] for further details on this aspect of the implementation.

8.1.2 Functional Form

Composite functions take the following general form in Fun3D:

fi =

X

Ji

j=1

ωj (Cj − C

∗

j

)

pj

(1)

Here, the index Ji corresponds to the number of individual component functions comprising composite function i. The factor ωj represents a user-specified

weighting coefficient in the summation; Cjis a Fun3D scalar output quantity,

C

∗

j

is a user-specified target value for that output quantity, and pjis a userspecified exponent. The currently available Fun3D output functions that may

be posed as Cj are listed in Table 10. Though not explicitly represented in

Eq. 1, the implementation also allows the user to only use specific boundary

contributions to Cj and not all boundaries if desired. This could be used to

focus the optimization function on forces acting on the wing or tail only. Note

that when composing an objective or constraint function it is often helpful

to scale the expected value to an O(1) quantity. This can be readily done

using the ωjfactor. Additional details relevant to more complex functions are

covered in section 8.2. The specific input mechanism for providing each of

the component/composite function parameters will be discussed at length in

section 8.6.2.

To demonstrate the use of the general functional form given by Eq. 1,

several examples are given here:

Unconstrained Drag Minimization For an unconstrained problem in

which the user wishes solely to minimize drag, one potential approach might

47
Table 10: Objective/constraint component function keywords.

Keyword Function

cl, cd Lift, drag coefficients

clp, cdp Lift, drag coefficients: pressure contributions

clv, cdv Lift, drag coefficients: shear contributions

cmx, cmy, cmz x/y/z-axis moment coefficients

cmxp, cmyp, cmzp x/y/z-axis moment coefficients: pressure contributions

cmxv, cmyv, cmzv x/y/z-axis moment coefficients: shear contributions

cx, cy, cz x/y/z-axis force coefficients

cxp, cyp, czp x/y/z-axis force coefficients: pressure contributions

cxv, cyv, czv x/y/z-axis force coefficients: shear contributions

powerx, powery, powerz x/y/z-axis power coefficients

clcd Lift-to-drag ratio

fom Rotorcraft figure of merit

propeff Rotorcraft propulsive efficiency

rtr thrust Rotorcraft thrust function

pstag RMS of stagnation pressure in cutting plane disk

boom targ Near-field p/p∞ pressure target

sboom Coupled sBOOM ground-based noise metrics

ae Supersonic equivalent area target distribution

press box RMS of pressure in user-defined box, also pointwise dp/dt, dρ/dt

cpstar Target pressure distributions

be to specify a single composite function consisting of a single component

function with ω1 = 1.0, C1 = cd, C

∗

1 = 0.0, and p1 = 2. In this manner, the

objective function is simply

f = C

2

D, (2)

where the quadratic form has been chosen to provide a convex function space.

Drag Minimization with Lift Penalty To add an interior penalty term

accounting for a lift equality constraint of 0.5, one might instead use two

component functions within the same single composite function where ω1 =

10.0, ω2 = 1.0, C1 = cd, C2 = cl, C

∗

1 = 0.0, C

∗

2 = 0.5, and p1 = p2 = 2. These

parameters yield

f = 10C

2

D + (CL − 0.5)2

. (3)

In this case, any deviation of the lift coefficient from its target value of 0.5

will “penalize” the objective function. The weighting parameters ωj have been

selected based on typical magnitudes of CD and CL, so as to produce roughly

equivalent contributions to the objective function. Note that the choice of

these weighting parameters is heuristic in nature and often troublesome in

practice.

48
Drag Minimization with Explicit Lift Constraint In this example, the

lift constraint CL = 0.5 is instead posed as an explicit constraint for the optimizer. Here, two composite functions are formed, each with a single component

function. First, an objective function is specified as in Eq. 2 with ω1 = 1.0,

C1 = cd, C

∗

1 = 0.0, and p1 = 2. As before, this yields

f1 = C

2

D. (4)

However, an additional composite function for the lift constraint is also specified with ω1 = 1.0, C1 = cl, C

∗

1 = 0.5, and p1 = 1, which gives

f2 = CL. (5)

This explicit form of the lift constraint is generally preferred in practice.

8.2 Some Details on Specific Objective/Constraint

Functions

Many of the scalar functions shown in Table 10 and designed to be used as the

term Cjin Eq. 1 are straightforward. For example, the keyword cd is sufficient

to characterize a drag-based component function. However, some of the scalar

functions listed in Table 10 require the user to be aware of specific requirements

and/or to provide additional auxiliary data. In this section, scalar functions

requiring further data and/or explanation are covered.

8.2.1 Lift-to-Drag Ratio (Keyword: clcd)

This function must be specified with a 0 for its boundary index, i.e., it must be

applied to the entire configuration and is not available for individual boundary

patches. It is defined as

f =

CL

CD

. (6)

8.2.2 Rotorcraft Figure of Merit (Keyword: fom)

This function is defined as

f =

C

3

L

2C2

Mz

. (7)

Note that this functional form assumes that the rotor axis of rotation is in

the +z direction. The definition also represents the square of the traditional

Figure of Merit function. See [12] for a motivation for this modified form.

This function must be specified with a 0 for its boundary index, i.e., it must be

applied to the entire configuration and is not available for individual boundary

patches.

49
8.2.3 Rotorcraft Propulsive Efficiency (Keyword: propeff)

This function is defined as

f =

−Cz

CMz

. (8)

Note that this functional form assumes that the rotor axis of rotation is in

the +z direction. The minus sign has been introduced to yield a positive

efficiency since CMzis negative. This function must be specified with a 0 for

its boundary index, i.e., it must be applied to the entire configuration and is

not available for individual boundary patches.

8.2.4 Rotorcraft Thrust (Keyword: rtr thrust)

This function is defined as the force normal to the plane of a rotor system:

f = CL cos(θT ) − CD sin(θT ) (9)

where the angle from +z-direction θT in radians is the variable thrust angle

that must be set in the source file LibF90/custom transforms.f90.

8.2.5 RMS of Stagnation Pressure (Keyword: pstag)

This function computes the RMS of stagnation (total) pressure in a circular disk that passes through the grid in a specified location and orientation.

This is commonly employed to quantify engine inlet distortion. The user must

specify the variables in the &pstag function namelist within fun3d.nml. See

section B.4.37 for details related to this namelist. This function is only available for compressible flows.

8.2.6 Near-field p/p∞ Pressure Target (Keyword: boom targ)

This function allows inverse design of near-field pressure signatures, which is a

commonly used tactic for creating low sonic boom configurations. This function is only available for compressible flows. The user specifies yz-coordinate

pairs through which rays are passed parallel to the x-axis. Off-body pressure

distributions in the vicinity of an aircraft are nominally oriented parallel to

the freestream velocity vector. In the case of a nonzero angle of attack, the

rays are rotated about a user-specified center of rotation to align them with

the freestream direction. The user also provides the minimum and maximum

x-extent for the rays. A user-specified number of points are evenly distributed

along each ray and the grid element containing each point is identified. See

section B.4.33 for guidance on the required namelist inputs.

The functional form is given by

50
f =

X

N

i=1

ωi



p

p∞









i

−

p

p∞









∗

i

2

(10)

where p is the local static pressure. The summation takes place over all points

in the rays defined by the user, and the values of p are evaluated at the

centroids of the enclosing elements. The values of ωi and p

p∞







∗

i

are user-supplied

pointwise weighting coefficients and target values of p/p∞, respectively, which

must be provided in a file named pressure target.dat. If this file is not

present, the target values of p/p∞ are set to 1.0 and the weighting coefficients

are set to 1.0. Note that with the above functional form, the target and

exponent parameters present in Eq. 1 are usually set to 0.0 and 1, respectively.

A template for pressure target.dat is typically generated by first extracting a set of p/p∞ distributions for a known configuration by running the

optimization driver with Operation to perform set to 1 (“Analysis only”)

in ammo.input. Note that the input value weight must be set to .true.

and the desired ray extraction (y, z) coordinate pairs must be specified in the

&sonic boom namelist in fun3d.nml. This operation produces a file named

pressure signatures.dat, which uses the same file format intended for the

pressure target.dat target input file. (Note that the file format is amenable

to Tecplot usage.) The user may then use the pressure signatures.dat

file to develop a pressure target.dat input file by modifying the existing

pressures to reflect their target values as desired. Note that by specifying

weight=.true. in the &sonic boom namelist, a column of data representing

pointwise weighting coefficients (all initially set to 1.0) will be provided in

pressure signatures.dat. This column of data is required to be present in

pressure target.dat. The individual weights may be left as 1.0, or they

may be modified on an individual basis to optionally weight a specific region

of the signature more or less in the final objective function. A brief example

of this file format for a case involving two off-body signatures is shown below.

Note that target distributions need not have the same number of locations as,

nor line up with, the eventual sampling locations along the extraction rays.

Fun3D will linearly interpolate between input target values to obtain values

at the sampling locations.

VARIABLES = "x", "y", "z", "p/pinf", "weight"

zone t="Signal 1"

-0.500E+01 0.100E-11 0.826E+00 0.110010E+01 0.100E+01

-0.472E+01 0.100E-11 0.835E+00 0.110011E+01 0.100E+01

-0.415E+01 0.100E-11 0.855E+00 0.110012E+01 0.100E+01

-0.354E+01 0.100E-11 0.876E+00 0.110016E+01 0.100E+01

zone t="Signal 2"

-0.500E+01 0.100E-11 0.182E+01 0.102008E+01 0.100E+01

-0.472E+01 0.100E-11 0.183E+01 0.102008E+01 0.100E+01

-0.414E+01 0.100E-11 0.185E+01 0.102009E+01 0.100E+01

51
-0.356E+01 0.100E-11 0.187E+01 0.102012E+01 0.100E+01

-0.335E+01 0.100E-11 0.188E+01 0.105013E+01 0.100E+01

-0.320E+01 0.100E-11 0.188E+01 0.105014E+01 0.100E+01

-0.264E+01 0.100E-11 0.190E+01 0.105017E+01 0.100E+01

8.2.7 Coupled sBOOM Ground-Based Signatures, Noise Metrics,

and Equivalent Areas (Keyword: sboom)

This option uses the adjoint capability of the Burgers equation boom propagation code sBOOM [13] to inversely design ground pressure signatures,

optimize a ground-based noise metric, or match equivalent area distributions.

[14–16] Fun3D must be configured and built with the sBOOM library as

described in section A.7.13 to use this capability.

In the coupled Fun3D-sBOOM implementation, Fun3D is responsible

for computing pressure signals in the immediate vicinity of an aircraft (typically within 10 body lengths). The sBOOM tool then propagates these disturbances to the ground using an augmented Burgers equation that considers

effects such as non-linearity, thermo-viscous absorption, and any number of

molecular relaxation phenomena during the propagation of waveforms through

the atmosphere. In this manner, the user can directly simulate ground-based

noise metrics such as A-weighted loudness or compute other loudness measures

(e.g., Perceived Level) from the computed ground signatures. In a similar fashion, a coupled adjoint problem is used to determine the discrete sensitivities

of the ground-based metrics with respect to any of Fun3D’s typical design

parameters which may then be used to optimize the configuration.

sBOOM can generate off-track signatures based on ray theory using user

input azimuthal angles. sBOOM can also predict the sonic boom signatures

in the presence of wind, turn rate (changing heading angle), climb rate, climb

angle, and acceleration (dMach/dt). During maneuvering flight, boom focusing is possible. The current version sBOOM in not able model focusing and

will exit with an appropriate message if focusing occurs.

Equivalent area distributions are computed with reversed augmented Burgers equation (when rs< (alt−hg)) or a direct conversion of off-body pressures

(when rs> (alt−hg)). This is different than the Mach cut equivalent area

matching approach in section 8.2.8. The discrete sensitivities of the difference

between a target and the computed equivalent areas are provided to Fun3D.

The target area is specified with the target dpress and target xx variables

in the &sboom namelist.

The user must provide inputs relevant to the nearfield pressure signal extraction (see section B.4.33) as well as parameters specific to the sBOOM

library (see section B.4.34). Note that when the sboom keyword is used as

the component function name, the actual form of the objective/constraint

component function is determined entirely within sBOOM. In this case, the

values of ω, C

∗

, and p in Eq. 1 are ignored. This function is only available for

52
compressible flows.

8.2.8 Supersonic Mach Cut Equivalent Area Distribution

(Keyword: ae)

This function aims to match a target Mach cut equivalent area distribution for

supersonic flows. The Mach cut equivalent area distribution is directly computed from surface pressures and geometry for this function. This is a different

approach than the equivalent area computation of sBOOM in section 8.2.7.

The function is defined as

f =

X

N

i=1

ωi(Li + Vi − A

∗

i

)

2

(11)

where N represents the total number of longitudinal stations used to sample

the solution and geometry for the current azimuth, and Li and Vi are the lift

and volume contributions, respectively, to the current equivalent area. The

term A∗

i

represents the user-supplied target equivalent area distribution. The

ωi enables the user to locally weight individual segments of the distribution

if desired. Note that with the above functional form, the target and exponent parameters present in Eq. 1 are usually set to 0.0 and 1, respectively.

This function is only available for compressible flows, and the configuration is

assumed to align with the x-axis.

Any number of desired azimuthal (centerline/off-track) locations may be

specified and used as individual component functions. The user must provide the data indicated in the &equivalent area namelist in fun3d.nml as

described in section B.4.35. A centerline symmetry plane may be used to

reduce computational expense; in this case, the cutting planes at each longitudinal station will be correctly accounted for on the virtual side of the aircraft.

A file ae target.dat must also be provided, which describes the (optionally

weighted) target equivalent area profiles.

A template for ae target.dat is typically generated by first extracting a

set of equivalent area distributions for a known configuration by running the

optimization driver with Operation to perform set to 1 (“Analysis only”) in

ammo.input. This operation will produce a Tecplot file [project rootname]

ae.dat which uses the same file format intended for the target input file

ae target.dat. The user may then use the [project rootname] ae.dat file to

develop a ae target.dat input file by modifying the existing equivalent areas

to reflect their target values as desired. Note that the file [project rootname]

ae.dat contains a column of data representing the pointwise weighting coefficients ωi (all initially set to 1.0). This column of data is required to be present

in ae target.dat. The individual weights may be left as 1.0, or they may be

modified on an individual basis to optionally weight a specific region of the

distributions more or less in the final objective function. A brief example of

53
this file format for a case involving three azimuthal signatures is shown below.

Note that target distributions need not have the same number of locations as,

nor line up with, the longitudinal sampling locations. Fun3D will linearly

interpolate between input target values to obtain values at the sampling locations. Also note that in the input file ae target.dat, the second and third

columns of the format are ignored.

VARIABLES = "x", "V", "L", "Ae", "weight"

zone t="Ae Function 1"

-0.01000E+00 0.00000E+00 0.00000E+00 0.00000E+00 0.10000E+01

0.13839E+01 0.25482E-01 -0.26289E-02 0.22853E-01 0.10000E+01

0.27678E+01 0.47548E-01 -0.64155E-02 0.41133E-01 0.10000E+01

0.41517E+01 0.76165E-01 -0.10361E-01 0.65804E-01 0.10000E+01

zone t="Ae Function 2"

-0.01000E+00 0.00000E+00 0.00000E+00 0.00000E+00 0.10000E+01

0.14018E+01 0.25700E-01 -0.26610E-02 0.23039E-01 0.10000E+01

0.28036E+01 0.48215E-01 -0.64628E-02 0.41752E-01 0.10000E+01

0.42054E+01 0.77379E-01 -0.10358E-01 0.67020E-01 0.10000E+01

0.56072E+01 0.11457E+00 -0.14045E-01 0.10052E+00 0.10000E+01

0.98126E+01 0.30728E+00 -0.25726E-01 0.28156E+00 0.10000E+01

zone t="Ae Function 3"

-0.01000E+00 0.00000E+00 0.00000E+00 0.00000E+00 0.10000E+01

0.14155E+01 0.26009E-01 -0.26166E-02 0.23392E-01 0.10000E+01

0.28310E+01 0.48902E-01 -0.62883E-02 0.42614E-01 0.10000E+01

0.42465E+01 0.78591E-01 -0.10011E-01 0.68579E-01 0.10000E+01

Finally, the solver will also provide the user with a Tecplot output file

[project rootname] ae cuts i.dat for the ith specified equivalent area function. These files contain the actual cross-sectional slices of the aircraft that

were generated for each azimuthal function.

8.2.9 RMS of Pressure in User-Defined Box, Pointwise dp/dt,

dρ/dt (Keyword: press box)

This function computes the RMS of a quantity in Cartesian region, which is

typically used to indicate a region of the flow is important for grid adaptation

or that fluctuations in a region should be minimized in a design. These functions rely on the inputs associated with the &press box function namelist;

see section B.4.36 for details. The function may be composed of the RMS

value of the pressure within a user-defined box in the domain, or for unsteady

simulations, the time derivative of pressure or density (for compressible flows)

at a single grid point.

8.2.10 Target Pressure Distributions (Keyword: cpstar)

Fun3D has an inverse design capability where the objective function may

be composed of target pressure distributions. The file containing the jth

54
target distribution must be named cpstar.data.j. However, setup is tedious, primarily due to the difficulty in specifying pressure distributions on

a three-dimensional configuration. If this capability is of interest, please contact Fun3D-Support@lists.nasa.gov for more detailed guidance.

8.3 Geometry Parameterizations

In order to perform shape optimization, Fun3D must be provided with a

set of design variables describing the geometric shape of the configuration.

Fun3D is currently set up to interface directly with geometry parameterizations provided by MASSOUD [17], Bandaids [18], or Sculptor. MASSOUD

and Bandaids are software packages developed by Jamshid Samareh of NASA

Langley (Jamshid.A.Samareh@nasa.gov). Users should contact him for copies

of the software; tutorial information for these tools is available on the Fun3D

website. These packages allow the user to parameterize completely arbitrary

shapes using a free-form deformation technique. The packages are very efficient, robust, and also provide analytic Jacobians of the parameterization,

which are necessary for Fun3D-based design. Sculptor is a popular commercial package developed by Optimal Solutions and also provides the necessary

data for Fun3D-based design. Note that any combination of parameterizations based on these tools may be used within the context of a single optimization. For example, the planform of a wing or tail surface may be best treated

using MASSOUD, while Bandaids or Sculptor may be most appropriate for

a wing-body fillet region or a feature such as a fuselage protuberance. Finally,

the user may also use a parameterization scheme of their choosing; see section

section 8.3.4 for further details.

8.3.1 Surface Grid Extraction

To parameterize a surface grid using any of the above tools, it must first be

extracted to a Tecplot file. To do this, add a &massoud output namelist

to fun3d.nml to group all of the required boundary patches for a body to be

parameterized into a single body (see also section B.4.32):

&massoud_output

n_bodies = 2 ! parameterize 2 bodies: wing and tail

nbndry(1) = 6 ! # of bounds that comprise wing

boundary_list(1) = '3-8' ! wing bounds (account for lumping!)

nbndry(2) = 3 ! # of bounds that comprise tail

boundary_list(2) = '9,10,12' ! tail bounds (account for lumping!)

/

Note that the boundary indices shown here must reflect any patch lumping that may have been requested in the &raw grid namelist (see also section B.4.2). A single iteration of the flow solver should now be executed

55
with the --write massoud file command line option. This will generate a

[project rootname] massoud bndry#.dat file for each of the boundary groups

present in the &massoud output namelist. These files contain the information

necessary to parameterize the surface grid using any of the aforementioned

tools. See the documentation for those packages for further instructions on

how to construct the actual parameterization.

8.3.2 Access to Executables

If MASSOUD, Sculptor, or a user-defined executable is being used for parameterizations, the executable for those packages must be available in the runtime

PATH. The executables for MASSOUD and Sculptor must be named massoud

and sculptor, respectively. If using a user-defined parameterization package

(see section 8.3.4), the executable must be named according to the input provided in ammo.input (see section 8.5.1). The optimization driver supplied with

Fun3D will attempt to call these executables if such parameterization types

are present. If Bandaids are being used, no additional executables must be

supplied; all Bandaid evaluations are handled internally by Fun3D.

8.3.3 Notes on Using Sculptor

If Sculptor is being used, Fun3D will invoke Sculptor in batch (non-GUI)

mode during the course of the optimization. However, current versions of

Sculptor will still attempt to communicate with an X server, even when run

in this fashion. If the system does not run an X server (such as compute nodes

on a cluster), then a fake X server such as Xvfb is recommended. You will

need to execute the fake server prior to running the design optimization. For

example, a run script may have the following commands:

Xvfb :1 &

export DISPLAY=:1.0 # for bash

setenv DISPLAY :1.0 # for c shell

[any command that uses Sculptor]

The syntax here may vary; if this does not allow the optimization driver to

run Sculptor in batch mode successfully on the system, the user should get

in touch with Sculptor support for assistance.

In addition, the parameterization of all bodies treated using Sculptor

must be bookkept within a single set of Sculptor input files. For example,

in the wing-tail example above, both bodies must be contained in a single instance of Sculptor files. Therefore, the &massoud output namelist described

above should group all of the desired boundaries necessary to describe the

geometry(s) of interest into a single body:

56
&massoud_output

n_bodies = 1 ! wing and tail grouped into a body

nbndry(1) = 9 ! # of tail and wing bounds

boundary_list(1) = '3-10,12' ! wing and tail boundaries

/

Each of the desired bodies may be worked on independently within Sculptor, but they must ultimately appear as a single body to Fun3D.

8.3.4 Using Other Parameterization Packages

Fun3D provides a generic interface for user-defined external geometric parameterization packages. The user-defined tool must provide the surface mesh

coordinates as a function of some vector of design variables for the body of

interest. The partial derivatives of these coordinates with respect to the design

variables must also be supplied. See [19] for an example of such an approach.

To invoke a user-defined parameterization package for one or more bodies

present in the simulation, the user must tag individual bodies appropriately

(see section 8.6.2) and provide the executable name to be invoked by Fun3D’s

design driver at run-time via the input deck ammo.input (see section 8.5.1).

This may be a binary executable or simply a script that invokes other userdefined operations that may be necessary to evaluate the parameterization and

its sensitivities.

When Fun3D requires an evaluation of the user-defined parameterization

for a body (or its sensitivities), it will first write a file named customDV.i, where

the i suffix corresponds to the body index for which Fun3D is requesting

updated surface data. The format of the customDV.i file is as shown below.

#User defined design variables

#Number of DVs

3

1.907460000000000E+00

0.000000000000000E+00

-0.002469800000000E+00

The first two lines are comment lines, and the third specifies the total number

of design variables in the parameterization for the current body (whether the

user may have designated some active and others inactive in rubber.data; see

section 8.6.2). The remaining lines in the file contain the current value of each

design variable, with one value per line.

After writing the customDV.i file, Fun3D will then invoke the user-specified

executable command provided in ammo.input. Fun3D will append a space and

a single integer to this executable command, where the integer corresponds to

57
the body index for which Fun3D requires an evaluation of the parameterization. The user-provided executable (or script) must be capable of parsing this

integer command-line option in order to process the requested body.

After the external package has completed the evaluation of the parameterization and its sensitivities, the data must be supplied to Fun3D via a Tecplot

file named model.tec.i.sd1, where the integer i in the filename represents the

current body index. The format of this file must be as follows:

TITLE = "PARAMETERIZATION DATA"

VARIABLES = "X" "Y" "Z" "ID" "XD1" "YD1" "ZD1" "XD2" "YD2" "ZD2" "XD3" "YD3" "ZD3"

ZONE T = group0, I = 4, J = 1, F=FEPOINT

0.0 1.0 0.0 235 1.234 -23.0 892.1 -23.0 82.123 -90.2 -905.2 857.12 348.2

1.0 1.0 0.0 872 4.14 -0.123 -0.324 23.13 2978.2 -0.114 -982.4 -3.22 0.1185

1.0 0.0 0.0 912 -0.34 0.938 8.45 78.23 -35.2 -0.023 8.32 -0.009 -0.92

0.0 0.0 0.0 455 9.01 -8.23 -0.456 2.56 1.21 0.0 -0.091 -1.22 0.0088

1 2 3 4

The trivial (and completely contrived) example shown here provides surface mesh point locations and the corresponding sensitivities for a single quad

element parameterized by three design variables. The title in the first line may

contain anything the user desires. The variables identified in line 2 represent

the x-, y-, and z-coordinates for the current surface mesh point, the node index in the global grid for the current surface mesh point, and the sensitivity

derivatives of the x-, y-, and z-coordinates of the current surface mesh point

with respect to each of the design variables provided by Fun3D in customDV.i

above. The file should contain a single zone, indicated by the third line of the

example file shown. Here, the zone title specified by T = may be anything the

user desires. The I = value corresponds to the number of surface mesh points

for the current body, while the J = value specifies the number of surface elements (triangles or quads) contained in the surface mesh for the current body.

Fun3D will only read the I = value; the surface mesh topology is immaterial

in this context.

In this example, the floating point values have been truncated for readability; users are strongly encouraged to provide double-precision values in

practice. The connectivity information at the end of the file is not used by

Fun3D. It may be omitted if desired; however, it is often instructive to load

this file into Tecplot for visualization. In that context, the connectivity data

(including the appropriate J = value in the file header) will be required.

For very large surface meshes and/or parameterizations containing a very

large number of design variables, I/O of this ASCII format can be inefficient.

There is an alternative C-binary/Fortran stream format that may be used in its

place; interested users should get in touch with Fun3D-Support@lists.nasa.gov

for further details on this option.

To support execution of the user-defined parameterization tool, auxiliary

files may be provided in the description.i directory; the filenames should

be provided in the file user def param files.data (see section 8.6.1).

58
8.4 Design Optimization Directory Structure

The optimization driver opt driver requires a very specific directory structure. It can be established by running opt driver in an interactive mode

with the --setup design command line option. The number of design points

should be 1 for single-point design or greater than 1 for multi-point design.

opt_driver --setup_design [number of design points]

This interactive command will prompt the user for several directory paths

required by the optimization, namely the paths to the Fun3D source code,

the configuration directory where Fun3D was configured and built, and the

path to the location where the design will be performed. Here, directories

should be provided as absolute paths contained in single quotes, with trailing

slashes omitted, i.e.,

'/absolute/path'

At the completion of this setup procedure, a summary of the files required

from the user will be echoed to the screen. The directories created in the

specified run location are shown in Table 11. The i suffix in description.i

Table 11: Directory structure required for Fun3D-based design.

Directory Description

ammo Location where optimization will be executed

description.i Location of all baseline input files describing design point i

model.i Location where analysis & sensitivity analysis of design point i will be performed

and model.i represents the design point index. For single-point design, this

will be 1; for multi-point design, this value will range from 1 to the number

of user-specified design points. The setup procedure will populate the various

directories with links to the required Fun3D executables and templates for

various input files described below.

8.5 Contents of the ammo Directory

The ammo directory will contain files related to the optimization procedure

itself. This includes the ammo.input input file and a link to the opt driver

executable.

8.5.1 ammo.input

The input parameters contained in this file control the actual optimization

procedure. A template of the file will be installed during the setup procedure;

an example is also provided below.

59
Optimization package

4

Base directory from which to run optimization

'/home/user/TestAMMO'

Number of design points

2

Weights for each design point

1.0

1.5

Operation to perform

1

Restart the optimization

0

Maximum number of flow solves

10

Maximum number of design cycles

5

Relative convergence criterion for subproblem

1.e-5

Absolute feasibility tolerance for constraint violation

110.0

Number of bodies with spatial transforms

2

List of bodies with spatial transforms

2 3

Body grouping desired

0

Executable for running MPI programs

'mpirun'

Number of processors from which to run adjoint solver

1024

DOT method

0

User-defined parameterization executable name

'MyParameterizationExecutable'

The various inputs specified in the ammo.input input file are described below. Care should be taken to preserve the structure of this file when modifying

its contents.

Optimization package This scalar integer specifies the optimizer to be

used. The available choices are (1) DOT/BIGDOT, (3) KSOPT, (4) PORT,

(5) NPSOL, and (6) SNOPT. Note that the PORT package does not support the use of explicit constraints. Also note that Fun3D must be configured

and built against the selected library.

Base directory from which to run optimization This should be an

absolute path to the design location specified during the setup procedure.

Path should be enclosed in single quotes and contain no trailing slashes.

60
Number of design points This scalar integer is the number of design points

to be considered during the optimization. The value should be at least 1 and

less than or equal to the number of design points specified during the setup

procedure.

Weights for each design point A non-negative real-valued scalar should

be specified on separate lines for each design point. The value represents the

weighting to be applied in the linear combination of objective functions from

each individual design point as used to construct the final composite objective

function (see section 8.10). For single point optimization, a single value of 1.0

should be specified.

Operation to perform This scalar integer specifies what operation the

optimization driver should perform. The valid values are (1) Analysis only,

(2) Analysis and sensitivity analysis, and (3) Optimization.

Restart the optimization This scalar integer specifies whether to start the

optimization from the baseline problem description (0), or to restart the optimization from a previous optimization run already executed in this directory

(1).

Maximum number of flow solves This scalar integer is only relevant for

PORT-based optimizations and sets an upper limit on the number of flow

solutions allowed during the design.

Maximum number of design cycles This scalar integer sets an upper

limit on the number of design cycles the optimizer may perform.

Relative convergence criterion for subproblem This scalar real value is

only relevant for DOT/BIGDOT- and PORT-based optimizations and specifies the relative function convergence criterion for which the optimization will

terminate.

Absolute feasibility tolerance for constraint violation This scalar real

value is only relevant for optimizations based on the DOT/BIGDOT, NPSOL,

and SNOPT packages. The value specifies the feasibility tolerance for constraints.

Number of bodies with spatial transforms This scalar integer specifies

the number of MASSOUD-parameterized bodies for which spatial transforms

should be applied. See also section 8.6.10.

61
List of bodies with spatial transforms This is a list of integers separated by spaces specifying the MASSOUD-parameterized bodies to which

spatial transforms are to be applied. There should be Number of bodies

with spatial transforms entries in this list. If Number of bodies with

spatial transforms is zero, this line of data should not be present. See also

section 8.6.10.

Body grouping desired This scalar integer specifies whether any body

grouping should be applied. A value of 0 indicates no grouping should be applied; a value of 1 indicates grouping should be applied. See also section 8.6.4.

Executable for running MPI programs This single character string enclosed in single quotes will be used as a prefix when running MPI programs.

This is usually mpirun or mpiexec, depending on the MPI implementation, or

perhaps aprun on Cray® systems.

Number of processors from which to run adjoint solver This scalar

integer specifies the number of processors on which to execute the adjoint

solver. Normally this is the same number of processors requested for the job

and used for the flow solver. However, in the event of a split communicator

in the flow solver (for Suggar++, VisIt, dedicated file I/O, etc), the adjoint

solver must be run on the same number of processors that the actual flow

solver was run on (does not include processors set aside for split communicator

functionalities).

DOT method This scalar integer is only used for DOT/BIGDOT-based

optimization and specifies the optimization method to be used with DOT/BIGDOT.

See the DOT/BIGDOT documentation for further information.

User-defined parameterization executable name This string should be

enclosed in single quotes and represents the name of the executable (or script)

to be launched if user-defined geometric parameterizations are to be used. The

executable should be available in the users PATH. See also section 8.3.4.

8.6 Contents of the description.i Directory

The description.i directory serves as a repository for the baseline files for

the CFD model, the geometric parameterization, and several other input files

related to the computational model for the ith design point. These files must

be set up by the user prior to the run and will not be modified by Fun3D during execution. During the initial setup procedure, templates for several input

files will be placed in this location to aid in setting up the case. During the

62
actual optimization, the optimization driver will copy files from this directory

into the model.i directory as needed.

Any files normally required by the flow solver must be present in this

directory. This would typically include the grid and boundary condition files

and fun3d.nml. If the mesh uses overset grids assembled with the Suggar++

utility, the Suggar++ DCI file must be present as well. The optional file

remove boundaries from force totals (section B.3) may also be present, if

desired.

In addition to the files normally required by the flow solver, a number of

other files must also be present to perform the design optimization, some of

which are optional. These are described below.

8.6.1 Geometry Parameterization Files

If performing shape optimization, the user must provide the relevant parameterization files for each body in the mesh to be modified. The specific set of

files required for each body depends on the parameterization package(s) being

used.

MASSOUD Parameterizations For MASSOUD parameterizations, the

MASSOUD parameterization files should be named design.gp.j, where j is

the index of the body to be designed. The files specifying the values of the

raw MASSOUD variables should be named design.j for each of the bodies

to be designed. For Fun3D-based design, the custom design variable linking

feature of MASSOUD must be used. If the raw MASSOUD variables are

intended to be used as-is, simply set the linking matrix as the identity matrix

in the MASSOUD .usd file. These files specifying the design variable linking

for each body should be named design.usd.j.

The MASSOUD control file specifies the names of the files outlined above

for MASSOUD and must be provided as massoud.j for the jth body. The

files listed in the MASSOUD control file must reflect these names. The first

line of the MASSOUD control file(s) must have a positive integer equal to

the number of custom design variables. If the intent is simply to use the raw

MASSOUD variables as-is, this value is simply the number of raw MASSOUD

variables for that body. For the in/out-of-core parameter, use in-core (0).

The file name for Tecplot output viewing must be named model.tec.j for

the jth body. The design variable grouping file specified should be named

designVariableGroups.j for the jth body. The FAST output file name can be

named anything the user wishes; the Fun3D tools do not use this MASSOUD

output file. Finally, the user design variable file for the jth body should be

named customDV.j. In summary, a massoud.j control file for the jth body

should look like the following:

63
#MASSOUD INPUT FILE

# runOption 0-analysis, >0-sd users dvs, -1-sd massouds dvs

52

# core 0-incore solution, 1-out of core solution

0

# input parameterized file

design.gp.1

# design variable input file

design.1

# input sensitivity file - used for runOption > 0

design.usd.1

# output file grid file

newframe.fast.1

# output Tecplot file for viewing

model.tec.1

# file containing the design variables group

designVariableGroups.1

# user design variable file

customDV.1

Bandaid Parameterizations For Bandaid parameterizations, the input

files created by the Bandaid setup tool should be named bandaid.data.j for

the jth body. Because Bandaid parameters behave linearly, the sensitivities

contained in these files are constant and this input is all that is required during

the course of a design.

Sculptor Parameterizations For Sculptor parameterizations, the user

must provide [project rootname].mdf, [project rootname].sd1, [project rootname]

.vol, and [project rootname].stu files. See the Sculptor documentation

for more details on each of these files. A file named [project rootname].def

must also be provided. An example [project rootname].def file for a simple

two-body parameterization is shown below:

set_mdf [project_rootname].mdf

default 1 DV1-T1 0.00

default 1 DV1-T2 0.00

default 1 DV1-T3 0.00

default 1 DV1-T4 0.00

default 1 DV1-T5 0.00

default 2 DV2-T1 0.00

default 2 DV2-T2 0.00

default 2 DV2-T3 0.00

export model.tec.1

exit

64
The filename specified for the export command must be model.tec.1. The

remainder of the file is dictated by the specific parameterization developed in

the Sculptor application.

After the configuration has been parameterized using Sculptor and all of

the appropriate files have been assembled for Fun3D-based design, a copy

of the original [project rootname] massoud bndry#.dat file must also be

placed in the description.i directory, but with the file name changed to

[project rootname].sd1. Sculptor requires this baseline file during the optimization.

Finally, prior to performing the design, the [project rootname].sd1 file

must be read into Sculptor in GUI mode as “Import Mesh/CFD as Tecplot Point FE.” Following this, the Sculptor volumes need to be imported

onto the [project rootname].sd1 file, and then the model must be saved

again. Once this is done, the command export model.tec.1 within the

[project rootname].def batch script will generate a model.tec.1.sd1 file as

needed for Fun3D-based design optimization.

User-Defined Parameterizations In the event that a user-defined geometric parameterization package is to be used, the user must provide a file

user def param files.data. Since Fun3D will not be aware of any auxiliary

files that may be needed by the user-defined parameterization package, those

files should be listed here, with a single file name per line. Each file named

here must be provided by the user. At run time, Fun3D will move the named

files to the appropriate location prior to execution of the parameterization

executable indicated by the user in ammo.input. See also section 8.3.4 and

section 8.5.1.

8.6.2 rubber.data

This section describes how to set up each block of the design control file

rubber.data. The template provided in the Adjoint directory of the source

code distribution is installed in the description.i directory during setup.

This file serves as the primary control file during the course of the optimization and stores all of the high-level information relevant to the design. The file

is repeatedly read and updated by the various tools during the design procedure. A simple example of this file to be used for discussion purposes is shown

below.

################################################################################

########################### Design Variable Information ########################

################################################################################

Global design variables (Mach number, AOA, Yaw, Noninertial rates)

Var Active Value Lower Bound Upper Bound

Mach 0 0.800000000000000E+00 0.000000000000000E+00 0.900000000000000E+00

AOA 1 1.000000000000000E+00 0.000000000000000E+00 5.000000000000000E+00

Yaw 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

65
xrate 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

yrate 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

zrate 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

Number of bodies

2

Rigid motion design variables for 'wing'

Var Active Value Lower Bound Upper Bound

RotRate 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

RotFreq 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

RotAmpl 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

RotOrgx 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

RotOrgy 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

RotOrgz 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

RotVecx 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

RotVecy 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

RotVecz 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

TrnRate 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

TrnFreq 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

TrnAmpl 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

TrnVecx 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

TrnVecy 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

TrnVecz 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

Parameterization Scheme (Massoud=1 Bandaids=2 Sculptor=4 User-Defined=5)

1

Number of shape variables for 'wing'

3

Index Active Value Lower Bound Upper Bound

1 1 1.000000000000000E+00 0.000000000000000E+00 2.000000000000000E+00

2 1 1.000000000000000E+00 0.000000000000000E+00 2.000000000000000E+00

3 1 1.000000000000000E+00 0.000000000000000E+00 2.000000000000000E+00

Rigid motion design variables for 'tail'

Var Active Value Lower Bound Upper Bound

RotRate 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

RotFreq 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

RotAmpl 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

RotOrgx 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

RotOrgy 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

RotOrgz 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

RotVecx 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

RotVecy 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

RotVecz 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

TrnRate 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

TrnFreq 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

TrnAmpl 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

TrnVecx 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

TrnVecy 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

TrnVecz 0 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00

Parameterization Scheme (Massoud=1 Bandaids=2 Sculptor=4 User-Defined=5)

2

Number of shape variables for 'tail'

2

Index Active Value Lower Bound Upper Bound

1 1 2.000000000000000E+00 -1.000000000000000E+00 5.000000000000000E+00

2 1 2.000000000000000E+00 -1.000000000000000E+00 5.000000000000000E+00

################################################################################

############################### Function Information ###########################

################################################################################

Number of composite functions for design problem statement

2

################################################################################

Cost function (1) or constraint (2)

1

If constraint, lower and upper bounds

0.0 0.0

Number of components for function 1

66
1

Physical timestep interval where function is defined

1 1

Composite function weight, target, and power

1.0 0.0 1.0

Components of function 1: boundary id (0=all)/name/value/weight/target/power

0 cl 0.000000000000000 1.000 10.00000 2.000

Current value of function 1

0.000000000000000

Current derivatives of function wrt global design variables

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

Current derivatives of function wrt rigid motion design variables of body 1

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

Current derivatives of function wrt shape design variables of body 1

0.000000000000000

0.000000000000000

0.000000000000000

Current derivatives of function wrt rigid motion design variables of body 2

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

Current derivatives of function wrt shape design variables of body 2

0.000000000000000

0.000000000000000

################################################################################

Cost function (1) or constraint (2)

2

If constraint, lower and upper bounds

-0.03 -0.01

Number of components for function 2

1

Physical timestep interval where function is defined

1 1

Composite function weight, target, and power

67
1.0 0.0 1.0

Components of function 2: boundary id (0=all)/name/value/weight/target/power

0 cmy 0.000000000000000 1.000 0.00000 1.000

Current value of function 2

0.000000000000000

Current derivatives of function wrt global design variables

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

Current derivatives of function wrt rigid motion design variables of body 1

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

Current derivatives of function wrt shape design variables of body 1

0.000000000000000

0.000000000000000

0.000000000000000

Current derivatives of function wrt rigid motion design variables of body 2

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

0.000000000000000

Current derivatives of function wrt shape design variables of body 2

0.000000000000000

0.000000000000000

Global Design Variable Data This section of rubber.data lays out global

design variables for the computation. These include the freestream Mach number, angle of attack, and angle of yaw. For simulations using a noninertial reference frame, the noninertial rotation rates about each of the three Cartesian

coordinate axes are also available as design variables.

Quantities associated with each variable are specified on their own row

in the file and have several attributes that must be set by the user. The first

column is a dummy index and is merely to assist the user in quickly navigating

68
through the file. The second column is a toggle to activate the design variable.

If this value is a 1, the variable will be allowed to change during the design.

If the value is assigned a 0, this variable will be held constant at the value

specified. For incompressible flows and mixed-element grids, the Mach number

must be declared inactive. Similarly, for flows posed in the inertial reference

frame, the noninertial rates must be declared inactive.

The third column in the design variable block is the current value for

this design variable. The values of any active variables in this file will take

precedence over other input decks during design. For example, the flow solver

will run an angle of attack of 1 degree in this case, regardless of what may be

specified in fun3d.nml. Columns four and five specify the upper and lower

bounds for the current design variable.

Body-Specific Design Variable Data The next input following the Mach

number and angle of attack entries specifies the number of bodies for which

the user has provided shape parameterizations. Note that not every body in

the grid must be included here. If the wing of an aircraft is the sole focus of

the optimization, there is no need to account for other boundaries such as the

tail or fuselage here.

Following the number of bodies, there should be two blocks of design variables for each desired body, namely a list of rigid motion variables controlling

the dynamics of the body, and a set of shape parameters controlling the shape

of the body. The columns of inputs are identical to those described above for

Mach number and angle of attack.

The bodies present in the computation may be listed in any order; however, the order of their appearance in this control file must match the integer

suffix on their parameterization files that are provided in the description.i

directory, as well as files such as body grouping.data, transforms.j, etc.

The first section for the current body specifies design variables governing

rigid body motion and is only applicable for time-dependent problems. For

optimization of steady flows and/or static geometries, the rigid motion data

is irrelevant but must be present in this file. These variables should be set as

inactive in these cases.

The next block of inputs relates to the shape parameterization for the

current body. First, the parameterization scheme is identified by a scalar

integer. The following values are available: (1) MASSOUD, (2) Bandaids,

(4) Sculptor, and (5) User-Defined. The next input specifies the number of

parameterized shape variables on the current body and the subsequent lines

lay out the design variable information for that body. A row of data must

be provided for every variable in the parameterization, whether it is active

or not. (Note however, that internally, the optimizer is only made aware of

the variables marked as active.) If a parameterization contains 25 variables,

then 25 rows must appear in this corresponding block of rubber.data, even if

69
only a subset is active. If the design variable linking feature in MASSOUD or

Bandaids has been used to create additional derived variables, they must also

appear here. Note that the “Active” attribute for shape variables may take

values of not only 0 or 1, but also −1 in certain multi-point design scenarios

(see section 8.10).

Care should be taken in choosing upper and lower bounds for shape variables. Optimizers tend to fully explore the design space, which may result in

infeasible shapes (or extreme shapes the mesh movement/solvers cannot handle robustly). Set these limits conservatively; one can always restart a design

with less restrictive bounds.

As noted previously, when using Sculptor parameterizations for multiple

bodies, all such design variables must appear as a single concatenated body in

rubber.data.

Cost Function/Constraint Specification The first line following the design variable block specifies the total number of composite functions to be used

as objectives or constraints for the current design point. Multiple composite

objective functions may be specified in certain cases; see section 8.9. Otherwise, a single composite objective function must be specified. The example

file shown here contains a single composite objective function based on the

lift coefficient and a single explicit constraint based on the pitching moment.

Note that explicit constraints may only be specified if the optimization package

chosen in ammo.input supports them.

Following the scalar value specifying the total number of composite objectives and constraints, each composite function and/or constraint will have a

block of data associated with it. Objective functions and constraints may be

specified in any order.

The first two inputs in the composite function block specify a scalar integer

indicating how the current function is to be viewed by the optimizer. The two

subsequent inputs represent lower and upper bounds on the function if it is

to be used as a constraint. If the function is an objective function, the first

input value should be 1, and the lower and upper bounds must be present but

their values are irrelevant. However, if the current function is to be used as

a constraint, special attention must be paid to these inputs depending on the

optimization package being used.

Constraints Using NPSOL and SNOPT If the current function

is to be used as an inequality constraint, the first input should be 2, and

the lower and upper bounds should be set to their appropriate values. If the

current function is to be used as an equality constraint, the first input should

be 2; however, the lower and upper bounds should both be set equal to the

desired constraint value.

70
Constraints Using KSOPT and DOT/BIGDOT These optimization packages assume constraint functions of the form f ≤ 0, such that the

bound of the feasibility region is implicit in the function definition and the

lower and upper bound inputs must be present but are not used. If the current function is intended as an inequality constraint, the first input should be

2. If the current function is intended as an equality constraint, the first input

value should be 3. In this case, Fun3D’s design driver will provide the current

function to the optimizer as an inequality constraint, but will also bookkeep

an equal and opposite function as an additional inequality constraint. In this

manner, an equality constraint is achieved by only allowing the intersection of

the two inequality constraints as feasible.

Following the classification of the current function, the next line states how

many component functions comprise the current composite function. This can

be any positive integer greater than or equal to 1. Following the number of

component functions, the user must specify the physical time step interval over

which the function is to be applied. This input is only relevant to optimization

of unsteady flows. For steady flows, the values of these two inputs are ignored

but must be present.

The weight, target, and power to be applied to the current composite

function are specified next. These values are only relevant when combining

multiple composite objective functions into a single global objective function

(see section 8.9). For all other cases, these values should be specified as 1.0,

0.0, and 1.0, respectively.

At this point, each component function that contributes to the current

composite function has a line specifying several pieces of data. The first column is the boundary patch over which to apply the current component. This

index corresponds directly to the boundary patches in the CFD grid, and

must reflect any patch lumping that is indicated in the &raw grid namelist

in fun3d.nml (see section B.4.2). If a component function is to be used over

the entire grid (total drag, for example), simply put a 0 in this column. Alternatively, if a single boundary patch is to be targeted, one might apply the

component function to only that patch. Several patches may be targeted by

including a component function for each. The next column is the keyword for

the aerodynamic quantity to be used for the current function component. For

a list of available keywords, see section 8.1. The next column contains the current value of the current function component. This is an output value during

the optimization and need not be set by the user. The final three columns in

the row correspond to the weight, target value, and power to be applied to the

current component function in constructing the overall composite function.

Current Function Value and Sensitivities Following the specification of

the component functions, the next line of rubber.data contains the current

71
value of the composite function. This is an output and need not be set by the

user.

The remaining lines in the current function block contain the sensitivity

derivatives with respect to all of the design variables listed in the top half of the

file. This section is divided into derivatives with respect to the global design

variables, as well as the rigid motion and shape design variables for each of the

bodies laid out in the top portion of the file. These derivatives are outputs set

by Fun3D and not by the user. However, a line for each design variable (both

global variables as well as body-specific variables) must be provided in each

composite function block present. The values do not matter, but the solvers

need positions available in the file to store the current values.

8.6.3 ae target.dat (optional)

If the function keyword ae is specified anywhere in rubber.data, the file

ae target.dat must be present prior to performing the optimization. This file

provides the target equivalent area distribution(s) for each of the azimuthal

locations specified in the &equivalent area namelist in fun3d.nml (in the

same order). See section 8.2.8 and section B.4.35.

8.6.4 body grouping.data (optional)

This file is used to specify body grouping information. For example, if the

objective function is the Figure of Merit FM for a three-bladed rotor, then

the three blades (each typically specified as a separate parameterized body in

rubber.data) should be associated into one group, so that sensitivity derivatives will reflect a composite ∂(FM)/∂D for all three blades. This capability

requires that the bodies to be associated all have identical parameterizations

(same number of design variables on each body, etc). The format of the

body grouping.data file is as follows:

Number of groups to create

1

Number of bodies in group, list of bodies

3

1 2 3

The first scalar integer specifies the number of groups to create (i.e., one rotor).

The next set of inputs specifies the number of bodies in each group, followed

by the bodies that comprise that group (i.e., each of the three rotor blade

bodies).

72
8.6.5 command line.options (optional)

The command line.options file specifies any command line options to be used

with the flow solver, the adjoint solver, or the MPI job launcher (mpirun,

mpiexec, aprun, etc). An example of this file is shown below.

3

1 flow

'--rmstol 1.e-7'

1 adjoint

'--rmstol 1.e-3'

2 mpirun

'-nolocal'

'-machinefile ../machinefile'

The first line of the file specifies the number of programs for which command

line options are being provided. The subsequent line must contain an integer

followed by a keyword. The integer specifies how many command line options

are being provided for the code identified by the keyword. The valid keywords

are flow, adjoint, and mpirun. This line is followed by a line for each of the

command line options provided for the code identified by the keyword. Each

command line option should appear in single quotation marks on its own line.

The specified programs and their associated command line options may appear

in any order.

8.6.6 cpstar.data.j (optional)

Fun3D has an inverse design capability where the objective function may

be composed of target pressure distributions. The file containing the jth

target distribution must be named cpstar.data.j. However, setup is tedious, primarily due to the difficulty in specifying pressure distributions on

a three-dimensional configuration. If this capability is of interest, please contact Fun3D-Support@lists.nasa.gov for more detailed guidance.

8.6.7 files to save.data (optional)

If desired, users may indicate specific files produced by the flow and adjoint

solvers to be archived during an optimization. For example, custom visualization files may be produced at each design iteration (see section 5.3.1) to

enable animations of the design history after the optimization is complete.

To specify certain files to be archived during the course of a design execution, the user may provide the optional file files to save.data in the

description.i directory. Each line of the file consists of one of two keywords, either “Flow” or “Adjoint”, followed by the specific name of a file to

73
be archived. For example, the following inputs could be used to archive Tecplot files containing solution data on boundaries for both the flow and adjoint

solvers, while also saving two additional Tecplot files containing user-specified

sampling data for the flow solution:

Flow [project_rootname]_tec_boundary.dat

Flow [project_rootname]_tec_sampling_geom1.dat

Flow [project_rootname]_tec_sampling_geom2.dat

Adjoint [project_rootname]_tec_boundary.dat

At the end of each function evaluation (i.e., flow solution) for the ith design

point, the files [project rootname] tec boundary.dat, [project rootname]

tec sampling geom1.dat, and [project rootname] tec sampling geom2.dat

will be stored in the model.i/Flow/SaveFiles directory, with an integer corresponding to the current design iteration appended to each of the filenames.

Similarly, the file [project rootname] tec boundary.dat will be stored in the

model.i/Adjoint/SaveFiles directory at the completion of each sensitivity

analysis (i.e., adjoint solution).

8.6.8 machinefile (optional)

If the optimization will be executed in an environment which requires an explicit list of machines on which the MPI jobs will be executed, this file must

be present. It should take the format required of the particular MPI implementation being used. If the optimization will be executed in an automated

queuing environment, the job scheduler normally assigns the machines to be

used at runtime and this file is therefore not required.

8.6.9 pressure target.dat (optional)

If the function keyword boom targ is specified anywhere in rubber.data, the

file pressure target.dat must be present prior to performing the optimization. This file provides the nearfield target p/p∞ distribution(s) for each of

the off-body locations specified in the &sonic boom namelist in fun3d.nml (in

the same order). See section 8.2.6 and section B.4.33.

8.6.10 transforms.i (optional)

Since MASSOUD uses a coordinate system specific to an assumed aircraft

orientation, it is sometimes necessary to reorient a body from its physical

position to a MASSOUD-aligned coordinate system and vice-versa. Examples

might include a vertical tail or the various blades of a rotor system. The file

describing the transform for the ith body should be included as transforms.i.

The format of a typical transforms.i file is as follows:

74
ROTATE 0.0 0.0 1.0 -120.0

This would rotate the MASSOUD parameterization for the ith body by −120

degrees about a unit vector in the +z direction. The commands TRANSLATE

and SCALE are also available.

8.7 Contents of the model.i Directory

Just as for the description.i directories, the i in the model.i naming convention represents the design point index. This value is 1 for single point design

or the design point index for multi-point design. The model.i directory contains the subdirectories Flow, Adjoint, and Rubberize. During the course

of the design procedure, Fun3D will evaluate the relevant parameterizations

and perform flow and adjoint solutions within these locations. These subdirectories are populated during the initial setup procedure with links to the

required executables from the user’s Fun3D installation. Files in the model.i

subdirectories should not be modified by the user, although one may wish to

observe various solver output files during the course of the optimization. All

user-provided inputs are confined to files located in the description.i and

ammo directories.

8.8 Running the Optimization

Once all of the required inputs and files have been provided, the user should

first request a single function evaluation from the optimization driver. This is

strongly recommended in order to identify any potential issues in the various

inputs. To perform this check, set the value of Operation to perform in

ammo.input to 1, and execute the optimization driver from the ammo subdirectory:

opt_driver > screen.output &

Here, the output from the optimization driver has been redirected to a file

called screen.output. This file is very useful if a problem needs to be diagnosed with the execution. It is also good practice to include this file with help

requests to Fun3D-Support@lists.nasa.gov.

At the completion of the function evaluation, the user should check for the

desired/expected result. This is also a good opportunity to establish reasonable values for the number of time steps to run, the residual tolerance at which

the solver should quit, and so forth. Such run control parameters may be set

in fun3d.nml or via the command line.options file.

Once the function evaluation procedure has been verified, the user should

perform the same test for a sensitivity analysis by setting Operation to

perform in ammo.input to 2 and re-executing the optimization driver. Similar

75
checks on convergence parameters, etc for the adjoint solver should be noted

and applied to the relevant input files.

With successful function and gradient evaluations in hand, an actual optimization may be initiated. The value of Operation to perform in ammo.input

should be set to 3, and the optimization driver can be executed as before. The

user should closely monitor the screen output as the process proceeds, especially during the first several design cycles when input parameters may first

cause problems. The largest changes in design variables often occur early on

as well, which can cause issues with mesh movement operations, solver convergence, and other aspects. It is also very useful to occasionally filter the

screen output for the current function value(s) reported at the completion of

each flow solution in order to monitor overall progress:

grep "Current value of function" screen.output

When an optimization completes, the optimizer will report the reason for

the termination to the screen, which may be a local minimum, or some problem encountered during the simulation. A summary of the optimization is

provided by each optimization package in the file(s) noted in Table 12. The

final set of design variables and function/constraint values determined by the

optimizer will be available in model.i/rubber.data. To track the history of the

optimization, a backup of all intermediate copies of rubber.data are stored

in the directory model.i/Rubberize/surface history. Intermediate copies

of the surface grids developed during the design process are also stored in this

location as model.tec.j.sd1.iter, where j is the body index, and iter is the

design iteration. These files may be used to produce animations of the surface

history if desired. Using the broad range of visualization output options for

the solvers, the user has great freedom to produce customized animations of

the design history (see section 8.6.7).

Table 12: Files containing design summary from various optimization packages.

Optimization Package Summary File(s)

DOT/BIGDOT dot.output

KSOPT ksopt.output

PORT port.output

NPSOL npsol.printfile, npsol.summaryfile

SNOPT snopt.printfile, snopt.summaryfile

8.8.1 Filesystem Latency Problems

Design optimization using some cached file systems may experience problems

due to the rapid execution of the various tools during the design process. In

some cases, a file system lag may cause some processes to receive older/stale

76
versions of files during execution. Specifying the --sleep delay [seconds]

command line option to the opt driver executable will pause the optimization

process with a sleep duration of seconds between subsequent code executions

to allow the file system to perform correctly. On older systems, delays as large

as 60 seconds are sometimes necessary; more recent systems seem to perform

considerably better and values of 5-10 seconds are often sufficient.

8.9 Multi-objective Design

KSOPT, PORT, and SNOPT are the only packages currently supported for

use with multi-objective design. Details on the usage for each package are

provided below.

8.9.1 KSOPT

KSOPT is the only supported optimization package with explicit support for

multiple objective functions. When using KSOPT, the user may designate any

number of composite functions as objective functions in rubber.data.

8.9.2 PORT, SNOPT

The Fun3D design driver offers a simple approach to scalarizing multiple userspecified objective functions for use with the PORT or SNOPT packages. If

multiple composite functions are specified in rubber.data, the Fun3D design

driver will combine them using the weight, target, and power values specified

at the composite function level (i.e., the input values that appear just before

the component function data is specified in rubber.data, see section 8.6.2). If

N composite functions f are labeled as objective functions in rubber.data, the

scalarized objective function F to be provided to the optimization procedure

will take the form

F = α1(f1 − f

∗

1

)

p1 + α2(f2 − f∗

2

)

p2 + ... + αN (fN − f∗

N )

pN (12)

where αi, f

∗

i

, and pi are the weight, target, and power values associated with

each composite function in rubber.data.

8.10 Multi-point Design

The Fun3D design infrastructure offers several approaches to multi-point optimization. This refers to design problems where the user may wish to simultaneously optimize a configuration for operations at two different conditions

— perhaps the beginning and end of a cruise segment for example, where the

aircraft weight may be substantially different. The user may also wish to design for cruise and takeoff or landing (or all three). The various design points

77
may be characterized by different flow conditions (i.e., speed, angle of attack,

etc), or more generally, by the geometries (and therefore grids) at each point.

For example, one design point may consist of a cruise geometry operating at

Mach 0.8, while another design point may be a landing configuration operating

at Mach 0.2 with a high-lift system deployed. For examples of Fun3D-based

multi-point design in practice, see the studies in [12] and [20]. In these references, a tilt-rotor geometry has been optimized for a set of several blade

collective settings as well as hover and forward flight conditions.

To perform a multi-point optimization, the user must request the desired

number of design points when setting up the directory structure where the

design will be performed (see section 8.4). The user must populate each of the

description.i directories for each design point i just as in the single-point

design context. The order of the design points does not matter. The value

of Number of design points in ammo.input should be set appropriately. Ultimately, Fun3D provides several ways to formulate the multi-point design

problem. These approaches are outlined below.

In general, the optimizer will be seeking a unique set of design variables

to simultaneously achieve goals at all of the design points. For this reason, a

consistent set of design variables across all design points must be used. This

applies to the global variables Mach number and angle of attack as well as any

body-specific variables such as shape parameters. For example, if a set of 15

thickness variables is provided for a wing shape in cruise, other design points

(again, perhaps a landing configuration as an example) must utilize the same

set of 15 thickness variables. Moreover, the same subset of design variables

must be active at each design point.

Multi-valued Design Variables In some situations, the user may desire

different optimal values of a design variable at different design points. For

example, consider power minimization for a rotor in hover at two different

weight conditions, where each of the two design points may have different

minimum thrust coefficients posed as constraints. In addition to other design

variables that may be present, the user may have a shape parameter controlling

the blade collective setting (blade pitch). However, rather than constraining

the optimal blade collective to a single unique value, the user may desire

separate, optimal values for each design point. As another example, consider

a configuration with an ability to actively morph its outer mold line. In this

case, the user may wish to determine optimal values of the shape parameters

that are unique to different design points.

To accommodate such multi-valued design variables, the user may set the

“Active” attribute for individual shape design variables to −1 in rubber.data

(see section 8.6.2). If this is done, it must be applied consistently for that

same variable across all design points. For variables with this attribute, the

Fun3D design driver will internally bookkeep separate values of the variable

78
for each design point. This feature is currently only available for use with the

SNOPT package.

8.10.1 Linear Combination of Objective Functions

The most straightforward approach to multi-point design is to linearly combine

individual objective functions fifrom each of the N design points i into a single

global objective function fmp:

fmp = α1f1 + α2f2 + α3f3 + ... + αN fN (13)

To perform the optimization in this fashion, a single composite objective function should be posed in each description.i/rubber.data file. Each of the αi

weighting coefficients must be specified as Weights for each design point

in ammo.input, in the corresponding order.

This form of multi-point design is supported by PORT, DOT/BIGDOT,

and SNOPT. Note that PORT and SNOPT will also combine multiple

objective functions within each design point as described in section 8.9 if desired. Explicit constraints can be posed at each design point when using

DOT/BIGDOT or SNOPT; such constraints are each treated individually.

8.10.2 Combination of Objective Functions using the KreisselmeierSteinhauser Function

Another alternative for performing multi-point design is the approach inherent in the KSOPT package. In this approach, all objective functions and

constraints are combined using the Kreisselmeier-Steinhauser (KS) function.

The user is referred to [21] for the details of this formulation. Here, the Fun3D

design driver gathers any number of objective and constraint functions across

all design points and provides them to KSOPT, which internally constructs

its KS function for the actual optimization problem.

8.10.3 Single-Point Objective Function with Off-Design Constraint

Functions

In this approach to multi-point design, a single objective function is provided

to the optimizer, while all other functions are treated as explicit constraints.

Here, the user should designate a single composite function across all of the

description.i/rubber.data input files as an objective function. Any other

composite functions at each design point should be designated as constraint

functions. KSOPT, SNOPT, and NPSOL support this form of multi-point

optimization; SNOPT can also construct the final objective function by linearly combining multiple objective functions within the desired design point

as described in section 8.9.

79
8.11 Optimization of Two-Dimensional Geometries

While the Fun3D flow solver supports a 2D mode of operation, this capability

is not currently available from within the design infrastructure. Instead, the

optimization must be performed as a pseudo-3D case. The user should provide a nominally two-dimensional grid, with a single layer of elements in the

spanwise (y) direction. The mesh should consist of either prisms or hexahedra

(or both), but should contain no pyramids or tetrahedra. Follow the same

procedure used for 3D cases to extract the surface grid for parameterization.

The surface should be parameterized just as for a 3D simulation; however, the

parameterization should allow no spanwise asymmetries in the geometry to

develop. When using MASSOUD or Bandaids, this is readily accomplished

by linking the raw parameters with an equal weighting across the span into a

single set of design variables that operate in a chordwise fashion. Note that

the sidewalls should use symmetry y boundary conditions so that only in-plane

mesh deformation occurs during the optimization. The design may now be executed as usual, with the 2D nature of the problem enforced implicitly through

the parameterization.

8.12 Using a Different Optimization Package

In a CFD-based design context, the term “function” implies an evaluation of

the geometric parameterization, mesh movement (both surface and volume),

a flow solution, and an evaluation of the output function/constraint for a

given set of design variables. The file manipulations and solver operations

necessary to achieve this are not trivial. For users interested in using the

tools as “black boxes” providing function data for an optimization package, a

wrapper has been provided in the LibF90 directory of the distribution named

analysis.f90. This module contains a subroutine called perform analysis()

which performs the extensive set of tasks involved with producing the final

desired function output.

To obtain sensitivities, the Fun3D package relies on a discrete adjoint formulation. As with function evaluations, the low-level operations required to

perform an adjoint-based sensitivity analysis are numerous. A wrapper routine

called perform sensitivity analysis() in the LibF90/sensitivity.f90

module will perform an adjoint solution for the flow field, an adjoint solution for the mesh movement scheme, an evaluation of the linearized geometric

parameterization, and finally produce the desired sensitivity derivatives.

The Fun3D design driver uses the wrappers perform analysis() and

perform sensitivity analysis() to greatly simplify function and gradient

evaluations when connecting to off-the-shelf optimization packages. If the

user wishes to implement a new optimization strategy, it is highly recommended that these wrappers be used in a similar fashion. A review of the

80
existing modules in the Design directory of the Fun3D source code distribution, which implement the currently available optimization interfaces, is also

strongly suggested. Users may contact Fun3D-Support@lists.nasa.gov for

further guidance in leveraging Fun3D’s capabilities from within their own

existing design framework.

8.13 Implementing New Cost Functions/Constraints

Implementation of new cost functions or constraints is not a trivial undertaking and requires extensive modification of Fun3D source code. Experience

in Fortran 2003, unstructured-grid discretizations, development in a domaindecomposed/distributed-memory environment, and general CFD methods are

essential. Routines to evaluate the proposed function and linearizations of the

function with respect to both the flow field variables and grid are ultimately

required. The complex-variable form of Fun3D (see section 8.14) is invaluable in verifying the accuracy of these linearizations. It is highly recommended

that the user contact Fun3D-Support@lists.nasa.gov for guidance prior to

attempting the implementation of a new cost function or constraint.

8.14 Forward Mode Differentiation Using Complex

Variables

The reverse, or adjoint, mode of differentiation is primarily used for design

with Fun3D. A forward mode of differentiation is also provided based on the

use of complex variables [22–24]. This capability is useful for design problems

containing few design variables and many cost functions or constraints. To

generate and build a complex-variable Fun3D executable, see section A.5.

The complex-valued flow solver reads the usual real-valued grid files and is

set up to compute derivatives of every output variable with respect to Mach

number, angle of attack, shape parameters, non-inertial rotation rates, or the

x, y, or z coordinate of a single grid point (others are trivial to add). This

choice is controlled by the file perturb.input. A template for this file is

provided in the FUN3D 90 directory and an example is also shown below.

PERTURB EPSILON GRIDPOINT

2 1.e-50 666

0 = No perturbation

1 = Mach number

2 = Alpha

3 = Shape

4 = x-rotation rate

5 = y-rotation rate

6 = z-rotation rate

81
7 = Grid point x

8 = Grid point y

9 = Grid point z

10 = Yaw

100+ = add an imaginary source term to equation

PERTURB-100 of node GRIDPOINT

(to verify the adjoint lambda value)

The value of PERTURB specifies the variable for which sensitivities will be

taken with respect to. The valid integer values are as shown above. The input

EPSILON specifies the magnitude of the imaginary perturbation to be applied.

The recommended value is 1.e-50. If the value of PERTURB is greater than

six, the value of GRIDPOINT specifies the grid point index to perturb. The

remaining lines in perturb.input are not read; they are simply reminders of

the valid inputs just described. The complex-valued flow solver may then be

executed in a manner similar to the real-valued flow solver:

mpirun ./complex_nodet_mpi

To compute derivatives with respect to a shape parameterization variable, the

sensitivities of the parameterization must first be evaluated in the directory

model.i/Rubberize using the relevant parameterization software. The value

of PERTURB should be set to 3 in perturb.input.The complex-valued flow

solver can then be executed in the following fashion:

mpirun ./complex_nodet_mpi --dv_index [body] [dv] --snap_grid

Here, the values of body and dv specify the body and design variable index in

rubber.data to which to apply the imaginary perturbation. The --snap grid

argument forces the flow solver to propagate the surface sensitivities into the

volume mesh using Fun3D’s elasticity-based deformation mechanics.

At the completion of the complex-valued flow solve, outputs will contain

both real and imaginary parts. The imaginary part represents the sensitivity

of that output with respect to the perturbation variable that was specified in

perturb.input.

82
References

1. Advisory Group for Aerospace Research and Development: Experimental Data Base for Computer Program Assessment: Report of the Fluid

Dynamics Panel Working Group 04. NATO Research and Technology Organisation AGARD AR-138, Jan. 1979.

2. Anderson, W. K.; and Bonhaus, D. L.: An Implicit Upwind Algorithm

for Computing Turbulent Flow on Unstructured Grids. Comp. & Fluids,

vol. 23, no. 1, Jan. 1994, pp. 1–21.

3. Alexandrov, N.; Atkins, H. L.; Bibb, K. L.; Biedron, R. T.; Gnoffo, P. A.;

Hammond, D. P.; Jones, W. T.; Kleb, W. L.; Lee-Rausch, E. M.; ; Nielsen,

E. J.; Park, M. A.; Raman, V. V.; Roberts, T. W.; Thomas, J. L.; Vatsa,

V. N.; Viken, S. A.; White, J. A.; and Wood, W. A.: Team Software Development for Aerothermodynamic and Aerodynamic Analysis and Design.

NASA TM-2003-212421, 2003.

4. Hecht, F.: The Mesh Adapting Software: BAMG. INRIA Report, 1998.

http://www-rocq1.inria.fr/gamma/cdrom/www/bamg/eng.htm.

5. Carlson, J.-R.: Inflow/Outflow Boundary Conditions with Application to

FUN3D. NASA TM-2011-217181, NASA Langley Research Center, Oct.

2011.

6. Peir ́o, J.; Peraire, J.; and Morgan, K.: FELISA System Version 1.1 Reference Manual Part 2–User Manual. University of Wales/Swansea Technical

Report CR/822/94, Aug. 1994.

7. Nielsen, E.; Lu, J.; Park, M.; and Darmofal, D.: An Implicit, Exact

Dual Adjoint Solution Method for Turbulent Flows on Unstructured Grids.

Computers and Fluids, vol. 33, no. 9, 2004, pp. 1131–1155.

8. Newman III, J.; Taylor, A.; Barnwell III, R.; Newman, P.; and Hou, G.-

W.: Overview of Sensitivity Analysis and Shape Optimization for Complex

Aerodynamic Configurations. Journal of Aircraft, vol. 36, no. 1, 1999,

pp. 87–96.

9. Peter, J.; and Dwight, R.: Numerical Sensitivity Analysis for Aerodynamic

Optimization: A Survey of Approaches. Computers and Fluids, vol. 39,

no. 3, 2010, pp. 373–391.

10. Nielsen, E.; and Diskin, B.: Discrete Adjoint-Based Design for Unsteady

Turbulent Flows on Dynamic Overset Unstructured Grids. AIAA Journal,

vol. 51, no. 6, 2013, pp. 1355–1373.

83
11. Jones, M.: CFD Analysis and Design Optimization of Flapping Wing

Flows. Ph.D. Thesis, North Carolina A&T State University, June 2013.

12. Nielsen, E.; Lee-Rausch, E.; and Jones, W.: Adjoint-Based Design of Rotors in a Noninertial Reference Frame. AIAA Journal of Aircraft, vol. 47,

no. 2, 2010, pp. 638–646.

13. Rallabhandi, S. K.: Advanced Sonic Boom Prediction Using the Augmented Burgers Equation. AIAA Journal of Aircraft, vol. 48, no. 4, July–

Aug. 2011, pp. 1245–1253.

14. Rallabhandi, S.: Sonic Boom Adjoint Methodology and its Applications.

AIAA Paper 2011–3497, 2011.

15. Rallabhandi, S.; Nielsen, E.; and Diskin, B.: Sonic Boom Mitigation

Through Aircraft Design and Adjoint Methodology. AIAA Paper 2012–

3220, 2012.

16. Rallabhandi, S.: Application of Adjoint Methodology to Supersonic Aircraft Design Using Reversed Equivalent Areas. AIAA Paper 2013–2663,

2013.

17. Samareh, J. A.: Novel Multidisciplinary Shape Parameterization Approach. AIAA Journal of Aircraft, vol. 38, no. 6, Nov.–Dec. 2001,

pp. 1015–1024.

18. Samareh, J. A.: Aerodynamic Shape Optimization Based on Free-From

Deformation. AIAA Paper 2004–4630, 2004.

19. Nielsen, E.; and Jones, W.: Integrated Design of an Active Flow Control

System Using a Time-Dependent Adjoint Method. Mathematical Modeling

of Natural Phenomena, vol. 6, no. 3, 2011, pp. 141–165.

20. Jones, W.; Nielsen, E.; Lee-Rausch, E.; and Acree Jr., C.: Multi-point

Adjoint-Based Design of Tilt-Rotors in a Noninertial Reference Frame.

AIAA Paper 2014–290, 2014.

21. Wrenn, G. A.: An Indirect Method for Numerical Optimization using

the Kreisselmeir-Steinhauser Function. NASA CR-4220, NASA Langley

Research Center, Mar. 1989.

22. Lyness, J. N.: Numerical Algorithms Based on the Theory of Complex

Variables. Proceedings of the ACM 22nd National Conference, Thomas

Book Co., 1967, pp. 124–134.

23. Lyness, J. N.; and Moler, C. B.: Numerical Differentiation of Analytic

Functions. J. Numer. Anal., vol. 4, 1967, pp. 202–210.

84
24. Anderson, W. K.; Newman, J. C.; Whitfield, D. L.; and Nielsen, E. J.: Sensitivity Analysis for the Navier-Stokes Equations on Unstructured Meshes

Using Complex Variables. AIAA J., vol. 39, no. 1, Jan. 2001, pp. 56–63.

See also AIAA Paper 99-3294.

25. Biedron, R. T.; and Thomas, J. L.: Recent Enhancements to the FUN3D

Flow Solver For Moving-Mesh Applications. AIAA Paper 2009–1360, 2009.

26. Anderson, W. K.; Rausch, R. D.; and Bonhaus, D. L.: Implicit/Multigrid

Algorithms for Incompressible Turbulent Flows on Unstructured Grids.

J. Comput. Phys., vol. 128, no. 2, 1996, pp. 391–408.

27. Sutton, K.; and Gnoffo, P. A.: Multi-Component Diffusion with Application to Computational Aerothermodynamics. AIAA Paper 98-2575, June

1998.

28. Park, M. A.: Anisotropic Output-Based Adaptation with Tetrahedral Cut

Cells for Compressible Flows. Ph.D. Thesis, Massachusetts Institute of

Technology, Sept. 2008.

29. Venkatakrishnan, V.: Convergence to Steady State Solutions of the Euler

Equations on Unstructured Grids with Limiters. Journal of Computational

Physics, vol. 118, no. 1, 1995, pp. 120–130.

30. Spalart, P. R.; and Allmaras, S. R.: A One-Equation Turbulence Model

for Aerodynamic Flows. La Recherche Aerospatiale, vol. 1, no. 1, 1994,

pp. 5–21.

31. Catris, S.; and Aupoix, B.: Density Corrections for Turbulence Models.

Aerospace Science and Technology, vol. 4, no. 1, Jan. 2000, pp. 1–11.

32. Spalart, P. R.; Jou, W.-H.; Strelets, M.; and Allmaras, S. R.: Comments

on the Feasibility of LES for Wing and on a Hybrid RANS/LES Approach.

Proceedings of the First ASOSR Conference on DNS/LES, Aug. 1997.

33. Allmaras, S. R.; Johnson, F. T.; and Spalart, P. R.: Modifications and

Clarifications for the Implementation of the Spalart-Allmaras Turbulence

Model. Seventh International Conference on Computational Fluid Dynamics (ICCFD7), 2012.

34. Menter, F. R.: Two-Equation Eddy-Viscosity Turbulence Models for Engineering Applications. AIAA Journal, vol. 32, no. 8, Aug. 1994, pp. 1598–

1605.

35. Menter, F. R.: Improved two-equation k-omega turbulence models for

aerodynamic flows. NASA TM-103975, Oct. 1992.

85
36. Wilcox, D. C.: Reassessment of the Scale-Determining Equation for Advanced Turbulence Models. AIAA Journal, vol. 26, no. 11, Nov. 1988,

pp. 1299–1310.

37. Wilcox, D. C.: Formulation of the k-ω Turbulence Model Revisited. AIAA

Journal, vol. 46, no. 11, Nov. 2008, pp. 2823–2838.

38. Langtry, R. B.; and Menter, F. R.: Correlation-Based Transition Modeling for Unstructured Parallelized Computational Fluid Dynamics Codes.

AIAA Journal, vol. 47, no. 12, Dec. 2009, pp. 2894–2906.

39. Dacles-Mariani, J.; Zilliac, G. G.; Chow, J. S.; and Bradshaw, P.: Numerical/Experimental Study of a Wingtip Vortex in the Near Field. AIAA

Journal, vol. 33, no. 9, Sept. 1995, pp. 1561–1568.

40. Dacles-Mariani, J.; Kwak, D.; and Zilliac, G.: On Numerical Errors and

Turbulence Modeling in Tip Vortex Flow Prediction. International Journal

for Numerical Methods in Fluids, vol. 30, no. 1, 1999, pp. 65–82.

41. Shur, M. L.; Strelets, M. K.; Travin, A. K.; and Spalart, P. R.: Turbulence

Modeling in Rotating and Curved Channels: Assessing the Spalart-Shur

Correction. AIAA Journal, vol. 38, no. 5, May 2000, pp. 784–702.

42. Spalart, P. R.; Deck, S.; Shur, M. L.; Squires, K. D.; Strelets, M. K.; and

Travin, A.: A New Version of Detached-eddy Simulation, Resistant to Ambiguous Grid Densities. Theoretical and Computational Fluid Dynamics,

vol. 20, no. 3, July 2006, pp. 181–195.

43. Vatsa, V. N.; and Lockard, D. P.: Assessment of Hybrid RANS/LES

Turbulence Models for Aeroacoustics Applications. AIAA Paper 2010–

4001, 2010.

44. Carpenter, M. H.; Viken, S. A.; and Nielsen, E. J.: The Efficiency of High

Order Temporal Schemes. AIAA Paper 2003–86, 2003.

45. Vatsa, V. N.; Carpenter, M. H.; and Lockard, D. P.: Re-evaluation of an

Optimized Second Order Backward Difference (BDF2OPT) Scheme for

Unsteady Flow Applications. AIAA Paper 2010–122, 2010.

46. Lee-Rausch, E. M.; Frink, N. T.; Mavriplis, D. J.; Rausch, R. D.; and

Milholen, W. E.: Transonic Drag Prediction on a DLR-F6 Transport Configuration Using Unstructured Grid Solvers. AIAA Paper 2004–556, 2004.

47. Alauzet, F.; and Loseille, A.: High-Order Sonic Boom Modeling Based

on Adaptive Methods. Journal of Computational Physics, vol. 229, no. 3,

2010, pp. 561–593.

86
48. Barth, T. J.: Recent Developments in High Order K-Exact Reconstruction

on Unstructured Meshes. AIAA Paper 93–668, 1993.

49. Alauzet, F.: Size Gradation Control of Anisotropic Meshes. Finite Elements in Analysis and Design, vol. 46, no. 1–2, 2010, pp. 181–202.

50. Venditti, D. A.: Grid Adaptation for Functional Outputs of Compressible

Flow Simulations. Ph.D. Thesis, Massachusetts Institute of Technology,

2002.

51. Loseille, A.; Dervieux, A.; and Alauzet, F.: Fully Anisotropic GoalOriented Mesh Adaptation for 3D Steady Euler Equations. Journal of

Computational Physics, vol. 229, no. 8, 2010, pp. 2866–2897.

52. Cheatwood, F. M.; and Gnoffo, P.: User’s Manual for the Langley

Aerothermodynamic Upwind Relaxation Algorithm (LAURA). NASA TM4674, 1996.

53. Michal, T.; and Krakos, J.: Anisotropic Mesh Adaptation Through Edge

Primitive Operations. AIAA Paper 2012–159, 2012.

54. Shenoy, R.: Overset Adaptive Strategies for Complex Rotating Systems.

Ph.D. Thesis, Georgia Institute of Technology, May 2014.

55. Park, M. A.; and Carlson, J.-R.: Turbulent Output-Based Anisotropic

Adaptation. AIAA Paper 2010–168, 2010.

56. Waithe, K. A.: Source Term Model for Vortex Generator Vanes in a

Navier-Stokes Computer Code. AIAA Paper 2004-1236, Jan. 2004.

57. Edwards, J. W.; Bennett, R. M.; Whitlow, Jr., W.; and Seidel, D. A.:

Time-Marching Transonic Flutter Solutions Including Angle-of-Attack Effects. AIAA J., vol. 20, no. 11, 1983, pp. 899–906.

58. O’Brien, D. M.: Analysis Of Computational Modeling Techniques For

Complete Rotorcraft Configurations. Ph.D. Thesis, Georgia Institute of

Technology, 2006.

59. Biedron, R. T.; and Lee-Rausch, E. M.: Rotor Airloads Prediction Using

Unstructured Meshes and Loose CFD/CSD Coupling. AIAA Paper 2008–

7341, 2008.

60. Srinivasan, S.; Tannehill, J. C.; and Weilmuenster, K. J.: Simplified Curve

Fits for the Thermodynamic Properties of Equilibrium Air. NASA RP1181, June 1987.

87
61. Prabhu, R. K.; and Erickson, W. D.: A Rapid Method for the Computation of Equilibrium Chemical Composition of Air to 15,000 K. NASA

RP-2792, Mar. 1988.

62. McBride, B. J.; and Gordon, S.: Computer Program for Calculation of

Complex Chemical Equilibrium Compositions and Applications. NASA

RP-1311, June 1996.

63. Gnoffo, P. A.; Gupta, R. N.; and Shinn, J. L.: Conservation Equations

and Physical Models for Hypersonic Air Flows in Thermal and Chemical

Nonequilibrium. NASA TP-2867, Feb. 1989.

64. Gupta, R.; Yos, J.; Thompson, R. A.; and Lee, K.: A Review of Reaction

Rates and Thermodynamic and Transport Properties for an 11-Species Air

Model for Chemical and Thermal Nonequilibrium Calculations to 30,000

K. NASA RP-1232, Aug. 1990.

65. Millikan, R. C.; and White, D. R.: Systematics of Vibrational Relaxation.

Chem. Phys., vol. 39, no. 12, Dec. 1963, pp. 3209–3213.

66. Ali, A. W.: The Harmonic and Anharmanic Models for Vibrational Relaxation and Dissociation of the Nitrogen Molecule. U.S. Navy NRL Memo

5924, Dec. 1986.

67. Wright, M.: Recommended Collision Integrals for Transport Property

Computations Part 1: Air Species. AIAA J., vol. 43, no. 12, 2005,

pp. 2558–2564.

68. Wright, M.: Recommended Collision Integrals for Transport Property

Computations Part 2: Mars and Venus Entries. AIAA J., vol. 45, no. 1,

2005, pp. 281–288.

69. Johnston, C. O.; Hollis, B. R.; and Sutton, K.: Spectrum Modeling for Air

Shock-Layer Radiation at Lunar-Return Conditions. Journal of Spacecraft

and Rockets, vol. 45, no. 6, Nov–Dec 2008, pp. 865–878.

70. Johnston, C. O.; Hollis, B. R.; and Sutton, K.: Non-Boltzmann Modeling

for Air Shock-Layer Radiation at Lunar-Return Conditions. Journal of

Spacecraft and Rockets, vol. 45, no. 6, Nov–Dec 2008, pp. 879–890.

71. Johnston, C. O.; Gnoffo, P. A.; and Sutton, K.: The Influence of Ablation

on Radiative Heating for Earth Entry. Journal of Spacecraft and Rockets,

vol. 46, no. 3, May–June 2009, pp. 481–491.

72. Cunto, W.: TOPbase at the CDS. Astronomy and Astrophysics, vol. 275,

1993, pp. L5–L8.

88
73. Gally, T.: Development of Engineering Methods for Nonequilibrium Radiative Phenomena about Aeroassisted Entry Vehicles. Ph.D. Thesis,

Texas A&M, 1992.

74. Johnston, C. O.; Hollis, B. R.; and Sutton, K.: Radiative Heating Methodology for the Huygens Probe. Journal of Spacecraft and Rockets, vol. 44,

no. 5, Sep–Oct 2007, pp. 993–1002.

75. Barth, T. J.: Aspects of Unstructured Grids and Finite-Volume Solvers

for the Euler and Navier-Stokes Equations. VKI Lecture Series 1994-05,

1994.

76. Diskin, B.; and Thomas, J. L.: unpublished notes, 2013.

89
Appendix A

Installation

Fun3D is distributed as gzipped archive of source code. The GNU build

system is used to package and install Fun3D. The required installation steps

are detailed in this section. Due to the large range of capabilities, configuring

the dependent packages is the most involved step and is the focus this section.

As was illustrated in the Quick Start section, four basic steps are required:

1. Extract the source code from the gzipped tarball archive with tar

2. Configure the desired dependencies and compiler options with configure

3. Compile via make

4. Install the compiled binaries and supporting scripts via make install

If any difficulties arise with the installation process please, send the entire

config.log file produced by configure and the full stdout and stderr of make

to Fun3D-Support@lists.nasa.gov. The user is strongly advised against

editing the configure script or any Makefile it produces. We are unable to

assist users who have edited these files.

A.1 Extracting Files

After downloading the source code as a gzipped tarball, the user can unpack

it with

tar zxf fun3d-12.5-*.tar.gz

which will create the directory fun3d-12.5-*. (The * represents a code that

the Fun3D uses internally to version the code.) If you have do not have a

GNU-compatible tar, you may have to insert a separate decompression step,

i.e.,

gzip -d fun3d-12.5-*.tar.gz | tar zxf -

A.2 Configure Introduction

The Fun3D suite of tools is configured and built via the GNU build system

and must be configured first. Change to this directory, e.g., cd fun3d-12.5-*,

and execute

./configure --help

90
to see a list of all available compilation options. When configure is invoked,

detailed results of all the tests it performs are written to the file config.log.

Some features of the configure step that have caused problems for users

are:

 An incorrect spelling of a --enable-* or --with-* option is silently

ignored. This will result in the intended option not being included in

the compiled executable.

 Option values containing spaces must be quoted to be correctly interpreted by the shell (i.e., FCFLAGS=’-option1 -option2’).

 If the configure command is executed more than once with different

options, make clean is required before the make step, so that changes

to the configuration are correctly reflected in the compiled executable.

A.3 Alternative Installation Path

The path to the installation directory is specified by the --prefix= option.

The default is to install to /usr/local with executables placed in /usr/

local/bin. This default location may not be available if the user does not have

write permission to this directory (without root or administrator privileges).

To install to an alternative path (e.g., $HOME/local), use the --prefix=

option to set the installation path

./configure --prefix=$HOME/local

Finally, to include the Fun3D executables in the command search path, add

setenv PATH $HOME/local/bin:$PATH

to the ~/.cshrc file or the equivalent for your shell.

A.4 Fortran Compiler Option Tuning (FTune)

By default, configure will use compiler and linker options chosen by the

Fun3D team. The process is referred to as “FTune.” The users PATH is

searched in a predefined order until the first Fun3D-compatible compiler is

found. When configured with MPI, the build will use mpif90 located in the

bin directory of the given MPI installation.A1 However, the user can explicitly

specify the desired Fortran compiler via the FC environment variable.

To directly specify the compiler and linker options, use the FCFLAGS and

LDFLAGS environment variables. The default behavior is to append their values

to the options defined by FTune. If the --disable-ftune option is given

to configure, FTune will be disabled and the values given by FCFLAGS and

A1To see what the underlying compiler is, use mpif90 -show.

91
LDFLAGS will be used explicitly. For example, to ensure that the Intel® Fortran

compiler ifort is used with only the -O3, -ip, and -lm options,

./configure --disable-ftune \

FC=ifort \

FCFLAGS='-O3 -ip' \

LDFLAGS='-lm'

The order of variables and options are inconsequential, and single quotation

marks (’) are used to protect values with spaces from the shell. Some FTune

options may be unconditionally required for a given compiler, as in the case of

linking with the math library -lm above.

A.5 Complex Variable Version

The Fun3D suite can be complied with the real variables in the code replaced with complex variables by a source translation tool. This permits

the computation of forward-mode sensitivities, see section 8.14 for details.

To enable, add the --enable-complex configure option to the configure

script. The complex-valued code can be compiled with make complex; and a

make install will place the complex-valued executables in the bin installation directory. Enabling the complex variable version will increase the compile

time.

A.6 Internal Libraries

Fun3D has internal dependencies to libraries that are distributed with Fun3D.

These libraries are automatically built and linked to Fun3D by default.

A.6.1 KNIFE

The knife cutcell library provides cutcell capabilities. The --without-knife

option will disable this library.

A.6.2 REFINE

The refine library provides access mesh adaptation and untangling capabilities. The --without-refine option will disable this library.

A.7 External Libraries

Fun3D relies on external libraries to enable some of its advanced applications.

Use Table A1 to determine which set of external libraries are necessary for your

applications of interest. Discussions of each external library are found in the

following sections.

92
Table A1: Configuration options.

Option Parallel Execution

Overset MotionComputed TrajectoriesUnconstrained DesignConstrained DesignBinary Tecplot OutputCGNSSonic Boom Propagation

MPI x

ParMETIS x

SUGGAR x

DiRTlib x

6-DOF x

KSOPT x

PORT x

SNOPT x

NPSOL x

DOT/BIGDOT x

Tecplot x

CGNS x

sBOOM x

It is highly recommended that Fun3D is configured to use a parallel execution (MPI and ParMETIS) if you plan to perform any advanced calculations.

SUGGAR++ and DiRTlib are only required if overset (chimera) meshes will

be used. The 6-DOF library is only required if six degrees of freedom simulations will be performed (trajectories determined by integrating the equation

of motion). KSOPT, PORT, SNOPT, NPSOL, and DOT/BIGDOT are

optimization libraries. At least one of these optimization libraries is required

for performing design optimization.

A.7.1 MPI

MPI provides Fun3D’s capability to communicate between processors. Configure with the option

--with-mpi=/path/to/MPI

where /path/to/MPI is the directory where MPI is installed.

In addition, Fun3D must be executed in an environment that represents the same MPI installation used for configuration/compilation (e.g. same

mpiexec, mpirun, etc.). Failure to provide such consistency will result in undefined behavior and undetermined segmentation faults.

In some cases, MPI may already be installed on the target machine. If it is

not, OpenMPI or MPICH can be used and the option of static MPI libraries

93
is recommended. Also, if building OpenMPI or MPICH from source, it is

important to maintain consistency with compilers (both vendor and version)

throughout the build and execution of Fun3D and its dependent libraries.

For example, if OpenMPI is built with gfortran version 4.4.7, then the execution environment for Fun3D must reflect the same vendor and version,

gfortran 4.4.7. Fun3D execution must also employ the same mpiexec from

the OpenMPI installation used to build the software.

Some high performance computing environments use a proprietary MPI

implementation that does not provide mpif90. It that situation, the configure option --without-mpif90 may be required in combination with the FC

environment variable to explicitly set the compiler.

Verifying the MPI Implementation Functionality A simple Fortran

program is included in the FUN3D distribution to verify that the MPI implementation is functional. This is very helpful for quickly troubleshooting issues

with the MPI implementation. It is located in utils/MPIcheck. From within

that directory you should be able to

mpif90 -o mpi_hello_world mpi_hello_world.F90

and execute on two processors

mpiexec -np 2 ./mpi_hello_world

0 says, "Hello World!" 5 = 5

1 says, "Hello World!" 5 = 5

To verify the Fortran compiler that MPI is built with, try

mpif90 -show

if the MPI implementation supports it.

A.7.2 ParMETIS

Website: http://glaros.dtc.umn.edu/gkhome/metis/parmetis/overview

The partitioning library ParMETIS is required for parallel execution. ParMETIS

is a parallel graph partitioner that is used to perform domain decomposition

for all parallel Fun3D jobs. It is critical that Fun3D and ParMETIS are

compiled with exactly the same MPI installation and compilers. This includes

the C compiler used to compile MPI, ParMETIS, and FUN3D.

When configuring Fun3D, use

--with-parmetis=/path/to/ParMETIS

where /path/to/ParMETIS is the directory of the ParMETIS installation.

Fun3D expects the /path/to/ParMETIS directory to contain the following

files in lib and install subdirectories,

94
/path/to/ParMETIS/lib/libmetis.a

/path/to/ParMETIS/lib/libparmetis.a

/path/to/ParMETIS/include/metis.h

/path/to/ParMETIS/include/parmetis.h

See the Install.txt instructions in the ParMETIS distribution for build

instructions. Fun3D requires both libmetis.a and libparmetis.a libraries

and their accompanying header files. There is an example of commands to

build both libraries,

cd parmetis-4.*

make config prefix=/path/to/ParMETIS

make install

cd metis

make config prefix=/path/to/ParMETIS

make install

where /path/to/ParMETIS matches the Fun3D configure argument.

A.7.3 SUGGAR++-1.0.10 or Higher

Website: http://celeritassimtech.com

SUGGAR++ is used for overset (chimera) applications and assembles composite meshes, cuts holes, determines interpolation coefficients, etc. If configuring with SUGGAR++, Fun3D must also be configured with DiRTlib v1.40

or higher.

SUGGAR++ may be compiled as a stand-alone executable and/or as a library. For static overset meshes you will need the stand-alone compilation; for

moving body simulations you will need to compile both the stand-alone executable and the library. See the documentation that comes with SUGGAR++

for more information on how to compile the software.

When configuring Fun3D, use

--with-suggar=/path/to/SUGGAR++

where /path/to/SUGGAR++ is the directory where SUGGAR++ library archive

files (.a files) reside. In this directory, there must be an archive file called

libsuggar.a, which is the serial compilation of SUGGAR++, and there must

also be an archive file called libsuggar mpi.a, which is the MPI compilation

of SUGGAR++.

A.7.4 DiRTlib v1.40 or higher

Website: http://celeritassimtech.com

95
The DiRTlib library must be linked to Fun3D in order to use the overset

connectivity data computed by SUGGAR++-1.0.10 or Higher. See the documentation that comes with DiRTlib for more information on how to compile

the software.

When configuring Fun3D, use

--with-dirtlib=/path/to/DiRTlib

where /path/to/DiRTlib is the directory where DiRTlib library archive files

(.a files) reside. In this directory, there must be an archive file called libdirt.a,

which is the serial compilation of DiRTlib, and there must also be an archive

file called libdirt mpich.a, which is the MPI compilation of DiRTlib.

A.7.5 6-DOF

Contact: Nathan.C.Prewitt@usace.army.mil

The 6-DOF libraries provide trajectory tracing. When configuring Fun3D,

use

--with-sixdof=/path/to/sixdof

where /path/to/sixdof is the directory where your 6-DOF installation resides.

A.7.6 KSOPT

Contact: Gregory.A.Wrenn@nasa.gov

The KSOPT [21] library is used for multi-objective and constrained Fun3Dbased design optimization. If you configure Fun3D to link to KSOPT, you

must use the Fortran 90 implementation of KSOPT with its object files gathered into a library called libksopt.a.

When configuring Fun3D, use

--with-KSOPT=/path/to/ksopt

where /path/to/ksopt is the directory where your KSOPT installation resides.

A.7.7 PORT

Website: http://www.netlib.org/port

The PORT library is used for unconstrained Fun3D-based design optimization. The Netlib site offers a tarball of the PORT library with a Makefile.

Download the tarball from Netlib, but replace the original Makefile with the

file included inside the Fun3D distribution as Design/PORT.Makefile. If you

install both the PORT and NPSOL libraries, you may have to comment out

96
low-level BLAS routines in one of the two packages because the linker will

report the duplicate versions of these routines.

When configuring Fun3D, use

--with-PORT=/path/to/port

where /path/to/port is the directory where your PORT installation resides.

A.7.8 SNOPT

Website: http://www.sbsi-sol-optimize.com

The SNOPT library is used for Fun3D-based design optimization. By

default the SNOPT package builds a shared library. Either build SNOPT

with the --disable-shared option, or add the the SNOPT install directory

to your LD LIBRARY PATH environment variable to ensure Fun3D can find the

shared library at run time.

When configuring Fun3D, use

--with-SNOPT=/path/to/snopt

where /path/to/snopt is the directory where your SNOPT installation resides.

A.7.9 NPSOL

Website: http://www.sbsi-sol-optimize.com

The NPSOL library is used for constrained Fun3D-based design optimization. If you install both the PORT and NPSOL libraries, you may have

to comment out low-level BLAS routines in one of the two packages because

the linker will report the duplicate versions of these routines.

When configuring Fun3D, use

--with-NPSOL=/path/to/npsol

where /path/to/npsol is the directory where your NPSOL installation resides.

A.7.10 DOT/BIGDOT

Website: http://www.vrand.com/products.html

The DOT/BIGDOT library is used for unconstrained or constrained

Fun3D-based design optimization. When configuring Fun3D, use

--with-DOT=/path/to/dot

where /path/to/dot is the directory where your DOT/BIGDOT installation

resides.

97
A.7.11 Tecplot

Website: http://www.tecplot.com

By default, any Tecplot output generated from within the flow solver itself

is written as a text file. If you have a copy of Tecplot, you were provided

with a library archive tecio.a (or tecio64.a for 64-bit versions) that allows

for binary output.A2 You may configure the Fun3D suite to use the library

via:

--with-tecio=/path/to/tecio

With this option, Tecplot solution data written out from the flow solver will

be in binary form. This results in smaller file sizes and faster importation into

Tecplot.

If you have compiled against the Tecplot tecio library, you can still

request text output via the --ascii tecplot output command line option.

A.7.12 CGNS

Website: http://www.cgns.org

The CGNS library is used for working with files written in CGNS format.

CGNS is a convention for writing machine-independent, self-descriptive data

files for CFD and includes implementation software. Fun3D has the capability

to translate and write CGNS files. The translation utilities are only compiled

when CGNS is configured. Version 2.5 or greater of the CGNS library is

required. To include CGNS, use

--with-CGNS=/path/to/cgns

where /path/to/cgns is the directory where the CGNS installation resides.

A.7.13 sBOOM

Contact: Sriram.Rallabhandi@NASA.gov

This package propagates a computed pressure signature to the ground for

sonic boom simulations. Atmospheric variations are included, and an adjoint

version is available for coupling into design and grid adaptation. sBOOM is

distributed as a standalone executable or a static library. Fun3D is not able

to interact with the standalone executable; the static library must be linked.

You may configure the Fun3D suite to use the library via:

--with-SBOOM=/path/to/sBOOM

where /path/to/sBOOM is the directory where the sBOOM installation resides.

A2The tecio library that was shipped with Tecplot360-2008 had a bug that will result

in error messages when the binary files are written. You must get an updated version of the

library.

98
Appendix B

Fun3D Input Files

There are a variety of input files necessary for the various codes that make

up the Fun3D suite. Table B1 lists frequently used input files with a short

description. This chapter will describe the basic formats of each of these files

and meaning of the specific inputs they contain.

Table B1: Fun3D input files.

File Description

stop.dat signals a change to the number of iterations /

time steps that were requested at the beginning

of the run

remove boundaries from force totals omits boundary faces from total force integration

[project rootname].flow* flow field solution

fun3d.nml primary Fortran namelist (required)

moving body.input body motion Fortran namelist

rotor.data describes the rotor actuator disk model

tdata specifies the generic gas model

kinetic data specifies the possible chemical reactions in the

generic gas model

species transp data specifies generic gas model species collision cross

sections

species transp data 0 specifies a higher-order generic gas model

species collision cross sections

hara namelist data controls the radiation models used by the Hara

library

* The [project rootname] is a &project namelist variable, see section B.4.1.

Fun3D utilizes Fortran namelists for a large portion of input specification

because it is defined in the Fortran 90 standard. With all Fortran namelists,

leaving out or misspelling any namelist (defined with an ampersand preceding

its name) will result in default values being used for all of the parameters within

that namelist. For example, if the namelist name linear solver parameters

were to be misspelled as linear solver parameter (missing s), then all parameters within that namelist would be ignored and retain their default values.

Leaving out any parameter within a namelist results in the default value for

that parameter being used. Misspelling or misusing any particular parameter

will typically cause Fun3D to issue an error and stop.

99
B.1 stop.dat

This optional file either halts or extends the execution of the solver. The

stop.dat plain text file contains a single integer. After every iteration, the

solver will check to see if this file exists. If the file is found in the directory

that the solver was invoked, the integer is read. If the integer is greater than

zero and less than or equal to the current iteration, the solver will write the

current solution, delete the stop.dat file, and halt execution. If the integer

is greater than the current iteration, code execution will proceed until the

iteration matches the integer. The value of the integer may be greater than

the number of iterations / time steps specified in fun3d.nml, so that stop.dat

can be used to extend the execution of the solver if desired.

Some environments, especially ones with network-mounted filesystems (e.g.,

NFS), may result in a delay with the stop.dat file being read or being deleted.

B.2 [project rootname].flow

The optional [project rootname].flow binary file contains flow solution and

checkpoint information. The [project rootname] is a &project namelist

variable, see section B.4.1. This file is read by the solver to restart computations from a previously computed flow solution. The contents vary due to

the checkpoint requirements of the simulation. The file contains a minimum

of the current solution and convergence history. It can also contain working

variables for the turbulence model, solutions from previous iterations for time

accurate cases, or previous grid positions and velocities for deforming grids.

B.3 remove boundaries from force totals

The optional remove boundaries from force totals file is for specifying boundaries that are not to be included in the calculation of force and moment totals.

This file is useful, for example, in situations where there may be a mounting

sting on a wind tunnel model, but only the forces on the model are actually of

interest. The forces on the specified boundaries are still computed and appear

in the [project rootname].forces file. However, they are not included in

the totals. The position of the text lines in this file is significant. So, follow

this template carefully:

Remove selected boundaries from the total forces

Number of boundaries to turn off

2

Boundaries to turn off (boundary lumping changes indexes)

12

15

100
The third line is the number of boundaries to exclude. The fifth and subsequent

lines are the patch indexes of the excluded boundaries.

B.4 fun3d.nml

The main input namelist file, fun3d.nml, is described in detail below, with defaults listed before the descriptions. The namelist file contains a large number

of input variables. In general, it is not necessary to specify them all because

they have suitable default values. Only those variables that are different from

the defaults need to be specified. An overview of tasks and their associated

namelists are listed below.

The project name and grid information:

&project (B.4.1)

&raw grid (B.4.2)

&force moment integ properties (B.4.3)

&grid transform (B.4.4)

&body transform (B.4.5)

The equation set and reference conditions:

&governing equations (B.4.6)

&reference physical properties (B.4.7)

&noninertial reference frame (B.4.8)

The inviscid flux discretization:

&inviscid flux method (B.4.9)

Turbulence model:

&turbulent diffusion models (B.4.10)

&spalart (B.4.11)

&gammaretsst (B.4.12)

Number of and size of time steps or steady iterations:

&code run control (B.4.13)

&nonlinear solver parameters (B.4.14)

101
Linear relaxation controls:

&linear solver parameters (B.4.15)

Boundary conditions and transition:

&boundary conditions (B.4.16)

&two d trans (B.4.17)

&three d trans (B.4.18)

Flowfield initialization:

&flow initialization (B.4.19)

Force tracking and visualization:

&component parameters (B.4.20)

&time avg params (B.4.21)

&global (B.4.22)

&volume output variables (B.4.23)

&boundary output variables (B.4.24)

&sampling output variables (B.4.25)

&sampling parameters (B.4.26)

&slice data (B.4.27)

Overset grid systems and rotorcraft simulation:

&overset data (B.4.28)

&rotor data (B.4.29)

Grid adaptation:

&adapt metric construction (B.4.30)

&adapt mechanics (B.4.31)

Design optimization cost functions:

&massoud output (B.4.32)

&sonic boom (B.4.33)

&sboom (B.4.34)

&equivalent area (B.4.35)

102
&press box function (B.4.36)

&pstag function (B.4.37)

Other:

&special parameters (B.4.38)

&vortex generator (B.4.39)

103
B.4.1 &project

This namelist allows the user to specify the rootname of the project, which

forms the majority of input and output filenames.

&project

project_rootname = 'default_project'

/

project rootname = ’default project’

The project rootname is the root for the grid, restart, and visualization

files. The manual refers to it as [project rootname]. The ’default project’

can be replaced with any filename allowed by the file system.

104
B.4.2 &raw grid

This namelist specifies details of the grid format.

&raw_grid

grid_format = 'vgrid'

data_format = 'default'

twod_mode = .false.

swap_yz_axes = .false.

fieldview_coordinate_precision = 'double'

patch_lumping = 'none'

ignore_euler_number = .false.

/

grid format = ’vgrid’

This specifies the grid file format. The currently supported values are:

‘fast’ for FAST .fgrid/.mapbc files.

‘vgrid’ for single- and multi-segmented VGRID .cogsg/.bc/.mapbc files.

‘fun2d’ for Fun2D.faces files.

‘aflr3’ for AFLR3 formatted, unformatted, or C-binary/Fortran-stream

.ugrid/.r8.ugrid/.b8.ugrid/.mapbc files,

‘felisa’ for Felisa grid files.

‘fieldview’ for FieldView formatted or unformatted .fvgrid fmt/.fvgrid unf/.mapbc

files.

data format = ’default’

This provides the encoding of the grid file. A particular grid format

may only support a subset of encodings. Fun3D will stop with an error

message if the data format is inconsistent with the grid format. The

’default’ value is changed to an admissible value based on grid format

as noted next to each value,

‘ascii’ ASCII text grid file. It is the default for ’felisa’ and ’fun2d’

grids.

‘unformatted’ Fortran unformatted grid file. It is the default for

’fast’, ’vgrid’, and ’fieldview’ grids.

‘stream’ C-binary/Fortran-stream grid file. It is the default for ’aflr3’

grids.

‘stream64’ 64 bit integer C-binary/Fortran-stream grid file.

twod mode = .false.

Turns on two-dimensional mode for a single layer prism or hex grid. If

grid format = ’fun2d’, twod mode is automatically .true..

105
swap yz axes = .false.

When .true., this swaps the y- and z-axes for the grid. This option can

be used to rotate the grid so the z-axes is in the Fun3D convention for

angle of attack and lift.

fieldview coordinate precision = ’double’

This specifies floating point precision of reals for FieldView meshes only.

‘double’ for double precision coordinates.

‘single’ for single precision coordinates.

patch lumping = ’none’

This enables boundary patch lumping. It combines the grid patches into

fewer patches to ease the bookkeeping of patch groups, but will effect all

features that reference boundary patch numbers (e.g., &boundary conditions).

The .mapbc files for any of the supported grid formats may contain an

optional third column of data, which specifies a family name. The exception is the VGRID.mapbc file, where the family name is mandatory

and appears in the sixth column. If family names are not present in the

.mapbc file, patch lumping can not be family.

‘none’ for no patch lumping.

‘bc’ for physical boundary condition lumping.

‘family’ for family name lumping

ignore euler number = .false.

This will permit the use of grids with a failing Euler number check. See

section C.7 for a description of the Euler number and its implications.

Ignoring the Euler number check is not recommended.

106
B.4.3 &force moment integ properties

Reference lengths and area are defined in this namelist to scale aerodynamic

force and moment data.

&force_moment_integ_properties

area_reference = 1.0

x_moment_length = 1.0

y_moment_length = 1.0

x_moment_center = 0.0

y_moment_center = 0.0

z_moment_center = 0.0

/

area reference = 1.0

This area is used for non-dimensionalization of forces and moments, specified in grid units squared.

x moment length = 1.0

This length in x-direction is used to nondimensionalize moments about

y (pitching moment), specified in grid units.

y moment length = 1.0

This length in y-direction is used to nondimensionalize moments about

x (rolling moment) and z (yawing moment), specified in grid units.

x moment center = 0.0

This specifies the x-coordinate location of moment center, in grid units.

y moment center = 0.0

This specifies the y-coordinate location of moment center, in grid units.

z moment center = 0.0

This specifies the z-coordinate location of moment center, in grid units.

107
B.4.4 &grid transform

This namelist defines a constant grid translation and rotation that is applied

before the start of the flow solution. For example, original grid may be reoriented to position the geometry at a different angle of attack.

&grid_transform

ds = 0.0

sx = 1.0

sy = 0.0

sz = 0.0

theta = 0.0

tx = 1.0

ty = 0.0

tz = 0.0

x0 = 0.0

y0 = 0.0

z0 = 0.0

scale = 1.0

transform(1,1:4) = 1.0, 0.0, 0.0, 0.0

transform(2,1:4) = 0.0, 1.0, 0.0, 0.0

transform(3,1:4) = 0.0, 0.0, 1.0, 0.0

transform(4,1:4) = 0.0, 0.0, 0.0, 1.0

/

ds = 0.0

This is the translation distance.

sx = 1.0

This is the x-component of a unit vector in the translation direction.

sy = 0.0

This is the y-component of a unit vector in the translation direction.

sz = 0.0

This is the z-component of a unit vector in the translation direction.

theta = 0.0

This is the rotation angle (in degrees). A positive rotation is applied by

the right hand rule with the thumb pointing in direction of rotation axis.

tx = 1.0

This is the x-component of the rotation axis unit vector.

ty = 0.0

This is the y-component of the rotation axis unit vector.

108
tz = 0.0

This is the z-component of the rotation axis unit vector.

x0 = 0.0

This is the x-coordinate of the rotation origin.

y0 = 0.0

This is the y-coordinate of the rotation origin.

z0 = 0.0

This is the z-coordinate of the rotation origin.

scale = 1.0

This a scale factor applied to all coordinate values.

transform(1,1:4) = 1.0, 0.0, 0.0, 0.0

This is a 4x4 transform matrix (see for example [25]).

109
B.4.5 &body transform

This namelist defines a constant body translation and rotation that is applied

before the start of the flow solution. For example, original body may be

reoriented to position the geometry at a different effective angle of attack.

After repositioning the body, the mesh is deformed once to reflect the new

position of the body, before beginning the solution.

&body_transform

n_bodies = 0

nbndry(:) = 0

boundary_list(:) = ''

ds(:) = 0.0

sx(:) = 1.0

sy(:) = 0.0

sz(:) = 0.0

theta(:) = 0.0

tx(:) = 1.0

ty(:) = 0.0

tz(:) = 0.0

x0(:) = 0.0

y0(:) = 0.0

z0(:) = 0.0

transform(1,1:4,1) = 1.0, 0.0, 0.0, 0.0

transform(2,1:4,1) = 0.0, 1.0, 0.0, 0.0

transform(3,1:4,1) = 0.0, 0.0, 1.0, 0.0

transform(4,1:4,1) = 0.0, 0.0, 0.0, 1.0

/

n bodies = 0

This is the number of bodies that are to be repositioned at the start of

the computation.

nbndry(:) = 0

This is the number of boundary patches listed for a given body.

boundary list(:) = ’’

This is a list of boundary patch numbers for a given body. Commas and

dashes can be used to specify ranges, i.e., ’1,2,5-7’.

ds(:) = 0.0

This is the translation distance.

sx(:) = 1.0

This is the x-component of a unit vector in the translation direction.

110
sy(:) = 0.0

This is the y-component of a unit vector in the translation direction.

sz(:) = 0.0

This is the z-component of a unit vector in the translation direction.

theta(:) = 0.0

This is the rotation angle (in degrees). A positive rotation is applied by

the right hand rule with the thumb pointing in direction of rotation axis.

tx(:) = 1.0

This is the x-component of the rotation axis unit vector.

ty(:) = 0.0

This is the y-component of the rotation axis unit vector.

tz(:) = 0.0

This is the z-component of the rotation axis unit vector.

x0(:) = 0.0

This is the x-coordinate of the rotation origin.

y0(:) = 0.0

This is the y-coordinate of the rotation origin.

z0(:) = 0.0

This is the z-coordinate of the rotation origin.

transform(1,1:4,1) = 1.0, 0.0, 0.0, 0.0

This is a 4x4 transform matrix (see for example [25]).

111
B.4.6 &governing equations

This namelist specifies the equation set that describes underlying physics of

the problem.

&governing_equations

eqn_type = 'compressible'

artificial_compress = 15.0

viscous_terms = 'turbulent'

chemical_kinetics = 'finite-rate'

thermal_energy_model = 'non-equilib'

prandtlnumber_molecular = 0.72

schmidt_number = -1.

gas_radiation = 'off'

rad_use_impl_lines = .false.

multi_component_diff = .false.

cpiv_min_factor = 0.0001

augment_kinetics_limiting = .false.

implicit_rate_limiting = .true.

/

eqn type = ’compressible’

This specifies the set of governing equations to be solved.

‘compressible’ for compressible, calorically perfect gas. See section 2.1

for equations and nondimensionalization.

‘incompressible’ for incompressible, calorically perfect gas. [26] See

section 2.2 for equations and nondimensionalization. The incompressible solution is affected by the choice of artificial compress, see the

description of this parameter for details.

‘generic’ for multispecies, reacting gas simulations. See section 2.3

for nondimensionalization. The tdata input file is required. Fun3D is

usually distributed with the ’generic’ option disabled. If it is required,

see section 1.4 for information on obtaining the version of Fun3D with

this capability.

artificial compress = 15.0

This is the artificial compressibility factor, β, which is only used by the

eqn type = ’incompressible’. This parameter must be in the range

of (100, 1). See Anderson, Rausch, and Bonhaus [26] for details. The

sensitivity of the solution to this parameter will decrease with mesh

refinement, so consider a refined grid if an unacceptable amount of sensitivity is experienced. A high sensitivity to this parameter can also

indicate that the problem is actually compressible and the user is encouraged to check the incompressible solution by performing a low Mach

compressible simulation.

112
viscous terms = ’turbulent’

This describes the modeling of the viscosity term in the governing equations.

‘inviscid’ no viscosity, for inviscid flow.

‘laminar’ apply laminar viscosity, to model laminar flow.

‘turbulent’ include laminar viscosity and model turbulent flow with a

&turbulent diffusion models.

chemical kinetics = ’finite-rate’

This describes the chemical kinetics, only used when eqn type = ’generic’.

‘frozen’ for frozen chemical compositions.

‘finite-rate’ for finite-rate reacting gases.

thermal energy model = ’non-equilib’

This describes the thermal energy model, only used when eqn type =

’generic’.

‘frozen’ for frozen chemical compositions.

‘non-equilib’ for non-equilibrium gases.

prandtlnumber molecular = 0.72

This is the molecular Prandtl number. It must be greater than zero.

schmidt number = -1.

This is the Schmidt number used in the generic gas path. If the user

wants to override the default path of computing a variable Schmidt number from collision cross sections then use this parameter to specify the

constant Schmidt number.

gas radiation = ’off’

This controls flow field radiation coupling. When active, this option will

compute radiation source terms and surface heat fluxes after the first

time step. Radiation source terms are not further updated during the

rest of the time steps. Radiation source terms are not stored in the

restart file, so they need to be recalculated when restarting simulations

that include flow field radiation. Only for eqn type = ’generic’.

‘off’ no radiation calculations.

‘uncoupled’ will use the HARA program to compute radiative surface

heat fluxes, but radiation source terms would not be included in the

flow-field governing equations.

‘coupled’ will include radiation source terms in the governing equations, with the divergence of the radiative flux being computed by the

113
HARA program. Requires rad use impl lines = .true.. only valid if

all of the domain nodes are included in one and only one line as defined

by the implicit lines file.

rad use impl lines = .false.

For gas radiation, the mesh nodes in the lines of sight are read from the

implicit lines file. Coupled radiation must use this option. For uncoupled

radiation, the lines of sight can either be read from the implicit lines file

when .true., or the lines of sight will be generated during the FUN3D

run when .false. Only for eqn type = ’generic’.

multi component diff = .false.

When .true., engage multi-component diffusion using sub-iteration of

Stefan-Maxwell Equations as described by Sutton and Gnoffo. [27] Otherwise, use binary diffusion with mass fraction averaged correction to

force sum of diffusion flux to equal zero. Only for eqn type = ’generic’.

cpiv min factor = 0.0001

This variable sets the minimum value of the vibrational-electronic heat

capacity as a fraction of the translational-rotational heat capacity for

each species i. In some cases, ramping this value up to 0.01 can help

suppress undershoot of vibrational temperature upstream of a strong

shock. The vibrational-electronic heat capacity must be positive for

stability. Only for eqn type = ’generic’.

augment kinetics limiting = .false.

When .true., augment chemical kinetic source term limiting. Only for

eqn type = ’generic’.

implicit rate limiting = .true.

When .true., limit chemical rates if extrema exist in formulation Only

for eqn type = ’generic’.

114
B.4.7 &reference physical properties

This namelist is used to specify reference conditions and nominal freestream

flow conditions in a user-defined unit system. It is also used to convert between

grid units and flow solver units.

&reference_physical_properties

dim_input_type = 'nondimensional'

gridlength_conversion = 1.0

mach_number = 0.0

reynolds_number = 0.0

velocity = 0.0

density = 0.0

temperature = 273.0

temperature_units = 'Kelvin'

angle_of_attack = 0.0

angle_of_yaw = 0.0

/

dim input type = ’nondimensional’

This is the system of measurement for the reference conditions. Currently, it must be ’dimensional-SI’ for eqn type = ’generic’ and

’nondimensional’ otherwise. This input is intended for future expansion. The temperature is always input as a dimensional quantity.

‘nondimensional’ requires mach number and reynolds number to be

defined.

‘dimensional-SI’ requires dimensional velocity and density to be

defined.

gridlength conversion = 1.0

For dim input type = ’dimensional-SI’, this is the conversion factor to scale the grid and it should be set to meters per grid unit. It

is used for providing heat flux in proper units and other tasks. For

dim input type = ’nondimensional’, this should be set to 1.0, because the grid is already in nondimensional grid units.

mach number = 0.0

This is the reference Mach number defined as velocity/speed-of-sound. It

is only allowed for dim input type = ’nondimensional’ and eqn type

= ’compressible’. It must be set to a positive value.

reynolds number = 0.0

This is the reference Reynolds number, per one unit of the grid. Not

correctly accounting for the unit of the grid has been a point of confusion

115
in the past. For example, when the grid units are feet, Reynolds number

should be specified per foot. This input is only used if dim input type =

’nondimensional’ and is ignored by eqn type = ’generic’. It must

be set to a positive value.

velocity = 0.0

This is the reference velocity, in m/s. Only used for dim input type =

’dimensional-SI’ and eqn type = ’generic’.

density = 0.0

This is the reference density, in kg/m3. Only used for dim input type

= ’dimensional-SI’ and eqn type = ’generic’.

temperature = 273.0

This is the reference temperature, in units of temperature units.

temperature units = ’Kelvin’

The units used to specify temperature.

‘Kelvin’ for SI units.

‘Rankine’ for the English system.

angle of attack = 0.0

This is the freestream angle of attack in degrees.

angle of yaw = 0.0

This is the freestream angle of yaw (side-slip) in degrees.

116
B.4.8 &noninertial reference frame

FUN3D can perform simulations in noninertial reference frame rotating at a

constant rate, Ω. The noninertial reference frame simulation can be run as a

steady state problem if the freestream velocity crossed with the rotation vector

is zero, U∞ × Ω = 0. In a practical sense, freestream velocity should be zero

or parallel to the axis of rotation. Using a standard inertial reference frame

requires the same problem to be run as an unsteady simulation at a larger

computational cost. Typical uses would be the simulation of an isolated rotor

in hover (without forward motion) or an aircraft performing a steady-state

pitching maneuver or constant roll about the wind axis.

&noninertial_reference_frame

noninertial = .false.

rotation_center_x = 0.0

rotation_center_y = 0.0

rotation_center_z = 0.0

rotation_rate_x = 0.0

rotation_rate_y = 0.0

rotation_rate_z = 0.0

/

noninertial = .false.

When .true., use a noninertial reference frame. The default is the inertial

reference frame.

rotation center x = 0.0

This is the x of the steady rotation rate center point.

rotation center y = 0.0

This is the y of the steady rotation rate center point.

rotation center z = 0.0

This is the z of the steady rotation rate center point.

rotation rate x = 0.0

This is the steady noninertial rotation rate about the rotation center xaxis in reference speed of sound per grid unit (eqn type = ’compressible’)

or reference speed per grid unit (eqn type = ’incompressible’).

rotation rate y = 0.0

This is the steady noninertial rotation rate about the rotation center yaxis in reference speed of sound per grid unit (eqn type = ’compressible’)

or reference speed per grid unit (eqn type = ’incompressible’).

117
rotation rate z = 0.0

This is the steady noninertial rotation rate about the rotation center zaxis in reference speed of sound per grid unit (eqn type = ’compressible’)

or reference speed per grid unit (eqn type = ’incompressible’).

118
B.4.9 &inviscid flux method

This namelist controls the construction of the inviscid fluxes and flux Jacobians.

&inviscid_flux_method

flux_construction = 'roe'

flux_construction_lhs = 'vanleer'

kappa_umuscl = -1.0

flux_limiter = 'none'

freeze_limiter_iteration = -1

first_order_iterations = 0

multidm_option = 1

fixed_direction = .true.

recalc_dir_freq = 1

adptv_entropy_fix = .false.

rhs_u_eigenvalue_coef = 0.

lhs_u_eigenvalue_coef = 0.

rhs_a_eigenvalue_coef = 0.

lhs_a_eigenvalue_coef = 0.

entropy_fix = .false.

re_min_vswch = 50.

re_max_vswch = 500.

pole_gradient = .false.

/

flux construction = ’roe’

This specifies the inviscid flux residual construction method.

‘roe’ for Roe flux difference splitting.

‘vanleer’ for van Leer flux vector splitting.

‘hllc’ for HLLC.

‘aufs’ for AUFS.

‘ldfss’ for LDFSS.

‘dldfss’ for dissipative LDFSS.

‘aldfss’ for LDFSS with an adaptive entropy fix.

‘roe ec’ for entropy-consistent Roe scheme.

‘stvd’ for Yee’s symmetric total variation diminishing scheme.

‘stvd modified’ for a modified version of STVD.

‘multidm’ for Gnoffo’s multidimensional scheme.

119
flux construction lhs = ’vanleer’

This specifies the inviscid flux Jacobian construction method. A ’consistent’

method yields the best asymptotic iterative convergence rate of the nonlinear residual, but a more diffusive flux may stabilize a poorly converging

or diverging linear system iterative scheme.

‘consistent’ for a consistent linearization with the residual construction method.

‘vanleer’ for Van Leer.

‘roe’ for Roe linearization.

‘hllc’ for HLLC.

‘aufs’ for AUFS.

‘ldfss’ for LDFSS.

kappa umuscl = -1.0

Controls the amount of upwinding in the unstructured-grid MUSCL reconstruction scheme. The default will adjust kappa umuscl internally

to 0.5 for 3D mixed-element grids or 0.0 for all other grid types. 0.0 is

the upwind-biased (Fromm) discretization, 1.0 is the (unstable) centraldifference discretization, and the range [0,1] is a blend of the two.

flux limiter = ’none’

This selects the flux limiter. The limiters that begin with the letter h,

’barth’, and ’venkat’ are stencil-based limiters (they apply a limiter

to each edge in a node’s the reconstruction stencil and store the most

restrictive edge limiter value at the node). Other limiters are evaluated

in a strictly edge-based manner. The h-series of limiters automatically

turns on a heuristic pressure based limiter that is used to augment the

selected flux limiter. [28] The node-based limiters can be frozen with

the freeze limiter iteration namelist variable to possibly improve

“ringing” nonlinear iterative convergence. The adjoint solver is only

compatible with a frozen limiter. For hypersonic flows computed using the calorically perfect gas path, the hvanleer or hvanalbada flux

limiters are recommended.

‘none’ for no limiter.

‘barth’ for the Barth limiter.

‘venkat’ for the Venkatakrishnan [29] limiter. This limiter is dimensional and should be scaled if the grid is not normalized to a characteristic

length of your model. The --smooth limiter coeff command line option should be set to a reciprocal of a characteristic length, i.e., 1/(Mean

Aerodynamic Chord).

120
‘hminmod’ for the stencil-based min-mod limiter augmented with a heuristic pressure limiter.

‘hvanleer’ for the stencil-based van Leer limiter augmented with a

heuristic pressure limiter.

‘hvanalbada’ for the stencil-based van Albada limiter augmented with

a heuristic pressure limiter.

‘hvenkat’ for the Venkatakrishnan limiter augmented with a heuristic

pressure limiter.

‘minmod’ for the min-mod limiter.

‘vanleer’ for the van Leer limiter.

‘vanleer gg’ for van Leer limiter that also turns on Green-Gauss gradients for inviscid reconstruction.

‘vanalbada’ for the van Albada limiter.

freeze limiter iteration = -1

The node-based limiters can be frozen by setting freeze limiter iteration

to zero or an iteration number. A negative value does not freeze the limiter. Zero is used to retain the limiter field contained in the restart

file. Freezing can possibly improve “ringing” nonlinear iterative convergence. [29] If a unrealizable reconstruction (negative density or pressure)

is encountered the limiter field will be locally updated at the node experiencing the problematic reconstruction. The adjoint solver is only

compatible with a frozen limiter.

first order iterations = 0

This is the number of iterations to use first-order spatial accuracy prior

to using second-order spatial accuracy. If second-order spatial accuracy

in not required, set this to a value larger than the number of steps.

This option is useful for starting difficult supersonic flow simulations.

For time accurate cases (time accuracy not equal to ’steady’), this

is the number of first-order accurate sub-iterations to run for each time

step.

multidm option = 1

This controls the multidm reconstruction weighting.

‘1’ virtual node averaging.

‘2’ weighted average of edges.

fixed direction = .true.

This specifies the use of Cartesian directions in multdm reconstruction.

121
recalc dir freq = 1

This sets the frequency of direction recalculation in the multidm scheme.

adptv entropy fix = .false.

This activates the adaptive entropy fix for Roe’s scheme.

rhs u eigenvalue coef = 0.

This is the contact/shear eigenvalue smoothing coefficient for the adaptive entropy fix and the roe residual.

lhs u eigenvalue coef = 0.

This is the contact/shear eigenvalue smoothing coefficient for the adaptive entropy fix and the roe Jacobian.

rhs a eigenvalue coef = 0.

This is the acoustic eigenvalue smoothing coefficient for the adaptive

entropy fix and the roe residual.

lhs a eigenvalue coef = 0.

This is the acoustic eigenvalue smoothing coefficient for the adaptive

entropy fix and the roe Jacobian.

entropy fix = .false.

This activates the entropy fix for the stvd flux.

re min vswch = 50.

For the stvd flux, eigenvalue limiting is turned off below this cell Reynolds

number.

re max vswch = 500.

For the stvd flux, eigenvalue limiting is fully engaged above this cell

Reynolds number.

pole gradient = .false.

If true, use limiting form of continuity equation across pole in association

with symmetry 1 strong, symmetry 2 strong, or symmetry 3 strong.

122
B.4.10 &turbulent diffusion models

When viscous terms = ’turbulent’, this namelist is used to set the form

of the turbulence model.

&turbulent_diffusion_models

turbulence_model = 'sa'

turb_model = 'deprecated-use-turbulence_model'

turb_intensity = 0.001

turb_viscosity_ratio = 0.001

turb_compress_model = 'off'

turb_conductivity_model = 'off'

prandtlnumber_turbulent = 0.9

schmidtnumber_turbulent = 1.

/

turbulence model = ’sa’

This selects the form of the turbulence model. The naming convention

of http://turbmodels.larc.nasa.gov/ is used for the models described

on the website.

‘sa’ for Spalart-Allmaras model. [30] See the &spalart namelist in section B.4.11 for additional controls.

‘sa-catris’ for Spalart-Allmaras Catris-Aupoix model. [31]

‘des’ for Spalart-Allmaras based DES model. [32] See the &spalart

namelist in section B.4.11 for additional controls. Not available for

eqn type=’generic’.

‘sa-neg’ for Spalart-Allmaras model with negative turbulence variable

provisions. [33] Not available for eqn type=’generic’.

‘des-neg’ for Spalart-Allmaras based DES model with negative turbulence variable provisions. [32,33] Not available for eqn type=’generic’.

‘menter-sst’ option is no longer valid, use sst or sst-v

‘sst’ Menter SST Two-Equation Model with strain source term. [34]

‘sst-v’ Menter SST Two-Equation Model with vorticity source term.

[35] Not available for eqn type=’generic’.

‘wilcox1988’ Wilcox (1988) k-omega Two-Equation Model. [36] Not

available for eqn type=’generic’.

‘wilcox1988-v’ Wilcox (1988) k-omega Two-Equation Model with vorticity source term. [36] Not available for eqn type=’generic’.

‘wilcox2006’ Wilcox (2006) k-omega Two-Equation Model. [37] Not

available for eqn type=’generic’.

123
‘wilcox2006-v’ Wilcox (2006) k-omega Two-Equation Model with vorticity source term. [37] Not available for eqn type=’generic’.

‘hrles’ for Menter SST-based hybrid-RANS/LES model. Does not

work with eqn type=’generic’.

‘gamma-ret-sst’ for Langtry and Menter SST transition model. [38]

See the &gammaretsst namelist in section B.4.12 for additional controls.

Not available for eqn type=’generic’.

‘baldwin-lomax’ Baldwin-Lomax algebraic model. Available only for

eqn type=’generic’.

‘cebeci-smith’ Cebeci-Smith algebraic model. Available only for eqn type=

generic.

turb model = ’deprecated-use-turbulence model’

This is a deprecated namelist variable for turbulence model. It is included for backwards compatibility with fun3d.nml files, but may be

removed in a future version.

turb intensity = 0.001

This sets the freestream turbulence intensity, q 2k

3u2∞

, where k is the turbulent kinetic energy. Only applies to eqn type=’generic’.

turb viscosity ratio = 0.001

This sets the freestream ratio of turbulent viscosity to molecular viscosity. Only applies to eqn type=’generic’.

turb compress model = ’off’

This controls the turbulence compressibility model. Only applies to

eqn type=’generic’.

‘off’ for no correction.

‘ssz’ for SSZ (use with Spalart-Allmaras models).

‘zeman’ for Zeman (use with k −  models).

‘wilcox’ for Wilcox (use with SST-based models).

‘sarkar’ for Sarkar (use with k −  models).

turb conductivity model = ’off’

This controls whether a turbulence conductivity model is employed.

Only applies to eqn type=’generic’.

‘off’ to turn off a turbulence conductivity model.

‘on’ to turn on a turbulence conductivity model.

124
prandtlnumber turbulent = 0.9

This is the turbulent Prandtl number.

schmidtnumber turbulent = 1.

This is the turbulent Schmidt number. Only applies to eqn type=’generic’.

125
B.4.11 &spalart

This namelist is used to modify details of the SA and SA based DES turbulence

models.

&spalart

turbinf = 3.0

dacles_mariani = .false.

sarc = .false.

ddes = .false.

ddes_mod1 = .false.

cddes = 0.975

/

turbinf = 3.0

This is the freestream turbulence value for the SA model.

dacles mariani = .false.

This activates the Dacles-Mariani [39, 40] rotation correction (denoted

SA-R by http://turbmodels.larc.nasa.gov/).

sarc = .false.

This activates the rotation/curvature correction [41] (denoted SA-RC by

http://turbmodels.larc.nasa.gov/).

ddes = .false.

This changes the turbulence model=’des’ into Delayed DES [42] (DDES).

ddes mod1 = .false.

This changes the turbulence model=’des’ into Modified Delayed DES

[43] (MDDES). It also requires ddes = .true. This option should be used

with caution. Most experience with this model is for large separated

flows encountered in wake regions of bluff bodies, such as cylinders and

landing gears. Further validation is required for other situations. There

is sensitivity to the parameter cddes.

cddes = 0.975

This is CMDD in [43]. It used with the ddes mod1 = .true.

126
B.4.12 &gammaretsst

This namelist modifies the details of the turbulence model = ’gamma-ret-sst’

transition turbulence model of Langtry and Menter. [38] Correctly setting the

freestream levels of turbulence is key to the transition location of this model.

Ideally, freestream turbulence levels are measured in an experiment.

&gammaretsst

set_k_inf_w_turb_intsty_percnt = -1.0

set_w_inf_w_eddyviscosity = -1.0

/

set k inf w turb intsty percnt = -1.0

This is the freestream turbulence level as a percentage. A positive value

will set k∞ = 1.5(0.01 ∗ M ∗ set k inf w turb intsty percnt)

2

.

set w inf w eddyviscosity = -1.0

This is the freestream eddy viscosity as the ratio between turbulent

eddy viscosity to laminar viscosity. A positive value will set ω∞ =

k∞/set k inf w turb intsty percnt. If not available, a value in the

range of 0.05 to 5 is commonly used, but the appropriate value is case

specific.

127
B.4.13 &code run control

This namelist controls the length of the simulation. Restart options, Jacobian

update strategy, and angle of attack continuation can also be specified.

&code_run_control

steps = 500

stopping_tolerance = 1.e-15

duration_limit_in_minutes = -1.0

no_restart = .false.

restart_write_freq = 250

restart_read = 'on'

smart_jupdate = .true.

jacobian_eval_freq = 0

jupdate_startup_steps = 10

jupdate_amut_max_change = 0.20

jupdate_cfl_inv_change = 5.0

dfduc3_jacobians = .false.

alpha_sweep = .false.

cycle_increment = 50

alpha_increment = 0.25

alpha_max = 180.0

alpha_min = -180.0

alpha_switchbacks = 0

/

steps = 500

This is the number of time steps or steady iterations to perform.

stopping tolerance = 1.e-15

This instructs the solver to terminate before all steps are complete when

root mean square (RMS) of the residual is less than this tolerance. For

Euler or laminar perfect gas simulations, only the continuity equation

residual is examined. In all other simulations, each equation RMS (continuity, energy, etc.) must meet this tolerance.

duration limit in minutes = -1.0

This is the maximum run duration limit in minutes (a negative value

is unlimited). This limit can terminate the solver before all steps are

complete, which may be helpful if the solver is run as a batch system job

with a time limit. Additional time is required to complete the current

iteration and write restart file. So, allow an extra time margin for code

shutdown. MPI required.

no restart = .false.

When this is .true., no restart checkpoint file is written.

128
restart write freq = 250

The restart checkpoint and convergence history files will be written to

disk every restart write freq time steps.

restart read = ’on’

This defines the solution at the first time step.

‘on’ to initialize the simulation with a solution read from the restart

file. The current convergence history will be concatenated with the prior

solution history.

‘on nohistorykept’ to initialize the simulation with a solution read

from the restart file. The previous history (e.g., residuals, forces, moments) will be discarded.

‘off’ for no restart file read. The solution will be initialized as freestream

or as specified in the &flow initialization namelist.

smart jupdate = .true.

This option allows the code to automatically adjust the Jacobian update

frequency based on residual reduction.

jacobian eval freq = 0

This is the frequency of Jacobian evaluation based on time steps. It

should be set to zero when smart jupdate = .true.

jupdate startup steps = 10

The Jacobians are evaluated at every time step for the first jupdate startup steps,

which aids robustness during initial start transients.

jupdate amut max change = 0.20

For turbulent flow, the Jacobians are refreshed when maximum eddy

viscosity changes by this amount from the maximum eddy viscosity corresponding to the last jacobian evaluation.

jupdate cfl inv change = 5.0

The Jacobians are refreshed when the time term associated with cfl of

the adaptive strategy and the time term of the jacobian evaluation differ

by this amount.

dfduc3 jacobians = .false.

This option only affects eqn type = ’incompressible’. When .true.,

approximate Jacobians are computed that may improve the convergence

of some cases.

129
alpha sweep = .false.

This option activates a procedure to adjust angle of attack during a

simulation. It can be used to calculate a drag polar in a single execution

or explore a hysteresis loop. It is controlled by the following options.

cycle increment = 50

When alpha sweep=.true,

cycle increment < 0 increments angle of attack after residuals have

reached the stopping tolerance.

cycle increment > 0 is the number of iterations between increments

to alpha.

cycle increment = 0 is an inadmissible value.

alpha increment = 0.25

When alpha sweep=.true., increment angle of attack by these many

degrees at a point controlled by cycle increment.

alpha max = 180.0

When alpha sweep=.true., this is the maximum value of angle of attack.

alpha min = -180.0

When alpha sweep=.true., this is the minimum value of angle of attack.

alpha switchbacks = 0

When alpha sweep=.true., this is the number of directional changes in

the angle of attack sweep. When alpha switchbacks > 0, alpha increment

changed in sign after reaching alpha max or alpha min. This allows exploration of hysteresis loops.

130
B.4.14 &nonlinear solver parameters

This namelist defines the temporal accuracy of the solution advancement

scheme. The subiterations and time step size of time accurate simulations

can also be specified. The ramping of the pseudo time advancement CFL

number is also set. Density and pressure floors on the update and relation

factors are available.

&nonlinear_solver_parameters

time_accuracy = 'steady'

time_step_nondim = 0.0

subiterations = 0

temporal_err_control = .false.

temporal_err_floor = 0.1

schedule_number = -1

schedule_iteration(1:2) = 1, 50

schedule_cfl(1:2) = 200.0, 200.0

schedule_cflturb(1:2) = 50.0, 50.0

f_allow_minimum_m = 0.01

invis_relax_factor = 1.0

visc_relax_factor = 1.0

/

time accuracy = ’steady’

This defines the temporal scheme.

‘steady’ for steady state calculations. This is a local time step pseudotime advancement scheme that is not time accurate.

‘1storder’ is a first-order backward differencing scheme (backward Euler) for time-accurate temporal time integration.

‘2ndorder’ is a second-order backward differencing scheme (BDF2 in

[44]) for time-accurate temporal time integration.

‘2ndorderOPT’ is an optimized second-order backward differencing (BDF2opt

in [45]) for time-accurate temporal time integration. This scheme is

second-order accurate in time but has an order-of-magnitude lower leading coefficient than standard BDF2.

‘3rdorder’ is a third-order backward differencing scheme (BDF3 in

[44]) for time-accurate temporal integration.

‘4thorderMEBDF4’ is a fourth-order modified extended backward differencing scheme (MEBDF4 in [44]) for time-accurate temporal integration.

‘4thorderESDIRK4’ is a fourth-order explicit, singly diagonally implicit

Runge-Kutta (ESDIRK4 in [44]) for time-accurate temporal integration.

131
time step nondim = 0.0

This is the nondimensional time step for time accurate simulations.

It is ignored when time accuracy = ’steady’. The nondimensionalization of this parameter depends on eqn type. When eqn type =

’compressible’, it is dt aref

L

, where aref is the reference speed of sound,

and L is unit 1 of the grid. When eqn type = ’incompressible’ or

’generic’, it is dturef

L

, where uref is the reference velocity. See section 2.4 for more details and guidance on appropriate values.

subiterations = 0

Number of subiterations applied to solve the implicit time integration.

It is ignored when time accuracy = ’steady’. A constant CFL time

step is used in each subiteration. By the end of a convergent subiteration

process the pseudo time term drops out, giving the correct temporal

discretization.

temporal err control = .false.

This governs whether the specified number of subiterations are run for

each time step (.false.), or, if the temporal error is monitored and the

subiterations are stopped when a specified tolerance is reached (.true.).

It is ignored when time accuracy = ’steady’.

temporal err floor = 0.1

This sets the tolerance for which time-accurate subiterations are stopped.

The tolerance is given as a multiplicative factor of the flow residuals

(mean and turbulence). It is ignored when time accuracy = ’steady’.

schedule number = -1

This variable is deprecated and will be removed. Please remove it from

your namelist. A warning will be provided if this variable is set.

schedule iteration(1:2) = 1, 50

These are the iteration or subiteration numbers at which CFL numbers

are specified. When time accuracy = ’steady’, this controls the CFL

number of the pseudo-time terms over iterations. When running timeaccurately, this controls the CFL number of the pseudo-time terms of the

linear system over subiterations. The parameter schedule iteration(1)

must be one, because it defines the starting CFL number at the first

iteration or subiteration. The actual CFL number is determined by

a linear ramp from schedule cfl(1) at schedule iteration(1) to

schedule cfl(2) at schedule iteration(2). The CFL number is held

constant at schedule cfl(2) after schedule iteration(2).

132
schedule cfl(1:2) = 200.0, 200.0

This controls the ramping and final CFL number of the meanflow equations. See the description for schedule iteration.

schedule cflturb(1:2) = 50.0, 50.0

This controls the ramping and final CFL number of the turbulence model

equations. See the description for schedule cfl in schedule iteration.

f allow minimum m = 0.01

This limits the solution update to prevent pressure and density from

dropping below this fraction of their freestream values. Applied to

eqn type = ’compressible’ only.

invis relax factor = 1.0

This is the relaxation factor of inviscid terms. It scales the nonlinear

update of the inviscid terms by this fraction and is only used for eqn type

= ’generic’.

visc relax factor = 1.0

This is the relaxation factor of viscous terms. It scales the nonlinear

update of the viscous terms by this fraction and is only used for eqn type

= ’generic’.

133
B.4.15 &linear solver parameters

The Fun3D solution process involves constructing a linearization of the residual with appropriate time terms and then solving this linear system to compute

the solution update. This namelist controls the solution process of this linear

system. The linearization is grouped in to the meanflow equations and the

turbulence model equations.

&linear_solver_parameters

meanflow_sweeps = 15

turbulence_sweeps = 10

linear_projection = .false.

line_implicit = 'off'

/

meanflow sweeps = 15

This is the number of the linear system red-black relaxations at each

steady iteration or time step of the meanflow equations when there is no

turbulence model or a loosely coupled turbulence model. For eqn type

=’generic’ or fully coupled meanflow and turbulence relaxation, this

refers to all equations (meanflow and turbulence).

turbulence sweeps = 10

This is the number of the linear system red-black relaxations at each

steady iteration or time step of the turbulence equations, when the turbulence equations are loosely coupled. It has no effect for fully coupled

meanflow and turbulence relaxation or a simulation without a turbulence

model.

linear projection = .false.

This options uses a Krylov projection method generalized conjugate gradient (GCR) to stabilize and improve convergence of linear system. This

will execute multiple sets of red-black relaxation to form the CGR search

directions, until a convergence criteria is met.

line implicit = ’off’

This option selects the relaxation scheme.

‘off’ uses point implicit relaxation.

‘on’ uses line implicit relaxation where lines are defined and point relaxation elsewhere. The line implicit feature requires construction of these

lines prior to running Fun3D. The lines are stored in the a file named

[project rootname].lines fmt, see section 4.4 for a description. The

aflr3 line extraction utility is distributed with Fun3D to generate

these lines.

134
B.4.16 &boundary conditions

This namelist provides auxiliary information to the boundary conditions. Refer to section 3 for the definition of boundary numbers and other information.

&boundary_conditions

total_pressure_ratio(:) = 1.0

total_temperature_ratio(:) = 1.0

subsonic_inflow_velocity(:) = 'normal'

alpha_bc(:) = 0.0

beta_bc(:) = 0.0

theta1(:) = 0.0

theta2(:) = 0.0

theta3(:) = 0.0

pt_amplitude(:) = 0.0

pt_frequency(:) = 0.0

pt_phase(:) = 0.0

tt_amplitude(:) = 0.0

tt_frequency(:) = 0.0

tt_phase(:) = 0.0

ampl(:) = 0.0

freq(:) = 0.0

phase(:) = 0.0

random(:) = .false.

ramp_constant(:) = 1.0

pressure_relaxation(:) = 1.0

nozzle_symmetry = 1.0

inlet_symmetry = 1.0

npr_set = 0.0

massflow_set_in = 0.0

static_pressure_ratio(:) = 1.0

inlet_solution_method(:) = 'mach'

mach_bc(:) = 0.0

massflow(:) = 0.0

massflow_set_out = 0.0

massflow_dimensions = 'nondim'

grid_units = 'nondim'

q_set(:,1:5) = 0.0

q_set_ramp(:) = 0

profile_type(:) = 'radial_polynomial'

patch_center(:,1:3) = 0.0

patch_scale(:) = 1.0

profile_rho_coef(:,0:6) = 0.0

profile_u_coef(:,0:6) = 0.0

profile_p_coef(:,0:6) = 0.0

profile_coef(:,1:3) = 0.0

135
wall_velocity(:,1:3) = 0.0

rotation_center(:,1:3) = 0.0

rotation_vector(:,1:3) = 0.0

rotation_rate(:) = 0.0

unorm_bc(:) = 0.0

wall_temperature(:) = 1.0

wall_temp_flag(:) = .false.

wall_radeq_flag(:) = .false.

wall_emissivity(:) = 0.8

wall_emissivity_b(:) = 0.

wall_emissivity_c(:) = 0.

wall_emissivity_d(:) = 0.

wall_temp_relax(:) = 0.001

wall_catalysis_model(:) = 'super-catalytic'

catalytic_efficiency_o(:) = 0.

catalytic_efficiency_n(:) = 0.

ablation_option_map(:) = 0

steady_ablation = .false.

ablation_recession_freq = 3000

start_recession = 0

bprime_flag_map(:) = 1

compute_mdot_initial_map(:) = 1

freq_mdot_map(:) = 5000

freq_wall_map(:) = 50

uncoupled_ablation_flag_map(:) = 0

wall_blowing_model(:) = 'none'

virgin_density_wall(:) = 1.

char_density_wall(:) = 1.

CHONSi_frac_char_map(:,1) = 1.

CHONSi_frac_pyrolysis_map(:,1) = 1.

h_ablation_map(:,:) = 0.

mdot_pressure_map(:,:) = 0.

t_sublimation_map(:,:) = 0.

plenum_t0(:) = 1000.

plenum_p0(:) = 1000.

plenum_id(:) = 0

fixed_in_id(:) = 0

fixed_in_rho(:) = 0.

fixed_in_uvw(:,1:3) = 0.

fixed_in_t(:) = 0.

fixed_in_tv(:) = 0.

fixed_in_turb(:,1:7) = 0.

specified_transition(:) = .false.

impose_pressure_gradient = .false.

pressure_gradient = 0.0

136
solidity(:) = 0.0

porous_coefficient(:) = 0.0

x_constant_boundary(:) = .false.

y_constant_boundary(:) = .false.

z_constant_boundary(:) = .false.

tol_const_coord = 1.0e-6

/

total pressure ratio(:) = 1.0

This is the ratio of plenum total pressure to reference pressure used by

7011 boundary condition. Inflow Mach number must be less than one.

total temperature ratio(:) = 1.0

This is the ratio of plenum total temperature to reference temperature

used by 7011 boundary condition. Inflow Mach number must be less

than one.

subsonic inflow velocity(:) = ’normal’

This sets the direction of the inflow velocity.

‘normal’ for inflow normal to each element face in the patch

‘alpha,beta’ the angle of the inflow is specified by alpha bc and

beta bc as shown in Fig. 4.

‘interior’ the angle of the inflow is specified by the Euler angles

theta1, theta2, and theta3 as shown in Fig. B5.

‘offset’ the angle of normal inflow to the patch boundary is rotated

by the Euler angles theta1, theta2, and theta3 as shown in Fig. B5.

alpha bc(:) = 0.0

When subsonic inflow velocity = ’alpha,beta’, this is the angle

of attack in radians for 7011 boundary condition inflow.

beta bc(:) = 0.0

When subsonic inflow velocity = ’alpha,beta’, this is the angle

of sideslip in radians for 7011 boundary condition inflow.

theta1(:) = 0.0

When subsonic inflow velocity = ’interior’ or ’offset’, this is

the Euler angle θ in radians for 7011 boundary condition inflow.

theta2(:) = 0.0

When subsonic inflow velocity = ’interior’ or ’offset’, this is

the Euler angle φ in radians for 7011 boundary condition inflow.

137
theta3(:) = 0.0

When subsonic inflow velocity = ’interior’ or ’offset’, this is

the Euler angle ψ in radians for 7011 boundary condition inflow.

pt amplitude(:) = 0.0

For use with the 7011 boundary condition, this sets the amplitude of

pulsed total pressure. ampl*sin(freq*simulation time+phase*pi/180).

pt frequency(:) = 0.0

For use with the 7011 boundary condition, this sets the frequency of

pulsed total pressure, see ampl.

pt phase(:) = 0.0

For use with the 7011 boundary condition, this sets a phase shift (in

degrees) of the inflow total pressure values, see ampl.

tt amplitude(:) = 0.0

For use with the 7011 boundary condition, this sets the amplitude of

pulsed total temperature conditions.

tt frequency(:) = 0.0

For use with the 7103 boundary condition, this sets the frequency of

pulsed total temperature, see ampl.

tt phase(:) = 0.0

For use with the 7011 boundary condition, this sets a phase shift (in

degrees) of the inflow total temperature, see ampl.

ampl(:) = 0.0

For use with the 7103 boundary condition, this sets the amplitude of

pulsed inflow conditions. Only the velocity is varied using the equation

[u, v, w] = ampl*sin(freq*simulation time+phase*pi/180).

freq(:) = 0.0

For use with the 7103 boundary condition, this sets the frequency of

pulsed inflow velocity values, see ampl.

phase(:) = 0.0

For use with the 7103 boundary condition, this sets a phase shift (in

degrees) of the inflow velocity values, see ampl.

138
random(:) = .false.

For use with the 7103 boundary condition, this creates random fluctuations in in the magnitude of the supersonic inflow conditions in the range

[0,ampl] when .true..

ramp constant(:) = 1.0

For use with 7104 boundary condition, this ramps the velocity magnitude

of supersonic inflow conditions with the exponential expression, (1 −

exp(−simulation time/ramp constant)).

pressure relaxation(:) = 1.0

For use with the 5051 boundary condition, this weights the user specified

back pressure with the solution pressure. p applied = pressure relaxation

* static pressure ratio + ( 1 - pressure relaxation ) * pressure internal

nozzle symmetry = 1.0

Use this factor to scale the area and massflow of a nozzle face. For

example, set to 2.0 to double a nozzle face on a symmetry plane or set

to 1.0 for a full span model.

inlet symmetry = 1.0

Use this factor to scale the area and massflow of an inlet face For example,

set to 2.0 to double an inlet face on a symmetry plane or set to 1.0 for

a full span model.

npr set = 0.0

This sets the nozzle pressure ratio for nozzle component performance.

massflow set in = 0.0

For use with 7036 boundary condition, this is the massflow into the

computational domain in the units of grid squared. Inflow Mach number

must be less than one.

static pressure ratio(:) = 1.0

This is the ratio of specified boundary static pressure to reference pressure used by the 7012 and 5051 boundary conditions. Outflow Mach

number must be less than one.

inlet solution method(:) = ’mach’

This is the solution method for 7031 bc.

‘mach’ adjusts back pressure to attain a Mach number mach bc. Do not

use for a face that has boundary layer ingestion; use ’pressure’ in that

situation.

139
‘massflux’ adjusts back pressure to attain a specified mass flux massflow.

‘pressure’ adjusts back pressure to attain a specified mass flux massflow.

mach bc(:) = 0.0

This is Mach number on boundary face used by 5052 and 7031 boundary

conditions. Outflow Mach number must be less than one.

massflow(:) = 0.0

This is massflow through boundary face in units of grid unit squared

used by 7031 and 7036 boundary conditions. It is nondimensionalized

according to (ρ/ρ∞)(u/u∞)Aboundarycondition.

massflow set out = 0.0

For use with 7031 boundary condition, This is massflow out of the computational domain in units of grid squared. Outflow Mach number must

be less than one.

massflow dimensions = ’nondim’

This is used for converting a user specified dimensional massflow to units

of mesh units squared.

‘nondim’ for nondimensional massflow input (units of mesh squared)

‘english’ for lbm/s

‘metric’ for kg/s

grid units = ’nondim’

This converts a user specified dimensional massflow to units of mesh unit

squared. If massflow is input in units of mesh units squared, grid units

is not required.

‘nondim’ for nondimensional input

‘m’ for meters

‘cm’ for centimeters

‘mm’ for millimeters

‘feet’ for feet

‘inches’ for inches

q set(:,1:5) = 0.0

This sets the primitive variables on boundary face used by boundary

conditions 7100 and 7105.

140
q set ramp(:) = 0

When this is greater than zero, primitive variables on boundary face are

ramped from zero to q set over these iterations, for boundary conditions

7100 and 7105.

profile type(:) = ’radial polynomial’

This switches between inflow profiles,

‘radial polynomial’ defines a radial polynomial about patch center

of size patch scale with profile rho coef, profile u coef, and profile p coef.

‘power law’ defines a power-law velocity profile function with profile coef.

patch center(:,1:3) = 0.0

This is the center of a 7101 bc.

patch scale(:) = 1.0

This scales the radius of a 7101 bc.

profile rho coef(:,0:6) = 0.0

This is the radius polynomial coefficients of density for 7101 bc.

profile u coef(:,0:6) = 0.0

This is the radius polynomial coefficients of u for 7101 bc.

profile p coef(:,0:6) = 0.0

This is the radius polynomial coefficients of pressure for 7101 bc.

profile coef(:,1:3) = 0.0

These three coefficients are wind speed reference, reference height, and

power law exponent,

profile coef(:,1)*(z/profile coef(:,2))**profile coef(:,3)

wall velocity(:,1:3) = 0.0

This is the 4000 solid wall specified translational velocity. It should be

tangent to the boundary to ensure a well-posed problem.

rotation center(:,1:3) = 0.0

This is the 4000 solid wall specified rotational velocity center point, see

rotation vector and rotation rate.

rotation vector(:,1:3) = 0.0

This is the 4000 solid wall specified rotational vector, see rotation center

and rotation rate. Should be unit length.

141
rotation rate(:) = 0.0

This is the 4000 solid wall specified rotational rate, see rotation center

and rotation vector

unorm bc(:) = 0.0

This is the specified velocity in the boundary normal direction, for 4000

solid walls.

wall temperature(:) = 1.0

This is the ratio of wall temperature to reference temperature for eqn type

= ’compressible’ or the wall temperature in degrees Kelvin for eqn type

= ’generic’. If set to -1, then the wall temperature is computed so

that there is zero heat flux, i.e., adiabatic. The wall temp flag must

be set to .true. for this boundary condition to take effect.

wall temp flag(:) = .false.

This must be .true. when specifying the wall temperature via the namelist

variable wall temperature. The default .false. sets Twall

Tref

= 1+

√

Pr(γ−1)M2

2

for eqn type = ’compressible’, see Anderson and Bonhaus [2].

wall radeq flag(:) = .false.

Compute the wall temperature via the Stefan-Boltzmann Law. The radiative equilibrium wall temperature is computed from the heating rate

qwall using qwall = σT4

radeq where the surface emissivity  is entered as

wall emissivity and σ is the Stefan-Boltzmann constant.

wall emissivity(:) = 0.8

This is 0, where emissivity is specified as a function of wall temperature

with the expression  = 0 + T(b + T(c + T d)). The other coefficients

are entered via the following three variables.

wall emissivity b(:) = 0.

This is b in the above equation.

wall emissivity c(:) = 0.

This is c in the above equation.

wall emissivity d(:) = 0.

This is d in the above equation.

wall temp relax(:) = 0.001

This is the relaxation factor η used for wall radeq flag wall temperature boundary condition. The wall temperature is updated as T

new =

T

old + η ∗ (Tradeq − Told)

142
wall catalysis model(:) = ’super-catalytic’

This defines the catalytic efficiency of the wall to promote recombination

of atoms to molecules. Allowable options are:

‘super-catalytic’ Forces the mass fraction of species at the wall to

equal the mass fractions specified for the free stream in the tdata file.

‘fully-catalytic’ Specifies a catalytic efficiency of 1 thereby forcing

homogeneous recombination of atoms diffusing to the wall.

‘non-catalytic’ Specifies a zero mole fraction gradient at the wall -

signifying zero catalytic efficiency.

‘equilibrium-catalytic’ Computes the equilibrium chemical composition of species at the wall temperature and pressure.

‘constant-catalytic’ Catalytic efficiency is user specified constants

‘Stewart-RCG’ Reaction cured glass from Stewart

‘Zoby-RCG’ Reaction cured glass from Zoby

‘Scott-RCG’ Reaction cured glass from Scott

‘CSiC’ Experimental CSiC from JSC for X-38

‘RCC-LVP’ Stewart NASA TM 112206

‘CCAT-ACC’ Shuttle RCC from Stewart NASA TM 112206

‘CSiC-SNECMA’ Derived from Stewart RCC

catalytic efficiency o(:) = 0.

This is the fraction of diffusion flux of atomic oxygen striking wall

that is converted to molecular oxygen, when wall catalysis model =

’constant-catalytic’.

catalytic efficiency n(:) = 0.

This is the fraction of diffusion flux of atomic nitrogen striking wall

that is converted to molecular nitrogen, when wall catalysis model =

’constant-catalytic’.

ablation option map(:) = 0

This is an integer that specifies whether the pyrolysis ablation rate and

wall temperature are computed in addition to the char ablation rate.

This option only affects cases with bprime flag map equal to 0 or 1.

‘0’ The pyrolysis ablation rate and wall temperature are computed, in

addition to the char ablation rate, assuming steady-state ablation.

‘1’ The pyrolysis ablation rate and wall temperature are held constant

(they are set to the values present in ablation from laura.m) while the

char ablation rate is computed.

143
steady ablation = .false.

This flags triggers the surface deformation and mesh movement through

aeroelastic deformation. Note: this flags only applies to the internal

Fun3D coupled-ablation mechanism and is not applicable to Fun3dCHAR coupled ablation. Default: .false.

ablation recession freq = 3000

It is an integer that specifies the frequency of surface recession update.

This flags only works with steady ablation = .true.. Default: 3000

start recession = 0

It is an integer that specifies when to start applying recession for surface

deformation. Default: 0

bprime flag map(:) = 1

This is an integer defining if the b-prime approach is applied. Applicable

only for blowing model equil char quasi steady = 0.

‘0’ Do not use bprime approach, and instead use a rigorous diffusion

model. This option is consistent with the ”Fully-Coupled” approach

defined in Ref. [2].

‘1’ Use b-prime approach. This option is consistent with the ”PartiallyCoupled” approach defined in Ref. [2].

‘2’ Hold the ablation rate and wall temperature constant from the

restart file, while applying the rigorous diffusion model (thus, the surface

energy balance and char equilibrium constraint are not satisfied). This

option is sometimes useful when transitioning from a bprime flag = 1

computation to a bprime flag = 0 computation.

compute mdot initial map(:) = 1

This is an integer defining if the ablation rates are computed before the

first flowfield iteration.

‘0’ Applies the ablation rates and wall temperatures present in the

ablation from laura.m file.

‘1’ Computes the ablation rates and wall temperatures before the first

flowfield iteration.

freq mdot map(:) = 5000

For bprime flag map = 1, this is an integer defining frequency of updating ablation rates and wall temperature.

144
freq wall map(:) = 50

For bprime flag = 1, this is an integer defining frequency of update

to ablation wall boundary conditions. For bprime flag = 0, an integer defining frequency of update to the surface energy balance solution,

which defines the wall temperature.

uncoupled ablation flag map(:) = 0

This is an integer defining if an uncoupled ablation analysis is applied.

The uncoupled ablation option is included to provide a baseline solution

for the coupled ablation analysis.

‘0’ Do not apply an uncoupled ablation analysis.

‘1’ Apply an uncoupled ablation analysis to a converged non-ablating

flowfield.

wall blowing model(:) = ’none’

This is the blowing or ablation model.

‘none’ No wall blowing

‘specified’ blowing rate is user specified function of pressure (see also

mdot press)

‘porous chamber’ Special options for simulation of buoyancy driven

flow in pressurized rig for BNNT production

‘quasi steady’ Compute ablation rate as function of surface energy

balance and equilibrium catalytic bc

‘equil char quasi steady’ Include equilibrium char approximation

‘FIAT’ Couple to material response code FIAT (not active)

virgin density wall(:) = 1.

This is the density (kg/m3) of thermal protection system ablator in virgin

state (prior to heating level sufficient to cause any reactions).

char density wall(:) = 1.

This is the density (kg/m3) of remaining char in ablator after binding

resins have pyrolized.

CHONSi frac char map(:,1) = 1.

See definition below for CHONSi frac pyrolysis map

CHONSi frac pyrolysis map(:,1) = 1.

These arrays set elemental mass fraction (second index) of C, H, O, N,

Si, Fe, Mg, Na, B species for char and pyrolysis gas. The fractions in

each array should sum to 1.

145
h ablation map(:,:) = 0.

This is a vector of extent 3 used to compute the heat of ablation in MJ/kg

for quasi steady blowing option as h ablation 0(1) + (h ablation 0(2)

) log pw + (h ablation 0(3))(log pw)**2 where pw is the local

pressure, in atmospheres.

mdot pressure map(:,:) = 0.

This is a vector of extent 2 is used to set the blowing or suction distribution defined as mdot pressure 0(1) + (mdot pressure 0(2))*p/

(rho inf*V inf**2) where p is the local pressure, rho inf is the reference density, and V inf is the reference velocity. Positive value produces

blowing distribution, while negative value produces suction distribution.

t sublimation map(:,:) = 0.

This is a vector of extent 3 used to compute the sublimation temperature

in degrees Kelvin for quasi steady blowing option as t sublimation 0(1)

+ (t sublimation 0(2)) log pw + (t sublimation 0(3))(log pw)

**2 where pw is the local pressure, in atmospheres.

plenum t0(:) = 1000.

For use with the 7021 boundary condition, this is the total plenum temperature in Kelvin.

plenum p0(:) = 1000.

For use with the 7021 boundary condition, The total plenum pressure in

N/m2(Pascals) feeding this boundary.

plenum id(:) = 0

For use with the 7021 boundary condition (one or more rcs jet plenum

bcs), the jet plenum contains this species set from the file tdata. For

example, if an RCS jet is firing H2 and O2 into an air stream, the tdata

file may look like:

One Temperature

N

O

N2 0.76

O2 0.24

NO

H2 0.5

O2 0.5

OH

H

O

146
In this case, if the boundary to the plenum is surface number 5 then

plenum id(5)=2, the second grouping of species in the tdata file. The

numbers following the species name define the mass fraction of that

species at the inflow boundary. The sum of the mass fraction in each

group must equal one. Species groups are separated by blank lines and

multiple RCS jets may be defined in this manner.

fixed in id(:) = 0

For use with the 70XX boundary condition (one or more supersonic

inflow bcs) the supersonic inflow boundary condition contains the species

set in the same way as the plenum id for the rcs jet plenum boundary

condition described above

fixed in rho(:) = 0.

For use with the 70XX boundary condition (one or more supersonic

inflow bcs) the dimensional inflow mixture density in kg/m**3

fixed in uvw(:,1:3) = 0.

For use with the 70XX boundary condition (one or more supersonic inflow bcs) the dimensional inflow Cartesian velocity components in m/sec

fixed in t(:) = 0.

For use with the 70XX boundary condition (one or more supersonic

inflow bcs) the dimensional inflow translational rotational temperature

in Kelvin

fixed in tv(:) = 0.

For use with the 70XX boundary condition (one or more supersonic

inflow bcs) the dimensional inflow vibrational-electronic temperature in

Kelvin

fixed in turb(:,1:7) = 0.

For use with the 70XX boundary condition (one or more supersonic

inflow bcs) This is for the turbulence models for a one-equation model

this is the ratio of the inflow eddy viscosity to the inflow molecular

viscosity, for a two-equation model this is: the inflow turbulence intensity

and the ratio of the inflow eddy viscosity to the inflow molecular viscosity

Full Reynolds stress models are not currently supported

specified transition(:) = .false.

When .true., a turbulent transition point will be imposed on the solution.

147
impose pressure gradient = .false.

When .true., a global pressure gradient in the x-direction of pressure gradient

will be imposed as a source term to the residual.

pressure gradient = 0.0

The nondimensional pressure gradient in the x-direction, imposed when

impose pressure gradient = .true.

solidity(:) = 0.0

This is the percent solidity to be applied to the passive porosity boundary

conditions.

porous coefficient(:) = 0.0

This is the Darcy law equation coefficient.

x constant boundary(:) = .false.

This specifies that a boundary is an x constant face for mesh movement,

constraining motion the to be tangent to face. Set automatically for

x-symmetry boundaries.

y constant boundary(:) = .false.

This specifies that a boundary is an y constant face for mesh movement,

constraining motion the to be tangent to face. Set automatically for

y-symmetry boundaries.

z constant boundary(:) = .false.

This specifies that a boundary is an z constant face for mesh movement,

constraining motion the to be tangent to face. Set automatically for

z-symmetry boundaries.

tol const coord = 1.0e-6

This is the tolerance for verifying that a boundary surface is a planar

boundary for mesh movement by restricting the minimum and maximum

value in the “constant” direction.

148
B.4.17 &two d trans

This namelist is used to specify a 2D transition location. If the airfoil is split

into upper and lower patches, the transition location can be specified independently on each patch. If there is only a single patch, it can be split with a z

value to designate the upper and lower airfoil surfaces. This transition specification is limited to specifying transition on a single-element configuration such

as an airfoil or a flat plate. Only a single transition location is supported for

multi-element airfoils. Transition is modeled by turning off the turbulent production terms in “laminar” regions of the grid. This option is only valid for the

perfect gas SA turbulence model. This is the same approach taken in CFL3D

and NSU3D.Fun3D results from this approach for a DLR-F6 transonic cruise

condition are shown in Lee-Rausch et al. [46]

&two_d_trans

turb_transition = .false.

use_2d_values = .false.

upper_patch = 1

lower_patch = 1

use_z_value = .false.

z_location = 0.0

upper_x_location = 0.0

lower_x_location = 0.0

/

turb transition = .false.

This must be .true. to specify laminar regions of flow during a turbulent

flow simulation.

use 2d values = .false.

This enables 2D transition specification.

upper patch = 1

This is the upper patch with specified transition.

lower patch = 1

This is the lower patch with specified transition.

use z value = .false.

This allows a single patch to be split into upper and lower surfaces of an

airfoil by a z plane.

z location = 0.0

This is the z location to split the airfoil if use z value = .true.

149
upper x location = 0.0

This is the upper surface x transition location.

lower x location = 0.0

This is the lower surface x transition location.

150
B.4.18 &three d trans

This namelist is used to specify 3D boundary layer transition locations. The

command line option --turb transition is required to activate. If you run

the flow solver without the --turb transition, it will default to fully turbulent even though you have the laminar boundaries defined. Transition is

modeled by the turning off the turbulent production terms in “laminar” regions of the grid. This option is only valid for the perfect gas SA turbulence

model. This is the same approach taken in CFL3D and NSU3D.Fun3D results from this approach for a DLR-F6 transonic cruise condition are shown

in Lee-Rausch et al. [46]

&three_d_trans

use_3d_values = .false.

n_transition_group = 1

transition_group_patches(:) = '1'

transition_x1(:) = 0.0

transition_y1(:) = 0.0

transition_x2(:) = 0.0

transition_y2(:) = 1.0

/

use 3d values = .false.

This turns 3D transition specification on.

n transition group = 1

This is the number of patch groups, limited to 100.

transition group patches(:) = ’1’

This is the patch indexes for each group. Commas and dashes can be

used to specify ranges, i.e., ’1,2,5-7’.

transition x1(:) = 0.0

This is the x value for determining the start of the transition line.

transition y1(:) = 0.0

This is the y value for determining the start of the transition line.

transition x2(:) = 0.0

This is the x value for determining the end of the transition line.

transition y2(:) = 1.0

This is the y value for determining the end of the transition line.

151
B.4.19 &flow initialization

This namelist allows the user to initialize regions of the meanflow solution with

quantities other than freestream. A maximum of 100 volumes can be defined.

The volumes may overlap each other as well as domain boundaries. In the event

that a grid point is contained in more than one volume, a subsequent volume

in this file will supersede the volumes listed before it. Boundary conditions

supersede the flow initialization.

&flow_initialization

number_of_volumes = 0

type_of_volume(:) = 'none'

center(1:3,:) = 0.0

radius(:) = 0.0

point1(1:3,:) = 0.0

point2(1:3,:) = 0.0

radius1(:) = 0.0

radius2(:) = 0.0

rho(:) = 1.0

c(:) = 1.0

u(:) = 0.0

v(:) = 0.0

w(:) = 0.0

mass_fraction(:,:) = 1.e-20

temperature(:,:) = 1000.

/

number of volumes = 0

This is the number of initialization volumes.

type of volume(:) = ’none’

This is the type of initialization volume.

‘box’ for a box. The diagonal corners are specified by point1 and

point2.

‘sphere’ for a sphere. The position and size is specified by center and

radius.

‘cylinder’ for a cylinder with size radius. The center axis is defined

between point1 and point2.

‘cone’ for a cone or frustum. The center axis is defined between point1

and point2. Two radii are required, radius1 at point1 and radius2

at point2. A frustum is specified with two nonzero radii.

center(1:3,:) = 0.0

This is the center of the ’sphere’ volume type.

152
radius(:) = 0.0

This is the radius of the ’sphere’ and ’cylinder’ volume types.

point1(1:3,:) = 0.0

This is one end of the ’cone’ or ’cylinder’ volume types or one corner

of a ’box’ volume type.

point2(1:3,:) = 0.0

This is the other end of the ’cone’ or ’cylinder’ volume types or the

opposite corner of a ’box’ volume type.

radius1(:) = 0.0

This is the radius at point1 of ’cone’ volume type.

radius2(:) = 0.0

This is the radius at point2 of ’cone’ volume type.

rho(:) = 1.0

This is the nondimensional density in the volume.

c(:) = 1.0

This is the nondimensional speed of sound in the volume.

u(:) = 0.0

This is the nondimensional x-component of velocity in the volume.

v(:) = 0.0

This is the nondimensional y-component of velocity in the volume.

w(:) = 0.0

This is the nondimensional z-component of velocity in the volume.

mass fraction(:,:) = 1.e-20

This is the species mass fraction array in the volume. The maximum

number of species is hardwired to 50 in this namelist. All mass fractions

are initialized to trace values (1.e-20) so it is only necessary to define

non-trace species.

temperature(:,:) = 1000.

This is the translational-rotational and vibrational electronic temperature array in the volume, in units of Kelvin.

153
B.4.20 &component parameters

This namelist provides expanded ability to track forces, moments, and massflows according to user-specified groups of boundary patches that define a

“component.”

&component_parameters

number_of_components = 0

component_count(:) = 0

component_xmc(:) = x_moment_center

component_ymc(:) = y_moment_center

component_zmc(:) = z_moment_center

component_cref(:) = x_moment_length

component_bref(:) = y_moment_length

component_sref(:) = reference_area

component_hinge_sweep(:) = 0.0

component_hinge_dihedral(:) = 0.0

component_input(:) = ''

component_name(:) = ''

calculate_cd(:) = .false.

calculate_thrust_ratio(:) = .false.

massflow_component(:) = 0

throat_area(:) = 0.0

units(:) = ''

npr(:) = 0.0

allow_flow_through_forces = .false.

/

number of components = 0

This is the number of components (groups of boundary patches) to track.

component count(:) = 0

This is the number of boundary patches assigned to a component. If -1

is given, this number is computed implicitly from component input.

component xmc(:) = x moment center

This is x-coordinate of the moment center assigned to a component. The

default value comes from the force and moment namelist, &force moment integ properties.

component ymc(:) = y moment center

This is y-coordinate of the moment center assigned to a component. The

default value comes from the force and moment namelist, &force moment integ properties.

component zmc(:) = z moment center

This is z-coordinate of the moment center assigned to a component. The

default value comes from the force and moment namelist, &force moment integ properties.

154
component cref(:) = x moment length

This is the x-direction reference length assigned to a component used to

non-dimensionalize moments about y (pitching moment). The default

value comes from the force and moment namelist &force moment integ properties.

component bref(:) = y moment length

This is the y-direction reference length assigned to a component used to

non-dimensionalize moments about x (rolling moment) and z (yawing

moment). The default value comes from the force and moment namelist

&force moment integ properties.

component sref(:) = reference area

This is the reference area assigned to a component used to non-dimensionalize

forces and moments. The default value comes from the force and moment

namelist &force moment integ properties.

component hinge sweep(:) = 0.0

This is the hinge sweep angle in degrees assigned to a component used

to non-dimensionalize moments about y (pitching moment). The default

value is zero.

component hinge dihedral(:) = 0.0

This is the hinge dihedral angle in degrees assigned to a component used

to non-dimensionalize moments about x (rolling moment). The default

value is zero.

component input(:) = ’’

This is the list of boundary patches to assigned to a component. Boundary indexes are separated with commas and dashes can be used to specify

ranges, i.e., ’1,2,5-7’.

component name(:) = ’’

This is the component output filename, [project rootname] fm [component name]

.dat.

calculate cd(:) = .false.

This will request an ideal mass flow calculation for component n.

calculate thrust ratio(:) = .false.

This will request a thrust ratio calculation for component n.

massflow component(:) = 0

Specifies what component to get the physical mass flow from to calculate

the ideal thrust.

155
throat area(:) = 0.0

This is the throat area associated with component n.

units(:) = ’’

This is the units of the throat area specified.

npr(:) = 0.0

This is the set nozzle pressure ratio associated with component n.

allow flow through forces = .false.

Pressure drag and skin friction forces are by default calculated only on

boundary faces designated as solid surfaces ( viscous or inviscid ). To

include the pressure and momentum flux forces due to nozzles or inlets allow flow through forces should be set to .true.. The flowthrough faces to be tracked should be listed in the component count

and component input lists accordingly.

156
B.4.21 &time avg params

This namelist controls the bookkeeping of time average and root mean square

statistics for every point in the domain. Tracking these statistics enables visualization of variables like p tavg, u trms, etc. See the visualization output

variable namelists &volume output variables, &boundary output variables,

and &sampling output variables for details. When these statistics are tracked,

the file [project rootname] TAVG.1 maintains information across restarts.

This statistics file is similar to the [project rootname].flow restart file in

that is not intended for the user to interact with directly.

&time_avg_params

itime_avg = 0

prior_time_avg = 0

use_prior_time_avg = 0

tavg_header_version = 1

/

itime avg = 0

This controls collection of statistics.

‘0’ does not compute time averaging statistics.

‘1’ computes time averaging statistics.

prior time avg = 0

This option specifies if a statistics file [project rootname] TAVG.1 exists.

‘0’ when no time averaging file exists.

‘1’ when time averaging file from previous run exists.

use prior time avg = 0

If available, use prior statistics.

‘0’ for discarding the prior statistics.

‘1’ for using and appending to the prior statistics.

tavg header version = 1

This option controls the variables for which statistics are collected.

‘1’ primitive variable averages and root mean squares

‘2’ primitive variable averages and root mean squares and the averages

of u’v’,u’w’,v’w’,mu t,vort mag.

157
B.4.22 &global

This namelist controls the frequency of visualization output and the logging of

command line options. It also serves to control some global options otherwise

set by command-line input

&global

moving_grid = .false.

grid_motion_only = .false.

grid_motion_and_dci_only = .false.

body_motion_only = .false.

timing = .false.

time_moving_grid = .false.

boundary_animation_freq = 0

volume_animation_freq = 0

slice_freq = 0

record_command_lines = .false.

/

moving grid = .false.

This governs whether the grid is moving or stationary

grid motion only = .false.

This turns off the flow solve during a simulation for which moving grid =

.true.. If the simulation involves overset grids, this command overrides

dci on the fly and DCI files are not output.

grid motion and dci only = .false.

This turns off the flow solve during a simulation for which moving grid

= .true.. If the simulation involves overset grids, this command honors

dci on the fly and DCI files are output if dci on the fly = .true..

body motion only = .false.

This turns off both the flow solve and the linear elasticity solve during a simulation for which moving grid = .true. and grid motion =

’deform’

timing = .false.

This triggers a timing of the execution of various sections of the flow

solver.

time moving grid = .false.

This triggers timing of the execution of various sections of the flow solver,

with emphasis on operations associated with grid motion. The timing

occurs over larger sections of the code than the timing option. For

158
correct timing information, timing and time moving grid should not

be used simultaneously.

boundary animation freq = 0

This is the visualization output frequency of the domain boundaries.

Zero is no output, -1 is output at the end of run, and a positive integer

is periodic output every boundary animation freq iterations. See the

&boundary output variables namelist for more details.

volume animation freq = 0

This is the visualization output frequency of the domain volume. Zero

is no output, -1 is output at the end of run, and a positive integer is periodic output every volume animation freq iterations. See &volume output variables

namelist for more details.

slice freq = 0

This is the output frequency of boundary slices for visualization and to

obtain loads. Zero is no output, -1 is output at the end of run, and

a positive integer is periodic output every slice freq iterations. See

&slice data namelist for more details.

record command lines = .false.

This creates a file temp.commands that contains the command line arguments

159
B.4.23 &volume output variables

This namelist controls volume variable output. Output frequency is controlled

by volume animation freq in the &global namelist. The resulting volumedata files have the following naming convention for export to=’tecplot’

output:

[project_rootname]_part[P]_tec_volume_timestep[T](.dat|.plt) if freq > 0

[project_rootname]_Part[P]_tec_volume(.dat|.plt) if freq < 0

where P = 1,2,. . . ,nproc (number of processors) and T is the iteration number.

The file extension is .dat for ASCII Tecplot format and .plt for binary

Tecplot format. Within the files, a single zone is written, with the zone

title “time 0.0000000E+00 processor 32” where the time value is the integer

iteration number for steady-state cases, and the current (non-dimensional)

time for time-dependent cases.

A request to output an undefined variable will overruled, i.e., turb1 will

be forced to .false regardless of user input when there is no turbulence model

in the simulation.

&volume_output_variables

export_to = 'tecplot'

x = .true.

y = .true.

z = .true.

primitive_variables = .true.

rho = .false.

u = .false.

v = .false.

w = .false.

p = .false.

entropy = .false.

mach = .false.

temperature = .false.

iblank = .false.

imesh = .false.

vort_mag = .false.

vort_x = .false.

vort_y = .false.

vort_z = .false.

q_criterion = .false.

div_vel = .false.

turbulent_fluctuations = .false.

uuprime = .false.

vvprime = .false.

wwprime = .false.

160
uvprime = .false.

uwprime = .false.

vwprime = .false.

cp = .false.

dp_pinf = .false.

volume = .false.

residuals = .false.

res1 = .false.

res2 = .false.

res3 = .false.

res4 = .false.

res5 = .false.

res_gcl = .false.

primitive_tavg = .false.

rho_tavg = .false.

u_tavg = .false.

v_tavg = .false.

w_tavg = .false.

p_tavg = .false.

primitive_trms = .false.

rho_trms = .false.

u_trms = .false.

v_trms = .false.

w_trms = .false.

p_trms = .false.

lambda1 = .false.

lambda2 = .false.

lambda3 = .false.

lambda4 = .false.

lambda5 = .false.

lambda6 = .false.

lambda7 = .false.

htot = .false.

ttot = .false.

ptot = .false.

etot = .false.

processor_id = .false.

turb_ke = .false.

turb_diss = .false.

mu_t = .false.

turb1 = .false.

turb2 = .false.

turb3 = .false.

turb4 = .false.

turb5 = .false.

161
turb6 = .false.

turb7 = .false.

turres1 = .false.

turres2 = .false.

turres3 = .false.

turres4 = .false.

turres5 = .false.

turres6 = .false.

turres7 = .false.

slen = .false.

iflagslen = .false.

hrles_blend = .false.

reconstruction_limiter_phi1 = .false.

reconstruction_limiter_phi2 = .false.

reconstruction_limiter_phi3 = .false.

reconstruction_limiter_phi4 = .false.

reconstruction_limiter_phi5 = .false.

tt = .false.

tv = .false.

sonic = .false.

mixture_mol_weight = .false.

mixture_density = .false.

ev = .false.

rho_i(1:n_species) = .false.

mu = .false.

id_l2g = .false.

divided_residuals = .false.

/

export to = ’tecplot’

file format of volume export

‘tecplot’ is Tecplot format (one file written for each processor)

‘cgns’ is CGNS format, requires Fun3D to be configured with a CGNS

library. This format already includes x, y, and z. Set these variables to

.false. to avoid duplication.

‘fvuns’ is FieldView C-binary (Fortran stream) format. This format

already includes x, y, and z. Set these variables to .false. to avoid

duplication.

‘fv’ is depreciated. Slated for removal, use ’fvuns’

‘vtk’ is legacy VTK format This format already includes x, y, and z.

Set these variables to .false. to avoid duplication.

‘csv’ is comma separated value format

‘sol’ is INRIA Metrix sol format

162
‘tec’ is a single image ASCII Tecplot format

‘raw ascii’ is a single image ASCII space separated format

‘native’ is the most efficient way to export the entire flow field to disk

at every time step when the grid is over a billion elements, but requires

specialized visualization tools to read.

x = .true.

X-coordinate

y = .true.

Y -coordinate

z = .true.

Z-coordinate

primitive variables = .true.

Output primitive variables: rho, u, v, w, and p

rho = .false.

Density

u = .false.

X-component of velocity

v = .false.

Y -component of velocity

w = .false.

Z-component of velocity

p = .false.

Pressure

entropy = .false.

Entropy

mach = .false.

Mach number

temperature = .false.

Temperature

iblank = .false.

I-blanking variable (default becomes .true. for overset mesh cases)

163
imesh = .false.

For overset mesh systems, index of associated component grid where 0

indicates background grid

vort mag = .false.

Vorticity magnitude

vort x = .false.

X-component of vorticity

vort y = .false.

Y -component of vorticity

vort z = .false.

Z-component of vorticity

q criterion = .false.

Q Criterion, the second invariant of ∇V

div vel = .false.

Velocity divergence

turbulent fluctuations = .false.

Activate all the following XYprime turbulent shear stresses normalized by

u

2

ref ; the definition of these variables depends on the turbulence model,

see http://turbmodels.larc.nasa.gov/noteonrunning.html for details

uuprime = .false.

Turbulence fluctuation, u

0u0

vvprime = .false.

Turbulence fluctuation, v

0

v

0

wwprime = .false.

Turbulence fluctuation, w

0w0

uvprime = .false.

Turbulence fluctuation, u

0

v

0

uwprime = .false.

Turbulence fluctuation, u

0w0

vwprime = .false.

Turbulence fluctuation, v

0w0

164
cp = .false.

Pressure coefficient

dp pinf = .false.

Normalized delta pressure (p − p∞)/p∞

volume = .false.

Dual-cell volume size

residuals = .false.

Activate all resN variables

res1 = .false.

Residual of equation 1, density

res2 = .false.

Residual of equation 2, x-momentum

res3 = .false.

Residual of equation 3, y-momentum

res4 = .false.

Residual of equation 4, z-momentum

res5 = .false.

Residual of equation 5, energy

res gcl = .false.

For moving meshes, residual of grid conservation law

primitive tavg = .false.

Output time-averaged primitives (requires &time avg params namelist):

rho tavg, u tavg, v tavg, w tavg, and p tavg

rho tavg = .false.

Time-averaged density

u tavg = .false.

Time-averaged x-component of velocity

v tavg = .false.

Time-averaged y-component of velocity

w tavg = .false.

Time-averaged z-component of velocity

165
p tavg = .false.

Time-averaged pressure

primitive trms = .false.

Output root mean squared primitives (requires &time avg params namelist):

rho trms, u trms, v trms, w trms, and p trms

rho trms = .false.

RMS-average of density

u trms = .false.

RMS-average of x-component of velocity

v trms = .false.

RMS-average of y-component of velocity

w trms = .false.

RMS-average of z-component of velocity

p trms = .false.

RMS-average of pressure

lambda1 = .false.

Adjoint Lagrange multiplier for equation 1 (when running the adjoint,

the primitive variables are turned off, and this is turned on)

lambda2 = .false.

Adjoint Lagrange multiplier for equation 2 (when running the adjoint,

the primitive variables are turned off, and this is turned on)

lambda3 = .false.

Adjoint Lagrange multiplier for equation 3 (when running the adjoint,

the primitive variables are turned off, and this is turned on)

lambda4 = .false.

Adjoint Lagrange multiplier for equation 4 (when running the adjoint,

the primitive variables are turned off, and this is turned on)

lambda5 = .false.

Adjoint Lagrange multiplier for equation 5 (when running the adjoint,

the primitive variables are turned off, and this is turned on)

lambda6 = .false.

Adjoint Lagrange multiplier for equation 6 (when running the adjoint,

the primitive variables are turned off, and this is turned on)

166
lambda7 = .false.

Adjoint Lagrange multiplier for equation 7 (when running the adjoint,

the primitive variables are turned off, and this is turned on)

htot = .false.

Total enthalpy per unit volume

ttot = .false.

Total temperature

ptot = .false.

Total pressure

etot = .false.

Total energy per unit volume

processor id = .false.

Processor on which a node resides

turb ke = .false.

Turbulence kinetic energy

turb diss = .false.

Turbulence dissipation rate

mu t = .false.

Turbulent eddy viscosity

turb1 = .false.

Turbulence variable 1 (model dependent)

turb2 = .false.

Turbulence variable 2 (model dependent)

turb3 = .false.

Turbulence variable 3 (model dependent)

turb4 = .false.

Turbulence variable 4 (model dependent)

turb5 = .false.

Turbulence variable 5 (model dependent)

turb6 = .false.

Turbulence variable 6 (model dependent)

167
turb7 = .false.

Turbulence variable 7 (model dependent)

turres1 = .false.

Residual of 1st turbulence equation

turres2 = .false.

Residual of 2nd turbulence equation

turres3 = .false.

Residual of 3rd turbulence equation

turres4 = .false.

Residual of 4th turbulence equation

turres5 = .false.

Residual of 5th turbulence equation

turres6 = .false.

Residual of 6th turbulence equation

turres7 = .false.

Residual of 7th turbulence equation

slen = .false.

Length to the nearest solid wall boundary

iflagslen = .false.

Turbulence model distance function closest boundary entity. (a negative

sign indicates the node has been prescribed as laminar)

hrles blend = .false.

HRLES blending function

reconstruction limiter phi1 = .false.

φ for the node-based reconstruction limiters (equation 1)

reconstruction limiter phi2 = .false.

φ for the node-based reconstruction limiters (equation 2)

reconstruction limiter phi3 = .false.

φ for the node-based reconstruction limiters (equation 3)

reconstruction limiter phi4 = .false.

φ for the node-based reconstruction limiters (equation 4)

168
reconstruction limiter phi5 = .false.

φ for the node-based reconstruction limiters (equation 5)

tt = .false.

Translational temperature only for eqn type = ’generic’

tv = .false.

Vibrational temperature only for eqn type = ’generic’

sonic = .false.

Frozen speed of sound only for eqn type = ’generic’

mixture mol weight = .false.

Mixture molecular weight only for eqn type = ’generic’

mixture density = .false.

Mixture density only for eqn type = ’generic’

ev = .false.

Vibrational energy only for eqn type = ’generic’

rho i(1:n species) = .false.

Species concentration only for eqn type = ’generic’

mu = .false.

Total viscosity

id l2g = .false.

Local-to-global node map

divided residuals = .false.

adds a vol suffix to the residual output variable names and divide by

volume

169
B.4.24 &boundary output variables

This namelist controls the boundary variable output. Output frequency is

controlled by boundary animation freq in the &global namelist. By default,

the output of solution data for all solid surfaces in 3D and on one y-constant

symmetry plane in 2D is included unless boundary list is specified.

Each time boundary data output is triggered, all output boundaries are

written to one file with the following naming convention:

[project_rootname]_tec_boundary_timestep[T](.dat|.plt) if N > 0

[project_rootname]_tec_boundary(.dat|.plt) if N < 0

where T is the iteration number. The file extension is .dat for ASCII Tecplot format and .plt for binary Tecplot format. Within the files, each

boundary is written as a separate zone. The zones are identified with the title

“time 0.0000000E+00 boundary 5” where the time value is the integer iteration number for steady-state cases, and the current (non-dimensional) time

for time-dependent cases.

By default, output is in the inertial reference frame. For moving body

problems, the &observer motion namelist can be used to change the visualization reference system to a body reference system or a reference system with

arbitrary motion.

A request to output an undefined variable will overruled, i.e., turb1 will

be forced to .false regardless of user input when there is no turbulence model

in the simulation.

&boundary_output_variables

number_of_boundaries = 0

boundary_list = ''

x = .true.

y = .true.

z = .true.

primitive_variables = .true.

rho = .false.

u = .false.

v = .false.

w = .false.

p = .false.

entropy = .false.

mach = .false.

temperature = .false.

iblank = .false.

imesh = .false.

vort_mag = .false.

vort_x = .false.

vort_y = .false.

170
vort_z = .false.

q_criterion = .false.

div_vel = .false.

turbulent_fluctuations = .false.

uuprime = .false.

vvprime = .false.

wwprime = .false.

uvprime = .false.

uwprime = .false.

vwprime = .false.

cp = .false.

dp_pinf = .false.

volume = .false.

residuals = .false.

res1 = .false.

res2 = .false.

res3 = .false.

res4 = .false.

res5 = .false.

res_gcl = .false.

primitive_tavg = .false.

rho_tavg = .false.

u_tavg = .false.

v_tavg = .false.

w_tavg = .false.

p_tavg = .false.

primitive_trms = .false.

rho_trms = .false.

u_trms = .false.

v_trms = .false.

w_trms = .false.

p_trms = .false.

lambda1 = .false.

lambda2 = .false.

lambda3 = .false.

lambda4 = .false.

lambda5 = .false.

lambda6 = .false.

lambda7 = .false.

htot = .false.

ttot = .false.

ptot = .false.

etot = .false.

processor_id = .false.

turb_ke = .false.

171
turb_diss = .false.

mu_t = .false.

turb1 = .false.

turb2 = .false.

turb3 = .false.

turb4 = .false.

turb5 = .false.

turb6 = .false.

turb7 = .false.

turres1 = .false.

turres2 = .false.

turres3 = .false.

turres4 = .false.

turres5 = .false.

turres6 = .false.

turres7 = .false.

slen = .false.

tt = .false.

tv = .false.

sonic = .false.

mixture_mol_weight = .false.

mixture_density = .false.

ev = .false.

rho_i(1:n_species) = .false.

mu = .false.

id_l2g = .false.

vort_x_rms = .false.

vort_y_rms = .false.

vort_z_rms = .false.

vort_mag_rms = .false.

vort_mag_tavg = .false.

yplus = .false.

mu_t_tavg = .false.

cmu_star = .false.

bird_breakdown = .false.

recovery_temperature = .false.

turb_mach = .false.

turbindex = .false.

average_velocity = .false.

uavg = .false.

vavg = .false.

wavg = .false.

cf_x = .false.

cf_y = .false.

cf_z = .false.

172
skinfr = .false.

cq = .false.

shear_x = .false.

shear_y = .false.

shear_z = .false.

heating = .false.

mdot = .false.

utau_wf = .false.

phi_wf = .false.

mu_t_wf = .false.

k_wallfunction_bc = .false.

omega_wallfunction_bc = .false.

/

number of boundaries = 0

Number of boundary patches given in boundary list (if -1 is given, this

number is computed from boundary list)

boundary list = ’’

List of boundary patch numbers. Commas and dashes can be used to

specify ranges, i.e., ’1,2,5-7’. If nothing is specified, then all but flowthrough boundaries are output for 3D or a single symmetry plane in

2D.

x = .true.

X-coordinate

y = .true.

Y -coordinate

z = .true.

Z-coordinate

primitive variables = .true.

Output primitive variables: rho, u, v, w, and p

rho = .false.

Density

u = .false.

X-component of velocity

v = .false.

Y -component of velocity

173
w = .false.

Z-component of velocity

p = .false.

Pressure

entropy = .false.

Entropy

mach = .false.

Mach number

temperature = .false.

Temperature

iblank = .false.

I-blanking variable (default becomes .true. for overset mesh cases)

imesh = .false.

For overset mesh systems, index of associated component grid where 0

indicates background grid

vort mag = .false.

Vorticity magnitude

vort x = .false.

X-component of vorticity

vort y = .false.

Y -component of vorticity

vort z = .false.

Z-component of vorticity

q criterion = .false.

Q Criterion, the second invariant of ∇V

div vel = .false.

Velocity divergence

turbulent fluctuations = .false.

Activate all the following XYprime turbulent shear stresses normalized by

u

2

ref ; the definition of these variables depends on the turbulence model,

see http://turbmodels.larc.nasa.gov/noteonrunning.html for details

174
uuprime = .false.

Turbulence fluctuation, u

0u0

vvprime = .false.

Turbulence fluctuation, v

0

v

0

wwprime = .false.

Turbulence fluctuation, w

0w0

uvprime = .false.

Turbulence fluctuation, u

0

v

0

uwprime = .false.

Turbulence fluctuation, u

0w0

vwprime = .false.

Turbulence fluctuation, v

0w0

cp = .false.

Pressure coefficient

dp pinf = .false.

Normalized delta pressure (p − p∞)/p∞

volume = .false.

Dual-cell volume size

residuals = .false.

Activate all resN variables.

res1 = .false.

Residual of equation 1, density

res2 = .false.

Residual of equation 2, x-momentum

res3 = .false.

Residual of equation 3, y-momentum

res4 = .false.

Residual of equation 4, z-momentum

res5 = .false.

Residual of equation 5, energy

175
res gcl = .false.

For moving meshes, residual of grid conservation law

primitive tavg = .false.

Output time-averaged primitives (requires &time avg params namelist):

rho tavg, u tavg, v tavg, w tavg, and p tavg

rho tavg = .false.

Time-averaged density

u tavg = .false.

Time-averaged x-component of velocity

v tavg = .false.

Time-averaged y-component of velocity

w tavg = .false.

Time-averaged z-component of velocity

p tavg = .false.

Time-averaged pressure

primitive trms = .false.

Output root mean squared primitives (requires &time avg params namelist):

rho trms, u trms, v trms, w trms, and p trms

rho trms = .false.

RMS-average of density

u trms = .false.

RMS-average of x-component of velocity

v trms = .false.

RMS-average of y-component of velocity

w trms = .false.

RMS-average of z-component of velocity

p trms = .false.

RMS-average of pressure

lambda1 = .false.

Adjoint Lagrange multiplier for equation 1 (when running the adjoint,

the primitive variables are turned off, and this is turned on)

176
lambda2 = .false.

Adjoint Lagrange multiplier for equation 2 (when running the adjoint,

the primitive variables are turned off, and this is turned on)

lambda3 = .false.

Adjoint Lagrange multiplier for equation 3 (when running the adjoint,

the primitive variables are turned off, and this is turned on)

lambda4 = .false.

Adjoint Lagrange multiplier for equation 4 (when running the adjoint,

the primitive variables are turned off, and this is turned on)

lambda5 = .false.

Adjoint Lagrange multiplier for equation 5 (when running the adjoint,

the primitive variables are turned off, and this is turned on)

lambda6 = .false.

Adjoint Lagrange multiplier for equation 6 (when running the adjoint,

the primitive variables are turned off, and this is turned on)

lambda7 = .false.

Adjoint Lagrange multiplier for equation 7 (when running the adjoint,

the primitive variables are turned off, and this is turned on)

htot = .false.

Total enthalpy per unit volume

ttot = .false.

Total temperature

ptot = .false.

Total pressure

etot = .false.

Total energy per unit volume

processor id = .false.

Processor on which a node resides

turb ke = .false.

Turbulence kinetic energy

turb diss = .false.

Turbulence dissipation rate

177
mu t = .false.

Turbulent eddy viscosity

turb1 = .false.

Turbulence variable 1 (model dependent)

turb2 = .false.

Turbulence variable 2 (model dependent)

turb3 = .false.

Turbulence variable 3 (model dependent)

turb4 = .false.

Turbulence variable 4 (model dependent)

turb5 = .false.

Turbulence variable 5 (model dependent)

turb6 = .false.

Turbulence variable 6 (model dependent)

turb7 = .false.

Turbulence variable 7 (model dependent)

turres1 = .false.

Residual of 1st turbulence equation

turres2 = .false.

Residual of 2nd turbulence equation

turres3 = .false.

Residual of 3rd turbulence equation

turres4 = .false.

Residual of 4th turbulence equation

turres5 = .false.

Residual of 5th turbulence equation

turres6 = .false.

Residual of 6th turbulence equation

turres7 = .false.

Residual of 7th turbulence equation

178
slen = .false.

Length to the nearest solid wall boundary

tt = .false.

Translational temperature, only for eqn type = ’generic’

tv = .false.

Vibrational temperature, only for eqn type = ’generic’

sonic = .false.

Frozen speed of sound, only for eqn type = ’generic’

mixture mol weight = .false.

Mixture molecular weight, only for eqn type = ’generic’

mixture density = .false.

Mixture density, only for eqn type = ’generic’

ev = .false.

Vibrational energy, only for eqn type = ’generic’

rho i(1:n species) = .false.

Species concentration, only for eqn type = ’generic’

mu = .false.

Total viscosity

id l2g = .false.

Local-to-global node map

vort x rms = .false.

RMS-average of x-component of vorticity

vort y rms = .false.

RMS-average of y-component of vorticity

vort z rms = .false.

RMS-average of z-component of vorticity

vort mag rms = .false.

RMS-average of vorticity magnitude

vort mag tavg = .false.

Time-average of vorticity magnitude

179
yplus = .false.

Dimensionless wall distance, y

+

mu t tavg = .false.

Time-average turbulent eddy viscosity

cmu star = .false.

k −  model turbulent length scale parameter

bird breakdown = .false.

Bird continuum breakdown parameter

recovery temperature = .false.

Recovery temperature

turb mach = .false.

Turbulent Mach number

turbindex = .false.

Turbulent index

average velocity = .false.

Turns on uavg, vavg, wavg

uavg = .false.

X-component of average velocity near a wall (used to plot surface streamlines)

vavg = .false.

Y -component of average velocity near a wall (used to plot surface streamlines)

wavg = .false.

Z-component of average velocity near a wall (used to plot surface streamlines)

cf x = .false.

X-component of skin friction

cf y = .false.

Y -component of skin friction

cf z = .false.

Z-component of skin friction

180
skinfr = .false.

Skin friction magnitude with sign determined by the inner product of

the skin friction vector and the freestream velocity vector

cq = .false.

Temperature gradient normal to the wall, with “dimensions” of nondimensional temperature per unit grid length for eqn type = ‘compressible’.

Heating rate non-dimensionalized by ρ∞V

3

∞ for eqn type = ‘generic’.

shear x = .false.

X-component of shear on the boundary, in MKS units

shear y = .false.

Y -component of shear on the boundary, in MKS units

shear z = .false.

Z-component of shear on the boundary, in MKS units

heating = .false.

Heating on the boundary in Watts per centimeter squared (for eqn type

= ‘compressible’, make sure the grid is in meters)

mdot = .false.

Dimensionless blowing rate non-dimensionalized by ρ∞V∞

utau wf = .false.

Friction velocity calculated from a wall function model.

phi wf = .false.

Pressure gradient term from a wall function model.

mu t wf = .false.

Wall function turbulent eddy viscosity at the wall.

k wallfunction bc = .false.

Turbulent kinetic energy wall function boundary condition.

omega wallfunction bc = .false.

Omega wall function boundary condition.

181
B.4.25 &sampling output variables

This namelist controls output of variables from user defined regions of the

computational domain. To use sampling, the &sampling parameters namelist

must be used to define the sampling geometries and the sampling frequency(:

) set for each geometry.

The resulting sampling data files will have the following naming convention:

[project_rootname]_tec_sampling_geom[G]_timestep[T](.dat|.plt) if N > 0

[project_rootname]_tec_sampling_geom[G](.dat|.plt) if N < 0

where G = 1,2,. . . ,number of geometries, and T is the iteration number. The

file extension is .dat for ASCII Tecplot format and .plt for binary Tecplot

format. A global image of the sampling surface is output with the zone title

“time 0.0000000E+00 geom 3” where the time value is the integer iteration

number for steady-state cases, and the current (nondimensional) time for timedependent cases.

A request to output an undefined variable will overruled, i.e., turb1 will

be forced to .false regardless of user input when there is no turbulence model

in the simulation.

&sampling_output_variables

x = .true.

y = .true.

z = .true.

primitive_variables = .true.

rho = .false.

rho_i(:) = .false.

u = .false.

v = .false.

w = .false.

p = .false.

entropy = .false.

mach = .false.

temperature = .false.

tt = .false.

tv = .false.

iblank = .false.

imesh = .false.

vort_mag = .false.

vort_x = .false.

vort_y = .false.

vort_z = .false.

q_criterion = .false.

div_vel = .false.

turbulent_fluctuations = .false.

182
uuprime = .false.

vvprime = .false.

wwprime = .false.

uvprime = .false.

uwprime = .false.

vwprime = .false.

cp = .false.

dp_pinf = .false.

volume = .false.

residuals = .false.

res1 = .false.

res2 = .false.

res3 = .false.

res4 = .false.

res5 = .false.

res_gcl = .false.

rho_tavg = .false.

primitive_tavg = .false.

u_tavg = .false.

v_tavg = .false.

w_tavg = .false.

p_tavg = .false.

mu_t_tavg = .false.

vort_mag_tavg = .false.

vort_x_tavg = .false.

vort_y_tavg = .false.

vort_z_tavg = .false.

primitive_trms = .false.

rho_trms = .false.

u_trms = .false.

v_trms = .false.

w_trms = .false.

p_trms = .false.

lambda1 = .false.

lambda2 = .false.

lambda3 = .false.

lambda4 = .false.

lambda5 = .false.

lambda6 = .false.

lambda7 = .false.

htot = .false.

ttot = .false.

ptot = .false.

etot = .false.

processor_id = .false.

183
turb_ke = .false.

turb_diss = .false.

mu_t_wf = .false.

mu_t = .false.

turb1 = .false.

turb2 = .false.

turb3 = .false.

turb4 = .false.

turb5 = .false.

turb6 = .false.

turb7 = .false.

turres1 = .false.

turres2 = .false.

turres3 = .false.

turres4 = .false.

turres5 = .false.

turres6 = .false.

turres7 = .false.

slen = .false.

iflagslen = .false.

hrles_blend = .false.

vort_x_rms = .false.

vort_y_rms = .false.

vort_z_rms = .false.

vort_mag_rms = .false.

yplus = .false.

cmu_star = .false.

mu_t_ratio = .false.

iib = .false.

iiib = .false.

uplus = .false.

kplus = .false.

wplus = .false.

yplusretau = .false.

t11plus = .false.

t12plus = .false.

t13plus = .false.

t22plus = .false.

t23plus = .false.

t33plus = .false.

bird_breakdown = .false.

vgradrho = .false.

f_r1 = .false.

xi_k = .false.

reconstruction_limiter_phi1 = .false.

184
reconstruction_limiter_phi2 = .false.

reconstruction_limiter_phi3 = .false.

reconstruction_limiter_phi4 = .false.

reconstruction_limiter_phi5 = .false.

/

x = .true.

X-coordinate

y = .true.

Y -coordinate

z = .true.

Z-coordinate

primitive variables = .true.

Output primitive variables: rho, u, v, w, and p

rho = .false.

Density

rho i(:) = .false.

Species densities

u = .false.

X-component of velocity

v = .false.

Y -component of velocity

w = .false.

Z-component of velocity

p = .false.

Pressure

entropy = .false.

Entropy

mach = .false.

Mach number

temperature = .false.

Temperature

185
tt = .false.

Translational-rotational temperature in the generic gas path

tv = .false.

Vibrational-electronic temperature in the generic gas path

iblank = .false.

I-blanking variable (default becomes .true. for overset mesh cases)

imesh = .false.

For overset mesh systems, index of associated component grid where 0

indicates background grid

vort mag = .false.

Vorticity magnitude

vort x = .false.

X-component of vorticity

vort y = .false.

Y -component of vorticity

vort z = .false.

Z-component of vorticity

q criterion = .false.

Q Criterion, the second invariant of ∇V

div vel = .false.

Velocity divergence

turbulent fluctuations = .false.

Activate all the following XYprime turbulent shear stresses normalized by

u

2

ref ; the definition of these variables depends on the turbulence model,

see http://turbmodels.larc.nasa.gov/noteonrunning.html for details

uuprime = .false.

Turbulence fluctuation, u

0u0

vvprime = .false.

Turbulence fluctuation, v

0

v

0

wwprime = .false.

Turbulence fluctuation, w

0w0

186
uvprime = .false.

Turbulence fluctuation, u

0

v

0

uwprime = .false.

Turbulence fluctuation, u

0w0

vwprime = .false.

Turbulence fluctuation, v

0w0

cp = .false.

Pressure coefficient

dp pinf = .false.

Normalized delta pressure (p − p∞)/p∞

volume = .false.

Dual-cell volume size

residuals = .false.

Activate all resN variables

res1 = .false.

Residual of equation 1, density

res2 = .false.

Residual of equation 2, x-momentum

res3 = .false.

Residual of equation 3, y-momentum

res4 = .false.

Residual of equation 4, z-momentum

res5 = .false.

Residual of equation 5, energy

res gcl = .false.

For moving meshes, residual of grid conservation law

rho tavg = .false.

Time-averaged density

primitive tavg = .false.

Output time-averaged primitives (requires &time avg params namelist):

rho tavg, u tavg, v tavg, w tavg, and p tavg

187
u tavg = .false.

Time-averaged x-component of velocity

v tavg = .false.

Time-averaged y-component of velocity

w tavg = .false.

Time-averaged z-component of velocity

p tavg = .false.

Time-averaged pressure

mu t tavg = .false.

Time-averaged turbulent eddy viscosity

vort mag tavg = .false.

Time-averaged vorticity magnitude

vort x tavg = .false.

Time-averaged x-component vorticity

vort y tavg = .false.

Time-averaged y-component vorticity

vort z tavg = .false.

Time-averaged z-component vorticity

primitive trms = .false.

Output root mean squared primitives (requires &time avg params namelist):

rho trms, u trms, v trms, w trms, and p trms

rho trms = .false.

RMS-average of density

u trms = .false.

RMS-average of x-component of velocity

v trms = .false.

RMS-average of y-component of velocity

w trms = .false.

RMS-average of z-component of velocity

p trms = .false.

RMS-average of pressure

188
lambda1 = .false.

Adjoint Lagrange multiplier for equation 1 (when running the adjoint,

the primitive variables are turned off, and this is turned on)

lambda2 = .false.

Adjoint Lagrange multiplier for equation 2 (when running the adjoint,

the primitive variables are turned off, and this is turned on)

lambda3 = .false.

Adjoint Lagrange multiplier for equation 3 (when running the adjoint,

the primitive variables are turned off, and this is turned on)

lambda4 = .false.

Adjoint Lagrange multiplier for equation 4 (when running the adjoint,

the primitive variables are turned off, and this is turned on)

lambda5 = .false.

Adjoint Lagrange multiplier for equation 5 (when running the adjoint,

the primitive variables are turned off, and this is turned on)

lambda6 = .false.

Adjoint Lagrange multiplier for equation 6 (when running the adjoint,

the primitive variables are turned off, and this is turned on)

lambda7 = .false.

Adjoint Lagrange multiplier for equation 7 (when running the adjoint,

the primitive variables are turned off, and this is turned on)

htot = .false.

Total enthalpy per unit volume

ttot = .false.

Total temperature

ptot = .false.

Total pressure

etot = .false.

Total energy per unit volume

processor id = .false.

Processor on which a node resides

turb ke = .false.

Turbulence kinetic energy

189
turb diss = .false.

Turbulence dissipation rate

mu t wf = .false.

Turbulent eddy viscosity at the wall from a wall function model.

mu t = .false.

Turbulent eddy viscosity

turb1 = .false.

Turbulence variable 1 (model dependent)

turb2 = .false.

Turbulence variable 2 (model dependent)

turb3 = .false.

Turbulence variable 3 (model dependent)

turb4 = .false.

Turbulence variable 4 (model dependent)

turb5 = .false.

Turbulence variable 5 (model dependent)

turb6 = .false.

Turbulence variable 6 (model dependent)

turb7 = .false.

Turbulence variable 7 (model dependent)

turres1 = .false.

Residual of 1st turbulence equation

turres2 = .false.

Residual of 2nd turbulence equation

turres3 = .false.

Residual of 3rd turbulence equation

turres4 = .false.

Residual of 4th turbulence equation

turres5 = .false.

Residual of 5th turbulence equation

190
turres6 = .false.

Residual of 6th turbulence equation

turres7 = .false.

Residual of 7th turbulence equation

slen = .false.

Length to the nearest solid wall boundary

iflagslen = .false.

Turbulence model distance function closest boundary entity. (a negative

sign indicates the node has been prescribed as laminar)

hrles blend = .false.

HRLES blending function

vort x rms = .false.

RMS-average of x-component of vorticity

vort y rms = .false.

RMS-average of y-component of vorticity

vort z rms = .false.

RMS-average of z-component of vorticity

vort mag rms = .false.

RMS-average of vorticity magnitude

yplus = .false.

Dimensionless wall distance, y

+

cmu star = .false.

k −  model turbulent length scale parameter

mu t ratio = .false.

Ratio of turbulent eddy viscosity to laminar (bulk) viscosity

iib = .false.

−trace(Bij ∗ Bij )/2

iiib = .false.

trace(Bij ∗ Bij ∗ Bij )/3

uplus = .false.

Dimensionless velocity, u

+

191
kplus = .false.

k

u2

τ

wplus = .false.

ων

u2

τ

yplusretau = .false.

u

+

reτ

t11plus = .false.

τ

+

11

t12plus = .false.

τ

+

12

t13plus = .false.

τ

+

13

t22plus = .false.

τ

+

22

t23plus = .false.

τ

+

23

t33plus = .false.

τ

+

33

bird breakdown = .false.

Bird continuum breakdown parameter

vgradrho = .false.

[u, v, w] · ∇ρ

f r1 = .false.

Curvature correction model function

xi k = .false.

Cross-diffusion term for Wilcox k-ω 1998

reconstruction limiter phi1 = .false.

φ for the node-based reconstruction limiters (equation 1)

reconstruction limiter phi2 = .false.

φ for the node-based reconstruction limiters (equation 2)

192
reconstruction limiter phi3 = .false.

φ for the node-based reconstruction limiters (equation 3)

reconstruction limiter phi4 = .false.

φ for the node-based reconstruction limiters (equation 4)

reconstruction limiter phi5 = .false.

φ for the node-based reconstruction limiters (equation 5)

193
B.4.26 &sampling parameters

This namelist specifies the types and frequency of sampling data to be exported for visualization. The output variables themselves are specified in the

&sampling output variables namelist. The last dimension of each array

references the geometry index, which is one to number of geometries.

&sampling_parameters

number_of_geometries = 0

sampling_frequency(:) = 0

label(:) = ''

type_of_geometry(:) = 'none'

crinkle = .false.

nodal = .false.

plot(:) = 'tecplot'

patch_list_count(:) = 0

patch_list(:) = ''

type_of_data(:) = 'volume'

move_with_body(:) = ''

boundary_list = ''

default_boundary = .true.

plane_center(1:3,:) = 0.0

plane_normal(1:3,:) = 0.0

box_lower_corner(1:3,:) = 0.0

box_upper_corner(1:3,:) = 0.0

sphere_center(1:3,:) = 0.0

sphere_radius(:) = 0.0

circle_center(1:3,:) = 0.0

circle_normal(1:3,:) = 0.0

circle_radius(:) = 0.0

cylinder_face1(1:3,:) = 0.0

cylinder_face2(1:3,:) = 0.0

cylinder_radius(:) = 0.0

cone_face1(1:3,:) = 0.0

cone_face2(1:3,:) = 0.0

cone_radius1(:) = 0.0

cone_radius2(:) = 0.0

corner1(1:3,:) = 0.0

corner2(1:3,:) = 0.0

corner3(1:3,:) = 0.0

corner4(1:3,:) = 0.0

number_of_points(:) = 0

points(1:3,:,:) = 0.0

number_of_lines = 0

p1_line(1:3,:) = 0.0

p2_line(1:3,:) = 0.0

194
schlieren_aspect = ''

window_height(:) = 0.0

window_width(:) = 0.0

window_center(1:3,:) = 0.0

number_of_rows(:) = 0

number_of_columns(:) = 0

model_center(1:3,:) = 0.0

plot_lines(:) = .false.

make_shadow = .false.

blanking_list_count(:) = 0

blanking_list(:) = ''

isosurf_variable(:) = 'p'

isosurf_value(:) = 0.0

isosurf_box(:) = .false.

x_range_lower(:) = -1.0

x_range_upper(:) = 1.0

y_range_lower(:) = -1.0

y_range_upper(:) = 1.0

z_range_lower(:) = -1.0

z_range_upper(:) = 1.0

isosurf_dist_threshold(:) = 0.0

variable_list(:) = ''

snap_output_xyz = .true.

dist_tolerance = 1.0e-3

fwh_formatted = .false.

append_history(:) = .false.

asynchronous_fwh = .false.

reference_length = 0.0

/

number of geometries = 0

This is the total number of sampling geometries.

sampling frequency(:) = 0

This specifies the iteration interval at which sampling is performed. The

special value of -1 means to only perform sampling at the end of a

successful run.

label(:) = ’’

This customizes the filename of sampling output. When it is blank, the

file will be [project rootname] tec sampling geomN.(dat,plt) where

N is the sampling geometry number, .dat is ASCII format, and .plt is

binary format.

type of geometry(:) = ’none’

This is the type of sampling geometry,

195
‘streamsurface’ is a stream surface, requires number of points and

points.

‘boundary points’ for boundary point sampling, requires number of points

and points, modified by snap output xyz and dist tolerance.

‘volume points’ for point sampling in the domain, requires number of points

and points.

‘schlieren’ is a schlieren image via an integral of the refractive index

field, requires number of rows, number of columns, window height, window width,

window center, and schlieren aspect. It is controlled by make shadow

and plot lines.

‘isosurface’ is an isosurface that requires isosurf variable and isosurf value.

It is controlled by * range lower and * range upper.

‘box’ samples a the surface of a box. It requires box lower corner and

box upper corner.

‘sphere’ samples a spherical surface. It requires sphere center and

sphere radius.

‘cylinder’ samples a cylindrical surface. It requires cylinder face1,

cylinder face2, and cylinder radius.

‘cone’ samples a conic surface. It requires cone face1, cone face2,

cone radius1, and cone radius2.

‘plane’ samples a plane. It requires plane center and plane normal.

‘quad’ samples a quadrilateral. It requires corner1, corner2, corner3,

corner4, and window normal.

‘circle’ samples a circle. It requires circle center, circle normal,

and circle radius.

‘line’ is line sampling, which requires number of lines, p1 line, and

p2 line.

crinkle = .false.

This snaps the sampling surface to nearest grid faces instead of using

linear interpolation.

nodal = .false.

This uses the nearest nodal values instead of interpolating.

plot(:) = ’tecplot’

This is the format of sampling output,

‘tecplot’ Tecplot format.

196
‘fwh’ format for Ffowcs Williams-Hawkings analysis.

‘serial history’ custom low-overhead point sampling format where

all locations listed once at the top and then just the requested values

per sampling frequency.

patch list count(:) = 0

This is the number of patches in patch list.

patch list(:) = ’’

A string list of patch face IDs to limit boundary survey to a subset of

the boundary faces. Commas and dashes can be used to specify ranges,

i.e., ’1,2,5-7’.

type of data(:) = ’volume’

The source of data for extracting the requested sampling variables for

each type of geometry.

‘volume’ extract data from the computational volume.

‘boundary’ extract data from a boundary.

move with body(:) = ’’

Move the sampling geometry with the body if body is in motion. Use

the fixed inertial reference frame when blank.

boundary list = ’’

List of patches to include when sampling boundaries; Commas and

dashes can be used to specify ranges, i.e., ’1,2,5-7’.

default boundary = .true.

Use FUN3D default solid-wall-only boundary patches when sampling

boundary points, i.e., ignore symmetry, slip, and flow-through boundaries.

plane center(1:3,:) = 0.0

This is a point on a requested sampling ’plane’; it fixes the location.

plane normal(1:3,:) = 0.0

This is a normal vector of sampling ’plane’; it fixes the orientation.

box lower corner(1:3,:) = 0.0

This is the coordinate of the lower corner of a ’box’.

box upper corner(1:3,:) = 0.0

This is the coordinate of the upper corner of a ’box’.

197
sphere center(1:3,:) = 0.0

This is the coordinate of ’sphere’ center; it fixes the location.

sphere radius(:) = 0.0

This is the radius for ’sphere’; it fixes the size.

circle center(1:3,:) = 0.0

This is the coordinate of center of a ’circle’; it fixes the location.

circle normal(1:3,:) = 0.0

This is the normal vector for a ’circle’; it fixes the orientation.

circle radius(:) = 0.0

This is the radius for a ’circle’; it fixes the size.

cylinder face1(1:3,:) = 0.0

This is the coordinate for the center of the first face of a ’cylinder’.

cylinder face2(1:3,:) = 0.0

This is the coordinate for center of the second face of a ’cylinder’.

cylinder radius(:) = 0.0

This is the radius of a ’cylinder’.

cone face1(1:3,:) = 0.0

This is the coordinate for center of the first face of a ’cylinder’.

cone face2(1:3,:) = 0.0

This is the coordinate for center of the second face of a ’cylinder’.

cone radius1(:) = 0.0

This is the radius of the first face of a ’cone’.

cone radius2(:) = 0.0

This is the radius of the second face of a ’cone’.

corner1(1:3,:) = 0.0

This is the coordinate of the first corner of a ’quad’; the corners proceed

clockwise.

corner2(1:3,:) = 0.0

The coordinate of the second corner of a ’quad’.

198
corner3(1:3,:) = 0.0

The coordinate of the third corner of a ’quad’.

corner4(1:3,:) = 0.0

The coordinate of the fourth corner of a ’quad’.

number of points(:) = 0

This is the number of points to be sampled by ’boundary point’ or

’volume point’.

points(1:3,:,:) = 0.0

These are the coordinates of boundary point and volume point sampling. The first index is the Cartesian direction, the second index is the

geometry, and the last index is the point in this geometry.

number of lines = 0

This is the number of lines in ’line’ sampling.

p1 line(1:3,:) = 0.0

This is the first end point of a line in line sampling.

p2 line(1:3,:) = 0.0

This is the second end point of a line in line sampling.

schlieren aspect = ’’

This is the Cartesian direction for ’schlieren’ view,

‘y’ Schlieren viewing along y axis.

‘z’ Schlieren viewing along z axis.

‘y1’ Schlieren viewing along y axis.

‘z1’ Schlieren viewing along z axis.

‘’ Schlieren viewing along window normal.

window height(:) = 0.0

This is the window height for ’schlieren’.

window width(:) = 0.0

This is the window width for ’schlieren’.

window center(1:3,:) = 0.0

This is the window center for ’schlieren’.

199
number of rows(:) = 0

This is the vertical number of pixels in the ’schlieren’ window.

number of columns(:) = 0

This is the horizontal number of pixels in the ’schlieren’ window.

model center(1:3,:) = 0.0

This is the model center for ’schlieren’.

plot lines(:) = .false.

This plots lines for ’schlieren’.

make shadow = .false.

The boundary will cast a shadow in schlieren output.

blanking list count(:) = 0

This is the number of boundaries to search for ’schlieren’ boundary

shadow.

blanking list(:) = ’’

This is a list of boundaries to search for ’schlieren’ shadow. Commas

and dashes can be used to specify ranges, i.e., ’1,2,5-7’.

isosurf variable(:) = ’p’

This is the variable used to define the geometry of an ’isosurface’ and

isocrinkle.

‘p’ Pressure.

‘rho’ Density.

‘u’ X-component of velocity.

‘v’ Y -component of velocity.

‘w’ Z-component of velocity.

‘vort x’ X-component of vorticity.

‘vort y’ Y -component of vorticity.

‘vort z’ Z-component of vorticity.

‘vort mag’ Total magnitude of vorticity vector.

‘vort mag avg’ Average total magnitude of vorticity vector.

‘vort mag rms’ RMS total magnitude of vorticity vector.

‘q criterion’ Q-criterion.

‘mach’ Mach number.

200
‘temperature’ Temperature.

‘p tavg’ Time average pressure.

‘rho tavg’ Time average density.

‘u tavg’ Time average x-component of velocity.

‘v tavg’ Time average y-component of velocity.

‘w tavg’ Time average z-component of velocity.

‘p trms’ RMS of pressure.

‘rho trms’ RMS of density.

‘u trms’ RMS of the x-component of velocity.

‘v trms’ RMS of the y-component of velocity.

‘w trms’ RMS of the z-component of velocity.

‘critical d’ critical d

‘s1a’ other option

‘s1b’ other option

‘s1’ other option

‘s2’ other option

‘lambda1’ Adjoint variable for the 1st governing equation.

‘lambda2’ Adjoint variable for the 2nd governing equation.

‘lambda3’ Adjoint variable for the 3rd governing equation.

‘lambda4’ Adjoint variable for the 4th governing equation.

‘lambda5’ Adjoint variable for the 5th governing equation.

‘lambda6’ Adjoint variable for the 6th governing equation.

‘lambda7’ Adjoint variable for the 7th governing equation.

‘processor id’ The assigned processor ID.

‘bird breakdown’ Bird breakdown factor.

isosurf value(:) = 0.0

This is the value of isosurf variable(:) to create the ’isosurface’

and isocrinkle geometry.

isosurf box(:) = .false.

This clips the sampling geometry to be inside a box sized by * range *

within isosurf dist threshold.

x range lower(:) = -1.0

This limits isosurface or isocrinkle when isosurf box(:) = .true.

201
x range upper(:) = 1.0

This limits isosurface or isocrinkle when isosurf box(:) = .true.

y range lower(:) = -1.0

This limits isosurface or isocrinkle when isosurf box(:) = .true.

y range upper(:) = 1.0

This limits isosurface or isocrinkle when isosurf box(:) = .true.

z range lower(:) = -1.0

This limits isosurface or isocrinkle when isosurf box(:) = .true.

z range upper(:) = 1.0

This limits isosurface or isocrinkle when isosurf box(:) = .true.

isosurf dist threshold(:) = 0.0

This trims portions of an isosurface or isocrinkle that have a distance to the surface less then this threshold. It requires isosurf box(:

) = .true.

variable list(:) = ’’

These variables augment &sampling output variables for this sampling object.

snap output xyz = .true.

This snaps the requested points to the nearest surface.

dist tolerance = 1.0e-3

This is the tolerance used when snap output xyz is engaged.

fwh formatted = .false.

Write Ffowcs Williams-Hawkings in Fortran unformatted format. The

default is Fortran stream (C-binary).

append history(:) = .false.

This option removes the step number from the filename and opens it

with append.

asynchronous fwh = .false.

This uses asynchronous I/O for permeable FWH output.

reference length = 0.0

This is the reference length for Reτ used in &sampling output variables.

202
B.4.27 &slice data

This namelist specifies boundary slices for visualization and to obtain loads.

Output frequency is controlled by slice freq in the &global namelist, where

zero for no output, -1 for output at the end of run, and a positive integer for

periodic output.

This is a limited ability to take slices through boundary surfaces. For

example, spanwise cuts along a wing may be extracted, and then the resulting

pressure and skin friction data may be plotted at each station. Slices can

only be extracted in Cartesian planes (e.g., constant y). For moving-body

cases, the slices may be taken at constant coordinate positions in the body-fixed

coordinate system, in which case the slices will not generally be in Cartesian

planes in inertial space.

The sliced data is written to an ASCII formatted Tecplot file with the

naming convention:

[project_rootname]_slice.dat

The variables output to this file are: x, y, z, cp, cfx, cfy, and cfz at each

output time step. The slicing output variables are not customizable by the

user.

Slicing occurs in the inertial frame, unless an alternate reference frame is

specified. For stationary geometries, the inertial frame is the only option. For

moving body cases, either the frame of one of the moving bodies or an observer

frame may specified.

When slicing boundary surfaces, a file called slice.info is output that

echos much of the input data. When the slicing is successful, the file will also

contain information about the number of points in the slice.

Below, namelist variables are defined. See section B.4.27 for some important considerations when using this capability.

&slice_data

nslices = 1

replicate_all_bodies = .false.

slice_x(:) = .false.

slice_y(:) = .true.

slice_z(:) = .false.

slice_location(:) = 0.0

slice_increment = 0.0

xx_box_max(:) = huge(1.0)

yy_box_max(:) = huge(1.0)

zz_box_max(:) = huge(1.0)

xx_box_min(:) = -huge(1.0)

yy_box_min(:) = -huge(1.0)

zz_box_min(:) = -huge(1.0)

203
slice_xmc(:) = huge(1.0)

slice_ymc(:) = huge(1.0)

slice_zmc(:) = huge(1.0)

n_bndrys_to_slice(:) = 0

bndrys_to_slice(:,:) = 0

slice_frame(:) = ''

slice_group(:) = 1

chord_dir(:) = 1

te_def(:) = 1

le_def(:) = 30

corner_angle(:) = 120.0

use_local_chord = .true.

tecplot_slice_output = .true.

output_sectional_forces = .true.

slice_initial_coords = .false.

custom_transform(1,1,1:4) = 1.0, 0.0, 0.0, 0.0

custom_transform(1,2,1:4) = 0.0, 1.0, 0.0, 0.0

custom_transform(1,3,1:4) = 0.0, 0.0, 1.0, 0.0

custom_transform(1,4,1:4) = 0.0, 0.0, 0.0, 1.0

output_in_slice_coords(:) = .false.

/

nslices = 1

This is the number of slices to create. If negative, then data for only

one slice station need be input, along with slice increment, and all the

data specified for the first station will be applied to subsequent stations,

with the exception of the slice location, which will be set using the slice

increment between stations.

replicate all bodies = .false.

This will set similar slice stations on multiple bodies with minimal input

beyond that required for slicing the first body. This is particularly useful

for rotorcraft applications where multiple blades are to be sliced. This

variable duplicates the input slice info for all moving bodies, with the

exception of the slice frame and the bndrys to slice.

slice x(:) = .false.

This extracts the slice at x = slice location in the specified reference

frame.

slice y(:) = .true.

This extracts the slice at y = slice location in the specified reference

frame.

204
slice z(:) = .false.

This extracts the slice at z = slice location in the specified reference

frame.

slice location(:) = 0.0

This is the coordinate value at which slice is taken.

slice increment = 0.0

When nslices is negative, this is the increment in slice coordinate between consecutive slice stations.

xx box max(:) = huge(1.0)

This is the maximum x-coordinate used to define a bounding box to

constrain the slicing to filter unwanted intersections.

yy box max(:) = huge(1.0)

This is the maximum y-coordinate used to define a bounding box to

constrain the slicing to filter unwanted intersections.

zz box max(:) = huge(1.0)

This is the maximum z-coordinate used to define a bounding box to

constrain the slicing to filter unwanted intersections.

xx box min(:) = -huge(1.0)

This is the minimum x-coordinate used to define a bounding box to

constrain the slicing to filter unwanted intersections.

yy box min(:) = -huge(1.0)

This is the minimum y-coordinate used to define a bounding box to

constrain the slicing to filter unwanted intersections.

zz box min(:) = -huge(1.0)

This is the minimum z-coordinate used to define a bounding box to

constrain the slicing to filter unwanted intersections.

slice xmc(:) = huge(1.0)

This is the x-coordinate of the moment center, in the specified reference

frame, for aerodynamic moments acting on the slice. The default value

”huge” will result in the moment center being taken as the computed

quarter chord of the slice.

slice ymc(:) = huge(1.0)

This is the y-coordinate of the moment center, in the specified reference

frame, for aerodynamic moments acting on the slice. The default value

205
”huge” will result in the moment center being taken as the computed

quarter chord of the slice.

slice zmc(:) = huge(1.0)

This is the z-coordinate of the moment center, in the specified reference

frame, for aerodynamic moments acting on the slice. The default value

”huge” will result in the moment center being taken as the computed

quarter chord of the slice.

n bndrys to slice(:) = 0

This is the number of candidate boundaries to search while computing

slice-plane intersections. The index is the slice. By default, all solid

boundaries will be searched. Specifying which boundaries are candidates

for slicing may speed up the slicing process and can be used to filter out

unwanted intersections or to slice non-solid boundaries.

bndrys to slice(:,:) = 0

This is the list of n bndrys to slice boundaries, when the variable

n bndrys to slice is greater than zero. The first index is the slice

and the second index is the boundary.

slice frame(:) = ’’

This is the name of the slice reference frame. Blank indicates the inertial frame. For moving geometries, output may be requested in either

the reference frame of a particular body, or an “observer” frame. To

specify the frame of a particular body, use the body name entered in the

&body definitions namelist. To specify the observer frame defined in

the &observer motion namelist, use ’observer’.

slice group(:) = 1

This assigns this slice to a particular group number. Within a group,

slice locations must be given in ascending order.

chord dir(:) = 1

This is the direction of local chord relative to the direction from leading

edge to trailing edge, in the slice plane. The value 1 indicates local chord

in direction from leading edge to trailing edge. The value −1 indicates

local chord in direction from trailing edge to leading edge. Determination

of the leading and trailing edges is described below.

te def(:) = 1

This is the number of points or line segments to consider when defining

the trailing edge of the slice (see Fig. B2). A value of 1 defines the

206
trailing edge as the aft-most point. This is best for sharp trailing edges.

A positive number greater than 1 initiates a search over the aft-most

te def segments for corners, after which the trailing edge is taken as

the average coordinate over all the detected corners. Two corners are

assumed to be the desired number, and warnings are output if only

one or more than two are found. The value of te def must be chosen

judiciously. It should be large enough to allow both corners to be found

but not so large as to cause excessive searching or for any non-trailing

edge corners to be found. A positive value of te def is best for and

recommended only for squared-off trailing edges. A negative number

indicates a parabolic fit of the aft-most abs(te def) points, which is

best for rounded or blunted trailing edges.

le def(:) = 30

This is the number of points to consider when defining the leading edge

of the slice (see Fig. B3). A value of 1 defines the leading edge as the

forward-most point. Use this if nothing else works or for special cases. A

positive number indicates a search over the forward-most le def points

for the one that has the maximum distance from the previously determined trailing edge. A positive number for le def is generally the best

choice provided that the trailing edge can be accurately located. A negative number indicates a parabolic fit over the forward-most abs(le def)

points.

corner angle(:) = 120.0

This is used in conjunction with a te def greater than 1. Angles between

adjacent sliced segments that are less than corner angle degrees will be

considered a corner between the two segments. For squared-off trailing

edges, two and only two corners should be detected; warnings are output

if only one or more than two are found.

use local chord = .true.

Use the computed local (sectional) chord based on the computed leading edge and trailing edge locations to normalize the sectional force

and moment data. When .false., the value of x moment length in

&force moment integ properties will be used instead of the locally

computed chord.

tecplot slice output = .true.

This outputs the sliced data to a formatted Tecplot file that is named

[project rootname] slice.dat. This file can become very large for

unsteady flows with frequently written data at many slice locations.

207
output sectional forces = .true.

This outputs detailed force and moment data for each slice to a formatted

file, [project rootname].sectional forces. This file contains force

and moment data, like that in the [project rootname].forces file, for

each and every slice. In addition, it contains geometrical data for each

slice (leading and trailing edge coordinates, moment center, etc.) This

file can become very large for unsteady flows with frequently written data

at many slice locations. The data in the file, especially the geometry

data, can be useful to assess whether the slicing is working as expected.

slice initial coords = .false.

This allows faster slicing for some cases by only computing slice interpolation coefficients once.

custom transform(1,1,1:4) = 1.0, 0.0, 0.0, 0.0

This is a user-specified transform matrix to allow slicing in a custom

coordinate system.

output in slice coords(:) = .false.

This outputs sliced data in the user-specified coordinate system. The

default outputs the data in the slice frame, which is only available if

custom transform is set.

Important Considerations for Determination of Leading And Trailing Edges Determining the locations of airfoil leading and trailing edges

is especially important for rotorcraft applications where airloads are usually

examined (and provided to a CSD code, if applicable), in an airfoil sectionaligned coordinate system. The leading and trailing edge points determine the

orientation of this section aligned coordinate system. In the section-aligned

system, the local x coordinate is aligned with the local chord, positive in the

direction from the leading edge to the trailing edge. The local span direction is

defined by the moment centers at the slice location points, positive in the

direction of increasing slice location. The local normal direction is defined

as the cross product of the local chord vector and local span vector. When

slicing boundary data, the computed forces are computed in both the selected

frame of reference (see slice frame) and in an airfoil section aligned system.

If the data in the section-aligned system is irrelevant to you, then you do not

need to worry about choosing the detection parameters carefully; the default

values should be reasonable. However, if resolution of forces and moments

into a section-aligned system is important to you, then there are a number of

things that should be considered:

1. Make sure the chord direction chord dir is correct; the default is that

going from the leading edge to the trailing edge is the same as traveling in

208
the positive “chordwise” coordinate direction. For most applications this

is the usual situation; however, the convention for rotorcraft applications

is the opposite, requiring chord dir = -1.

2. Since the best option for determining the leading edge uses the trailing

edge location (le def > 1), care should be taken to get the trailing edge

correct. For sharp trailing edges, this is very simple since the default of

te def = 1 (i.e., use the aft-most point) is the best option. However,

smoothly blunted or squared-off trailing edges are more difficult. When

the boundary surface of an unstructured mesh is sliced, the resulting

section will be comprised of line segments determined by the intersection of the specified plane and the edges of the surface triangles. These

segments and the points that make up the segments will not usually be

the same as the surface points; typically there are more segments and

points arising from intersected triangles, as illustrated in Fig. B1. This

greater point count should influence the selection of te def and le def

values. You will need enough segments (te def and le def) to ensure

that both corners are detected, but not so many that other, non trailingedge corners (if present) are detected. Another parameter that may be

of use to aid in the detection of corners is the corner angle; corners

with angles larger than corner angle between adjacent segments will

require a larger value of corner angle for detection.

The resulting section corresponding to the slice depicted in Fig. B1 is

shown in Fig. B2, where the view is zoomed in to the trailing edge

region. The aft-most 8 segments (of the approximately 30 segments in

this view) are shown in red. The computed trailing edge locations using

two different te def values are shown. The minimum te def value at

this particular station to pick up both corners would be 8, but a value of

20 was used in case another slice required more segments. If the blade

was pitched downward rather than upward, then the point chosen by

te def = 1 would be the lower corner, rather than the upper corner as

shown. Thus, when pitching up and down, te def = 1 with squared-off

trailing edges can lead to jumps in the trailing edge position as the section

transitions from pitch up to pitch down. Depending on the thickness of

the trailing edge, this can lead to jumps in the geometric pitch angle of a

few tenths of a degree. To avoid this, the option slice initial coords

= .true. will reuse the leading and trailing edges determined from the

initial grid definition, rather than the current, displaced grid location.

3. Smoothly-blunted (rounded) trailing edges should be done with either

te def = 1 (aft-most point) or via a parabolic fit of the aft-most

abs(te def) points; the latter option is probably better in general but

will require some experimentation for the particular case at hand to

209
choose the optimal number of points over which to fit the parabola.

4. The leading edge is typically easier to determine, if a good trailing edge

position has already been found. The default value of le def = 30

(search the 30 forward-most points for the one with the greatest distance from the trailing edge location) should do a decent job for most

cases.

Figure B3 shows a sliced section, zoomed in to the leading edge region.

The forward-most 20 segments (of the approximately 30 segments in this

view) are shown in red. The computed leading edge locations using two

different le def values are shown. In this case, both results are fairly

close but le def = 30 has picked out the true leading edge (as judged

from the leading edge geometry at zero pitch angle).

5. The leading edge and trailing edge detection schemes can be somewhat

sensitive to the input choices. For cases that rely on accurate resolution

of forces and moments into section-aligned coordinates (e.g., rotorcraft),

it is wise to spend some time up front to make sure that things are

Figure B1: View looking upstream from the trailing edge of a rotor blade

mesh; the light-colored region is the squared-off trailing edge; the red line

shows the location where an x=constant slice will be taken; black circles

indicate surface grid points on the trailing edge.

210
coming out as expected. To do this, inspect the [project rootname]

.sectional forces file for a particular slice station; at each station the

computed leading and trailing edge coordinates will be output. Plot

the corresponding station from the [project rootname] slice.dat, as

done above, and make sure the computed coordinates are the correct

ones. If many stations are sliced, it is impractical to inspect all of

them in this manner, but it is good practice to spot check at least a

few stations. For moving-geometry cases, try first running the case with

--body motion only. That will allow output of the [project rootname]

.sectional forces and [project rootname] slice.dat files without

the expense of a flow solve or mesh deformation; for spot checking you

may want to have the slicing done infrequently, perhaps using fewer stations than ultimately desired, as these output files can be huge.

6. While the [project rootname].sectional forces can be useful for

spot checking, the data in the file is not in a format that is amenable to

plotting. The Fun3D distribution utils/Rotorcraft directory contains a utility code that will read in both the files slice.info and

[project rootname].sectional forces to output Tecplot files, for

each slice group, containing force and moment data in the section-aligned

Figure B2: Sliced section corresponding to Fig. B1; zoomed in to the

trailing edge region.

211
coordinate system, as well as geometry data (leading edge, trailing edge,

quarter-chord coordinates, and pitch angle).

7. After making sure that the leading edge and trailing edge positions are

being computed correctly, you may want to turn off one or both of

the [project rootname].sectional forces and [project rootname]

slice.dat files unless needed. For instance, in rotorcraft applications

with coupling to external CSD codes, although the blade boundary surfaces must be sliced to generate the aerodynamic loads data for the CSD

code, this information is actually passed to the CSD code by another file;

the [project rootname].sectional forces and [project rootname]

slice.dat files are not used.

8. Although the slicing process will work for multi-element airfoils, at this

time the computation of the leading edge and trailing edge is only done

for the entire section, not each element individually.

Figure B3: A sliced section, zoomed in to the leading edge region.

212
B.4.28 &overset data

This namelist specifies information for overset grid simulations.

&overset_data

overset_flag = .false.

dci_on_the_fly = .false.

dci_period = huge(1)

reset_dci_period = .false.

dci_freq = 1

dci_dir = '.'

reuse_existing_dci = .false.

skip_dci_output = .false.

dci_io = .false.

dci_io_nproc = 1

use_imesh_constraint = .true.

suggar_nproc = 1

/

overset flag = .false.

When .true., overset mesh capability is enabled.

dci on the fly = .false.

This controls whether overset connectivity is computed as the grid moves,

or whether overset connectivity has been pre-computed for each grid

position and is available to read in. Ignored if overset flag = .false.

and &rotor data’s overset rotor = .false..

dci period = huge(1)

This controls the period (in term of timesteps) at which the dci counter

is reset. At time step dci period, the flow solver will read dci data

from the dci file for time step 1. Ignored if overset flag = .false. and

&rotor data’s overset rotor = .false..

reset dci period = .false.

When .true., allows dci period to be reset to a different value for

restarting with a different time step.

dci freq = 1

This controls how frequently the dci data is updated, either by computation within the flow solver, or by reading a new dci file. Dci data is

updated every dci freq time steps.

dci dir = ’.’

This is the directory where dci files are located. Note: A trailing forward slash (/) is automatically added and should not be included in the

directory name.

213
reuse existing dci = .false.

When .true., allows the computation of dci data to be skipped if a dci

file for the current time step already exists. This option is typically used

in conjunction with dci period, so that dci files are computed on the fly

for the first dci period time steps, and then files are reused for all subsequent periods of grid motion, without having to change dci on the fly

in between. Ignored if dci on the fly = .false..

skip dci output = .false.

When .true., the solver will not save the dci data to a file. Ignored if

dci on the fly = .false..

dci io = .false.

When .true., dci files are read from disk with a dedicated rank (processor) to help mask communication with computation.

dci io nproc = 1

When dci io = .true., this specifies the number of ranks to use for

loading of dci files.

use imesh constraint = .true.

When .true., the imesh value is taken into account when partitioning.

suggar nproc = 1

This specifies the number of ranks to use for running libSUGGAR++

Intended for future expansion; currently must be 1.

214
B.4.29 &rotor data

This namelist controls high-level rotor simulation settings. Eventually, this

namelist may subsume rotor.input.

&rotor_data

comprehensive_rotor_coupling = 'none'

overset_rotor = .false.

/

comprehensive rotor coupling = ’none’

This controls whether the code is to be coupled to a rotorcraft comprehensive code, and if so, which one.

‘none’ not coupled.

‘camrad’ coupled to CAMRAD-II.

‘rcas’ loosely coupled to RCAS.

‘rcas tight’ tightly coupled to RCAS.

‘fsi’ tightly coupled to DYMORE.

overset rotor = .false.

This controls whether overset meshes are used for moving rotor simulations. When .true., the rotor motion is governed by the rotor.input

file.

215
B.4.30 &adapt metric construction

This namelist controls how the metric is formed for metric-based mesh adaptation. More details on grid adaptation can be obtained in section 7.

&adapt_metric_construction

adapt_hessian_key = 'mach'

adapt_hessian_method = 'lsq'

adapt_max_anisotropy = 1.0e6

adapt_max_edge_growth = 2.0

adapt_max_edge_length = -1.0

adapt_min_edge_length = -1.0

adapt_output_tolerance = -0.5

adapt_complexity = -1.0

adapt_gradation = -1.0

adapt_error_estimation = 'embed'

adapt_exponent = 0.2

adapt_feature_scalar_key = 'density'

adapt_feature_scalar_form = 'delta'

adapt_feature_length_exp = 0.5

adapt_intersect_metric_in_time = .false.

adapt_metric_from_file = ''

adapt_export_metric = .false.

adapt_twod = .false.

adapt_verbose = .false.

adapt_export_feature_scalar_key = 'none'

adapt_visualize_metric = 'none'

adapt_current_h_method = 'edge'

adapt_current_h_gradation = 1.5

/

adapt hessian key = ’mach’

This variable is used to define anisotropic Hessian,

‘mach’ is Mach number.

‘pressure’ is pressure.

‘entropy’ is entropy.

‘temp’ is temperature.

‘density’ is density.

‘vorticity-magnitude’ is the magnitude of the vorticity vector.

adapt hessian method = ’lsq’

This is the mathematical method used to recover the Hessian,

216
‘lsq’ applies a least-square gradient calculation twice. First it computes

gradients via least-squares. Then the Hessian is computed by a second

application of least-squares to the reconstructed gradient.

‘green’ use a Green variational approach, see Loseille et at. [47] for

details.

‘kexact’ reconstructs the Hessian with a k-exact approach. See Barth

[48] for details.

‘grad’ is volume-averaged element-based gradients, applied twice.

‘mesh’ implies the metric of the current grid for use in testing grid

adaptation mechanics or maintaining the current anisotropy.

adapt max anisotropy = 1.0e6

This is the upper limit of the largest to smallest spacing in the metric.

adapt max edge growth = 2.0

This is the amount of coarsening that will be allowed by the scalar term

of feature-based adaptation. It is not used by adjoint-based adaptation.

adapt max edge length = -1.0

This sets a maximum allowable spacing of the metric. It is a grid and

problem dependent value and should be expressed in grid units. A negative value is unlimited.

adapt min edge length = -1.0

This sets a minimum allowable spacing of the metric. It is a grid/problem

dependent value and should be expressed in grid units. A negative value

is unlimited.

adapt output tolerance = -0.5

This is the error request for output-based adaptation and the scaling of

the scalar term for feature-based adaptation. Feature-based adaptation

requires a positive number. Output-based adaptation can be negative

to indicate a relative error reduction or positive to indicate an absolute

error request. It is difficult to choose a good value for this tolerance, see

adapt complexity for a more intuitive way to request the adapted grid

size.

adapt complexity = -1.0

This is the target complexity for the metric. It is intended to allow a

user specification of the number of nodes in the adapted grid. There is

a difference between the requested complexity and the number of nodes

in the adapted grid that is a function of grid size. This is because the

requested complexity is a continuous measure, but the metric is discrete.

217
Also, the adaptation mechanics produce a grid that is near but does not

exactly match the metric. Adjust the requested complexity manually to

obtain the desired grid size if the grid is smaller or larger than expected.

adapt gradation = -1.0

This is the allowable gradation of spacing between adjacent metric tensors. [49] A positive value activates gradation control, which should have

parameter in the range [1.1 − 2.0]. A negative value deactivates this

option. A smaller value producing a more gradual spatial variation of

the spacing request (1.0 would be no variation).

adapt error estimation = ’embed’

This selects the method used for error estimation for output-based adaptation,

‘embed’ uses a uniformly refined grid and interpolated solution to estimate the output error. [50]

‘single’ uses the current grid and reconstructed solution to estimate

the output error. Uses much less memory, but does not provide an

improved estimate of the functional. [28]

‘opt-goal’ is the optimal goal-oriented metric. [51] It requires the

namelist option adapt complexity to be set.

adapt exponent = 0.2

This is the exponent on error estimate to map local error to a change

in grid spacing. It is based on an a priori spatial error convergence

estimate. [50]

adapt feature scalar key = ’density’

This is the “key” flow variable (feature) on which to adapt for featurebased adaptation,

‘mach’ is Mach number.

‘pressure’ is pressure.

‘entropy’ is entropy.

‘temp’ is temperature.

‘density’ is density.

‘vorticity-magnitude’ is the magnitude of the vorticity vector.

adapt feature scalar form = ’delta’

This is the method to calculate feature-based refinement indicator from

the adapt feature scalar key scalar field. The following terms are

218
computed for each edge in the grid and the nodal adaptation intensity

is the maximum for all incident edges. The edge terms are,

‘delta’ is the jump in the key across the edge.

‘delta-l’ is the jump the key across the edge times the edge length to

the adapt feature length exp power.

‘average-l’ is the average key of the two nodes of an edge times the

edge length.

‘ratio’ is the ratio of the largest to the smallest key at the edge nodes.

‘max’ is the largest key at the nodes of the edge.

‘none’ will not use scalar term. It is uses the Hessian only.

adapt feature length exp = 0.5

This is the exponent for use with adapt feature scalar form = ’delta-l’.

adapt intersect metric in time = .false.

This will export a metric intersected over a window that includes each

time step of the current run. It is used for fixed-point adaptation of

time-accurate simulations. [51]

adapt metric from file = ’’

This reads the metric from this file instead of computing it when it is

blank.

adapt export metric = .false.

This exports the metric for external grid adaptation tools.

adapt twod = .false.

When .true., compute a 2D metric for a one cell wide 3D grid. This

is required when a 2D adaptation method is selected but the grid is

actually a one cell wide 3D grid, because the adjoint does not have a 2D

specific mode.

adapt verbose = .false.

When .true., this option reports more information during the error estimation process.

adapt export feature scalar key = ’none’

This is the format to export the feature scalar key for visualization,

‘none’ will not export.

‘cgns’ is CGNS format, requires Fun3D to be configured with a CGNS

library. This format already includes x, y, and z. Set these variables to

.false. to avoid duplication.

219
‘fvuns’ is FieldView C-binary (Fortran stream) format. This format

already includes x, y, and z. Set these variables to .false. to avoid

duplication.

‘VTK’ is legacy VTK format.

‘csv’ is a comma separated value format.

‘tec’ is a single image ASCII tecplot format.

‘raw ascii’ is a single image raw ASCII space separated format

adapt visualize metric = ’none’

This is the format to export the metric for visualization,

‘none’ will not export.

‘cgns’ is CGNS format, requires Fun3D to be configured with a CGNS

library. This format already includes x, y, and z. Set these variables to

.false. to avoid duplication.

‘fvuns’ is FieldView C-binary (Fortran stream) format. This format

already includes x, y, and z. Set these variables to .false. to avoid

duplication.

‘VTK’ is legacy VTK format.

‘csv’ is a comma separated value format.

‘tec’ is a single image ASCII tecplot format.

‘raw ascii’ is a single image raw ASCII space separated format.

adapt current h method = ’edge’

This is the method to estimate the current spacing of the grid,

‘edge’ will use the shortest incident edge at a node.

‘implied’ will use the largest eigenvalue of adjacent element implied

metrics.

adapt current h gradation = 1.5

This limits the gradation of the current spacing estimate by requiring it

to be larger than this ratio of its neighbor’s spacing estimate.

220
B.4.31 &adapt mechanics

This namelist contains variables that control how grid adaptation is performed. More details on general metric-based grid adaptation can be obtained in section 7. This namelist also contains variables to control specialized

line adaptation adapt library = ’line’ and shock fitting line adaptation

adapt library = ’sfline’.

Variables with the ladapt prefix control line adaptation and variables

with a sfline prefix control shock fitting line adaptation. These specialized

1D adaptation methods originated in the LAURA code and have a number of

requirements that are described in the LAURA User’s Manual. [52] The grid

origin must be structured and all nodes assigned to a unique line. All lines

must have the same number of nodes. The outer boundary (opposite solid

walls) can be moved in or out to align with a developing bow shock and the

distribution of points across the boundary layer can be adjusted to recover a

target cell Reynolds number. If the grid has prisms grown off a solid surfaces

then the distribution of prism heights can be adjusted to recover a target cell

Reynolds number at the wall while retaining the the original spacing at the

top of the prism stack.

Variable names beginning with sfline control how shock fitting meshes

are adapted. Currently the shock fitting is only available with line adaptation

which is engaged by specifying adapt library = ’sfline’. The variables

ladapt re cell, ladapt ep0 grd, ladapt fstr, and ladapt g limiter are

also active with shock fitting.

&adapt_mechanics

adapt_library = 'refine/one'

adapt_project = ''

adapt_freezebl = -1.0

adapt_cycles = 2

adapt_bamg_command = 'bamg'

adapt_bamg_geometry_format = 'amdba'

ladapt_fsh = 0.8

ladapt_fstr = 0.75

ladapt_fctrjmp = 1.05

ladapt_re_cell = 1.

ladapt_beta_grd = 0.

ladapt_ep0_grd = 0.

ladapt_max_distance = 1.e+06

ladapt_jumpflag = 2

ladapt_freq = 0

ladapt_max = 1000

ladapt_g_limiter = 0.

sfadapt_fsbuffr = 3

sfadapt_ceqinc = 0.5

221
sfadapt_shkdtct = 1.0e-01

sfadapt_fsfrac0 = 1.0e+00

sfadapt_fsfraci = 1.0e-01

/

adapt library = ’refine/one’

Adaptation library to call. The options are,

‘refine/one’ is the refine tetrahedral metric-based adaptation library.

See Park [28] for a detailed description.

‘refine/two’ is a version of the refine adaptation library that is still

undergoing development. It is based on original version of refine with

some ideas from Michal and Krakos. [53]

‘meshsim’ is the Simmetrix MeshSim adaptation library.

‘bamg’ is the BAMG [4] 2D metric-based adaptation library. The metric

and solution files will be exported and the BAMG executable will be run

in the ../Flow directory.

‘line’ is line-based adaptation [52] for structured grids.

‘sfline’ is shock-fitting line-based adaptation for structured grids.

‘interpolate’ will linearly interpolate the project rootname solution

to an existing adapt project grid without adaptation using the approach of Shenoy. [54]

adapt project = ’’

This is the project name for exporting the adapted grid and solution. An

empty string appends R to the project rootname from the &project

namelist.

adapt freezebl = -1.0

This prevents modification of the grid within this distance of solid wall

boundaries. It is used to to preserve an existing boundary layer grid

structure. A negative value does not freeze. It is described by Park and

Carlson. [55]

adapt cycles = 2

This is the number of adaptation passes. It is only used for adapt library

= ’\refine/one’. Choosing more cycles will produce a grid that better

matches the metric, but can increase the time required for adaptation.

adapt bamg command = ’bamg’

This the the system command to execute BAMG. It may include the full

path or command line arguments.

222
adapt bamg geometry format = ’amdba’

BAMG geometry file format

‘amdba’ specifies -b [project rootname].ambda as the BAMG geometry source. This will spline current boundary nodes to form the geometry

of the domain boundary. It is approximate, but less likely to fail than

.msh file boundary reconstruction.

‘msh’ specifies -b [project rootname].msh as the BAMG geometry

source. This will access the original geometry .msh file to define the

domain boundary, but BAMG may have problems with boundary reconstruction.

ladapt fsh = 0.8

This is the fraction of the distance between the body and the opposing

boundary along a line of nodes where the captured shock is situated.

ladapt fstr = 0.75

This is the fraction of edges along a line that are intended to resolve the

boundary layer.

ladapt fctrjmp = 1.05

This is the property ratio used to detect the shock when marching from

the freestream toward the body. It is assumed the flow above the shock

is uniform and the property ratios across edges along the line remain

equal to one until the shock is encountered.

ladapt re cell = 1.

This is the target cell Reynolds number based on the speed of sound

used to define the edge length ∆n of the first edge leaving the wall.

recell = ρ∆nc/μ.

ladapt beta grd = 0.

This is an exponential grid distribution parameter. Any value greater

than 1 will override adaptation. If it is used to override adaptation to

local flow, the recommended value is 1.15.

ladapt ep0 grd = 0.

This is a grid clustering factor to pull nodes into the captured shock.

A minimum value of 0 produces no clustering. A maximum value of

6.25 produces greatest clustering. Larger values can produce negative

volumes.

ladapt max distance = 1.e+06

This is the maximum distance in grid units the outer boundary can be

moved away from the body. This parameter is useful when adapting to

223
the shock in the wake, where the adapting grid may become excessively

skewed. This value then effectively defines the maximum length of the

wake domain.

ladapt jumpflag = 2

This is an integer flag used to select the method of shock detection,

‘0’ is no movement of outer boundary. Resolution in the boundary layer

is adjusted to recover target re cell.

‘1’ uses pressure as sensing parameter.

‘2’ uses density as sensing parameter.

‘3’ uses temperature as sensing parameter.

‘4’ scales all edges along the line by a factor equal to ladapt fctrjmp.

ladapt freq = 0

This is the number of relaxation steps between calls to line adaptation.

The value 0 prevents line adaptation.

ladapt max = 1000

This is the maximum number of calls to line adaptation permitted.

ladapt g limiter = 0.

This parameter insures a minimum mesh size does not get too big on a

line and cause local skewing. It must be a positive number to engage.

sfadapt fsbuffr = 3

This is the number of buffer nodes between the freestream boundary and

the fitted shock. Zero buffer nodes make the freestream boundary the

shock fitting surface, three buffer nodes moves the shock fitting surface

three nodes into the interior of the computational domain relative to the

freestream boundary.

sfadapt ceqinc = 0.5

This is the shock fitting compatibility equation influence coefficient. A

value of 0.0 means that shock fitting is controlled by the continuity equal

to the compatibility equation, a value of 1.0 means that the shock fitting

is controlled by momentum equation compatibility equal to the compatibility equation, and a value of 0.5 means that shock fitting is equally

controlled by the continuity and momentum compatibility equations.

sfadapt shkdtct = 1.0e-01

This is the shock fitting shock-boundary interaction detector coefficient.

This parameter controls when the shock is considered to be interacting

224
with the shock fitting boundary nodes and determines when the boundary begins to be fitted to the shock. The value is one minus the local

relative density jump below which the shock is not considered to be interacting with the boundary. Increasing this parameter decreases the

sensitivity of the sensor and decreasing this parameter increases the sensitivity of the sensor.

sfadapt fsfrac0 = 1.0e+00

This is the shock fitting initial freestream velocity boundary velocity fraction. When the bow shock has not yet reached the freestream boundary,

the shock fitting equations are not valid. However, the code allows the

freestream boundary to initially move towards the body at some fraction

of the freestream boundary velocity. A value of 0.0 freezes the freestream

boundary until the shock reaches it, a value of 1.0 moves the freestream

boundary at the freestream velocity until the shock reaches it, and a

value in the range (0.0, 1.0) moves the freestream boundary towards the

body at sfadapt fsfrac0*freestreamtotal velocity.

sfadapt fsfraci = 1.0e-01

This is the shock fitting interaction freestream velocity boundary velocity fraction. When the bow shock has been determined to be interacting with the freestream boundary, the shock fitting equations are not

valid all along the shock. However, the code allows the initial interaction speed of the shock with the freestream boundary to be scaled back

at some fraction of the freestream boundary and/or shock velocity. A

value of 0.1 constrains the freestream boundary to move at a fraction

of the freestream velocity and a value in the range (0.0, 1.0) moves the

freestream boundary towards/away from the body at freestream total

velocity*sfadapt fsfraci.

225
B.4.32 &massoud output

This namelist controls the output of files for interaction with the MDO packages (e.g., design, aeroelastics). In a design setting, these files contain the

information necessary to parameterize the surface grid(s). The commandline option --write aero loads to file is required to output the aeroelastics file [project rootname] ddfdrive bodyN.dat and the command line option --write massoud file is required to output the design parameterization

file [project rootname] massoud bodyN.dat for each of the N body groups

present.

&massoud_output

n_bodies = 0

nbndry(:) = 0

boundary_list(:) = ''

massoud_output_freq = -1

massoud_file_format = 'ascii'

massoud_use_initial_coords = .false.

aero_loads_output_freq = -1

aero_loads_file_format = 'ascii'

include_time_info = .true.

aero_loads_use_initial_coords = .false.

aero_loads_dynamic_pressure = 1.0

output_transform(1,1:4) = 1.0, 0.0, 0.0, 0.0

output_transform(2,1:4) = 0.0, 1.0, 0.0, 0.0

output_transform(3,1:4) = 0.0, 0.0, 1.0, 0.0

output_transform(4,1:4) = 0.0, 0.0, 0.0, 1.0

output_scale_factor = 1.0

input_transform(1,1:4) = 1.0, 0.0, 0.0, 0.0

input_transform(2,1:4) = 0.0, 1.0, 0.0, 0.0

input_transform(3,1:4) = 0.0, 0.0, 1.0, 0.0

input_transform(4,1:4) = 0.0, 0.0, 0.0, 1.0

input_scale_factor = 1.0

/

n bodies = 0

This is the number of user-defined bodies. For moving-grid cases, these

bodies are typically the same as those defined as moving bodies, but that

need not be the case.

nbndry(:) = 0

This is the number of boundary patches listed for a given body.

boundary list(:) = ’’

This is a list of boundary patch numbers for a given body. Commas and

dashes can be used to specify ranges, i.e., ’1,2,5-7’.

226
massoud output freq = -1

This is the iteration frequency of massoud output, where the special

value -1 corresponds to once at the end of a successful run.

massoud file format = ’ascii’

This is the format of the massoud file; the alternate choice is ’stream’

(C binary).

‘ascii’ is ASCII file format

‘stream’ is Fortran stream (C binary) format

massoud use initial coords = .false.

Write the massoud file for the x, y, z surface coordinates at t=0. Otherwise, use current x, y, z surface coordinates.

aero loads output freq = -1

This is the iteration frequency of aerodynamic loads output, where the

special value -1 corresponds to once at the end of a successful run.

aero loads file format = ’ascii’

This is the format of the aerodynamic loads file; the alternate choice is

’stream’ (C binary).

‘ascii’ is ASCII file format

‘stream’ is Fortran stream (C binary) format

include time info = .true.

Write simulation time and strand info to ASCII Tecplot file(s). Including time info in the files makes animation within Tecplot very simple.

aero loads use initial coords = .false.

Write the current aerodynamic loads mapped to the x, y, z surface coordinates at t=0. Otherwise, use current x, y, z surface coordinates. This

option is only relevant if the grid is moved or changed during the solution

process.

aero loads dynamic pressure = 1.0

The dynamic pressure used to convert force coefficients into forces; the

default value leaves the output in coefficient form. Note that the input

variable output scale factor separately handles scaling of coordinate

values, so care must be exercised to insure appropriate dimensional forces

if both are used in combination.

227
output transform(1,1:4) = 1.0, 0.0, 0.0, 0.0

This is a user-specified transform matrix to allow output of aero loads

in a custom coordinate system; typically used to output aero loads in

an FEM/CSD coordinate system that differs from the CFD coordinate

system. Note, at this point in time, this transform is applied to ALL

bodies that are defined in this namelist. Note: the transform matrix

should NOT include a scaling factor (e.g. inches to meters); any required

scale factor is input separately.

output scale factor = 1.0

Allows a scaling of the output x,y,z coordinates (e.g. meters to inches).

Scaling is applied as a multiplicative factor.

input transform(1,1:4) = 1.0, 0.0, 0.0, 0.0

This is a user-specified transform matrix to allow input of a new surface

mesh that is defined in a custom coordinate system; typically used to

read in a displaced surface defined in an FEM/CSD coordinate for use in

the CFD coordinate system. Note, at this point in time, this transform

is applied to ALL bodies that are defined in this namelist. Note: the

transform matrix should NOT include a scaling factor (e.g. inches to

meters); any required scale factor is input separately.

input scale factor = 1.0

Allows a scaling of the input x,y,z coordinates (e.g. inches to meters).

Scaling is applied as a multiplicative factor.

228
B.4.33 &sonic boom

This namelist specifies how near-field pressures are extracted from Fun3D

for comparison to wind tunnel measurements, atmospheric propagation to the

ground by another code, or for boom related adjoint cost functions. When

nsignals is greater than zero, the pressure signature is output as a Tecplot

file. The number of points in this output file is determined by the number of

element faces intersected by each user-specified ray, and will span the x-extent

of the entire mesh at that ray location.

The rays are rotated about (x cor,z cor) by angle of attack when the

variable rotate ray by angle of attack is true.

This namelist is also used with the sonic boom adjoint cost functions

boom targ (section 8.2.6) and sboom (section 8.2.7). To form the cost function the ../rubber.data file is required for the flow and adjoint solvers. See

section 6.3 for details on the minimum inputs required for specifying the adjoint cost function. To compute the value of the objective function in the flow

solver, the --design run command line option is required.

&sonic_boom

nsignals = 0

y_ray(:) = 0.001

z_ray(:) = 0.0

x_cor = 0.0

z_cor = 0.0

rotate_ray_by_angle_of_attack = .true.

npoints = 1000

ray_x_limit_method = 'local'

x_lower_bound = -1.e20

x_upper_bound = 1.e20

dp_pinf = .true.

p_pinf = .false.

weight = .false.

/

nsignals = 0

This is the total number of signal rays.

y ray(:) = 0.001

This is the y value of each ray before angle of attack rotation. It is

dimensioned 1 to nsignals.

z ray(:) = 0.0

This is the z value of each ray before angle of attack rotation. It is

dimensioned 1 to nsignals.

229
x cor = 0.0

This is the x center of angle of attack rotation.

z cor = 0.0

This is the z center of angle of attack rotation

rotate ray by angle of attack = .true.

When .true., this will rotate the rays by angle of attack about x cor

and z cor.

npoints = 1000

This is the nominal number of points in each ray that is used to construct

the cost function. Any points lying outside the domain will be ignored.

The points are linearly spaced between the lower and upper bound of x.

ray x limit method = ’local’

This is the method used to determine the x-direction start and end of

the ray when forming the objective function. If x lower bound and/or

x upper bound is specified, then ray x limit method must be set to

’explicit’.

‘local’ sets each ray limit independently by computing the x min and

x max of all grid cells intersected by the ray.

‘explicit’ explicitly sets the x min and x max of all rays with the

x lower bound and x upper bound namelist variables. Only valid for

adjoint cost function boom targ.

x lower bound = -1.e20

This is the explicit x lower bound for ray x limit method=’explicit’

in the cost function definition.

x upper bound = 1.e20

This is the explicit x upper bound for ray x limit method=’explicit’

in the cost function definition.

dp pinf = .true.

When .true., this will include normalized delta pressure (p − p∞)/p∞ in

tecplot output.

p pinf = .false.

When .true., this will include normalized pressure (p)/p∞ in tecplot

output.

weight = .false.

When .true., this will include a weight of one in tecplot output for use

in setting up a near-body target pressure design.

230
B.4.34 &sboom

This namelist contains variables that specify the inputs required to execute

the sBOOM library. See section 8.2.7 for details.

&sboom

alt = 45000.0

hg = 0.0

headangle = 0.0

climbangle = 0.0

dmdt = 0.0

turnrate = 0.0

climbrate = 0.0

rs = 500.0

signum = 10000

zeronum = 1200

tol2 = 1.e-6

nonlinear = 1

thermoviscous = 1

relaxation = 1

initialtimestep = 0.01

refl = 1.9

outflag = 0

numouts = 1000

tol = 0.005

inputininches = 0

adjmode = 1

runmode = 1

objmode = 1

nazimuths = 1

phi(:) = 0.0

targetdbas(:) = 56.0

createtarget = 0

lowerbound = -1000.0

upperbound = -1000.0

lappass = 500

target_numpts(:) = 0

target_xx(:,:) = 0.0

target_dpress(:,:) = 0.0

tflag = 0

ntalt = 0

ztalt(:) = 0.0

talt(:) = 0.0

windflag = 0

nwindx = 0

zwindx(:) = 0.0

231
windx(:) = 0.0

nwindy = 0

zwindy(:) = 0.0

windy(:) = 0.0

rflag = 0

nhalt = 0

zrh(:) = 0.0

rh(:) = 0.0

bodylen = 127.0

reg = 1.e-4

regr = 1.e-4

lbd = 0.99

ubd = 1.0

/

alt = 45000.0

This is the cruise altitude of the full-scale vehicle in feet.

hg = 0.0

This is the height of the ground in feet.

headangle = 0.0

This is the vehicle heading angle in degrees. A 180 heading would mean

away from the x-axis, a 90 heading would mean away from the y-axis.

This option is only relevant when winds are specified.

climbangle = 0.0

The is the vehicle climb angle in degrees.

dmdt = 0.0

This is the acceleration of the vehicle in 1/second (Mach number per

second).

turnrate = 0.0

This is the turning rate of the vehicle in degrees per second.

climbrate = 0.0

This is the climb rate of the vehicle in degrees per second.

rs = 500.0

This is the off-body distance in full-scale feet. This full-scale distance

should match the location in grid units used to define y ray and z ray

in &sonic boom.

232
signum = 10000

This is the number of points representing the off-body waveform for propagation. Increasing the number points reduces the discretization error

of the Burgers equation and increase the execution time of sBOOM.

zeronum = 1200

This in the number of points used to zero pad the front part of the

signature. These points are required to prevent the initial shock from

propagating to the front of the Burgers equation domain and causing

a numerical instability. The actual waveform will be sampled using

(signum-zeronum) points. Typically, 10–20% of signum is required.

tol2 = 1.e-6

This is the leading zero tolerance of the input waveform. It is used to

truncate the initial portion of the off-body waveform before zero padding,

where dp/p value are less than this number.

nonlinear = 1

This controls solution non-linearity,

‘1’ uses cumulative non-linearity.

‘0’ does not use cumulative non-linearity.

thermoviscous = 1

This controls the modeling of thermo-viscous absorption,

‘1’ uses cumulative thermo-viscous absorption.

‘0’ does not use thermo-viscous absorption.

relaxation = 1

This controls the modeling of molecular relaxation,

‘1’ uses cumulative molecular relaxation.

‘0’ does not use molecular relaxation.

initialtimestep = 0.01

Nondimensional initial step size for propagation. A smaller number prevents a multi-valued function, but increases execution time. If you receive a discontinuity error, reduce this value.

refl = 1.9

This is the ground reflection factor used to scale ground signatures.

outflag = 0

This determines the format of the output,

233
‘0’ outputs delta pressure in psf as a function of time in ms.

‘1’ outputs delta pressure divided by freestream pressure as a function

of x in feet.

numouts = 1000

This is the number of points requested in the ground signature.

tol = 0.005

This is the slope tolerance needed for removing zero paddings from the

ground signatures. This allows signatures at different azimuthal angles

to have the same time axis starting with the initial shock.

inputininches = 0

This is the units of the Fun3D grid and geometry to scale the near field

signature x for propagation,

‘0’ for Fun3D grid units in feet.

‘1’ for Fun3D grid units in inches.

‘2’ for Fun3D grid units in meters.

adjmode = 1

This is the sBOOM simulation mode,

‘1’ for a primal and adjoint simulation.

‘0’ for primal simulation only.

runmode = 1

This is the type of propagation and the class of cost function,

‘1’ propagates near field dp/p∞ to ground and adjoint sensitivities of

ground based metrics defined by objmode. The target pressure is specified with target numpts, target dpress, and target xx.

‘0’ reverse propagates near field dp/p∞ to compute equivalent area

(when rs< (alt−hg)) and directly converts off-body pressures to equivalent area (when rs> (alt−hg)). No ground signature or ground-based

cost function is computed. See bodylen, reg, regr, lbd, and ubd. The

target area distribution is specified with target numpts, target dpress,

and target xx.

objmode = 1

This is the cost function definition. The value of runmode changes its

behavior as follows,

234
‘1’ for an A-weighted loudness target of I = (dBA − dBAt)

2 when

runmode=1 and an equivalent area target I =

PN

i=1

1

2

[Ae(i)−Aetarget(i)]2

when runmode=0.

‘2’ for an inverse pressure design objective of I =

PN

i=1[p(i) − p(t, i)]2

when runmode=1 and an equivalent area sum I =

PN

i=1 Ae(i)

2 when

runmode=0.

‘3’ for combined A-weighted loudness and inverse pressure design objective of I = (dBA − 56.0)2 +

PN

i=1[p(i) − p(t, i)]2 when runmode=1.

‘4’ for an A-weighted loudness objective of I = dBA when runmode=1.

nazimuths = 1

This is the number of azimuths to propagate. The nazimuths must

match nsignals in &sonic boom.

phi(:) = 0.0

This is a nazimuths length vector of azimuthal locations in degrees.

targetdbas(:) = 56.0

This is the target (dBAt) at each azimuthal location when objmode=1.

createtarget = 0

This is the source of a ground target signature,

‘0’ for no ground target signature.

‘1’ to internally create a ground target by Laplace smoothing. The

smoothing is controlled by lowerbound, upperbound, and lappass.

‘2’ for a user specified target. The target is defined by the target numpts,

target xx, and target dpress variables.

lowerbound = -1000.0

When createtarget=1, this is the lower bound in time (milliseconds)

after which the user wants to Laplace smooth the computed signature

to form the target. When runmode=0, this defines the start of locations

in X (feet) where any difference in equivalent area between actual and

target equivalent areas will contribute to the cost functional. Outside

these bounds, even if the equivalent area does not match the target, it

does not contribute to the cost functional.

upperbound = -1000.0

When createtarget=1, this is the upper bound in time (milliseconds)

before which the user wants to Laplace smooth the computed signature

to form the target. When runmode=0, this defines the end of locations

235
in X (feet) where any difference in equivalent area between actual and

target equivalent areas will contribute to the cost functional. Outside

these bounds, even if the equivalent area does not match the target, it

does not contribute to the cost functional.

lappass = 500

The number of Laplace smoothing passes to generate a target ground

signature. A higher number increases the smoothness of the target. It

is only used for createtarget=1.

target numpts(:) = 0

This is the number of points in the target xx and target dpress at

each azimuth. It is used for runmode=1 with objmode=2,3 or runmode=0

with objmode=1.

target xx(:,:) = 0.0

This is the time (in milliseconds) of the target signature at each azimuth

for runmode=1 or x in feet for runmode=0. It is only used for some

objective functions, see objmode. The first index is azimuthal location

and the second index is the target signature point.

target dpress(:,:) = 0.0

This is the delta pressure (in psf) of the target signature at each azimuth for runmode=1 or the equivalent area target for runmode=0. It is

only used for some objective functions, see objmode. The first index is

azimuthal location and the second index is the target signature point.

tflag = 0

This controls the source for the atmospheric temperature distribution,

‘0’ for the 1976 U.S. Standard Atmosphere temperature profile.

‘1’ for a temperature profile specified by ntalt, ztalt, and talt.

ntalt = 0

This is the number of ztalt altitude and talt temperature pairs to

define the temperature profile.

ztalt(:) = 0.0

This is ntalt length vector of altitudes (in meters) to specify an atmospheric temperature distribution.

talt(:) = 0.0

This is ntalt length vector of temperature (in Fahrenheit) to specify an

atmospheric temperature distribution.

236
windflag = 0

This controls the source for winds,

‘0’ for no winds.

‘1’ for a wind profile specified by nwindx, windx, zwindx, nwindy,

windy, and zwindy.

nwindx = 0

This is the number of zwindx altitude and windx x-wind pairs that define

the wind profile.

zwindx(:) = 0.0

This is a vector of length nwindx of altitude (in meters) to specify a wind

profile.

windx(:) = 0.0

This is a vector of length nwindx of x-wind speeds (in meters/sec) to

specify a wind profile.

nwindy = 0

This is the number of zwindy altitude and windy y-wind pairs that define

the wind profile.

zwindy(:) = 0.0

This is a vector of length nwindy of altitude (in meters) to specify a wind

profile.

windy(:) = 0.0

This is a vector of length nwindy of y-wind speeds (in meters/sec) to

specify a wind profile.

rflag = 0

This controls the source for the atmospheric humidity distribution,

‘0’ for the 1976 U.S. Standard Atmosphere relative humidity profile.

‘1’ for a relative humidity profile specified by nhalt, zrh, and rh.

nhalt = 0

This is the number of zrh altitude and rh relative humidity pairs.

zrh(:) = 0.0

This is a vector of length nhalt of altitude (in meters) to specify a

relative humidity profile.

237
rh(:) = 0.0

This is a vector of length nhalt of relative humidity (in percent) to

specify a relative humidity profile.

bodylen = 127.0

This is the aircraft body length in feet. It is only used for the adjoint of

equivalent area matching, runmode=0 and adjmode=1.

reg = 1.e-4

This is the thermo-viscous absorption regularization parameter. A smaller

value could lead to an ill-posed reverse diffusion problem. A higher value

increases error. Applicable only when rs< (alt−hg). It is only used for

equivalent area, runmode=0.

regr = 1.e-4

This is the molecular relaxation regularization parameter. A smaller

value could lead to an ill-posed reverse diffusion problem. A higher

value increases error. Applicable only when rs< (alt−hg). It is only

used for equivalent area, runmode=0.

lbd = 0.99

This is the under-deviation parameter for reversed equivalent area matching. Equivalent area deviations below a target are generally favorable to

deviations above a target. Equivalent area matching cost functions and

their sensitivities are only computed when the equivalent area is within

the lbd and ubd limits. It is only used for the adjoint of equivalent area

matching, runmode=0 and adjmode=1.

ubd = 1.0

This is the over-deviation parameter for reversed equivalent area matching. Equivalent area deviations below a target are generally favorable to

deviations above a target. Equivalent area matching cost functions and

their sensitivities are only computed when the equivalent area is within

the lbd and ubd limits. It is only used for the adjoint of equivalent area

matching, runmode=0 and adjmode=1.

238
B.4.35 &equivalent area

This namelist contains variables that specify the inputs associated with equivalent area-based sonic boom cost functions, which is described in section 8.2.8.

The number and order of these inputs should match the equivalent area (Ae)

functions appearing in ../rubber.data.

&equivalent_area

nfunctions = 0

nplane(:) = 0

global_scaling_factor(:) = 1.0

lift_scaling_factor(:) = 1.0

off_track_angle(:) = 0.0

/

nfunctions = 0

This is the total number of Ae functions, including functions used as

objectives and constraints.

nplane(:) = 0

This is the total number of cutting planes along x-axis for each Ae function.

global scaling factor(:) = 1.0

This is the Ae(x) scaling factor for each Ae function.

lift scaling factor(:) = 1.0

This is the Lift L(x) scaling factor for each Ae function.

off track angle(:) = 0.0

This is the off-track angle in degrees for each Ae function.

239
B.4.36 &press box function

This namelist contains variables that are required for the press box function,

which is described in section 8.2.9. The namelist requires the ../rubber.data

file for the flow and adjoint solvers. See section 6.3 for details on the minimum inputs required for specifying the adjoint cost function. To compute

the functional in the flow solver, the --design run command line option is

required.

&press_box_function

integrand_type = 0

gid = 1

xmin = -huge(1.0)

xmax = huge(1.0)

ymin = -huge(1.0)

ymax = huge(1.0)

zmin = -huge(1.0)

zmax = huge(1.0)

/

integrand type = 0

This integer indicates the functional form.

‘0’ is the volume integral of pressure squared inside the defined box.

‘1’ is the volume integral of w-momentum inside the defined box.

‘2’ is the volume integral of u-momentum inside the defined box.

‘3’ is the density at the global node with index gid. Not admissible for

eqn type = ’incompressible’.

‘4’ is the time derivative of pressure at the global node with index gid.

‘5’ is the time derivative of density at the global node with index gid.

Not admissible for eqn type = ’incompressible’.

gid = 1

This integer is a global grid point index to be used with integrand type

= 3-5.

xmin = -huge(1.0)

This real value defines the lower bound in the x-direction for the box

that encloses the volume integral.

xmax = huge(1.0)

This real value defines the upper bound in the x-direction for the box

that encloses the volume integral.

240
ymin = -huge(1.0)

This real value defines the lower bound in the y-direction for the box

that encloses the volume integral.

ymax = huge(1.0)

This real value defines the upper bound in the y-direction for the box

that encloses the volume integral.

zmin = -huge(1.0)

This real value defines the lower bound in the z-direction for the box

that encloses the volume integral.

zmax = huge(1.0)

This real value defines the upper bound in the z-direction for the box

that encloses the volume integral.

241
B.4.37 &pstag function

This namelist contains variables that are required for the pstag function,

which is described in section 8.2.5. This namelist requires the ../rubber.data

file for the flow and adjoint solvers. See section 6.3 for details on the minimum inputs required for specifying the adjoint cost function. To compute

the functional in the flow solver, the --design run command line option is

required.

&pstag_function

slice_orientation = 1

disk_radius = 1.0

x_disk_origin = 0.0

y_disk_origin = 0.0

z_disk_origin = 0.0

/

slice orientation = 1

This integer represents the orientation of the cutting plane. The acceptable values are 1 (x-plane), 2 (y-plane), and 3 (z-plane).

disk radius = 1.0

This real value is the radius of the disk over which the function is to be

evaluated.

x disk origin = 0.0

This real value is the x-coordinate of the origin of the disk.

y disk origin = 0.0

This real value is the y-coordinate of the origin of the disk.

z disk origin = 0.0

This real value is the z-coordinate of the origin of the disk.

242
B.4.38 &special parameters

This namelist specifies changes to the discretization to handle elements with

large face angles.

&special_parameters

large_angle_fix = 'off'

override_bc_limitation = .false.

/

large angle fix = ’off’

Grids with with elements that have adjacent face angles that approach

180 degrees may result in a sudden onset of not a number (NaN). Grids

produced by VGRID may contain these elements.

‘off’ uses all elements in viscous flux evaluation. This is a consistent

viscous discretization.

‘on’ neglects viscous fluxes in cells containing angles between adjacent

faces of 178 degrees or greater. This is an inconsistent discretization,

but may allow the calculation of a solution on a grid that is not suitable

for the consistent viscous discretization.

override bc limitation = .false.

Allow sensitivity analysis for cases with element-based boundary conditions. Users should contact Fun3D-Support@lists.nasa.gov to determine if this option can be used for their simulation.

243
B.4.39 &vortex generator

This namelist is used to specify parameters related to source terms designed

to simulate the effects of vortex generators.

&vortex_generator

number_of_vgs = 0

configuration(:) = 'area_and_height'

boundary_patch1(:) = 0

boundary_patch2(:) = 0

planform_area(:) = 0.0

height(:) = 0.0

calibration_constant(:) = 0.0

point1_xcoord(:) = 0.0

point1_ycoord(:) = 0.0

point1_zcoord(:) = 0.0

point2_xcoord(:) = 0.0

point2_ycoord(:) = 0.0

point2_zcoord(:) = 0.0

point3_xcoord(:) = 0.0

point3_ycoord(:) = 0.0

point3_zcoord(:) = 0.0

reverse_t(:) = .false.

reverse_n(:) = .false.

/

number of vgs = 0

Specifies the number of user-defined vortex generators (max 1000).

configuration(:) = ’area and height’

Specifies the input configuration for each vortex generator. If configuration(i) is ’area and height’, then the ith vortex generator planform

will be a symmetric trapezoid with the endpoints of its base defined by

the point1 and point2 coordinate inputs in the namelist and its area

and height defined by the planform area(i)and height(i) values. If configuration(i) is ’three points’, then the ith vortex generator will have a

triangular planform where the user must supply the coordinates of a

third point defining the off-surface tip of the vortex generator geometry.

In this case, the planform area and height are derived quantities based

on the three input point locations.

boundary patch1(:) = 0

Specifies the boundary patch index for point1 of the ith vortex generator.

This patch will be used for projection of the point1 coordinates specified.

244
boundary patch2(:) = 0

Specifies the boundary patch index for point2 of the ith vortex generator.

This patch will be used for projection of the point2 coordinates specified.

planform area(:) = 0.0

Specifies the intended planform area of the ith vortex generator. This

input only required if configuration = ’area and height’.

height(:) = 0.0

Specifies the height of the ith vortex generator. This input only required

if configuration = ’area and height’.

calibration constant(:) = 0.0

Specifies the calibration constant of the ith vortex generator.

point1 xcoord(:) = 0.0

Specifies the x-coordinate of point 1 defining the ith vortex generator

location. These coordinates need not be precise; the input coordinates

will be projected onto boundary patch1(i).

point1 ycoord(:) = 0.0

Specifies the y-coordinate of point 1 defining the ith vortex generator

location. These coordinates need not be precise; the input coordinates

will be projected onto boundary patch1(i).

point1 zcoord(:) = 0.0

Specifies the z-coordinate of point 1 defining the ith vortex generator

location. These coordinates need not be precise; the input coordinates

will be projected onto boundary patch1(i).

point2 xcoord(:) = 0.0

Specifies the x-coordinate of point 2 defining the ith vortex generator

location. These coordinates need not be precise; the input coordinates

will be projected onto boundary patch2(i).

point2 ycoord(:) = 0.0

Specifies the y-coordinate of point 2 defining the ith vortex generator

location. These coordinates need not be precise; the input coordinates

will be projected onto boundary patch2(i).

point2 zcoord(:) = 0.0

Specifies the z-coordinate of point 2 defining the ith vortex generator

location. These coordinates need not be precise; the input coordinates

will be projected onto boundary patch2(i).

245
point3 xcoord(:) = 0.0

Specifies the x-coordinate of point 3 defining the ith vortex generator

location. This input only required if configuration = ’three points’.

point3 ycoord(:) = 0.0

Specifies the y-coordinate of point 3 defining the ith vortex generator

location. This input only required if configuration = ’three points’.

point3 zcoord(:) = 0.0

Specifies the z-coordinate of point 3 defining the ith vortex generator

location. This input only required if configuration = ’three points’.

reverse t(:) = .false.

Reverse the assumed direction of the unit vector tˆ for the ith vortex

generator.

reverse n(:) = .false.

Reverse the assumed direction of the unit vector ˆn for the ith vortex

generator.

Additional information on the use of vortex generator source terms

The implementation of these source terms in Fun3D is based on the heuristic

model described in [56] and previous references cited therein. The approach

avoids the need for resolving geometric details of vortex generator devices

during mesh generation. Sufficient grid resolution may still be required to

convect the simulated effects of the vortex generator downstream as desired.

The user must also provide a calibration constant for each simulated vortex

generator. This value should be chosen carefully to produce the desired impact

on the local flowfield. Vortex generator source terms currently may only be

applied to static grid simulations. The source terms are treated fully implicit

during the solution procedure.

After developing the desired set of namelist inputs, it is useful to run the

solver for a single iteration, requesting boundary output for (at least) the

boundaries on which vortex generators are to be placed. The geometry for

each vortex generator as determined by Fun3D based on the namelist inputs

will be provided in the Tecplot file [project rootname] vg geometry.dat.

The user should visualize the placement of each vortex generator in relation

to the boundary patches of the grid to ensure the desired placement.

The user will also be provided with a Tecplot file [project rootname]

vg vectors.dat. This file contains the unit vectors ˆb, tˆ, and ˆn according to

the notation described in [56]. The user should visualize these vectors to ensure

that they are oriented appropriately. The vector ˆb is defined uniquely by the

local boundary orientation; however, Fun3D attempts to infer the directions

246
of the vectors tˆ and ˆn based on the freestream direction. If the local flow

direction is expected to be substantially different, these vectors may need to

be manually reversed using the appropriate namelist inputs.

If desired, the user may also plot the points at which the actual source

terms will be computed by ‘scatter plotting’ the data contained in the Tecplot file [project rootname] vg source locations.dat. These locations

are determined by the intersections of the vortex generator geometries with

edges in the grid. Source terms are computed at each of these locations then

scattered to the residual values at either end of the intersecting edge.

An example of the geometry features described above and the local flowfield

in the vicinity of simulated trapezoidal and triangular vortex generators near

the leading edge of a wing is shown here.

Figure B4: View of trapezoidal and triangular vortex generators placed near

the leading edge of a wing geometry. The unit vectors ˆb, tˆ, and ˆn are shown,

as well as the points where the actual source terms will be computed.

247
B.5 moving body.input

This namelist file is only used for time-dependent, moving grid cases to specify

grid motion as a function of time. This file must be used in conjunction with

either the command line option --moving grid, or with the input variable

moving grid = .true. in the &global namelist of the fun3d.nml input file.

The grid-motion options in Fun3D are fairly generally in order to handle

a wide variety of applications. The basic approach is for the user to define one

or more boundaries in the grid to be a ‘body’. Multiple bodies may be defined. Basic setup for these bodies is established using the &body definitions

namelist. A hierarchical relation may be established between multiple bodies

to allow the motion of one body (a ‘child’) to follow the motion of another

body (the ‘parent’). The top level of this hierarchy is the inertial reference

frame, and all motion is ultimately referenced back to this inertial frame. Each

body has its own reference frame, and the reference frames of all bodies are

assumed to be coincident with the inertial reference frame at t=0.

Having established the basic body definition(s), the user specifies a general

descriptor (motion driver) for the mechanism that will drive the motion of

the body, and specifies how the mesh is to be moved - by rigid motion or

by deformation (or both) - in response to the body motion. Note that mesh

deformation requires more CPU time than rigid mesh motion, and is less robust. Mesh deformation may lead to negative cell volumes, at which point the

solution is terminated, while rigid motion will preserve positive cell volumes.

Thus, rigid mesh motion should be favored over mesh deformation whenever

possible. However, there are certain situations where only a deforming mesh

is appropriate. For example if the body is aeroelastic, then the mesh must be

deformed to fit the deformed body surface. In some situations the potential

for a deforming mesh to encounter negative cell volumes can be mitigated by

combining deformation with rigid motion. An example of this is the motion

of elastic rotor blades, wherein the overall rotational motion of the blades is

handled via rigid rotation, but the relatively smaller elastic deflection of the

blades is handled via deformation.

The motion driver specification simply provides a notional mechanism for

how the body is to be moved; details of this mechanism are then provided by

one or more additional namelists. For example, if motion driver = ‘forced’

then details of how to move the body, perhaps by rotation with a given frequency and amplitude, are specified via the &forced motion namelist. Other

options for motion driver - and the required auxiliary namelists to specify

the details - are given in the following sections.

By default, boundary output from Fun3D for visualization purposes (see

section 5.3.1) is provided in the inertial frame. It is sometimes useful to have

this output in a different reference frame, an ‘observer’ frame. For example,

the observer frame might be one attached to a moving body. Specification of

248
an alternate observer frame is handled via the &observer motion namelist.

See the following sections for descriptions of the namelists in this file.

249
B.5.1 &body definitions

This namelist specifies which mesh surfaces define the moving bodies. In

general, each body may have a different motion. However, there are some

fundamental constraints. For example, in a mesh with multiple bodies undergoing different motions, either overset meshes or a deforming mesh would be

required. Note that a deforming mesh might well support only small relative

motions between the bodies before the mesh becomes invalid (negative cell

volumes). For a single rigid mesh, all bodies within the mesh would need to

have the same motion.

&body_definitions

n_moving_bodies = 0

body_frame_forces = .false.

output_transform = .false.

dimensional_output = .false.

ref_velocity = 1117.0

ref_density = 0.002378

ref_length = 1.0

body_name(:) = ''

parent_name(:) = ''

n_defining_bndry(:) = 0

defining_bndry(:,:) = 0

motion_driver(:) = 'none'

mesh_movement(:) = 'static'

x_mc(:) = xmc

y_mc(:) = ymc

z_mc(:) = zmc

s_ref(:) = sref

c_ref(:) = cref

b_ref(:) = bref

move_mc(:) = 1

trim_control(:) = 'none'

baseline_psi(:) = 0.0

steps_per_period(:) = 0

/

n moving bodies = 0

This is the number of bodies in motion.

body frame forces = .false.

This outputs aero forces acting on the body in the frame of the body

when .true., rather than in the inertial reference frame.

output transform = .false.

This outputs the transform matrix to TransformMatrixBody N.hst for

body N when .true..

250
dimensional output = .false.

This outputs the body state data (displacements, velocities, and aero

forces) in dimensional form for forced or 6-DOF motions. Use with

ref velocity, ref density, and ref length to produce body state

output with the desired units.

ref velocity = 1117.0

This is the reference velocity to make aerodynamic forces dimensional,

when dimensional output = .true. Note that this should correspond

to the sound speed if compressible. The default corresponds to standard

sea level speed of sound, in ft/sec.

ref density = 0.002378

This is the reference density to make aerodynamic forces dimensional,

when dimensional output = .true. The default corresponds to standard sea level density, in slugs/ft3

.

ref length = 1.0

This is the reference length to make aerodynamic forces dimensional,

when dimensional output = .true. The default corresponds to one

unit consistent with the values of ref velocity and ref density (i.e.,

1 ft for the default reference conditions).

body name(:) = ’’

This is the name used to identify the body; the array index corresponds

to body number.

parent name(:) = ’’

This is the name of the parent body; the array index corresponds to body

number. The motion of a body follows (i.e., is added to) the motion of

the parent. When naming the parent, ’’ signifies that the parent is the

inertial frame. For single or independently-moving bodies, the default

parent name should be used.

n defining bndry(:) = 0

This is the number of boundaries that define the body; the array index

corresponds to body number.

defining bndry(:,:) = 0

This is a list of n defining bndry boundaries that define the body; the

array index 1 corresponds to the boundary (from 1 to n defining bndry)

defining the body; the array index 2 corresponds to the body number.

If boundary lumping is used (section B.4.2), the boundaries must correspond to lumped boundaries.

251
motion driver(:) = ’none’

This is the body motion mechanism; the array index corresponds to body

number:

‘none’ is for no motion.

‘forced’ uses forced motion prescribed in &forced motion.

‘surface file’ uses surface motion prescribed in &surface motion from file.

‘motion file’ uses motion prescribed in &motion from file.

‘6dof’ computes motion via 6-DOF library, which is governed by &sixdof motion.

‘aeroelastic’ computes motion via &aeroelastic modal data, or by

coupling with an external FEM.

‘custom’ uses custom kinematics; the user supplies a custom transform matrix as a function of time and design variables.

mesh movement(:) = ’static’

This is the type of grid movement associated with body motion; the

array index corresponds to body number:

‘static’ no mesh movement.

‘rigid’ rigid mesh movement; all nodes of the mesh rotate/translate in

unison with the body.

‘deform’ deforms the mesh locally to accommodate the motion of the

solid body.

‘rigid+deform’ mesh undergoes both rigid and deforming motions

x mc(:) = xmc

The is the x-coordinate of moment center at t = 0; the array index

corresponds to body number.

y mc(:) = ymc

This is the y-coordinate of moment center at t = 0; the array index

corresponds to body number.

z mc(:) = zmc

This is the z-coordinate of moment center at t = 0; the array index

corresponds to body number.

s ref(:) = sref

This is the nondimensional reference area for force and moment normalization; the array index corresponds to body number.

252
c ref(:) = cref

This is the nondimensional reference chord length for force and moment

normalization; the array index corresponds to body number.

b ref(:) = bref

This is the nondimensional reference span length for force and moment

normalization; the array index corresponds to body number.

move mc(:) = 1

This controls the movement of the moment center; the array index corresponds to body number.

‘0’ leave moment center fixed in space

‘1:’ move moment center following the body number indicated by the

value of move mc(body) (applicable only for rigid-body motion of body

move mc(body))

trim control(:) = ’none’

This controls whether trim as applied to the body; the array index corresponds to body number.

‘none’ no trim control applied;

‘design’ trim control applied via design variables;

‘body motion’ trim control applied via moving body components;

baseline psi(:) = 0.0

This is the starting azimuth for trim when trim is used as a design

variable; the array index corresponds to body number.

steps per period(:) = 0

This is the number of steps to define a trim period when trim is used as

a design variable; the array index corresponds to body number.

253
B.5.2 &forced motion

&forced_motion

rotate(:) = 0

rotation_rate(:) = 0.0

rotation_freq(:) = 0.0

rotation_phase(:) = 0.0

rotation_tphase(:) = 0.0

rotation_amplitude(:) = 0.0

rotation_origin_x(:) = 0.0

rotation_origin_y(:) = 0.0

rotation_origin_z(:) = 0.0

rotation_vector_x(:) = 0.0

rotation_vector_y(:) = 1.0

rotation_vector_z(:) = 0.0

rotation_start(:) = 0.0

rotation_duration(:) = 1.0e99

translate(:) = 0

translation_rate(:) = 0.0

translation_freq(:) = 0.0

translation_phase(:) = 0.0

translation_tphase(:) = 0.0

translation_amplitude(:) = 0.0

translation_vector_x(:) = 0.0

translation_vector_y(:) = 0.0

translation_vector_z(:) = 1.0

translation_start(:) = 0.0

translation_duration(:) = 1.0e99

/

rotate(:) = 0

This is the type of rotational motion; the array index corresponds to

body number:

‘:-1’ rotate to match Cl target

‘0’ for no rotation.

‘1’ for constant rotation rate, rotation rate.

‘2’ is sinusoidal rotation where θ = rotation amplitude sin(2π rotation freq t +

rotation phase π/180) + rotation tphase π/180 and t is nondimensional.

‘3’ is a square-wave doublet in rotation θ = rotation amplitude for the

first half of the specified rotation duration and θ = -rotation amplitude

for the second half of the specified rotation duration

254
rotation rate(:) = 0.0

This is the nondimensional rotation rate associated with rotate=1; the

array index corresponds to body number.

rotation freq(:) = 0.0

This is the nondimensional rotation reduced frequency associated with

rotate=2; the array index corresponds to body number.

rotation phase(:) = 0.0

This is the rotation phase shift (in degrees) associated with rotate=2;

the array index corresponds to body number.

rotation tphase(:) = 0.0

This is the rotation offset (in degrees) associated with rotate=2 or 3;

the array index corresponds to body number.

rotation amplitude(:) = 0.0

This is the rotation amplitude (in degrees) associated with rotate=2 or

3; the array index corresponds to body number.

rotation origin x(:) = 0.0

This is the x-coordinate of rotation center; the array index corresponds

to body number.

rotation origin y(:) = 0.0

This is the y-coordinate of rotation center; the array index corresponds

to body number.

rotation origin z(:) = 0.0

This is the z-coordinate of rotation center; the array index corresponds

to body number.

rotation vector x(:) = 0.0

This is the x-component of a unit vector along the rotation axis; the

array index corresponds to body number.

rotation vector y(:) = 1.0

This is the y-component of a unit vector along the rotation axis; the

array index corresponds to body number.

rotation vector z(:) = 0.0

This is the z-component of a unit vector along the rotation axis; the

array index corresponds to body number.

255
rotation start(:) = 0.0

This is the nondimensional time at which the rotational motion begins

the array index corresponds to body number.

rotation duration(:) = 1.0e99

This is the nondimensional time over which the rotational motion is

active; the array index corresponds to body number. After this time the

rotational motion is zeroed out.

translate(:) = 0

This is the type of translational motion; the array index corresponds to

body number:

‘0’ for no translation.

‘1’ for a constant translation rate, translation rate.

‘2’ is sinusoidal translation where displacement = translation amplitude

sin(2π translation freq t + translation phase π/180) + translation tphase π/180

and t is nondimensional.

translation rate(:) = 0.0

This is the nondimensional translation rate associated with translate=

1; the array index corresponds to body number.

translation freq(:) = 0.0

This is the nondimensional translation reduced frequency associated with

translate=2; the array index corresponds to body number.

translation phase(:) = 0.0

This is the translation phase shift (in degrees) associated with translate=

2; the array index corresponds to body number.

translation tphase(:) = 0.0

This is the translation offset (in grid units) associated with translate=2;

the array index corresponds to body number.

translation amplitude(:) = 0.0

This is the translation amplitude (in grid units) associated with translate=

2; the array index corresponds to body number.

translation vector x(:) = 0.0

This is the x-component of a unit vector along the translation axis; the

array index corresponds to body number.

256
translation vector y(:) = 0.0

This is the y-component of a unit vector along the translation axis; the

array index corresponds to body number.

translation vector z(:) = 1.0

This is the z-component of a unit vector along the translation axis; the

array index corresponds to body number.

translation start(:) = 0.0

This is the nondimensional start time of the translational motion; the

array index corresponds to body number.

translation duration(:) = 1.0e99

This is the nondimensional duration of the translational motion; the

array index corresponds to body number.

257
B.5.3 &observer motion

This namelist specifies motion of an observer as a function of time for boundary

animation purposes (see the &boundary output variables namelist for more

details); the animation is output from the point of view of the observer.

&observer_motion

ob_parent_name = ''

ob_rotate = 0

ob_rotation_rate = 0.0

ob_rotation_freq = 0.0

ob_rotation_phase = 0.0

ob_rotation_tphase = 0.0

ob_rotation_amplitude = 0.0

ob_rotation_origin_x = 0.0

ob_rotation_origin_y = 0.0

ob_rotation_origin_z = 0.0

ob_rotation_vector_x = 0.0

ob_rotation_vector_y = 1.0

ob_rotation_vector_z = 0.0

ob_translate = 0

ob_translation_rate = 0.0

ob_translation_freq = 0.0

ob_translation_phase = 0.0

ob_translation_tphase = 0.0

ob_translation_amplitude = 0.0

ob_translation_vector_x = 0.0

ob_translation_vector_y = 0.0

ob_translation_vector_z = 1.0

/

ob parent name = ’’

This is the observer parent reference frame. The default indicates the

inertial reference frame - the same as when observer motion is not explicitly specified.

ob rotate = 0

This is the type of rotational motion:

‘0’ for no rotation.

‘1’ for a constant rotation rate, ob rotation rate.

‘2’ is sinusoidal rotation where θ = ob rotation amplitude sin(2π ob rotation freq t +

ob rotation phase π/180) and t is nondimensional.

ob rotation rate = 0.0

This is the nondimensional rotation rate associated with rotate=1.

258
ob rotation freq = 0.0

This is the nondimensional rotation reduced frequency associated with

rotate=2.

ob rotation phase = 0.0

This is the rotation phase shift (in degrees) associated with rotate=2.

ob rotation tphase = 0.0

This is the rotation phase shift (in degrees) applied to transform matrix.

ob rotation amplitude = 0.0

This is the rotation amplitude (in degrees) associated with rotate=2.

ob rotation origin x = 0.0

This is the x-coordinate of rotation center.

ob rotation origin y = 0.0

This is the y-coordinate of rotation center.

ob rotation origin z = 0.0

This is the z-coordinate of rotation center.

ob rotation vector x = 0.0

This is the x-component of a unit vector along the rotation axis.

ob rotation vector y = 1.0

This is the y-component of a unit vector along the rotation axis.

ob rotation vector z = 0.0

This is the z-component of a unit vector along the rotation axis.

ob translate = 0

This is the type of translational motion:

‘0’ for no translation

‘1’ for constant translation rate, ob translate rate.

‘2’ is sinusoidal translation where displacement = ob translation amplitude

sin(2π ob translation freq t + ob translation phase pi/180) and t

is nondimensional.

ob translation rate = 0.0

This is the nondimensional translation rate associated with translate=

1.

259
ob translation freq = 0.0

This is the nondimensional translation reduced frequency associated with

translate=2.

ob translation phase = 0.0

This is the translation phase shift (in degrees) associated with translate=

2.

ob translation tphase = 0.0

This is the translation phase shift (in degrees) applied to transform matrix.

ob translation amplitude = 0.0

This is the translation amplitude (in grid units) associated with translate=

2.

ob translation vector x = 0.0

This is the x-component of a unit vector along the translation axis.

ob translation vector y = 0.0

This is the y-component of a unit vector along the translation axis.

ob translation vector z = 1.0

This is the z-component of a unit vector along the translation axis.

260
B.5.4 &motion from file

This namelist specifies rigid body (and grid) motion via a file containing a 4x4

transform matrix as a function of time. It allows user-defined motion that is

more general than the motions available in the &forced motion namelist.

&motion_from_file

n_time_slices_file(:) = 0

repeat_time_file(:) = 1.0e+99

motion_file(:) = ''

motion_file_type(:) = 'transform_matrix'

/

n time slices file(:) = 0

This is the number of transforms (at selected points in time) defining

the motion of the body; the array index corresponds to body number.

All the transforms for a particular body are contained in a single file.

repeat time file(:) = 1.0e+99

This is the nondimensional time when the motion will repeat; the array

index corresponds to body number.

motion file(:) = ’’

This is the name of the ASCII file that contains the transform matrices

used to set the grid position and orientation of the body for each of the

specified instants in time; the array index corresponds to body number.

The following pseudo code illustrates how such a motion file might be

created:

loop over time steps

write() simulation time

write() xcg, ycg, zcg

do i=1,4

write() transform matrix(i,j), j=1,4)

end do

end time step loop

where simulation time is the nondimensional time, and where xcg,ycg,zcg

are the coordinates of the center of gravity of the body in grid units.

motion file type(:) = ’transform matrix’

This is the type of transform matrix specified; the array index corresponds to body number:

‘transform matrix’ specifies the transform from inertial coordinates

to body (moving) coordinates as a matrix.

261
‘inverse transform’ specifies the transform from body (moving) coordinates to inertial coordinates as a matrix.

262
B.5.5 &surface motion from file

This namelist allows the motion of surface grids to be defined in files. Since

only the surface is specified, mesh movement = ’deform’ must be used to

deform the volume mesh to conform to the specified surface. These files must

be named [project rootname] bodyN timestepM.dat, where N is the body

number and M is the time slice index (1 to n time slices). The files are ASCII

Tecplot files with a zone title line that contains “TIME simulation time”,

where simulation time is nondimensional time. The variables in the file are

the values of x, y, z, as well as id, where id is the global grid number of the

surface point.

&surface_motion_from_file

n_time_slices(:) = 0

repeat_time(:) = 1.0e+99

/

n time slices(:) = 0

This is the number of equally spaced instants in time (and files describing

the shape at those times) defining the motion of the body; the array index

corresponds to body number. Each file contains the surface shape at a

point in time.

repeat time(:) = 1.0e+99

This is the nondimensional time when the motion will repeat; the array

index corresponds to body number.

263
B.5.6 &sixdof motion

This namelist provides details of 6-DOF motion simulations. It requires linking to the 6-DOF library, see section A.7.5. NOTE: most data in this namelist

is input as dimensional data. For 6-DOF motion, the variables ref velocity,

ref density and ref length in the namelist &body definitions must also

be set, in units consistent with those used in &sixdof motion. Note (important): data are assumed to be in FUN3D body coordinates, which are the

FUN3D coordinates at t=0. Note that the assumption of FUN3D coordinates

applies to the moments of inertia.

&sixdof_motion

mass(:) = 1.0

cg_x(:) = 0.0

cg_y(:) = 0.0

cg_z(:) = 0.0

i_xx(:) = 1.0

i_yy(:) = 1.0

i_zz(:) = 1.0

i_xy(:) = 0.0

i_xz(:) = 0.0

i_yz(:) = 0.0

body_lin_vel(:,:) = 0.0

body_ang_vel(:,:) = 0.0

euler_ang(:,:) = 0.0

gravity_dir(1:3) = 0.0, 0.0, -1.0

gravity_mag = 32.2

n_extforce(:) = 0

n_extmoment(:) = 0

file_extforce(:,:) = ''

file_extmoment(:,:) = ''

ignore_x_aeroforce(:) = .false.

ignore_y_aeroforce(:) = .false.

ignore_z_aeroforce(:) = .false.

ignore_x_aeromoment(:) = .false.

ignore_y_aeromoment(:) = .false.

ignore_z_aeromoment(:) = .false.

print_sixdof_summary = .false.

use_specified_aero_data = .false.

use_restart_mass_properties = .false.

/

mass(:) = 1.0

This is the mass of the body; the array index corresponds to the body

number.

264
cg x(:) = 0.0

This is the x-coordinate of the center of gravity; the array index corresponds to the body number.

cg y(:) = 0.0

This is the y-coordinate of the center of gravity; the array index corresponds to the body number.

cg z(:) = 0.0

This is the z-coordinate of the center of gravity; the array index corresponds to the body number.

i xx(:) = 1.0

This is the moment of inertia about the x axis as the body rotates about

the x axis; the array index corresponds to the body number.

i yy(:) = 1.0

This is the moment of inertia about the y axis as the body rotates about

the y axis; the array index corresponds to the body number.

i zz(:) = 1.0

This is the moment of inertia about the z axis as the body rotates about

the z axis; the array index corresponds to the body number.

i xy(:) = 0.0

This is the moment of inertia about the x axis as the body rotates about

the y axis; the array index corresponds to the body number.

i xz(:) = 0.0

This is the moment of inertia about the x axis as the body rotates about

the z axis; the array index corresponds to the body number.

i yz(:) = 0.0

This is the moment of inertia about the y axis as the body rotates about

the z axis; the array index corresponds to the body number.

body lin vel(:,:) = 0.0

These are the components of linear velocity; The first array index (ranging from 1 to 3) corresponds to the x, y, and z components; The second

array index corresponds to the body number.

body ang vel(:,:) = 0.0

These are the components of angular velocity (degrees/sec); The first

array index (ranging from 1 to 3) corresponds to the x, y, and z components; The second array index corresponds to the body number.

265
euler ang(:,:) = 0.0

These are the Euler angles (degrees); The first array (ranging from 1 to

3) corresponds to the rotation angle components; the second array index

corresponds to the body number.

gravity dir(1:3) = 0.0, 0.0, -1.0

This is a unit length gravity vector.

gravity mag = 32.2

This is the magnitude of the gravity vector (default units: f t/sec2).

n extforce(:) = 0

This is the number of imposed external forces, excluding gravity. The

array index corresponds to the body number.

n extmoment(:) = 0

This is the number of imposed external moments; the array index corresponds to the body number.

file extforce(:,:) = ’’

This file specifies the external forces; the first array (ranging from 1

to n extforce) corresponds to the external force number. The second

array index corresponds to the body number.

file extmoment(:,:) = ’’

This file specifies the external moments; the first array (ranging from 1

to n extforce) corresponds to the external force number. The second

array index corresponds to the body number.

ignore x aeroforce(:) = .false.

Flag to ignore the influence of the x-component of the aerodynamic force

on the 6DOF motion of the body; the array index corresponds to the

body number.

ignore y aeroforce(:) = .false.

Flag to ignore the influence of the y-component of the aerodynamic force

on the 6DOF motion of the body; the array index corresponds to the

body number.

ignore z aeroforce(:) = .false.

Flag to ignore the influence of the z-component of the aerodynamic force

on the 6DOF motion of the body; the array index corresponds to the

body number.

266
ignore x aeromoment(:) = .false.

Flag to ignore the influence of the x-component of the aerodynamic

moment on the 6DOF motion of the body; the array index corresponds

to the body number.

ignore y aeromoment(:) = .false.

Flag to ignore the influence of the y-component of the aerodynamic moment on the 6DOF motion of the body; the array index corresponds to

the body number.

ignore z aeromoment(:) = .false.

Flag to ignore the influence of the z-component of the aerodynamic moment on the 6DOF motion of the body; the array index corresponds to

the body number.

print sixdof summary = .false.

Print out a summary of the 6DOF data for each body at each time step,

from within the 6DOF solver itself; useful for verifying that the 6DOF

library is getting the correct data from FUN3D

use specified aero data = .false.

Use aero forces and moments read from file(s) instead of the computed

values (used for validating 6DOF library implementation). When this

option is used, files must be specified for ALL bodies moving under

6DOF. For body N, the file name must be named specified aero data bodyN.dat

use restart mass properties = .false.

Use mass and moments of inertia from the FUN3D restart file instead of

those in this namelist; only needed FUN3D has modified the mass and

inertia during the simulation.

267
B.5.7 &aeroelastic modal data

This namelist specifies modal data for static and dynamic aeroelastic analysis

via time integration of the structural dynamics equations (see for example [57]).

&aeroelastic_modal_data

plot_modes = .false.

nmode(:) = 0

grefl(:) = 1.0

uinf(:) = 0.0

qinf(:) = 0.0

gdisp0(:,:) = 0.0

gvel0(:,:) = 0.0

gforce0(:,:) = 0.0

gmass(:,:) = 0.0

freq(:,:) = 0.0

damp(:,:) = 0.0

moddfl(:,:) = 0

moddfl_amp(:,:) = 0.0

moddfl_freq(:,:) = 0.0

moddfl_t0(:,:) = 0.0

moddfl_add(:,:) = 0

mode_file_format = 'ascii'

/

plot modes = .false.

This generates tecplot files of each mode shape added to the body surface.

These can be inspected these to insure the validity of input modal surface

data.

nmode(:) = 0

This is the number of aeroelastic modes used to represent the structural

deformation; the array index indicates the body number.

grefl(:) = 1.0

This is the scaling factor between CFD grid units and the structural

dynamics equation units; the array index indicates the body number.

uinf(:) = 0.0

This is the freestream velocity, in structural dynamics equation units;

the array index indicates the body number.

qinf(:) = 0.0

This is the freestream dynamic pressure, in structural dynamics equation

units; the array index indicates the body number.

268
gdisp0(:,:) = 0.0

This is the generalized displacement of a specified mode at the starting

time step. It is used to perturb a mode to excite a dynamic response.

The first array index indicates the mode number and the second array

index indicates the body number.

gvel0(:,:) = 0.0

This is the generalized velocity of a specified mode at the starting time

step. It is used to perturb a mode to excite a dynamic response. The

first array index indicates the mode number and the second array index

indicates the body number.

gforce0(:,:) = 0.0

This is the generalized force of a specified mode at the starting time

step. It is used to perturb a mode to excite a dynamic response. The

first array index indicates the mode number and the second array index

indicates the body number.

gmass(:,:) = 0.0

This is the generalized mass of a specified mode. The first array index

indicates the mode number and the second array index indicates the

body number.

freq(:,:) = 0.0

This is the frequency of specified mode, in rad/sec. The first array index

indicates the mode number and the second array index indicates the

body number.

damp(:,:) = 0.0

This is the damping ratio of specified mode. The first array index indicates the mode number and the second array index indicates the body

number.

moddfl(:,:) = 0

This is the type of time-varying mode perturbation. The first array

index indicates the mode number and the second array index indicates

the body number.

‘-1’ is the modal displacement and velocity held fixed at the initial

values specified by gdisp0 and gvel0, respectively.

‘0’ is no modal perturbation.

‘1’ is a harmonic modal oscillation.

‘2’ is a Gaussian pulse modal deflection.

269
‘3’ is a step pulse modal deflection.

‘5’ specifies simultaneous inputs for reduced order model.

moddfl amp(:,:) = 0.0

This is the amplitude of mode perturbation. The first array index indicates the mode number and the second array index indicates the body

number.

moddfl freq(:,:) = 0.0

This is the frequency of mode perturbation. If moddfl=2, it is the Gaussian pulse half-life. The first array index indicates the mode number and

the second array index indicates the body number.

moddfl t0(:,:) = 0.0

If moddfl=1, this is the dimensional time at which the sinusoidal perturbation starts. If moddfl=2, this is the dimensional time of the center of

the Gaussian pulse. If moddfl=3, this is the start time of a step pulse.

The first array index indicates the mode number and the second array

index indicates the body number.

moddfl add(:,:) = 0

This determines how the modal perturbation is applied. The first array

index indicates the mode number and the second array index indicates

the body number.

‘0’ replaces the perturbation with the static aeroelastic solution.

‘1’ adds the perturbation to an existing static aeroelastic solution (if

one exists).

mode file format = ’ascii’

This indicates the type and format of the mode-shape files that are read

by the code. mode file format = ’ascii’ indicates the files are ASCII

Tecplot files, with a file extension .dat; mode file format = ’stream’

indicates binary (stream) DDF files, with a file extension .ddfb.

270
B.5.8 &composite overset mesh

This namelist provides the input for SUGGAR++ (see the documentation

supplied with SUGGAR++ for details).

&composite_overset_mesh

input_xml_file = ''

/

input xml file = ’’

This is the file containing the XML commands for SUGGAR++. Specify

the same Input.xml file that was used to generate the initial composite

grid with the “stand-alone” SUGGAR++ code.

271
B.5.9 &body motion trim

This namelist provides the input for trimming a moving body to match selected trim targets. Trim is achieved by moving one or more bodies via rotation, translation, or modal amplitude. This option often relies on parent-child

composite bodies. For example, a wing composite body (the parent) may be

comprised of a main element (a child) and a flap element (another child). If

the wing composite body is to be trimmed to match both a lift target and a

pitching moment target, the lift target can be achieved by adjusting the rotation angle of the wing composite body, and the moment target can be achieved

by adjusting the rotation angle of the flap element. An imposed restriction is

that each trim target is achieved by moving a single body; that single body

could however be a composite parent-child body

&body_motion_trim

trim_ref_frame = 'body'

n_trim_targets(:) = 0

trim_variable(:,:) = 'none'

trim_value(:,:) = 0.0

body_used_for_trim(:,:) = 0

motion_used_for_trim(:,:) = 'none'

mode_used_for_trim(:,:) = 0

per_step_limit(:,:) = 0.0

update_frequency(:,:) = 1

trim_jacobian(:,:,:) = 0.0

/

trim ref frame = ’body’

This sets the reference frame in which trim targets are to be satisfied.

Note that wind-aligned trim targets (Cl and Cd) are unaffected by the

choice of trim ref frame.

n trim targets(:) = 0

This sets the number of trim targets for the body; the array index corresponds to body number of the body to be trimmed.

‘0:max trim targets’ up to three simultaneous trim targets per body;

trim variable(:,:) = ’none’

This specifies the force/moment variables to trim to; the array index

1 corresponds to the trim target from 1 to n trim targets set for the

body; the array index 2 corresponds to the body number of the body to

be trimmed.

‘cl’ trims to a specified lift coefficient

‘cd’ trims to a specified drag coefficient

272
‘cw’ trims to a specified weight coefficient; weight is assumed to act in

the (negative) z-direction. Trim is computed as if a thrust is applied

along the body x-axis to counterbalance drag; if the body x-axis is not

aligned with the inertial x-axis, this thrust will also have a contribution

in the inertial z-direction.

‘cx’ trims to a specified force coefficient in the x-direction

‘cy’ trims to a specified force coefficient in the y-direction

‘cz’ trims to a specified force coefficient in the z-direction

‘cmx’ trims to a specified moment coefficient about the x-axis

‘cmy’ trims to a specified moment coefficient about the y-axis

‘cmz’ trims to a specified moment coefficient about the z-axis

trim value(:,:) = 0.0

This specifies the desired numerical values of the trim variables at the

time condition; the array index 1 corresponds to the trim target from 1

to n trim targets set for the body; the array index 2 corresponds to

the body number of the body to be trimmed.

body used for trim(:,:) = 0

This specifies the body number of the body that is moved to achieve the

trim target; the array index 1 corresponds to the trim target from 1 to

n trim targets set for the body; the array index 2 corresponds to the

body number of the body to be trimmed.

motion used for trim(:,:) = ’none’

This specifies the type of body motion used to achieve the trim target; the

array index 1 corresponds to the trim target from 1 to n trim targets

set for the body; the array index 2 corresponds to the body number of

the body to be trimmed.

‘rotate’ trims by rotating the body used for trim

‘translate’ trims by translating the body used for trim

‘mode’ trims by adjusting modal amplitude of the body used for trim

mode used for trim(:,:) = 0

This specifies the aeroelastic mode number used to achieve the trim

target; only used for modal aeroelastic simulations, and only active when

motion used for trim=’mode’; the array index 1 corresponds to the

trim target from 1 to n trim targets set for the body; the array index

2 corresponds to the body number of the body to be trimmed.

273
per step limit(:,:) = 0.0

This specifies the maximum amount that the motion used for trim can

change during each attempt to achieve trim; if the motion is rotation,

the units are degrees; if translation, the units are grid units; if modal

amplitude, the units are (I have no idea); the array index 1 corresponds

to the trim target from 1 to n trim targets set for the body; the array

index 2 corresponds to the body number of the body to be trimmed.

update frequency(:,:) = 1

This specifies the frequency with which the trim variable is updated

trim jacobian(:,:,:) = 0.0

This specifies the sensitivities of the specified trim variable(s) to a

change in the specified motion used for trim(s). Thus it is an n trim targets

x n trim targets array for each body with trim control = ’body motion’.

The array index 1 corresponds to the trim variable, array index 2 corresponds to the control motion, the array index 3 corresponds to the

body number of the body to be trimmed. The sign of the entries is

important. For example, if the trim variable is lift, and the motion is

rotation, then if an increase in the rotation angle produces an increase

in lift, then the sign of that entry in trim jacobian should be positive.

Conversely, if an increase in rotation angle produces a decrease in lift,

then the sign of that entry in trim jacobian should be negative. If the

motion used for trim is rotation, the sensitivity is assumed to be input

per degree.

274
B.6 rotor.input

Fun3D is capable of modeling a rotating blade system using different levels of

approximation. In order of increasing complexity/fidelity/cost, rotor systems

may be analyzed using either a time-averaged actuator disk, or via first principles modeling of the moving, articulated, rotor blades using overset, moving

grids. The actuator method utilizes momentum/energy source terms to represent the influence of the rotating blade system. Use of the source terms

simplifies grid generation, since the actuator surfaces do not need to be built

into the computational grid. However, the computational grid should have

some refinement in the vicinity of the actuator surfaces to obtain accurate

results. The steady-state actuator disk capability was originally implemented

by Dave O’Brien, at the time a PhD candidate at Georgia Tech. [58] O’Brien

also initiated the overset capability in Fun3D, which was later extended and

coupled to a rotorcraft comprehensive code by Biedron et al. [59]

The rotor.input file is used primarily for specifying input quantities related

to an actuator surface model for rotor/propeller combinations. When using

overset, moving grids and/or coupling Fun3D to a rotorcraft comprehensive

code for a more detailed simulation, a limited number of the input fields in

the rotor.input file are also required. The fields required for coupled rotorcraft simulations include (required for coupled simulation) in the variable

description. The command line option --rotor is required for both types of

analysis.

Fun3D can also use the actuator disk library developed by Dave O’Brien

for the Department of Defense HI-ARMS/CREATE/HELIOS project, Software Module for Engineering Methods of Rotor Dynamics (SMEMRD). The

Fun3D team is unable to provide technical support for SMEMRD; please

contact Dave O’Brien directly for assistance (David.ObrienJr@us.army.mil).

SMEMRD adds the ability to trim to thrust values and use airfoil lookup

tables. The --hiarms rotor command line option activates the SMEMRD

model.

The two parameters used to set the flight condition and force/moment coefficient normalization in compressible rotorcraft simulations are mach number in

fun3d.nml and Vinf Ratio in rotor.input. To nondimensionalize the forces

with the rotor tip velocity, set mach number to the tip mach number and

Vinf Ratio to the ratio of freestream velocity to rotor tip velocity (the helicopter advance ratio). When mach number is the tip mach number then

reynolds number should be set to the corresponding tip Reynolds number.

To nondimensionalize the forces with the freestream velocity, set mach number

to the freestream mach number and Vinf Ratio to one. The Vinf Ratio will

still affect the force nondimensionalization as described above, for incompressible solutions.

A sample rotor.input file is shown below for a conventional main rotor

275
and tail rotor helicopter.

# Rotors Vinf_Ratio Write Soln Force_ref Moment_ref

2 0.1 50 1.0 1.0

=== Main Rotor =========================================================

Rotor Type Load Type # Radial # Normal Tip Weight

1 0 50 720 0.0

X0_rotor Y0_rotor Z0_rotor phi1 phi2 phi3

0.00 0.00 0.00 0.00 -5.00 0.00

Vt_Ratio ThrustCoff PowerCoff psi0 PitchHinge DirRot

1.00 0.005 -1.00 0.00 0.0 0

# Blades TipRadius RootRadius BladeChord FlapHinge LagHinge

4 1.00 0.00 0.05 0.00 0.00

LiftSlope alpha, L=0 cd0 cd1 cd2

6.28 0.00 0.002 0.00 0.00

CL_max CL_min CD_max CD_min Swirl

1.50 -1.50 1.50 -1.50 0

Theta0 ThetaTwist Theta1s Theta1c Pitch-Flap

5.00 -2.00 0.00 0.00 0.00

# FlapHar Beta0 Beta1s Beta1c

0 0.00 0.00 0.00

Beta2s Beta2c Beta3s Beta3c

0.00 0.00 0.00 0.00

# LagHar Delta0 Delta1s Delta1c

0 0.00 0.00 0.00

Delta2s Delta2c Delta3s Delta3c

0.00 0.00 0.00 0.00

=== Tail Rotor =========================================================

Rotor Type Load Type # Radial # Normal Tip Weight

1 0 100 720 0.0

X0_rotor Y0_rotor Z0_rotor phi1 phi2 phi3

1.00 0.00 0.00 90.00 0.00 0.00

Vt_Ratio ThrustCoff PowerCoff psi0 PitchHinge DirRot

1.25 0.001 -1.00 0.00 0.0 0

# Blades TipRadius RootRadius BladeChord FlapHinge LagHinge

3 0.20 0.00 0.01 0.00 0.00

LiftSlope alpha, L=0 cd0 cd1 cd2

6.28 0.00 0.002 0.00 0.00

CL_max CL_min CD_max CD_min Swirl

1.50 -1.50 1.50 -1.50 1

Theta0 ThetaTwist Theta1s Theta1c Pitch-Flap

8.00 0.00 0.00 0.00 0.00

# FlapHar Beta0 Beta1s Beta1c

0 0.00 0.00 0.00

Beta2s Beta2c Beta3s Beta3c

0.00 0.00 0.00 0.00

# LagHar Delta0 Delta1s Delta1c

0 0.00 0.00 0.00

Delta2s Delta2c Delta3s Delta3c

0.00 0.00 0.00 0.00

The header line is where the user specifies the number of rotors, the rotor

advance ratio, and how often to output the plot3d loading file. The remainder

of the file is in a block structure, where each block represents the inputs for

one rotor. The first line of each block is a text line that can be edited to keep

the rotors organized for the user. The input values do not have to be in a fixed

format (spaces and number of decimal points do not matter), but the input

values do have to be in the correct order as noted by the header lines for the

individual input parameters.

276
B.6.1 Header

# Rotors (required for coupled simulation)

This is the number of actuator surfaces to create. The number of rotor

input blocks in this file must match the number of rotors specified.

Vinf Ratio (required for coupled simulation)

This is the ratio of the freestream velocity to the the velocity used for

force normalization. This velocity used for force normalization is typically the tip velocity for rotorcraft applications; in that case, Vinf Ratio

is the advance ratio and mach number is the freestream velocity.

Write Soln

This is the frequency (in iterations) of Plot3D rotor loading data output,

which is pairs of source grid 00000.p3d and source data 00000.p3d

files. To write once, set Write Soln to steps.

Force ref

This is the conversion factor to obtain forces in alternate units,

1.0 will output the standard Fun3D nondimensionalization

(L

2

refa

2

ref )/(πR2

rotorV

2

tip) will output standard rotorcraft nondimensionalization

ρrefa

2

refL

2

ref will output dimensional units

Moment ref

This is the conversion factor to obtain moments in alternate units.

1.0 will output the standard Fun3D nondimensionalization

(L

2

refa

3

ref )/(πR3

rotorV

2

tip) will output standard rotorcraft nondimensionalization

ρrefa

2

refL

3

ref will output dimensional units

B.6.2 Actuator Surface Model

Rotor Type

Type of rotor model to apply,

1 models the rotor as an actuator disk.

2 models the rotor as actuator blades.

Load Type

Type of loading to apply to the rotor model.

277
1 is a pressure jump based on ThrustCoeff that is constant over the

disk.

2 is a pressure jump based on ThrustCoeff that increases linearly with

radius.

3 is blade element based loading based defined by the blade element

parameters defined in section B.6.6 and section B.6.7.

4 is user specified source geometry and strength. Not recommended unless you have experience in actuator disk modeling. See the subroutine read user source2 in LibF90/rotors.f90 for input format.

5 is user specified thrust and torque radial distributions in the file

propeller propertiesN.dat, where N is the rotor index. The first

line of the file is the number of radial stations. The following lines

have three numbers per station, with r/R,

dCT

d(r/R)

,

dCl

d(r/R)

.

# Radial

This is the number of sources to distribute along the blade radius. This

should be set to approximately match the resolution of the volume grid,

otherwise a suggested value is 100.

# Normal

This is the number of sources to distribute along the circumferential

direction. This should be set to approximately match the resolution

of the volume grid. For Rotor Type=1, 720 is suggested for a source

every 0.5 degrees. For Rotor Type=2, 20 points in the chord direction is

suggested.

Tip Weight

This is the hyperbolic weighting factor for distributing sources along the

blade radius. A suggested value is 0.0, which yields uniform distribution. A value larger than 2.0 is not advised, because this large a value

concentrates too many sources at the blade tip.

B.6.3 Rotor Reference System

X0 rotor (required for coupled simulation)

This is the x coordinate of the hub center of rotation, in grid units.

Y0 rotor (required for coupled simulation)

This is the y coordinate of the hub center of rotation, in grid units.

Z0 rotor (required for coupled simulation)

This is the z coordinate of the hub center of rotation, in grid units.

278
phi1

This is the first Euler angle describing a rotation about the x axis, in

degrees. For a propeller oriented in the x-positive direction, this should

be 0.

phi2

This is the second Euler angle describing a rotation about the a2 axis, in

degrees. For a propeller oriented in the x-positive direction, this should

be −90.

phi3

This is the third Euler angle describing a rotation about the b3 axis, in

degrees. For a propeller oriented in the x-positive direction, this should

be 0.

The Euler angles must be input correctly to obtain the correct orientation

of the source based actuator disk. The following example illustrates how to

determine these angles. Figure B5 depicts the rotations phi1 = 10, phi2 =

−15, and phi3 = 15. Initially, the thrust is assumed to be in the z direction

and the disk is located in the x − y plane. The first rotation of phi1 about

the x axis takes the x − y − z system to the a1 − a2 − a3 system shown in red.

The second rotation of phi2 about the a2 axis takes the a1 − a2 − a3 system

to the b1 − b2 − b3 system shown in green. The final rotation of phi3 about

the b3 axis takes the b1 −b2 −b3 system to the rotor reference system shown in

blue. The black circle represents the initial disk orientation and the blue circle

represents the final disk orientation. In general phi1 and phi2 are sufficient

to define the thrust orientation. The variable phi3 only changes the location

of the zero azimuth angle definition for the rotor.

Figure B5: Rotor disk Euler angles.

279
B.6.4 Rotor Loading

Vt Ratio (required for coupled simulation)

This is the ratio of the tip speed to the velocity used for force normalization. If the force normalization velocity is freestream, then Vt Ratio

= 1/(advance ratio). For Load Type = 3, a negative value will reverse

the rotation direction.

ThrustCoff

This is the rotor thrust coefficient defined as, CT = Thrust / (πρrefR2(ΩDimR)

2

),

when Load Type=1 or Load Type=2. The blade element model does not

trim to specified thrust coefficient.

PowerCoff

This is the rotor power coefficient [Not implemented].

B.6.5 Blade Parameters

psi0 (required for coupled simulation)

This is the initial azimuthal position of blade one, in degrees; the azimuth

position is defined as zero when the blade is oriented along the x-axis

with the tip at the most positive x location.

PitchHinge (required for coupled simulation)

This is the radial position of the blade pitch hinge normalized by tip

radius.

DirRot (required for coupled simulation)

This is the direction of rotor rotation. Zero is counter-clockwise rotation and one is clockwise rotation. This option only applies to coupled

simulation, not actuator models.

# Blades (required for coupled simulation)

This is the number of rotor blades. It is only used for Load Type=3 and

overset rotor simulations.

TipRadius (required for coupled simulation)

This is the radius of the blade, in grid units.

RootRadius (required for coupled simulation)

This is the radius of the blade root, in grid units. It accounts for the

cutout region immediately surrounding the hub.

280
BladeChord (required for coupled simulation)

This is the chord length of the blade, in grid units. It can only handle

rectangular blade planforms and is only valid for Load Type=3.

FlapHinge (required for coupled simulation)

This is the radial position of the blade flap hinge normalized by tip

radius.

LagHinge (required for coupled simulation)

This is the radial position of the blade lag hinge normalized by tip radius.

B.6.6 Blade Element Parameters for Load Type=3

These inputs are used to set the blade element lift and drag curves according

to:

CL = LiftSlope(α − αL=0) (B1)

and

CD = cd0 + cd1 α + cd2 α

2

(B2)

LiftSlope

This is the lift curve slope per radian.

alpha, L=0

This is the zero lift angle of attack, in degrees.

cd0, cd1, and cd2

These are the quadratic drag polar coefficients; where cd1 is per radian

and cd2 is per radian squared.

CL max and CL min

These limiters to control the lift coefficient beyond the linear region.

CD max and CD min

These limiters to control the drag coefficient.

Swirl

0 neglects the sources terms that create rotor swirl.

1 the swirl inducing source terms.

281
B.6.7 Pitch Control Parameters for Load Type=3

These inputs are used to specify the pitch/flap controls according to:

θ = Theta0 + ThetaTwist (r/R) + Theta1c cos(ψ) + Theta1s sin(ψ) (B3)

Theta0

This is the collective pitch defined at r/R=0, in degrees.

ThetaTwist

This is the total amount of linear blade twist from the origin to the blade

tip, in degrees.

Theta1s

This is the longitudinal cyclic pitch input, in degrees.

Theta1c

This is the lateral cyclic pitch input, in degrees.

Pitch-Flap

Pitch-Flap coupling parameter [not implemented].

B.6.8 Prescribed Flap Parameters

These inputs are used to specify the flap harmonics according to:

β = Beta0 + Beta1s sin(ψ) + Beta1c cos(ψ)

+Beta2s sin(2ψ) + Beta2c cos(2ψ) (B4)

+Beta3s sin(3ψ) + Beta3c cos(3ψ)

# FlapHar

This is the number of flap harmonics to include. The valid input range

is zero to three.

Beta0

This is the coning angle, in degrees.

Beta1s and Beta1c

This is the first flap harmonics, in degrees.

Beta2s and Beta2c

This is the second flap harmonics, in degrees.

Beta3s and Beta3c

This is the third flap harmonics, in degrees.

282
B.6.9 Prescribed Lag Parameters

These inputs are used to specify the lag harmonics according to:

δ = Delta0 + Delta1s sin(ψ) + Delta1c cos(ψ)

+Delta2s sin(2ψ) + Delta2c cos(2ψ) (B5)

+Delta3s sin(3ψ) + Delta3c cos(3ψ)

# LagHar

This is the number of lag harmonics to include. The valid input range

is zero to three.

Delta0

This is the coning angle, in degrees.

Delta1s and Delta1c

This is the first lag harmonics, in degrees.

Delta2s and Delta2c

This is the second lag harmonics, in degrees.

Delta3s and Delta3c

This is the third lag harmonics, in degrees.

B.7 tdata

This file defines the gas model when eqn type = ’generic’. A keyword is

required on the first line of tdata. Many of these models require additional

information as detailed in each keyword section.

Some keywords require a list the species. For these keywords, additional

groups of species can be specified for boundary conditions after a blank line.

If new species are introduced in subsequent instances their mass fractions are

automatically initialized to zero at any previous inflow boundary. All the

species entries in this file are available as reactants throughout the entire flow

field.

B.7.1 perfect gas Keyword

A perfect gas can be modeled with the perfect gas keyword. The parameters

can be explicitly defined in tdata by the namelist &species properties. The

namelist in tdata has different variables than the &species properties in

species thermo data. Here is an example of the namelist with defaults that

are all given in SI units,

283
perfect_gas

&species_properties

gamma = 1.4

mol_wt = 28.8

suther1 = 0.1458205E-05

suther2 = 110.333333

prand = 0.72

/

Where gamma is the gas specific heat ratio, mol wt is the gas molecular weight,

prand is the gas Prandtl number, and suther1 and suther2 are the first and

second Sutherland’s viscosity coefficients, s1 and s2, in

μ = s1

T

3/2

T + s2

(B6)

These defaults are used if the &species properties namelist or any of its

variables are omitted.

B.7.2 equilibrium air t Keyword

The equilibrium air t keyword engages the Tannehill curve fits for thermodynamic and transport properties of equilibrium air. [60] This keyword does

not require additional lines.

equilibrium_air_t

B.7.3 equilibrium air r Keyword

The equilibrium air r keyword engages the Tannehill curve fits for transport

properties and a table look-up for equilibrium gases [61], This keyword does

not require additional lines.

equilibrium_air_r

B.7.4 one Keyword

This one-temperature (1-T) model assumes that all the species are thermally

in equilibrium state; the translational temperature T and vibrational temperature Tv are equal. This is a mixture of thermally perfect gases and multi-species

transport. In this example, only molecular oxygen and nitrogen are present

on the inflow boundary, but atomic nitrogen and oxygen and nitric oxide may

be produced elsewhere in the flow field due to chemical reactions. The inflow

boundary mass fraction of molecular oxygen and nitrogen is given next to their

symbols. Mass fractions should sum to one.

284
one

N2 .767

N

O2 .233

O

NO

B.7.5 two Keyword

This two-temperature (2-T) model assumes that energy distribution in the

translational and rotational modes of heavy particles (not electrons) are equilibrated at translational temperature T and all other energy modes (vibrational,

electronic, electron translational) are equilibrated at vibrational temperature

Tv. In this example, the gas is assumed to be a mixture of 11 thermally perfect

gases. The inflow boundary mass fraction of molecular oxygen and nitrogen is

given next to their symbols. Mass fractions should sum to one. Other products

are the results of chemical reactions flow field.

two

N2 .767

N

O2 .233

O

NO

O2+

O+

NO+

eB.7.6 FEM Keyword

This Free-Energy Minimization (FEM) model causes the species continuity

equations to be replaced with elemental continuity equations and equilibrium

relations for remaining species. In this example, the gas is assumed to be a

mixture of 11 thermally perfect gases. The inflow boundary mass fraction of

molecular oxygen and nitrogen is given next to their symbols. Mass fractions

should sum to one. Other products are the results of chemical reactions flow

field.

FEM

N2 .767

N

O2 .233

O

NO

O2+

285
O+

NO+

eB.8 species thermo data

The species thermo data file is the master file for species thermodynamic

data. The majority of simulations do not require changes to this file. Investigating other sources of thermodynamic data is the only reason to edit this file.

If the file is not found in the local run directory, it is assumed to be located in

the [install-prefix]/share/physics modules directory. See section A.3

for [install-prefix].

Each species record consists of the species name, a &species properties

namelist, the number of thermodynamic property curve fit ranges, and the

curve fit coefficients for each range. [62] No blank line is allowed in this

file. This &species properties namelist has different variables than the

&species properties in tdata. The elements of the &species properties

namelist are:

mol wt

This sets the molecular weight of the particle. It is always required.

molecule = .false.

This is denotes the the species a molecule (composed of more than one

atom);

ion = .false.

This is denotes the the species a charged particle. Do not set it for neutrals and electrons. This will initializes electron-neutral energy exchange

cross section and sum of the charges.

charge = 0

This is an integer number to determine number of positive charges in

particle. It should only be used with ion = .true.

elec impct ion = -1. dp

This sets the energy for neutrals ion=.false. that is required to liberate

an electron when the neutral impact a free electron, in units of electron

volts (eV).

siga(:) = -1. dp

This is an array of three real numbers, which correspond to the curve

fit coefficients for electron-neutron energy exchange. The cross section

is defined as

σen = a + bT + cT2(B7)

286
where σen is the electron-neutron energy exchange collision cross section

in m2. The variables a, b, and c are the curve fit coefficients and T is

the gas temperature. [63, 64] For example, siga=7.5e-20, 0, 0.

disoc ener = 0. dp

This is the dissociation energy of molecule in electron volts (eV).

alantel = 0. dp

This is the Landau-Teller constant to compute vibrational relaxation

time for molecule. [65, 66]. It is required when molecule=.true..

cprt0 = 0. dp

This non-dimensional real number defines translational-rotational heat

capacity. It is normalized by the gas constant and is equal to

cprt() = f + 2

2

(B8)

where f is the number of degrees of freedom in translation and rotation. The defaults for atoms and diatomic molecules are 2.5 and 3.5,

respectively.

A portion of the species thermo data that provides thermodynamic properties of carbon is shown below.

C 1

&species_properties 2

molecule = .false. 3

ion = .false. 4

charge = 0 5

elec_impct_ion = 11.264 6

siga = 7.5e-20, 5.5e-24, -1.e-28 7

mol_wt = 12.01070 8

/ 9

3 10

0.64950315E+03 -0.96490109E+00 0.25046755E+01 -0.12814480E-04 11

0.19801337E-07 -0.16061440E-10 0.53144834E-14 0.00000000E+00 12

0.85457631E+05 0.47479243E+01 200.000 1000.000 13

-0.12891365E+06 0.17195286E+03 0.26460444E+01 -0.33530690E-03 14

0.17420927E-06 -0.29028178E-10 0.16421824E-14 0.00000000E+00 15

0.84105978E+05 0.41300474E+01 1000.000 6000.000 16

0.44325280E+09 -0.28860184E+06 0.77371083E+02 -0.97152819E-02 17

0.66495953E-06 -0.22300788E-10 0.28993887E-15 0.00000000E+00 18

0.23552734E+07 -0.64051232E+03 6000.000 20000.000 19

The species name is defined in line 1. Between lines 2 and 9 species properties

are defined. Line 10 shows that there are three thermodynamic property curve

287
fits for temperature ranges of 200 K < T < 1,000 K, 1,000 K < T < 6,000 K,

and 6,000 K < T < 20,000 K. Each data range consists of 12 real numbers.

Four real numbers must be given on each line. The first 10 real numbers are the

thermodynamic curve fit coefficients, and the last two real numbers identify

the temperature range for the given curve fit coefficients. These coefficients

are used to calculate the following thermodynamic properties

cp(T)/R = a1T

−2 + a2T−1 + a3 + a4T + a5T2 + a6T3 + a7T4

(B9)

h(T)/RT = −a1T

−2+a2T−1

ln T +a3+a4

T

2

+a5

T

2

3

+a6

T

3

4

+a7

T

4

5

+

a9

T

(B10)

s(T)/R = −a1

T

−2

2

−a2T

−1+a3ln T +a4T +a5

T

2

2

+a6

T

3

3

+a7

T

4

4

+a10 (B11)

where T is the gas temperature, R is the universal gas constant, cp, h, and s

are the species specific heat, enthalpy and entropy, respectively, and ai are the

provided curve fit coefficients in species thermo data.

The following corrections will be applied if the gas temperature is out of

the given range for the given curve fit coefficients:

cp(T) = cp(T

∗

) (B12)

h(T) = h(T

∗

) + (T − T

∗

)cp(T

∗

) (B13)

s(T) = s(T

∗

) + ln T

T

∗

cp(T

∗

) (B14)

where

T

∗ =



Tlower for T < Tlower

Tupper for T > Tupper

(B15)

B.9 kinetic data

The kinetic data file defines possible chemical reactions and is optional. If

the file is not found in the local run directory, it is assumed to be located in

the [install-prefix]/share/physics modules directory. See section A.3

for [install-prefix]. Reactants and products can be any species defined in

the species thermo data described in section B.8. A sample entry looks like

O2 + M <=> 2O + M 1

2.000e+21 -1.50 5.936e+04 2

teff1 = 2 3

exp1 = 0.7 4

t_eff_min = 1000. 5

t_eff_max = 50000. 6

C = 5.0 7

O = 5.0 8

288
N = 5.0 9

H = 5.0 10

Si = 5.0 11

e- = 0. 12

The first line specifies the reaction while line 2 provides three coefficients of

an Arrhenius-like equation,

Kf = cfT

η

ef f e

−0/kTeff (B16)

where cf is the pre-exponential factor, η is the power of temperature dependence on the pre-exponential factor, 0 is the Arrhenius activation energy, and

k is the Boltzmann constant. The arrowheads in line 1 signify the allowed

directionality of the reaction. The symbol => denotes forward reaction only

while <=> denotes forward and backward rates are computed. The coefficients

in line 2 correspond to cf , η, and 0/k, respectively. For reactions with a

generic collision partner, M, such as this one, these coefficients correspond to

Argon; and other collision partners and their efficiencies (multipliers of cf )

are specified on lines following line 5 and 6, which give the valid temperature

range for the reaction. The effective temperature, Tef f , is defined according

to a given integer number in line 3.

teff1 = 1,teff2 = 1

This defines the formula to compute the effective temperature Tef f for

the forward rate and backward rate, respectively. It is engaged for the

case of thermal nonequilibrium. Options for teff are:

1: Tef f = Ttr

2: Tef f = T

exp1

tr T

1−exp1

v

3: Tef f = Tv

where Ttr and Tv are translational and vibrational temperatures, respectively.

exp1 = 0.7

This is the exponent used to define the effective temperature when

teff1= 2 (forward rate) or teff2 = 2 (backward rate).

rf max = 1.e+20

This is the upper limit on forward reaction rate in cgs units when

augment kinetics limiting = .true. For unlimited rates as function

of temperature, see the output file kinetic diagnostics output.

289
rf min = 1.e-30

This is the lower limit on forward reaction rate in cgs units when

augment kinetics limiting= .true. For unlimited rates as function of

temperature, see the output file kinetic diagnostics output.

rb max = 1.e+30

This is the upper limit on backward reaction rate in cgs units when

augment kinetics limiting = .true. For unlimited rates as function

of temperature, see the output file kinetic diagnostics output.

rb min = 1.e-30

This is the lower limit on backward reaction rate in cgs units when

augment kinetics limiting = .true. For unlimited rates as function

of temperature, see the output file kinetic diagnostics output.

t eff min = 1000.

This is the minimum temperature for Tef f . This may circumvent stiff

source terms when computing reaction rates.

t eff max = 50000.

The maximum temperature for Tef f . This may circumvent stiff source

terms when computing reaction rates.

B.10 species transp data

The species transp data file contains log-linear curve fit coefficients for

species collision cross sections that are defined based on temperature range

of 2,000–4,000 K. [64] This temperature range spans boundary-layer temperatures for typical hypersonic entry. The curve fit for the given coefficients is

poor at temperatures below 1,000 K. Higher order curve fit data is available

in species transp data 0. The file should not be changed by the user unless

there is a need to investigate other sources of collision cross-section data. If

the file is not found in the local run directory, it is assumed to be located in

the [install-prefix]/share/physics modules directory. See section A.3

for [install-prefix]. An example of the entries in the file is

Ar Ar 1

-14.6017 -14.6502 -14.5501 -14.6028 ! trr132+kestin et al 2

Ar+ Ar+ 3

-11.48 -12.08 -11.50 -12.10 4

Ar N2 5

-14.5995 -14.6475 -14.5480 -14.5981 ! kestin et al 6

Ar CO 7

-14.5975 -14.6455 -14.5459 -14.5964 ! kestin et al 8

290
B.11 species transp data 0

The file species transp data 0 provides collision cross section coefficients

[67,68] for a higher order curve fit data than those that are in the species transp data.

The data in species transp data 0 supersedes the data in species transp data

The file should not be changed by the user unless there is a need to investigate other sources of collision cross-section data. If the file is not found in

the local run directory, it is assumed to be located in the [install-prefix]

/share/physics modules directory. See section A.3 for [install-prefix].

An example of the entries in the file is

O2 N 1 1 1 (c)

-1.1453028E-03 1.2654140E-02 -2.2435218E-01 7.7201588E+01

-1.0608832E-03 1.1782595E-02 -2.1246301E-01 8.4561598E+01

1.4943783E-04 -2.0389247E-03 1.8536165E-02 1.0476552E+00

NO N 1 1 1 (c)

-1.5770918E-03 1.9578381E-02 -2.7873624E-01 9.9547944E+01

-1.4719259E-03 1.8446968E-02 -2.6460411E-01 1.0911124E+02

2.1014557E-04 -3.0420763E-03 2.5736958E-02 1.0359598E+00

NO O 1 1 1 (c)

-1.0885815E-03 1.1883688E-02 -2.1844909E-01 7.5512560E+01

-1.0066279E-03 1.1029264E-02 -2.0671266E-01 8.2644384E+01

1.4145458E-04 -1.9249271E-03 1.7785767E-02 1.0482162E+00

END END 1 1 0

0. 0. 0. 0.

0. 0. 0. 0.

B.12 hara namelist data

The hara namelist data file controls the radiation models used by the Hara

radiation module. [69,70] It is optional for coupled radiation simulations. If it is

not present, then the code automatically chooses the radiative mechanisms associated with species present in the flowfield that have number densities greater

than 1000 particles/cm2) Other options are set to the defaults. For users not

experienced in shock-layer radiation, the recommended default options should

be used. this hara namelist data A default hara namelist data is available

in the PHYSICS MODULES directory of the Fun3D distribution.

specifying radiation mechanisms for atomic species: The treatment

of radiation resulting from atomic lines, atomic bound-free, and free-free photoionization (referred to here as atomic continuum), and negative ion continuum is available for atomic carbon, hydrogen, oxygen, and nitrogen. These

291
mechanisms are specified through the following binary flags (on=1/off=0). If

any of these flags are not present in hara namelist data, then that flag is set

to true only if the number density of the associated atomic species is greater

than 1000 particles/cm2somewhere in the flowfield.

treat [?] lines

A binary flag to enable the treatment of atomic lines for species [?],

where [?] can be c, h, n, and o, for atomic carbon, hydrogen, nitrogen

and oxygen, respectively.

treat [?] cont

A binary flag to enable the treatment of atomic bound-free and free-free

continuum for species [?], where [?] can be c, h, n, and o, for atomic

carbon, hydrogen, nitrogen and oxygen, respectively.

treat [?] other

A binary flag to enable the treatment of the negative-ion continuum for

species [?], where [?] can be c, h, n, and o, for atomic carbon, hydrogen,

nitrogen and oxygen, respectively.

specifying radiation mechanisms for molecular species: The treatment of radiation resulting from numerous molecular band systems is available through the following flags (0 = off, 1 = SRB, 2 = LBL). The smeared

rotational band (SRB) approach applies a simplified and efficient treatment of

each molecular band system, which is accurate for optically thin conditions.

The line-by-line (LBL) approach is a detailed but highly inefficient treatment

of each molecular band system. The LBL option is not recommended for coupled radiation-flowfield computations, except for possibly the CO 4+ system,

which may be optically thick for Mars entry conditions. If any of these flags

are not present in hara namelist data, then that flag is set to the SRB option

only if the number density of the associated molecular specie is greater than

1000 particles/cm2somewhere in the flowfield. Additional band systems are

listed in the following paragraph. These additional band systems are generally considered negligible relative to those listed in this section. Therefore, for

computational efficiency, they are not engaged by default. Definitions of each

band system and the modeling data applied are discussed in Refs. [69, 71].

treat band c2 swan

A flag activating the C2 Swan band system.

treat band c2h

A flag activating the C2H band system.

292
treat band c3

A flag activating the C3 and vacuum ultra-violet (VUV) band systems.

treat band cn red

A flag activating the CN red band system.

treat band cn violet

A flag activating the CN violet band system.

treat band co4p

A flag activating the CO 4+ band system.

treat band co bx

A flag activating the CO B-X band system.

treat band co cx

A flag activating the CO C-X band system.

treat band co ex

A flag activating the CO E-X band system.

treat band co ir

A flag activating the CO X-X band system.

treat band h2 lyman

A flag activating the H2 Lyman band system.

treat band h2 werner

A flag activating the H2 Werner band system.

treat band n2fp

A flag activating the N2 1+ band system.

treat band n2sp

A flag activating the N2 2+ band system.

treat band n2pfn

A flag activating the N+

2 first-negative band system.

treat band n2 bh1

A flag activating the N2 Birge-Hopfield I band system.

treat band n2 bh2

A flag activating the N2 Birge-Hopfield II band system.

293
treat band no beta

A flag activating the NO beta band system.

treat band no delta

A flag activating the NO delta band system.

treat band no epsilon

A flag activating the NO epsilon band system.

additional molecular band systems: This paragraph lists molecular band

systems available in addition to those listed in the paragraph above. The

band systems listed here are generally weak emitters and absorbers, and are

therefore not engaged as a default. Therefore, for these band systems to be

engaged, the following flags (0 = off, 1 = SRB, 2 = LBL) must be present

in the hara namelist data file. The LBL treatment of these bands is not

recommended.

treat band c2 br

A flag activating the C2 Ballik-Ramsay band system.

treat band c2 da

A flag activating the C2 Deslandres-d’Azambuja band system.

treat band c2 fh

A flag activating the C2 Fox-Herzberg band system.

treat band c2 mulliken

A flag activating the C2 Mulliken band system.

treat band c2 philip

A flag activating the C2 Philips band system.

treat band co3p

A flag activating the CO 3+ band system.

treat band co angstrom

A flag activating the CO angstrom band system.

treat band co asundi

A flag activating the CO Asundi band system.

treat band co triplet

A flag activating the CO triplet band system.

294
treat band co2

A flag activating the CO2 band system. A value of two activates an

approximate nonequilibrium model for UV emission, while a value of

one assumes Boltzmann emission. The LBL treatment of this band is

not available.

treat band n2 cy

A flag activating the N2 Carrol-Yoshino band system.

treat band n2 wj

A flag activating the N2 Worley-Jenkins band system.

treat band n2 worley

A flag activating the N2 Worley band system.

treat band no gamma

A flag activating the NO gamma band system.

treat band no betap

A flag activating the NO beta-prime band system.

treat band no gammap

A flag activating the NO gamma-prime band system.

treat band o2 sr

A flag activating the O2 Schumann-Runge band system.

treat [?] photo dis

A binary flag activating the molecular photo-dissociation mechanism [72]

for [?] specie, where [?] can be O2 or N2. This mechanism is not

technically a molecular band system.

treat [?] photo ion

A binary flag activating the molecular photo-ionization mechanism [72]

for [?] specie, where [?] can be O2 or N2. This mechanism is not

technically a molecular band system.

treat no photo

A binary flag activating the molecular photo-ionization mechanism [72]

for NO.

295
atomic line models: There are various models available for atomic line radiation, one of which must be chosen for each specie that engages atomic line radiation (as specified using treat [?] lines). This choice of atomic line model

is made using the following flags. The listed defaults are applied if the individual flag is not present in hara namelist data, or if hara namelist data

is not present in the working directory. All model types in this category must

be surrounded by a quotation marks.

c atomic line model, h atomic line model

A character identifier for selecting the atomic line model for atomic carbon or hydrogen. Presently, the only available option is the model compiled in Ref. [71], which is referred to here as the Complete Line Model

(CLM). Default : ‘clm’

n atomic line model, o atomic line model

A character identifier for selecting the atomic line model for atomic nitrogen or oxygen. The available models are compiled and compared in

Ref. [69], which is referred to here as the Complete Line Model (CLM).

Default : ‘clm’ Available models are:

‘all multiplets’

This model treats all lines as grouped multiplets. This significantly

reduces the number of lines treated as well as the computational

expense. However, this grouped multiplet approximation will lead

to errors for non-optically-thin conditions.

‘clm’

This model, which stands for Complete Line Model, applies the

individual treatment of strong atomic lines while applying multiplet

averages for weak lines. This is the recommended model.

electronic state population models: These flags specify the model applied for predicting the electronic state populations of atoms and molecules.

The listed defaults are applied if the individual flag is not present in

hara namelist data, or if hara namelist data is not present in the working

directory. All model types in this category must be surrounded by a quotation

marks, e.g. ‘ ’.

atomic electronic states

The electronic state populations for atoms are required for computing atomic

line and photoionization emission and absorption. The compilation and comparison of the available models are presented in Ref. [70].

296
c electronic state, h electronic state

A character identifier for selecting the electronic state model for atomic

carbon and hydrogen. Available models are (default : ‘boltzmann’):

‘boltzmann’

Applies Boltzmann population of electronic states.

‘Gally 1st order LTNE’

Applies the Gally first-order local thermodynamic nonequilibrium

method [73], which approximately accounts for the non-Boltzmann

population of atomic states.

n electronic state, o electronic state

A character identifier for selecting the electronic state model for atomic

nitrogen and oxygen. Available models are (default : ‘CR’):

‘boltzmann’

Same as for c electronic state

‘Gally 1st order LTNE’

Same as for c electronic state

‘CR’

Applies the detailed collisional radiative (CR) model developed in

Ref. [70].

‘AARC’

Applies the approximate atomic collisional radiative (AARC) model

developed in Ref. [70]. This model is essentially a curve-fit based

approximation of the CR model, which allows for improved computational efficiency with a slight loss in accuracy.

molecular electronic states

The electronic state populations for molecules are required for computing

molecular band emission and absorption. The compilation and comparison

of the available models are presented in Refs. [70, 74].

molecular electronic state

A character identifier for selecting molecular electronic state for all molecular band systems. Available models are (default : ‘CR’):

‘boltzmann’

Applies Boltzmann population of electronic states.

297
‘CR’

Applies a detailed collisional radiative model considering both heavyparticle and electron impact transitions. Some molecular states

are still assumed Boltzmann with this model because no data is

presently available for the CR model.

other flags:

use triangles

A logical flag specifying whether optically-thin atomic lines are modeled

as triangles to reduce computational time. This option has shown to

result in a negligible loss of accuracy while greatly reducing the computational time, [69] and is therefore recommended. Default : .true. Note:

This flag is automatically set to .true. when n or o atomic line model=

‘clm’ — see atomic line models earlier in this section.

use edge shift

A logical flag to engage the photoionization edge shift [69] for atomic

bound-free radiation. (on=1/off=0). Default : .true.

298
Appendix C

Troubleshooting

The goal of the Fun3D developers is to produce as robust a solver as

possible. However, there are times when the code fails to produce a converged

solution. For example, taking the square root of a negative quantity (due to a

negative density or pressure) results in a NaN. We hope that these suggestions

are helpful. If none of the suggestions listed here remedy your problem, please

contact Fun3D-Support@lists.nasa.gov.

C.1 What if the solver has trouble starting or reports

NaNs?

Check that the freestream, reference, and boundary conditions are specified

correctly. Visualize the solution, especially near the location of the maximum

residual. If the problem is widespread, run the simulation again and visualize

the solution a few iterations before the problem happens. Look for extremely

large Mach numbers, low pressures, low densities, or reversed flow at boundaries.

Examining the residual history may help to isolate the problem to the

mean flow or turbulence model. Lowering the CFL numbers of the meanflow and turbulence equations can aid linear and nonlinear convergence, see

section B.4.14. If the linear system is diverging (the linear system can be examined with the --monitor linear command line option), increase the number

of sweeps or utilize the Krylov projection method linear projection=.true.,

see section B.4.15.

Try flow field initialization in the problematic region of the domain (e.g.,

engine plenum), see section B.4.19. Start with some first order iterations

(section B.4.9) or try continuation from less challenging freestream condition

(e.g., lower angle of attack, subsonic Mach number).

C.2 What if the forces and moments aren’t steady or

residuals don’t converge to steady-state?

Try lowering the CFL numbers of the mean flow and turbulence model, see

section B.4.14. Examining the residual history may help to isolate the problem

to the mean flow or turbulence model. The problem may be unsteady; try

restarting the solution with a time-accurate simulation.

299
C.3 What if the solver dies unexpectedly?

You may need to set your shell limits to unlimited,

$ ulimit unlimited # for bash

$ unlimit # for c shell

If your operating system reports a Signal 9 or 11 and you have already tried

removing shell restrictions, you have likely hit the memory limit of your machine. Try reducing the number of mesh points, running on more nodes, or

installing more memory on your machine.

C.4 What if a segmentation fault occurs after “Calling

ParMetis”?

Make sure that the the width (32 or 64 bits) of integers in Fun3D and

ParMETIS are consistent. More recent implementations of MPI (e.g., OpenMPI) internally manage the handles (i.e., communicators) differently from

previous versions of MPI. However, ParMETIS 3.* uses an older paradigm,

which has been updated in ParMETIS 4.*. Upgrade to ParMETIS 4.*.

C.5 What if the solver dies with an error like “input

statement requires too much data” after echoing

the wrong number of elements or nodes?

The endianness (section 4.1) of the grid files (section 4) may be different than

Fun3D expects.

C.6 What if the solver dies with an error like “input

statement requires too much data” after echoing

the number of tetrahedra and nodes for a VGRID

mesh?

Single-segmented VGRID grids over 20 million nodes exceed the allowable

record length. Use postgrid to save grid as a multi-segmented format (option

O5 in batch mode).

C.7 What if the solver reports that the Euler numbers

differ?

The Euler number is a global indicator of consistent node, element, and face

connectivity. There is some limited evidence that suggests there may be times

when it reports a problem that may not be an issue for the solver, but the

300
failure of the Euler number check indicates a problem with the grid in a majority of cases. Instructions to determine if the Euler number will impact your

solution follow this description of the Euler number.

C.7.1 Euler Number Description

A valid grid is composed of four elemental volume types (tetrahedra, pyramids, prisms, and hexahedra) face-connected either to each other or one of

two boundary face types (triangles or quadrilaterals). Each boundary edge

connects to precisely two boundary faces. Two neighboring boundary faces

share exactly one boundary edge. For each boundary face connecting to a

boundary node, every other boundary face connecting to the same boundary

node can be found by a path through a connected-edge/connected-face traverse

starting from that boundary face.

The above restrictions are meant to exclude certain topologies such as two

spherical boundaries coming together at a point or two rectangular boundaries

connecting along an edge. These restrictions are not checked explicitly but will

cause the Euler number check described below to fail.

The Euler Number computed from boundary data (ENb) is

ENb = Nb − Eb + Fb (C1)

where

Nb ≡ boundary nodes (counted) (C2)

Eb ≡ boundary edges (inferred fromNtri and Nquad) (C3)

Fb ≡ boundary faces (inferred from Ntri and Nquad) (C4)

The Euler number is a characteristic number for the topology of the boundary

or boundaries. Ntri and Nquad are the number of triangular and boundary

faces, respectively.

The Euler Number computed from volume data (ENv) is

ENv = 2(N − E + F − C) (C5)

where

N ≡ volume nodes (counted) (C6)

E ≡ volume edges (counted) (C7)

F ≡ volume faces (inferred from C and Fb) (C8)

C ≡ volume cells (counted) (C9)

The formula that is checked is

ENv − ENb = 0 (C10)

301
Barth [75] derived this formula for tetrahedra and noted the formula does

not hold in certain cases, such as two simplices that share only one common

edge or two simplices that share only one common node. Barth notes that the

above formulas are specific forms of the general Dehn-Sommerville formula,

reported in Wikipedia to hold for simplicial polytopes and simple polytopes.

The pyramid is not a simple polytope. It can be proved by induction [76] that

the formula holds for every valid grid as defined above.

Try this checklist to diagnose the problem:

1. Check the ENb with your expectations for this case:

2 for a spherical topology, simple 3D wing with symmetry, . . .

0 for a torus, donut, . . .

-2 for a double torus, . . .

-4 for a triple torus, pretzel, . . .

4 for a sphere within a sphere, . . .

6 for two spheres within a sphere, . . .

2. Ensure the number of boundary nodes Nb and faces Fb reported match

expected values.

3. Ensure the number of nodes N and cells C reported match expected

values.

4. The difference between ENb and ENv points to inconsistencies in edge

counts, i.e., δ(E) = 2(ENb − ENv) 6= 0. The inequality ENb > ENv

implies you have more edges than expected. When this occurs, the reported face counts will differ from an actual count. An error of this type

would arise when there are adjacent faces that are inconsistent, such as

a quadrilateral face shared between two elements that is cut into two

triangular faces by different edges.

C.7.2 Determining the Impact of an Euler Number Mismatch

A freestream residual problem localization technique is described. However,

the best practice is to not proceed without repairing the grid to ensure ENb =

ENv. The ignore euler number namelist variable does just what the name

implies, and allows the solver to proceed. The --test freestream option can

be used as a secondary check on the mesh. On a valid mesh, the solver should

preserve the freestream for an arbitrary number of iterations. You should run

20–50 iterations, which may require a lowering of the stopping tolerance

to 1e-20 so the solver does not automatically stop. All residuals should

hover around machine zero, and not slowly increase (there will be iterationto-iteration variation in the exact number, however).

302
If freestream is maintained by this test, you could proceed with your intended computation using only ignore euler number, but this is not recommended. If freestream is not maintained, this test confirms that there is a

problem with the mesh and the location of the max residual may give a clue

as to where in the mesh to start looking for the problem.

303
REPORT DOCUMENTATION PAGE Form Approved

OMB No. 0704-0188

2. REPORT TYPE 

Technical Memorandum

 4. TITLE AND SUBTITLE

FUN3D Manual: 12.5 

5a. CONTRACT NUMBER

 6. AUTHOR(S)

Biedron, Robert T.; Derlaga, Joseph M.; Gnoffo, Peter A.; Hammond, 

Dana P.; Jones, William T.; Kleb, William L.; Lee-Rausch, Elizabeth M.; 

Nielsen, Eric J.; Park, Michael A.; Rumsey, Christopher L.; Thomas, James 

L.; Wood, William A.

 7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

NASA Langley Research Center

Hampton, VA 23681-2199

 9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)

National Aeronautics and Space Administration

Washington, DC 20546-0001

 8. PERFORMING ORGANIZATION

 REPORT NUMBER

L-20451

10. SPONSOR/MONITOR'S ACRONYM(S)

NASA

13. SUPPLEMENTARY NOTES

12. DISTRIBUTION/AVAILABILITY STATEMENT

Unclassified - Unlimited

Subject Category 61

Availability: NASA CASI (443) 757-5802

19a. NAME OF RESPONSIBLE PERSON

STI Help Desk (email: help@sti.nasa.gov)

14. ABSTRACT

This manual describes the installation and execution of FUN3D version 12.5, including optional dependent packages. FUN3D 

is a suite of computational Fluid dynamics simulation and design tools that uses mixed-element unstructured grids in a large 

number of formats, including structured multiblock and overset grid systems. A discretely-exact adjoint solver enables 

efficient gradient-based design and grid adaptation to reduce estimated discretization error. FUN3D is available with and 

without a reacting, real-gas capability. This generic gas option is available only for those persons that qualify for its beta 

release status. 

15. SUBJECT TERMS

Aerodynamics; Computer programming; Fluid mechanics; Mathematics; Propulsion system

18. NUMBER

 OF 

 PAGES

304

19b. TELEPHONE NUMBER (Include area code)

(443) 757-5802

a. REPORT

U

c. THIS PAGE

U

b. ABSTRACT

U

17. LIMITATION OF 

 ABSTRACT

UU

Prescribed by ANSI Std. Z39.18

Standard Form 298 (Rev. 8-98)

3. DATES COVERED (From - To)

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

 794072.02.07.02.03 

11. SPONSOR/MONITOR'S REPORT

 NUMBER(S)

NASA/TM-2014-218520

16. SECURITY CLASSIFICATION OF:

The public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, 

gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this 

collection of information, including suggestions for reducing this burden, to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and 

Reports (0704-0188), 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person 

shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number.

PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS.

1. REPORT DATE (DD-MM-YYYY)

01- 09 - 2014