Dear all,
I’ve been working on a project designing wind turbine blades using an in-house simulation software, and have been running my designs through openFAST for validation. I’m running into a strange issue resulting in a mismatch in blade edgewise displacement between the two codes - and while I appreciate the results from the in-house software won’t be possible for people to recreate, I’m hoping to get some suggestions on the underlying causes to my errors.
Despite outputting very similar aerodynamic forces and modal frequencies, and having identical cross-sectional properties, I’m unable to get a match in steady-state in-plane deflection. To use a familiar reference point I’ll illustrate the error using the NREL 5MW rotor rather than any of my designs. The attached images show results comparisons from the NREL 5MW RWT in a uniform windfield of 12m/s with fixed pitch and RPM. The first showsime-averaged deflection as a function of spanwise location on the left, and the time series for the tip node on the right. The second shows the time-averaged in-plane and out of plane forces and aerodynamic coefficients.
I’ve taken the following lines of investigation to try and pinpoint my issue, and in all cases the discrepancy remained:
- Looking at the in-plane displacement with no rotor movement to observe deflection under self-weight
- Removing edgewise damping from the openFAST input files, testing if it was hindering the in-plane deflection in any way
- Fixing my pitch-axis input as per this forum post
- Comparing modal frequencies and mode shapes using ACDC as recommended in this forum post
- Tinkering with the aerodyn settings - strangely turning off the “UseBlCm” is what gives me this very close match in flapwise displacement. As a result I looked into the airfoil data files I was using and they were identical in moment coefficient for both programs.
I would greatly appreciate any pointers or suggestions as to what could be causing such an issue under my specific circumstances, and I’m happy to share any further details that would be useful in narrowing down the problem.
Best wishes,
Abdirahman
Dear @Abdi.SheikHassan,
To debug what seems to be a difference in the structural beam formulation, I would suggest isolating the blade statics and dynamics, so, the first bullet in your list of investigations is what I would focus one; perhaps bullet four as well. What was the result of this test (or these tests) without aerodynamic loads? Have you tried comparing the blade deflections with known applied point loads? (In OpenFAST, you can apply point loads on the blade through the Structural Control (StC) submodel of ServoDyn.)
Also, which beam model in OpenFAST are you using: ElastoDyn or BeamDyn? Perhaps try comparing to both?
If you have concerns with the aerodynamic applied loads, I would first suggest comparing these loads in the absence of blade deflection (you model a rigid rotor in OpenFAST by disabling BeamDyn, as well as the blade degrees of freedom in ElastoDyn).
Best regards,
Dear @Jason.Jonkman,
I’m using ElastoDyn + BeamDyn, the aerodynamic forces match well in both rigid and elastic simulations, and the moment issue was symptomatic of a difference in pitching moment formulation between the codes which I’ve now fixed.
I’m trying to reproduce the runs without aerodynamic forces - but when I run openFAST with CompAero or CompInflow set to 0 I get no deflections. How should I go about checking deflection under gravity with BeamDyn?
Best wishes,
Abdirahman
Dear @Abdi.SheikHassan,
I’m not sure I understand why you are not seeing this, but I would expect the gravity load, when enabled, to lead to structural deflections in ElastoDyn and BeamDyn in the absence of aerodynamic loading.
Best regards,
Dear @Jason.Jonkman
Thanks for the clarification, your response made me realise I was comparing blades at different azimuth angles as the only case where I would see no deflection under gravity would be in the blade pointing straight up, whereas my code has a different starting position.
Accounting for this discrepancy and correcting the pitching moments these are my deflections:
Correcting the azimuth has helped with the phase difference but the time-averaged result at the tip is still off by about 15%.
These are the deflections with CompInflow and CompAero off, and similarly no aerodynamic forces in the code I’m comparing:
Another point that may be of interest is that my pitching moments match very well in rigid simulations but when I enable elasticity they start to show differences partway through the blade despite the moment coefficients matching well:
Thanks again for the tips,
Abdirahman
Dear @Abdi.SheikHassan,
I can’t really comment on why OpenFAST may differ from your ATOM code, but I’m not sure I understand why OpenFAST is showing no variation in deflection with time for the case without aerodynamics. Is the rotor spinning with gravity enabled in OpenFAST?
Best retgards,
Dear @Jason.Jonkman,
To make the comparison I had set RPM to zero in openFAST and a low number in ATOM since I couldn’t turn off BEM entirely.
The remaining issues turned out to be various smaller corrections with regards to co-ordinate systems and airfoil data, and my programs now have a decent match 
The means by which I got this match does raise some questions though - ATOM calculates pitching moments by denormalising the moment coefficients calculated through BEM, and then adding the moment from the aerodynamic forces using the distance between the pitch axis and aerodynamic centre as the moment arm. Removing this additional moment gave me the match I described in this post, which implies the moment arm I’m using in ATOM is defined as zero in openFAST (i.e. pitch axis and AC coincide). Is this the case? And if so, which input variables can I adjust to offset the aerodynamic centre?
Best wishes,
Abdirahman
Dear @Abdi.SheikHassan,
When AeroDyn is coupled to ElastoDyn or BeamDyn in OpenFAST, the total aerodynamic pitching moment would be the same as you describe:
denormalising the moment coefficients calculated through BEM, and then adding the moment from the aerodynamic forces using the distance between the pitch axis and aerodynamic centre as the moment arm
The offset between the aerodynamic center and the pitch axis is defined in the AeroDyn blade input file via inputs BlCrvAC and BlSwpAC.
Best regards,
1 Like
Dear @Jason.Jonkman,
Is this specifically for when AeroDyn is coupled with ElastoDyn/BeamDyn, or is it also the case for rigid sims using AeroDyn?
Also strangely enough, when I change the variables you mention, I don’t observe any meaningful difference in the output pitching moment compared to the values I get with zero offset. Is there some sort of option I’m missing?
Best wishes,
Abdirahman
Dear @Abdi.SheikHassan,
AeroDyn blade input file inputs BlCrvAC and BlSwpAC define the offset between the aerodynamic center and the pitch axis regardless of whether AeroDyn is coupled to ElastoDyn or BeamDyn through OpenFAST or when AeroDyn is called by its standalone driver code.
If you are not seeing an effect from these inputs, can you clarify your simulation set up, the results you are obtaining, and why you think they are incorrect?
Best regards,
Dear @Jason.Jonkman,
Thanks for the prompt response. I was testing the effect of these parameters on the NREL 5MW blade using CompElast = 1 and all DOFs turned off. I first set SwpAC and CrvAC as zero, and removed the additional moment term from ATOM, and got matching pitching moments. I then set SwpAC to an arbitrary value (-1m all the way along the span) and got the same match, which is why I had the impression you meant the offset isn’t used to calculate the pitching moment in standalone AeroDyn.
When I couple the simulation with BeamDyn, I do observe a change in my pitching moment, which I’m now working on getting to match ATOM with the additional moment term included. ATOM defines spanwise values of pitch axis and aerodynamic centre, which I’m using in reference to this post to get:
BlCrvAC = (AeroCent - PitchAxis) * Chord * SIN(AeroTwst)
BlSwpAC = (AeroCent - PitchAxis) * Chord * COS(AeroTwst)
Is this correct?
Dear @Abdi.SheikHassanm,
I guess whether your equations make sense depends on how you are defining AeroCent and PitchAxis. If you are using the variables from the following forum post: NREL 5MW Rotor Geometry - #3 by Jason.Jonkman, I would say the equations should be:
BlCrvAC = (AeroRef - PitchAxis) * Chord * SIN(AeroTwst)
BlSwpAC = (AeroRef - PitchAxis) * Chord * COS(AeroTwst)
, where AeroRef has replaced AeroCent.
Best regards,
1 Like
Dear @Jason.Jonkman,
I just wanted to pin down the implication of something you mentioned in one of your earlier replies:
When AeroDyn is coupled to ElastoDyn or BeamDyn in OpenFAST, the total aerodynamic pitching moment would be the same as you describe
As I mentioned, when arbitrarily changing the BlSwpAC/BlCrvAC in a rigid simulation, I observe no difference in the pitching moment output from the “BxNyMm” output channel. When I use the offsets from the formulae we discussed in an aeroelastic simulation, I get a nice match in aerodynamic forces and displacements, but I don’t see the expected change in pitching moment.
This implies to me that the correct moments are being calculated (including the offsets) and transferred over to BeamDyn to calculate displacements, but the output I’m requesting is still only showing me the aerodynamic pitching moments about AC and therefore without the offset. Any clarification would be appreciated.
To illustrate my point, here are the pitching moments and coefficients when the offset term is removed from ATOM and BlCrv/SwpAC are all zero in OpenFAST:
And with the term included in both:
Best wishes,
Abdirahman
Dear @Abdi.SheikHassan,
Can you clarify this?:
As I mentioned, when arbitrarily changing the BlSwpAC/BlCrvAC in a rigid simulation, I observe no difference in the pitching moment output from the “BxNyMm” output channel. When I use the offsets from the formulae we discussed in an aeroelastic simulation, I get a nice match in aerodynamic forces and displacements, but I don’t see the expected change in pitching moment.
By “rigid simulation”, are you referring to running AeroDyn standalone through the AeroDyn driver? What output channels are you referring to specifically?
I’m not familiar with how ATOM is interfaced to AeroDyn, but does this interface include the spatial mesh-to-mesh libraries available within OpenFAST, which OpenFAST uses when interfacing AeroDyn to BeamDyn or ElastoDyn?
Best regards,
Dear @Jason.Jonkman,
In this case rigid simulation refers to running openFAST through the openFAST driver, with CompElast set to 1 and all DOFs turned off in ElastoDyn. In the “aeroelastic” case I have CompElast set to 2 and the 1st/2nd Flapwise and 1st Edgewise DOFs turned on in ElastoDyn. Both the images provided are from the latter case.
There isn’t any interfacing between the programs, I use the data from ATOM to generate a set of input files for OpenFAST which I then run to compare the outputs. In this case I’m comparing the pitching moment per unit length which I request in the AeroDyn input file as B1N1Mm, B1N2Mm etc for all my nodes.
Best wishes,
Abdirahman
Dear @Abdi.SheikHassan,
Thanks for clarifying. But if ATOM is generating an OpenFAST model, what is the difference between “ATOM” and “FAST” in your plots?
The AeroDyn output BαNβMm is the pitching moment relative to the aerodynamic center associated purely with Cm. If you output the total integrated aerodynamic load on a blade, AeroDyn output BαAeroMz for the pitching moment, then you’ll get the integration of the pitching moment plus the effect of the aerodynamic offsets.
Best regards,
1 Like
Dear @Jason.Jonkman,
The ATOM results are those generated by the ATOM code, and the “FAST” results are those extracted from OpenFAST which was run on models generated by some code I wrote to transfer between the ATOM and OpenFAST formats. The purpose of this validation exercise is to ensure the physics is the same between softwares, and that my conversion code is working correctly by generating an identical blade for OpenFAST.
Perfect, thanks for the clarification. I’m now using your suggested output to make my comparison and have isolated a discrepancy that is causing a difference in torsional deflection between the programs. In the attached plot, the ATOM data shows the total integrated aerodynamic pitching moment in the blade co-ordinate system - this doesn’t include gravitational/centripetal forces so I compared it against BαAeroMz from openFAST with gravity set to zero.
Still unsure about what’s behind this constant offset I’m seeing - could you tell me a bit more about how the BαAeroMz term is calculated? My forces and AC offset match so I can only conclude that our moments are calculated differently.
Best wishes,
Abdirahman
Dear @Abdi.SheikHassan,
BαAeroMz is the total integrated aerodynamic pitching moment, which is found by integrating along the blade the aerodynamic pitching moment plus the moment arm crossed with the aerodynamic forces.
Best regards,
