# Presentation: 194832

## AeroDyn Theory and Structure —  

- 	AeroDyn Overhaul Kick-Off Meeting
- National Wind Technology Center (NWTC)
- Boulder, CO (USA)
- February 13-14, 2008

**AeroDyn Theory and Structure —  **
**Detailed Description of Problems, Proposed Enhancements, and Discussion**

## AeroDyn Coordinate Systems

| Existing | Proposed |
| --- | --- |
| Different conventions between structural codes and AeroDyn:
Nacelle yaw angle (+ about –zi)
Wind direction (+ about –zi) | Define + wind and yaw angles about   +zi |
| “Ground” coordinate system located along undeflected tower centerline at HH
Becomes reference location for:
Wind input
Turbine motions | Locate “ground” along undeflected tower centerline at ground level [onshore] or MSL [offshore]:
“FF wind files” relative to this system (& independent of turbine)
Add reference height input for “HH wind files” (and independent of HH)  |
| Structural codes must compute wind and node velocities relative to the element | Structural codes will send node / element position, orientation, and velocity in ground system
AeroDyn will do the rest |

## AeroDyn Coordinate Systems (cont)

- Discussion points:
- Is it problematic that the proposed wind direction convention is opposite to that of a meteorologist’s convention?
- i.e., counterclockwise from above
- Change name of “HH wind files” to “uniform wind files”?

## Binary Wind Files

- Existing approach:
- BLADED-style files store wind data as normalized 16-bit integers
- Data is scaled by turbulence intensity and hub-height wind speed
- Binary files require data from the summary files for scaling information
- Existing problems:
- Current scaling loses more precision than necessary
- The scaling parameters must be modified for low TI or high shear
- Summary (.sum) and binary (.wnd) files must be stored together
- AeroDyn wastes time checking that the summary file and binary file are compatible

## Binary Wind Files (cont)

- Proposed modification:
- Create a new binary file format that contains all scaling parameters in one file
- Scale data by the range of wind speeds in the file to achieve maximum precision in 16-bit integers
- Discussion points:
- Should we store other information in the binary files, too?  What?
- Do we need turbulence information for points on the tower below the grid?  Is the “lollipop” shape sufficient?

## AeroDyn Wind Output

- Existing approach & problems:
- The wind can be output at two locations:
- The hub-height undeflected tower centerline
- The outboard element on blade 1 (includes shear and tower shadow, but not induced velocity)
- Proposed modification:
- Output wind vector at blade element locations
- Output coherent TKE at blade element locations

## AeroDyn Wind Output (cont)

- Discussion points:
- Do other wind characteristics need to be output?
- Averaged wind speed over the blade elements
- Disk-averaged wind speed
- Instantaneous shear
- Do we want to output wind at points other than at blade elements?
- Tower elements
- Nacelle anemometer
- Fixed locations in space
- Should wind output include induced velocities, relative motions, or only the undisturbed wind field?

## Rotational Augmentation

- Existing approach:
- External to AeroDyn – AirfoilPrep
- Du and Selig (1998)
- Eggers and Chaney (2004) for drag
- Existing problem — Model depends on rotor speed and radial position
- Proposed modification — Include in AeroDyn
- Discussion points:
- Stability of algorithm?
- Include other models (e.g. Snel and Houwink (1993))
- Coupling with dynamic stall and induction calculations

## Interpolation of Airfoil Data

- Existing approach:
- Users specify airfoils at each analysis node.
- AeroDyn interpolates only between Reynolds Numbers
- Existing problems:
- Manually interpolating airfoil tables using AirfoilPrep is tedious and prone to error
- Proposed modifications:
- Users specify airfoil data only at “pure” airfoil sections
- Let AeroDyn interpolate between input stations.
- Option to output interpolated data to verify reasonableness
- Discussion points:
- Interpolation doesn’t always work well and should require verification
- Better to create a MatLab batch script instead of doing inside AeroDyn?

## BEM Solution Iteration

