Methodology Discussion: Modeling Floating Multi-VAWTs using AeroDyn and "Rigid Dummy Blades" for Load Transfer

[gxyanwork-byte]

Hello,

1. Research Background
   I am currently working on a fully coupled aero-hydro-servo-elastic simulation of a "Multi-Rotor H-type Vertical Axis Wind Turbine (VAWT) + Semi-submersible Platform" system using OpenFAST, coupled with the OLAF free-vortex wake module.

2. The Challenge
   OpenFAST's structural module (ElastoDyn) is natively built on a Horizontal Axis Wind Turbine (HAWT) framework. If one attempts to force the actual VAWT structural geometry into ElastoDyn, its underlying logic—which assumes blades radiate outward radially from the hub—not only causes severe 3D rendering distortions (making it look like a "ceiling fan" or an "umbrella") but also frequently triggers mesh mapping errors and numerical divergence.

3. My Proposed Solution (Aerodynamic Equivalent Load Transfer)
   To bypass the structural modeling limitations while maintaining full aero-hydro-servo-elastic coupling for the floating platform, I have devised the following "equivalent load transfer" framework:

Aerodynamic Calculation (AeroDyn + OLAF): Input the true H-type VAWT geometric parameters (AD_blade.dat), and utilize the OLAF module to accurately compute lift, drag, and wake interactions at the spatial aerodynamic nodes.

Structural Setup (ElastoDyn): Pitch the shaft vertically (ShftTilt = 90) and disable all blade deformation DOFs (FlapDOF/EdgeDOF = False). Simultaneously, I introduce a "dummy blade" into the system—with its mass density set to a negligible value (e.g., 0.001) and stiffness set to an extremely high value.

Equivalent Transfer Mechanism: The transient aerodynamic loads calculated by AeroDyn are mapped onto this massless, non-deformable rigid "dummy blade". These loads are then transferred 100% losslessly to the Hub -> Nacelle -> Tower, ultimately driving the 6-DOF motion of the bottom floating platform.

Could anyone provide some guidance or feedback on the feasibility of this approach? Are there any hidden pitfalls, or are there better alternative methods within OpenFAST to solve this VAWT modeling issue?

Thank you in advance for your time and insights!

[jjonkman]

Dear @gxyanwork-byte,

That is a creative OpenFAST set-up! I see what you are trying to do, but can you clarify what you mean by "dummy blade" and how you are introducing it in OpenFAST?

FYI: To get around the configuration limitations of ElastoDyn and to enable the aero-hydro-servo-elastic modeling of floating VAWTs, we previously coupled OpenFAST modules with the OWENS structural solver from Sandia National Laboratory, as explained in the following paper: https://www.mdpi.com/1996-1073/16/5/2462. However, SNL has recently stopped development of OWENS.

As an alternative, we are now working on the coupling between OpenFAST modules and Project Chrono, which will support the aero-hydro-servo-elastic modeling of floating VAWTs. We expect to release this capability later this year.

Best regards,

[gxyanwork-byte]

Dear jjonkman,
Thank you so much for your reply and the highly encouraging feedback!The upcoming integration of OpenFAST with Project Chrono is absolutely thrilling news for the floating VAWT community. I will definitely keep a close eye on that release later this year. Thank you also for sharing the OWENS paper; it provides great context on how this coupling was handled previously.To clarify my "dummy blade" approach: since the OpenFAST glue code requires structural line elements (in ElastoDyn) to map the aerodynamic loads (from AeroDyn) onto, I essentially created a set of massless, infinitely stiff "phantom" blades to act purely as a load-transfer mechanism.Here is exactly how I introduced it in the OpenFAST setup:

