I am running an ADAMS model (created with FAST2ADAMS) with a straight, untapered, zero offset, aerocent = 0.25, rotor with NO_CM. With no gravity and 10 m/s uniform wind, I obtain a steady negative twist. I cannot understand where this twist is coming from. If I run with no AERO and 9.81 m/s^2 gravity, I get no twist. If I run at zero rpm and 10 m/s, I get no twist but expected blade deflection. So it seems to a combination of aero and rotation.
Any ideas on where this twist is coming from or other troubleshooting ideas?
Thanks and regards to all
The blade pitching moment–and thus the blade twist in ADAMS–depend on more than just the aero center offset (AeroCent) and the aerodynamic Cm values. Because the aerodynamic loads are applied in the deflected state in ADAMS (and in FAST), when a blade deflects, the deflection in combination with the aerodynamic loads will bring about contributions to the blade pitching moments. Likewise, the blade element inertia forces, in combination with the blade deflection, will bring about contributions to the blade pitching moments. These additional terms will contribute to the blade pitching moments unless the blade is modeled rigid. I suspect it is these effects that are causing the twist you are seeing.
Thank you for the reply Jason. I did not think of the blade deflected state. To verify this, I ran a case with 50 m/s at 90 deg pitch and zero rpm and I observed the blade twisting.
Jason (or whoever wishes to comment),
now that I supposedly understand what is going on in ADAMS, the real problem I have is to understand why this twist is not occurring in my modifications to FAST (I’m calling it CurveFAST) that include the first torsion mode. Given the equations of motion with flexible modes written in Kane’s form, for the case with a parked blade at 90 deg pitch in high wind (also no CM and aerocent =0.25), there is nothing that results in twist. More specifically, at equilibrium the terms on the right hand side of augmented matrix are zero for the torsion degree of freedom. For the generalized active forces, there is no aero moment and the partial linear velocities are zero because the torsion mode does has no contribution (only to partial angular velocity). It seems like with the modal method there is no way to obtain twist in this situation, like the blade does not know that it is bent and the drag force should result in twisting. Am I missing something with the generalized active forces (or elsewhere), or is this really a limitation with the modal method?
I appreciate your help.
I’m not sure what exactly you’ve changed in FAST, but does your version of FAST predict a pitching moment at the root of the blade in the situation you describe?
In the public domain version of FAST, although there is no blade-twist DOF, the blade deflection in combination with the aerodynamic and inertia forces still contribute to a blade pitching moment (as described in my previous post). This pitching moment should twist the blade when the twist DOF is added. There is no limitation in the modal-based method that should cause it to produce different results from ADAMS when the response is dictated by lowest modes that are represented within FAST.
Yes the pitching moment at the root is predicted and matches ADAMS (and regular FAST). However, this pitching moment only enters the equations through the root forces, just like the regular version of FAST; the PMomH0B and MomH0Bt.
If we forget about blade curvature, the changes I made to FAST are:
- The mode shapes are now the eigenvectors from a finite element program. For example, the first flap has a displacement value (normalized by the tip reading) at each analysis node.
- An additional mode (degree of freedom) has been added. This can be any mode, but I am using it for the first torsional mode.
- The stiffness matrix [K] comes from the finite element analysis. The elastic energy for a particular DOF is therefore 1/2*[mode vector]Transposed * [K] *[mode vector] * (DOF value)^2
- I have added rotational inertia to the Generalized Inertia Forces, but for this static equilibrium case these are zero
As stated before, for the torsional mode the partial velocity is zero and for this model case the aero pitching moment is zero. Therefore, is seems there is no aerodynamic contribution to the generalized active forces for the torsional mode.
I’m next going to look at if I am missing some possible coupling between modes in the elastic forces (I thought there was none), but if you think of anything else, please let me know.
I’m not sure why you say that the “pitching moment only enters the equations through the root forces.” This is not true. A deflection of the blade will generate a pitching moment–not just at the blade root–but at all blade stations inboard of the deflection. You should be able to see this effect by outputting the pitching moments at the local blade stations.
A “partial velocity” is a vector pointing in the direction of a generalized speed, and so is never zero even if the generalized speed is zero. (In FAST the generalized speeds are the time rate of changes of the DOFs.)
Thank you again for the reply, this is discussion is definitely helping me along.
What I meant was the pitching moment (due to drag force on the deflected blade) does not enter the equations of motion at the point in the augmented matrix for the torsion DOF. Yes the pitching moment is calculated along the blade (in SUB CalcOuts), however it does not result in twist. It should, so I am wondering what I am missing in the equations of motion.
For the torsional DOF, the mode shape is pure twisting about the j3 axis, so the partial linear velocities for this mode are zero.
I think I figured out the problem. In the equations of motion I need to add to the generalized active forces (for a particular blade node) the moments resulting from forces applied to the outboard deflected elements. These calculations would be similar to the ones for pitching moments at the gage locations in CalcOuts.
The equations of motion implemented in routine RtHS() are entirely consistent with the output loads computed in routine CalcOuts(). So, if there is a pitching moment (due to the aerodynamic and inertia forces on the deflected blade) in the output loads, then this same pitching moment exists in the equations of motion. For example, a pitching moment in a blade–even when there is no torsion DOF–will cause bending in the tower through the equations of motion (when the blade is not vertical).
It appears to me that you have missed some terms in your derivation of the new equations of motion with a blade torsion DOF. For example, the position vector from the apex of rotation (point Q) to a point in blade 1 (point S1), rQS1, should depend on the torsion of the blade because the twisted shape functions depend on the twist distribution. In your case, this twist is not static (i.e., it is not the same as the structural pretwist) but will depend on the blade torsion DOF. Did you include this effect? If you did, and if you carried this effect through the rest of the equation of motion derivations, then the partial linear velocity of point S1 for the torsion DOF should have components that depend on the flap and edge deflection. This, then, will cause the pitching moments to effect the torsion DOF in the augmented matrix of the equations of motion.
For this particular problem the blade is not twisted, so the flap, edge, and torsional motions are uncoupled.
I agree that for the root loads the SUBs RtHS and CalcOuts are consistent; however, I believe there is something missing from generalized active forces at the analysis nodes. The particular code is:
DotProd( PAngVelEM(K,J,PSBE(K,I),0,colon), TmpVec3 )
where TmpVec3 is:
TmpVec3 = MMAero(K,J,colon)*DRNodes(J)
Currently, CM is zero and aerocent = 0.25 so MMAero is zero.
I believe that the pitching amount arising from the outboard elements needs to be included in this vector. Otherwise, there would be no contribution to the augmented matrix for the torsional DOF. This pitching moment is calculated at the blade gages in CalcOuts, but I need to add the inertia forces from the twisting of the outboard elements. Please comment.
Another day and I am wavering from my beliefs in my last post. I need to look at your comments more closely and think about what is going on in the equations of motion with my modifications for torsion.
I agree that MMAero will be zero in your case as you describe because CM is zero and AeroCent = 0.25. What should not be zero is the code:
DotProd( PLinVelES(K,J,PSBE(K,I),0,colon), TmpVec1 )
TmpVec1 = FSAero(K,J,colon)DRNodes(J) - ElmntMass( Gravity*z2 + LinAccESt(K,J,colon) )
because the partial linear velocity will not be zero for the torsion mode as I explained in my previous response. Even though the flap, edge, and torsion motions are uncoupled, the torsion motion will still effect the twisted shape functions, and thus it will effect the position vector, rQS1, and partial linear velocity of point S1 for the torsion DOF. Only if rQS1 were independent of the torsion DOF, would there be no twist due to flap and edge deflections. But rQS1 should depend on the torsion DOF, so blade should twist.
I have found a problem in my derivation. In FAST language the partial linear velocity for a blade element was:
PLinVelES = PLinVelEQ + PLinVelHS + PAngVelEH x rQS1.
When I added blade torsion, I failed to change PAngVelEH to PAngVelEM (the element now has a angular velocity relative to the hub frame). With this change, there should be a partial linear velocity for the torsional degree of freedom with a deflected blade. This should give the twist I am looking for.
It would not be correct to change PAngVelEH to PAngVelEM in the equation
PLinVelES = PLinVelEQ + PLinVelHS + PAngVelEH x rQS1.
This equation is correct as is. It states that the partial linear velocity of a point in blade 1 (point S1) in the inertia frame (E) equals the partial linear velocity of the hub center (point Q) in E, plus the partial linear velocity of point S1 in the moving hub frame (H), plus the partial angular velocity H in E crossed with the position vector from point Q to point S1. This is the standard expression for motion of a particle in a moving coordinate system.
Instead, the torsion DOF should effect PLinVelES through the term PLinVelHS (i.e., the partial linear velocity of point S1 in H). This can only be the case when rQS1 depends on the torsion DOF, as I indicated before.
Thank you for pointing this out. I remember struggling over this when I first went through the kinematics a while back, and I mistakenly thought this might be my fix.
I am having trouble with your suggestions about modifying the position vector (rQS1) for torsion. I understand (somewhat) how you could approach this with twisted shape functions; where the twist is now time dependent. I don’t know how the resulting analysis would look like without carrying it through, and I’m not sure how to continue on to blade curvature/sweep. As stated before, I used a finite element analysis to obtain eigenvectors for the mode shapes. The eigenvectors are completely decoupled, so for straight blade torsion there is pure twisting. Therefore, I have no change in the position vector for the straight blade torsion mode. I don’t understand how (if possible), or why (scientific basis), the eigenvectors from my analysis are/have to be coupled. Do you have any suggestions or thoughts on this?
You must remember that even if the eigenvectors (mode shapes) for flap, edge, and torsion are uncoupled (as would be the case for a blade that is initially straight, initially untwisted, and uniform), the position vector rQS1 still includes contributions from all of components. This is because rQS1 represents the superposition of all of contributing modes to characterize the actual deflection.
You will have to work through the details of the derivation yourself. All I know is that if you want the loads in the deflected position to effect the twist, then the deflected position must be effected by the twist. Of course, the equations will be much simpler for a blade that is initially straight, initially untwisted, and uniform than it will be for a more sophisticated blade.
Thank you for the reply and the previous responses. I’ll head back into my cave and study this in detail.