beamdyn coordinate

[Unique-Wang]

Dear @jjonkman ,

I've been reading this document http://forums.nrel.gov/t/simulations-using-beamdyn/2294/6 and I'm a bit confused by the point O,
,I know its the origin of the cross section (defined by the reference axis) but i don't think I fully understand this like ,if I already know the distance of 1/2*chord to the blade pitch axis in x direction and y direction , then how do I get kp_xr and kp_yr? Whats the relationship between 1/2*chord and point O? I'd appreciate it if you could help me with this!

Best regards,

[jjonkman]

Dear @Unique-Wang,

The reference axis specified in BeamDyn is user defined. It should generally follow the geometry of the blade (with precurve, presweep), but it need not be located at half chord. Some users prefer specifying the reference axis as the loci of shear center, tension center, or mass center, but the reference axis need not be any of these explicitly.

Best regards,

[Unique-Wang]

Thank you ! It seems that this bug is already fixed in the latest version of OpenFAST, because the same error doesn't occur anymore when I use version3.1.

Best regards,

[Unique-Wang]

And I encountered this error,
, in #1007 you said this is because of the incompatibility in #1007, but I'm really confused by 'Closest distance is 5.81670E-02 m'

Best regards,

[jjonkman]

Dear @Unique-Wang,

These errors are notifying you of an incompatibility between the AeroDyn and BeamDyn meshes. 5.81670E-02 m is the size of the mismatch. All AeroDyn nodes must be able to project orthogonally onto the Line2 elements of the BeamDyn mesh. See how the Line2-to-Line2 mesh mapping search is described in our AIAA SciTech 2014 paper: https://www.nrel.gov/docs/fy14osti/60742.pdf.

Best regards,

[Unique-Wang]

Thanks a lot!
And one more thing that I've been confused so long is solution doesn't converge, I know it has something to do with DT, and I set DT ten(or even over ten) times smaller(0.0005s) than before(0.005s) to make the solution converge, but this slows down the calculation so much.I don't know if it's appropriate to ask but, is 0.0005s normal?

Best regards,

[jjonkman]

Dear @Unique-Wang,

We are aware that BeamDyn requires smaller time steps than would generally be desired. We have plans to address this issue by introducing a tight coupling algorithm between BeamDyn and ElastoDyn (and between ElastoDyn and SubDyn). Until then, the time step is likely driven by high natural frequencies in your BeamDyn model that are being propagated into the ElastoDyn model through the structure-to-structure coupling.

Are the stiffness and mass properties you've specified in your BeamDyn model physically realistic? If the mass is artificially low or the stiffness is artificially high, then unphysically high frequencies could be introduced, requiring small time steps, which could be increased by introducing physically accurate mass and stiffness values. Reducing the order of the finite element in BeamDyn may also allow you to use larger time steps.

Best regards,

[Unique-Wang]

Dear @jjonkman ,

I recently found that when I use beamdyn for blades, the simulation results of my model basically match my Bladed model results at low wind speed(such as 6.5m/s), but there would always be severe fluctuations of rotor speed and generator power, and then the controller would shut the model down if I use a relatively higher wind speed (such as 12.5m/s and 15m/s) . But this would not happen if I use elastodyn for blades.

What could be the reason you think?

Best regards,

[jjonkman]

Dear @Unique-Wang,

I would guess that your BeamDyn model is capturing blade flexural modes that are not accounted for in your ElastoDyn model, such as torsion, or higher flapwise and bending modes, and that these modes are interacting with the controller behavior. It could also mean that your BeamDyn model has unstable modes at the higher wind speeds.

Best regards,