Computational Simulation of Flow Around Helicopter Fuselages

81 downloads 4386 Views 4MB Size Report
around a helicopter fuselage is explored using unstructured grids in a parallel flow solver. The flow ...... 1.2 Method (from CAD Drawing to Solution). In order to ...
The Pennsylvania State University The Graduate School Department of Aerospace Engineering

COMPUTATIONAL SIMULATION OF FLOW AROUND HELICOPTER FUSELAGES

A Thesis in Aerospace Engineering by Steven Schweitzer

 1999 Steven Schweitzer

Submitted in Partial Fulfillment of the Requirements for the Degree of Master of Science

May 1999

We approve the thesis of Steven Schweitzer. Date of Signature

Lyle N. Long Professor of Aerospace Engineering Thesis Advisor

Edward C. Smith Associate Professor of Aerospace Engineering

Dennis K. McLaughlin Professor of Aerospace Engineering Head of Department of Aerospace Engineering

iii

ABSTRACT The possibility of predicting the full three dimensional unsteady separated flow around a helicopter fuselage is explored using unstructured grids in a parallel flow solver. The flow solver used is modified version of the Parallel Unstructured Maritime Aerodynamics (PUMA) solver. Dr. Christopher Bruner wrote PUMA as part of his doctoral thesis [1] at the Virginia Polytechnical Institute and State University. The efficiency and accuracy of PUMA at resolving a steady state solution was measured in order to determine if it was a suitable platform to serve as an input to the Non-Linear Disturbance Equations (NLDE) algorithm derived by Dr. Philip Morris and Dr. Lyle Long [2]. PUMA is a small, highly portable, easy to use code that could easily be modified to include NLDE. NLDE has proven successful in predicting complex flows in several cases, which will be discussed. Unstructured Grids were utilized in order to maximize the number of cells in the area of interest while minimizing cells in the far field. A high level of clustering will be required to properly implement NLDE and unstructured grids offer the least expensive method to ensure proper clustering. NASA’s Vgrid package was used to generate the unstructured grids. The geometry computed for comparison was around the NASA Rotor Body Interaction Fuselage (ROBIN) [3]. The ROBIN geometry has been extensively tested in the NASA Langley wind tunnels and excellent experimental data exists for the shape. The PUMA steady state solutions compare very well with experimental data.

iv

TABLE OF CONTENTS

LIST OF FIGURES..................................................................................................VI LIST OF TABLES ...................................................................................................IX ACKNOWLEDGMENTS ........................................................................................X Chapter 1 MOTIVATION AND BACKGROUND.................................................1 1.1 1.2 1.3 1.4 1.5

Previous Work............................................................................................2 Method (from CAD Drawing to Solution) ..................................................4 Robin Body ................................................................................................6 Flow Solvers...............................................................................................10 Thesis Scope ..............................................................................................10

Chapter 2 GRID GENERATION............................................................................12 2.1 VGrid Unstructured Grid Generator............................................................16 Chapter 3 FLOW SOLVERS...................................................................................25 3.1 CFL3D versus PUMA ................................................................................26 3.2 PUMA........................................................................................................31 Chapter 4 COMPUTATIONAL RESULTS .............................................................35 4.1 4.2 4.3 4.4

Computers Utilized.....................................................................................35 Robin Experimental Data............................................................................36 ROBIN Results...........................................................................................38 Apache Results...........................................................................................61

Chapter 5 FUTURE WORK ...................................................................................69 5.1 5.2 5.3 5.4

Viscous Robin ............................................................................................69 Nonlinear Disturbance Equations................................................................70 Preconditioning ..........................................................................................74 K-Exact Reconstruction..............................................................................75

v 5.5 Future Geometries for Analysis ..................................................................76 Chapter 6 CONCLUSION ......................................................................................78 BIBLIOGRAPHY ....................................................................................................81 Appendix A PRO ENGINEER TO GRIDTOOL EXPORTER................................84 Appendix B

PARAMETERS FOR GENERATING ROBIN SHAPE ....................86

Appendix C

F-77 PROGRAM TO PRODUCE ROBIN SHAPE............................88

Appendix D PUMA SAMPLE INPUT FILE ..........................................................99 Appendix E ROBIN EXPERIMENTAL DATA (ALPHA=0).................................102 Appendix F ROBIN EXPERIMENTAL DATA (ALPHA=-5)................................105

vi

LIST OF FIGURES

Figure 1–1: General Ship Shape (GSS), CAD to Solution ........................................6 Figure 1–2: ROtor Body INteraction Fuselage Geometry (ROBIN) .........................9 Figure 1–3: ROBIN Wind Tunnel Model with General Rotor Model System (GRMS). Model was tests in a NASA Langley 14 by 22 foot subsonic Wing Tunnel ...............................................................................................................9 Figure 2–1: Structured Grid around NACA 0012 Rotor Blade..................................13 Figure 2–2: NACA 0012 Airfoil...............................................................................14 Figure 2–3: Side View of NACA 0012 Unstructured Grid........................................15 Figure 2–4: ROBIN Computation Volume with Source Terms.................................17 Figure 2–5: ROBIN Source Terms ...........................................................................17 Figure 2–6: ROBIN Geometry Unstructured Mesh...................................................20 Figure 2–7: ROBIN Grid Growth, Time Snap #1 .....................................................21 Figure 2–8: ROBIN Grid Growth, Time Snap #2 .....................................................21 Figure 2–9: ROBIN Grid Growth, Time Snap #3 .....................................................22 Figure 2–10: Aircraft Carrier Unstructured Mesh .....................................................23 Figure 2–11: AH-64 Apache Unstructured Grid .......................................................24 Figure 3–1: Categorization of Flow Solvers .............................................................26 Figure 3–2: Grid Flow Chart. From GridTool to PUMA..........................................34 Figure 4–1: ROBIN Geometry Experimental Pressure Tap Locations.......................37 Figure 4–2: Convergence History of ROBIN at Alpha=-5 ........................................38

vii Figure 4–3: Side View of ROBIN Pressure Tap Locations .......................................40 Figure 4–4: Cp, Alpha=0, X/R=0.0517 ....................................................................42 Figure 4–5: Cp, Alpha=0, X/R=0.0941 ....................................................................42 Figure 4–6: Cp, Alpha=0, X/R=0.1450 ....................................................................43 Figure 4–7: Cp, Alpha=0, X/R=0.2007 ....................................................................43 Figure 4–8: Cp, Alpha=0, X/R=0.3074 ....................................................................44 Figure 4–9: Cp, Alpha=0, X/R=0.3497 ....................................................................44 Figure 4–10: Cp, Alpha=0, X/R=0.4669...................................................................45 Figure 4–11: Cp, Alpha=0, X/R=0.6003...................................................................45 Figure 4–12: Cp, Alpha=0, X/R=0.8809...................................................................46 Figure 4–13: Cp, Alpha=0, X/R=1.0008...................................................................46 Figure 4–14: Cp, Alpha=0, X/R=1.1620...................................................................47 Figure 4–15: Cp, Alpha=0, X/R=1.3450...................................................................47 Figure 4–16: Cp, Alpha=0, X/R=1.5298...................................................................48 Figure 4–17: Cp, Alpha=-5, X/R=0.0517 .................................................................49 Figure 4–18: Cp, Alpha=-5, X/R=0.0941 .................................................................49 Figure 4–19: Cp, Alpha=-5, X/R=0.145 ...................................................................50 Figure 4–20: Cp, Alpha=-5, X/R=0.2007 .................................................................50 Figure 4–21: Cp, Alpha=-5, X/R=0.3074 .................................................................51 Figure 4–22: Cp, Alpha=-5, X/R=0.3497 .................................................................51 Figure 4–23: Cp, Alpha=-5, X/R=0.4669 .................................................................52 Figure 4–24: Cp, Alpha=-5, X/R=0.6003 .................................................................52 Figure 4–25: Cp, Alpha=-5, X/R=0.8809 .................................................................53 Figure 4–26: Cp, Alpha=-5, X/R=1.0008 .................................................................53

viii Figure 4–27: Cp, Alpha=-5, X/R=1.162 ...................................................................54 Figure 4–28: Cp, Alpha=-5, X/R=1.345 ...................................................................54 Figure 4–29: Cp, Alpha=-5, X/R=1.5298 .................................................................55 Figure 4–30: Streamlines at Alpha=0.0 ....................................................................56 Figure 4–31: Streamlines at Alpha=-5 ......................................................................57 Figure 4–32: Cp plot at Alpha=0.0 ...........................................................................58 Figure 4–33: Cp Plots at Alpha = -5 .........................................................................59 Figure 4–34: Mach number plots at Alpha=0.0.........................................................60 Figure 4–35: Non Dimensionalized Entropy at Alpha=0.0........................................61 Figure 4–36: Apache Convergence at Alpha=0.0......................................................62 Figure 4–37: Apache Pressure Coefficient at Alpha=0 .............................................63 Figure 4–38: Apache Mach Number at Alpha=0 ......................................................64 Figure 4–39: Apache Steamlines at Alpha=0............................................................65 Figure 4–40: Nosecone Apache Streamlines at Alpha=0 ..........................................66 Figure 4–41: Apache Engine Streamlines at Alpha=0...............................................67 Figure 4–42: Apache Entropy...................................................................................68 Figure 5–1: ROBIN viscous grid at rear of pylon (doghouse) ...................................70 Figure 5–2: Cp, Alpha=-5 at X/R=0.8809 .................................................................71 Figure 5–3: Pressure Contours on ROBIN @ Alpha=0.0..........................................71 Figure 5–4: Boeing General Helicopter Shape..........................................................77 Figure E–1: ROBIN Experimental Data @ Alpha=0 ................................................102 Figure F–1: ROBIN Experimental Data @ Alpha=-5 ...............................................105

ix

LIST OF TABLES

Table 3–1: PUMA vs CFL3D Comparison Table......................................................30 Table 5–1: Computational Algorithm vs Ability .......................................................72 Table 8–1: Fuselage Parameter for Equation 1-5.......................................................86 Table 8–2: Pylon (Doghouse) Parameters for Equation 1-5.......................................87

x

ACKNOWLEDGMENTS

I would like to thank my advisor Dr. Lyle Long for all his patience and support. Additionally, I would like to thank the United States Army and the United States Military Academy for providing this opportunity. I also want to thank Dr. Christopher Bruner and Anirudh Modi for providing personalized PUMA support. I extend special thanks Dr. John Berry and Dr. Ray Mineck for there help with the ROBIN generic helicopter shape. Sally Viken and Javier Garriz deserve special credit for training me to use the VGrid unstructured grid generator. Henry E. Jones deserves gratitude for providing the Apache geometry on extremely short notice. Special thanks to Dr. Anthony Pilon for his expert guidance on using TecPlot. This thesis is dedicated to my wife Wendy and my daughter Emma whose love and support made all this possible.

Chapter 1

MOTIVATION AND BACKGROUND

