CAPS
Computational Aircraft Prototype Syntheses
Overview

Aerospace vehicle design can be described as an evolutionary process of gathering information to make informed decisions. Meticulous application of this process involves numerous simulations covering many disciplines and fidelity levels. A design team needs to be able to easily increase or decrease fidelity as they gather more information about a particular design. To this end a geometry system that can support multi-disciplinary, multi-fidelity analysis from a single source is required. The Computational Aircraft Prototype Syntheses (CAPS), which is a part of the Engineering Sketch Pad (ESP) [7], satisfies the above by combining proven computational geometry, meshing, and analyses model generation techniques into a complete browser-based, client-server environment that is accessible to the entire design team of an aerospace vehicle. CAPS links analysis and meshing disciplines to any ESP geometry model via dynamically-loadable Analysis Interface Module (AIM) plugins. CAPS is accessed from either a browser-based user interface and or Multi-Disciplinary Analysis and Optimization (MDAO) framework through a programming interface. Here, we describe the fundamental building blocks of CAPS and ESP. The paradigm shift of creating geometry for multi-fidelity design is described in detail and represented in ESP scripts. We then demonstrate the use of this multi-fidelity geometry to support multi-fidelity, multi-physics analysis including discipline coupling.

This tutorial will introduce the main concepts and requirements to use CAPS. Before beginning the user should be familiar with ESP and be comfortable with creating parametric geometry inputs in a *.csm file format. For the user not familiar with ESP at a command prompt execute the following.

>>serveCSM

Click on the Help button on the upper left of the screen. This will bring up the Engineering Sketch Pad (ESP) Version X.XX documentation. After completing the tutorials return to this CAPS overview!

Executive Overview