- Existing approach:
- AeroDyn starts first iteration assuming a=0
- Iteration finds solution nearest a=0
- Subsequent iterations initialize with values from previous solution
- Existing problems:
- Although BEM theory assumes induction is constant across rotor, current code can have discontinuities along blade
- BEM can have multiple valid solutions to equations.  Which is correct?
- Local minima/maxima can prevent convergence
- Need robust iteration algorithm
- Speed may be a problem for a robust solution

## BEM Solution Iteration (cont)

- Proposed modifications:
- Improve performance of WT_Perf’s in-development algorithm and use it with AeroDyn
- Test for large variations in induction and seek alternate solutions closest to average
- Discussion points:
- Does quality of airfoil data justify inclusion of tangential induction
- Should we abandon BEM and use GDW exclusively?
- GDW can be slow when enough modes are used to show tip losses

## BEM Solution Iteration (cont)

## Influence of Drag on Induction

- Existing approach:
- Undocumented option adds drag term to axial and/or tangential induction equations
- Default is to not use drag in either equation
- Documented option in WT_Perf
- Existing problem:
- Some people may want to include drag in one or both equations
- Proposed modifications:
- Will be standard option in new AeroDyn
- Discussion points:
- No consensus on inclusion of drag terms in induction calculation

## Hub and Tip Loss Models

- Existing approach:
- Prandtl/Glauert (1935)
- Also Xu and Sankar (2002)
- Existing problem — Better models may exist, particularly for tips with lift (cambered airfoils and non-zero pitch).
- Proposed modification — Include model of Shen et al. (2005). Remove Xu and Sankar.
- Discussion points:
- Shen model shows only slight improvement and is better at higher TSR’s (>~10)
- Xu and Sankar was tuned to NREL Phase VI but may not be widely applicable
- Include Goldstein model (1929) or others?
- More computationally expensive
- Prandtl/Glauert less accurate for two blades and high TSR
- Bladed “F*(1-a*F)” instead of “F*(1-a)”?

## Coned Rotor Corrections

- Existing approach:
- Coned rotors assumed to be small perturbations of planar rotors
- Existing problem — Mikkelson (2001) and Crawford (2006) found BEM inaccurate when coning was large
- Proposed modification — Include model modifications from Mikkelsen and Crawford in BEM
- Discussion points:
- Highly flexible structures blades will approximate large coned rotors
- How will these additions interact with skewed wake corrections?
- What about GDW?

## Initialization of GDW

- Existing approach:
- Released AeroDyn uses BEM (Equilibrium Wake) for first second to initialize GDW
- Existing problem:
- BEM and GDW do not necessarily produce same answers
- BEM can cause controller to reach wrong equilibrium in one second
- Alpha version uses BEM solution for just one time step, resulting in smoother simulation start
- Proposed modifications:
- Use the alpha method
- Discussion points:
- Can we use the closed-form BEM solution for initialization?

## GDW Flow States

- Existing approach:
- Method of Pitt and Peters
- Existing problem — Only 10 flow states (rotational and azimuthal) modeled. Not enough to resolve tip losses
- Proposed modification — Add user defined number of flow states (Peters and He) (Alpha)
- Discussion points:
- 33 flow states need to resolve tips loss
- What about hub loss?
- What about tangential induction?
- Coned rotors?

## GDW Stability — Turbulent Wake State

- Existing approach:
- Method of Pitt and Peters
- Existing problem — Method does not include correction for vortex ring state – high TSR’s
- Proposed modification — Include turbulent wake state correction (Alpha)
- Discussion points:
- Stability in and out of wake state?

## GDW Stability — Inflow Velocity

- Existing approach:
- 10 minute mean wind speed is used as incoming velocity for GDW iteration
- Existing problem — Method neglects large changes in velocity during 10-minute period
- Proposed modification — Include a filtered velocity input based on work of Peters and He (Alpha).
- Discussion points:
- Stability?
- What is the correct filter constant – same as helicopters?

## ONERA Model

- Extended ONERA model (Pitot, 1989):
- Model formulated in terms of differential equations.  The equations account for unsteady effects (viscous, inertial, time-lag).
- Time-varying lift is given by

## ONERA Model (cont)

