TiGL – An Open Source Computational Geometry Library for Parametric Aircraft Design
Abstract
This paper introduces the software TiGL: TiGL is an open source highfidelity geometry modeler that is used in the conceptual and preliminary aircraft and helicopter design phase. It creates full threedimensional models of aircraft from their parametric CPACS description. Due to its parametric nature, it is typically used for aircraft design analysis and optimization. First, we present the usecase and architecture of TiGL. Then, we discuss it’s geometry module, which is used to generate the Bspline based surfaces of the aircraft. The backbone of TiGL is its surface generator for curve network interpolation, based on Gordon surfaces. One major part of this paper explains the mathematical foundation of Gordon surfaces on Bsplines and how we achieve the required curve network compatibility. Finally, TiGL’s aircraft component module is introduced, which is used to create the external and internal parts of aircraft, such as wings, flaps, fuselages, engines or structural elements.
65D17, 65D05, 65D10
1 Introduction
Optimizing airplane designs often requires a large consortium of engineers from many different fields to work together. Every group of engineers works with a specific set of simulation tools, but almost all tools require information about the current design’s geometry. The TiGL Geometry Library (TiGL) [1] generates threedimensional airplane geometries from a standardized parametric description. It is a piece of software developed mainly at the German Aerospace Center (DLR), in cooperation with Airbus Defense and Space and RISC Software GmbH. These geometries include the outer shape exposed to the surrounding airfield as well as the inner structure of the fuselage and wings that provides the necessary stability.
The Common Parametric Aircraft Configuration Schema (CPACS) is an exchange format for describing airplane design in form of an XMLfile [2, 3]. Among other things, it contains a parametric description of the aircraft geometry that is interpreted by TiGL. TiGL offers the functionality to export these CPACS geometries to standard CAD formats such as IGES, STEP, VTK as well as functions to query points and curves on the airplanes surface. TiGL uses the OpenCASCADE CAD kernel [4] to model the geometries based on Bspline surfaces. Additional geometric modeling features are included on top of OpenCASCADE, such as specialized curve interpolation and approximation functions, surface skinning algorithms and a newly implemented algorithm to interpolate curve networks based on Gordon surfaces. The library also provides interfaces to many common programming languages such as C, C++, Python, Java and MATLAB and comes with a graphical user interface to visualize a CPACS configuration.
TiGL is not the only freely available parametric geometry modeler for conceptual aircraft design. While it is not the intention of this paper to compile a complete list, a few of these tools and publications deserve to be mentioned. OpenVSP [5] is a parametric aircraft design tool for aircraft developed by NASA. Haimes and Drela published on the feasibility of conceptual aircraft geometry design for high fidelity by using a bottomup approach [6]. GeoMACH [7] is a mutlidisciplinary analysis and optimization (MDAO) tool for geometric aircraft design, which supports a large number of design variables by providing also derivatives of the geometry with respect to the design variables. Caesiom [8] is a design framework based on MATLAB that includes a parametric geometry modeler, but also simplified physical simulation tools for aerodynamics, structures, propulsion and flight control. SUMO [9] is a surface modeler specifically designed for conceptual aircraft design that comes with a mesh generator and a postprocessing tool. Finally, JPAD [10] is an analysis tool suite including JPADCAD, an OpenCASCADEbased geometry modeler for aircraft.
This paper is organized as follows. Sections 1.1 and 1.2 will introduce the idea behind CPACS and what role CPACS and TiGL play in multidisciplinary optimization. Section 2 gives an overview of the software architecture and design. Section 3 describes TiGL’s backbone, the geometry module. A special focus is given to the curve network interpolation algorithm used in TiGL to generate interpolating surfaces form a network of profile and guide curves. The CPACS description and TiGL implementation for specific aircraft components such as wings, the airplane fuselage, control surfaces etc. are discussed in Section 4. Finally, the paper closes with a summary and outlook in Section 5.
1.1 CPACS Parametrization
The Common Parametric Aircraft Configuration Schema (CPACS) is a data model that contains parametric desciptions of aircraft configurations, as well as missions, airports, fleets and more [2]. Its development started in 2005 at the German Aerospace Center, when there was an increasing need for a common aircraft model description that can be used in MultiDisciplinary Optimization (MDO) applications. It is specifically designed for collaborative design in a heterogenous environment of engineers from different fields. Engineers can use it to exchange information on their models and tools. Next to the model description, process information is stored so that CPACS can be used to setup interdisciplinary workflows.
CPACS it based on a schema definition (XSD) for XML and as such has a hierarchical structure. On the highest level, the XSD description contains a header with metainformation about the CPACS file, such as a description, creation date, and CPACS version. Next to the header, there are elements for airlines, airports, flights, mission definitions, studies, tool specific information as well as vehicles. The latter element contains descriptions of airplanes or rotorcrafts, engines, fuels, materials, as well as guide and profile curves used for the geometric modeling of components. TiGL uses the parametric description from these elements to construct the aircraft geometry. Section 4 contains details on the parametric description of specific components as well as its interpretation in TiGL.
In late July 2018, CPACS 3.0 was released [3]. The upcoming release of TiGL 3.0 is tightly coupled to some of the major changes introduced in the new CPACS version. Revised definitions for “component segment” coordinate systems or a new simplified definition of guide curve points are two reasons, why TiGL 3.0 is designed not to be backwardscompatible. This means that TiGL 3 will not be able to read CPACS 2 files. This is less errorprone and increases robustness of the code. To make the transition from CPACS 2 to CPACS 3 easier, a converter tool called ”cpacs2to3” is now being developed by the community [11].
1.2 Optimization
Both CPACS and the TiGL geometry library were designed specifically for use in mutlidisciplinary optimization (MDO). The parametric description of CPACS enables users to directly control the configuration of an aircraft with just a small selection of parameters, see Fig. 2. With the help of TiGL, slight modifications of aircraft geometries can be created in an automated workflow. CPACS and TiGL are currently being developed and constantly extentended in research projects related to MDO [12, 13, 14]. Some ideas to increase the optimization capabilities in the future are