The flow field around helicopters is extremely complicated due to the characteristics of the airflow of a rotating system mixed with the fuselage flow field. Understanding and predicting flow around helicopters is becoming increasingly important as designers push for greater payloads and speed. Stealthy helicopters, such as the RAH-66 Comanche with faceted surfaces, will also demand intensive flow field investigation. The major complexity of the flow lies in the lifting surfaces (rotor) dynamic coupling with the flow field of the fuselage. Isolated rotor systems have been examined extensively, but few computational models accurately incorporate the effects of the helicopter fuselage. One of the most common problems in the flow field around a helicopter is the flow separating from the hub or hub fuselage area (pylon/doghouse). This separated flow then impinges on the tail rotor and other control surfaces. In a hovering flight profile the induced flow from the main rotor is the predominant factor but as forward airspeed increases the unsteady separated flow from the fuselage begins to influence the flow field. The unsteady separated flow from the fuselage can have several effects. The fuselage flow can directly effect the onset flow to the main rotor. A change in the onset flow can change the rotor systems vibratory excitations and response. This change in

2 rotor dynamics makes the study of isolated rotor system less than accurate. The same can be shown for the rotor interaction with the fuselage flow. The induced flow from the rotor system greatly alters the aerodynamic loading on the fuselage. [3] This complex flow involving rotor-fuselage interaction is a major source of structural fatigue, control problems, noise, and drag. A detailed solution of the rotorfuselage flow field is needed to increase the service life and performance of future helicopters.

1.1 Previous Work In 1979 Freeman and Mineck [3] took a large amount of experimental data over a helicopter fuselage with and without a rotor system. The data was taken to expand the data available to validate analytic models of the flow field around a helicopter fuselage. Freeman and Mineck did not analyze the data and only presented the test results. There were several studies conducted that utilized an isolated fuselage solution superimposed on a rotor wake solution to study the rotor wake-fuselage interaction. These approaches did not address the key non-linear effects present in a true rotor wakefuselage interaction. The isolated fuselage approaches did not properly address the effects the presence of a rotor system has on the fuselage flow [4]. These approaches also did not consider the effect that the fuselage would have on the onset flow to the rotor or the rotor wake distortion caused by the fuselage.[4] Dr. Berry [4] attempted to address these non-linearities with a fuselage panel solution that had a rotor and its wake modeled as elements of a vortex lattice. This

3 approach worked well at predicting the inflow velocities just above the rotor disk. The solution method, however, was laminar only and showed a great variance with experimental data in areas where separated flow would be expected.[4] The panel method used on the helicopter fuselage was also quite sensitive to the fidelity of the paneling. To address the problems associated with potential laminar solutions, Dr. Berry moved to the NASA Langley CFL3D flow solver. (For the capabilities of the CFL3D flow solver, see Chapter 3). Dr. Berry used the ROBIN body experimental data to validate his approach. He completed a good comparison of a potential theory panel method to a CFL3D Navier Stokes solution over an isolated ROBIN fuselage. The Navier-Stokes solution compared extremely well with the experimental data. The solution was however quite computationally expensive as CFL3D is a serial code that utilizes structured grids. Dr. Berry called for the need to introduce a complex lifting rotor and its wake to the solution [5]. Mohagna et al [6] introduced an unstructured grid approach to solving rotor flows. They used the ROBIN geometry with rotor as the basis for validation. They compared pressure coefficients along the advancing and retreating blades. The computed pressure coefficients compared well but their solution method was inviscid. The data did not compare well in areas of separated flow. A full viscous Navier-Stokes solution would be required to minimize these discrepancies. Also the rotor flow was assumed to be uniform. A rotor model that varies both in the radial and azimuthal directions would be required for more accurate predictions.

4 Duque et al [7] used the OVERFLOW flow solver to analyze the flow around the United States Army’s RAH-66 Commanche. The OVERFLOW flow solver uses the thin-layer Navier-Stokes for its predictions. OVERFLOW uses the Parallel Virtual Machine (PVM) language to distribute the compute load in parallel. PVM is not the standard for parallel communication and is generally not well supported. The viscous isolated fuselage solution compared well with the experimental data. The computational solution with a modeled main rotor did not compare favorably with experimental data. This clearly demonstrated the need for better rotor and rotor wake simulations. Ghee et al [8] completed an extensive rotor wake measurement study. Extensive wake measurement data was taken around the ROBIN. Berry and Bettschart completed a rotor-fuselage interaction study using the Dauphine helicopter [9]. The Rotor Wake Fuselage (RWI) and Programme d’Etude d’Interaction Rotor Fuselage (PEIRF) codes did reasonably well at predicting steady solutions with a complete rotor system and its interations with the fuselage. Neither did very well at capturing any of the unsteady attributes of the flow. They were particular poor at predicting the unsteady terms aft of the pylon and along the tailboom.

1.2 Method (from CAD Drawing to Solution) In order to speed investigations, a standard method was initiated to bring complex geometries easily from paper to final flow solution. ProEngineer was utilized as the design package to get geometries into a digital format. ProEngineer is a widely used

5 CAD package that is simple to use and allows a user to create complex geometries from simple 2-D drawings. Since the CAD package used is dependent on personal preference, the file transfer to a grid generator should be generic. The NASA Langley unstructured grid generator (VGRID) is designed to import files in the Initial Graphics Exchange Specification (IGES) which is the United States national standard for the exchange of data between dissimilar CAD systems. To export files in the appropriate IGES format, the exporter file in Appendix A was utilized. The United States Navy’s General Ship Shape (GSS) was utilized as a proof of concept. The GSS is a standard shape set forth by the United States Navy as a geometry to be used to compare flow solvers. The GSS represents a United States Navy frigate with the area of interest being the flow field on the aft deck. The aft deck primarily acts as a landing area for helicopters. The turbulent, separated flow cause by the ship structure can make landing a helicopter extremely difficult. The strong unsteady flows can also cause severe blade deformation during start up and shut down of a helicopter. This GSS geometry unstructured grid and solution was completed in conjunction with the Pennsylvania State University Ship Airwake Studies [10].

6

Figure 1–1: General Ship Shape (GSS), CAD to Solution

1.3 Robin Body The Rotor Body Interaction Fuselage (ROBIN) was utilized to validate the capabilities of the Parallel Unstructured Maritime Aerodynamics (PUMA) flow solver. The ROBIN is a generic rotorcraft fuselage shape that has been extensively tested in wind tunnels. A large amount of experimental data exists for the ROBIN shape. The ROBIN

7 shape has also had several computational studies completed on it with a variety of grids and flow solvers. [5].

The ROBIN shape is mathematically derived from super-ellipse equations [3]. For a given fuselage station of X, the cross section (Y and Z) are defined by height (H), width (W), camber line (Z0), and elliptical power (N) A super ellipse is defined by the elliptical equation:

n

m

 x + x0   y + y0    +  =C  A   B 

( 1.1 )

Solving equation 1.1 for y (x) yields:

1

n m   x + x0   y = F ( x ) = B C −    − y0  A   

( 1.2 )

Expanding the x term of equation 1.2 and substituting m=C8, y0=-C6, B=C7, C=C1 and X=x yields:

 X + C3   x + x0   − → + C 2     A   C4  n

C5

( 1.3 )

1

C5   X + C 3   C8   F ( X ) = C 6 + C 7 C 1 + C 2    C 4  

( 1.4 )

8 Equation 1.4 can be used to calculate H, W Z0 and N as functions of X by selecting the appropriate constants from table B-1 in Appendix B. Transforming equation 1.2 into polar coordinates and apply these constant relationships, C=1 and n=m=N yields:

1

 N ( AB )N r= N N   ( A sin φ ) + ( B cos φ ) 

( 1.5 )

By using equation 1.5, the shapes Cartesian coordinates may be obtained for φ = 0 to 2π by substituting A=H/2, B=W/2 and N obtained from equation 1.4. An F-77 program that generates the ROBIN geometry can be found in Appendix C. This F-77 program uses equations 1.2, 1.5 and table B-1 to create a plot3D file that can easily be imported into numerous automated grid generators. The ROBIN Body was not created using ProEngineer, however, the ROBIN can be modified in Pro Engineer then recomputed.

9

Figure 1–2: ROtor Body INteraction Fuselage Geometry (ROBIN)

Figure 1–3: ROBIN Wind Tunnel Model with General Rotor Model System (GRMS). Model was tests in a NASA Langley 14 by 22 foot subsonic Wing Tunnel

10 1.4 Flow Solvers Today there are a wide variety of commercial and research computational fluid dynamics (CFD) flow solvers. Each flow solver has its own unique features that make it applicable to certain types of geometries and flow solutions. Some of these features are method of time integration, turbulence models, grid structure, and memory/processor distribution. One of the predominant CFD flow solvers is CFL3D, which was written at NASA Langley. CFL3D is a Reynolds-averaged thin-layer Navier-Stokes flow solver for structured grids. While CFL3D is fairly robust, it does have several shortcomings when attempting to solve flow around complex geometries. The three most significant problems with CFL3D are that it is a serial code, it uses structured grids and it is only equipped with one time integration scheme. PUMA is a fairly new solver that was developed by Dr. Chris Bruner as part of his doctoral work [1]. PUMA is a parallel, unstructured grid solver that offers several different time-integration methods. PUMA was written to conduct a comparison of different time integration methods on parallel computers.

1.5 Thesis Scope The purpose of this work was to explore the possibility of using PUMA as a steady state solution as an input to the Nonlinear Disturbance Equations (NLDE) method in order to predict the unsteady separated flow associated with helicopter fuselages. The

11 results from PUMA will be compared with experimental wind tunnel pressure data. This basic work is merely the beginning of a project to apply NLDE to a helicopter fuselage with a full rotor system. This would allow an accurate prediction of the flow field including all fuselage-rotor interactions. Chapter 2 delves into unstructured grid generation. A brief explanation of NASA Langley’s unstructured grid generator VGRID will be presented. With the development of simple-to-use unstructured grid generators the amount of time spent generating the grid can be drastically reduced. This simplification of the discretization of complex geometries will improve the capability of CFD as a design tool [11]. Several examples of generated unstructured grids will be presented. A detailed comparison of PUMA and CFLD3D features will be presented in Chapter 3. This includes a discussion of why PUMA is the better choice for a NLDE preprocessor. The computational results of ROBIN using PUMA will be presented in Chapter 4. These results will be compared to experimental wind tunnel pressure data. Chapter 4 also includes an explanation of PUMA and the computers that were utilized. Suggested future work will be presented in Chapter 5. This will include a discussion of NLDE and k-exact reconstruction. The future work section is quite lengthy, as this thesis is stage one of a three-stage project. Finally, Chapter 6 presents conclusions that can be drawn from the flow solutions.

12

Chapter 2

GRID GENERATION

Before any numerical solution can be computed, the physical domain must be covered with a computational grid. The grid must be constructed in a way to accurately preserve the geometry of interests while providing the proper resolution for the algorithm to be applied. The two major categories of grid construction are structured grids and unstructured grids. Each type of grid has its own particular advantages and disadvantages. Structured grids are easier to handle computationally because their connectivity information is stored block to block. Structured grids are however more difficult to construct and tend to waste memory with unnecessary cells in the far field. Unstructured grids are more difficult to handle computationally because their connectivity is stored for each node. Unstructured grids, however, tend to be easier to construct and can waste memory in far field cell resolution [12]. Figure 2–1 shows a structured gird around an NACA 0012 Rotor Blade. This grid was generated as part of the Pennsylvania State University Rotorcraft Center of Excellence’s investigations into rotor tip vortices. Figure 2–1 clearly demonstrates how structured grids can waste cells in the far field. At the root and tip of the NACA 0012 there is a heavy concentration of cells to provide the resolution necessary to capture the full wake structure. These fine cells are carried all the way to the edge of the

