ARMET: AN ENGINEERING EDUCATION PROGRAM TO EXPEDITE AIRCRAFT GEOMETRY CREATION AND MESHING WITH ELEMENT QUALITY FEEDBACK
by
JASON R NANEZ
B.S., University of California Irvine, 2015
A thesis submitted to the Graduate Faculty of the University of Colorado Colorado Springs
in partial fulfillment of the requirements for the degree of
Master of Science
Department of Mechanical and Aerospace Engineering 2018
This thesis for the Master of Science degree by Jason R Nanez
has been approved for the
Department of Mechanical and Aerospace Engineering by
Andrew Ketsdever, Chair Hui Wan
Adam Jirasek
Nanez, Jason R (M.S., Mechanical Engineering)
ARMET: An Engineering Education Program to Expedite Aircraft Geometry Creation and Meshing with Element Quality Feedback
Thesis directed by Professor Andrew Ketsdever
ABSTRACT
A program known as ARMET (Automated useR-interfaced Multi-Software Educational Tool) that automates aircraft geometry creation, meshing, and computational fluid dy-namics (CFD) pre-processing is described. Developed for use in United States Air Force Academy (USAFA) CFD classes, ARMET creates aircraft geometries by reading coordinate data from an internal USAFA Excel spreadsheet. Using Python as its main scripting lan-guage, the program creates SolidWorks curve files (.SLDCRV) and executes a SolidWorks VBA macro to create the geometry. ARMET then executes a Pointwise script to generate a volumetric mesh based on two grid resolution presets and exports the mesh file in .AVM format, the preferred mesh file format for the CFD program to be used, Kestrel. Addition-ally, data on element angles is exported for interpretation in a mesh report particular to the model being meshed. Various well-documented mesh quality metrics are discussed and summarized in a manner to recommend refinement to the user. After the mesh is gener-ated, additional program windows are available to modify the input file of the Kestrel, and a command file for use on high-performance computing networks. Packaged as a compressed digital archive, ARMET is opened through an executable file for use on Windows operating systems. The capability to quickly create and mesh a geometry make the program useful for a CFD course; relevant coursework can be covered earlier in the curriculum rather than being delayed by troubleshooting various problems in geometry and mesh creation.
ACKNOWLEDGEMENTS
To my lovely girlfriend, Chloe, who helped me through my long nights and believed in me from the very start. To my parents, my sister, and my aunt: I wouldn’t have written this without your endless support. I love you all.
This research would not have existed without the work of Dr. Andrew Ketsdever, Maj. Matthew Satchell, and Lt. Col. Roger Greenwood in maintaining a relationship between the engineering departments of the University of Colorado, Colorado Springs and the US Air Force Academy. I am thankful for their efforts in providing research opportunities for UCCS students like myself. I also thank my other committee members, Dr. Hui Wan, and Dr. Adam Jirasek, for their guidance, and Max Kaiser for his work in making the program presented in this research possible.
TABLE OF CONTENTS
I INTRODUCTION 1
1.1 Motivation . . . 1
1.2 Objective . . . 2
II LITERATURE REVIEW 6 2.1 Algebraic Mesh Quality Metrics . . . 6
2.2 Anisotropic Mesh Adaptation . . . 11
2.3 Element Quality . . . 15
III PROGRAM FEATURES 18 3.1 Spreadsheet Manipulation . . . 19
3.2 SolidWorks Macro . . . 20
3.3 Pointwise Meshing . . . 22
3.3.1 Separate Body Approach . . . 22
3.3.2 One Body Approach . . . 26
3.3.3 Meshing . . . 27
3.4 Kestrel Input . . . 29
3.5 Additional Program Features . . . 30
3.6 Packaging as Executable . . . 31
4.1 Scripting Limitations . . . 34
4.2 Minimum Included Angle . . . 35
4.3 Maximum Included Angle . . . 36
4.4 Equiangle Skew . . . 37
4.5 Domain-Specific Analysis . . . 38
V RESULTS FOR VARIOUS AIRCRAFT TRIALS 41 VI COMPLICATIONS AND IMPROVEMENTS 45 6.1 Capstone Meshing . . . 45
6.2 Benefits of Separate Body Approach . . . 48
6.3 Appearance of User Interface . . . 49
6.4 Lack of Integrated Kestrel Operation . . . 49
6.5 Preference for Anisotropic Mesh Elements . . . 50
6.6 Tetrahedral Extrusion Layers . . . 51
LIST OF TABLES
3.1 Number of grid points along connectors for a Coarse or Fine mesh on the F-22 aircraft. Recommended numbers from course instructors. . . 28
5.1 Results of running each aircraft through ARMET. A “Yes” indicates an ac-curate model for SolidWorks, a valid mesh for Pointwise, and a valid report for Mesh Report. . . 41 5.2 Element quality metrics breached for each problem domain or block for the
F-16 with a coarse mesh (left) and a fine mesh (right). An “x” indicates the condition threshold has been breached by that domain or block. . . 42 5.3 Element quality metrics breached for each problem domain or block for the
F-104C with a coarse mesh (left) and a fine mesh (right). An “x” indicates the condition threshold has been breached by that domain or block. . . 42 5.4 Element quality metrics breached for each problem domain or block for the
F-106A with a coarse mesh (left) and a fine mesh (right). An “x” indicates the condition threshold has been breached by that domain or block. . . 42 5.5 Element quality metrics breached for each problem domain or block for the
T-38 with a coarse mesh (left) and a fine mesh (right). An “x” indicates the condition threshold has been breached by that domain or block. . . 43 5.6 Element quality metrics breached for each problem domain or block for the
F-22 with a coarse mesh (left) and a fine mesh (right). An “x” indicates the condition threshold has been breached by that domain or block. . . 43
7.1 Time savings in performing key operations with ARMET as opposed to executing each task manually. Values shown for manual trials do not in-clude start-up times for each application or time for troubleshooting Solid-Works/Pointwise errors. It is likely that real-world manual operation time could be on the order of hours or days. . . 54
LIST OF FIGURES
2.1 Three test cases for measuring algebraic mesh quality metrics. Knupp (2001) 7 2.2 Test one, where the interior angle θ is varied from 0 to 180 degrees (x-axis)
and the resulting calculated metrics (y-axis). All metrics except volume vary from zero to unity. Shape and length ratio peak when the interior angle matches the 60 degree angle of the reference triangle, with the skew curve overlaid on the shape curve. Knupp (2001) . . . 8 2.3 Test two, where the interior angle θ is varied from 0 to 180 degrees thus
ranging the angle between the x-axis and the triangle edge from 30 to 210 degrees. The resultant calculated metrics are shown along the y-axis. Values for shape peak at 105 degrees, with the skew curve again overlaid on the shape curve. Knupp (2001) . . . 8 2.4 Test three, where the length of the second side of the triangle is varied from 0
to 3. In general, shape, skew, and length ratio curves peak when the second edge length matches that of the reference triangle in test two. Knupp (2001) 9 2.5 Example triangle wherein mesh quality indicator qanisois defined from di, the
derivative of the quadratic function along the edge of a triangle connecting two nodes vi and vi+1. Berzins (2000) . . . 9 2.6 Use of anisotropic elements on areas of high velocity gradients. Mach
gradi-ents smoothed as long, thin elemgradi-ents are used in key areas within the mesh. Ollivier-Gooch and Sharbatdar (2013) . . . 12 2.7 Comparison of anisotropic (“smooth”, 19381 vertices) and isotropic
(“non-smooth”, 19995 vertices) meshes. Ollivier-Gooch and Sharbatdar (2013) . . 14 2.8 Directional refinement of mesh along the leading edge of a turbine blade. Left
figure shows a rough isotropic mesh throughout; right figure shows anisotropic refinement along the leading edge,, gradually becoming isotropic in the chord direction. Peraire and Morgan (1997) . . . 15 2.9 200 triangles used to render a paraboloid. Obtuse triangles cause a rough
approximation, whereas acute triangles aren’t excessively detrimental to the rendering. Shewchuk (2002) . . . 16
2.10 The error between the interpolated value (50) and the known nodal value (40) grows extremely large as the largest angle approaches 180 degrees. Shewchuk (2002) . . . 17
3.1 A flowchart outlining the structure of ARMET (Automated useR-interfaced Multi-software Educational Tool). Major operations are bolded. . . 18 3.2 User selection of a JET spreadsheet containing 3-D geometry data. . . 19 3.3 Extrusion required to close gap between strake and fuselage on F-22
Solid-Works model. Only one strake shown for clarity. . . 21 3.4 Connectors in Pointwise that run along the geometry of the aircraft. By
im-porting each aircraft component separately, some connectors protrude within volumes that should be solid (e.g., fuselage). . . 23 3.5 Methods to distinguish connectors that need to be kept or deleted. Above:
script takes average Y-position of intersection curve as threshold condition. Below: script splits curve into ten sections and finds average Y-position of each for threshold position, resulting in a finer approximation. Intersection curve is exaggerated for illustrative purposes. . . 24 3.6 Left: Multiple features intersecting each other for F-22. Right: Horizontal
tail intersects only vertical tail for F-104C. . . 25 3.7 Gaps between geometry features when viewed in Pointwise. Upon meshing,
Pointwise treats features as separate and introduces surfaces that prevent a watertight model. . . 26 3.8 Intersections automatically detected with import of a single combined model
into Pointwise. Note that there are no connectors within the interior of the aircraft model. . . 27 3.9 Window to modify Kestrel XML input parameters from ARMET. . . 29 3.10 ARMET window to edit runqCopper information (above) and the
runqCop-per file contents (below). . . 30 3.11 Window to modify the size of the CFD bounding box. . . 31
4.1 Distribution of minimum included angle of elements within all domains (left) and the volumetric block (right). X-axis indicates the minimum included angle of any given element; Y-axis indicates the number of elements that fall into a particular angle range. . . 35 4.2 From left to right: the Overlay step, the Stitching step, and the Completion
4.3 An example report summary on a single domain. In this case, a coarse mesh on the strake of the F-16 results in very small interior angles on a few 2-D elements, which causes a skew value larger than 0.8. As before, X-axis indicates the angle/skew of any given element; Y-axis indicates the number of elements that fall into a particular angle/skew range. . . 38 4.4 The location along the aircraft strake where skewed 2-D elements were
de-tected. It appears that the skewed elements were warranted because of the strake geometry. . . 39 4.5 Error window in which the automation program lists the domains and block
where skewed elements exist. In this case, thresholds were crossed with the minimum included angle and equiangle skew for several domains. . . 40
6.1 Edges indicated as “degenerate” on the F-16 nose and strake when attempt-ing a basic mesh in Capstone with default conditions. . . 46 6.2 Rounding the nose tip of an aircraft eliminated the “Degenerate
paramet-ric edge between edges A and B” error. However, blunt nose will present inaccuracies, especially under supersonic flow conditions. . . 47 6.3 Mesh composed of non-anisotropic elements (6.3a) results in clear, distinct
velocity gradients (6.3b) without the use of highly-skewed elements. Images from Kumar et al. (2015). . . 51 6.4 Meshed airfoil with T-Rex boundary layers along the leading and trailing edge. 52
CHAPTER I
INTRODUCTION
1.1 Motivation
In September 2017, the United States Air Force Academy (USAFA) called for one or two graduate students at the University of Colorado, Colorado Springs (UCCS) to create educational tool for an introductory Computational Fluid Dynamics (CFD) course taught at USAFA. Instructors expressed their concern with how much time the necessary pre-processing steps took out of the semester; creating a solid 3-D model of an aircraft, having the model free of unintended holes or voids that interfere with the creation of a complete mesh, generating a usable 3-D mesh, and preparing the CFD solver input command files would take some students weeks to complete, thus using valuable time that could otherwise be focused on the course material. Thus a research project was initiated to develop a program that would automate the pre-processing steps such that the student in the CFD course would only have to edit a spreadsheet containing aircraft curve data, select the spreadsheet file through an automation program interface developed in this research, and run through prompts that will create the aircraft geometry, mesh, and CFD input files for the student. The resulting output files of the program are the aircraft geometry file, a 3-D mesh of the geometry, CFD solver input file, and another command file for running the simulation on a remote high-performance computing network.
While this program is intended for an introductory CFD course where the focus will primarily be on the CFD solver (Kestrel), mesh quality is important to measure and consider in the pre-processing steps. The mesh generation step is an opportunity for the developed automation program to expand its educational breadth and provide even more utility to the
student. The results generated from a CFD solver are only useful if the mesh accurately depicts the model geometry, the flow conditions, and the unique phenomena that arise from the flow conditions.
1.2 Objective
The aircraft to be modeled begins as a spreadsheet where the student can edit physi-cal parameters such as wing aspect ratio, airfoil profile, and surface area. One tab of the spreadsheet lists three-dimensional coordinates that form cross-sectional curves for each aircraft component: nose, fuselage, wings, tail(s), and strakes (if applicable). This spread-sheet serves as the starting point where the automation program developed in this research receives the coordinate data and eventually produces the files necessary to run Kestrel. The following features are what USAFA instructors need from this program:
1. A 3-D Model of the aircraft: Through the automation program, instructors want a command that takes data from the spreadsheet and creates a model in SolidWorks. This serves as an intermediate step to generating a mesh, but it also allows the student to review their model before proceeding with the next steps. Furthermore, the use of a SolidWorks part format is familiar to students and allows for easy manipulation, 3-D printing, and creating reports.
2. A 3-D Mesh of the aircraft: Instructors want the automation program to open the Pointwise meshing software and generate a basic volumetric mesh that will be com-patible with the Kestrel CFD solver. The mesh is to be ”basic” in the sense of being comprised of unstructured triangular and tetrahedral elements, and the student would be able to broadly determine the mesh size.
3. Kestrel input files: Along with the Pointwise mesh output, Kestrel needs additional files to run. One is an XML document that contains flow data, boundary conditions, and other settings that define the Kestrel simulation. The other is a run command file which calls Kestrel from a remote computing server, allocates a certain number of computing cores to the simulation, and queues the simulation to run.
It became evident early in the development of this tool that creating a broad automatic meshing script in Pointwise would become the most complex task of this project. Most students have a competent grasp on manipulating geometry in SolidWorks, and feedback on the physical accuracy of the model is immediate; by simply looking at the model, one can determine whether the wings are swept correctly, whether the nose is properly lofted, and more. Determining the “accuracy” of the Pointwise mesh is far less obvious and students likely have less-experience in assessing a mesh for quality.
Therefore, implementing a feature where the student would receive mesh quality feed-back and brief recommendations to improve the mesh would make a difference in both the CFD simulation and the student’s knowledge of what makes a mesh “good”. While the quality of the mesh is not the direct focus of the CFD course, exposing students to general meshing techniques is certainly a helpful subject to cover in current and future courses, which is why this research project focuses so greatly on mesh quality measures and on im-plementing a mesh feedback reporting feature. This mesh feedback report has been worked into the automation tool and further develops the tool’s function as an educational asset for engineering.
To accomplish the above tasks, this research focused on and developed the following features as part of the program ARMET (Automated useR-interfaced Multi-software Edu-cational Tool):
1. User Interface: A user interface window was created for several reasons. First, it serves as the operations center of ARMET where the user can execute commands to select input spreadsheet data, create aircraft geometry, create a mesh, and create CFD input files. Second, a user interface offers convenient means to change ARMET pref-erences such as the directories of important programs (SolidWorks CAD and Point-wise Meshing). Third, a user interface is familiar and offers a visualization of the expected workflow of the project, with large buttons that explicitly state each opera-tion. Python was chosen as the primary programming language of ARMET because of its versatility in having libraries for user interface design, multi-thread processing, and executing Windows programs.
2. Mesh Generation: This research also explores several methods of meshing in Pointwise and selects one that best fits the scope of the project. In order for the meshing oper-ation to be automated, this research developed a script to be used within Pointwise and is capable of handling a wide array of aircraft geometries. This script is executed from the ARMET user interface. To further simplify the meshing step, two presets (Coarse and Fine) are available for selection from the user interface that dictates the mesh resolution.
3. CFD Input File Creation: Along with the mesh file created in Pointwise, Kestrel requires a data file (.XML) that contains flow conditions and other input parameters. By introducing a separate window that opens from the ARMET main user interface window, the user can edit the XML file without the use of a text editor.
4. High-Performance Computing Command File: In a similar vein to the XML file, an additional window is provided where the user can edit a particular file that commands the CFD simulation to run on a high-performance computing network.
5. Mesh Report: To further expand ARMET’s purpose as an educational tool, this re-search includes a mesh report that provides feedback on mesh element quality. Quality is established on well-defined measures from the literature and Pointwise documenta-tion.
6. Executable Packaging: For ease of distribution and operation, ARMET also took advantage of a script that packages the Python program, the Python interpreter, necessary libraries, and additional files into one archive. Opening ARMET is done by executable file, which is how all Windows programs open and should be familiar to a Windows user.
This research does not take credit for the development of two features of ARMET: the interpretation of the coordinate data from the USAFA aircraft spreadsheet and the SolidWorks macro from which 3D aircraft geometry is created. While these features were developed by a second member of the research project team, this paper describes these
features in detail because they are critical to the project as a whole and ultimately lead to other important features such as mesh generation and the mesh report.
Many aspects of this research have likely been explored or developed in one capacity or another; this is evidenced by the wide availability of online resources for scripting in SolidWorks and Pointwise. The mere existence of scripting functions within these programs such as recording operations to a text file, batch-processing, and executing scripts on pro-gram start-up indicate that many solutions exist to automate processes such as geometry and mesh creation. What makes this research unique is the source data of the geometry and the integration of several automation processes into one package. The spreadsheet that contains aircraft geometry data was developed for internal USAFA use and therefore has little to no exposure to the public; only with this research has it been explored as a means of automatically creating aircraft geometry. Moreover, the procedure outlined by USAFA instructors involves the uncommon CFD software, Kestrel, along with options to run on the Department of Defense High-Performance Computing (HPC) network; the workflow involving the spreadsheet, SolidWorks, Pointwise, Kestrel, and then the computing network makes this research highly specialized and unexplored as a whole.
CHAPTER II
LITERATURE REVIEW
Limited published work has been done on creating an automated process for creating 3-D geometry from curve points, generating a 3-D mesh from that geometry, and running a CFD simulation; this project becomes more specialized once particular programs are required for its use, namely: SolidWorks CAD, Pointwise meshing, and Kestrel CFD solver. However, studies into quantifying the quality of a mesh and recommendations for mesh refinement have been in place since the creation of the finite element method. These mesh qualities, refinement techniques, and comparisons to flow conditions prove useful in creating a mesh feedback system for this rese..
2.1 Algebraic Mesh Quality Metrics
Mesh quality metrics have the following purposes:
1. The metric establishes a mesh requirement specification before the mesh is created. 2. The metric serves as a measure of improvement after refinement (smoothing, element
swapping, etc).
3. The metric acts as a quality control specification and determines when a mesh is “good enough” for simulation.
Knupp (2001) establishes general definitions of algebraic metrics for element qualities such as shape, skew, length ratio, and volume. He creates three cases of triangular geometry and varies either an interior angle or a side length to see how the algebraic metric increases or decreases with the changing variable; these three test cases are shown in Figure 2.1.
Test one Test two Test three ❅ ❅ ❅ ❅ ❅ ❅ ✟✟✟✟ ✟✟ ✡✡ ✡✡ ✡✡ ✡✡ ✡ ✡ ✟✟✟✟ ✟✟❍ ❍ ❍ ❍ ❍ ❍ ❍ ❍ ❉ ❉ ❉ ❉ ❉ ❉❉ θ 1 1 θ 30 1 2 75 30 1 ℓ
Figure 2.1: Three test cases for measuring algebraic mesh quality metrics. Knupp (2001)
For test one, the interior angle θ is varied from 0 to 180 degrees while the two sides are fixed at unit length; the reference triangle is equilateral; comparing this variation with calculated metrics is shown in Figure 2.2. For test two, the length of the second side is increased to 2, the base of the triangle is rotated 30 degrees with respect to the x-axis, and the reference triangle is now isosceles with base 1 and height 2; plotting metrics values with respect to a variation in θ is shown in Figure 2.3. For test three, the base is still rotated 30 degrees from the x-axis but the interior angle between the first and second sides is fixed at 75 degrees; the length of the second side is varied from 0 to 3, and the reference triangle is the same as in test two; the corresponding calculated metrics values are shown in Figure 2.4. Knupp (2001) reached the conclusion that shape, volume, and combined shape-volume are “the most valuable” metrics because these metrics are at near unity when the test element matches the reference element. Skew varies almost identically to shape.
Rather than develop a mesh quality measure based on an element’s geometric similarities to an equilateral element, Berzins (2000) derives a mesh quality indicator qaniso, which provides a measure of anisotropy of a particular element as a function of interpolation error. qaniso is derived from di, the derivative of a quadratic function along the edge of a triangle connecting two nodes viand vi+1(see Figure 2.5 and Equation 1). With this definition, and some prior derivation of a linear interpolation function, Berzins (2000) derives the following to reach qaniso:
di = 1
2(vi+1− vi) T H
Figure 2.2: Test one, where the interior angle θ is varied from 0 to 180 degrees (x-axis) and the resulting calculated metrics (y-axis). All metrics except volume vary from zero to unity. Shape and length ratio peak when the interior angle matches the 60 degree angle of the reference triangle, with the skew curve overlaid on the shape curve. Knupp (2001)
Figure 2.3: Test two, where the interior angle θ is varied from 0 to 180 degrees thus ranging the angle between the x-axis and the triangle edge from 30 to 210 degrees. The resultant calculated metrics are shown along the y-axis. Values for shape peak at 105 degrees, with the skew curve again overlaid on the shape curve. Knupp (2001)
Figure 2.4: Test three, where the length of the second side of the triangle is varied from 0 to 3. In general, shape, skew, and length ratio curves peak when the second edge length matches that of the reference triangle in test two. Knupp (2001)
Figure 2.5: Example triangle wherein mesh quality indicator qaniso is defined from di, the derivative of the quadratic function along the edge of a triangle connecting two nodes vi and vi+1. Berzins (2000)
˜ di =
|di| dmax
, where dmax= max [|d1|, |d2|, |d3|] (2) ˜
q(˜d) = ( ˜d1+ ˜d2+ ˜d3)2+ ˜d21+ ˜d22+ ˜d23 (3) qaniso = q(˜˜d)
12 (4)
By the definition of the coefficients ˜di in Equation 2, qaniso is bounded between 0 and 1, where a value of 0 indicates an unskewed element and an value of 1 indicates a highly skewed, flat element. For example, the following combines Equations 3 and 4 to calculate the value of qanisoof a triangle with one edge contributing to interpolation error and another with two edges contributing to the error, respectively:
qaniso = (1 + 0 + 0)2+ 12+ 02+ 02 12 = 1 6 (5) qaniso = (1 + 1 + 0)2+ 12+ 12+ 02 12 = 1 2 (6)
Upon deriving qaniso, Berzins (2000) shows that this value is a scaled form of the inter-polation error in Equation 7. The development of this mesh quality indicator demonstrates the importance of identifying elements that give a poor linear estimation of the actual function as a consequence of their anisotropy. However, other sources offer evidence that element anisotropy may be beneficial for some geometries, and create algorithms to promote anisotropic elements. qaniso = 15 A d2 max Z T (elin(x, y))2dx dy (7) Z T(elin(x, y)) 2dx dy = A 180 h (d1+ d2+ d3)2+ d12+ d22+ d32 i (8)
2.2 Anisotropic Mesh Adaptation
In the development of an anisotropic unstructured mesh algorithm, Castro-D´ıaz et al. (1997) make the following claim in justification for using anisotropic mesh elements over isotropic mesh elements:
From finite element theory it is well known that for isotropic problems, meshes with equilateral triangles are more suitable. However, the notion of equilaterality involves lengths through scalar products in a given metric. Therefore anisotropic meshes might be seen as isotropic with respect to a different metric. [Castro-D´ıaz et al. (1997)]
Beginning from a similar assumption, Ollivier-Gooch and Sharbatdar (2013) examine the anisotropic nature of aerodynamic flows and thus how it warrants an anisotropic mesh. As explained here:
[In a boundary layer] strong velocity gradients develop in a direction perpendic-ular to the flow in comparison with velocity gradients parallel to the flow...one should use anisotropic meshes aligned with the flow feature, which means that the mesh contains long and thin elements that have been stretched according to a preferred direction i.e. parallel to the boundary layers or shock waves. [Ollivier-Gooch and Sharbatdar (2013)]
For its complex geometry, and especially for the flow conditions, the aircraft that ARMET will mesh will likely be experiencing areas of strong velocity gradients that, ac-cording to Ollivier-Gooch and Sharbatdar (2013), warrant the use of anisotropic elements. Broadly speaking, matching the level of mesh anisotropy with the level of flow condition anisotropy will yield a favorable accuracy in the solution. For example, transonic flow over a symmetric airfoil is shown in Figure 2.6. The Mach number gradients are unrefined in Figure 2.6a when generally isotropic elements are used, but when the mesh is refined to im-plement anisotropic elements along areas of strong velocity gradients (i.e., the flow crosses many mesh element boundaries in a short distance), the Mach number gradients become smooth and distinct, as shown in Figure 2.6d.
To directly attribute the improved simulation results to the use of anisotropic elements, and not an increased element count, Ollivier-Gooch and Sharbatdar (2013) compare results
Mach: 0.7 0.9 1.05 1.2
(a) Generally isotropic mesh (2543 vertices)
Mach: 0.7 0.9 1.05 1.2
(b) Initial refinement (3816 vertices) Mach: 0.8 0.925 1.1 1.45
(c) Further refinement (13348 vertices)
Mach: 0.8 0.925 1.1 1.35
(d) Generally anisotropic mesh (19381 vertices)
Figure 2.6: Use of anisotropic elements on areas of high velocity gradients. Mach gradients smoothed as long, thin elements are used in key areas within the mesh. Ollivier-Gooch and Sharbatdar (2013)
of a more-isotropic (“non-smooth”) mesh and a more-anisotropic (“smooth”) mesh with a similar vertex count (19995 and 19381, respectively). Figure 2.7a shows the difference in the two meshes, with the highly skewed elements concentrated in the area of shock above the airfoil. In Figure 2.7b, Ollivier-Gooch and Sharbatdar (2013) compare the difference in pressure coefficient and mach number for each mesh along the airfoil. These plots show that the computed shock along the smoothed mesh is sharper and has less overshoot when compared to the non-smoothed mesh.
Indeed, Berzins (1998) reached a similar conclusion in his paper, where he presents a tetrahedral mesh quality measure using both geometric and solution information. Taking the flow conditions, as well as the geometry, into account when modifying a mesh is the best procedure when faced with especially strong gradients:
The overall conclusion is that the only really satisfactory approach would seem to be to use an error estimator based on both solution and geometry information to modify the mesh. This would appear to be true for strongly directional fluid flows for which highly distorted meshes appear to be very effective. [Berzins (1998)]
Peraire and Morgan (1997) develop another mesh refinement algorithm based on the idea of modeling mesh elements after the anisotropic nature of aerodynamic flows; they call it “directional refinement”. In addition to the elements being stretched parallel to distinct flow features, Peraire and Morgan (1997) go further and specify that the mesh must have elements that are stretched such that “the largest angle in any triangle or tetrahedron is close to ninety degrees”. For this refinement algorithm, every point in space is assigned a scalar value δ which is “the distance between that point and the nearest point on a specified curve or surface”. If δ is too large, more points are added between the two points. Figure 2.8 shows the mesh refinement from this algorithm on a turbine blade: Figure 2.8a is the unrefined isotropic mesh, and Figure 2.8b is the directionally refined mesh. The method of adding more points/elements if the spacing (δ) is too large is fairly simple, but what is interesting is the condition that the largest angle in each element must be no greater than 90 degrees. This restriction of no obtuse triangles is notable for reasons to be explored in the following section.
(a) Left: smoothed (anisotropic) mesh, 19381 vertices; Right: non-smoothed (isotropic) mesh, 19995 vertices) X/C -C P 0.4 0.5 0.6 0.7 0.8 -0.5 0 0.5 1 1.5 Smoothed Non-smoothed
(a) Pressure coefficient distribution
X/C M ac h n u m b er 0.4 0.5 0.6 0.7 0.8 0.6 0.8 1 1.2 1.4 Smoothed Non-smoothed
(b) Mach number distribution
(b) Comparison of results from smoothed (generally anisotropic) mesh and from non-smoothed (generally isotropic) mesh. Computed shock on smoothed mesh has little overshoot and is sharper in comparison with non-smoothed mesh.
Figure 2.7: Comparison of anisotropic (“smooth”, 19381 vertices) and isotropic (“non-smooth”, 19995 vertices) meshes. Ollivier-Gooch and Sharbatdar (2013)
Figure 4: Turbine blade: original unre ned mesh
Figure 5: Turbine blade: directional re nement based on distance to blade leading edge 10
(a) Isotropic mesh
Figure 4: Turbine blade: original unre ned mesh
Figure 5: Turbine blade: directional re nement based on distance to blade leading edge 10
(b) Directionally refined
Figure 2.8: Directional refinement of mesh along the leading edge of a turbine blade. Left figure shows a rough isotropic mesh throughout; right figure shows anisotropic refinement along the leading edge,, gradually becoming isotropic in the chord direction. Peraire and Morgan (1997)
2.3 Element Quality
Upon research into element quality metrics, a few conditions proved to be directly appli-cable to Pointwise; in some cases, Pointwise uses these conditions for its own mesh quality checks. Brandts et al. (2011) consider two simple but indicative element qualities: minimum angle condition and maximum angle condition. For an element to satisfy a certain minimum angle condition, the interior angle of a 2-D mesh element must be greater than some angle (α) where α is greater than zero. Conversely, for an element to satisfy a maximum angle condition, the interior angles must be smaller than some uniquely-specified angle γ where γ is less than 180 degrees. Citing Babuˇska and Aziz (1976) for Equation 9, where the smooth solution u and the finite element approximation uh is equated to a constant C multiplied by the discretization parameter h and the seminorm of the smooth solution, Brandts et al. (2011) summarize this finding: “the minimum angle condition is not necessary to achieve convergence [of the finite element method]”.
Figure 2.9: 200 triangles used to render a paraboloid. Obtuse triangles cause a rough approximation, whereas acute triangles aren’t excessively detrimental to the rendering. Shewchuk (2002)
This finding proves to be extremely useful in meshing, where nearly flat (degenerate) ele-ments may be useful for “covering thin slots, gaps, or strips of different materials” Brandts et al. (2011). These flat triangular elements are also useful in a fluid dynamics sense, where a flow condition gradient may change rapidly in one direction than in a different direction; this is the motivation behind applying anisotropic elements to CFD meshes.
The impact of excessively large interior angles is illustrated in Figure 2.9. Each mesh approximates a smooth paraboloid. The left rendering is composed of equilateral triangular elements and provides a reasonable approximation. The right rendering is composed of long thin elements with angles no greater than 90 degrees; the approximation for this mesh is only slightly worse than the equilateral approximation. The center rendering, however, is composed of obtuse triangles with angles approaching 180 degrees, and the approximation is significantly worse than the left or right meshes.
Figure 2.10 assigns arbitrary nodal values to an element and shows how obtuse triangles can cause excessively large interpolation errors. Arbitrary values are assigned to each node. At the midpoint of the bottom-most edge, the interpolated value is 50 (midway between 35 and 65). As the obtuse angle approaches 180 degrees, the known nodal value (40) gets
35
50
65
40
Figure 2.10: The error between the interpolated value (50) and the known nodal value (40) grows extremely large as the largest angle approaches 180 degrees. Shewchuk (2002)
physically close to the interpolated value (50) and causes a large interpolation error (10) [Shewchuk (2002)]. This would not occur in the case of acute angles, where two angles approach 90 degrees and the third approaches 0. The obtuse elements may be split into smaller elements, but this increases node/element count and thus computational time.
As mentioned earlier, these angle conditions mirror how Pointwise determines the “qual-ity” of mesh elements. Pointwise goes further to create a few normalized parameters to measure element skew in 2-D and 3-D: they are Equiangle Skewness, Equiarea Skewness, and Equivolume Skewness. Equiangle Skewness is applicable to 2-D and 3-D elements, and is calculated in Equation 10: max Q max− Qe 180 − Qe ,Qe− Qmin Qe (10)
where Qmax is the largest angle in the element, Qmin is the smallest angle in the element, and Qe is the angle for an equilateral element (60 for a triangular element), all in degrees [Pointwise (2018a)]. This parameter ranges from 0 (“good”) to 1 (“bad”); the documenta-tion recommends a value below 0.8 for a “good grid”, and values below 0.9 are “acceptable, depending on the solver”. Equiarea and Equivolume Skewness are for 2-D and 3-D tetra-hedral elements, respectively, and are calculated in Equation 11:
Optimal Cell Size− Actual Cell Size
Optimal Cell Size (11)
where Optimal Cell Size is the area or volume of an equilateral cell with the same circum-radius as the actual cell. Like Equiangle Skewness, values below 0.8 are recommended for a good grid, and values below 0.9 are acceptable depending on the solver Pointwise (2018b).
CHAPTER III
PROGRAM FEATURES
The first conceptualization of ARMET involved some sort of user interface (UI) where the user could execute commands, monitor the progress of the current operation, and edit pre-processor variables or preferences (e.g., initial flow conditions, file paths, program direc-tories). The programming language Python was chosen as the language to develop ARMET for several reasons. First, Python can utilize TkInter, a UI package that creates a straight-forward interface of buttons, messages, progress bars, and images for the user to interact with. Second, Python has great versatility in imported libraries: NumPy and Matplotlib allow for MATLAB-like mathematical operations and plotting, os and subprocess allow for Python to operate system applications through traditional terminal commands, and thread-ing allows the running of multiple tasks at the same time. A flowchart outlining ARMET is shown in Figure 3.1. ARMET Select Aircraft XLS File ARMET Creates SolidWorks Curve Files Create Geometry ARMET Opens SolidWorks, Creates the 3-D Geometry, and Exports the File
Scale CFD Bounding Box (Optional) Create Mesh (Pointwise) Review Mesh Quality Report Modify CFD Input File Modify HPC Command File File Directory Preferences ARMET Opens Pointwise, Creates a Mesh,
and Exports the File
Figure 3.1: A flowchart outlining the structure of ARMET (Automated useR-interfaced Multi-software Educational Tool). Major operations are bolded.
Figure 3.2: User selection of a JET spreadsheet containing 3-D geometry data.
3.1 Spreadsheet Manipulation
Upon opening ARMET, the user is greeted with a clean and simple main window where core operations can be executed. The first button, Select JET XLS File, prompts the user to select a spreadsheet file known as Jet Designer (Figure 3.2). Jet Designer was developed by Dr. Steve Brandt of USAFA in 2003 as a means of calculating a multitude of information about a particular aircraft (aerodynamic analysis, geometry, cost analysis, thrust modeling, etc); this program only reads geometry information, which is in the form of 3-D coordinate (XYZ) points. These coordinate points represent cross-sectional and longitudinal guide curves of the nose, fuselage, wings, tail sections, and optional strakes of the aircraft. SolidWorks is incapable of reading this data in the raw spreadsheet format, so a Python code was written to create SolidWorks Curve Files (.SLDCRV) with the help of the numpy library for rearranging arrays and writing to files. Each SLDCRV file contains coordinate points that either forms a single closed loop for each geometry cross-section or a single open loop for a guide curve. By systematically importing these newly-created files into SolidWorks, the sequential numbering of these curves in SolidWorks remains consistent across all aircraft and thus a dependable SolidWorks macro can be developed. For reliable access, the SLDCRV files are written to the SolidWorks Data directory on the main C:/ drive. This directory is created by default when SolidWorks is installed on a Windows PC.
3.2 SolidWorks Macro
Once the SLDCRV files are created, ARMET will confirm the name of the spreadsheet from which the data was extracted, and the program is ready to create the 3-D geometry. When the user clicks on the second button (Run SolidWorks), ARMET will open SolidWorks and run a pre-written macro (JET Curve Import.swp). This macro reads each curve file from the SolidWorks Data directory, draws these curves in the model space, and lofts each piece of the aircraft according to the guide curves also generated in the code. Because ARMET was tasked with writing and naming the curve files, the SolidWorks macro can depend on filename and coordinate data order for import.
SolidWorks was chosen as the CAD program for this operation because it is used for USAFA courses and comes installed on cadet computers. Additionally, it was a favorable program to use because it is generally lenient when the macro comes across a potential error. For example, the macro calls for import of wing strakes which exist in aircraft such as the F-16 and the F-22, but not the F-106A or the T-38. Rather than stop the geometry creation and display an error message for the latter two aircraft, SolidWorks simply skips the operations for which there is no import data. Its sole acknowledgement of this discrepancy during operation is the error audio tone, which may sound several times during the macro run.
Strake geometry proved to be the most difficult feature to create because of the variation of information provided in the JET spreadsheet. As previously mentioned, aircraft with no strakes could simply skip that part of the macro. Aircraft with strakes, however, had varying definition to strake geometry; sometimes the strake was defined by a single airfoil profile located along the fuselage surface (e.g. F-16), and sometimes the strake was defined by two airfoil profiles: one located along the fuselage and another offset away from the fuselage, meant to represent the strake tip (e.g. F-22). The latter case could be treated the same as the main wing loft, but the former case required additional 3-D sketches to form the boundaries of the strake. These boundaries formed a triangle shape when viewed from above, meaning that the strake extends out to a point rather than a new, smaller airfoil profile. USAFA instructors confirmed this was an appropriate estimation to make, given
Figure 3.3: Extrusion required to close gap between strake and fuselage on F-22 SolidWorks model. Only one strake shown for clarity.
the simplicity of the model as a whole and the level of CFD simulation that will be run. Unfortunately, the strakes had another problem. The “root” airfoil profile along the fuselage surface was not perfectly flush with the fuselage loft, meaning the strake was at times floating offset from the fuselage and at times protruding into the fuselage. The strake-fuselage interference was not an issue because the model will be treated as a solid body, but the gap was a problem and needed to be filled. However, because the strake root was at times halfway inside the fuselage, SolidWorks would not allow a simple loft between the profile and the fuselage surface. A new 3-D sketch creation and extrusion had to be performed to fill the gap, as shown in Figure 3.3.
Once all the curves have been imported and lofted, the appropriate features were mir-rored across the plane of aircraft symmetry and the model was made into one solid watertight entity using the “Combine” feature. This proved to be the simplest way to get Pointwise to accept the model as watertight; several trials that led to this conclusion will be explained in the following sections. This solid model was then exported as a STEP file to the same SolidWorks Data directory, and SolidWorks closes. ARMET then asks the user if he or she
would like to review the model. If yes, SolidWorks will open the model for review; if no, the program is ready for mesh generation.
3.3 Pointwise Meshing
Pointwise can use a script to automate tasks much like how SolidWorks uses a macro; both even include a record function that proved to be useful in writing the scripts and quickly finding the name and format of a particular function. Rather than SolidWorks’ VBA language, Pointwise uses the language Glyph, based off the programming language Tcl. Documentation for Glyph is readily available online and has proved to be extremely useful in developing the script, but the lack of a website search made it difficult to find a particular function at times; often, it was quicker to record the action manually and view the generated code to learn the proper function syntax.
At first, it made sense to try to write the script with the same procedure as a manual meshing of a model. Typically, one would import separate bodies into Pointwise and assign different layers for different features; this makes applying actions to certain features reliable and easy to maintain. However, the uncertainty in the aircraft geometry being considered – presence and type of strake, horizontal tail position, main wing intersection with fuselage or tail, and any combination of these characteristics and more – made it extremely difficult to create a one-size-fits-all script. I will call this trial (trying to create the script by treating each aircraft component as a distinct entity) the “Separate Body Approach”.
3.3.1 Separate Body Approach Intersections Within Pointwise
It is generally convenient to keep aircraft features in separate layers upon import. Ap-plying mesh properties to a single layer is simpler to track than continuously selecting cer-tain features. The script could then create lists of database entities (the geometry curves, points, etc), connectors (one-dimensional grid elements), or domains (two-dimensional grid elements) and apply a common action to any list or lists. However, problems would arise when dealing with intersecting geometry, and trying to command Pointwise to perform the
Figure 3.4: Connectors in Pointwise that run along the geometry of the aircraft. By im-porting each aircraft component separately, some connectors protrude within volumes that should be solid (e.g., fuselage).
intersection at a particular location.
For example, SolidWorks lofts the main wing through the fuselage (and depending on the aircraft, the tail section as well), which means there is wing geometry inside the fuselage. Pointwise does not recognize the wing-fuselage interference and will create continuous con-nectors that run through the fuselage surface, as shown in Figure 3.4. In order to eliminate interior connectors, one would first force Pointwise to detect an intersection between the two bodies and split the connectors at this intersection. For a human operator, deleting the newly-formed interior connectors is simple – visually identify the interior connectors, select them, and delete. For a script, however, distinguishing interior and exterior connectors became extremely convoluted and risky.
For the case of the wing/fuselage intersection, the script first found the average Y-position of the fuselage surface where the wing intersection occurs and made that Y-Y-position a threshold value. Wing connectors with an average Y-position greater than this threshold are preserved, while connectors with an average Y-position less than this threshold are deleted (Figure 3.5a). While this worked for the F-16 wing/fuselage intersection, it did not work for the F-16 strake/fuselage intersection. The front of the fuselage curves substantially
(a)
(b)
Figure 3.5: Methods to distinguish connectors that need to be kept or deleted. Above: script takes average Y-position of intersection curve as threshold condition. Below: script splits curve into ten sections and finds average Y-position of each for threshold position, resulting in a finer approximation. Intersection curve is exaggerated for illustrative purposes.
such that the average Y-position is too rough of an estimation to represent the intersection as a whole. Therefore, some small connectors were susceptible to wrongful deletion or preservation. A solution to this would be to analyze more points along the intersection connectors; rather than solely depend on the average Y-position of the connector, Pointwise could determine the XYZ-position of ten points along the connector and assign a Y-position threshold as a function of X-position (Figure 3.5b).
A finer resolution for Y-position threshold seemed to be a good solution until the script encountered multi-feature intersections in the F-22. In this case, the main wing not only intersects the fuselage, but it also intersects the strakes, the horizontal tail, the vertical tail,
(a) (b)
Figure 3.6: Left: Multiple features intersecting each other for F-22. Right: Horizontal tail intersects only vertical tail for F-104C.
and the tail of the fuselage, which is treated a separate entity from the main fuselage. The F-104C was another unique case in that the horizontal tail only intersects the vertical tail (see Figure 3.6. Following the technique of evaluating the intersection with ten points along the connector will now have to work in three dimensions. As this was tested for several aircraft, the script often missed connectors that should have been split, and retained connectors that should have been deleted. The script was becoming convoluted for the luxury of discrete layers for each aircraft feature. The multitude of aircraft that could be created with the JET spreadsheet is so great that it becomes exceedingly difficult to account for each unique case, especially for the eventual application of this program: basic meshes for basic CFD simulations.
Pre-Cut Components
A potential solution to handling intersections is to perform the appropriate cuts in SolidWorks before importing each feature into Pointwise. SolidWorks is well equipped to handle an intersection cut between two interfering bodies: the “Intersect” function allows the user to select two or more bodies and dictate whether SolidWorks should preserve the interior or exterior sections of each body. By selectively exporting each body into STEP files, the Pointwise script should be able to import each part separately and negate the need for Pointwise intersections.
Import was successful, but unfortunately there were some unexplained discrepancies between the geometry is SolidWorks and the geometry in Pointwise. For example, the strakes in the F-22 were cut correctly in SolidWorks, but upon import into Pointwise a
Figure 3.7: Gaps between geometry features when viewed in Pointwise. Upon meshing, Pointwise treats features as separate and introduces surfaces that prevent a watertight model.
small gap mysteriously appeared between the strake and the fuselage (see Figure 3.7). It is unclear why this is occurring: perhaps Pointwise is not as robust as SolidWorks when handling geometry, or perhaps the refinement in which SolidWorks exports STEP file is not read well by Pointwise. No matter the cause, the unreliable import of multiple bodies made this method unattractive.
3.3.2 One Body Approach
Another potential solution is to import the entire aircraft as one solid body into Point-wise. While this process loses the nuance of separating components of the aircraft into distinct layers, Pointwise would be able to detect intersections without further action from the script. To create one solid body, the SolidWorks macro simply uses the “Combine” feature, and a single body is created. Once that body is imported into Pointwise through a STEP file, all bodies are accounted for and intersections are detected (see Figure 3.8).
Figure 3.8: Intersections automatically detected with import of a single combined model into Pointwise. Note that there are no connectors within the interior of the aircraft model.
3.3.3 Meshing
The mesh is always set to be unstructured and composed of triangular or tetrahedral elements, per USAFA instructor request. An unstructured mesh will fill the surface or volume with elements in a non-uniform fashion; given the wide variation in aircraft to be meshed through this program, it would be difficult to establish a structured mesh where elements are placed in a particular pattern. Pointwise begins defining the mesh grid density by assigning a certain discretization to each connector – it calls this “dimensioning”. For example, assigning a dimensioning value of 50 means that there are 50 nodes within that connector; edges of mesh elements must be joined by nodes for a valid mesh, so the number of mesh elements bounded by that connector correlates with the dimensioning number. Alternatively, one can assign an average spacing value (∆s), where Pointwise will compute the number of grid points for the connector that most closely matches ∆s.
Since the connectors being considered vary greatly in length, setting a global dimension-ing value may result in overly fine grid density for short connectors and overly coarse grid density for long connectors. Therefore, it would be more appropriate to assign a global av-erage spacing ∆s value for a first iteration. Rather than having the ARMET user explicitly
Surface Coarse Fine Recommended Wing/Fuselage Intersection 82 135 100
Wing Leading Edge 93 154 150
Fuselage Body Length 200 332 250
Table 3.1: Number of grid points along connectors for a Coarse or Fine mesh on the F-22 aircraft. Recommended numbers from course instructors.
state a value for ∆s, the program instead suggests two presets: “Coarse” and “Fine”. The “Coarse” preset assigns a ∆s of 0.0762 meters. For areas of the aircraft where connectors are relatively short in length (e.g. wing/fuselage intersection), this ∆s yields a node count of about 80, whereas areas of longer spanning connectors (e.g., fuselage body) have a node count of about 200. Conversely, the “Fine” preset assigns a ∆s of 0.04572 meters. Node counts for the two types of areas listed above are about 140 and 330, respec-tively. Table 3.1 summarizes these values, and compares them to recommended values from USAFA instructors.
From defining the number of grid points, Pointwise has a simple and reliable way to generate domains (2-D surface meshes) through the “On Database Entities” command. Available through the Pointwise GUI or through the Glyph scripting language, this com-mand allows Pointwise to create domains aligned with the geometry without first having to define connectors; Pointwise will assemble the connectors onto the domains. This has proven to be a reliable method across several aircraft. Once these domains are established, the creation of a block (3-D volumetric mesh) is simple: the bounding box domains are grouped together as one face (facing inward) while the aircraft domains are grouped to-gether as another face (facing outward), and Pointwise can then create an unstructured block.
Assigning quantitative boundary conditions to each face is unnecessary because the Kestrel input file will contain information on incoming flow conditions. Pointwise will, however, assign the bounding box face a farfield boundary and the aircraft face a no-slip wall boundary. From this step, Pointwise then initializes the block. Initializing the block populates the volume with nodes that define the tetrahedral mesh elements; this process is the lengthiest step in the script, but given the relatively low resolution of these meshes,
Figure 3.9: Window to modify Kestrel XML input parameters from ARMET.
initialization rarely takes more than a few minutes. After initialization, the script exports the mesh in an .AVM format, ready for simulation in Kestrel.
3.4 Kestrel Input
As mentioned before, the Kestrel CFD program requires an input XML file in addition to the mesh file. This XML file contains information such as freestream inlet pressure, temperature, Mach number, and other qualities about the incoming flow. Rather than forcing the user to modify the XML in a text editor, ARMET provides a window in which all editable parameters are listed in a table, with the current values displayed next to the variable. By clicking “Apply Changes”, ARMET rewrites the XML file to accommodate any changes. This window is shown in Figure 3.9.
If Kestrel were run locally, the AVM mesh file and the XML file are the only necessary input files for running a CFD simulation. However, USAFA students utilize a network of high-performance computing (HPC) machines to run CFD simulations. For this operation, a special command file called “runqCopper” is required to instruct the HPC machine (Copper) to locate the Kestrel XML file, the mesh file, and the CFD program itself to run the
Figure 3.10: ARMET window to edit runqCopper information (above) and the runqCopper file contents (below).
simulation. Additionally, runqCopper lists the computing core allocation, the allocated run time, and the job priority level. ARMET includes a window to change these qualities about runqCopper, under Edit >Edit runqCopper. This program window is shown in Figure 3.10, along with the contents of the runqCopper file.
3.5 Additional Program Features
The Edit toolbar tree is also the location for the user to change certain ARMET prefer-ences that don’t necessarily need to be changed with each model. For example, the location of the SolidWorks executable and the Pointwise executable may not be consistent across all computers; in this case, the Preferences window allows the user to remap the file location
Figure 3.11: Window to modify the size of the CFD bounding box.
of these programs. Moreover, rather than have ARMET dictate the output folder for im-portant files like the mesh file, the CAD model file, the XML file, and more, the Preferences window lets the user select their own output directory for these important files.
Another quantity that is infrequently changed is the size of the bounding box for the CFD simulation. Under Edit >Bounding Box..., the user can dictate the size of the bounding box in each dimension as a function of aircraft length. This was designed as such because as the length of the aircraft changes, the bounding box scales appropriately without user intervention. With this scaling, the user shouldn’t have to change these parameters often, making this feature appropriate for the Edit toolbar tree. The window to edit the bounding box size is shown in Figure 3.11.
3.6 Packaging as Executable
A particularly useful feature of ARMET is that all necessary components–data files, the Python code, and the Python interpreter itself–are in one compressed archive, with ARMET launching as an executable file. The approximately 200MB uncompressed executable
pack-age is created with cx Freeze, a set of scripts and modules used to packpack-age Python scripts into executables. By utilizing cx Freeze, ARMET can be distributed as one archive with version control, rather than a set of files. Moreover, the inclusion of the Python interpreter means that ARMET does not require Python to be installed on the computer in order to run. This makes ARMET more accessible and easier to use for a wider range of users who perhaps do not have experience running Python scripts, or who have a different version of Python installed on their computer. As implied by the executable format, opening ARMET will only work for Windows operating systems, and the code itself uses Windows file path conventions, command window prompts, and a user interface reminiscent of a Windows program.
CHAPTER IV
MESH REPORT
With features demonstrated in the previous section, the program ARMET developed in this research has fulfilled its purpose for USAFA classroom use. Student work time for pre-CFD steps (e.g., building the 3-D model, generating a valid mesh, gathering necessary command/run files) will decrease significantly and educators can spend more time on the core subjects of the CFD course. However, as it became clear exactly how much workload would be lifted from student responsibility, the opportunity arose to expand the program as an educational tool rather than leave it as a “black box” only valuable for its output.
ARMET has two operations that save the most student time: creating the 3-D aircraft model in SolidWorks and generating the 3-D mesh in Pointwise. One option to expand ARMET as a more effective educational tool is to provide guidance and feedback on the 3-D model in SolidWorks. As this idea was further considered, it quickly became obvious that the amount and quality of help the student would receive on the geometry would be limited. First, it would be extremely difficult to provide practical feedback on the geometry because ARMET – nor SolidWorks – would know the intentions of the student. For example, perhaps ARMET could have some level of gap detection to close gaps in the geometry, but there are often intentional “gaps” like the small gap between the strake and the leading edge of the main wing on the F-16. Second, the SolidWorks documentation is extensive, easy to search for on the internet, and provides great detail with step-by-step written and video tutorials. ARMET would not be able to provide a uniquely beneficial experience to the student compared to the SolidWorks documentation or the online resources.
for practical feedback because the mesh has qualities that are quantifiable through well-proven metrics. Pointwise is aware of these metrics and even provides certain statistics on the completed mesh for user review. Moreover, meshing is arguably less intuitive and a skill that most undergraduate students lack compared to creating a model in SolidWorks. 3-D CAD has immediate feedback in that the model looks incorrect if it is incorrect; an “incorrect” mesh is far less obvious based on appearance. Therefore, the meshing step appears to be the opportune part to expand ARMET’s use as an educational tool. By clicking Mesh Report after Pointwise has completed its meshing operation, ARMET will generate a report on the mesh for student review.
4.1 Scripting Limitations
As mentioned above, Pointwise has data and statistics on the elements within a mesh available for user review. These functions are available through the Examine menu through the Pointwise user interface and include measures such as Volume, Edge Length, Aspect Ratio, various measures of skewness, and more. By selecting one or more domains or blocks, the user can see the range of values for each of these functions; perhaps the most useful representation of this data is through a histogram graph, where the user can quickly see the average and extreme values for each measure.
Unfortunately, accessing this data cannot be done through the Pointwise interface and must be done through Glyph script. Upon reviewing the Glyph documentation, the list of commands available under the Examine menu is severely limited compared to the available commands through the Pointwise interface. Even by recording actions and letting Pointwise write the script, the functions not available in the Glyph documentation were simply omitted from the script, so there was truly no scriptable commands for many of these operations. As disappointing as this was, there were a few key statistics that were scriptable and provide reasonably good measures to provide mesh feedback. These statistics are described in the following sections.
Figure 4.1: Distribution of minimum included angle of elements within all domains (left) and the volumetric block (right). X-axis indicates the minimum included angle of any given element; Y-axis indicates the number of elements that fall into a particular angle range.
4.2 Minimum Included Angle
One available set of data is the minimum included angle, which reports statistics on the smallest angle within each 2-D or 3-D element for any selected domain or block. As discussed in the literature review, allowing too small of a minimum angle may cause ill-conditioned linear systems that are difficult to solve accurately, and may lengthen the CFD simulation run time Bern et al. (1994). However, the literature also states that small angles may be necessary to represent thin geometry, and may even result in more accurate solutions along areas of flow anisotropy Ollivier-Gooch and Sharbatdar (2013).
Upon opening the mesh report, the student will see a brief definition of the minimum included angle and two graphs displaying the range of minimum included angle for all domains and the block. A red vertical line at 12 degrees marks the threshold value where the automation program will consider the minimum included angle to be “too small”. 12 degrees was chosen because this value results in an equiangle skew of 0.8; the significance of this measure and value will be discussed in a later section. These graphs are shown in Figure 4.1. Also in this section of the report is an illustration from Ollivier-Gooch and Sharbatdar (2013) showing the value of anisotropic elements with a small interior angle in accurately representing the Mach number gradients on an airfoil. This figure is shown in Figure 2.6b.
4.3 Maximum Included Angle
Pointwise also has the capability of exporting data on the maximum included angle, or, the largest angle within each 2-D or 3-D element for any selected domain or block. The relevance of measuring the largest interior angle of each element is explained in the literature. Most notably, a large interior angle can cause large interpolation errors with known nodal conditions, as best illustrated in Figure 2.10. Figure 2.9 also visually demonstrates the poor approximation of a paraboloid by using obtuse triangles, especially when compared to acute or equilateral triangles.
Data on the maximum included angle for the student’s mesh is shown in the report along with a brief description of the relevance of this measure. The two bar graphs show the range of angles across all 2-D domains and the 3-D block. A red vertical line at 156 degrees marks the threshold value where ARMET will consider the maximum included angle to be “too large”. 156 degrees was chosen because this value results in an equiangle skew of 0.8; the significance of this measure and value will be discussed in the following section. Moreover, a maximum included angle of 156 degrees is consistent with existing algorithms to limit large interior angles. Miller et al. (2007) analyze the Overlay Stitch Meshing algorithm (OSM), which consists of three phases: Overlay, Stitching, and Completion. They are described as follows and illustrated in Figure 4.2:
In the first phase, a standard point set meshing algorithm is run on the input vertices to form the overlay mesh. In the second phase, the input edges are stitched into the mesh...The Stitching phase will leave some non-triangular faces. In the last phase...these leftover faces are triangulated to minimize the largest angle. [Miller et al. (2007)]
The OSM algorithm guarantees that no interior angle of any element will be larger than 170 degrees, and results in a mesh “competitive with any optimal triangulation that is conforming and good quality”. Their motivation for bounding the maximum interior angle is explained through the Babuˇska and Aziz (1976) paper – where large angles affect interpolation error – and the Boman et al. (2004) paper – where only large angles affected the convergence of elliptic finite element problems. Therefore, marking the maximum angle threshold at 156 degrees seemed like a reasonable and safe bound for student guidance.
Figure 4.2: From left to right: the Overlay step, the Stitching step, and the Completion step of the OSM algorithm. Miller et al. (2007)
4.4 Equiangle Skew
The last metric available for review through the mesh report is Equiangle Skew. This is a normalized value where a skew closer to 0 is considered “good” and a skew closer to 1 is considered “bad”, according to Pointwise documentation Pointwise (2018a); Equiangle Skew is calculated by Equation 11. Like the previous bar graphs for minimum and maximum included angles, there is a red vertical line that marks the threshold where an element is considered to be “too skewed”. This line is placed at 0.8 for a couple reasons. First, Pointwise documentation recommends that the skewness measure be kept below 0.8 for a “good grid”, and a value below 0.9 is “acceptable, depending on the solver”. While the documentation does not explain its motivation for these values, they are generally consistent with the maximum angle constraints explored in Boman et al. (2004), Miller et al. (2007), and Babuˇska and Aziz (1976). Second, the motivation behind presenting a mesh report to a student is to encourage a deeper look into the element qualities of the mesh, namely, the cause of a highly skewed element: is it the result of an excessively small angle? A large angle? Is this element representative of the flow conditions in that region, or is it seemingly random and ill-suited for that area? Setting the threshold value at 0.8 will trigger warnings within the automation program more often than, say, a threshold value of 0.9, thus encourage a review of the mesh.
Figure 4.3: An example report summary on a single domain. In this case, a coarse mesh on the strake of the F-16 results in very small interior angles on a few 2-D elements, which causes a skew value larger than 0.8. As before, X-axis indicates the angle/skew of any given element; Y-axis indicates the number of elements that fall into a particular angle/skew range.
4.5 Domain-Specific Analysis
The final section of the mesh report contains bar graphs for the three measures – mini-mum included angle, maximini-mum included angle, and equiangle skew – only for the domains that trigger the threshold values of 12 degrees, 156 degrees, or 0.8, respectively. Along with these graphs is a Pointwise screenshot of the aircraft with the domain in question highlighted, so the student can quickly identify which domain is causing the “error”. An example of this is shown for a coarse mesh in Figure 4.3.
This example highlights the strake of the F-16 as a potential problem area for the Kestrel solver. A quick review of the accompanying bar graphs shows that a few elements have a skewness value larger than 0.8. Keeping in mind that a skewness value that high can result from large or small interior angles, the user can then review the other two bar graphs to
