NREL PPT template light blue background

1
AeroDyn Interface with Structural Codes
Detailed Description of Problems, Proposed
Enhancements, and Discussion
AeroDyn Overhaul Kick-Off Meeting National Wind
Technology Center (NWTC) Boulder, CO
(USA) February 13-14, 2008
2
Interface Scenario 1
STR DYN
AeroDyn
Main
B-L Model
Xations
GDW
. . .
Free Wake
WIND
3
Notes on Scenario 1

• Information to B-L model may be passed as arrays.
  Each element in the array refers to a particular
  blade section.
• Wake models may require additional information
  (rotor disc orientation and motion) depending on
  the sophistication required.
• Minimize reliance on modules.

4
Interface Scenario 2
AeroDyn
B-L Model
Aero-StructureInterface
STR DYN
GDW
. . .
Free Wake
WIND
5
Interface Scenario 3
AeroDyn
B-L Model
S-A for B-L
STR DYN
GDW
S-A for GDW
. . .
Free Wake
S-A for FW
WIND
6
A Hybrid Scenario
STR DYN
AeroDyn
Main
B-L Model
Xations
GDW
. . .
Detailed Interface
Advanced Aero Model
WIND
7
Modularization of AeroDyn

• Existing approach AeroDyns internal modules
  are tightly intertwined
• Existing problem The intertwining makes it
  difficult to add new modules to, maintain, and
  even understand AeroDyn
• Proposed modifications Modularize the code
• Clearly separate the submodels
• Inflow models
• Rotational augmentation models
• Wake models (BEM, GDW, vortex wake, etc.)
• Model corrections (tip and hub losses, skewed
  wake)
• Dynamic stall models
• Tie together submodels with wrapper routines
• Switch between submodels using SELECT CASE
  statements
• Add input parameters to select between the
  submodels
• Develop hooks for new submodels
• Discussion points None?

8
Development of a Standardized Interface

• Existing approach
• AeroDyn is tightly coupled with the structural
  codes
• AeroDyn performs some calculations differently
  depending on the structural code
• Existing problems
• Tight coupling makes it difficult to use AeroDyn
  with other structural codes
• AeroDyn is difficult to enhance, maintain, and
  even understand
• Proposed modifications
• Eliminate the tight coupling between AeroDyn and
  the structural codes
• Develop the interface such that AeroDyn does not
  know, nor care, which structural code is calling
  it
• Develop international standard interface between
  AeroDyn and structural codes

9
Development of a Standardized Interface (cont)

• Discussion points
• Who in international community would cooperate in
  development of a standard interface?
• What should be standardized?
• Interface format?
• Inputs?
• Outputs?

10
Passing Data Back and Forth
11
Passing Data Back and Forth (cont)
12
Passing Data Back and Forth (cont)

• Discussion points
• Should we have AeroDyn return the loads for each
  analysis node individually, by calling AeroDyn
  for each node separately
• All structural data would only be passed on the
  call of the first node
• This would only require AeroDyn to store all
  nodal loads
• How should data be shared? Through arguments or
  through modules?
• Should, and how can, the structural and
  aerodynamic EoM be coupled?

13
Static or Dynamic Library
14
Static or Dynamic Library (cont)

• Proposed modification
• Implement AeroDyn as a DLL
• Have input parameters in the structural code for
• The path to the AeroDyn DLL
• The AeroDyn input file name
• Discussion points
• Will it be more difficult to port AeroDyn to
  non-Windows platforms?
• If so, is this a problem?
• Is it beneficial to make each submodel a separate
  library (DLL) that can be developed and
  maintained independently?
• Inflow libraries (single-point, full-field)
• Induction libraries (BEM, GDW, vortex wake, etc.)
• Dynamic stall libraries
• Airfoil table lookup libraries
• This will require some standardization of
  submodel interfaces
• Is this level of modularization practical?
  Possible?

15
NWTC Subroutine Library

• Existing approach
• AeroDyn, and programs that use it, each have
  their own set of general-purpose routines
• Existing problem
• Conflicts between AeroDyn routines and
  structural-code routines have caused problems
• Maintenance costs higher

16
NWTC Subroutine Library (cont)

• Proposed modifications
• Use the NWTC Library of Fortran subroutines and
  data modules
• I/O, Math, Aerodynamic, and Compiler-specific
  routines
• Used by many other NWTC codes
• Reduces development and maintenance time
• Discussion points
• Any reason why not?

17
Stand-Alone Aeroacoustics Module

• Existing approach
• Integrated with FAST and AeroDyn
• Existing problem Cannot be used with other
  dynamics codes
• Proposed modification Create stand alone
  aeroacoustics module (DLL) that will interface
  with a range of dynamics codes and AeroDyn
• Discussion points
• Aeroacoustics assumed not to affect fluid
  dynamics one way module fine
• Need blade position and orientation as well as
  aerodynamics
• Future integration with CFD for boundary layer
  properties

18
Stand-Alone Aeroacoustics Module (cont)

• Needed Inputs from AeroDyn/Structures Code
• Chord
• Angle of attack
• Total velocity at airfoil
• Turbulence intensity at airfoil
• Airfoil position relative to observer
• Absolute position
• Angle of chordline
• Xfoil/Rfoil
• Airfoil name (NACA)
• Airfoil Coordinates
• CFD
• Boundary layer thickness at tailing edge
• Coefficient of friction at trailing edge

19
Input-File Format

• Existing approach
• Uses a style different from other NWTC codes
• Existing problem
• Many options use strings instead of true/false or
  integers
• Not broken into logical sections
• Many constants are hard-coded
• Proposed modifications
• Divided into meaningful sections
• Many hard-coded terms added to input file
• All options are true/false or numbers for
  multi-way switches
• Example
• Discussion points
• Would an optional research input file be more
  appropriate?

20
AeroDyn Output Files

• Existing approach
• Currently, AeroDyn can generate three types of
  output files
• Blade-element data
• Vx, Vx, Vz, Alpha, Qbar, CL, CD, CN, CT, CM,
  Pitch, AxInd, TanInd, ForceN, ForceT, Pmom, Re
• Can specify which nodes are written
• Options file
• Warning/error log
• Existing problem
• No option to disable options file or error log
• Options file works differently than FASTs echo
  file
• Other outputs needed (e.g., nacelle anemometer)
• No option to specify what outputs are desired

21
AeroDyn Output Files (cont)

• Proposed modifications
• Return all AeroDyn outputs to structural codes
  structural code will specify which to output
• Add additional outputs such as lift, drag, and
  relative velocity
• Return wind speeds other than at tower centerline
  at hub height
• Add AeroDyn input to FASTs echo file create own
  echo file for other codes
• Pass warnings/errors to structural codes for
  handling
• Discussion points
• Should AeroDyn have option to write blade-element
  data in blocks as WT_Perf does?
• Will specifying blade-element data for each
  parameter and node in FAST input file be too
  onerous?

22
Other?