to include automatic differentiation in TiGL’s geometry module,

to automatically generate CFD meshes by including an open source mesh library, and

to track mesh deformations through geometry changes and thus provide shape gradients with respect to parameters to an external optimization tool.
2 Software Architecture
As TiGL is open source software, all its dependencies are open source as well. In that sense, it can be used in its full functionality without any commercial license by the users. TiGL is mainly based on the TiXI XML library [15] to read or write the CPACS data sets. TiGL heavily relies on the OpenCASCADE Technology CAD kernel [4], which is used for the geometric and topological modeling, for CAD data exports, to create solids via constructive solid geometry (CSG), and even for visualization.
Internally, TiGL contains multiple modules that are used for the several different aspects of the software. The geometry module includes all operations required to build the curves and surfaces that finally resemble the aircraft shape. These operations are all based on Bsplines and NURBS (NonUniform Rational BSplines). In addition, it contains an extension to OpenCASCADE’s boundary representation (BREP) of shapes that adds metadata to the shapes. These metadata contain information about the shape modification history and the names of the shape and its faces. Since this information is preserved during CAD file exports, it can be used by external mesh generators, e.g. to create boundary layers around the wing surface.
The CPACS tree module is an object hierarchy of the CPACS standard. Each node in the CPACS tree is mapped to a C++ object that contains all of its attributes and subnodes as child objects. The code for these classes is automatically generated from the CPACS XML schema (see Section 2.1).
The component module implements the modeling of the all aircraft components and the wing and fuselage structure, including spars, ribs, frames, beams and much more (see Section 4). The export and import module are the interface to other analysis tools. TiGL can export the aircraft geometries to CADbased as well as triangulated file formats. The former includes standard CAD exchanges formats such as IGES, STEP (ISO 10303) and OpenCASCADE’s internal format BREP. They are mainly used in combination with external mesh generation software. The latter includes STL (stereolithography), VTK polydata (to be used e.g. in ParaView [16]), and COLLADA (COLLAborative Design Activity) to support 3D rendering of the geometries.
Although TiGL is written in C++, it provides bindings to C, MATLAB, Python, and JAVA (see Section 2.2). In addition to the library, the software package comes with TiGL Viewer, a viewer for CPACS and other CAD files. It uses TiGL for modeling and provides a 3D OpenGL based view of the geometries. In addition to the pure visualization, TiGL Viewer includes a scripting console that can be used for small automation tasks e.g. to create a foursided view of the aircraft. A screenshot of TiGL Viewer is shown in Fig. 2(b).
2.1 Automatic Code Generation
For every relevant CPACS entity, there must be a corresponding representation in TiGL. This is achieved by automatic code generation from the CPACS schema which was recently introduced into TiGL. Compared the the former approach of manual implementation, automatic code generation has many benefits, e.g.

reduced development time,

changes to CPACS can be adapted much faster,

fewer errors, and

CPACS files can now be checked strictly to their standard definition.
This generator was mainly developed by RISC Software GmbH and can be publicly accessed on Github [17]. CPACSGen is a command line tool, which uses the CPACS schema file as its input and produces a C++ class for each of the CPACS nodes. There are several ways to influence the code generation process. For example, there are many node definitions in CPACS that are not used by TiGL. Therefore, the generator allows the definition of a prune list input file that lists CPACS nodes, which are completely discarded – including their subtrees. This is an effective mechanism to drastically reduce the amount of created code. Manual modifications to the autogenerated code can be realized by inheriting from the automatically generated classes, as the autogenerated code should not be modified by hand. Although, CPACSGen was designed primarily for TiGL, it can be used for other XML schema as well with only small adaptations.
2.2 Software Bindings
Even though TiGL is written in C++, it is mainly used by our users from the Python programming language. In addition, TiGL also comes with bindings for C, MATLAB and Java. Based on the public C interface of TiGL, the bindings are automatically generated by a small selfdeveloped tool included in TiGL. The tool parses the C API and creates the bindings code for each of the programming languages. Sometimes, a C function signature can be ambiguous. For example a pointer to an integer int* could be either an integer return value or an input integer array. To overcome the ambiguity, annotations inside a function’s docstring allow to define the semantics of each function argument. For each supported programming language, a code generator finally produces the bindings code. Right now, we are using the following technologies to enable the bindings:

Python: Dynamic function calls via Python’s ctypes.

MATLAB: One compiled MATLABmex file combined with a *.m file per function.

