BEMT is well-documented in standard aerodynamic texts , so here we focus on its application within our aero-structural coupling framework. For our BEMT, we use Ning's one-residual formulation inside of the code package CCBlade.jl (https://github.com/byuflowlab/CCBlade.jl, last access: 3 December 2025). Using a BEMT with one residual allows for solvers with guaranteed convergence such as Brent's method . This reliability transfers through to the derivative calculation, providing smooth derivatives of the aerodynamic solution across the design space.

Prandtl tip corrections are applied at both the hub and the tip. The 2D airfoil polars from the wind turbine description are provided at 17 spanwise stations and have been smoothed using B splines. Linear interpolation between these stations produces airfoil polars at each blade node. The smoothing and interpolation are performed as a preprocessing step, while Akima splines interpolate each polar during the solution process.

To enable unsteady analysis with BEMT, we implement the Beddoes–Leishman dynamic stall model incorporating Gonzalez's modifications . Our implementation follows the discrete ordinary differential equation formulation from OpenFAST v3.5.1 and is available in DynamicStallModels.jl (https://github.com/byuflowlab/DynamicStallModels.jl, last access: 3 December 2025). The state predictions match those of OpenFAST to machine precision.

In the pre-process step (and outside of all optimization loops), we generate a spatially uniform turbulent wind field using TurbSim. The outputs used at every time step of the time-domain analysis are the three components of the wind speed (U, V, and W). For simplicity, the velocity is assumed to be uniform across the rotor plane; however, WATT.jl could be easily extended to accommodate a spatially varying wind field. WATT.jl is already capable of using a temporal discretization independent of the time step used in the turbulence model, but the results are co-located for the purpose of this study.

As previously mentioned, we use the nonlinear GEBT solver GXBeam.jl to predict the structural response of the wind turbine blade. The formulation of GXBeam allows large deflections and rotations, while maintaining solution robustness and derivative stability. GXBeam uses the Newmark-beta method to integrate the equations of motion across time. The inputs to the model are the loads, the blade geometry, and the material properties. The outputs used for the aero-structural coupling are the linear/angular deflections and velocities. The internal forces and moments are also available for post-processing. The blade is modeled as a cantilevered beam with a fixed root and free tip. Aerodynamic loads are rotated into the root reference frame and applied as non-following distributed loads, which are assumed constant across each element.

