OpenMDAO Component types

The design intention of Ard is to offer a principled, modular, extensible wind farm layout optimization tool.

In order to balance focus with the modularity and extensibility intended for the code, we will classify different types of components, and build "base Ard" with a set of default components. Each type of component will be defined below, and each type of component will have a template parent class which can be used to derive custom user-defined components to serve as drop in replacements in Ard.

Ard has a set of fundamental variables, that we expect to be used in (almost) every simulation:

• x_turbines: a vector of \(x\)-location of each turbine, i.e. in an East-West local coordinate frame

• y_turbines: a vector of \(y\)-location of each turbine, i.e. in an North-South local coordinate frame

• power_farm: a float-valued estimate of the farm's power at a set of wind conditions

• AEP_farm: a float-valued estimate of the farm's annual energy production (\(\mathrm{AEP}\)), when full wind rose data is provided

Layout DV Components (layout)

Wind farm layout optimization is known to be a significantly challenging problem for global optimization, due to the existence of many local minima (see, e.g., Stanley and Ning, 2019, among many others). One strategy for reducing the dimensionality of the design space is to use layout models. layout components are for connecting some reduced layout variables to the turbine location variables, x_turbines and y_turbines. These reduced-dimensional variables can be passed to downstream analyses or the full \((x,y)\) set of coordinates can be used for downstream analyses.

The default layout component is the grid farm layout defined in ard/layout/gridfarm.py, which parameterizes a structured rectilinear farm in terms of a primary axis, aligned with respect to North by an orientation angle coincident with compass rose angles, with rows spaced along this axis by a constant spacing measured in rotor diameters; and a secondary axis, skewed from orthogonal by a skew angle in the direction of compass angles, with rows spaced along this axis by a constant spacing. This results in four parameters, two nondimensional spacing values and two angles.

tl;dr: layout components map from a simplified parameter set to Cartesian farm coordinates

Farm Aero Components (farm_aero)

farm_aero components take in a set of farm layout design variables, in terms the turbine location variables, x_turbines and y_turbines, and potentially some control command input, namely yaw_turbines.

In addition to these design variables, the turbine definitions to be used and some (possibly comprehensive) set of wind conditions to be queried from a windIO plant file are also provided to a given farm_aero component.

The result of a farm_aero component is the power or energy production quantity of interest given the wind resource.

The default farm_aero component is NREL's FLORIS tool, which can be found at ard/farm_aero/floris.py. We wrap FLORIS to map from x_turbines, y_turbines, and yaw_turbines to turbine powers, turbine thrusts, farm power, and, optionally, farm AEP.

tl;dr: farm_aero components map from a farm layouts and possibly control settings to some measure of farm power production

Collection Components (collection)

collection components model the systems that handle the "collection" of energy generated by wind turbines. Namely, this consists of power management systems that move energy from wind turbine generators to substations where energy can be efficiently converted to appropriate forms for long-distance transmission.

collection components take in farm layout (in terms of x_turbines and y_turbines), turbine specifications, and substation location(s) (in terms of vector-valued x_substations and y_substations), and output a set of cable edge lengths, required capacities, and other information about the cable paths.

tl;dr: collection components map farm specifications to the necessary energy management systems

Economics and Finance Components (cost)

The cost components are less formally structured than the components above, but generally take inputs that are consumable stocks or marketable products of a wind system. Meanwhile, they give as outputs some measure of the value that the wind system can create. Complete details are provided in the components in the ard/cost folder.

The default cost component set are the WISDEM tools given in ard/cost/wisdem_wrap.py, which include WISDEM's LandBOSSE module for BOS calculation and WISDEM's PlantFinance module for computation of LCOE.

tl;dr: cost components map from machines and their production of energy to money inputs and outputs

Explanation of Utilities (utils)

The utils sub-module of Ard contains the many generic capabilities needed for effective wind farm design and optimization in order to facilitate maximum code reuse. However, utils includes only generalized functions and methods and excludes most code that is technology-specific (see IO as an exception). As the capabilities in utils expand, some of them could eventually be broken off into a separate package. Utilities are divided into the following categories:

Core

The capabilities housed in core.py are generic and short enough that having a discipline-specific file is not warranted.

Geometry

The capabilities housed in geometry.py are generic geometry-related code. They calculate distances, define shapes, and generally simplify working with geometric tasks in a continuously differentiable way in Ard.

IO

The capabilities in io.py provide for loading and saving information and may be technology specific.

Mathematics

The capabilities housed in mathematics.py are pure mathematical functions generally formulated to be continuously differentiable. These functions are useful in a range of applications within Ard and design optimization generally.

Test Utils

The capabilities housed in test_utils.py are specifically for use in testing and not in other parts of Ard.