Article Title
+Intro text.
+ +Subsection Header
+ +Subsection text.
+ + Code Sample + +
+ +
Intro text.
+ +Subsection text.
+ + Code Sample + Intro Text. +
+ ++ Subsection Text. +
++ Attributes are how SUAVE provides data and information outside of + vehicle and mission parameters, but still necessary or useful for + mission simulation. Not typically modified by the end user, + attributes provide information on material properties, atmospheric + and weather conditions, and basic physical constants +
+ ++ SUAVE's material property library includes solids like aluminum and + carbon fiber composites which are given strength, density, and other + pertinent attributes. It also has data on gases and liquids such as + water and steam, CO2, and air including thermochemical constants and + composition proportions for mixtures like air. For propellants and + fuels, SUAVE stores specific energy, and critical temperatures. +
+ ++ Location data includes atmospheric data, like the 1976 US Standard + Atmophere, from which data on pressure, density, etc. can be queried + on an altitude basis. It also includes a data structure for + assigning attributes to specific arrival and departure airports, + though at present SUAVE does not come pre-packaged with data for + specific airports. +
++ SUAVE does, however, come pre-packaged with data for Earth as a + planet including its mean radius, sea level gravity and Hitchhiker's + Guide status. It also includes a generalized Planet data structure + for evaluation of vehicles mean for deployment on Mars, Venus, or + in the atmospheres of the gas giants of the solar system. +
+ ++ The Constant class in SUAVE inherits from the Data class and is + meant to hold data that does not change. This may be physical + constants or else data that is to be monitored for change through + the progress of a mission. SUAVE does not come with any additional + physical constants hard-coded in this section of the library. +
++ This section details the basic data structures SUAVE uses to store + and manage everything from physical constants and material data to + mission simulation and vehicle optimization results. This page has + a brief overview of each data type, and their dedicated pages detail + their methods and child classes. +
+ ++ The most basic of SUAVE data types is the Data class. It takes the + native Python dictionary data type and adds the ability to assign a + tag to the dictionary, and access its values using the '.' operator, + as in: + +
+Data.Key = Value
+ + The Container data type inherits from SUAVE's Data class, and is + thus itself a dictionary with tag and '.' use, as well as the Data + classes extra methods. Data classes can themselves contain other + Data classes in a nested fashion, but Containers are designed to + contain many instances of similar Data structures. +
+ ++ A typical example is that a vehicle has a Container called "Wings" + which contains every one of the vehicle's wings. Similarly, a + mission might contain many segments. Thus, in addition to the basic + methods associated with the Data class, Containers have extra + methods which allow new items to be neatly added in. The most + closely related class are the ContainerOrdered class which adds + ordering to the Data structures contained within it. +
+ ++ Units in SUAVE are handled using + Pint. The default + units are thus all SI: meter/kilogram/second. If left "naked" or + unmodified by a Pint unit class, the unit is treated as the SI unit + appropriate to the measure. Pint's unit classes act to both multiply + a parameter by the appropriate conversion factor, and tag it with + the new unit. +
++ For instance, if you have a wing that's one foot long, + you can write it as: + +
+from SUAVE.Core import Units
+
+wing.spans.projected = 1. * Units.ft
+ + SUAVE models are most naturally written out as Python code + defining all relevant parameters, and may be shared between users as + .py files, or another text format containing all specifications. +
++ + However, mission results and other "online" data is not readily + available within a written vehicle specification or mission setup. + Also, users may wish to share data with others not familiar with + SUAVE, so we have also made it possible to output SUAVE data, + including vehicles, mission specifications, or results data. +
++ The appropriate functions for outputing any SUAVE data stored as a + Data Object into JSON or XML format may be found in the + SUAVE.Input_Output.SUAVE and SUAVE.Input_Output.XML sublibraries. +
++ Components are SUAVE's data structure for modeling and storing + information regarding the various pieces of an aircraft. Each + analysis method in SUAVE requires some component or a combination + of components to be defined and assigned certain paramaters. +
++ Once a component has been defined, it is typically appended to a + Container data structure that holds all of the similar components + for a vehicle model. Main and secondary wings, elevators, etc. are + all collected in a "Wings" Container. Main and nose landing gears + are collected in a "Landing Gear" container. These Containers are + then appended to the Vehicle data structure (covered in the next + section) to assemble a completed vehicle model. +
+ ++ Most methods and analyses in SUAVE are designed to work on the + Vehicle level, even if they only require a subset of Components to + be defined. Thus, it's good practice to append your Components into + Containers and your Containers into a Vehicle, even if you're only + going to, for example, run a particular aerodynamic analysis on a + wing. +
+ ++ Fuselages are SUAVE's data type for passenger and cargo storage + bodies. It has attributes for physical location/origin of the body + relative to the reference origin of the vehicle, the body's + aerodynamic center, and a variety of geometric parameters, such as + its height, width, and length. +
+ ++ Fuselages can be separated into Segments. Each Segment is its own + independent data structure, stored on the fuselage in an Ordered + Container. Segments can be designate particular locations inside + fuselage, such as the cockpit, passenger cabin, and cargo cell, or + to vary the geometry of the fuselage. +
+ ++ Wings are SUAVE's data type for most primary aerodynamic surfaces on + an aircraft. This includes main wings and empennage, as well as + designated control surfaces. They store various attributes such as + span, chord, and airfoil, and may be separated into Segments to + vary these properties, as with fuselages. +
+ ++ Landing Gear is SUAVE's data type for the wheels and struts used to + support an aircraft while in contact with the ground. The parent + Landing Gear class has few attributes to keep it general across + different types of aircraft, but the Main Landing Gear and Nose + Landing Gear child classes include attritubes for strut length, + number of wheels, tyre diameter, etc. This makes them suitable for + use primarily with tube-and-wing civil transport aircraft. +
+ ++ Payloads are SUAVE's data type for things which may be carried by + the aircraft but are not part of it as it sits empty. This may + include passengers or cargo, and the class therefore has few + native attributes to keep it general. +
+ ++ Systems are SUAVE's data type for onboard hydraulic, electric, and + other secondary systems. This may include avionics, environmental + control systems, or anything else which the model must account for. + As such it is also a very general data type with few native + attributes, though it is common to add those necessary to the + analysis methods being used, such as power draw. +
+ ++ Energy Networks are a complex structure incorporating a wide variety + of components and models, including turbofan engines, battery and + hybrid electric power trains, and rocket motors. Little can be said + in brief about SUAVE's energy networks - each is closely tied to + its associated analytic methods and these must be be considered in + detail to grasp how different sub-components and their attributes + interact. +
+ ++ Costs and other non-physical elements of the vehicle may also be + modeled as Components to ensure that they are consistent across + analyses. Attributes such as depreciation lifetime, industrial + costs, and crew rates are stored in this data structure. +
+ ++ Intro Text. +
+ ++ Subsection Text. +
++ Intro Text. +
+ ++ Subsection Text. +
++ This user guide is designed to work as both an introduction and + reference manual for SUAVE. If you're completely new to SUAVE, we + recommend reading through each of the sections below, in the order + listed, to get familiar with the code and how to use it. +
+ ++ The guides are conceptually complete if read on their own, but + advanced guides on vehicles, missions, and optimization will use the + SUAVE tutorial scripts as examples. These can be obtained at the + SUAVE Tutorial + Repository for your reference. +
+ ++ This section details the Data and Container data types that SUAVE + adds on to Python's basic data types, and covers their usage and + associated methods. It also details SUAVE's protocol for assigning + units to vehicle and mission parameters. There are some notes + introductory notes on SUAVE's input/output schemes and how SUAVE + data can be saved and transferred between users. +
+ ++ This section details SUAVE's data libraries for materials (including + solids, liquids, gases and propellants), environments (local airport + data, atmospheric models, planetary conditions), and physical + constants. +
+ ++ This section details SUAVE's native component types, including + fuselages, wings, landing gear, payloads, systems, and energy + networks. +
+ ++ The section on energy networks has a more detailed breakdown of the + various sub-component types involved in simulating propulsion + system behavior including the various types of networks and the + storages, distributors, converters, and peripherals involved. +
+ ++ Some non-physical attributes of vehicles, such as cost estimations, + are also treated as components within SUAVE and are detailed here. +
+ ++ Vehicles are largely containers for collections of components within + SUAVE, and so SUAVE has no native types of vehicles. This + section details how components are collected together within a + single vehicle, and how multiple configurations of that vehicle are + created within a single data structure. +
+ ++ This section details each of SUAVE's built-in analysis methods. + These include a variety of vortex lattice methods for aerodynamics + and native methods for propulsion, weights and CGs, flight dynamics, + costs, and noise generation. +
+ ++ These methods are only those coded natively in Python and included + as part of SUAVE. The next section on Input/Output details using + SUAVE alongside third party tools to augment SUAVE's native + capabilities. +
+ ++ This section details using external tools to augment SUAVE's + analysis capabilities, including + AVL, + OpenVSP, + SU2, and + GMSH, all of which are free and open + source tools for aircraft design and analysis. +
+ ++ In addition to interfacing with analysis tools, SUAVE includes + capability to export and import data from other instances of SUAVE, + or in XML, D3.js, or FreeMind formats. +
+ ++ This section details setting up collections of SUAVE methods and + external tools in order to run multi-disciplinary analyses of + vehicles. Many comprehensive methods have dedicated methods, but + methods can be mixed and matched as desired. +
+ ++ This section details both the numerical methods and structure SUAVE + uses to determine solutions to its analyses. The different types of + mission segments native to SUAVE such as climb, cruise, hover, + descent, etc. are also detailed here. +
+ ++ This section details SUAVE's optimization structure, use of the + nexus data structure for storing optimization data and parameters, + and the various optimization packages SUAVE is designed to work + with, including PyOpt and + + SciPy's optimization module. +
+ ++ This section details knowledge needed to begin modifying SUAVE and + contributing to its development, including use of the GitHub + repository for version control, SUAVE's Style Guide, and the + particulars of the developer installation. +
+ ++ This section details the ways SUAVE users and developers can obtain + help with any problems or development goals they may have, including + the SUAVE forum and developer's e-mail list. +
+ ++ Methods are where the proverbial rubber begins to meet the road in + SUAVE. Up until this point, the User Guide has covered primarily how + SUAVE stores and organizes data. Methods are how SUAVE uses that + data to calculate performance and characteristics of the vehicle. +
++ Methods themselves are design to be relatively "atomic" - + self-contained, straight-forward input-output functions. This both + allows some of them to be broken out of SUAVE entirely and used in + much the same way as NumPy or SciPy functions, but "within" SUAVE + it allows them to be swapped in and out or assembled into more + complicated Analyses, which are covered in a separate section. +
++ Generally speaking, SUAVE Methods are sensitive to their input + parameters and data types. They are "Garbage In, Garbage Out" and + are not robust against non-physical or physically impossible setups. + If methods seem to be returning non-sensical, non-numerical, or + unconverging values, they are likely reflecting the physical + impossibility of the inputs. +
++ Because the Methods can be driven to such extremes by a wide + variety of conditions, there is little customized error handling. + The burden lies on the user to ensure that their input models and + data are sensible and well structured. +
+ ++ Aerodynamic Methods are those used to solve aerodynamic equations + for input vehicle/wing geometries. They include lifting line and + potential flow solvers like the Weissinger Vortex Lattice and + Athena Vortex Lattice methods, as well inviscid and Euler CFD + solutions through interface with the SU2 CFD package. +
++ They are typically used to resolve lift and drag vectors for + aerodynamic surfaces and vehicles. Where the solver also + provides pertinent stability information, processing of this + information is performed with a separate and Analysis. +
+ ++ Propusion Methods include those used in the analysis of propulsion + systems, including turbofans, propeller systems, and rocket motors. + They include methods for sizing these systems and resolving thrust + vectors. +
++ Because propulsors are usually highly coupled to the energy network + of a vehicle, many of these methods are only meaningful when used to + analyze a fully described energy network. For instance, use of + propeller methods on a battery powered vehicle without consideration + of the stateof charge and available voltage of the battery may + overestimate the thrust the propeller could provide. +
+ ++ Weights are those Methods concerned with estimating the mass and + weight of a vehicle and its various components. At present, these + Methods are separated into two types - Correlations, and Buildups. +
++ Correlation methods use historical data to estimate the weight of a + new aircraft of similar configuration and operational plan. SUAVE + utilizes Methods of this type to estimate the weight of most + aircraft including tube-and-wing civil transports, general aviation + craft, and blended-wing-bodies. Buildups use ground-up physics based + component sizing to arrive at a weight estimate. SUAVE uses Methods + of this type for electric vertical take-off and landing aircraft. +
+ ++ Center of Gravity (CG) Methods estimate the location of a vehicle's + CG, the CGs of its components, and fuel loads. These methods are + typically coupled with methods in the Flight Dynamics library for + estimating vehicle stability parameters, but may be used + independently if desired. They require all components to be + assigned individual origin attributes in a consistent and cohesive + manner. +
+ ++ Flight Dynamics Methods are those concerned with estimating a + vehicle's static and dynamic stability margins and derivatives. They + are built into SUAVE and may therefore be used separately from or + in addition to aerodynamic solvers such as AVL which provide + similar information. +
+ ++ Cost Methods estimate the industrial and operating costs of a + vehicle based on the physical and Cost attributes assigned to the + model. +
+ ++ Geometry Methods are largely supporting methods used in substeps of + other Methods, such as processing data for airfoils, cross-sectional + areas inside of jet engines, or projected planforms of aerodynamic + surfaces. They may however, also prove useful when used outside of + SUAVE Methods as independent functions. +
+ ++ Noise Methods are used to estimate jet-wash, propeller, airframe, + and other sources of operational noise when the aircraft is in + operation. At present, SUAVE's methods for noise estimation include + a number of correlative and low-fidelity physics based methods. +
+ ++ Intro Text. +
+ ++ Subsection Text. +
++ Intro Text. +
+ ++ Subsection Text. +
++ Intro Text. +
+ ++ Subsection Text. +
++ Intro Text. +
+ ++ Subsection Text. +
++ Vehicles are SUAVE's over-arching data type for assembling + Containers of Components into one, cohesive data structure. In + addition to the Containers, it stores attributes on total vehicle + mass properties, passenger capacity, and the vehicle's operating + flight envelope. +
++ Most analyses in SUAVE are written to operate on a Vehicle data + structure, and so components should be assembled into Containers + and Containers into Vehicles, even if only certain components or + certain attributes are necessary to run an analysis. +
+ ++ It's common for users to wish to study several different slight + variations on the same vehicle, or have that vehicle modify itself + slightly throughout a mission simulation. Studying different + proposed wings appended to the same fuselage, or deployment of slats + or flaps during take-off and landing are typical examples. +
++ The Configuration data-type exists to facilitate such cases. Each + Configuration is created from a reference, "base configuration", and + needs only its differences from that base configuration designated. +
++ Thus, typical procedure in such cases is to define the common set of + Components across all Configurations of the Vehicle, and create a + base configuration comprised of Containers of those Components. + Then, separate Configurations can be created using differentiated + componentry. Then, all the different Configurations are assembled + into one, top-level Vehicle data structure that stores all the + different Configurations. +
++ Analyses which are designed to run on Vehicle data structure will + either just as easily run on a specific configuration, or if run + inside a mission, will identify the Configuration being used at + the moment, such as the case of flap deployment during a landing + segment. +
+