- Time-varying drag is given by
- Equations reproduce small-amplitude oscillations of an airfoil in linear and stalled regions.
- Allow modeling of large-amplitude oscillations through additional empirical parameters (which model classical time delays).
- Because the model is in the state-space form, it can be readily integrated with a dynamics code.  It can also be easily linearized to aid stability & controls.

## Gaussian Quadrature(for Airloads Integration)

- Existing approach:
- Aerodynamic points (points at which AeroDyn picks up blade motion and computes loads) coincide with structural points.
- Vector force summation used to compute shears and moments.
- Existing problem:
- Blade segments over which aerodynamic forces vary rapidly may not overlap segments over which structural properties vary rapidly.
- Not the most accurate integration approach.

## Gaussian Quadrature (cont)

- Proposed modifications:
- Provide for selection of blade aero segments independent of the structural segments.
- Specify *n* Gaussian points on each segment (*n* is user-selectable).
- Use Gaussian quadrature to compute integrals required for shear and moment calculations.
- Discussion points:
- Gaussian integration most accurate for a given number of points (if *n* is the number of Gaussian points, a function of ‘*2n-1’* degree is exactly integrated).
- Should we limit *n* to a specific value, say *6*, and store corresponding values of Gaussian point locations and weights?Or, should we let user define any *n* and write a routine to compute Gaussian point locations and weights?

## Time Integration Issues

- Variable-step integrator desirable for efficiency and accuracy. Most integrators also use back stepping.
- This back-stepping is distinct from the past time steps required in computation of the Duhamel integrals in the Beddoes-Leishman Model.
- The clash of the two steps must be avoided.
- GDW requires rotor thrust and moments to compute induced inflow distribution. These loads depend algebraically on the rotor states. Leads to DAEs. Numerical drift and stability problems can arise unless special integrators are used.

## Aerodynamic Model Interaction

- Existing approach:
- Induction, skewed wake (BEM), rotational augmentation and dynamic stall all separately calculated
- Existing problem — Does this accurately capture the coupling of all these affects?
- Proposed modification — Couple models all in single iteration loop
- Discussion points:
- Stability?
- Difference of time scales – e.g. dynamic stall vs. wake

## Impact of Turbine Motions & Turbulence on Wake

- Existing approach:
- Induced velocities calculated using:
- Induced velocities = [ ( mean wind ) + ( turbulent fluctuations ) ] 			     × ( induction coefficients )
- AoA & local dynamic pressure calculated using:
- Relative wind = ( mean wind ) + ( turbulent fluctuations ) 			            – ( induced velocities ) – ( blade node velocities )
- Existing problems:
- Turbine motions are treated differently than turbulent fluctuations:
- Turbine motions are assumed to be of high frequency (i.e., V ÷ R << f)
- Turbulent fluctuations are assumed to be of low freq. (i.e., V ÷ R >> f)
- Low frequency turbine motions possible with soft structures, especially in floating platforms:
- Damping will be under predicted
- High frequency turbulent fluctuations probable

## Impact of Turbine Motions & Turbulence on Wake (cont)

- Proposed modifications:
- For turbine motions:
- Have the structural codes send partial velocities instead of absolute velocities (i.e., send AeroDyn the blade node velocities as separate components for platform, tower, & blade DOFs, etc.)
- User-defined choice of which partial velocities are high & low frequency
- For turbulent fluctuations:
- Store low & high frequency components separately
- User-defined dividing frequency
- High frequencies will not effect wake, low frequencies will
- Discussion points:
- Can we instead pass the turbine motions and turbulent fluctuations through a filter?
- Is there a suitable model for the effect of mid-range frequencies on the wake?
- What about HH wind files?

## Rotor Motion Effects

- Existing approach:
- Influence of hub velocity due only to yaw motion in skewed wake and GDW
- Existing problem — Hub velocity is independent of hub pitching and other motions
- Proposed modification — Add all hub motions to relative velocities
- Discussion points:

## Non-Rotor Aerodynamic Loads

- Existing approach:
- Tower influences downwind rotor
- Simple wake deficit
- Tower, nacelle, and hub aerodynamic loads are not computed
- Other influences not computed
- Existing problem:
- Tower, nacelle, and hub loads are required by standards
- Need nacelle, hub, and upwind tower influence