13 computational boundary in all directions. Figure 2–2 and Figure 2–3 show an NACA 0012 airfoil with an unstructured grid. This grid was created to capture vortices at fivedegrees angle of attack. This is shown by the concentration of cells in the know vortex area. This clearly demonstrates how unstructured grids can concentrate cells in areas of interest, thus allowing for large computational problems to be examined. Given the complex nature of helicopter flow problems, the unstructured approach offers the best opportunity to quickly, accurately and effectively obtain flow solutions.

Figure 2–1: Structured Grid around NACA 0012 Rotor Blade

14

Figure 2–2: NACA 0012 Airfoil Inviscid grid: 41,013 nodes, 456382 faces, 226,030 cells Approximately 446 MB memory required in double precision mode

15

Figure 2–3: Side View of NACA 0012 Unstructured Grid

16

2.1 VGrid Unstructured Grid Generator The unstructured grids created around the ROBIN were generated using the advancing front method grid generator VGrid [11]. The ViGYAN Company in association with the NASA Langley Research Center created VGrid as a method of quickly and easily generating grids around complex objects. VGrid is a fully functional; user oriented unstructured grid generator. GridTool is the program that acts as a bridge between Computer Aided Design (CAD) packages and grid generation in VGrid [13]. The typical process involves first completing a drawing of the geometry of interest in a CAD package. This geometry is then exported from the CAD package in an IGES format as specified in Appendix A. GridTool can then prepare the geometry for grid generation. GridTool simply provides VGrid with a complete and accurate definition of the geometry [13]. This is accomplished by specifying curves along the geometry and then turning these curves into unique surface patches that define the geometry. Source terms are then added to the computational domain, which will provide VGrid with the starting information for the grids in the advancing front. The source terms can be freely placed anywhere in the domain and allow the user to very specifically focus the growth of the future grid. Figure 2–4 and Figure 2–5 show the ROBIN geometry inside GridTool. The large distributed tetrahedrons are the source terms that will define the grid growth.

17

Figure 2–4: ROBIN Computation Volume with Source Terms

Figure 2–5: ROBIN Source Terms

18 VGrid takes finished GridTool files and uses them as the basis for the unstructured advancing front grid growth [14]. VGrid’s first step is to create a surface mesh based on the provided surface patches and source terms (Figure 2–6) The source terms specified in GridTool can be considered simple heat sources. The spatial variation in the grid is then determined by computing the heat diffusion from the discrete heat sources. The heat equation is solved using a Gauss-Seidel iterative scheme with an applied successive over-relaxation. A complete explanation of the equations and method can be found in several papers presented by Dr. Shahyar Pirzadeth [11, 15, 16]. The advancing front grows from the smallest source terms outward. The heat diffusion is calculated, then one layer of the grid front is grown. This iterative process is continued until the entire domain is filled. Figures 2–7, 2–8 and 2–9 show a sample of the grid growth on the ROBIN geometry. The finest source terms were located at the aft end of the ROBIN hub pylon so grid growth began first at this location. As the iterative process continues, the entire ROBIN is covered with growing grids (Figure 2–9). VGrid is capable of generating an automatic viscous layer for Navier-Stokes algorithmic solutions. This option is turned on with a simple flag in GridTool. When the viscous flag is active, VGrid creates small layers of prisms all along the surface of the given geometry [15]. These prisms completely and uniformly cover all surfaces making this an extremely easy way to make any grid a viscous grid. VGrid determines the number of viscous prism layers from the complexity of the shape. All solutions presented in this thesis were computed on inviscid grids. A sample viscous ROBIN grid is presented in Chapter 5.

19 VGrid is extremely versatile and can be used to generate grids around almost any shape. An unstructured grid was created around a United States aircraft carrier for the Pennsylvania State University Ship Airwake Study [10]. The aircraft carrier geometry was provided by Steven Kern at Patuxent River Naval Research Center. An Apache AH64 helicopter was also completed to begin studying more complex helicopter fuselage shapes. The Apache geometry was provided by Henry E. Jones, U. S. Army Aviation & Missile Command, Aeroflightdynamics Directorate, Joint Program Research Office NASA Langley Research Center.

20

Figure 2–6: ROBIN Geometry Unstructured Mesh Inviscid grid: 49,662 nodes, 532492 faces, 260,858 cells Approximately 606 MB memory required in double precision mode

21

Figure 2–7: ROBIN Grid Growth, Time Snap #1

Figure 2–8: ROBIN Grid Growth, Time Snap #2

22

Figure 2–9: ROBIN Grid Growth, Time Snap #3

23

Figure 2–10: Aircraft Carrier Unstructured Mesh Inviscid grid: 89,605 nodes, 974150 faces, 478,506 cells Approximately 1,090 MB memory required in double precision mode

24

Figure 2–11: AH-64 Apache Unstructured Grid Inviscid grid: 101,377 nodes, 1,125,596 faces, 555,772 cells Approximately 1,246 MB memory required in double precision mode

Chapter 3 FLOW SOLVERS

There are currently a wide variety of commercial and semi-commercial flow solvers available for researchers and designers. Most modern flow solvers incorporate many algorithms and functions that allow them to be applied to a wide assortment of problems. Flow solvers can be broadly categorized by their computational implementation and refined by the particular algorithmic schemes utilized for solution. Flow solvers can be categorized as either Parallel or Serial. Serial flow solvers execute on only one processor and are limited to the memory available on that one processor. Parallel codes distribute the computational load across several processors. This means that a parallel code generally computes faster and can handle larger problems since the data is distributed across several processors. Flow solvers can further be categorized by the grid structure that they utilized to describe the physical domain. In general, flow solvers can accommodate structured or unstructured grids. Structured grids have highly ordered connectivity schemes that are stored from block to block. Structured grids are easier to handle computationally but tend to be difficult to construct when analyzing a complex shape. In unstructured grids the connectivity of the nodes is stored cell to cell. Since each cell contains connectivity information there can be significant overhead costs in a solver that uses unstructured grids. Unstructured grids, however, do allow a complex shape to be easily be modeled.

26 The grid type is independent of the algorithmic scheme (parallel or serial). Figure 3–1 shows the basic classification of flow solvers.

Flow Solvers

Parallel

Structured

Serial

Unstructured

Structured

Unstructured

Grids

Grids

Grids

PUMA

CFL3D

Figure 3–1: Categorization of Flow Solvers

3.1 CFL3D versus PUMA To begin an earnest effort to accurately model the unsteady separated flow from a helicopter fuselage a flow solver had to be selected. Chaffin and Berry [5] utilized the extremely popular CFL3D flow solver for their investigation into separated flow around helicopter fuselages. Currently, the primary developers/supporters of CFL3D are Dr. Christopher L. Rumsey and Dr. Robert T. Biedron of the Aerodynamics and Acoustics

27 Branch at NASA Langley. CFL3D predicted the fuselage flow sufficient well for the study of viscous properties near the fuselage. CFL3D however did not capture the separated flow in the detail needed for a study of rotor fuselage interactions. PUMA (Parallel Unstructured Maritime Aerodynamics) is a relatively new flow solver that was developed by Dr. Christopher Bruner [1]. PUMA was untested at solving large problems around complex shapes, but PUMA offers many key advantages over CFL3D and other flow solvers. Table 3–1 compares the features of CFL3D and PUMA [17, 1]. CFL3D is a serial code that utilizes structured grids while PUMA is a parallel code that uses unstructured grids. The parallelization of PUMA and the fact that it uses unstructured grids are the two most important advantages that PUMA has over CFL3D. A parallel code offers many advantages over a serial code. In a parallel code the domain is decomposed and distributed across several processors. This distribution allows parallel codes to handle much larger problems than their serial counterparts. In a large computational domain, the grid points are distributed amongst the various processors allowing meshes of tens of millions of grid points. Since the computational load is also distributed, parallel codes also tend to converge much faster than serial codes. This is, of course, only true if communication times between the processors are kept to a minimum. Currently programmers at NASA Langley are working on parallelizing CFL3D but at this time it is not available. PUMA uses an unstructured mesh while CFL3D utilizes a structured mesh. Today’s unstructured mesh generators are extremely easy to use and nearly automatic.

28 The use of unstructured meshes greatly decreases the amount of time spent generating appropriate meshes. Unstructured meshes unlike structured meshes also eliminate needless grid points in the far field. By easily concentrating cells around appropriate areas and not other, extremely complex shapes can be grided quickly, easily and with the fewest possible nodes. Both PUMA and CFL3D are 2nd order accurate. Neither PUMA nor CFL3D currently implement a k-exact method to improve their order of accuracy. PUMA offers a wide variety of time integration schemes while CFL3D utilizes only the ADI. This makes PUMA much more versatile since ADI schemes are slow to converge on certain problems and ADI is not well suited for unsteady problems. PUMA was originally written to conduct a comparison of various time integration schemes on parallel computers. Dr. Christopher Bruner concluded that the best performing algorithm in PUMA is dependant upon the communication network utilized by the computer system. The presence of all the algorithms in the PUMA code allows individual researchers to determine which algorithm is most appropriate for their particular needs. In this way, PUMA, unlike CFL3D offers a large amount of flexibility for different problems and circumstances. PUMA does not have the robust turbulence modeling that is present in CFL3D. The lack of good turbulence modeling is not a large issue since it can be added to PUMA. The ease of the additional turbulence models stem from the relatively small size of the PUMA code. PUMA is around 10,000 lines of code while CFL3D is 100,000 lines of code. This order of magnitude difference makes it much easier for anyone to learn,

29 understand and modify PUMA. Also of importance is that PUMA is written in C while CFL3D is in F77. With the F90 standard implemented and F95 on the way, it will not be long before CFL3D will need to be drastically updated to work with modern compilers. While F77 remains the standard due to a large portion of legacy flow solver, the momentum is gradually shifting toward lightweight, highly portable C codes. This brief comparison of PUMA and CFL3D makes it clear that PUMA offers a much better starting point for capturing rotor wake helicopter fuselage interaction. There are many other flow solvers that were not considered due to their lack of portability, limited usefulness in the area of separated flow or their extreme complication. PUMA’s simplistic, small, parallel, unstructured approach is ideal for quick modifications for almost any external flow solution need.

30

Table 3–1: PUMA vs CFL3D Comparison Table

Parallel Multigrid Unstructured Grids Structured Block Grids Order of Accuaracy

CFL3D

PUMA

N Y N Y 2nd

Y N Y N 2nd

N N N N N N Y

Y Y Y Y Y Y N

Y Y Y Y Y Y Y Y Y

N N Y Y N N N N N

Y Y 100K F-77 Y

Y Y 10K C/MPI Y

Time Integration Scheme Runge-Kutta Gauss Seidel Jacobi RSOR FSOR SSOR ADI

