GitHub

Required Inputs

As briefly described in the Quick Start there are three required inputs to the analysis function: a DuctedRotor object, comprised of duct and center body coordinates, a Rotor object, and a PanelingConstants object; an OperatingPoint or vector of operating point objects; and a ReferenceParameters object.

DuctedRotor

The DuctedRotor input contains all the information related to the geometry of the ducted rotor system and how that geometry will be handled in the preprocessing stage of the analysis.

DuctAPE.DuctedRotor — Type
DuctedRotor(
    duct_coordinates, center_body_coordinates, rotor, paneling_constants; kwargs...
)

Arguments

  • duct_coordinates::AbstractMatrix : The [z r] coordinates of the duct geometry beginning at the inner (casing) side trailing edge and proceeding clockwise. Note that the duct geometry absolute radial position does not need to be included here if the autoshiftduct option is selected.
  • center_body_coordinates::AbstractMatrix : The [z r] coordinates of the center_body beginning at the leading edge and ending at the trailing edge. Note that the leading edge is assumed to be placed at a radial distance of 0.0 from the axis of rotation.
  • rotor::Rotor : Rotor (and possibly stator) geometric paramters.
  • paneling_constants::PanelingConstants : Constants used in re-paneling the geometry.

Keyword Arguments

  • i_know_what_im_doing::Bool=false : if set to false, performs various checks on the inputs and manually adjusts in some cases with a warning, and errors in cases that cannot be automatically adjusted.
  • silence_warnings::Bool=false : if set to false, prints warnings when automatically adjusting inputs.
source

Duct and Center Body Coordinates

The duct and center body coordinates are input into the DuctedRotor type in the order of duct then center body. Both sets of coordinates must be given in a counter-clockwise order. For the duct, that means the coordinates start at the inside trailing edge, and continue clockwise around the leading edge and end at the outside trailing edge. For the center body, that means the coordintes start at the leading edge and end at the trailing edge. In addition, the coordinates are expected to be provided in columns of the format [z r], where z are the axial coordinates and r are the radial coordinates (analogous to x and y common for 2D airfoils). There are several checks in place when the DuctedRotor object is constructed to attempt to ensure the formats are correct, but it would be best to input things correctly in the first place.

Rotor

The Rotor object contains mostly information about the rotor blade geometry, but also includes details used for the blade section lift and drag polar lookups. For the most part, the inputs are pretty straightforward and the docstring below is sufficient to understand what they are. In general, the blade geometry should be defined from hub to tip, therefore the radial locations should be monotonically increasing. Care should be taken to note which inputs are dimensional and which are non-dimensional. It should also be noted that the rotor inputs are always interpolated as part of the analysis preprocess.

DuctAPE.Rotor — Type
Rotor(
    B, rotor_axial_position, r, Rhub, Rtip, chords, twists, tip_gap, airfoils, is_stator
)

Composite type containing the rotor(s) geometric properties.

Note that the actual struct requires the inputs to be arrays, but there is a constructor function that will take in scalars and automatically build the array-based struct.

