OpenVSP: parametric aircraft geometry you can hand to an analysis tool

Parameters in, geometry out

OpenVSP is a parametric aircraft geometry tool. It lets the user create a three-dimensional model of an aircraft defined by common engineering parameters, and that model can be processed into formats suitable for engineering analysis. The word that does the work is parametric. In a conventional CAD workflow you build a shape by manipulating a mesh, and every variant of that shape is another mesh to maintain. Here the shape is a function of inputs, so a sweep of wing span or a change of fuselage length is an edit to a number. The topics the repository carries line up with what the exports are for: aerodynamics, CFD, finite element methods, aerospace engineering and 3D modelling. The tool is the front half of a workflow, and its output is meant to be fed into a solver rather than looked at.

Two ways in: the GUI and the API

Most users are familiar with the OpenVSP GUI, but OpenVSP can also be accessed by other programs through an API, or in a batch mode with no user interaction. Those headless targets may be compiled without any of the graphics libraries installed. The dependency list marks the libraries that only the GUI program and the graphics-enabled API need with the flag GRAPHICS_ONLY, which is a useful piece of engineering: it means an organisation that only wants to generate geometry from a script does not have to install OpenGL, FLTK, GLEW, GLM, the cartesian plotting library or the bundled glFont2 font tool. That separation is what makes the tool usable on a build server, and it is the reason to read the dependency section carefully rather than installing everything.

Four categories of dependency

The README splits the dependencies into four groups, and the grouping is the most useful thing in the document. The first are those assumed to be provided by the operating system, where the example is OpenGL, the three-dimensional graphics library, which should be available on any platform capable of displaying three-dimensional graphics, and which is marked GRAPHICS_ONLY. The second are those that must be downloaded and installed by the developer, among them the C++ compiler, CMake 3.24, SWIG, Python and Doxygen. The third are bundled with OpenVSP but where the developer may prefer a different version installed on the system. The fourth are bundled outright. The README is explicit that the section is informational for users and about giving credit where due, and that you need to know more only if you intend to compile VSP or use the VSP API.

What the developer has to install

The developer-installed group is the short list you actually need for a build. A modern C++ compiler supporting some C++11 features is required, with Visual Studio 2010 Express or newer required on Windows and LLVM and GCC supported on macOS and Linux and BSD. CMake 3.24 is the cross-platform build system, generating platform-native build files that control the compilation. SWIG is optional and is used to build the API interface for Python and other scripting languages, and Python is an optional dependency required if you are building the Python API module. Doxygen is optional and generates documentation from the source, and it can also use graphviz dot to generate improved figures in the documentation. So the minimum build is compiler plus CMake, and everything else is conditional on what you intend to do with it.

The bundled libraries and what they are for

The bundled-with-substitution list is where the engineering shows. AngelScript is an embedded scripting language for C++, used for user-defined components, so the user can extend the model without writing C++. Code-Eli is a header-only curve and surface library developed by David Marshall specifically to meet OpenVSP's needs, and the README notes it is unlikely to be packaged on any system. Eigen3 is a template library for linear algebra, header-only, required by Code-Eli, and likely available as a standard package on Linux. Clipper2 handles clipping and offsetting of two-dimensional lines and polygons. CMinpack is a C and C++ port of the standard Fortran Levenberg-Marquardt implementation, which is how the tool does optimisation. delabella is a C++ Delaunay triangulation library, and Triangle by Jonathan Shewchuk is a two-dimensional Delaunay triangulator, with OpenVSP using a CMake library version of it. Pinocchio is the auto-rigging and weighting tool, OpenABF is an angle-based flattening mesh parameterisation library, and STEPcode handles STEP standard files.

The bundled-only dependencies

Four items are bundled outright and cannot be substituted. The cartesian library is a simple two-dimensional plotting library for FLTK, marked GRAPHICS_ONLY. glFont2 by Brad Fish is a two-dimensional OpenGL font tool, included in the source distribution and also marked GRAPHICS_ONLY. nanoflann is a fast nearest neighbours library. pcg-cpp is a random number generator. The last is the most interesting: sixseries is NASA 6-Series airfoil generation Fortran code released to the public domain by NASA from Technical Memorandum X 3069 in September 1974, converted to C. So the tool carries a piece of its own heritage in the source tree, an airfoil generator that predates the licence by several decades and is public domain for that reason.

Licence and lineage

OpenVSP is available under the terms of the NASA Open Source Agreement version 1.3, with the complete terms in the LICENSE file, and the repository's licence field carries a custom classification GitHub cannot label. The history is stated in the introduction. The predecessors to OpenVSP were developed by JR Gloudemans and others for NASA since the early 1990s, and in January 2012 OpenVSP was released as an open source project under the NOSA 1.3 licence, with the first open source version being 2.0.0. The NOSA is a NASA-specific category rather than a standard permissive licence, so for a commercial user the terms are worth reading rather than assuming they resemble MIT. The project site is openvsp.org, and the repository has no GitHub releases, with the changelog kept in a CHANGELOG.md file and a changelog.sh script at the root.

Where OpenVSP is the wrong choice

Four limits apply. It produces geometry and not analysis, so a team that needs aerodynamic results still has to run a solver and handle the export formats and their units, and the topics list makes clear the analysis tools are separate projects. It is a desktop-oriented tool with a heavy native dependency tree, and the bundled libraries that are unlikely to be packaged anywhere mean a build environment has to be assembled rather than installed. The scripting layer is AngelScript rather than a mainstream language, which lowers the barrier for an aerodynamicist and raises it for a web developer, though the SWIG and Python bindings are there for the latter. And the parametric model assumes a conventional aeroplane topology, so anything that is not a fuselage, wing and tail arrangement is going to need the API rather than the GUI.

Editorial conclusion

Use OpenVSP when you need a lofted, parametric aircraft shape that an analysis tool can consume, because the whole point is the parameters flowing into the geometry rather than a mesh you edited by hand. Do not expect it to perform the analysis, since it produces the model and the exports rather than the results. Verify first which dependency group you actually need, since the GUI-only libraries are marked GRAPHICS_ONLY and the headless and API targets compile without any of them, that your compiler meets the C++11 requirement and that CMake 3.24 is available, and that the NOSA 1.3 terms suit your use, since that is a licence category with its own obligations rather than a permissive one.

Frequently asked questions

Official sources

1. Issues
2. OpenVSP/OpenVSP on GitHub
3. Project website
4. README