# 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](https://doi.org/10.5194/wes-4-663-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](https://ieawindsystems.github.io/windIO/main/source/plant_schema.html#site_energy_resource_wind_resource) 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](https://nrel.github.io/floris), 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.