Feature Request: IMU at blade span locations

Wind & Water Computer-Aided Engineering Software Tools
1

Hello FAST-users,

I am looking for a possibility to simulate sensor signals from an acceleration sensor in the blades. However I only can request the local acceleration at the blade tip (TipALxb1), which does not contain the effects from gravity and tower top acceleration. Is it possible to include in the next version of FAST one or more inertial measurement units, for which I could specify the location (radius), which then returns the local accelerations in all three axes and maybe also the roll rates (like d/dt TipRDxb2).

Or is such a feature already available and I just didn’t find it?

Best regards
Felix

2

Dear Felix,

The accelerations output by FAST at the blade tip (TipALxb1, etc.) are not accelerations relative to the hub. Instead, the accelerations output by FAST at the blade tip are the absolute accelerations (relative to the inertia frame) but expressed in a local blade coordinate system (that deflects with the blade). These accelerations do include the motion of the tower-top. The gravitational acceleration is not added to these accelerations, but that request is on our to-do list because we understand those are the accelerations that would be measured by an accelerometer.

The velocities of the blade tip are also on our to-do list.

Best regards,

3

Dear Jason,

The topic just came up again. I installed FAST 8 (by the way: Its dependence on Python is kind of annoying) and looked into the available outputs.

What I need is a possibility to output the accelerations (including gravity) and rotational velocities at some blade element. In the FAST source code I was able to locate the position, where the blade element accelerations are computed: ElastoDyn.f90, line 1925. They depend on LinAccES which is computed in lines 1827-1849.
As fortran beginner its difficult to understand the code, especially as I should really dig deep into the source code to understand what is happening and to be able to extend it.

Would it be possible that you tell me the necessary source code extensions to add gravity and to calculate rotational speeds? I hope that I am then able to add new output variables for these computations.

Best regards
Felix

4

Dear Felix,

You can add the effect of gravity to the blade acceleration outputs by changing line 1828 of ElastoDyn.f90 to be:

LinAccES(K,p%TipNode,:) = OtherState%RtHS%LinAccESt(K,p%TipNode,:) - p%Gravity*OtherState%CoordSys%z2

and changing line 1840 to be:

LinAccES(K,J,:) = OtherState%RtHS%LinAccESt(K,J,:) - p%Gravity*OtherState%CoordSys%z2

Adding the rotational velocity outputs will be a bit trickier.

Best regards,

5

Dear Jason,

thanks for your reply. I carefully went trough the code and found, that your suggestion will lead to a problem when calculating the span forces and moments. Look at lines 2133, 2139, 2153 which all add the gravity effect for calculating the forces/moments like (shown here line 2133)

FrcMGagB = OtherState%RtHS%FSTipDrag(K,:) - p%TipMass(K)*( p%Gravity*OtherState%CoordSys%z2 + LinAccES(K,p%TipNode,:) )

Now, as I understand the code a little better, I can fix this on my own. However I wonder about the sign: The existing code uses a positive sign to add the gravity effect, but you told me to use a negative sign:

LinAccES(K,p%TipNode,:) = OtherState%RtHS%LinAccESt(K,p%TipNode,:) - p%Gravity*OtherState%CoordSys%z2

Which is correct?

When going through the code I was wondering why the coordinate systems are named and aligned differently as described by the FAST documentation. For example
CoordSys%z1, z2, z3 in the source code is very similar to the inertial coordinate system xi, yi, zi described by the FAST documentation. Are you planning to change this such that the source code reflects the FAST convention? This would make things easier to understand for novice users like me.

About the rotational velocity: Do you have an idea how to do it? Would you extent

SUBROUTINE SetCoordSy

to also compute the rotational velocity of each coordsys? Or is there a better way to do it?

Best regards
Felix

6

The MAP_win32.dll distributed with FAST v8.03.x contained a dependence on Python; we removed that dependency in a new release of the MAP dll: wind.nrel.gov/designcodes/simula … 6a-mdm.zip

7

Dear Felix,

Good point. Instead of subtracting p%Gravity*OtherState%CoordSys%z2 directly from LinAccES, you could perform the subtraction directly in the equation for the output you want changed, e.g., change line 1905 of ElastoDyn.f90 to be:

OtherState%AllOuts( TipALxb(K) ) = DOT_PRODUCT( LinAccES(K,p%TipNode,:) - p%Gravity*OtherState%CoordSys%z2, OtherState%CoordSys%n1(K,p%BldNodes,:) )

The substraction is correct. p%Gravity is stored as a positive number in ElastoDyn. The equation you copied

FrcMGagB = OtherState%RtHS%FSTipDrag(K,:) - p%TipMass(K)*( p%Gravity*OtherState%CoordSys%z2 + LinAccES(K,p%TipNode,:) )