Turbulence Models Baldwin-Lomax Baldwin-Barth Spalart-Allmaras Wilcox k-Omega Menter’s k-Omega Abid k-Epsilon Speziale-Gatski k-Omega Speziale-Gatski k-Epsilon Girimaji k-Epsilon Upwind Compressible Lines of Code Programming Language Portable

31 3.2 PUMA PUMA is a finite volume flow solver that supports mixed topology unstructured grids. PUMA is written entirely in ANSI C using the MPI library for message passing. The use of MPI for communication makes PUMA a highly portable code. PUMA utilizes dynamic memory allocation, thus problem size is only limited by the amount of memory. [1] The MPI paradigm distributes the problem’s data across several processors. Each processor only has access to its own local data. To access non-local data a small message must be passed between the requesting processor and the processor that owns the data. This approach is applicable to all parallel architecture computers, including both shared and distributed memory machines. For PUMA, each compute node reads its own portion of the grid at startup. At compute node interfaces, cell values are duplicated on each processor node. At the end of each iteration, solution variables are updated via communications between compute nodes that interface. Because of these communications, the performance of any MPI code is highly dependent on how the data is distributed. The distribution of data to the processors is dependent on the domain decomposition. Since the domain decomposition greatly effects the performance of an MPI code, it is important to look at what affects the communication times between two processors (equation 3.1) [1].

32 C = Latency + message size/Communication Bandwidth Where C = Communication Time

( 3.1 )

The PUMA code merely reads the entire grid in a specific fixed order and then gives equal consecutive chunks of it to every processor. Each grid should be preprocessed to ensure that it is optimally decomposed. If the grid is not optimized, PUMA will assign cell faces to processors in a random fashion, which could drastically increase the number of necessary communications. In order to minimize communications interconnected cell faces should be assigned to the same processors. The PUMA package includes a small utility (gps) which employs a Gibbs-Poole-Stockmeyer algorithm to optimally align the grid [18]. This algorithm is completely independent of the number of processors that are being utilized. This GPS approach to domain decomposition focuses on the first term of equation 3.1. Latency is the amount of time required to send a message of zero bytes. It is simply the overhead cost of sending a message. In this approach the number of communications between the processors is minimized [1]. By minimizing the number of communications the total communication overhead (latency) is minimized. This approach works extremely well for parallel machines that possess poor latency times. To address issues involving the second term of equation 3.1, the grids can be preprocessed by another code to optimize the grid structure based on the number of processors to be utilized. This optimization of the gird is not trivial and must be completed each time the grid is computed on a different number of processors [18].

33 Currently, it is not felt that this optimization is necessary or would offer significant improvements. PUMA includes several utilities for importing formatted grids from VGrid/PostGrid. The “fromvgrid” utility takes the formatted files from VGrid (.int, .grd, .bc, and .mapbc) and produces a .sg file. The .grd file is the file that contains the x,y,z coordinates of each node in the volume while the .int file contains the connectivity data of each of the tetrahedrons in the volume [19]. This grid file can then be optimized with the GPS utility. Following this optimization the grid is ready to be utilized by PUMA. See Figure 3–2 for a flow chart of how a grid moves from GridTool to an input file for PUMA. A sample of PUMA’s input file is in Appendix D. The input files for PUMA are simple and intuitive. PUMA supports a multitude of boundary conditions. The codes for the available boundary conditions are also included in Appendix D.

34

Figure 3–2: Grid Flow Chart. From GridTool to PUMA

Chapter 4 COMPUTATIONAL RESULTS

4.1 Computers Utilized The ROBIN calculations were conducted on two separate Personal Computer clusters, which were constructed by the Pennsylvania State University Institute for High Performance Computing Applications [20]. The first cluster was nine Pentium II 266 MHz computers running Solaris with MPI. This was an experimental cluster built as a proof of concept. The second personal computer cluster was twenty-five dual processor Pentium II 400 MHz computers running Linux with MPI [21]. PUMA performed extremely well on both clusters. Both personal computer clusters were linked together using Fast Ethernet. The use of Fast Ethernet did not drastically effect the communication times of PUMA. The personal computer clusters use distributed memory so each compute node has its own local memory. In the first cluster of the 266 MHz PCs, each processor had its own local RAM and was connected to the other compute nodes with a dedicated Fast Ethernet. Each processor had 256 Megabytes of RAM available. In the second cluster, the PCs were dual processor PCs. This means some of the compute nodes used the same physical RAM but it was divided into individual virtual local RAM. This also means that

36 the processors are physically located together in the same tower utilized the PC bus system for communications. The second PC cluster also utilized a dedicated Fast Ethernet network for communications. Each SMP node in this cluster had 512 Megabytes of RAM available.

4.2 Robin Experimental Data Freeman and Mineak [3] conducted extensive wind tunnel tests of the ROBIN geometry in 1979. They measured the time-averaged fuselage surface pressures of the ROBIN geometry with 3.15-meter diameter, four bladed articulated rotors. Pressure data was also collected without the rotor system. The wind tunnel data was acquired at a Mach number of 0.062 and an effective Reynolds number of 4.46 x 106 with a threemeter model. This time-averaged pressure data was utilized to validate the results of the ROBIN flow solutions as computed by PUMA. Tabular forms of the experimental data are located in Appendix D and Appendix F. The pressure data was gathered from pressure taps located along the fuselage of the ROBIN geometry. Figure 4–1 shows the location of the pressure taps. It should be noted that no pressure taps were located on the hub pylon cover. The wind tunnel investigation was conducted at NASA Langley’s V/STOL closed return atmospheric tunnel.

37

Figure 4–1: ROBIN Geometry Experimental Pressure Tap Locations

38

4.3 ROBIN Results The ROBIN body inviscid flow solutions were calculated at both a zero degree and a five-degree nose down angle of attack. All computational solutions were performed at a Mach number of 0.3. This high Mach number was utilized to avoid numerical stiffness since currently PUMA does not have any preconditioning. The ROBIN solutions are currently only inviscid. All computer runs were completed on the above mentioned clustered computers and converged in under 1,000 iterations (Figure 4– 2).

Figure 4–2: Convergence History of ROBIN at Alpha=-5

39

The computed pressure coefficients were compared to experimental data at stations along the vertical coordinate of the ROBIN geometry. These stations correspond to the experimental pressure tap locations shown in Figure 4–1 . The PUMA results compare reasonably well with the experimental results at most stations (Figure 4– 4 thru 4–16 for zero angle of attack and Figures 4–17 thru 4–29 for five-degrees nose down). The PUMA results begin to vary from experimental data at stations where flow separation is expected. Separation would be expected to occur from station X/R=0.8809 and aft. These discrepancies can be noted in Figures 4–12 thru 4–16 for the zero angle of attack case and in Figures 4–25 thru 4–29 for the five-degree nose down case. The largest discrepancies occur at the top ROBIN main fuselage along the hub pylon cover near Z/R=0.125.

The large discrepancies occur here because the top of the

fuselage at the aft end of the hub pylon is an area where highly separated flow is expected. Since the PUMA ROBIN solutions are currently only inviscid, these discrepancies are expected. There were no experimental pressure taps on the hub pylon cover but given the nature of the separated flow it can be assumed that the discrepancies would also exists along the top of the pylon. There is better agreement in the aft section along the side of the ROBIN since this is not an area of highly separated flow. The effects of the separated flow can clearly be seen by examining the differences between the zero degree and five-degree nose down cases. In the zero degree case, station X/R=0.8809 (Figure 4–12) agrees well since separation has not yet occurred. In 5 degree

40 nose down case, station X/R=0.8809 (Figure 4–25 ) does not agree well since the separation point has moved forward.

Figure 4–3: Side View of ROBIN Pressure Tap Locations

Figures 4–30 and 4–31 show the streamlines along the ROBIN geometry from the VSAERO panel method, CFL3D and PUMA. The VSAERO and CFL3D images where scanned from Chaffin et al [5]. Figure 4–30 and Figure 4–31 clearly demonstrate that both the VSAERO and PUMA are inviscid solutions. The VSAERO and PUMA streamlines strictly follow the contours of the ROBIN and do not converge or cross. The CFL3D streamlines reflect a viscous solution and it does capture the flow separation areas. The streamlines in these figures are limited to the surface of the ROBIN. In both PUMA solutions, it is obvious by the continuous streamlines that the current solutions do not capture the separation points or the associated vortical flow. Three-dimensional Cp plots (Figures 4–32 and 4–33 ) are included for reference with the XY plots (Figure 4–4 thru Figure 4–29). The computations were conducted at

41 Mach 0.3. A Mach number plot (Figure 4–34) is presented to verify that no transonic flow is occurring. The current PUMA solutions are inviscid so there are no shock waves. The solution should reflect a flow that is isentropic, but Figure 4–35 clearly shows that the solution is not isentropic. These variances are due to the implicit and explicit artificial viscosity induced by the algorithms [22]. The artificial viscosity produces some dissipation, which causes the entropy variation in the flow field. The entropy variation is concentrated in regions near the solid walls. These variations could be significantly reduced with mesh refinement at the boundary areas.

42

Figure 4–4: Cp, Alpha=0, X/R=0.0517

Figure 4–5: Cp, Alpha=0, X/R=0.0941

43

Figure 4–6: Cp, Alpha=0, X/R=0.1450

Figure 4–7: Cp, Alpha=0, X/R=0.2007

44

Figure 4–8: Cp, Alpha=0, X/R=0.3074

Figure 4–9: Cp, Alpha=0, X/R=0.3497

45

Figure 4–10: Cp, Alpha=0, X/R=0.4669

Figure 4–11: Cp, Alpha=0, X/R=0.6003

46

Figure 4–12: Cp, Alpha=0, X/R=0.8809

Figure 4–13: Cp, Alpha=0, X/R=1.0008

47

Figure 4–14: Cp, Alpha=0, X/R=1.1620

Figure 4–15: Cp, Alpha=0, X/R=1.3450

48

Figure 4–16: Cp, Alpha=0, X/R=1.5298

49

Figure 4–17: Cp, Alpha=-5, X/R=0.0517

Figure 4–18: Cp, Alpha=-5, X/R=0.0941

50

Figure 4–19: Cp, Alpha=-5, X/R=0.145

Figure 4–20: Cp, Alpha=-5, X/R=0.2007

51

Figure 4–21: Cp, Alpha=-5, X/R=0.3074

Figure 4–22: Cp, Alpha=-5, X/R=0.3497

52

Figure 4–23: Cp, Alpha=-5, X/R=0.4669

Figure 4–24: Cp, Alpha=-5, X/R=0.6003

53

Figure 4–25: Cp, Alpha=-5, X/R=0.8809

Figure 4–26: Cp, Alpha=-5, X/R=1.0008

54

Figure 4–27: Cp, Alpha=-5, X/R=1.162

Figure 4–28: Cp, Alpha=-5, X/R=1.345

55

Figure 4–29: Cp, Alpha=-5, X/R=1.5298

56

Figure 4–30: Streamlines at Alpha=0.0

57 Figure 4–31

Figure 4–31: Streamlines at Alpha=-5

Figure 4–32: Cp plot at Alpha=0.0

59

Figure 4–33: Cp Plots at Alpha = -5

60

Figure 4–34: Mach number plots at Alpha=0.0

61

Figure 4–35: Non Dimensionalized Entropy at Alpha=0.0