JAVA: Dynamic DLL loading with the JNA library [18].
In addition to the relatively simplistic language bindings via the public C API, we started to bind the entire internal C++ interface to Python. This makes it possible to use TiGL and pythonOCC [19] – the Python bindings to OpenCASCADE – in an interoperable fashion. This way, geometric objects can be passed from TiGL to OpenCASCADE and vice versa. Just like pythonOCC, these bindings are created with SWIG [20]. We experienced, that these new Python bindings encourage now also external developers with no C++ knowledge to contribute code to TiGL.
3 Geometry Module
3.1 Bspline modeling
TiGL uses the OpenCASCADE Technology CAD kernel [4] extensively for many tasks, e.g. to create solid objects, apply Boolean operations to them, and as a basis for the import and export modules. The geometric operations in OpenCASCADE however are not used in TiGL since several robustness issues were experienced in the past and the quality of the generated surfaces was not always satisfying. Therefore, most of the geometric modeling algorithms are implemented in the TiGL software itself. Just as OpenCASCADE, the geometric modeling is based on Bspline curves and surfaces. A Bspline curve is defined as
(1) 
where are the control points of the curve, is its knot vector, and are the Bspline basis function of degree . Bspline surfaces are defined as a tensor product of the Bspline basis functions, in particular
(2) 
All geometric shapes in TiGL, such as wings, fuselages, or engines have to be modeled as a combination of multiple Bspline surfaces. A bottomup approach, as proposed in [6], is used for the geometric modeling: CPACS defines parametric points which are then used to build up curves, such as airfoils or fuselage sections. These curves are then connected to create the final surfaces. Several surfaces are eventually formed to solids and enriched by metadata, which contain additional information such as face names. The single solid components are finally used to create the shape of the entire aircraft via Boolean operations, typically done in Constructive Solid Geometry. This approach is illustrated in Fig. 4.
The Bspline modeling algorithms used in TiGL are standard methods from textbooks [21, 22]. The most often used algorithm to create curves is Bspline interpolation, which creates as Bspline curve that passes through a set of points. Let be a set of points that should be interpolated at the curve parameters , then the interpolation conditions form the following linear system:
(3) 
This can be solved using standard linear solver methods, such as Gaussian elimination. When interpolating a closed set of points – i.e. where the first and last point is identical – with a periodic, continuous Bspline curve, this linear system can get singular for even polynomial degrees. To overcome this issue, the shifting method [23] is used. The interpolation of curves – often referred to as surface skinning [24, 25] – is similar to the curve interpolation. Surface skinning requires a set of compatible Bspline curves, where the curves differ only in their control points. The control points of the skinning surface are then computed by interpolating the curve’s control points as before in equation (3).
In addition to curve and surface interpolation, TiGL also uses Bspline approximation algorithms in a few cases. These algorithms perform a leastsquares fit of a Bspline to a set of points.
3.2 Curve Network Interpolation
At the heart of the geometric module is the curve network interpolation algorithm. It allows an accurate modeling of surfaces while keeping the number of input curves small. Compared to the simpler surface skinning method [24, 25], where a set of profile curves is interpolated by a surface, additional guide curves – sometimes also called rail curves – provide more control over how the surface interpolates the profiles. The algorithm is based on the Gordon surface method (see Section 3.2.1), which a almost never found in free or open source software. To our knowledge, only Ayam [26] and Sintef’s Go Tools [27] implement the method, but without addressing the curve network compatibility problem (see Section 3.2.3).
Consider a curve network with profile curves with and guide curves with . The curve network should be properly closed by surrounding profile and guide curves, i.e.
(4)  
(5) 
This basically means, that all profile curves must begin at the first and end at the last guide curve. And vice versa, all guide curves must begin at the first and end at the last profile curve. Such a curve network is depicted in Fig. 5. This curve network should now be interpolated by one single surface . If it is enforced, that the input curves are isoparametric curves of the resulting surface, the following conditions must hold:
(6)  
(7) 
Using these isoparametric conditions, it is now easy to see, that for any profile curve and guide curve , the compatibility condition of the curve network follows:
(8) 
i.e. all profile curves must intersect a guide curve at the same curve parameter, and all guides curves must intersect a profile curve at the same parameter.
3.2.1 Gordon Surfaces
William J. Gordon published a method [28] that is able to interpolate a curve network if it fulfills the curve compatibility condition (8): For any set of spline blending functions and satisfying the conditions
(9) 
the following blending surface interpolates the curve network and :
(10) 
Here is the intersection point of the ith profile curve with the jth guide curve , i.e.
(11) 
Equation (10) can now be rewritten as follows:
(12) 
Each of the three summands can be interpreted as an interpolation surface. The first is a surface that interpolates the profile curves , whereas the second term is an interpolation surface for the guide curves . The third term, often also called tensor product surface, interpolates the net of intersection points . Fig. 6 illustrates the surface construction principle for Gordon surfaces. It can be seen as a generalization of the Coonspatch method [29] to more than two profile and guide curves.
3.2.2 Gordon Surfaces with Bsplines
Since TiGL relies on the Bspline based OpenCASCADE CAD library, all curves of the curve network are Bsplines and the Gordon surface must also be a Bspline surface finally. Since the Gordon surface consists of two skinning surfaces and one tensor product surface, the surfaces and can be interpreted as the Bspline based skinning surfaces of the profile curves and guide curves. According to “the NURBS Book” [21, p. 485], the blending functions and can be interpreted as Bspline basis functions.
For the further derivation of the Bspline based Gordon surface method, it is required that all profile curves share

the same degree

