Dr. Jonkman,
I am currently trying to run a modified version of Test21 (the same wind/wave set-up but with a different turbine and modified support structure).
FAST doesn’t seem to have any issues initializing but after calculating the internal modal eigenvectors I receive the error message shown in the attached image. "BDED_L_2_AD_L_B(1): MeshMapCreate:CreateMotionMap_L2_to_L2:CreateMapping_ProjectToLine2:Node 19 does not project onto any line2 element.
Looking into other forum posts you previously indicated that these types of errors can be caused when the tower start/end points are inconsistent between AeroDyn and ElastoDyn files, but I have confirmed that is not the case here. Am I right to think that “BDED” indicates the issue is with the blades and not the tower?
I have attached the relevant inputs files and would appreciate any guidance you can provide as to how to move forward. Thank you.
MC Anderson
Vestas8MW_HybridBase_ElastoDyn_Tower.txt (3.61 KB)
Vestas8MW_Blade.txt (6.38 KB)
Nevermind,
The error was due to an error defining the hub radius HubRad in the ElastoDyn file.
Hello,
I experience a similar error as described by Mary Carol:
FAST_InitializeAll:InitModuleMappings:BDED_L_2_AD_L_B(1):MeshMapCreate:CreateMotionMap_L2_to_L2:CreateMapping_ProjectToLine2:Node 1 does not project onto any line2 element.
However, I couldn’t link it to an error in the HubRad definition. If I understand this correctly it is an error in the mapping between AeroDyn and BeamDyn for all three Blades, is that correct? One thing I find suspicious is that the error appears with the very first node “Node 1”.
I have tried to reduce the BlSpn value at the last station of the AeroDyn Blade definition input file about a couple of millimeters as mentioned in “NRELOffshrBsline5MW_AeroDyn_blade.dat”, but this didn’t help. My blade is pre-swept and pre-bent with a radius of 20m measured along the blade pitch axis (i.e. along the curved blade axis it is longer), therefore I am not completely sure about the TipRad setting in the ElastoDyn Input File. For a blade length along pitch axis of 20m and a HubRad of 0.816m, the TipRad should be set to 20.816, or could this be wrong because of pre-sweep and pre-bend of the blade?
I am grateful for any hints.
Regards
Paul
I have just found that this errors seems to be related to the AeroDyn BlSpn, BlCrvAC and BlSwpAC values. I am currently using 28 keypoints for the BeamDyn blade reference axis (kp_xr, kp_yr, kp_zr) and 28 stations for AeroDyn as well. If I set the AeroDyn and BeamDyn values to BlSpn = kp_zr, BlCrvAC = kp_xr and BlSwpAC = kp_yr the error message disappears. (There is a new error though, but it is related to not converging, i.e. a different topic, I guess.)
However, with the keypoints in BeamDyn I defined the neutral axis of the blade to be the reference axis, while AeroDyn expects the distances from the blade root pitch axis to the aerodynamic center of the blade station, which is not necessarily the BeamDyn main axis as described (in my case, neutral axis and AC do not coincide).
Is my assumption of the meaning of these terms correct or might there be another problem in my blade definition?
Dear Paul,
Yes, this error is notifying you of an incompatibility between the AeroDyn and BeamDyn meshes.
When BeamDyn is enabled, the blade-related inputs and outputs from the ElastoDyn module are unused, including TipRad, replaced with those available in the BeamDyn module.
Your understanding of the aerodynamic center in AeroDyn is correct, but the reference axis in BeamDyn need not be associated with the neutral axis. As has been discussed several times on this forum e.g.: 6x6 Stiffness Matrix of NREL5 MW Turbine - #13 by Jason.Jonkman, I suggest defining the reference axis in BeamDyn as a smooth curve that follows the natural geometry of the blade i.e. likely not the neutral axis, shear center, mass center, etc. Typically this curve can be set with very few key points. Is your reference axis in BeamDyn a smooth curve?
Best regards,
Hello Jason,
I still have some problems with the mapping of BeamDyn and AeroDyn. Originally my BeamDyn reference axis was not smooth, but I fixed this and now this shouldn’t be an issue anymore. However, I still get various BeamDyn error messages depending on the BeamDyn settings. E.g. for Trapezoidal quadrature and 5th order elements (same settings as for the NREL 5MW BeamDyn blade) I receive a mapping error similar to the one described above. If I select Gaussian quadrature with 5th order elements, the “Solution does not converge after the maximum number of iterations”. If I reduce the element order to 3rd order elements and select a very low timestep for BeamDyn (2e-4 sec), the simulation starts but crashes at 0.274s (“FAST_Solution:FAST_AdvanceStates:AD_UpdateStates:BEMT_UpdateStates(node 14, blade
2):BEMT_UnCoupledSolve:DeterminePhiBounds:There is no valid value of phi for these operating
conditions! Vx = -0.13624, Vy = 65.18, rlocal = 9.8299, theta = 0.12972”).
I think this is an issue of BeamDyn and I am not sure how to deal with this problem anymore, since I have tried different reference axes and interpolation schemes in order to find a suitable reference axis and a smooth curve for AeroDyn’s BlCrvAng as well. I have also tried to set the last AeroDyn station to some millimeters before the blade tip as in the “NRELOffshrBsline5MW_AeroDyn_blade.dat”, which didn’t help as well.
Please see attached the normalized plots of my BeamDyn reference axis (“Ref. pitch axis bend/swp”) and the corresponding Aerodynamic Center axis of AeroDyn. The “Neutral axis” is not used in my FAST model and can be ignored. You can also see that the BlCrvAng is smooth as well. The only thing that is not very smooth is the initial_twist angle for BeamDyn as shown below. could this be an issue?
AeroDyn BlCrvAC vs. BeamDyn reference axis bending (x)
AeroDyn BlSwpAC vs. BeamDyn reference axis Sweep (y)
AeroDyn BlCrvAng
As I was not able to attach the graph of the initial_twist angle to my last post I will post it here:
BeamDyn initial_twist
If I understand the BeamDyn manual correctly this initial_twist is the angle of the local principal axes in the sectional coordinate system. The strange angle of almost 90 degrees at the beginning of the blade is a result of the stiffness distribution and is calculated that way by FOCUS6. Therefore I am not able to change it easily in order to smoothen it somehow.
Dear Paul,
Just a few comments:
- I recommend using Trapezoidal quadrature in BeamDyn for best results.
- The mesh-mapping error appears to be related to the two most inboard nodes. From your plot, I don’t see large offsets between the inboard nodes in AeroDyn and the reference curve in BeamDyn, so, I’m a bit surprised you are getting this error. Are you sure you’ve plotted the data correctly?
- The initial_twist in BeamDyn should also be smooth. But the initial_twist need not match the structural pretwist; the initial twist should simply define the reference orientation of the local coordinate system used to define the sectional mass and stiffness matrices; structural twist can also be included in the sectional stiffness matrices (through off-diagonal terms in the two bending degrees of freedom).
I’d probably have to see your input files to comment further.
Best regards,
Dear Jason,
thank you for you quick reply. I would very much appreciate if you could have a look at my input files but I would rather not make it publicly available in this forum. Can I send you an email with my model instead?
Regarding you comments:
- Using trapezoidal quadrature it seems that I will always receive a mapping error. Unlike shown in the picture above it affects Node 21 (at x=0.8 in the graphs), which I don’t really understand as this point is not much different from the others around it
- Of course there still might be an error somewhere but I am very sure that these plot should be correct
- I have created an artifical smooth trend for initial_twist but this didn’t help with the mapping error
With Gaussian quadrature and an element order of 4 using the smoothened initial_twist I am able to start the simulation. The results look quite strange as if there are some problems with the model or the initial conditions, but I think this should not affect the module mapping even before the simulation starts.
Dear Paul,
You can send me a message through the forum, with attachments.
At node 21 (80% span), perhaps there is a problem in the mesh mapping due to the higher curvature in the sweep direction. Can you avoid the error by moving node 21 in AeroDyn slightly inboard or outboard?
Smoothing out initial_twist wont impact the mesh-mapping error, but it should improve the convergence of BeamDyn once you get the model to run.
Best regards,
Dear Jason,
I will send you a message with my FAST model. I have tried to change the BlSwpAC value of node 21 slightly in order so reduce the curvature, but this did not help.
Thanks again for your help,
regards
Paul
Dear Paul,
I took a brief look at your model and reproduced the mesh-mapping error when using trapezoidal quadrature. However, I was able to eliminate the error by shifting blade node 21 in AeroDyn slightly inboard e.g. from 16.0 to 15.9 m. Basically, the mesh-mapping utility is having trouble projecting a line from AeroDyn node 21 normal to the BeamDyn reference line at the start of the blade sweep at 16-m span. Shifting this node slightly inboard solves the problem.
Once the mesh-mapping issue is solved, FAST still bombs when using trapezoidal quadrature, but I would guess this is related to how the BeamDyn model has been set-up and I have not try to resolve it further.
Best regards,
Dear Jason,
thank you for having a look at my model. I wonder what exactly you mean with “this is related to how the BeamDyn model has been set-up”. Is there another way to set up the model? E.g. should I use more (or less) key points or cross sectional matrices or what do you mean?
In this phase of our project we depend on a suitable FAST model of the turbine as it is the basis of the controller design for the real turbine test of the blades. Do you have any advise for me on how to proceed further with changes in the model in order to obtain a stable BeamDyn model?
Thanks again for your help,
regards
Paul
Dear Paul,
I’m not sure what is wrong with your BeamDyn model. A few comments:
- If you haven’t already, trying running the BeamDyn model in standalone mode (uncoupled from FAST). Do you get the expected response e.g. for various tip loads?
- Have you verified that the cross-sectional mass and stiffness matrices are entered correctly?
- Perhaps the curvature of the reference line is still to high? Can you eliminate all but a few key points to ensure a smooth reference curve?
- Have you verified that the model discretization in terms of time step and spatial discretization is appropriate?
Best regards,
Dear Jason,
I will focus on the points you mentioned, although I have verified most of the points you adressed already. However, I will tell you if I have gained some new findings.
Regards
Paul
Dear Jason,
I have just found this topic and wanted to add some remarks regarding my findings.
When drastically decreasing the simulation time step to 1e-5s I am able to simulate the model using trapezoidal quadrature and an element order of 8, which I found to be sufficient for convergence regarding the total total blade mass and the location of the center of gravity. However, I need to set the overall FAST time step as well to 1e-5s, as for larger time steps (e.g. 1e-3s in FAST, 1e-5s in BeamDyn) the solver again does not converge.
This in turn leads to extremely high computational efforts for an CAE aero-elastic simulation tool (Time Ratio (Sim/CPU): 6.62342E-04). It took me more than 5 days to simulate a time series of only 300s with these settings.
Therefore I wanted to ask about your experience with the required BeamDyn time step. I have noticed that for the NREL5MW loadcases provided with FAST a time step of 1e-3s is preset (and working), but the blades are straight and much larger, leading to lower eigen frequencies that explain the larger time step. I have also noticed that for the FAST8 validation campaign with a SWT-2.3-108 with curved blades a time step of 5e-4s has been used for the BeamDyn model.
Is it reasonable that I am forced to set a time step as small as 1e-5s for curved 20m blades? Do you maybe have any more hints for me which settings I could change in order to increase the simulation speed without losing convergence of the model (if possible), or do you have any other remarks?
Best regards
Paul
Dear Paul,
OK, thanks for the update.
The easiest way to increase the time step in BeamDyn is to reduce the order of the finite element. You mention the use of Order_Elem = 8, which is high (usually we we set Order_Elem <= 7).
We are also aware of a number of issues and bugs in BeamDyn that are resulting in smaller than otherwise necessary time steps (e.g. the open Issues on the OpenFAST page: github.com/OpenFAST/openfast/issues). Some of these issues have been fixed by Envision Energy, but NREL has not yet had the time to merge there changes back into the official NREL-supported version. Some of the issues require further development.
Best regards,
Dear @Jason.Jonkman
I may be having a similar problem when the program shows no convergence during initialization.
FAST_InitializeAll:InitModuleMappings:BD_2_AD_BladeMotion(1):MeshMapCreate:CreateMotionMap_L2_to_L
2:CreateMapping_ProjectToLine2:Found close value for node 1. (3.21370E-06 m)
InitModuleMappings:AD_2_BD_BladeLoad(1):MeshMapCreate:CreateLoadMap_L2_to_L2:CreateMapping_Project
ToLine2:Found close value for node 1. (3.21370E-06 m)
InitModuleMappings:BD_2_AD_BladeMotion(3):MeshMapCreate:CreateMotionMap_L2_to_L2:CreateMapping_Pro
jectToLine2:Found close value for node 61. (1.30521E-05 m)
InitModuleMappings:AD_2_BD_BladeLoad(3):MeshMapCreate:CreateLoadMap_L2_to_L2:CreateMapping_Project
ToLine2:Found close value for node 61. (1.30521E-05 m)
FAST_Solution:FAST_AdvanceStates:B1:BD_GA2:BD_DynamicSolutionGA2:Solution does not converge after
the maximum number of iterations
FAST_AdvanceStates:B2:BD_GA2:BD_DynamicSolutionGA2:Solution does not converge after the maximum
number of iterations
FAST_AdvanceStates:B3:BD_GA2:BD_DynamicSolutionGA2:Solution does not converge after the maximum
number of iterations
I tried setting the pre-bending value of the blade to 0 as well as the coupling term in the stiffness matrix, meanwhile the time step of the simulation is set to 0.0005s, but this did not work. This OpenFAST model works fine without BeamDyn, and no errors are reported when BeamDyn is run alone. So I wonder if something went wrong when BeamDyn was coupled with Aerodyn. I hope to get your guidance and answers.
Best regards
Dear Jason
Since I don’t know how to upload files to the forum, I will send you my input files by email to you later.
Best regards,