4.4 Apache Results The AH-64 Apache geometry flow solution was computed to verify PUMA’s ability to solve for the flow over extremely complex shapes. There is currently no experimental data available to use as a comparison to these results. The Apache solutions are all inviscid. The Apache solutions where computed at a zero angle of attack and a Mach number of 0.3. The Apache solution converged in 4500 iterations in 350 hours on 8 P266 MHz processors (Figure 4–36). The Apache solutions presented are the Pressure Coefficient (Figure 4–37), Mach Number (Figure 4–38 ), streamlines (Figures 4–39 thru Figure 4–41 ) and non-dimensionalized entropy (Figure 4–42 ). The Apache inviscid grid had 101,377 nodes, 1,125,596 faces, and 555,772 cells. The grid required approximately 1,246 MB with double precision. The Apache geometry was provide by Henry E. Jones, U.S. Army Aviation Missile Command, Aeroflightdynamics Directorate, Joint Program Research Office, NASA Langley Research Center.

62

Figure 4–36: Apache Convergence at Alpha=0.0

63

Figure 4–37: Apache Pressure Coefficient at Alpha=0

64

Figure 4–38: Apache Mach Number at Alpha=0

65

Figure 4–39: Apache Steamlines at Alpha=0

66

Figure 4–40: Nosecone Apache Streamlines at Alpha=0

67

Figure 4–41: Apache Engine Streamlines at Alpha=0

68

Figure 4–42: Apache Entropy

69

Chapter 5

FUTURE WORK

This investigation of the ROBIN body was a preliminary investigation to determine the suitability of PUMA to eventually solve the flow around a helicopter fuselage with main rotor effects. In order for PUMA to be useful for capturing the unsteady separated flow and rotor-fuselage interaction several modifications should be investigated.

5.1 Viscous Robin The ROBIN solutions that were compared to experimental data were all inviscid solutions. The Euler equations in PUMA were utilized for all solutions. Since the Euler solutions neglect viscous effects, separated flow is not accurately captured. PUMA does include a Reynolds Averaged Navier Stokes (RANS) algorithm. The ROBIN viscous grid has already been generated (Figure 5–1) and a viscous flow solution should be calculated soon. The viscous grid was generated using the viscous option in GridTool/Vgrid. This is readily apparent by the prismatic layers that were generated on the surface of the ROBIN. PUMA’s viscous solution method is RANS, which should capture some of the separated flow but most likely not accurately enough to study rotor-

70 fuselage interaction. All of the ROBIN meshes are extremely coarse and will require refinement for better results once PUMA is modified as detailed in this chapter.

Figure 5–1: ROBIN viscous grid at rear of pylon (doghouse)

5.2 Nonlinear Disturbance Equations PUMA’s current algorithms do not accurately capture the unsteady separated flow. This is clearly demonstrated by the computed solution on the tail section of ROBIN not agreeing well with experimental data (Figure 5–2). It is also apparent from the pressure contour plots (Figure 5–3). To accurately capture the rotor-fuselage flow interaction a scheme must be implemented to fully capture the unsteady separated flow from the helicopter fuselage.

71

Figure 5–2: Cp, Alpha=-5 at X/R=0.8809

Figure 5–3: Pressure Contours on ROBIN @ Alpha=0.0

72 The Nonlinear Disturbance Equations have the potential of capturing the unsteady separated flow in enough detail to allow a study of rotor-fuselage interaction. Table 5-1 shows the capabilities of the most common solution algorithms. Currently both CFL3D and PUMA use the Reynolds Average Navier-Stokes method. NLDE is essentially a combination of RANS and LES [23] NLDE captures the essential nonlinear and linear fluctuation terms with high accuracy. These fluctuations are beyond the capability of the standard RANS models. NLDEs higher order accuracy will reduce numerical round off associated with problems that exhibit a wide range of scales. NLDE also exhibits superior dispersion and dissipation characteristics eliminating any numerical artificial phenomenon [23]. Table 5–1: Computational Algorithm vs Ability Non-Linear

Vorticty Transport

Viscous

Turbulence

Inhomogeneous Turbulence

All Scales

DNS

X

X

X

X

X

X

NLDE

X

X

X

X

X

LES

X

X

X

X

X

RANS

X

X

X

X

Laminar NS

X

X

X

Euler

X

X

Full Potential

X

(CFL3D, PUMA)

The nonlinear disturbance equations are obtained from the full time-dependant Navier-Stokes equations [2]. Equation 5.1 is the three-dimensional Navier-Stokes equation in Cartesian coordinates.

73 ∂q ∂F ∂G ∂H + + + =0 ∂t ∂x ∂y ∂z

( 5.1 )

The vector q is the flow vector of the conserved variables The terms F,G and H are the flux terms. A simple explanation of NLDE begins by splitting the flow vector q into its mean term (q0) and its perturbation term (q/).

1 q = q0 + q ′, q0 = lim T →∞ T

t0 +T

∫ q( t )dt

( 5.2 )

t0

Substitution of equation 5.1 into equation 5.2 and by reorganizing the mean flow and perturbation terms, the nonlinear disturbance equations become equation 5.3. ∂q ′ ∂F ′ ∂G ′ ∂H ′ + + + =Q ∂t ∂x ∂y ∂z

( 5.3 )

The left-hand side of equation 5.3 represents the perturbation and cross terms. In equation 5.3, Q represents terms involving purely mean flow quantities and thus are treated solely as a source term. The mean flow source term is defined by equation 5.4 ∂G 0 ∂H 0  ∂F Q = − 0 + + ∂ x ∂ y ∂z 

  

( 5.4 )

For a complete explanation of the nonlinear disturbance equation derivation see Morris et al [2]. The NLDE approach will allow the use of the most appropriate algorithm for each portion of the physics. The mean flow can be determined by any validated CFD solver. The mean flow solution can then be used as a primer for NLDE, which will resolve the

74 unsteady flow. Unsteady flows require much finer meshes for the time marching, explicit algorithm. By separating the mean flow solution from the unsteady algorithm the grid resolution can be adjusted to be appropriate for each. The steady solution can use a relatively coarse mesh while a finer mesh can be utilized for the unsteady solution. The NLDE approach has proven successful in several applications. NLDE’s most notable successes lie in jet noise simulations [24] and engine inlet liner simulations [25]. Both of these applications of NLDE have compared very well with experimental data. The jet noise and engine linear solutions both used a proven RANS flow solver to determine the mean flow, which was then used by NLDE. Both of these applications, however, use a structured grid approach with fourth order spatial solvers. The application of NLDE to an unstructured mesh may present some different problems.

5.3 Preconditioning All of the ROBIN test cases were conducted at a relatively high Mach number. Low speed flow can cause stiffness in the governing equations. This stiffness is caused when the ratio of the convective speed to the speed of sound is quite small. This can be best understood by examining the eigenvalues of the Euler equations (u, u+c, u-c). This will lead to large errors or slow convergence in the flow solution when applying an iterative method. This stiffness problem can be solved by the inclusion of a preconditioner. This simply consists of the addition of a transformation matrix to put the coefficient matrix into a more favorable invertible matrix form [27]. If Ax=b is the stiff system of

75 equations a preconditioning matrix Q can be easily applied. The new system of equations would then become Q-1Ax=Q-1b. This new system of equations would be easier to solve, converge faster and produce more accurate results at low Mach numbers.

5.4 K-Exact Reconstruction It has been shown that higher order solvers can be much more efficient than lower order solvers. A 4th order accurate method can be 50-100 times more efficient than a 2nd order method. Due to the nature of unstructured grids, unstructured flow solvers tend to be 2nd order accurate in both time and space. Accuracy in flow solvers that use unstructured grids can be great improved be implementing a local refinement scheme. PUMA is currently a 2nd order accurate finite volume flow solver that could be significantly improved by implementing a higher order accurate approximation. This can be implemented through a reconstruction technique know as k-exact [26]. Reconstruction consists of determining the point-wise variation of the flow field variables from the cell averages with the restriction that integrating the point-wise function recovers the cell averages [26]. Since the flow variables are known at the center of each tetrahedron a control volume of x cell centers can be constructed. The flow variables in the control volume can then be approximated by a polynomial of degree k (equation 5.5).

k

k − i k −( i + j )

P k ( x , y, z ) = ∑ ∑ i =0 j = 0

∑C k =0

i , j ,k

xi y j zl

( 5.5 )

76 This polynomial (equation 5.5) satisfies a criteria call k-exactness. K-exactness means that a polynomial of degree k recovers the cell average correctly. In a threedimensional case the polynomial contains [(k+1)(k+2)(k+3)]/6 coefficients. In onedimension the polynomial would contain k+1 coefficients while a two-dimensional case would contain [(k+1)(k+2)]/2 coefficients. P 1 = C 0 + C1 x + C 2 y + C 3 z

( 5.6 )

This system can then be solved for P1. 1  1 1  1

x1 x2 x3 x4

y1 y2 y3 y4

z 1   C 1   Q1      z 2  C 2   Q 2  =  z 3   C 3   Q 3   z 4   C 4   Q 4 

( 5.7 )

PUMA should be modified to include a k-exact reconstruction. To approximate 4th order accuracy at least 35 cells will be required in each control volume. A detailed comparison of the accuracy improvement versus the computational costs should be completed on a variety of geometries, from simple to complex.

5.5 Future Geometries for Analysis The ROBIN geometry offered a good way to validate PUMA due to the wealth of experimental data and computational data that exists on this general geometry. ROBIN, however is a very generic, streamlined shape that offers little in computing the flow

77 around a realistic helicopter fuselage. A solution around a real AH-64A Apache geometry was computed but no experimental data was available for this geometry. A complex fuselage with experimental data needs to be computed and verified. Dr. Hormoz Tadghighi of Boeing Mesa has provided Penn State University with their generic helicopter shape (Figure 5–4 ). Boeing Mesa has collected a large amount of experimental data on this generic helicopter shape. This Boeing generic helicopter shape is not as streamlined as ROBIN and will offer a chance to study a more realistic helicopter fuselage and compare the results with experimental data. This generic shape should be the used for further analysis of PUMA and all future modifications.

Figure 5–4: Boeing General Helicopter Shape Hormoz Tadghighi, Senior Technical Specialist at the Mesa Boeing Company, provided the Boeing general helicopter shape.

Chapter 6

CONCLUSION

An unstructured grid based computational solution around multiple geometries has been demonstrated. This grid generation was tied to development of geometries with computer aided design software packages. A complete solution method from development of a geometry to a flow solution has proven extremely useful. The advancing front grid generator GridTool/VGrid has proven itself a quick and easy way to create unstructured grids around a variety of complex shapes. This method of grid generation from computer aided design IGES files will greatly reduce the grid development time for future work. Unstructured grids have great potential for modeling complex flows [28]. The flow solver PUMA has been verified with experimental data from inviscid pressure solutions around the ROBIN body. PUMA solutions were compared to experimental data for zero and minus five degrees fuselage angle of attack. This preliminary work clearly demonstrates PUMA’s potential and the need for further development. The static pressures from PUMA compare extremely well with experimental data except for areas around the tail boom. This result was expected given that the tail boom area is an area of highly unsteady flow. PUMA’s solutions also compared favorably with solutions from CFL3D presented in Chaffin et al [10]. The