## Non-Rotor Aerodynamic Loads (cont)

- Proposed modifications:
- Add aerodynamic loads to tower, nacelle, and hub (noninduced airfoil table lookup)
- Add new tower effects on rotor (Bak potential flow)
- Add hub/nacelle influence on flow
- Discussion points:
- Can be unstable very near tower – have reality checker
- Should we worry about aerodynamic loads on offshore platforms?
- What model should we use for hub/nacelle influence on the flow?
- Other models?

## Wake Tracking

- Existing approach:
- None
- Existing problem — No way to examine near or far wake velocities – may be important for nacelle, tail fin or anemometer modeling
- Proposed modification — Include near wake model (Madsen 2004), wake meander and far wake model
- Discussion points:
- Just use free or prescribed wake method instead?

## Tail Fin Aerodynamics

- Existing approach:
- Tail fin loads = ( local dynamic pressure )						      × ( airfoil data coefficients—Cl, Cd, Cp—at local AoA)		      × ( tail fin planform area )
- Relative wind = ( unobstructed wind velocity at tail fin CP )				        – ( body velocity of tail fin CP )					        – ( rotor-averaged axial induced velocity )  optional
- Existing problem — Rotor-averaged axial induction is subtracted regardless of the position of the tail fin
- Proposed modification — Nothing thought of yet
- Discussion points:
- Is it possible to determine whether the fin is in the wake of the rotor?
- Can the calculation be improved by tracking the wake?

## Apparent Aerodynamic Mass Effects

- Existing approach:
- The apparent or virtual aero forces, associated with non-circulatory inertia terms, are ‘probably’ ignored.
- Existing problem:
- Aero loads may be estimated somewhat wrongly.
- Torsion damping ignored.
- Proposed modification:
- Include non-circulatory terms.
- Discussion points:
- Two ways to implement: a) structural code pass accelerations to AeroDyn, which in turn passes back apparent forces, b) get apparent mass matrix directly from AeroDyn? Feasibility of each scheme?
- Mass matrix symmetry lost.

## Considerations for Water Turbines

- Water turbines ≠ wind turbines with 1000× the fluid density
- Additional considerations for water turbines:
- Wave kinematics
- Unique turbulence models for sea current, tidal flow, and rivers
- Diffraction loading (from incident flow):
- Inertia loading from decelerating flow
- Radiation loading (from turbine motions  outgoing flow):
- Added mass
- Damping
- Buoyancy loading
- Blockage due to seabed and free surface
- Potential for cavitation
- Any thoughts on the best approach?

## Linearization of Wake and Dynamic-Stall (DS) Models

- Existing approach and problems:
- Linearization of the structural models not available with frozen or GDW (it is only available with nonfrozen BEM)
- Linearization of the structural models not available with DS (it is only available with static airfoil data)
- These are potentially important models to include in linear state-space-based controls design & stability analyses

## Linearization of Wake and Dynamic-Stall Models (cont)

- Proposed modifications:
- Have structural codes send AeroDyn a run-time switch indicating whether the calculations are for time-domain or linearization analyses
- Add options for frozen BEM & GDW in linearization analyses
- Add option for (nonfrozen) GDW in linearization analyses
- Add linearized Beddoes-Leishman (B-L) DS model:
- Use the model by: “Hansen, M.H., Gaunaa, M., Aagaard Madsen, H., *A Beddoes-Leishman type dynamic stall model in state-space and indicial formulations*, Risø-R-1354(EN), Denmark: Risø National Laboratory, 2004.”
- Make available in both time-domain & linearization analyses
- Augment structural states in linearized models with states for (nonfrozen) GDW & DS

## Linearization of Wake and Dynamic-Stall Models (cont)

- Discussion points:
- Are the assumptions in Hansen’s (et al) linearized B-L DS model appropriate?
- Are there other suitable linearized DS models?
- Should the number of DS states be limited while linearizing by applying DS only to user-defined (most likely outboard) blade elements?
- How does the Multi-Blade Coordinate (MBC) transformation interact with the states for GDW & DS?