Overview

After Project Caladrius, wherein a colleague and I developed time-based models to simulate a conventional, jet-powered aircraft in takeoff, climb, and cruise, I decided to expand the code and package it along with the scripts I had written for my 2023 and 2024 entries into the AIAA Design Competitions. The result was DSAeroTools.

DSAeroTools is, simply put, a well-structured compilation of every piece of code I have written thus far in my college career - aero related, of course. It is mostly geared towards the challenge of designing an aircraft from scratch, but can also serve as a general analysis tool for miscellaneous tasks.

It is split into two categories: DSAeroToolsSim and Tools.

DSAeroToolsSim

Overview

DSAeroToolsSim is a time-based mission analysis tool. Its basic functionality hinges on the parametrization of a Vehicle through the modelling of different disciplines of the Vehicle. A Vehicle consists of the following disciplines:

• Geometry Model
• Weight Model
• Lift Model
• Parasite Drag Model
• Propulsion Model
• Drag Model

Each handling the unique physics of their respective disciplines.

Fidelity and Flexibility

Several different levels of fidelity are available for each model. The geometry, for instance, can be parametrized using a simple conventional geometry model (wing, horizontal, vertical) or it can be parametrized using a more nuanced "general geometry" model, which allows the user to define any arbitrary number of surfaces. If using in conjunction with the component-by-component parasitic drag buildup model, the user can specify specific boundary layer formulations to be used with each surface, and the drag of each will be computed at every time-step of the flight. This exemplifies the different degrees of fidelity possible with the sim.

Another good example of the flexibility of the sim is the propulsion model. The integrator keeps track of not only the weight and energy contents of the fuel (or battery, or fuel cell...) but also their time derivatives, allowing for the modelling of not only fuel-burning systems but also electric, hybrid, and more.

Mission Analysis

A mission is composed of segments. The segments are solely responsible for the physics of the problem. They are written so that they work with any of the models for the disciplines that comprise a Vehicle.

Cruise segments have different termination settings. A cruise segment can be terminated by running out of:

• Range
• Time
• Energy

However, DSAeroToolsSim also allows for convergence of missions where the starting weight in certain segments might not be known. This is the case, for instance, of a mission where after ascent, cruise, and descent, the vehicle must be able to ascend to a loitering altitude, loiter for 30 minutes, and descend back to ground level. In this case, we must iteratively guess the cruise range such that after simulating the rest of the mission the final energy is driven to zero.

The user can indicate whether the cruise segment must be converged with the "converge":True entry into the mission dictionary. More than one cruise segments can be driven by the solver, allowing a lot of flexibility for mission convergence where alternate/reserve mission must be flown in sequence with the design mission.

Additionally, the user can choose to converge a given mission in a two different ways: mission fixed or energy fixed.

In mission fixed simulations, the mission is entirely defined - i.e., every segment has a defined termination condition, be it cruise or time. In this case, the energy onboard is iteratively guessed until the final energy is zero (the Vehicle has just enough energy to fly the design mission)

In the energy fixed simulations, the energy onboard is defined (input) and the mission must be allowed to vary in some way. The most common example is a ferry mission: the energy content is fixed (as much fuel as the plane can carry) but some aspect of the mission is iteratively varied (in the case of a ferry mission, the range) until the final energy is zero.

Most design cases will use a mission fixed simulation - the RFP specifies a design mission, or a series of design missions. However, it is often the case that the ferry range is a performance parameter of the aircraft. Thus, DSAeroToolsSim also allows for the simulation of a ferry mission following a design mission, and the ferry range is added as a performance metric to the output of the Vehicle’s JSON.

Trade Studies

DSAeroToolsSim features an abstract trade study class, which can handle trade studies of several variables. This is done by deep-copying a baseline vehicle (which contains attributes shared by all vehicles) N-times into an array, then looping through the array and assigning the traded attributes appropriately. Each vehicle is then initialized and simulated.

Data is parsed into JSONs. Each vehicle receives a unique ID, which also determines the directory in which that vehicle's converged mission's JSON is stored. For instance, a trade of 10 vehicles will create directories JSONDumpDir/0/Vehicle.json, JSONDumpDir/1/Vehicle.json, JSONDumpDir/2/Vehicle.json, etc.

DSAeroToolsSim also contains a PostProcessing class to handle any visualization and analysis of the resulting data. Included in PostProcessing is:

• Methods to read the Trade Study results (parse the JSON files)
• Contour plotting
• Data retrieval

And more custom methods can be easily written by the user.

Tools

Overview

The Tools directory contains miscellaneous parametric tools that are useful in the early stages of conceptual design. They differ from the time-based sim in that they do not integrate states, but rather use analytical methods and expressions from literature for a first-stab at the design space. This is not to say that these tools are completely separate from DSAeroToolsSim - some tools, for example, might use the same geometry parametrization models from DSAeroToolsSim. There is a good reason for this: they were developed in tandem!

Breguet-Based Mission Analysis

Tools contains functions for iterative sizing of vehicles using breguet-based formulations for mission analysis. These methods are widely explored in literature and great explanations can be found in books like Raymer's Aircraft Design: A Conceptual Approach or Gudmundsson's General Aviation Aircraft Design. They are useful for a first estimation of design takeoff gross weight for a given mission profile.

These methods tend to rely on statistical weight equations, found in the same references listed above. This can be unreliable for unconventional configurations and edge-of-the-envelope missions.

Constraint Analysis

Perhaps the most useful formulations in Tools are the methods for creation of constraint diagrams. This is an exceptionally useful investigation of the design space, conducted quite early in the design process. These functions generate T/W versus W/S diagrams with performance-based constraints - or isolines - plotted in the diagram, representing combinations of T/W and W/S that satisfy some performance constraint.

Tools also includes methods for parametric-baseline type trades. The performance formulations were solved for the performance parameters such that the T/W and W/S can be parametrically varied and the change in the performance parameter obtained. This variation from the baseline (a parametric variation, if you will) is useful to conduct sensitivity studies early in the design process, and consider alternative sizing approaches depending on the sensitivities.

AVL, QPROP, and XFOIL

Finally, Tools also allows the user to run AVL, QPROP, and XFOIL through Python scripts. It is well integrated with the same geometry parametrizations that are used for DSAeroToolsSim, making the codebase flexible.

In the future, this author plans on implementing surrogate aero and propulsion models in DSAeroToolsSim with these codes. The fact that they share the geometry parametrization will probably help to that end.

Documentation

This project was this author’s first time documenting code in a distributable fashion. Sphinx was used to build the docstrings into an HTML, and a nice theme from ReadTheDocs was used. For deployment, a Github Action was written to build the docs and deploy them in an auxiliary branch every time a push or commit is made to the main branch, or a pull request is merged into main. The docs are hosted in a public Github Page.