To prepare the cross-sectional properties for the beam model, we use CLT to calculate the mass and compliance properties of the cross-section. Since traditional classical laminate theory is designed for composite flat plates, we use the Kollar and Springer formulation in the GXBeamCS.jl package (https://github.com/byuflowlab/GXBeamCS, last access: 3 December 2025). This formulation allows for the calculation of the mass and compliance properties of arbitrary cross-sections in a similar manner to PreComp. Key differences are the implementation of the shear flow model, compatibility with AD methods, and post-processing capabilities. Although classical laminate theory has its limitations in precisely predicting cross-sectional compliance, its accuracy remains sufficient for practical purposes, and its mesh-free nature greatly simplifies analysis and parameterization for optimization. Analysis is done at the elastic center and in the principal axes, so calculation of the axial strain is straightforward.

We used three approaches for material failure analysis: ultimate strain, panel buckling, and linear accumulation of fatigue damage. The strain calculated in the cross-section analysis can be used to calculate material failure by comparing against the ultimate strain. Buckling is predicted using a simple panel buckling method .

To predict the fatigue damage, we use ASTM's range-pair rainflow counting algorithm to separate the strain signal into load ranges and corresponding counts. Before applying Miner's rule, we apply the Goodman correction. Typically, fatigue damage is accumulated by analyzing the stress signal; however, we directly use the strain signal to avoid including the inaccuracies included in the compliance matrix from CLT. This action is equivalent to assuming that all of the off-diagonal terms of the compliance matrix are zero. This assumption is reasonable for our case since the CLT approach does not account for these compliance values, and they are already assumed to be zero.

As previously mentioned, AD provides a means of computing derivatives both more accurately and more efficiently than finite differencing. AD calculates the derivatives of the function by calculating the partial derivatives of each elementary operation in the code and then combining them using the chain rule . In AD, the derivatives are computed after each operation is performed and then propagated through the code to obtain the function output and its derivative with respect to the function input. Because the derivatives are calculated analytically for each operation, the precision of the derivatives can match the precision of the function evaluation. The exact nature of AD-computed derivatives does not mean that the approach is impervious to error. Like any floating-point computation, numerical error can still accumulate through round-off error, particularly in complex models with many operations. This challenge is particularly poignant when iterative solvers are used, such as in Brent's method for the BEMT or in the Newmark-beta method for the GEBT.

Several factors influence the efficiency of AD. There are two modes of AD: forward mode and reverse mode. In forward mode, the derivatives are propagated from the inputs to the outputs, while in reverse mode, the derivatives are propagated from the outputs to the inputs. Since reverse mode backpropagates the derivatives in reverse, it requires a computational graph to be saved so that the derivative can be calculated in a reverse pass. Saving the computational graph increases memory usage, which can become prohibitive if the computational graph is large. Forward-mode AD, similar to finite differencing, calculates an entire column of the Jacobian at a time, whereas reverse-mode AD calculates an entire row of the Jacobian at a time. This means that the computational cost of forward-mode AD scales linearly with the number of inputs, while the computational cost of reverse-mode AD scales linearly with the number of outputs. Thus, reverse-mode AD is more efficient for functions with many inputs and few outputs, while forward-mode AD is more efficient for functions with few inputs and many outputs. In practice, forward mode is also more efficient for square Jacobians because of the overhead cost of storing the computational graph. Having two modes of AD to choose from allows the user to select the most efficient method for their specific problem. In this work we use the ForwardDiff.jl and ReverseDiff.jl packages (https://github.com/JuliaDiff/ReverseDiff.jl, last access: 22 November 2025) for forward- and reverse-mode operator overloaded AD respectively.

One feature of ForwardDiff.jl with particular relevance to our study is chunking. ForwardDiff stores the primal (the function value) and derivative of each operation in an object called a dual number, rather than as a typical floating-point number. Each dual number can be tagged to several design variables, so the derivative of multiple design variables can be calculated in the same function call, at the expense of additional memory. These groups of design variables are called chunks. Theoretically, given enough memory, the chunk size can be increased to include all design variables, allowing the entire Jacobian to be calculated in a single function call, but typically memory limitations keep the chunk size around eight. The chunk size is determined by heuristics within ForwardDiff.jl and for this optimization problem is set to eight. While increasing the size of a chunk does not decrease the total number of computations required, it can improve the efficiency of the derivative computation process by reducing the overhead associated with running the code multiple times.

Implicit differentiation can be used to further improve the efficiency of derivative computation, specifically when iterative solvers are used. The operation of solving for the derivative of a nonlinear system of equations can be reduced to a single implicit analytic operation . Rather than differentiating through each solver iteration, implicit differentiation exploits the fact that the converged residual equals zero. By applying the chain rule to this converged residual equation, we obtain a linear system whose solution provides the desired derivatives. The required partial derivatives of the residual can be computed using AD. This process can be generalized to any solution process for which the residual can be evaluated with AD. In this work we automate this process by using the ImplicitAD.jl package, which we developed in previous work

In this work we more fully describe the process of automating implicit analytic methods.

Both AD and finite-difference methods can be parallelized. While this does not reduce the number of computations required, it can improve the real time required for derivative computations, especially for large-scale problems. Despite these improvements, finite differencing still suffers from accuracy errors, and AD should be used when it is available. In this work, we use the PolyesterForwardDiff.jl package to parallelize the forward-mode AD calculations.

When applying PolyesterForwardDiff, the required number of processors can be determined from the following relationship: 1Nproc=ceilNdvNchunk, where Nproc is the number of processors, Ndv is the number of design variables, and Nchunk is the chunk size. This relationship is the direct result of the chunking process described previously. While the parallel derivative computation cannot leverage more processors to reduce the wall time, parallelization can still be exploited in other parts of the problem, such as running multiple design load cases simultaneously.

As previously mentioned, Jacobians in many engineering problems exhibit sparsity. Sparse matrix formats store only the non-zero entries along with their indices, rather than the entire matrix. The indices of the non-zero entries form the sparsity pattern of the matrix. Sparse formats enable operations to be performed exclusively on non-zero entries, reducing computational cost. Additionally, sparse storage drastically reduces memory requirements compared to dense matrix formats.

By leveraging the sparsity pattern of the Jacobian, the number of computations required to compute the derivatives can be further reduced . The process of leveraging the sparsity pattern is to (1) determine the sparsity pattern of the Jacobian, (2) find the colorings of the Jacobian, and (3) compute the colored Jacobian. The first two steps can be done before the optimization process begins, while the last step is done during the optimization process. We proceed by examining each of these three steps in more detail.

Since the sparsity pattern of a Jacobian may have variations throughout the design space, we estimate the global sparsity pattern by combining the sparsity pattern of randomly chosen designs. Sparsity patterns can be combined by summing the absolute values of each of the elements of the Jacobian: 2Jglobal=∑i=1N|Ji|, where Jglobal is the global sparsity pattern, Ji is the sparsity pattern of design i, and N is the number of designs used to determine the global sparsity pattern.

Coloring a Jacobian is the process of determining which columns (or rows) of the Jacobian are structurally orthogonal to one another. Two structurally orthogonal columns are those that do not share any non-zero entries in the same row. When computing the derivative, structurally orthogonal columns can be computed simultaneously without interference, effectively reducing the number of columns that need to be computed. Depending on the sparsity pattern of the Jacobian, multiple columns can be structurally orthogonal to one another. Columns that are structurally orthogonal are referred to as having the same color. In this work, we use the Greedy D1 coloring algorithm in SparseDiffTools.jl (https://github.com/JuliaDiff/SparseDiffTools.jl, last access: 22 November 2025) to determine the color of each of the columns of the Jacobian of the constraints. We compute the colored Jacobian following an approach similar to SparseDiffTools.jl but re-implement it to enable efficient parallelization. Specifically, we use PolyesterForwardDiff.jl to compute the colored Jacobian.

While sparsity can be applied to both the columns and the rows of a Jacobian, constraint aggregation offers a complementary approach for compressing dense rows. Among various aggregation techniques, the Kreisselmeier–Steinhauser method effectively computes a smooth maximum over a constraint set. By formulating constraints as gi≤0, multiple constraints can be combined into a single aggregate constraint. This aggregation provides minimal benefit for forward-mode methods (forward-mode AD, direct implicit differentiation, and finite differences) but substantially accelerates reverse-mode approaches by reducing the number of required reverse passes. The trade-off is that constraint intersections are smoothed into a single curve, introducing a small offset from the true feasibility boundary that depends on the aggregation parameter. This parameter must balance smoothness for differentiation against accuracy in representing the original constraints. Adaptive approaches, such as the approach proposed by , assist in selecting appropriate parameter values. We apply KS aggregation with reverse-mode AD later in this work to compute constraint Jacobians in a single reverse pass.

For the power generation case, we allow the optimizer to vary the tip speed ratio and the pitch of all 23 wind speeds. This accounts for 24 additional design variables. In total, this problem has 57 design variables. While a comprehensive blade optimization would include additional variable types, we limit the design space to maintain focus on demonstrating the derivative computation methods.

The objective function is the cost of energy. The cost of energy is estimated using the cost model in WISDEM : 3COE=FCR⋅ICCAEP+OPEX(1-TR)AEP, where FCR is the fixed charge rate (assumed to be 0.1158), ICC is the initial capital cost, AEP is the annual energy production, OPEX is the annual operating expenses (assumed to be USD 144 000 per year), and TR is the tax rate (assumed to be 0.4). All of the assumed values in the cost model are based on values found in the implementation of the cost model in WISDEM (https://github.com/WISDEM/WISDEM, last access: 21 November 2025). The initial capital cost is calculated as 4ICC=BOS+TCC+WP, where BOS is the balance of station cost (assumed to be USD 2979 000), TCC is the turbine capital cost, and WP is the warranty premium (assumed to be 13 % of the turbine capital cost). The turbine capital cost is a summation of simple empirical models for the major components of the wind turbine, including the rotor, nacelle, and tower.

These models are dependent on various aspects of the design, such as the rotor diameter, the rated power, and the rated torque. The blade cost model is the most directly used in this optimization problem: 5cblade=14.6mblade, where mblade is the mass of the blade. The mass of each blade design is calculated by multiplying distributed weight (from the cross-section inertial data) of each beam element by the volume of the element (assuming that the density of each beam element is constant) and summing the result across the entire blade.

The AEP is calculated by integrating the power curve across a standard Weibull distribution with a mean wind speed of 6 ms-1 and a shape parameter of 2.0. Since the power curve can be calculated via steady analysis, we perform this calculation just using CCBlade.jl (not including the entire aero-elastic solver). The power is constrained to be no greater than the rated power, and the thrust is constrained to be no greater than 600 kN at every wind speed. The thrust constraint is a surrogate for modeling the structural response of the tower. We also constrain the maximum rpm at each wind speed to 12. The power generation case contributes a total of 47 constraints to the optimization problem.

The second case, the parked extreme loading case, assumes a 50-year return-period wind speed of 70 m s⁻¹. Because the loading is treated as steady, the analysis shifts from a time-domain simulation to a steady aerodynamic analysis, with the dynamic stall model omitted. The resulting aerodynamic loads are applied directly to a steady-state beam model solution. The blade is assumed to be in its worst-case orientation (horizontal) with a pitch of 0°. The primary constraints for this case are buckling, ultimate strain, and tip deflection. The Bir buckling criterion is enforced at the top of each layer in the spar cap across all cross-sections, introducing 842 additional constraints. A conservative ultimate strain limit of 0.01 is applied to the top of every layer, in every segment, and across all cross-sections, resulting in 10 355 constraints. The ultimate strain limit incorporates a partial safety factor (γf) of 1.35 and a material safety factor (γm) of 1.1. The tip deflection is constrained to be less than the original design's overhang distance of 5.019 m with a safety factor of 1.15.

The third case is a dynamic turbulent inflow case. The turbulent inflow field is generated as specified in the pre-process step. We use the IEC Kaimal spectrum to generate a turbulent wind field with a 10 m s⁻¹ mean wind speed, a power law exponent of 0.2, and a surface roughness length of 0.03 m. The resulting wind field has an expected turbulence intensity of 0.16. Damage is extended from a simulation damage count to lifetime damage by simple scaling: 6D=Dsimtlifetimetsimulation. The standard approach to calculating damage is by using a weighting of the lifetime damage from a range of different wind speeds. In this work, we calculate damage at only a single wind speed (the turbulent case at 10 m s⁻¹) to focus on demonstrating the capability to include fatigue damage in the optimization loop; full wind turbine design should consider the complete wind speed distribution. Furthermore, the damage analysis is only performed at key locations along the blade. While the strain analysis is relatively quick (93 ms), performing this analysis at every cross-section at every time step results in significant computational times. The damage was calculated at five locations along the blade: the root, the end of the cylinder section, and the three next-highest damage locations in the original design (25.79 %, 39.14 %, and 45.81 % of the blade length).

The IEC standard requires that damage be calculated based on 600 s of simulation in response to turbulent inflow. Typically, in OpenFAST, this is accomplished by running a 650 s simulation and removing the first 50 s of the simulation to allow the system to finish responding to the initial conditions (what we call the transient response). Including a 650 s simulation analysis in the optimization loop would result in significant computational times. To determine the length of simulation for the objective function, we swept the length of the simulation and experimented with several different cutoff times (see Fig. ) when analyzing the initial design.

The cutoff time was determined by running simulations of 600 s plus the portion removed at the beginning. Although the results did not demonstrate convergence at the standard 50 s cutoff, we selected a cutoff of 10 s for two reasons: (1) the relative percent difference in damage between all tested cutoff times and the standard 50 s cutoff was less than 3 %, and (2) including a cutoff reduces the influence of the transient response on the damage calculation. Extended cutoff times beyond 50 s showed no significant improvement in convergence, suggesting that the residual variation is inherent to the stochastic turbulent inflow rather than insufficient simulation duration. After fixing the cutoff at 10 s, we varied the total simulation length. A duration of 100 s was selected, as it was the shortest tested length yielding damage within 5 % of the 600 s result (specifically, within 1.48 %). The damage analysis introduces an additional 1811 constraints to the optimization problem. The damage metric exhibits high sensitivity to design changes, with values that can vary by multiple orders of magnitude. To improve optimizer performance, we apply a logarithmic transformation. Specifically, the damage is scaled by the safety factor (γfatigue=1.3), logarithmically transformed, and then constrained to be less than or equal to zero.

Finally, the tip deflection is constrained to be less than 90 % of the overhang distance at each time step throughout the same time period used for fatigue analysis. The simulation is run with a time step of 0.05 s, so the total number of time steps analyzed for fatigue and tip deflection is 1801. The size of the optimization problem is summarized in Table . The optimization problem is formulated as follows: 7minimize: COEby varying: ci,θi,sn,βj,λsubject to: Pj<PmaxTj<TmaxΩ<Ωmaxβj<βj+1Bult<1εγfγmεult<1δs<doverhangδk<0.9doverhanglog⁡(D/γfatigue)<0s>smin, where COE is the cost of energy, c is the chord length, θ is the aerodynamic twist angle, s values are the scaling factors of all of the layer thicknesses in a segment, β is the pitching angle, λ is the tip speed ratio, Bult is a buckling constraint, εult is an ultimate strain constraint, δ is a tip deflection constraint, doverhang is the maximum allowable overhang distance, Tmax is the maximum thrust force, Ω is the rpm (and corresponding constraint), D is the section damage constraint, and smin is a minimum manufacturable thickness constraint. Note that the subscript i refers to values that vary across the blade, j refers to values that vary across wind speeds, and k refers to values that vary across time.

Table  shows the wall time and number of allocations of the six different differentiation techniques. We discuss four different features of Table .

First, we see that if we naively apply forward-mode AD to the optimization problem, the stack memory requirements quickly become untenable, specifically when propagating derivatives through the nonlinear solver inside of the time-domain portion of the structural model. These memory issues are not inherent to forward-mode AD with iterative solvers in general but arise from our specific implementation. The structural model we use, GXBeam.jl, is optimized to utilize stack memory for efficient structural analysis by storing variables on the stack rather than on the heap. ForwardDiff.jl tracks derivatives by augmenting each scalar variable with additional derivative information, effectively replacing each number with a small data structure containing both the value and its derivatives. When GXBeam.jl's many stack-allocated variables are augmented with this derivative information, the stack memory capacity is quickly exceeded. Applying implicit differentiation around the iterative solves circumvents this issue by computing derivatives without propagating them through the solver iterations, making AD feasible. GXBeam.jl was designed with implicit differentiation methods in mind so that it can benefit from both the speed of stack memory and the accuracy of AD.

Second, we see a variation in memory usage across the different methods. The number of allocations is not a reflection of how much information is held in memory at once but how much the memory is being used. The reverse-mode method offers a modest reduction in wall time compared to the forward-mode method, at the cost of increased memory usage. However, the increased memory requirements are lower than what a centered finite difference demands. The parallelization of the derivatives provides the largest speedup but requires more allocations than plain forward-mode AD. This is because extra memory must be allocated to avoid data race conditions.

Third, there is opportunity for further speedup of the finite differencing by using more compute resources, specifically the number of threads used in the derivative computation. If memory is not a limiting factor, then theoretically the number of threads could be increased to the number of design variables times 2 (for centered finite differencing). This would reduce the wall time to be about the time it takes for a single function evaluation (about 48.43 s with 114 cores for this problem). Even though modern HPC resources could provide enough threads to make this cost tractable for small problems, they cannot improve the limited accuracy of finite differencing. Higher-order finite-difference schemes can improve derivative accuracy, but such methods are often impractical for large problems. Ultimately, the trade-off between computational resources and real-time performance is an engineering decision, where derivative accuracy remains a critical factor. Additionally, while higher-order finite-differencing schemes can improve the accuracy of the derivatives, they will always be limited by the truncation and round-off errors associated with finite differencing.

Fourth, the sparse method is the fastest method tested for the original optimization problem, over an order of magnitude faster than a centered finite difference. The sparse method is faster than the parallelized method because the sparsity means the method is solving a smaller problem. Because of the relatively low cost of evaluating the power generation case, we separate gradient evaluation from the Jacobian evaluation. Thus, we are able to color the Jacobian and compress the number of columns from 57 to 35 (a reduction of 22 columns or 38 %). The gradient is evaluated using reverse-mode differentiation, which takes about 0.1 s. The Jacobian is evaluated using parallelized forward-mode AD, which takes the rest of the time for the sparse differentiation method.

To demonstrate how the different methods scale with the number of design variables, we performed two types of sweeps: (1) varying the number of control points used in the chord and twist parameterizations and (2) varying the number of wind speeds analyzed in the power generation case. The first sweep increases the number of dense columns in the Jacobian, while the second sweep increases the number of columns that can be colored (see Fig. ). Each method was evaluated 10 times, and the wall times were averaged. We compare methods by examining wall time increase per additional design variable. All methods exhibit approximately linear scaling (O(n)). Note that forward-mode AD without implicit differentiation is omitted due to prohibitive stack memory requirements.

The finite-difference method had the worst scaling in both sweeps. The small difference in the slopes for the two sweeps, 1.63 and 1.59 for the control point sweep and the wind speed sweeps respectively, is likely due to the relatively small sample size used in timing. Parallelizing the finite difference would dramatically increase the scaling of the method at the expense of an obvious increase in computational resources.

Forward-mode AD with implicit differentiation demonstrates superior scaling compared to finite differences, with an average slope of 0.795. This improvement stems from the reduced number of mathematical operations required. Centered finite differences evaluate each operation 1+2N times: once for the primal and twice (forward/backward perturbation) for every N design variables. Forward-mode AD evaluates each operation 1+N times: once for the primal and once per derivative direction. In ForwardDiff.jl, the primal is recomputed for each chunk, so each operation is repeated ceilN/chunk size+N times. With the application of implicit differentiation to the iterative solvers, the iterated operations are only evaluated for the primal solve and not for the derivative computation (although the residual is evaluated once for each derivative). Additionally, since the entire code is evaluated fewer times, there are improved memory savings from re-allocating vectors fewer times.

The reverse-mode derivative with implicit differentiation and constraint aggregation method has the best scaling in both sweep cases, 0.01 and 0.001. This is expected because of the fact that reverse-mode differentiation scales with the number of outputs, not the number of inputs. Since the constraints are aggregated into a single constraint, they can be calculated with a single pass. The differences in scaling between the two cases are likely due to the sample size and locations (i.e., if there were more samples, we would likely see a more consistent slope for the two methods). We do expect to see a slope (and some slight differences in the slope) because there is increased computational costs and memory overhead associated with evaluating a larger primal function. We note that in an optimization setting, instead of aggregating all constraints into a single constraint, you may seek more accuracy in your constraints and so you may aggregate constraints by type. In this case, you can decrease wall time by parallelizing constraint gradient computation.

The parallelized forward mode with implicit differentiation method has the next best scaling. The parallelized forward-mode AD method scales better than the forward-mode AD method because, as the number of columns increased, we increased the number of CPU cores available. To demonstrate the effect of not using an optimal number of cores, we used a constant number of cores in the second sweep. In the first sweep, the slope was 0.03, but the slope for the second sweep was 0.17. You can see two sections where the wall time increases (when it jumps from 64 to 74 design variables and when it jumps from 123 to 134 design variables). Since the chunk size is eight and the sweep uses eight CPU cores, we expect there to be jumps in the wall time when the number of design variables surpasses multiples of 64 (64, 128, 192, etc.). What is happening here is that every 64 design variables, the processors have to run another batch of derivatives in order to calculate all of the columns of the Jacobian. You can avoid these jumps by using more processors or increasing the chunk size. Recall that increasing the chunk size will increase memory requirements and may result in slower derivative computation times. Experimentation is required to determine the optimal chunk size to processor ratio. Outside of the jumps, the scaling of the second sweep is 0.04 (calculated by looking at just the wall times in between the two jumps). The slope of 0.17 is still better than the plain forward-mode method with implicit differentiation because there are more CPU cores working on the problem.

Finally, we consider the sparse parallelized forward mode with implicit differentiation method for calculating derivatives. Note that the slope goes from 0.04 for the first sweep to 0.004 in the second sweep. The slope improves greatly from the first sweep to the second sweep because adding wind speeds adds structurally orthogonal columns to the Jacobian. For this method, this means the only added cost is the added cost of calculating the primal values for the new analyses (in a similar fashion to the reverse-mode method). We note that for the second sweep, we also held the number of CPU cores constant, but because the number of columns of the Jacobian did not effectively change, we do not see any jumps in the wall time.

The techniques presented here can benefit gradient-based optimization across various applications, though implementation considerations differ depending on your starting point. For those developing new analysis tools, incorporating AD compatibility from the outset lays the groundwork for efficient gradient-based optimization. This early consideration should be balanced alongside other design decisions, such as ensuring numerical stability and convergence robustness. For existing codebases where restructuring for AD compatibility may be impractical, techniques like parallelization and exploiting sparsity offer more accessible performance improvements that do not require fundamental code changes. Tests are recommended as scaling is problem dependent.

First, we consider the optimal design and then discuss the performance of the baseline optimization in comparison to a finite-difference approach. The optimization results are summarized in Table , and the optimal design is shown in Fig. .

We performed the baseline optimization in 29.8 h using eight 2.45 GHz AMD EPYC 7763 CPU cores with 7 GB of RAM from the Fulton HPC resources at Brigham Young University. The optimization converged in 104 iterations to an optimality of 4.6×10-5, representing the infinity norm of the Lagrangian gradient. The objective function (COE) decreased by 12.78 % through a 13.03 % mass reduction and 8.59 % increase in annual energy production (AEP). The initial design had 279 active constraints, while the optimal design had 127 active constraints. The optimizer required 179 function calls, including line search evaluations.

When considering the optimal design, we highlight four design trends. We note that since the focus of our work is the optimization efficiency and robustness, we only provide a brief discussion of these trends. First, in Table , we see that the change in blade mass outweighs the change in annual energy production. Consistent with other studies , the material in the blade (and thus the mass) is the primary driver of decreasing the cost of energy. Second, in Fig. , we see a trade-off between the chord and the twist. We see that the chord is increased at the inboard region of the blade, whereas it is decreased near the outboard region. In the outboard regions the twist is also decreased. We see a similar trend in analytic aerodynamic-only optimal solutions (see , for an example of the analytic BEMT optimal solution). However, as seen in Fig. , the solution does not reach the aerodynamic-only solution because the objective function prioritizes cost reduction rather than pure aerodynamic performance. Third, we see a trade-off between the chord and layer thicknesses. We see that in the inboard region, especially in the cylinder region, the layer thicknesses shrink in response to the increased chord. The larger chord is better able to resist the loads applied there, so the thicknesses can be reduced there to decrease the mass. Fourth, the optimized design has a delayed initiation of the blade pitch controller as compared to the initial design. Delaying pitch increases the loading, which in turn increases the torque, resulting in higher power generation. It is important to recognize that since the optimization considers design variables that affect both the design and the control of the wind turbine, it must also analyze the effects they have on each other so that they are co-designed.

Of the 127 active constraints at the optimal design, 28 were minimum-manufacturable-thickness constraints, 1 was the static deflection constraint, 7 were pitch monotonicity constraints, 15 were max power constraints, 73 were buckling constraints, 1 was the max thrust constraint, and 3 were fatigue constraints. The buckling constraints were active in three sections near the hub ranging from 1.9 to 2.1 m. The active fatigue constraints were all located in the trailing-edge segment of the cross-section at the end of the cylinder section. This is typical (see ), as the trailing edge typically experiences the largest-amplitude strain oscillation.

Comparing our approach to finite difference highlights significant practical advantages. The AD-based optimization converged to an optimality of 4.6×10-5 in 29.8 h. From Sect. , we see that finite-difference gradients are approximately 10× slower than the parallelized sparse approach. Assuming that the optimizer would follow the same trajectory as when using the sparse approach, this implies that similar convergence would require roughly 298 h or just over 12 d. To compare against this projection, a centered finite-difference optimization was attempted directly. It failed within the first few iterations. The inherent error in finite-differenced derivatives exceeded the optimizer's default tolerances for gradient noise, causing premature termination before the optimization could progress. While careful hyperparameter tuning and scaling might enable some degree of convergence, reaching the same optimality achieved with accurate AD derivatives would be unlikely. The baseline optimization establishes two key findings: the derivative methods yield physically realistic designs in an optimization, and they significantly outperform finite difference. Single-point convergence alone, however, cannot establish derivative stability throughout the design space.

The second study evaluates derivative stability across the design space through multi-start optimization. Multi-start optimization is a well-established technique for robustly locating global optima , and convergence behavior under this framework provides insight into gradient reliability. Consistent convergence from diverse starting points within the same basin of attraction indicates reliable derivatives, whereas chaotic or inaccurate gradients would prevent the optimizer from repeatedly reaching the same solution. We generated 50 starting designs by randomly perturbing all initial design variables within ±10 % of their baseline values. Design variable perturbations have small magnitudes such that starting designs are likely to occupy the same basin of attraction as the original design. We selected the sample size as it approximates the dimensionality of the optimization problem. Of the 50 runs, 34 optimizations converged smoothly and 16 failed due to structural analysis instabilities. The following analysis addresses converged cases first, followed by the non-converged cases.

The converged optimizations shown in Fig.  demonstrate remarkable consistency. The optimal designs cluster tightly together, with the optimal chord exhibiting an average standard deviation of just 1.08 cm. Such tight convergence indicates that the derivatives are both accurate and consistent across a sizable portion of the design space that the optimizer explored. While a stricter optimality tolerance could reduce this variability, doing so could substantially increase iteration counts and might necessitate stopping and rescaling design variables. If the optimizations were conducted with noisy or inaccurate gradients, we would expect to see a wider spread in the final designs.

A total of 16 randomly generated starting points failed to converge due to numerical instabilities in the unsteady aero-structural analysis, particularly within the structural solver. These failures typically stem from highly elastic blade designs that create positive feedback loops with the aerodynamic model. A finer temporal mesh generally resolves such instabilities. These failure modes are characteristic of the underlying physics and solver performance rather than deficiencies in the derivative computation. The gradients accurately reflect the challenging landscape near infeasible designs. The 34 converged cases validate derivative consistency in the feasible and near-optimal regions.