1. ElastoDyn Main File Adjustments:To orient the rotational plane horizontally and prevent ElastoDyn from calculating inappropriate HAWT beam kinematics, I set:ShftTilt = 90.0,PreCone(1-3) = 0.0,OverHang = 0.0,FlapDOF1, FlapDOF2, EdgeDOF = False (treating the blades as rigid bodies).TipRad = A value slightly larger than my actual VAWT radius in AeroDyn .
2. The "elastodyn' Blade" File:Instead of using a real HAWT blade file, I assigned a custom Blade.dat to BldFile(1-3). Inside this file, I neutralized the structural properties:Mass Density (BMassDen): Set to a near-zero value (e.g., $1.0 \times 10^{-4}$ kg/m) to eliminate centrifugal forces and unwanted rotor inertia.Stiffness (FlpStff, EdgStff): Set to an artificially high value (e.g., $1.0 \times 10^{12}$ Nm$^2$) to ensure absolute rigidity.Structural Twist (StrcTwst): Set to 0.0 along the entire span.
   My underlying assumption:By doing this, the aerodynamic forces ($F_x, F_y, F_z$) and moments computed accurately by AeroDyn + OLAF at the spatial H-type nodes are mapped onto these rigid, massless ED line elements. These rods then transfer the loads 100% losslessly to the Hub $\to$ Nacelle $\to$ Tower, ultimately driving the 6-DOF rigid body motion of the floating platform and capturing the platform aero-elastic damping. I understand this completely ignores the internal structural dynamics of the VAWT blades, but my primary focus right now is the platform's global response and wake interactions.
   My follow-up question for you:Before the Project Chrono capability is released, does this "rigid massless rod" workaround present any hidden mathematical pitfalls in the current OpenFAST glue code? Specifically, could the mapping from AD nodes to ED nodes in a ShftTilt = 90 configuration introduce spurious forces or gyroscopic artifacts, despite the near-zero mass of the blades?Thank you again for your time and guidance!
   Best regards

[jjonkman]

Dear @gxyanwork-byte,

Thanks for clarifying. Your approach makes sense with me if you are OK considering the VAWT rotor as rigid, for now. Presumably you've set some nonzero BMassDen somewhere along the span to have some nonzero mass and inertia of the rigid rotor (or perhaps you've lumped that fully in the hub)?

Just FYI: The FlpStff and EdgStff values and the mode shapes are not used in ElastoDyn when the blade DOFs are disabled.

Best regards,

[gxyanwork-byte]

Dear jjonkman,

Following up on our discussion, I had a quick theoretical question regarding ElastoDyn's source code.

To visually and kinematically represent an H-type VAWT, .I set:ShftTilt = 90.0,PreCone(1-3) =89.9999，would it be possible to hack the coordinate transformation matrices within the ElastoDyn Fortran source code? My thought was to modify the mesh generation logic by first applying a radial translation (e.g., an 8-meter horizontal offset to represent the rigid strut) and then applying a 90-degree vertical rotation for the blade span.

I strongly suspect this might be a dead end because ElastoDyn is based on Kane’s method derived for HAWTs. Modifying just the spatial coordinates without adding the corresponding DOFs for the struts (like strut torsion) would likely break the underlying partial differential equations (e.g., miscalculating centrifugal stiffening or load transfer paths).

Has a simple coordinate transformation modification like this ever been attempted to bypass the radial configuration, or is it fundamentally unviable due to the underlying equations of motion?

Thanks again for your time and insights!

Best regards,

[jjonkman]

Dear @gxyanwork-byte,

By setting PreCone = 90deg in ElastoDyn, all blades will collapse along the same line, as you've shown. With PreCone = 0, the blades in ElastoDyn really represent the struts of the H-VAWT.

It sounds like what you want to do is change the underlying kinematics of ElastoDyn so that the precone angle is not specified relative to an "apex of rotation", but relative to some radial offset, such as the hub radius. This would be possible with a source code change, but you'd have to be consistent across all kinematic quantities. This change would also cause the strut to be located at one end of the blade not in the blade of the blade, which is odd for an H-VAWT.

Best regards,