and a common knot vector
in addition to the compatibility conditions of the curve network (8). The same should also apply to all guide curves. In practice, both can always be achieved by using degree elevation [30, 31] and knot insertion [32, 33] of the input curves.
In this case, all profile curves and all guide curves are of the form
(13) 
Here, are the control points of the kth profile curve and are the control points of the lth guide curve.
If the profile curves are skinned with a Bspline surface with knot vector and degree and the guide curves are skinned with a Bspline surface with knot vector and degree , Gordon’s equation (10) for Bsplines can be rewritten as follows:
(14) 
The three control nets , and must comply with the following interpolation conditions for all and :
(15)  
(16)  
(17) 
These ensure, that the first term interpolates the profile curves, the second term interpolates the guides curves, and the third term interpolates the curve network’s intersection points . The interpolation conditions are linear systems, which can be solved again using e.g. Gaussian elimination. It should be emphasized that the interpolation of the intersection points (17) must use the same interpolation parameters, degrees and knot vectors as the interpolation of the profile curves (15) and the guide curves (16).
The Bspline based Gordon surface (14) still is a superposition of the three interpolation surfaces. The three surfaces differ in their degree and knot vector. To be usable for TiGL in the end, the Gordon surface has to be converted back to a single Bspline surface. Fortunately, this is easy to achieve: first the degree of the surfaces is elevated to their maximum u and vdegree. Then, knots in u and vdirection have to be inserted, such that all surfaces share the same knot vector. After degree elevation and knot insertion, the three surfaces are compatible and thus have the same number of control points. The final Bspline based Gordon surface is created by adding the control points of the skinning surfaces and subtracting the control points of the tensor product surface.
3.2.3 Achieving compatibility of the curve network
Until know, it was assumed that the curves of the curve network are compatible, i.e. they meet the compatibility conditions (8). In practice, however, this is almost never the case, since the curves can be parametrized arbitrarily. To meet the compatibility conditions, the curve network has to be reparametrized first.
Without loss of generality, the following derivations will be performed on the profile curves. For the guide curves, the equations then follow analogously. Let the original profile curve intersect the original guide curve at parameter , i.e.
(18) 
It is known from the analyses before, that the profile curve has to intersect all guide curves at the parameters . Using a reparametrization function , the reparametrized profile curve can now be defined as
(19) 
The function must satisfy
(20) 
This type of Bspline reparametrization is described in [21, pp. 241] as “internal point mapping”. The choice of the reparametrization function is arbitrary but must fulfill in addition to (20) the following conditions:

It must be twice continuously differentiable since curvature continuous surfaces are required in the end.

The mapping function must be strictly increasing () such that each original parameter maps uniquely to one target parameter (monotone + bijective).
For the sake of simplicity, a Bspline interpolation based reparametrization of degree 3 was chosen, which is
(21) 
where the second part ensures the mapping (20). Here, are the control values of the interpolation Bspline of the curve . It should be noted, that if original parameters and target parameters deviate too much, the function can lose its bijectivity due to Bspline oscillations. For now, the bijectivity is checked by the TiGL software. If it fails, the code will create an error.
After the reparametrization function has been found, the composed curve has to be transformed to Bspline form. There are two ways to achieve this:

Exact reparametrization as described in [21, pp. 247]. Since it is exact, it does not introduce any error to the method. The big drawback of this method is the greatly increased degree of the profile / guide curve after reparametrization. Since the degrees of the original curve and the reparametrization function are multiplied for the resulting curve, an input curve with degree 4 and a reparametrization function of degree 3 results in a profile function of degree 12. As a consequence, also the degree of the final surface will be large.

