You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Modelling a large blade with BeamDyn leads to large computational times. Especially when the cross-sectional matrices are fully populated, a small time step has to be chosen for the coupling with AeroDyn, and the order of elements is relative high. In my case, a Time/CPU-ratio in the order of 10^(-3) is no exception, leading to CPU Times in the order of days.
For large blades, 9 output nodes is not enough to fully capture the detailed deformation or load distribution of the blade. It is a shame that after all that computational work, only the results at 9 nodes can be written as an output. Hence, only a small part of the computational work is than available for the user. If one needs more nodes, you will have to redo the whole computation only then with different output nodes.
Describe the solution you'd like.
Introduce an option where users can define an unlimited number of output nodes.
Describe alternatives you've considered.
Related to this feature request. The elements in BeamDyn are spanned by the basis functions. The solution BeamDyn finds is thus continuous. It would be great if the user can also define output nodes in BeamDyn that are not equal to the FE nodes or the quadrature nodes. Deformations at nodes other than the FE or quadrature nodes should be easily computed since this is just an expansion of the basis functions, weighted with the deformations at the FE nodes. This expansion as a post processing step has become more difficult for the user to do since the deformations at the FE nodes are no longer an output as from OpenFAST v2.0.0.
By doing so, the user can specify a sensor location equal to an actual location for a real blade test, or a location equal to other codes for a code-to-code comparison, and is unlimited by a post processing step that requires interpolation.
The text was updated successfully, but these errors were encountered:
JelmerPolman
changed the title
More than 9 output nodes for AeroDyn and BeamDyn
Feature Request - More than 9 output nodes for AeroDyn and BeamDyn
Aug 2, 2019
This issue was addressed in #373 with the new nodal output features in AeroDyn, ElastoDyn, and BeamDyn.
I suggest closing this issue and creating a new issue for the related request listed in the Describe alternatives you've considered, if that feature is still desired.
Is your feature request related to a problem? Please describe.
Modelling a large blade with BeamDyn leads to large computational times. Especially when the cross-sectional matrices are fully populated, a small time step has to be chosen for the coupling with AeroDyn, and the order of elements is relative high. In my case, a Time/CPU-ratio in the order of 10^(-3) is no exception, leading to CPU Times in the order of days.
For large blades, 9 output nodes is not enough to fully capture the detailed deformation or load distribution of the blade. It is a shame that after all that computational work, only the results at 9 nodes can be written as an output. Hence, only a small part of the computational work is than available for the user. If one needs more nodes, you will have to redo the whole computation only then with different output nodes.
Describe the solution you'd like.
Introduce an option where users can define an unlimited number of output nodes.
Describe alternatives you've considered.
Related to this feature request. The elements in BeamDyn are spanned by the basis functions. The solution BeamDyn finds is thus continuous. It would be great if the user can also define output nodes in BeamDyn that are not equal to the FE nodes or the quadrature nodes. Deformations at nodes other than the FE or quadrature nodes should be easily computed since this is just an expansion of the basis functions, weighted with the deformations at the FE nodes. This expansion as a post processing step has become more difficult for the user to do since the deformations at the FE nodes are no longer an output as from OpenFAST v2.0.0.
By doing so, the user can specify a sensor location equal to an actual location for a real blade test, or a location equal to other codes for a code-to-code comparison, and is unlimited by a post processing step that requires interpolation.
The text was updated successfully, but these errors were encountered: