How to Read (and Write) the Documentation

This is an explanation of how documentation is built in SUAVE so that the user can know what to look for and how to write it if they wish to add their own code. The doxygen page is available here.

Docstrings

All classes and functions in SUAVE have docstrings have docstrings. These give the user an understanding of what the function does and information on the input and output variables.

Classes

For a class, the docstring has three parts:

• General description
• Assumptions
• Source

The general description provides a brief summary of what the class is used for. Assumptions list any significant assumptions are important in how it is used. This may be listed as None or N/A if there are no important assumptions. The source section should provide the general source of methods in the class. If there is no overall source, a message like ‘see sources in functions’ may be appropriate. There are also cases where a source is not relevant, such as simple geometric functions, and may also be listed as None or N/A.

Class Docstring Template

This is the general template that can be used when creating a new class. It should be placed directly under the class declaration.

"""<Description>
			
			Assumptions:
			<any assumptions>
			
			Source:
			<source>
			"""
			

Functions

For functions there are six categories:

• Description

This is a general description of what the function does. It should also include any key information that does not fit into one of the other categories.

• Assumptions

This should contain any assumptions made by the function. None or N/A can be used if none are used.

• Source

The source of any methods that have been implemented. Simple methods like basic geometric relations do not need a source.

• Inputs

This should contain any variables or functions passed to the function. If the passed variable is a data structure, the components that are used should be listed. Each item should include a description if it is not obvious from the name. It should also include any relevant units. In addition, information about the variable type or any other information that might be important can be added here.

• Outputs

This should contain the same information as in the inputs. It may also contain information on variables that are modified but not explicitly returned.

• Properties Used

This carries the same information as input and outputs. It typically contains variables that are properties of the parent class but are not modified. There is some overlap with inputs and outputs, but either category is acceptable as long as the variable is documented.

Function Docstring Template

This is a template docstring:

    """<Description>
			
			Assumptions:
			<any assumptions>
			
			Source:
			<source>
			
			Inputs:
			<input1> <units>
			<input2> <units>
			..
			
			Outputs:
			<output1> <units>
			<output2> <units>
			..
			
			Properties Used:
			<property1> <units>
			<property2> <units>
			..
			"""   
			

Doxygen Grouping Tags

Tags are used to put files into groups that match the SUAVE file structure. @defgroup tags define a group and should be placed in the init file. An example is shown here:

## @defgroup Analyses-Aerodynamics Aerodynamics
			# These are the analyses that control aerodynamic evaluations.
			# @ingroup Analyses
			

In this example, Analyses-Aerodynamics is the doxygen tag for the group, while the group appears in the documentation as Aerodynamics, the next part of the string. The tag is based on the file structure (Analyses/Aerodynamics here). Since this is a subgroup of Analyses, @ingroup Analyses is used here, with Analyses as the doxygen tag for the next level up.

In files, the @ingroup tag should be inserted before all classes and stand-alone functions. The tag should match the tag in the folder init file’s @defgroup string.