The primary programmatic access point into CAPS is through the CAPS Executive. It is envisioned that there will be 3 different approaches to using CAPS. One way is to interactively build a model and exercise the build to examine aspects such as the design sensitivities. Another scenario is to run one or more analysis packages interactively. Both of these approaches use an enhanced version of ESP (within a Web Browser) to interact with CAPS directly. The last approach has CAPS driven by an optimizer or by an MDO framework, such as SORCER [10], ModelCenter [17] or OpenMDAO [9]. The access, under all of these cases, is through the CAPS API, which in essence, is the portal to all of the CAPS functionality (the lower 2 dotted arrows as seen at the left of the CAPS Block Diagram Figure.

The CAPS API is `object-based' very much in the same manner as both EGADS [8] and OpenCSM [4]. `Object-based' (unlike object-oriented) is a technique that allows for the use of objects in traditional procedural-based programming. This is done with opaque (or blind) pointers that the API functions parse and then perform the desired functions driven by the type of object input. The hierarchy of the CAPS objects can be seen in CAPS Objects Table and include the following types.

capsProblem. The Problem is the top-level container for a single mission. It maintains a single set of interrelated geometric models, analyses to be executed, connectivity and data associated with the run(s), which can be both multi-fidelity and multi-disciplinary. Various data entries can be connected via linkage ports found in all input objects. There can be multiple Problems in a single execution of CAPS and each Problem is designed to be thread safe allowing for multi-threading of CAPS at the highest level.

capsValue. A Value Object is the fundamental data container that is used within CAPS. It can represent inputs to the Analysis and Geometry subsystems and outputs from both. Also, Value Objects can refer to mission parameters that are stored at the top-level of the CAPS database. The values contained in any input Value Object can be bypassed by the linkage connection to another Value (or DataSet) Object of the same shape. Attributes are also cast to temporary ( User) Value Objects.

capsAnalysis. The Analysis Object refers to an instance of running an analysis code. It holds the input and output Value Objects for the instance and a directory path in which to execute the code (though no explicit execution is initiated). Multiple various analyses can be utilized and multiple instances of the same analysis can be handled under the same Problem.

capsBound. A Bound is a logical grouping of BRep Objects that all represent the same entity in an engineering sense (such as the ``upper surface of the wing''). A Bound may include BRep entities from multiple Bodies; this enables the passing of information from one Body (for example, the aero OML) to another (the structures Body).

capsVertexSet. A VertexSet is a connected or unconnected group of locations at which discrete information is defined. Each connected VertexSet is associated with one Bound and a single Analysis. A VertexSet can contain more than one DataSet. A connected VertexSet can refer to 2 differing sets of locations. This occurs when the solver stores its data at different locations than the vertices that define the discrete geometry (i.e. cell centered or non-isoparametric FEM discretizations). In these cases, the solution data is provided in a different manner than the geometry itself.

capsDataSet. A DataSet is a set of engineering data associated with a VertexSet. The rank of a DataSet is the (user/pre)-defined number of dependent values associated with each vertex; for example, scalar data (such as pressure) will have rank of one and vector data (such as displacement) will have a rank of three. Values in the DataSet can either be deposited there by an application or can be computed (via evaluations, data transfers, or sensitivity calculations).

Analysis Subsystem

The Analysis Subsystem is where analysis data is prepared, held, queried, and where meshing is either accomplished or inputs are prepared for the use of a stand-alone grid generation package. A BRep at the proper level of fidelity (optionally with its tessellation) can be retrieved from the Geometry Subsystem, which is used for the meshing process. Again, to maintain the flexibility of CAPS, all specific analysis packages have (at least) one associated plug-in to perform the associated analysis. Multiple plug-ins may be attached to a single analysis package if the analysis has different execution modes (with different input requirements) and/or requiring differing levels of geometric fidelity. See the discussion of the AIM plug-ins below.

This subsystem is responsible for parsing the analysis output and aggregating the results to be passed to the CAPS Executive or maintained within this subsystem to pass on to another analysis module (in a multi-disciplinary setting). The plugin also handles retrieving the salient outputs (that can be constructed as objective functions) from the analysis.

AIM Overview

CAPS connects applications to ESP through Analysis Interface Modules or AIMs. These applications to date have involved meshing or specific analysis tools. Each AIM supplied has a specific tutorial that enables a user to use its intended applications. The current list of AIMs is in the table below

Surface Meshing Volume Meshing Aerodynamics Structures
EGADS Tess.[8] TetGen [19] FRICTION [13] MYSTRAN [3]
AFLR4 [11] [12] AFLR3 [11] [12] AWAVE [14] NASTRAN [18]
- - XFOIL [6] -
- - TSFOIL -
- - AVL [5] -
- - CART3D [1] -
- - SU2 [15] [16] -
- - FUN3D [2] -

For more information on each of the AIMs please see the specific tutorial for the AIM you are interested in. This CAPS overview will continue to introduce the overall features of CAPS. If you are new to CAPS it is recommended that you finish this overview before jumping to the specific AIM tutorials.

The following functions are a part of any AIM plug-in

Attribute/Input Checking. This AIM function is invoked before any mesh/input file generation to ensure that all of the required data can be found.

Meshing. The input BRep and/or tessellation are used to either perform the meshing directly (if possible or the mesh system has an API) or to provide input to a grid generator. Note that the mesh vertices that sit on geometry (as described in the input BRep) need to be associated back to the geometry. This is important for generating parametric sensitivities and performing conservative data fitting. Most stand-alone grid generation systems maintain this data internally but do not make it available as output. Any attempt to re-associate this data by inverse evaluations is slow and not robust.

Quilting. After meshing and the association of the mesh vertices back to the geometry, this function specifies collections of BRep objects that may act as a single engineering ``surface''. This function also specifies element types so that the solver-based discretization is fully described.

Analysis Input File(s) Generation. The input values and attributes found on the geometry are used to construct and generate the input file(s) required to run the analysis.

Output file parsing. This is required to get performance data, displacements, pressures or other information required to be used as input to another analysis module or to inform the optimizer of the objective functional value(s).

Conservative Data Transfer Functions. In order to perform the interdisciplinary coupling in a conservative manner, functions that compute interpolation within a surface element, integration of quantities over an element (and their backward or dual variants) are needed.

pyCAPS

As previous detailed, CAPS is designed to be incorporated into a larger MDO infrastructure; as such pyCAPS provides a light weight, Python-based framework that logically ties together features of the CAPS ``C" API to enable rapid generation of problems in the Python environment. To date not all features of the CAPS API have been utilized in pyCAPS.

In its current state, pyCAPS consists of a single parent class, `capsProblem', and three children classes: `capsAnalysis', `capsGeometry', and 'capsDataTransfer'. The capsProblem class controls the overall workflow for a given problem and contains functions to load the geometry, load AIMs, setup data transfers, etc. The children classes provide additional functionality to the capsProblem class for dealing with specific aspects of their respective domains. Multiple analysis (capsAnalysis class) and data transfer (capsDataTransfer class) objects may be loaded into a single capsProblem object and are book-kept by the class in a dictionary format for easy reference. The following outlines additional details for the children classes:

capsAnalysis A single instance of the capsAnalysis class is synonymous with an instance of a loaded AIM. This class provides the user the ability to set input values (e.g., Mach number, angle of attack), retrieve output variables (e.g., lift or drag coefficient), and other functionality for a given analysis plug-in.

capsGeometry This class consists of functions to interact with the geometry model (e.g., set a geometric design parameter) loaded into a given capsProblem.

capsDataTransfer A single instance of the capsDataTransfer class corresponds to an instance of a capsBound, with capsDataSets being referenced in a dictionary format. The primary function of the capsDataTransfer class is to execute the CAPS routines needed to initiate a data transfer to take place for given variable (i.e., capsDataSet).

Please refer to pyCAPS documentation for a more in depth discussion on its use.

Geometry Attributes

In CAPS, there are two sources of data to perform a computational analysis. These are the geometry itself, and AIM input values. For example, think of a surface on a wing that is a boundary condition for a CFD analysis. This surface can be identified with an attribute that gives it a name. For example:

attribute capsGroup $wingSurface

*Recall that in ESP a '$' designates a string

When this attribute is attached to a specific piece of geometry inside the *.csm input then it can have more information associated with it inside an AIM. For example, if we use the CFD solver FUN3D as an example a pyCAPS entry that defines the above capsGroup attribute may be:

viscousBC = {"bcType" : "Viscous" , "wallTemperature" : 1}
inviscidBC = {"bcType" : "Inviscid", "wallTemperature" : 1.2}
myProblem.analysis["fun3d"].setAnalysisVal("Boundary_Condition", [("WingSurface", inviscidBC),
("WingTip", viscousBC),
("Farfield","Farfield")])

In the entry above two other capsGroup entries are defined WingTip and Farfield. This information will now naturally propagate to any mesh and FUN3D input. This is the point of attribution. It allows information to be located (on the geometry) and defined in a single place.

Every AIM uses attributes and AIM inputs to enable it. These are given in detail in each individual AIM's documentation. AIM documentation includes all the attributes, AIM Inputs, AIM Outputs and Example geometry and pyCAPS inputs to use them.

Many attributes are common across multiple AIMS. Below is a brief description of attributes that will be used in many AIMs. documentation capsGroup. The capsGroup attribute is used to logically group components together and or give a string name to a specific portion of geometry. This is commonly used to identify areas where specific boundary conditions will be applied. The string name used is entirely up to the user. This attribute is used by almost every AIM.

capsType. The capsType attribute is used to separate lifting surfaces and body surfaces in low fidelity aerodynamic tools. This attribute must follow the naming convention defined for a specific AIM of interest. Example AIMs include Friction and Awave.

capsLength. Some analysis tools require that input files be created in a specific unit system. To accomplish this the AIM requires the unit system that the *.csm geometry is created in. This attribute defines this unit system. All conversion is handled by the AIM internally.

capsIntent. Each AIM knows what type of analysis it can support. Geometry input is created with a specific analysis in mind. An AIM can identify the type of geometry has been given automatically, however it cannot determine the intended analysis type the user intends to geometry to support. capsIntent can have the following values: ALL, WAKE, STRUCTURE, LINEARAERO, FULLPOTENTIAL, CFD.

vlmControl. This attribute is used to identify control surfaces in low fidelity aerodynamic tools the vlmControl attribute is used. This attribute can also name the control surface being defined. Users are pointed to documentation specific to the AVL AIM for more information.

Creating ESP Inputs for CAPS

Creating input for use with CAPS must be a forethought not and afterthought! That is if you generate an ESP geometry and then want to use different analysis AIMS on it you may have already made choices in the generation of that geometry that are not compatible with all of the AIMs of interest. To further the discussion the topic of fidelity and how it is used inside of CAPS follows.

Fidelity is the most important thing to keep in mind when generating geometry input for CAPS. There are two types of fidelity in the CAPS system.

Geometry Fidelity. This type of fidelity deals with the type of geometric topology that is being generated. For a detailed review the user is referred to EGADS documentation. For this discussion, a list of the types are given in increasing complexity as: Node, Edge, Loop (closed wire), Face, Shell (empty solid), Body (solid), Model (complex Body). In CAPS it is important to understand that the geometry construction philosophy is to only generate what is required and not attempt to reverse engineer anything.

Analysis Fidelity. This type of fidelity is more common to the everyday engineer. This has to do with analysis fidelity. For example in aerodynamics you may have a tool that only requires wetted area, or a flat uncambered plate, or a cambered mid plane, or a water tight closed solid. These could be used to support analysis of drag, linear aerodynamics, nonlinear transpiration based calculations and or body fitted CFD such as Euler or RANS analysis. At this point reread the above paragraph on Geometry Fidelity. The conclusion is that Geometry and Analysis Fidelity are tightly linked.

After reading about the different fidelity definitions an appreciation of understanding how an ESP model will be used downstream should be forming. That is before any geometry is created the user should have an idea of what it is going to be used for. If the answer is my things (i.e. many different analyses at multiple fidelities) then the appropriate types of geometry must be constructed to support the downstream intentions, and it can be more than one!

Design Parameters

The first step in creating geometry for CAPS at any fidelity is determining the design parameters that will drive the geometry. These parameters have may useful purposes. The first is they make you think about what you are doing. The less sarcastic reasons for them are:

Parametric Geometry Design parameters allow the model you are generating to be parametric. Many times a conceptual designer may inform you what parameters they are interested in.

Analytic Sensitivities When the geometry is created the sensitivity of that final "shape" is calculated with respect to all of the design parameters. These sensitivities may be fed to a mesh and downstream analysis to calculate engineering derivatives that are useful for design space exploration, uncertainty quantification, etc.

Ties Geometric Fidelities Together Possibly the most important reason for design parameters is that it allows the construction of multiple geometry fidelities to support multiple analyses at different fidelities to be tied together. That is all geometry is created from a single source of design parameters. This allows a seamless transition between fidelities without cumbersome reverse engineering or model regeneration.

Set Parameters

The second step is to determine how to manipulate the information defined in the design parameters into data that can be used to layout geometry. This is not always simple. For example,, a wing aspect ratio may be a design parameter. But it does not tell you anything about how to generate geometry. However if another design parameter is span OR area then the opposite can be determined. For example:

# Design Parameters
despmtr AspectRatio 10
despmtr Area 10
# Set Parameters
set Span sqrt(AspectRatio*Area)

This process follows until a complete geometry can be created from the design parameters. It is possible that design parameters may need to be added or removed in this process. A designer using CAPS should determine all design and set parameters before creating ANY geometry.

Geometry Primitives

Next geometry in ESP is constructed in a top down fashion. Many primitive shapes are supplied however the user has the ability to generate UDP's (see ESP documentation for information on this). These primitive shapes will be driven by the design and set parameters previously defined to generate the desired geometry. Not primitives are not required to be solids!

Specific AIM Attributes

Finally, if you are interested in a particular type of analysis it is important to understand what is required of its associated AIM from an attribution standpoint. You need to read that AIM's specific documentation first! Then you need to make sure that the required attributes appear in the ESP input being discussed currently.

Available Documentation

Documentation for CAPS is presented in this overview in addition to a detailed description of pyCAPS and each of the individual AIM applications. What follows is a description of all the available CAPS documentation. In many cases the specific application that an AIM supports is not distributed by CAPS. The AIMs themselves are freely available, however the specific applications must be obtained independently by the user. The documentation for these products discusses the AIMs interface to these tools and do not replace the individual tools documentation. AIMs may make is significantly easier to start using a new capability but they do not replace specific tool knowledge.

General

CAPS_Overview.pdf - This document provides an overview of what CAPS is and how to use it.

InstallationGuide.pdf - A detailed review on installing ESP and CAPS on Windows, Linux and Mac operating systems

pyCAPS.pdf - A complete review of pyCAPS significantly expanding on what was presented in the CAPS_Overview document. pyCAPS is presented in a way that enables a new user to get started and an advanced user to look up detailed information on specific functionality. This document in addition to the ESP help guide are critical to creating geometry and running CAPS.

Meshing

CAPS_AIM_aflr3.pdf - AFLR3 is an unstructured volume meshing software applying Advancing-Front/Local-Reconnection (AFLR) procedure developed by David L Marcum. AFLR3 is not distributed with the CAPS software however an interface is, and is described in this document.

CAPS_AIM_aflr4.pdf - AFLR4 allows the user to generate high quality unstructured 3D surface grids. This AIM interfaces directly with the AFLR4 libraries distributed and developed by David L Marcum.

CAPS_AIM_tetgen.pdf - Tetgen is a free volume meshing technology that’s library is linked to CAPS.

CAPS_AIM_delaundo.pdf - Delaundo is a free 2D meshing technology that has the ability to grow boundary layer meshes for 2D, RANS calculations.

Aerodynamic Solvers

CAPS_AIM_avl.pdf - AVL is a linear subsonic aerodynamic solver developed by Mark Drela. For distribution see: http://web.mit.edu/drela/Public/web/avl/

CAPS_AIM_awave.pdf - AWAVE is a wave drag estimation tool distributed by NASA.

CAPS_AIM_friction.pdf - Friction is a profile and viscos drag estimation tool that is distributed with permission with CAPS.

CAPS_AIM_su2.pdf - SU2 is an open source solver distributed by Stanford University

CAPS_AIM_fun3d.pdf - FUN3D is a NASA developed and distributed solver commonly used by U.S. government agencies and U.S. contractors.

CAPS_AIM_xfoil.pdf - XFOIL is an open source, subsonic airfoil analysis tool developed by Mark Drela. For distribution see: http://web.mit.edu/drela/Public/web/xfoil/ .

CAPS_AIM_tsfoil.pdf - TSFOIL is a transonic airfoil analysis tool available at http://www.dept.aoe.vt.edu/~mason/Mason_f/MRsoft.html .

Structural Solvers

CAPS_AIM_mystran.pdf - MYSTRAN is a free linear structural solver

CAPS_AIM_nastran.pdf - NASTRAN is an industry standard structural solver with nonlinear, aerodynamic and design capability.