79 small discrepancies between PUMA and CFL3D can be accounted for by the CFL3D solution being viscous while the current PUMA solutions are inviscid. Using the RANS algorithms in PUMA will allow a viscous solution to be obtained but it is not likely to fully capture the unsteady flow over the tail boom area. Current flow solvers do not accurately capture the unsteady separated flow that exists after the rotor hub pylon. As discussed, PUMA with slight modifications can become a robust solver capable of capturing the unsteady, separated flow to the extent necessary to fully model the rotor interaction with the helicopter fuselage. This research is the foundation for future rotor/fuselage interaction studies. NLDE, k-exact and preconditioning can be added to PUMA to make the solver much more robust. These modifications should be verified with simple geometries, with analytical solutions, and then with experimental data on more complex shapes. A stationary uniform lifting rotor can be added to a generic fuselage to study PUMA’s new ability to capture the interaction between the rotor system and the fuselage. This will also allow a preliminary study of the interactions effect on the tail boom and tail rotor system. This would allow some predictions of the unsteady loads and noise due to the non-uniform flow. Finally a full moving rotor system with rotor wake simulation could be added to a helicopter fuselage. By working with easily generated unstructured meshes and a quick, efficient parallel flow solver it may be possible to introduce complex flow solutions into the design process. A computational study of this nature would truly allow designers to

80 significantly reduce the vibration, noise and handling difficulties caused by the unsteady flow on helicopters.

BIBLIOGRAPHY

1.

Bruner, Christopher. Parallelization of the Euler Equations on Unstructured Grids, Ph.D. thesis, Virginia Polytechnical Institute and State University, 1996.

2.

Morris, Philip J., Long, Lyle N., Bangalore, A, and Wang, Qunzhen. “A Parallel Three-Dimensional Computational Aeroacoustic Method Using Non-Linear Disturbance Equations.” Journal of Computational Physics 133 (1997): 56-74.

3.

Freeman, Carl E. and Mineck, Raymond E. “Fuselage Measurements of a Helicopter Wind-Tunnel Model with a 3.15-Meter Diameter Single Rotor.”, NASA Technical Memorandum 80051, 1979.

4.

Berry, John D. and Althoff. “Inflow Velcoity Parameters Due to Fuselage Effects in the Presence of Fully Interactive Wake." American Helicopter Society 46th Annual Forum Proceedings, Washington D.C., May 1990.

5.

Chaffin, Mark S. and Berry, John D. “Navier-Stokes and Potential Theory Solutions for a Helicopter Fuselage and Comparison with Experiment.” NASA Technical Memorandum 4566, 1994.

6.

Pandya, M, Bhat, M, and Parikh, P. “Application of Unstructured Grid Methodology to Rotorcraft Flows”, AHS Rotorcraft Acoustics and Aerodynamics Specialists Meeting, Williamsburg, VA. October, 1997.

7.

Duque, Earl and Berry, John. “A Comparision of Computed and Experimental Flowfields of the RAH-66 Helicopter.” AHS Aeromechanics Specialist Meeting, 1995.

8.

Ghee, Terence, Berry, John, Zori, Laith, and Elliot, Joe. “Wake Geometry Measurements and Analytical Calculations on a Small-Scale Rotor Model.” NASA TP 3584, ATCOM TR 96-A-007, August 1996.

9.

Berry, John and Bettschart, Nicolas. “Rotor-Fuselage Interaction: Analysis and Validation with Experiment.” 53rd American Helicopter Society Forum, Virginia Beach, VA. May 1997.

10.

Liu, Jingmei and Long, Lyle N. “Higher Order Accurate Ship Airwake Predictions for the Helicopter/Ship Interface Problem.” 54th Annual American Helicopter Society Forum, Washington D.C., 1998.

82 11.

Pirzadeh, Shahyar. “Progress Toward a User-Oriented Unstructured Viscous Grid Generator.” AIAA Paper 96-0031, AIAA 34th Aerospace Sciences Meeting and Exhibit, Reno, NV, 1996.

12.

Tannehill, John C., Anderson, Dale A., and Pletcher, Richard H., Computational Fluid Mechanics and Heat Transfer. Wahington D.C.: Taylor & Francis Publishers, 1997

13.

Geolab NASA Langley, GridTool Training Manual. NASA Langley, VA, 1998.

14.

Garriz, Javier A. VGrid 3.2 Reference Documents. ViGYAN Inc., 1998.

15.

Pirzadeh, S. “Three-Dimensional Unstructured Viscous Grids by the AdvancingLayers Method.” AIAA Journal, Volume 34 (1996) pages 43-49.

16.

Pirzadeh, S. “Structured Background Grids for Generation of Unstructured Grids by Advancing-Front method.” AIAA Journal, Volume 31 (1996): pages 257-265.

17.

Krist, Sherrie L., Beidron, Robert T., and Rumsey, Christopher L. CFL3D Users Manual, The Aerodynamic and Acoustic Methods Branch of the NASA Langley Research Center, 1996.

18.

Modi, Anirudh. “PUMA Slideshow Presentation.” 20 December 1998 .

19.

Bruner, Christopher. PUMA User Manual. 1998.

20.

Long, Lyle N. "Institute for High Performance Computing Applications". 10 Dec 1998. Pennsylvania State University. .

21.

Long, Lyle N. "Cost Effective Computing Array". 10 January 1990. Pennsylvania State University. .

22.

Hirsh, Charles. Numerical Computation of Internal and External Flows Volume 2. New York: John Wiley & Sons, 1990.

23.

Khan, M. “Computations of Aeroacoustic Fields Using Finite Volume Method.” Computational Acoustics: Algorithms and Applications. 1988: pages 83-101.

24.

Morris, P.J., Long, L.N., Scheidegger, T.E., Wang, Q., and Pilon, A.R. “High Speed Jet Noise Simulations.” AIAA 98-2290, 4th AIAA/CEAS Conference, Toulouse, France, 1998.

25.

Liu, J. and Long, L.N. “Direct Aeroacoustic and Aerodynamic Simulation of Multi-Hole Engine Linears.” AIAA 98-2330, 4th AIAA/CEAS Aeroacoustics Conference, Toulouse, France, 1998.

83 26.

Barth, Timothy J. “Recent Developments in High Order K-Exact Reconstruction on Unstructured Meshes.” AIAA 93-0668, 31st Aerospace Sciences Meeting and Exhibit, 1993.

27.

Merkle, C.L. "Preconditioning Methods for Viscous Flow Calculations". Computational Fluid Dynamics Review 1995, John Wiley & Sons, England, 1995, pp 419-436.>.

28.

Wang, Qunzhen, Massey, Steven, and Abdol-Hamid, Khaled S. “Solving NavierStokes Equations with Advanced Turbulence Models on Three-Dimensional Unstructured Grids.” AIAA 99-0156, 37th AIAA Aerospace Sciences Meeting and Exhibit, 1999.

Appendix A

PRO ENGINEER TO GRIDTOOL EXPORTER

!ProE ---> GridTool (via IGES Surfaces) !Supplied by Sally Viken, NASA Langley ! ! The objects should be created as follows: ! Feature ! Create ! Solid ! Protusion ! ! For exporting to IGES select: ! Export ! IGES ! Surfaces BELL no ! ! this first directive says that if an ! entity is blanked don't write it to ! the iges file ! intf_out_blanked_entities no ! ! this says to convert all base surfaces ! to nurbs before writing them out ! iges_out_all_srfs_as 128 ! ! this controls how much overlap there ! is when the trimmed surfaces come out ! of pro ! intf3d_out_extend_surface NO ! ! convert all spline curves to nurbs ! iges_out_spl_crvs_as_126 YES ! ! convert all spline surfaces to nurbs ! iges_out_spl_srfs_as_128 YES ! ! not quite sure what this is supposed ! to do... needs more experimentation

85 ! !iges_out_trim_xyz YES ! ! ! mapkey definitions ! ! mapkey pt #Part;#Create; def_part;; mapkey df #Feature;#Create;#Datum;#Plane;#Default;#Done; mapkey dc #Feature;#Create;#Datum;#Coord Sys; #Default; #Done; ! mapkey zi #View;#Pan/Zoom;#Zoom In; mapkey zo #View;#Pan/Zoom;#Zoom Out; mapkey zr #View;#Pan/Zoom;#Reset; mapkey zp #View;#Pan/Zoom;#Pan; ! mapkey vd #View;#Default;#Done-Return; mapkey vr #View;#Repaint;#Done-Return; mapkey sp #View;#Spin; mapkey sd #View;#Cosmetic;#Shade;#Display;#Done-Return;

Appendix B

PARAMETERS FOR GENERATING ROBIN SHAPE

Table 8–1: Fuselage Parameter for Equation 1-5 Function

X/R

C1

C2

C3

C4

C5

C6

C7

C8

H

0 to 0.4

1.00

-1.00

-0.40

0.40

1.80

0.00

0.25

1.80

W

1.00

-1.00

-0.40

0.40

2.00

0.00

0.25

2.00

Z0

1.00

-1.00

-0.40

0.40

1.80

-0.08

0.08

1.80

N

2.00

3.00

0.00

0.40

1.00

0.00

1.00

1.00

0.25

0.00

0.00

0.00

0.00

0.00

0.00

0.00

W

0.25

0.00

0.00

0.00

0.00

0.00

0.00

0.00

Z0

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

N

5.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

1.00

-1.00

-0.80

1.10

1.50

0.05

0.20

0.60

W

1.00

-1.00

-0.80

1.10

1.50

0.05

0.20

0.60

Z0

1.00

-1.00

-0.80

1.10

1.50

0.04

-0.04

0.60

N

5.00

-3.00

-0.80

1.10

1.00

0.00

0.00

0.00

1.00

-1.00

-1.90

0.10

2.00

0.00

0.05

2.00

W

1.00

-1.00

-1.90

0.10

2.00

0.00

0.05

2.00

Z0

0.04

0.00

0.00

0.00

0.00

0.00

0.00

0.00

N

2.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

H

H

H

0.4 to 0.8

0.8 to 1.9

1.9 to 2.0

87

Table 8–2: Pylon (Doghouse) Parameters for Equation 1-5 Function

X/R

C1

C2

C3

C4

C5

C6

C7

C8

H

0.4 to 0.8

1.00

-1.00

-0.80

0.40

3.00

0.00

0.20

3.00

W

1.00

-1.00

-0.80

0.40

3.00

0.00

0.17

3.00

Z0

0.11

0.00

0.00

0.00

0.00

0.00

0.00

0.00

N

5.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

1.00

-1.00

-0.80

0.22

2.00

0.00

0.20

2.00

W

1.00

-1.00

-0.80

0.22

2.00

0.00

0.17

2.00

Z0

1.00

-1.00

-0.80

1.10

1.50

0.07

0.06

0.60

N

5.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

H

0.8 to 1.018

Appendix C

F-77 PROGRAM TO PRODUCE ROBIN SHAPE

PROGRAM ROBIN c c c c c c c c c c c c c C c

