Bug report

[ptrbortolotti]

Bug description This is an issue that is hopefully not an issue. The fear that blades 2 and 3 in BeamDyn are not symmetric with blade 1 still circulates. I paste here some plots showing how this was clearly the case in OpenFAST v2.3.0, whereas things seem fine in v3.0.0. The simulations are run with a constant pitch of 0 deg and a constant rotor speed of 2rpm. Gravity is on, aerodynamics is off. The model is the IEA15MW from the BeamDyn branch (https://github.com/IEAWindTask37/IEA-15-240-RWT/tree/beamdyn/OpenFAST/IEA-15-240-RWT).

OpenFAST Version v2.3.0 and v3.0.0

OpenFAST-v3.0.0

• Compiler: Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Compile Info: Version 19.1.1.217 Build 20200306
• Architecture: 64 bit
• Precision: double
• OpenMP: No

If the team has special requests, I can run more cases

Thank you

[ptrbortolotti]

We might have closed this too soon...

The previous plots had AD15 turned off. When I turn it on, with the airfoil unsteady aero turned off (AFAeroMod=1), I do see some some asymmetry in the blade tip deflections, especially visible in the tip rotation channels (TipRD)

ElastoDyn has only blade DOFs turned on (I tested the tower DOFs both on and off and conclusions don't change). Blade root forces and moments show perfect symmetry.

The plots are generated from this .outb file https://github.com/ptrbortolotti/debug_BD_bladesymm/blob/master/BDaero_notwrDOFs/IEA-15-240-RWT_ws09.outb which was generated by running OF v.3.0.0 here https://github.com/ptrbortolotti/debug_BD_bladesymm/tree/master/BDaero_notwrDOFs

[andrew-platt]

I can also confirm this is still an issue with a heavily curved blade with sweep and twist (gravity on, no aero). The tip translational deflections are close, but the rotational terms are off.

[ptrbortolotti]

If I zoom in in the first plots, the asymmetries are still there indeed. I will now run a case without gravity

[ptrbortolotti]

Things seem to stay symmetric for the no gravity / no aerodynamics case (https://github.com/ptrbortolotti/debug_BD_bladesymm/tree/master/BDstruct_nograv)

@andrew-platt could you please check on your end?

[andrew-platt]

For no gravity, there is a very small difference in the blade I was looking at.

One interesting thing with both your plot and these plots is the azimuth dependent oscillation. All 3 blades are in phase with the azimuth angle. This doesn't damp out even after 1,200 seconds. This makes me a little suspicious there is an error with an internal stress term someplace (the blades all pass their respective reference frames at the rotor azimuth=0).

[ptrbortolotti]

I've just checked the blade asymmetry issue in the IEA15 RWT comparing old results with newer ones generated using the qfit=6 beamdyn model implemented in https://github.com/ptrbortolotti/openfast/blob/7ac7a03b628bcee244a97d8e2e1a93e13d3026ee/modules/beamdyn/src/BeamDyn.f90#L566

The case has gravity and aerodynamics turned on. The plot below compares blade tip rotations around the y axis.

With order element 10, the asymmetry is smaller than in the past, but it persists. It seems to disappear if I push the order element to 14

@andrew-platt @michaelasprague Any thought? Andy can you please check your case with the highly curved and present blade?

[ptrbortolotti]

The plot might not be zoomed in enough, but rotations with order element 10 are consistently off by 5e-4, whereas they are machine-precision identical with order element 14

[andrew-platt]

I checked the case I had previously run (curve + sweep + non-linear twist) using dev at f5b3baef with the qfit limit discussed in the meeting. The differences in tip displacements between blades 1, 2, and 3 are now on the order of machine precision for both 7th order and 9th order.

There is still a periodic displacement dependent on rotor azimuth for all three blades, but it significantly reduced from the above plot (5E-6 for order 7, 1E-7 for order 9 on TipTDxr).

There is also a very slight displacement of the order 9 results from the order 7 results of roughly 1E-4. This does make sense that there could be a slight shift in the result since the blade is represented by a different set of spectral elements with LSFE nodes in different locations, and will converge slightly differently.

[SimonHH]

Hi all, I am seeing the same asymmetries in the rotational states that are described in this issue. The blade, that I am calculating, has curve + sweep + non-linear twist. I am running cases with gravity, aerodynamics and static wind. I am using order_elem = 5 for the blade. The version is OpenFAST-v3.0.0. Do you expect the above mentioned bugfix (qfit limit) to also eliminate the asymmetries in my case?

[ptrbortolotti]

Hello, yes that, combined with an order_elem=10, should fix the issue. Please let us know if that is or isn't the case. Pietro

[SimonHH]

With order_elm=10 the asymmetries are reduced significant. But in the rotational states still some asymmetrie are observed. I hope to further improve this once the qfit limit is included in the next release of OpenFAST. In case I find time to compile the fix before that I will let you know my findings.

[rafmudaf]

@ptrbortolotti could you verify and document that https://github.com/OpenFAST/openfast/pull/1050 fixes this issue?

[ptrbortolotti]

I confirm that this issue is fixed