Arguments

  • B::AbstractVector{Float} : The number of blades for each rotor. May not be an integer, but usually is.
  • rotor_axial_position::AbstractVector{Float} : Dimensional, axial position of each rotor.
  • r::AbstractArray{Float} : Non-dimensional radial locations of each blade element.
  • Rhub::AbstractVector{Float} : Dimensional hub radius of rotor. (may be changed if it does not match the radial position of the center_body geometry at the selected rotor_axial_position.
  • Rtip::AbstractVector{Float} : Dimensional tip radius of rotor. Is used to determine the radial position of the duct if the autoshiftduct option is selected.
  • chords::AbstractArray{Float} : Dimensional chord lengths of the blade elements.
  • twists::AbstractArray{Float} : Blade element angles, in radians.
  • tip_gap::AbstractVector{Float} : Currently unused, do not set to anything other than zeros.
  • airfoils::Vector{Vector{AFType}} : Airfoil types describing the airfoil polars for each rotor and blade element [[rotor 1 airfoils], [rotor 2 airfoils], ...].
  • is_stator::AbstractVector{Bool} : Flag to indicate if the airfoil lift values should be flipped or not.

Keyword Arguments

  • i_know_what_im_doing::Bool=false : if set to false, checks the twist angles, and if greater than 1.75, prints a warning and converts from degrees to radians.
source

Airfoils

The input with the most flexibility in the Rotor object is the airfoils input. These "airfoils" are really the methods for looking up the lift and drag polar values given inputs such as angle of attack, Reynolds number, Mach number, etc. Airfoil types for DuctAPE are currently contained in the C$^\textrm{4}$Blade sub-module of DuctAPE which is exported as c4b and also contains the various airfoil evaluation functions used for the blade element lookups. The available airfoil types include all the airfoil types from CCBlade, as well as DFDCairfoil which is an XROTOR-like parametric cascade polar used in DFDC. In addition there are untested cascade types with similar structure to CCBlades airfoil types called DTCascade. Furthermore, there is an experimental actuator disk model implemented via the ADM airfoil type in C4Blade. Any airfoil object used needs to be able to be deconstructed into a vector for compatiblity with PreallocationTools (see Precompiled Caches below) and then automatedly reconstructed inside the solve. This process has been generalized for all the C4Blade airfoil types, and should work without much issue for other types as long as the airfoil type fields are arrays of numbers. In addition, if custom user types are added, they must be of one of the C4Blade abstract airfoil types, otherwise DuctAPE will not know which evalutaion function to use and throw an error.

PanelingConstants

The PanelingConstants object contains all the information required to dictate how the preprocess repanling will take place and almost all of the information required to generate the precompiled caches.

The first two inputs dictate the number panels that should be used in repaneling the region of each body from their respective leading edge to the axial position of the first rotor. Note that even though we have called this region the inlet, it really controls the number of panels ahead of the first rotor's axial position. The num_panels input is a vector describing the number of panels to be linearly spaced between each discrete location in the system, where discrete locations are rotor axial positions as well as the axial position of the body trailing edges (in the case of the duct, this is the interior trailing edge, even though the exterior trailing edge could be further back in the case where a trailing edge gap is present).

The dte_minus_cbte is the duct trailing edge axial position minus the center body trailing edge axial position. If it is zero, the axial positions of duct and center body trailing edge must be exactly equal.

The num_wake_sheets controls how many blade elements are interpolated from the Rotor input. The wake sheets are linearly interpolated along the first rotor from center body to duct, so there are one fewer blade elements than wake sheets. Note that there is no way to manually control how the wake aligns with rotors aft of the first rotor, so those rotor inputs will be interpolated at the points at which the wake sheets align.

The wake_length input defaults to 1.0 and we have found that to be a generally reasonable value. Note that a shorter or longer wake will not lead to a change in number of panels since the last entry in num_panels controls that.

DuctAPE.PanelingConstants — Type
PanelingConstants(
    num_duct_inlet_panels,
    num_center_body_inlet_panels,
    num_panels,
    dte_minus_cbte,
    num_wake_sheets,
    wake_length=1.0,
)

Constants used in re-paneling geometry.

Note that unlike other input structures, this one, in general, does not define fields as vectors. This is because these values should not change throughout an optimization, even if the geometry may change. Otherwise, discontinuities could be experienced.

Arguments

  • num_duct_inlet_panels::Int : The number of panels to use for the casing inlet.
  • num_center_body_inlet_panels::Int : The number of panels to use for the center body inlet.
  • num_panels::AbstractVector{Int} : A vector containing the number of panels between discrete locations inside the wake. Specifically, the number of panels between the rotors, between the last rotor and the first body trailing edge, between the body trailing edges (if different), and between the last body trailing edge and the end of the wake. The length of this vector should be N+1 (where N is the number of rotors) if the duct and center_body trailing edges are aligned, and N+2 if not.
  • dte_minus_cbte::Float : An indicator concerning the hub and duct trailing edge relative locations. Should be set to -1 if the duct trailing edge axial position minus the center_body trailing edge axial position is negative, +1 if positive (though any positive or negative number will suffice), and zero if the trailing edges are aligned.
  • num_wake_sheets::Int : The number of wake sheets to use. Note this will also be setting the number of blade elements to use.
  • wake_length::Float=1.0 : Non-dimensional (based on the length from the foremost body leading edge and the aftmost body trailing edge) length of the wake extending behind the aftmost body trailing edge.
source

OperatingPoint

The OperatingPoint inputs contains all the information concering the freestream as well as the rotor rotation rate(s). Note that the pressure and temperature fields in the struct are currently unused. For analyses with multiple operating points a vector of these objects should be used, even though many of the fields will be repeated.

DuctAPE.OperatingPoint — Type
OperatingPoint(Vinf, Minf, rhoinf, muinf, asound, Ptot, Ttot, Omega)
OperatingPoint(
    Vinf, Omega, rhoinf=nothing, muinf=nothing, asound=nothing; altitude=0.0
)
OperatingPoint(
    ::Imperial, Vinf, Omega, rhoinf=nothing, muinf=nothing, asound=nothing; altitude=0.0
)

DuctedRotor operating point information.

Functions that take in altitude will populate undefined thermodynamic properties of the freestream using a standard atmosphere model, ideal gas law, and Sutherland's law; defaulting to SI units. If the ::Imperial dispatch type is input, then the thermodynamic properties will be converted to Imperial units.

Fields/Arguments

  • Vinf::AbstractVector{Float} : Freestream velocity magnitude (which is only in the axial direction).
  • Minf::AbstractVector{Float} : Freestream Mach number
  • rhoinf::AbstractVector{Float} : Freestream density
  • muinf::AbstractVector{Float} : Freestream viscosity
  • asound::AbstractVector{Float} : Freestream speed of sound
  • Ptot::AbstractVector{Float} : Freestream total pressure
  • Ttot::AbstractVector{Float} : Freestream total temperature
  • Omega::AbstractVector{Float} : Rotor rototation rate(s)
source

ReferenceParameters

The ReferenceParameters are only used in the postprocessing to compute various coefficients. Usually, the reference radius is simply the rotor tip radius. The reference velocity may be selected as the freestream velocity, but often may not be, for example in the case of zero freestream velocity (static conditions), the reference velocity should probably be some non-zero value such that the coefficients don't simply return zeros or infinities.

DuctAPE.ReferenceParameters — Type
ReferenceParameters(Vref, Rref)

Reference parameters for post-process non-dimensionalization.

Note that the actual struct requires the inputs to be arrays, but there is a constructor function that will take in scalars and automatically build the array-based struct.

Arguments

  • Vref::AbstractVector{Float} : Reference velocity.
  • Rref::AbstractVector{Float} : Reference rotor tip radius.
source