Program to calculate the surface coordinates of the ROBIN body and doghouse. Code provided by John Berry 10/97. Modified to cluster points near corners on body. Number of points around circumference determined in external include statement. Code modified to eliminate the gap between the body and the pylon. The first and last points on the pylon are replaced with points on the body at the same lateral and longitudinal locations. HESS format surface definition written to file ROBIN.hess PLOT3D format surface definition written to file ROBIN.plot3d Correction from the coefficients in TM 80051 (JDB-88) include 'parameter.inc'

c REAL CH(6,8),CW(6,8),CZ0(6,8),CN(6,8) CHARACTER*8 labxor(6) DATA labxor/'0.0->0.4','0.4->0.8','0.8->1.9', + '1.9->2.0','0.4->0.8','-> 1.018'/ C Blockc: 1-12; 12-18; 18-28; 28-31; 12-18; 18-21 C Segment -1- -2- -3- -4- -5- -6C 1--- BODY ---1 C 1-------1 dog-house DATA CH/ 1.0, .25, 1.0, 1.0, 1.0, 1.0, + -1.0, 0.0,-1.0,-1.0,-1.0,-1.0, + -0.4, 0.0,-0.8,-1.9,-0.8,-0.8, + 0.4, 0.0, 1.1, 0.1, 0.4,.218, + 1.8, 0.0, 1.5, 2.0, 3.0, 2.0, + 0.0, 0.0, .05, 0.0, 0.0, 0.0, + 0.25,0.0, 0.2, .05,.145,.145, + 1.8, 0.0, 0.6, 2.0, 3.0, 2.0/ c + 0.25,0.0, 0.2, .05, 0.2, 0.2, ORIG c + 1.8, 0.0, 0.6, 2.0, 3.0, 2.0/ ORIG c + 0.25,0.0, 0.2, .05,.145,.145, Onera c + 1.8, 0.0, 0.6, 2.0, 3.0, 2.0/ Onera c + 0.25,0.0, 0.2, .05,.1935,.1935, 2MRTS? c + 1.8, 0.0, 0.6, 2.0, 3.0, 2.0/ 2MRTS? DATA CW/ 1.0, .25, 1.0, 1.0, 1.0, 1.0, + -1.0, 0.0,-1.0,-1.0,-1.0,-1.0, + -0.4, 0.0,-0.8,-1.9,-0.8,-0.8,

89 + + + + + C C c c

0.4, 0.0, 1.1, 0.1, 0.4,.218, 2.0, 0.0, 1.5, 2.0, 3.0, 2.0, 0.0, 0.0,0.05, 0.0, 0.0, 0.0, .25, 0.0, 0.2, .05,.1656,.1656, 2.0, 0.0, 0.6, 2.0, 3.0, 2.0/ + .25, 0.0, 0.2, .05,.172,.172, ORIG + 2.0, 0.0, 0.6, 2.0, 3.0, 2.0/ ORIG + .25, 0.0, 0.2, .05,.1656,.1656, 2MRTS? + 2.0, 0.0, 0.6, 2.0, 3.0, 2.0/ 2MRTS? DATA CZ0/1.0, 0.0, 1.0, .04,.125, 1.0, + -1.0, 0.0,-1.0, 0.0, 0.0,-1.0, + -0.4, 0.0,-0.8, 0.0, 0.0,-0.8, + 0.4, 0.0, 1.1, 0.0, 0.0, 1.1, + 1.8, 0.0, 1.5, 0.0, 0.0, 1.5, + -.08, 0.0, .04, 0.0, 0.0,.065, + .08, 0.0,-.04, 0.0, 0.0, .06, + 1.8, 0.0, 0.6, 0.0, 0.0, 0.6/ DATA CN/ 2.0, 5.0, 5.0, 2.0, 5.0, 5.0, + 3.0, 0.0,-3.0, 0.0, 0.0, 0.0, + 0.0, 0.0,-0.8, 0.0, 0.0, 0.0, + 0.4, 0.0, 1.1, 0.0, 0.0, 0.0, + 1.0, 0.0, 1.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 1.0, 0.0, 0.0, 0.0, 0.0, 0.0/

C C -- Print the coefficient table (per TM80051) open (9,file='output',form='formatted') rewind 9 OPEN(10,FILE='ROBIN.tab',status='UNKNOWN') write(10,'(////,30x,''Fuselage Parameters''//)') write(10,1005) write(10,'(5x, + ''Function X/R C1 C2 C3 C4 C5'', + '' C6 C7 C8'')') write(10,1005) do j=1,4 write(10,1001)labxor(j),(CH(j,i),i=1,8) write(10,1002)(CW(j,i),i=1,8) write(10,1003)(CZ0(j,i),i=1,8) write(10,1004)(CN(j,i),i=1,8) end do write(10,'(////,32x,''Pylon Parameters''//)') write(10,1005) do j=5,6 write(10,1001)labxor(j),(CH(j,i),i=1,8) write(10,1002)(CW(j,i),i=1,8) write(10,1003)(CZ0(j,i),i=1,8) write(10,1004)(CN(j,i),i=1,8) end do CLOSE(10) 1001 FORMAT(8x,'H',2x,a8,1x,8f7.3) 1002 FORMAT(8x,'W',11x,8f7.3)

90 1003 FORMAT(8x,'Z0',10x,8f7.3) 1004 FORMAT(8x,'N',11x,8f7.3/) 1005 FORMAT(5x,71('-')) C c call interact(ch,cw,cz0,cn) c if (1.eq.1) stop 'temporary stop' C -- set constant TWOPI = 8*atan(1.0) c 6.28318 C -- compute radial distribution: c NR = 60 C C - determine fuselage break points: IPT1 = 1 IPT2 = 2 IPT3 = 3 IPT4 = 4 IEND = 5 EPS = .001 DO I=1,nx if (ABS(XOR(I)-0.400) .LT. EPS) IPT1 = I if (ABS(XOR(I)-0.800) .LT. EPS) IPT2 = I if (ABS(XOR(I)-1.018) .LT. EPS) IPT3 = I if (ABS(XOR(I)-1.900) .LT. EPS) IPT4 = I if (ABS(XOR(I)-2.000) .LT. EPS) IEND = I END DO C delth = twopi/Float(NR) C volume = 0.0 area = 0.0 oldarea = 0.0 OPEN(11,FILE='ROBIN.hess',status='UNKNOWN') write(6,*)' Output file opened...' C C -- FIRST STRIP OF ZEROS DO J=1,NR + 1 K=0 IF (J .EQ. 1) K = 2 WRITE(11,100)XOR(1),0.,GEOM(CZ0,1,XOR(1)),k,0 END DO C...5....1....5....2....5....3....5....4 write(6,*)' First zero s output' C C -- Over the Nose IX = 1 write(6,*)' DO i=2,',IPT1 DO I=2,IPT1 XN=GEOM(CN,IX,XOR(I)) XZ0=GEOM(CZ0,IX,XOR(I)) XW=GEOM(CW,IX,XOR(I)) XH=GEOM(CH,IX,XOR(I)) call WRTSTRP(delth,AREA,NR,XOR(i),XN,XZ0,XW,XH)

91 volume = volume + (xor(i) - xor(i-1))*(area + oldarea)/2.0 write(6,*)'At ',XOR(i),' area ',area,' running volume ',volume oldarea = area area = 0.0 END DO C C -- Over the Middle IX = 2 DO I=IPT1+1,IPT2 XN=GEOM(CN,IX,XOR(I)) XZ0=GEOM(CZ0,IX,XOR(I)) XW=GEOM(CW,IX,XOR(I)) XH=GEOM(CH,IX,XOR(I)) call WRTSTRP(delth,AREA,NR,XOR(i),XN,XZ0,XW,XH) volume = volume + (xor(i) - xor(i-1))*(area + oldarea)/2.0 write(6,*)'At ',XOR(i),' area ',area,' running volume ',volume oldarea = area area = 0.0 END DO C C -- Over the Tail IX = 3 DO I=IPT2+1,IPT4 XN=GEOM(CN,IX,XOR(I)) XZ0=GEOM(CZ0,IX,XOR(I)) XW=GEOM(CW,IX,XOR(I)) XH=GEOM(CH,IX,XOR(I)) call WRTSTRP(delth,AREA,NR,XOR(i),XN,XZ0,XW,XH) volume = volume + (xor(i) - xor(i-1))*(area + oldarea)/2.0 write(6,*)'At ',XOR(i),' area ',area,' running volume ',volume oldarea = area area = 0.0 END DO C C -- Over the Tail Cone IX = 4 DO I=IPT4+1,IEND XN=GEOM(CN,IX,XOR(I)) XZ0=GEOM(CZ0,IX,XOR(I)) XW=GEOM(CW,IX,XOR(I)) XH=GEOM(CH,IX,XOR(I)) call WRTSTRP(delth,AREA,NR,XOR(i),XN,XZ0,XW,XH) volume = volume + (xor(i) - xor(i-1))*(area + oldarea)/2.0 write(6,*)'At ',XOR(i),' area ',area,' running volume ',volume oldarea = area area = 0.0 END DO C C -- Now for the 'dog-house' C C -- FIRST STRIP OF ZEROS C...5....1....5....2....5....3....5....4 DO J=1,NR/2 + 1

92 K=0 IF (J .EQ. 1) K = 2 WRITE(11,100)XOR(IPT1),0.,GEOM(CZ0,5,XOR(IPT1)),k,0 END DO C C -- Over the Nose IX = 5 DO I=IPT1+1,IPT2 XN=GEOM(CN,IX,XOR(I)) XZ0=GEOM(CZ0,IX,XOR(I)) XW=GEOM(CW,IX,XOR(I)) XH=GEOM(CH,IX,XOR(I)) xnb=geom(cn,2,xor(i)) xzb=geom(cz0,2,xor(i)) xwb=geom(cw,2,xor(i)) xhb=geom(ch,2,xor(i)) call WRTSTRP2(delth,AREA,NR,XOR(i),XN,XZ0,XW,XH,xnb,xzb,xwb,xhb) volume = volume + (xor(i) - xor(i-1))*(area + oldarea)/2.0 write(6,*)'At ',XOR(i),' area ',area,' running volume ',volume oldarea = area area = 0.0 END DO C C -- Over the Tail IX = 6 DO I=IPT2+1,IPT3-1 XN=GEOM(CN,IX,XOR(I)) XZ0=GEOM(CZ0,IX,XOR(I)) XW=GEOM(CW,IX,XOR(I)) XH=GEOM(CH,IX,XOR(I)) xnb=geom(cn,3,xor(i)) xzb=geom(cz0,3,xor(i)) xwb=geom(cw,3,xor(i)) xhb=geom(ch,3,xor(i)) call WRTSTRP2(delth,AREA,NR,XOR(I),XN,XZ0,XW,XH,xnb,xzb,xwb,xhb) volume = volume + (xor(i) - xor(i-1))*(area + oldarea)/2.0 write(6,*)'At ',XOR(i),' area ',area,' running volume ',volume oldarea = area area = 0.0 END DO C C -- LAST STRIP OF ZEROS C...5....1....5....2....5....3....5....4 DO J=1,NR/2 + 1 K=0 IF (J .EQ. 1) K = 1 WRITE(11,100)XOR(IPT3),0.,GEOM(CZ0,6,XOR(IPT3)),k,0 END DO C C write(6,*)'Total volume ',volume C CLOSE(11)