says that the tip mass will introduce a force if the acceleration is not equal to the acceleration in free fall, whereby

LinAccES(K,p%TipNode,:) = -p%Gravity*OtherState%CoordSys%z2

This is simply a restatement of the equation F = m*a, where F = -mg is the weight of a mass.

You’ve noticed that the inertial frame coordinate system internal within ElastoDyn does not follow IEC convention. That is, z1 in ElastoDyn = xi from the IEC coordinate system, z2 in ElastoDyn = zi from the IEC coordinate system, and z3 in ElastoDyn = -yi from the IEC coordinate system (the y and z axes are swapped between the IEC convention and the internal ElastoDyn coordinate system). The internal coordinate system was established back when FAST was first written in the 1990s, before even I worked on the software. While I agree that it would be much easier if the internal coordinate system followed IEC convention, it would be very difficult to change at this point, so, we have not spent the effort to make the change. You may have noticed that in FAST v8 we do ensure that all data passed between modules follows IEC convention. This requires swapping a few signs when data is exchanged between ElastoDyn and other FAST modules.

I don’t have the time at the moment to fully explain how to introduce the rotational velocities of the blade elements into ElastoDyn. I will say that some of the equations are already implemented – search e.g., for “AngVelEM” in the source code.

Best regards,

8

Dear Jason,

thanks for answering my questions. As we are currently working with FAST 7.02.00d-bjj I added the effect of gravity to this version. Those who are interested can find a patch file attached, to add this feature to their own version of FAST (recompilation necessary). It includes adding a term for gravity to the blade span accelerations and to the output of the inertia measurement unit in the nacelle NcIMUTA*.
Jason, I used a positive sign for gravity in all sensor outputs: Think about an inertia measurement unit consisting of a little mass attached to a spring which itself is attached to the nacelle. Then the mass is hanging downwards (to the negative z-axis) due to gravity. This is the same effect, as if we have no gravity but an acceleration of 1g into positive z-direction acting on the nacelle. Therefore - in my opinion - the sign needs to be positive.

In my opinion this feature should be added to the FAST version provided by the NREL. The Spn*-Outputs are described as the outputs of some gage at some user specified position in the blade. Therefore the outputs should reflect, what some measurement instrument at that position would measure. As I understand, the bending moments SpnMLyb include the effect of gravity. Therefore also the accelerations measured at that position should include gravity. The same argumentation is true for NcIMUTA.

It would be great, if you could add this feature to your next release, especially as it is very easy to implement.

Best regards
Felix
FAST.f90.patch.txt (1.65 KB)

9

Dear Jason,

also thank you very much for the hint, that the rotational speeds for the blade elements are already in the code but commented out. So I went through the code and uncommented the sections and added new outputs SpnRVb*. I also created a patch for that change which you can find attached.

  • Please add the Write_ChckOutLst.m to the FAST archive, which is necessary to generate the code for the outputs. I found a link to it in another topic in the forum, but it should be included with FAST
  • Due to the outputs that I added, the total number of outputs is > 1000. Compiling works fine, but I think FAST2ADAMS won’t work anymore. It would be great, if future versions of FAST would not have such a limit any more (I think it is on the ToDo-List of FAST 8 ).
  • I use the variable AngVelHM from the source code and write it to SpnRVb*. I am not really sure if that is correct. I want to get the rotational speed as measured by some inertial measurement unit in the blade. From the name AngVelHM it follows that the variable should contain the rotational speed of blade element M relative to the hub H. So I looked for AngVelEM which does not exist. However if I look on the output, the rotational speeds from AngVelHM in the three directions add up to RotSpeed very well. So it seems to be correct.

I would really like to see the inclusion of the rotational speeds of the blade spans in your next release of FAST!

Best regards
Felix

[02-19-14] Removed the patch because the rotational speeds which it returns are not correct. If I am able to fix the bug I will upload the patch again.

10

Dear Felix,

OK, I see your point about the sign of the gravity. An accelerometer would measure an upward acceleration for an object resting in standstill on the earth. Effectively, the object can be thought of as accelerating upward to cancel the downward acceleration from gravity. Thanks for the correction. However, I have not checked your source code implementation.

Adding this feature is on our to-list. Our plan was to add a switch to the ElastoDyn input file that determines whether the acceleration-related outputs include the gravity term. A new version of FAST v8 is coming soon, but this feature will not be included in that version. We’ll identify it as a high-priority feature for a subsequent release.

FAST v8 does not have any problem with having more than 1000 outputs. You’re right that this was a FAST-to-ADAMS limitation of FAST v7; FAST v8 does not currently support the FAST-to-ADAMS preprocessor.

I have not had the time to review your changes for the rotational speeds.

Best regards,