Sr. Engineer, Sales & Marketing
Aircraft design is typically segregated into three distinct phases: conceptual design, preliminary design, and detailed design. The varying levels of detail and resolution in each of these design phases drives adoption for a myriad of geometry creation and analysis tools. Organizations whose activities span all three phases are inclined to select tools that can be reused throughout each phase of product development. This is especially true for geometry definition tools where aircraft manufacturers will typically use computer-aided design (CAD) software throughout the product's lifecycle. In doing so, they are able to carry the design forward into each subsequent design phase - a distinct advantage that may not be realized by others whose activities may be more focused.
However, the use of CAD software is particularly ill-suited during conceptual design, where design tends to be very open-ended and typically involves large changes to the geometry definition in order to explore a vast design space. When organizations' activities do not span all three phases of aircraft design, and they cannot expend the resources, expertise, or time typically required for modeling with traditional CAD packages, NASA Langley's team has created a more suitable alternative with Vehicle Sketch Pad (OpenVSP). OpenVSP is an easy-to-use, conceptual-design-centered, and parametric aircraft design tool that enables designers to quickly create 3-D aircraft models. These models may then be analyzed using tools packaged with OpenVSP, exported for further manipulation in other geometry programs, or used in higher fidelity computer-aided engineering (CAE) applications such as finite element analysis (FEA) or computational fluid dynamics (CFD).
NASA Langley hosted its third OpenVSP Workshop 2015 at the National Institute of Aerospace in Hampton, Virginia on 11-13 August. The workshop provided a venue for OpenVSP developers and users (about 65 to 70 attendees in total) to learn more about the software from a range of topics including introductory and advanced model building, recent developments in the software, and several use cases highlighting the diverse utilization of OpenVSP.
The first day of the workshop OpenVSP developers introduced the software. They presented the design goals and motivation for continued development of OpenVSP, and then introduced the various 3-D parametric modeling operations and how they are invoked within the GUI. This was followed by an interactive session where attendees collaborated with presenter Bill Fredericks in a hands-on demonstration where OpenVSP was used to create a Predator B model based on a suggestion from one of General Atomics Aeronautical Systems' employees in attendance. While Fredericks was demonstrating his approach and explaining each step in the modeling process, those in the audience provided assistance by gathering publicly available information related to the aircraft's design. In a testament to OpenVSP's modeling capabilities, the group managed to put together a representative model of the Predator B in about 45 minutes.
The second and third days of the workshop provided an overview of physics-based analysis capabilities packaged with OpenVSP (e.g. mass properties and aero reference tools, a vortex lattice solver, an interactive wave drag prediction tool, etc.) as well as a number of presentations from users demonstrating how they have incorporated OpenVSP into their own work. Highlights included presentations covering rapid aircraft structural modeling, high-lift prediction, and meshing for CFD.
One subtle advantage that models created in OpenVSP inherit, as opposed to those generated using more conventional CAD packages, is that the geometric surfaces are comparatively clean and watertight representations suitable for analysis from the outset. Very little time or effort is required to prepare a model exported from OpenVSP for mesh generation appropriate for FEA or CFD analysis. You are typically not going to encounter models with detailed design elements, gaps between surfaces, missing surfaces, or other common geometry anomalies familiar to FEA or CFD practitioners. As a result, the meshing process for an OpenVSP model is less involved than it would be on a geometry exported from a more detailed design oriented CAD system. Couple this with automated meshing, and integrating high fidelity analysis tools during conceptual design becomes far more feasible--particularly for experimental design or parametric trade studies.
During last year's OpenVSP workshop, Pointwise demonstrated how OpenVSP's built-in surface meshing capabilities could be used in conjunction with Glyph in Pointwise to help automate volume mesh creation. One caveat to this approach was that the surface meshes created within OpenVSP are limited to isotropic triangle elements, which could be locally refined in areas of high curvature using OpenVSP's sources feature. However, this often results in excessive surface cell and point counts as depicted in Fig. 1 due to the number of elements required to adequately resolve the geometry.
This year, the OpenVSP developers further enhanced OpenVSP's STEP file export, making it more robust and including support for easily creating blunt trailing edges. Both of these additions make automation of anisotropic unstructured surface and volume mesh generation in Pointwise, using best meshing practices, relatively straightforward.
Earlier releases of OpenVSP limited the available options for importing a model into Pointwise to a single STL-formatted file - a CAD format that only provides a discrete representation of the geometric model. It is preferable to have an analytic surface definition, rather than discrete information when more localized meshing control and anisotropic surface meshing are needed. The STEP file format both provides an analytic surface representation and can be imported natively into Pointwise.
The ability to include more realistic blunt trailing edges for wings, tails, etc. in OpenVSP models helps improve cell quality, particularly large volume ratios, which can result around sharp trailing edges as shown in Figure 2 when using Pointwise's anisotropic tetrahedral extrusion (T-Rex) feature. Given these changes, we demonstrated mesh automation using a Glyph script that exposes a limited number of user-specified parameters for creating a mesh around one of the generic transport aircraft models available at the OpenVSP Hangar -- a central hub where users can submit and share their OpenVSP models.
While Glyph is often used to automate specific tasks within Pointwise, rather than to mesh entire configurations, the models generated in OpenVSP are typically simple enough for Glyph to be used for this purpose. Furthermore, scripts can be written to accommodate some topological changes to the model; for example, when there are several similar configurations as in an experimental design or parametric design trade study.
In an effort to streamline some of this demonstration, a few geometry cleanup tasks were performed manually prior to executing the script. Typically, each component in the OpenVSP model (e.g. wing, fuselage, tail, etc.) imports into Pointwise as its own watertight collection of B-Spline surfaces assembled as separate models. Ideally, these components would be combined into a single watertight solid model with each analytic surface defined as its own quilt and assigned a unique name in Pointwise. Therefore, surfaces for each component were trimmed with those of adjacent components. The separate models representing each component were then assembled into a single model, and quilts were provided unique names corresponding to their intended analytic surface representation. The final assembled model is shown in Figure 3. While these geometry pre-processing tasks could also be accomplished using Glyph, references to the unique surface names within the STEP file would need to be extracted and explicitly included within the Glyph script. For a model including several surfaces, including these references could be a lot more tedious than performing these operations manually in Pointwise prior to meshing. Doing so also helps prevent coupling the Glyph script to any specific geometry definition. Lastly, model symmetry was used to help reduce the resulting mesh cell and point counts. After a volume mesh has been generated, copying and mirroring the mesh to provide a full model representation are easily managed using the coupled copy, paste, and transform operations available in Pointwise.
The Glyph script begins with several user-defined parameters as illustrated in Figure 4 that allow users to specify a number of options including the input Pointwise project filename, a few edge spacing lengths for initial mesh and isotropic refinement steps, mesh quality criteria, typical T-Rex control parameters, and specific CAE solver to be used.
Next, a database-constrained isotropic mesh is generated on all of the surfaces using the user-specified surface average edge length as shown in Figure 5. The connectors and domains created during this step are assigned descriptive variable names based on the name of their associated quilt for easy recall during the following mesh refinement and T-Rex extrusion steps.
Isotropic mesh refinement is applied to sensitive flow regions including the wing, horizontal tail and vertical tail surfaces using the refined surface average edge length user-defined parameter. Next connectors along the root, tip, and span of the wing, horizontal tail, and vertical tail are given growth distributions, and the grid point dimensions along these connectors are set using the growth rate and aspect ratio parameters specified in the user-defined parameter list. T-Rex is then invoked to extrude anisotropic cells to efficiently resolve areas of curvature at the wing, horizontal tail, and vertical tail leading and trailing edges. The surface mesh that results from anisotropic extrusion on the wing's surface is shown in Figure 6. Before the surface mesh is complete, unstructured domains along trailing edges are replaced with structured domains that are then triangulated to help reduce any large area ratios in these regions of the mesh. Lastly, end spacing of connectors adjacent to the vertical tail are updated to be consistent with the spacing changes made to the vertical tail connectors prior to the T-Rex extrusion step.
Once the surface mesh is complete, the geometric extent of the model is computed in order to determine a center point. This reference point is then used to generate a semicircle given the characteristic length and farfield size parameters from the user-defined parameters list. This semicircle is then revolved around the aircraft's yaw axis centered at the reference point to create a hemispherical surface, and a database-constrained mesh is generated on this surface of revolution for use as the farfield boundary. These domains are shown in Figure 7. The edge connectors created on this farfield domain are used in conjunction with connectors lying along the Generic Transport model's symmetry edge to create a symmetry plane mesh. An unstructured block entity is created from the symmetry domain, farfield domains, and domains on the model's surfaces.
Next, the script sets a number of the 3-D T-Rex extrusion attributes from the user-defined parameters, applies the appropriate T-Rex wall and match boundary conditions to the model's surface domains and symmetry domains, respectively, and then runs T-Rex. After block initialization has completed, a few important mesh quality criteria are output to the Messages window in Pointwise for users to quickly gauge mesh characteristics. Finally, appropriate CAE boundary conditions are applied for the CAE solver specified, and the resulting mesh is saved as a separate Pointwise project file in the working directory from where the Glyph script was originally executed. Figure 8 illustrates a cut plane through the final mesh that results from running the Glyph script. If the underlying geometric definition changes, but the assigned quilt names associated with that surface remain the same, then the script can be re-used across localized changes to the geometry. This becomes a powerful tool for quickly meshing parametric models during experimental design or trades studies.
Rapid conceptual design can often be inhibited by the tools selected during this critical phase of product development. Conventional CA packages are not necessarily well-suited for easily and affordably defining parametric models suitable for the variety of multidisciplinary analysis tasks that engineers typically pursue during conceptual design. The OpenVSP team at NASA Langley has acknowledged these shortcomings and developed a very nicely packaged parametric geometry modeling tool which addresses many of these limitations. More information related to OpenVSP can be found at their website, and presentations from the OpenVSP Workshop 2015 can be found via this link.
Exporting parametric models from OpenVSP for use in high-fidelity analysis tools has become easier now that exporting models to a STEP file is fully supported. These analytic model representations can be readily used within Pointwise to produce anisotropic viscous meshes. Model definitions during conceptual design are typically uncomplicated; therefore, automating the process of meshing entire configurations can be handled entirely within Glyph--Pointwise's scripting environment.
The Glyph script in its entirety along with the sample input Pointwise project file as described here are both available for download at the Pointwise Glyph Script Exchange. Users are encouraged to download both and explore Pointwise's Glyph scripting capabilities as a tool to expedite and automate repeatable meshing processes within Pointwise; or even as in this example, automate meshing of entire conceptual design models.
If you are not a current Pointwise customer, and you want to explore how the software can bridge conceptual design software and high-fidelity CFD, then request a no-cost, no-obligation trial license today.
3rd Quarter of 2017
2nd Quarter of 2017
May 2017, Special Edition
1st Quarter of 2017
December 2016, Special Edition
4th Quarter of 2016
September 2016, Special Edition
3rd Quarter of 2016
2nd Quarter of 2016
1st Quarter of 2016
February 2016, Special Edition
November / December 2015
September 2015, Special Edition
September / October 2015
July / August 2015
June 2015, Special Edition
May 2015, Special Edition
May / June 2015
March / April 2015
February 2015, Special Edition
January / February 2015
November / December 2014
September / October 2014
August 2014, Special Edition
July / August 2014
May / June 2014
April 2014, Special Edition
March / April 2014
January / February 2014
November / December 2013
September 2013, Special Edition
September / October 2013
July / August 2013
June 2013, Special Edition
May / June 2013
March / April 2013
February 2013, Special Edition
January / February 2013
December 2012, Special Edition
November / December 2012
September / October 2012
August 2012, Special Edition
July / August 2012
May / June 2012
March / April 2012
March 2012, Special Edition
January / February 2012
November / December 2011
September / October 2011
July / August 2011
May / June 2011
March / April 2011
January / February 2011