93 call surface STOP 'DONE' 100 FORMAT(3F10.5,2i1) END C SUBROUTINE WRTSTRP(DT,AREA,NR,XOR,XN,XZ0,XW,XH) DO J=1,NR + 1 TH = DT*(J-1) c c Cluster points on corners c c call angle(j,nr,th) K=0 IF (J .EQ. 1) K = 1 STH = -SIN(TH) CTH = COS(TH) C DENOM = (ABS(XH*STH)**XN + ABS(XW*CTH)**XN)**(1./XN) RVAL = .5*XH*XW/DENOM C if (j .le. NR) area = area + .5 * RVAL*RVAL*DT C XVAL = XOR YVAL = RVAL*STH ZVAL = XZ0 + RVAL*CTH C WRITE(11,100)XVAL,YVAL,ZVAL,k,0,j,th END DO RETURN 100 FORMAT(3F10.5,3i2,f6.1) END C SUBROUTINE WRTSTRP2(DT,AREA,NR,XOR,XN,XZ0,XW,XH,xnb,xzb,xwb,xhb) DO J=1,NR/2 + 1 TH = DT*((NR/2 + 1)-J) c c Cluster points on corners c c jj=nr/2-j+2 c call angle(jj,nr,th) K=0 IF (J .EQ. 1) K = 1 STH = SIN(TH) CTH = -COS(TH) C DENOM = (ABS(XH*STH)**XN + ABS(XW*CTH)**XN)**(1./XN) RVAL = .5*XH*XW/DENOM C if (j .le. NR) area = area + .5 * RVAL*RVAL*DT C XVAL = XOR YVAL = RVAL*CTH ZVAL = XZ0 + RVAL*STH

94 if(j.eq.1) then call intersec(yval,xnb,xzb,xwb,xhb,zint) write(9,333)xval,yval,zval,zint 333 format(4f10.5) endif if(j.eq.1 .or. j.eq.(nr/2+1))then write(11,100)xval,yval,zint,k,0,th else WRITE(11,100)XVAL,YVAL,ZVAL,k,0,th endif END DO RETURN 100 FORMAT(3F10.5,2i1,f6.2) END subroutine intersec(y,xn,xz0,xw,xh,zval) dt=0.01 th=0.0 sth=-sin(th) cth=cos(th) denom=(abs(xh*sth)**xn+abs(xw*cth)**xn)**(1./xn) rval=0.5*xh*xw/denom y1=rval*cth z1=xz0+rval*sth th1=th 100 continue th=th+dt if(th.gt.6.3)stop sth=-sin(th) cth=cos(th) denom=(abs(xh*sth)**xn+abs(xw*cth)**xn)**(1./xn) rval=0.5*xh*xw/denom y2=rval*cth z2=xz0+rval*sth th2=th if((z2.lt.0.) .or. (y1.lt.y .and. y2.lt.y) . .or. (y1.gt.y .and. y2.gt.y))then y1=y2 z1=z2 th1=th2 go to 100 endif factor=(y-y1)/(y2-y1) th=th1+factor*(th2-th1) sth=-sin(th) cth=cos(th) denom=(abs(xh*sth)**xn+abs(xw*cth)**xn)**(1./xn) rval=0.5*xh*xw/denom yval=rval*cth zval=xz0+rval*sth return end C REAL FUNCTION VALU(COEF,IX,XVAL)

95 REAL COEF(6,8) VALU= COEF(IX,6) IF (COEF(IX,8) .NE. 0.) THEN X1=(XVAL-COEF(IX,3))/COEF(IX,4) X2=COEF(IX,1)-COEF(IX,2)*X1**COEF(IX,5) VALU = VALU + COEF(IX,7)*X2**(1./COEF(IX,8)) END IF RETURN END c REAL FUNCTION geom(COEF,IX,XVAL) REAL COEF(6,8) IF (COEF(IX,4) .EQ. 0.) THEN GEOM= COEF(IX,1) ELSE X1 = COEF(IX,1)+COEF(IX,2)*(ABS((XVAL+COEF(IX,3)) + /COEF(IX,4)))**COEF(IX,5) GEOM = X1 IF (COEF(IX,8) .EQ. 0. .OR. COEF(IX,8) .EQ. 1.0) RETURN GEOM = COEF(IX,7)*(ABS(X1))**(1.0/COEF(IX,8))+COEF(IX,6) END IF RETURN END c subroutine interact(co1,co2,co3,co4) character*24 inpt real co1(6,8),co2(6,8),co3(6,8),co4(6,8) c write(6,*) ' Interactive mode: ' 10 write(6,*) ' Enter segment (1-6) and x station (or Q to proceed):' read(5,'(a)')inpt if (inpt(1:1).eq. 'q' .or. inpt(1:1) .eq. 'Q') return read(inpt,*,err=99)iseg,x c write(6,*)' At segment ',iseg,' and distance ' . ,x,' dimensions are:' XH = GEOM(co1,iseg,x) write(6,*) ' Height: ',XH XW = GEOM(co2,iseg,x) write(6,*) ' Width: ',XW Z0 = GEOM(co3,iseg,x) write(6,*) ' Z offset: ',Z0 XN = GEOM(co4,iseg,x) write(6,*) ' Power: ',XN c write(6,*) ' Enter Y to match: ' read(5,*)ytest rval = .5*XH*XW if (ytest*ytest .gt. XW*XW) then write(6,*)' Sorry too big!!' goto 10 end if yval = 0.0

96 do i=1,100 TMP = .25*(ytest+3*yval)/rval TH = ATAN(1.0000) if (TMP .LT. 1.00000) TH = ASIN(.25*(ytest+3*yval)/rval) STH = sin(TH) CTH = cos(TH) write(6,*)yval,180*TH/3.14159 C DENOM = (ABS(XH*STH)**XN + ABS(XW*CTH)**XN)**(1./XN) RVAL = .5*XH*XW/DENOM C YVAL = RVAL*STH write(6,*)yval if (abs(yval-ytest) .lt. rval*1.0E-6) go to 20 end do write(6,*)' NOT CONVERGED!!!' 20 continue ZVAL = Z0 - RVAL*CTH ZVAU = Z0 + RVAL*CTH write(6,*) 'At ',yval,' Zs are: ',ZVAL, ZVAU go to 10

C

c 99 continue return end subroutine angle(j,nr,th) pi=3.14159 fract=float(j-1)/float(nr) alpha=fract*4.0*pi factor=abs(sin(alpha)) iquad=8*(j-1)/nr if(iquad.eq.0)th= +factor*pi/4.0 if(iquad.eq.1)th= pi/2.0-factor*pi/4.0 if(iquad.eq.2)th= pi/2.0+factor*pi/4.0 if(iquad.eq.3)th= pi -factor*pi/4.0 if(iquad.eq.4)th= pi +factor*pi/4.0 if(iquad.eq.5)th= 3.0*pi/2.0-factor*pi/4.0 if(iquad.eq.6)th= 3.0*pi/2.0+factor*pi/4.0 if(iquad.eq.7)th= 2.0*pi -factor*pi/4.0 if(iquad.eq.8)th= 2.0*pi return end subroutine surface c This program reads the HESS format output file for the ROBIN c body and writes out a PLOT3D format file of the surface. c include 'parameter.inc' c dimension x1(nx,nrp1),y1(nx,nrp1),z1(nx,nrp1), . x2(np,nrd2),y2(np,nrd2),z2(np,nrd2) dimension xa(nx*nrp1),ya(nx*nrp1),za(nx*nrp1), . xb(np*nrd2),yb(np*nrd2),zb(np*nrd2) c

97 .

equivalence (x1(1,1),xa(1)),(y1(1,1),ya(1)),(z1(1,1),za(1)), (x2(1,1),xb(1)),(y2(1,1),yb(1)),(z2(1,1),zb(1))

c i1=nx j1=nrp1 k1=1 i2=np j2=nrd2 k2=1 c close (1) open (1,file='ROBIN.hess',form='formatted',status='old') rewind 1 c c c

Read body coordinates do 100 i=1,i1 do 90 j=1,j1 read(1,*) x1(i,j),y1(i,j),z1(i,j) 90 continue 100 continue

c c c

Read doghouse coordinates do 120 i=1,i2 do 110 j=1,j2 read(1,*) x2(i,j),y2(i,j),z2(i,j) 110 continue 120 continue

c close (1) close (2) open (2,file='ROBIN.plot3d',form='formatted') rewind 2 c c c

Write out surface as multi-block PLOT3D file nblk=4 nib=nx njb=nr/2+1 nkb=1 nip=np njp=nrd2/2+1 nkp=1 nb =nx*(nr/2+1) nb1=nx*(nr/2)+1 nb2=nx*(nr+1) nd =np*(nr/4+1) nd1=np*(nr/4)+1 nd2=np*(nr/2+1) write(6,222)np,nrd2,np*nrd2,nd,nd1,nd2 222 format(' nx nrd2 nxnrd2 nd nd1 ', . ' nd2',/,9i7)

98 c c

c

c

c

c

Number of blocks write(2,201)nblk Size of each bloc write(2,201)nib,njb,nkb write(2,201)nib,njb,nkb write(2,201)nip,njp,nkp write(2,201)nip,njp,nkp Block #1 write(2,202)(xa(m),m=1,nb) write(2,202)(ya(m),m=1,nb) write(2,202)(za(m),m=1,nb) Block #2 write(2,202)(xa(m),m=nb1,nb2) write(2,202)(ya(m),m=nb1,nb2) write(2,202)(za(m),m=nb1,nb2) Block #3 write(2,202)(xb(m),m=1,nd) write(2,202)(yb(m),m=1,nd) write(2,202)(zb(m),m=1,nd) Block #4 write(2,202)(xb(m),m=nd1,nd2) write(2,202)(yb(m),m=nd1,nd2) write(2,202)(zb(m),m=nd1,nd2)

c close (2) return c 201 format(3i8) 202 format(10f8.4) end

Appendix D

PUMA SAMPLE INPUT FILE

Gamma 1.4

R 287.04

rho_inf 32.341

rhoRef 32.341

Vref 320.46

u_inf v_inf w_inf p_inf 19.87 0.0 0.0 101325.0

mu_inf 1.231e-5

T_Suth 110.0

PrLam 0.72

PrTurb 0.9

numIts 500

maxMinutes 2000

wrRestart 10

wrResid 1

CFLconst CFLslope 10 2 localStepping spatial_order 1 2 innerIters 50

innerTol 0.0

gridName "robin_i.sg.gps"

inviscid_flux "roe"

omega stages 1.0 2

restartFrom "robin_i.rst"

muRef 1.231e-5 fsMult 1.0

relResid 1.0e-6

integ_scheme limiter "ssor" "none"

K 5.0e+2

restartTo "robin_i.rst"

implicitBCs viscousModel 1 "inviscid" Num_surfaces 66 surface BC_type rho u v w p 1 8 : All 8s represent surface of robin 2 8 3 8 4 8 5 8 6 8 7 8 8 8 9 8 10 8 11 8 12 8 13 8 14 8

absResid 1.0e-16

commScheme "delta q" residName "robin_i.rsd"

100 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66

8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 5 5 5 8 5 5 8 8 8 8 8 8

< < < <