Approximate reparametrization: The reparametrized function is approximated by sampling the curve and subsequently creating a new one from these sampled points. This way, the degree can be limited and the knot vector can be chosen more freely. The obvious drawback is the additional error introduced by the approximation.
For TiGL, the second method was chosen due to the following reasons: First, large degrees of the final surfaces should be avoided to keep the numerical complexity low. Second, the error of the approximation can be controlled and it can always be reduced by increasing the number of control points. Third, the free choice of the knot vector can be exploited such that e.g. the resulting profile curves all have the same knot vector. This helps to keep the number of knots and control points of the final surface low.
When using the approximation technique, it is essential that the reparametrized curve still exactly passes through its intersection points of the curve network, such that Gordon’s equation (10) is still valid. To achieve this, a hybrid approximation / interpolation technique of the sampled curve points is used: Let be sample parameters of the curve and let be the curve intersection parameters of the curve with the curve network. Then the control points of the approximation Bspline are computed by solving the following constrained linear least squares problem:
(22) 
Using the Lagrange multiplier method, this problem (22) can be transformed into the constrained normal equation:
(23) 
with
and 
As usual, represents the Lagrange multipliers of the constraint problem. The linear system (23) is finally solved using Gaussian elimination. If the original curve contains kinks, these kinks are reproduced in the reparametrized curve by inserting knots with a multiplicity of the curve’s degree into the knot vector prior to the approximation.
The approximation can be performed with an arbitrarily chosen number of sample points . To get a unique solution, must be larger than the number of control points of the reparametrized curve. The number of control points should be as small as possible to avoid unnecessary computational complexity but should be large enough to keep the approximation error small. In TiGL, we simply use roughly the same number of control points for the reparametrized curve as for the original curve. This way, it is possible to reproduce all features of the original curve. The knot vector is chosen to be uniform.
3.2.4 Algorithm
The whole algorithm combines the previously described steps. To achieve a low number of control points of the final surface, we use the same number of control points in all profile / guide curves in the reparametrization step. By using always the same number of control points, all profiles / guide curves will get the same uniform knot vector and hence also the skinning surface. If the knot vectors were different, all knot vectors would have to be merged first. This would result in a very large knot vector and therefore a large number of control points for the final surface. The pseudo code of our Bspline based Gordon method is depicted in Algorithm 1. Figure 7 shows six different example geometries that are created with this algorithm. The extreme helicopter case (see Fig. 6(e)) shows that the algorithm is also suitable for very large curve networks. The resulting surfaces are smooth – except for intentionally inserted kinks – and interpolate the curves as they should.
4 Aircraft Component Module
Many aircraft component geometries can be generated using a network of profile and guide curves. Section 4.1 will therefore describe how these curves can be defined according to the CPACS definition. Afterwards, details about the definition and modeling of wings, fuselages, control surfaces, structural elements as well as engine nacelles and pylons are presented.
4.1 Profile and Guide Curves
In this section, we are going to introduce the two basic building blocks for modeling wings and fuselages: profile and guide curves. Both of these entities are defined with respect to some local coordinate system as it is common to the CPACS description. For the wing profiles, TiGL implements a definition based on local points as well as a parametric description (CST). The guide curves are defined by a set of points in a local coordinate system.
4.1.1 Profiles from Point Lists
This is the most commonly used approach to creating wing and fuselage profiles with TiGL. Given a set of threedimensional points in a local coordinate system of a section, a Bspline curve is interpolated. In a second step the curve is transformed to a global coordinate system to bring it to the position of the section and scale it accordingly.
A typical airfoil can be seen in Fig. 8. It is created by a list of points which are ordered in a mathematically positive sense. The list starts and ends at the trailing edge of the airfoil.
4.1.2 Profiles from Parametrized Curves (CST)
An alternative to the creation of wing profiles via points is the analytic description of the airfoils by the Class Shape Transformation method (CST) [34]. Both the upper and the lower half of the profile is defined by a twodimensional curve, which reads
The exponents and of the Class function determine the slope at the leading and trailing edge, respectively. The Shape function
is a linear combination of Bernstein basis functions of degree and controls the shape of the airfoil. The size of the trailing edge is given by . With this, the CST curve is completely characterized by the exponents , , the Bernstein coefficients and .
Figure 9 shows a simple example of a CST curve for an upper wing profile.
4.1.3 Guide Curves from Point Lists
Guide curves connect the profiles in order to create a curve network (cf. Fig. 5 and Section 3.2). Each guide curve is created by Bspline interpolation of a set of guide curve points. Since a guide curve always starts and ends at a profile, the first and the last guide curve points are attached to these profiles. The position of the start points can be given either by a relative circumference of the profile or by pointing to the end point of a previous guide curve. In the latter case, the continuity across the profile can be set. This is described in Section 4.2.2. The position of the end point is always set by a relative circumference of the profile. The intermediate guide curve points are described by three local coordinates .
In the following, we will describe how to construct a guide curve point in real space from the local coordinates (see Fig. 10). As a first step, we draw a straight line from the start to the end point. This line defines the first axis of the coordinate system. We move along this line from the start point () towards the end point (). Hereby, is the normalized distance between start and end point. From there, we move towards a predefined direction. Here is the linear interpolation between the typical length of the start profile and the end profile . In the case of wing profiles, and are the cord lengths of the start and end profiles, respectively. The predefined direction is usually the global axis for wing guide curves and the global axis for fuselage guide curves. As a last step we move in the direction perpendicular to both previous directions.
4.2 Wing
4.2.1 CPACS Parametrization of the Wing
According to the CPACS definition, a wing is modeled from its (cross)sections. For a wing, at least two sections must be present, one for the root of the wing and one for the tip.
A section is a coordinate system that is used to position airfoil curves in threedimensional space, see Fig. 11. This coordinate system is defined using a transformation consisting of scaling in three dimensions, rotation around the ,  and axis, as well as a threedimensional translation. In addition to the transformations, sections can be translated relative to each other using a positioning vector. It consists of a sweep and dihedral angle, as well as a length for the offset between two sections. The positioning vector of a section does not influence its rotation or scale. The total translation of the section is the sum of the positioning vector in Cartesian coordinates and the translation prescribed in the section’s transformation.
Within a section, several elements can be placed, where each element references one airfoil curve. An element is again a coordinate system that is used to transform an airfoil within a section. By placing two elements in one section, it is possible to define wings, whose cross section has a discontinuous jump in spanwise direction, see Fig. 11.
A wing segment is the volumetric part of the wing that connects two elements from adjacent sections. It is possible to use guide curves within each segment to influence the segment shape. All segments must have the same number of guide curves and the guide curves of two adjacent segments must be connected. Otherwise, the guide and profile curves would not constitute a valid curve network and the Gordon surface algorithm would fail.
Finally, a component segment is a part of the wing that consists of several adjacent segments. Component segments are used to define the relative position of the internal wing structural elements and fuel tanks, control devices, and the wing fuselage attachment.
4.2.2 Geometric Modeling of the Wing
The wing profile curves described in section 4.1.1 are elements of wing sections. They are transformed through the section’s transformation and positioning vector, as well as the element’s transformation itself.
Guide curves can be defined for the segments through guide curve points (cf. section 4.1.3). They are constructed as curves spanning the wing from its root to the tip. Together with the wing profiles, they serve as input for the Gordon algorithm described in section 3.2.1. The connected guide curves are interpolated piecewisely, depending on the prescribed continuity condition of the guide curve. Continuity conditions are optional, and they can include “C0”, “C1 from previous”, “C1 to previous”, “C2 from previous” and “C2 to previous” according to the CPACS schema.
A connected guide curve is broken into parts at the prescribed continuity conditions, see Fig. 12. As a default, each part is interpolated smoothly, meaning a continuity is prescribed. The parts depend on each other according to the “from previous” or “to previous” continuity conditions. A “from previous” conditions means, that the tangent at the beginning of the guide curve must be the same as the end tangent of the inner neighboring guide curve. A “to previous” condition implies, that the tangent at the beginning of the guide curve is prescribed onto the end of the inner neighboring guide curve. This implies an order in which guide curve parts must be interpolated, so that the prescribed tangents are available. TiGL uses a topological sorting algorithm based on Kahn’s method [35] to achieve this. Note that TiGL only prescribes tangents at the break points and not the curvature. Therefore, only continuity is guaranteed.
If there are no guide curves, the profile curves are skinned linearly, or optionally using a Bspline of degree up to three. The resulting surface must be closed by side caps at the root and tip to make a solid, otherwise the wing geometry cannot be used in Boolean operations. The modeling of the wing tip geometry is planned for the future. Fig. 12(a) shows a wing created from a CPACS file with TiGL.
4.3 Flaps
Flight control surfaces such as ailerons, flaps, slats, spoilers and rudders can be modeled with CPACS and TiGL. There are three categories: leading edge devices, trailing edge devices and spoilers. Fig. 12(b) shows extended trailing edge devices that were modeled using TiGL. The devices can have an internal structure, that is similar to the definition of the wing structure, see Section 4.5.
The outer shape of a control surface is defined by defining four points in the local coordinates of the component segment. These points roughly describe the position and shape of the control device as well as the wing cutouts. Alternatively, the exact shape of the flap can be described using profile curves. In addition to the exact control surface shape, the shape of the wing cutout can be described more precisely by defining the cutout limits independently of the flap shape and separately for the upper and lower skin of the wing. In this case, the upper and lower cutout must be closed with a profile curve on the inner and outer side of the flap.
Alongside the description of the actuators of the control surfaces, the path along which a control surface moves when it is extended can be given. For this, an inner hinge point and an outer hinge point must be provided in order to define the connection of the flap to the actuators. All possible positions of the flap are described by giving steps along a path from a minimum deflection to a maximum deflection value. A step along this path includes a translation of the control device together with a rotation around the axis defined by the two hinge points.
Using TiGL’s API, the flaps can be deflected and the resulting geometry can be exported for further processing. A console in TiGL Viewer allows the interactive deflection of the control devices for more control.
4.4 Fuselage
Fuselages are created in TiGL similarly to wings: A fuselage is comprised of segments, which contain sections. Each section can contain one or more elements of fuselage profiles. The sections can be connected via guide curves. In order to create a solid fuselage, the profile curves and the connected guide curves with prescribed continuity conditions are transformed to global coordinates in TiGL. Together, they form the curve network that is used as an input for the Gordon Surface algorithm. Currently, the front and back of the fuselage are closed by side caps to create solids. The modeling of fuselage noses and rears are planned for the near future. Fig. 14 shows a fuselage that was created with TiGL.
4.5 Wing and Fuselage Structure
4.5.1 Wing structure geometry
The structural definition of the wing is being developed by Airbus Defence and Space since [36] and was cantributed back to the TiGL source code in . The foundation is the wing component segment, consisting mainly of the upper and lower wing shell, wing stringers, spars and ribs. Currently only the geometry generation of the ribs and spars is supported by TiGL.
The spar definition, shown in Fig. 14(a), is realized with spar positions and segments. A positioning can be defined by (, ) coordinates in the relative space of the component segment or with an unique identifier (UID) referring to a sectionelement and a value. A spar segment has to consist of two or more spar positions.
The rib geometries are constructed as a second step, because their definition can be spar dependent. There are two different rib positioning schemes, the common and the explicit one. The common rib positioning is defined by two values, one for the first and one for the last rib. As for the spar positions, these values can also be replaced by sectionelement UIDs, to place ribs directly at a section border. Additionally, the number of ribs is defined in the CPACS schema, and so the remaining ribs are placed equally distributed between the start and end rib. The chordwise borders of the ribs can be the leading or the trailing edge of the wing or any spar that intersects the rib plane.
The main issue with this CPACS definition is, that it is not possible to define three or more ribs with a dedicated chordwise connection. This is due to the common rib definition, which uses one spanwise position in combination with an angle. This allows to generate either an exact starting point or an exact ending point. To encounter this, the explicit rib definition with an exact chordwise start and end position, was introduced. A major drawback of this method is, that every single rib face has to be defined and no distribution can be given. The described difference is visualized in Fig. 15(a) and Fig. 15(b).
4.5.2 Fuselage structure geometry
The structural definition of the fuselage is also developed by Airbus Defence and Space and was contributed to TiGL in . The CPACS definition of the fuselage structure differs completely from the one of the wing. Unfortunately, it is based on absolute coordinates, which leads to problems with the paradigm of parametric modeling. This was solved with an internal normalization of the absolute coordinate values in TiGL. Global values are normalized with the overall length of the fuselage. The and values are normalized with a bounding box, containing a curve of the fuselage loft at a global position. This solution enables the automatic adaption of the fuselage structure, if the fuselage loft is changed. When a CPACS export is requested, the absolute values are calculated in the reverse way and exported in absolute numbers.
The structural entities of the fuselage currently supported by TiGL, are: skin cells, fuselage frames, fuselage stringer, pressure bulkheads, fuselage doors, cross beams, cross beam struts, and long floor beams. Some of these entities are shown in Fig. 17.
4.6 Engine Nacelles and Pylons
Engines are connected to the wing by pylons (see Figure 18). Engine nacelles and pylons are not yet implemented in TiGL, but will be in the near future. The definition of the pylon and engine geometry is currently undergoing changes in CPACS as well. The definition for the pylon geometry as described here is already included in the latest CPACS release, while the engine nacelle definition will be updated soon. The CPACS definition of pylons resembles that of a wing. Profile curves define the spanwise crosssection of a pylon and the curves are skinned in chordwise direction (see Fig. 17(b)). In accordance with the CPACS definition, the outer geometry of the engine nacelles will be modeled from profile and guide curves (see Fig. 5). Twodimensional profile curves define the radial sections of the engine nacelle in flow direction. The profile curves are placed around the engine’s symmetry axis using cylindrical coordinates, i.e. by prescribing an angle and a radius. If only one profile is given, the resulting engine nacelle will be rotationally symmetric. Otherwise, the profiles will be connected using closed guide curves.
To guarantee that the inner geometry of the engine nacelle is perfectly rotationally symmetric, a curve for the inner shape can be defined with an offset from the engines symmetry axis. This curve is used to generate a rotation surface which is then blended with the – not necessarily rotationally symmetric – outer nacelle surface in a transition zone.
5 Summary and Outlook
This paper presented the software TiGL, which is a parametric geometry generator for aircraftlike configurations. It can be used in the aircraft design optimization process, by changing the CPACS design variables of the aircraft and regenerating the geometry using TiGL. TiGL models the major parts of an aircraft, including wings, fuselages, control surface devices, the inner aircraft structure, nacelles and pylons. It is primarily focused on parametric aircraft configurations in the CPACS format, which is getting more and more traction in the aircraft design community. Using TiGL and CPACS, it is possible to model a broad range of different configurations. Figure 19 illustrates five different example configurations, all defined in the CPACS format and modeled with TiGL.
Moreover, since TiGL is modular, its core modules can also be used completely disconnected from CPACS. For example it is possible to use only TiGL’s geometry module for general modeling. One of the most important features of the geometry module is the implementation of the Bspline based Gordon surface algorithm. To the authors knowledge, this algorithm almost never occurs in freely available software. Since this algorithm allows for high precision surface modeling, TiGL is also suitable for high fidelity analysis.
TiGL is already used by the aircraft community outside the German Aerospace Center (DLR). For example Airbus Defence and Space developed the DESCARTES analysis software [37] based on TiGL and improved TiGL during their development. A graphical CPACS editor [38] is currently being developed by CFS Engineering and is based on the TiGL Viewer. The aircraft tool suite JPAD [10] is using TiGL to integrate CPACS support into their software.
The development of TiGL will continue. In the near future, we will finish our implementation on nacelles and pylons. Afterwards, belly fairings, an improved modeling of the wing tips and winglets will follow. We are currently working on the automatic mesh generation for low and midfidelity CFD. Therefore, it is planned to integrate the Salome Mesh module [39], which is based on Netgen [40], such that surface and volumetric meshes can be generated via a call to TiGL’s API. To improve the support of gradient based MDO, it will be investigated whether an adjoint code or automatic differentiation of the geometry kernel is possible.
Acknowledgement
TiGL has been developed for several years now. During this time TiGL has been developed and improved by many of our colleagues. In particular we would like to thank Markus Litz, who laid the foundation for TiGL. Special thanks go to Bernhard Gruber and Roland Landertshammer from RISC Software for their work on the software development and Merlin Pelz from DLR for the Gordon surface implementation. Finally, many thanks to our colleagues Jonas Jepsen, Philipp Kunze, Sebastian Deinert, Mark Geiger, Volker Poddey, Konstantin Rusch, and Paul Putin for their contributions to TiGL.
References
 [1] DLRSC, “The TiGL geometry library to process aircraft geometries in predesign.” https://github.com/DLRSC/tigl, 2018. Accessed: 20180927.
 [2] B. Nagel, D. Böhnke, V. Gollnick, P. Schmollgruber, A. Rizzi, G. La Rocca, and J. J. Alonso, “Communication in aircraft design: Can we establish a common language,” in 28th International Congress Of The Aeronautical Sciences, Brisbane, 2012.
 [3] DLRSL, “CPACS  common parametric aircraft configuration schema.” https://github.com/DLRLY/CPACS, 2018. Accessed: 20180922.
 [4] OPENCASCADE, “Open CASCADE Technology, 3d modeling and numerical simulation.” https://www.opencascade.com. Accessed: 20180925.
 [5] A. Hahn, “Vehicle sketch pad: a parametric geometry modeler for conceptual aircraft design,” in 48th AIAA Aerospace Sciences Meeting Including the New Horizons Forum and Aerospace Exposition, p. 657, 2010.
 [6] R. Haimes and M. Drela, “On the construction of aircraft conceptual geometry for highfidelity analysis and design,” in 50th AIAA Aerospace sciences meeting including the new horizons forum and aerospace exposition, p. 683, 2012.
 [7] J. Hwang and J. Martins, “GeoMACH: geometrycentric mdao of aircraft configurations with high fidelity,” in 12th AIAA Aviation Technology, Integration, and Operations (ATIO) Conference and 14th AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference, p. 5605, 2012.
 [8] M. R. Afsar, M. A. H. Banna, M. J. Uddin, and M. A. Salam, “Ceasiom: An open source multi module conceptual aircraft design tool,” International Journal of Engineering, vol. 2, no. 7, 2013.
 [9] larosterna, “Sumo  modeling and mesh generation.” https://www.larosterna.com/products/opensource, 2018. Accessed: 20180929.
 [10] DAF Research Group at University Naples Federico II, “JPAD: java program toolchain for aircraft design.” https://github.com/AircraftDesignUniNa/jpad, 2018. Accessed: 20180928.
 [11] DLRSC, “cpacs2to3: A tool to convert cpacs files to version 3.” https://github.com/DLRSC/cpacs2to3, 2018. Accessed: 20180922.
 [12] N. Kroll, M. AbuZurayk, D. Dimitrov, T. Franz, T. Führer, T. Gerhold, S. Görtz, R. Heinrich, C. Ilic, J. Jepsen, et al., “Dlr project digitalx: towards virtual aircraft design and flight testing based on highfidelity methods,” CEAS Aeronautical Journal, vol. 7, no. 1, pp. 3–27, 2016.
 [13] C. Liersch, K. Huber, A. Schütte, D. Zimper, and M. Siggel, “Multidisciplinary design and aerodynamic assessment of an agile and highly swept aircraft configuration,” CEAS Aeronautical Journal, vol. 7, no. 4, pp. 677–694, 2016.
 [14] S. Goertz, C. Ilic, J. Jepsen, M. Leitner, M. Schulze, A. Schuster, J. Scherer, R. Becker, S. Zur, and M. Petsch, “Multilevel MDO of a longrange transport aircraft using a distributed analysis framework,” in 18th AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference, p. 4326, 2017.
 [15] DLRSC, “TiXI: Fast and simple xml interface library.” https://github.com/DLRSC/tixi, 2018. Accessed: 20180922.
 [16] J. Ahrens, B. Geveci, and C. Law, “Paraview: An enduser tool for large data visualization,” The visualization handbook, vol. 717, 2005.
 [17] RISC Software GmbH, “CPACSGen: Generates CPACS schema based classes for tigl.” https://github.com/RISCSoftware/cpacs_tigl_gen, 2017. Accessed: 20180924.
 [18] “JNA: Java native access.” https://github.com/javanativeaccess/jna. Accessed: 20180924.
 [19] T. Paviot and J. Feringa, “pythonOCC–3D CAD for python.” http://www.pythonocc.org, 2016. Accessed: 20180928.
 [20] D. M. Beazley et al., “Swig: An easy to use tool for integrating scripting languages with c and c++.,” in Tcl/Tk Workshop, 1996.
 [21] L. Piegl and W. Tiller, The NURBS book. Springer Science & Business Media, 2012.
 [22] G. Farin, Curves and Surfaces for CAGD: A Practical Guide. Morgan Kaufmann, 2014.
 [23] H. Park, “Choosing nodes and knots in closed bspline curve interpolation to point data,” ComputerAided Design, vol. 33, no. 13, pp. 967 – 974, 2001. DOI 10.1016/S00104485(00)001330.
 [24] A. A. Ball, “CONSURF. part one: introduction of the conic lofting tile,” ComputerAided Design, vol. 6, no. 4, pp. 243–249, 1974.
 [25] A. A. Ball, “CONSURF. part two: description of the algorithms,” ComputerAided Design, vol. 7, no. 4, pp. 237–242, 1975.
 [26] R. Schultz, “Ayam: A free 3d modelling environment for the renderman interface..” http://ayam.sourceforge.net/ayam.html, 2018. Accessed: 20180928.
 [27] SINTEF, “GoTools.” https://www.sintef.no/projectweb/geometrytoolkits/gotools/. Accessed: 20180928.
 [28] W. J. Gordon, “Splineblended surface interpolation through curve networks,” Journal of Mathematics and Mechanics, pp. 931–952, 1969.
 [29] S. COONS, “Surface for computer aided design of space forms,” MIT Project MAC, TR41, 1967.
 [30] H. Prautzsch, “Degree elevation of bspline curves,” Computer Aided Geometric Design, vol. 1, no. 2, pp. 193–198, 1984. DOI 10.1016/01678396(84)900311.
 [31] L. Piegl and W. Tiller, “Softwareengineering approach to degree elevation of bspline curves,” ComputerAided Design, vol. 26, no. 1, pp. 17–28, 1994. DOI 10.1016/00104485(94)900043.
 [32] W. Boehm, “Inserting new knots into bspline curves,” ComputerAided Design, vol. 12, no. 4, pp. 199–201, 1980. DOI 10.1016/00104485(80)901542.
 [33] E. Cohen, T. Lyche, and R. Riesenfeld, “Discrete bsplines and subdivision techniques in computeraided geometric design and computer graphics,” Computer graphics and image processing, vol. 14, no. 2, pp. 87–111, 1980. DOI 10.1016/0146664X(80)900404.
 [34] B. M. Kulfan, “A universal parametric geometry representation method  ”CST”, jan. 2007,” in 45th AIAA Aerospace Sciences Meeting and Exhibit, p. 0062, 2007.
 [35] A. B. Kahn, “Topological sorting of large networks,” Commun. ACM, vol. 5, pp. 558–562, Nov. 1962.
 [36] R. Maierl, Ö. Petersson, and F. Daoud, “Automated creation of aeroelastic optimization models from a parameterized geometry,” in 15th International Forum on Aeroelasticity and Structural Dynamics, 2013.
 [37] F. Daoud, S. Deinert, R. Maierl, and Ö. Petersson, “Integrated multidisciplinary aircraft design process supported by a decentral mdo framework,” in 16th AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference, p. 3090, 2015.
 [38] CFS Engineering, “CPACSCreator.” https://github.com/cfsengineering/CPACSCreator, 2018. Accessed: 20180928.
 [39] V. Bergeaud and V. Lefebvre, “SALOME. a software integration platform for multiphysics, preprocessing and visualisation,” in SNA+MC 2010 Conference, p. 21â29, 2010.
 [40] J. Schöberl, “NETGEN an advancing front 2d/3dmesh generator based on abstract rules,” Computing and visualization in science, vol. 1, no. 1, pp. 41–52, 1997.