I have come across a problem when trying to measure the rotor low speed shaft bending moment using FAST.
When measuring the shaft bending moment, I noticed that both the rotating and non-rotating bending moments were availiable in the output options. In this case if I take the vector sum of shaft bending moments in the ys and zs or ya and za directions, shouldn’t the rotating and non-rotating bending moments be the same? However my testing results showed they weren’t the same. /cry
Could someone please tell me what caused them to be different?
I certainly agree that the vector sum of rotating and nonrotating shaft bending moments should be the same. However, I just double-checked the output of FAST and found no problems.
In my check, I modified the primary input file for certification test #2 (file Test02.fst) to include outputs of the nonrotating bending moments at the shaft strain gage (outputs LSSGagMys and LSSGagMzs) and the azimuth angle of the shaft strain gage (output LSSGagP). (The rotating bending moment outputs at the shaft strain gage, LSSGagMya and LSSGagMza, are already included in this certification test.) From the vector relationships, the equations relating these two sets of outputs are:
In Test02.fst, the reference azimuth angle, AzimB1Up, is 0.0, so the equations above can be simplified.
Using either set of equations with the output of Test02.fst, the mismatch between the right-hand and left-hand sides of the equations is very small (generally fractions of a percent). The small mismatch error that does exist is most likely due to numerical round-off of the FAST output.
Can you describe what you are doing to notice a large mismatch between rotating and nonrotating bending moments?
Now I understand why large mismatch between non-rotating loads and rotating loads was noticed from my tests.
Instead of taking the vector sum of the shaft loads straight from output results, I calculated the fatigue damage equivalent loads first and then took the vector sum.
I have changed my codes a bit into taking the vector sum before calculating the fatigue damage equivalent loads, now the rotating and non-rotating loads for the low speed shaft are the same.
When analyzing loads for vector pairs such as shaft, tower, and blade-root loads, you really should use load roses, which are calculated in Crunch. Load roses use the vector pairs to compute the loads for many orientations about the axis. You then should do your fatigue calculations for those values instead of the original pairs.
Suppose you have a shaft with two pairs of strain gages that are 90 degrees to each other. This is the usual way to measure bending loads on shafts, blades, and towers. When a shaft is bent, it is not necessarily bent purely in the direction of one of the strain gages, but at some angle between. However, the gages measure only the bending moments in those two directions. You can find the magnitude of the pure bending moment by taking the root of the sum of the squares of the two measured loads. You can determine the orientation of the pure load by taking the arc tangent of one divided by the other.
If you are trying to determine the fatigue damage of a shaft, it isn’t reasonable to calculate the damage of the loads measured by the two strain gages. It is unlikely that either orientation represents the most heavily loaded orientation. To use one or the other for the maximim damage is unconservative, to add the two is overly conservative.
A load rose will calculate how much bending there is at many orientations around that shaft at each time step. One of our postprocessing programs, Crunch, will create new channels from the ones generate by a simulation or from test data. Here is an except from the Crunch manual:
After generating the load roses, you should then do your rainflow calculation to determine the fatigue damage for each of the load rose’s orientations. The maximum of those calculations is much closer to the true maximum damage to the shaft. Crunch will generate the load roses and perform the rainflow analysis all in a single step.
No. You must use a postprocessing program such as Crunch to generate load roses.
Yes, it is overly conservative. If load roses weren’t an easy option, I would recommend that method, but they are. It also seems meaningless to use the vector magnitude of the loads, as the phase changes.
Are you asking for a reference on calculating DELs in general, or specifically how they are done with load roses?
If the latter, when you use Crunch to generate load roses, it simply adds extra channels to the input time series that you can rainflow count in the regular way. The Crunch manual describes the process.
Crunch currently does not calculate DELs from the rainflow cycle counts. I use a spreadsheet or a program called Fatigue to do that. If you need details on the spreadsheet, I can post the equations. I use the spreadsheet to calculate the DELs for a single simulation.
My Fatigue program is useful when you want to take the cycle counts of many simulations at different wind speeds and weight the counts according to a Rayleigh distribution. It is available for download from our web site.
However, it seems to me the question is akin to asking if it is more accurate to have strain gages at five points along the blade instead of only at the root. It is a computational method to provide greater detail as to what is happening to some bendable structure.
It seems obvious to me on first principles that it is more accurate. The question is whether is it worth the extra effort. I find that it really requires very little effort, so my answer to that question is “yes.”
I can not understand why we not use the vector sum of two strain gages. The vector sum is always the maximum value of the damage load. Could someone tell me the reason. Thanks!
You can use the magnitude of the vector sum of the two orthogonal loads to calculate the ultimate load of a shaft.
For fatigue loads, however, it is important to perform the rainflow cycle counting and DEL calculation at multiple orientations around of the shaft. This is because the rainflow cycle count would not be accurate if the orientation changed with each cycle. Once the DEL is calculated for multiple orientations around the shaft, the orientation with the highest DEL is the fatigue driver.
For the load roses, I generate the other channels according to this formula: Load(Sector) = Load0COS(Angle) + Load90SIN(Angle).
I would like to ask if in this formula that was written in a post above, if Load0 and Load90 correspond to LSSTipMzs and LSSTipMys respectively that are the non-rotating moments.
The formula for the load roses applies to any orthogonal loads Load0 and Load90 e.g. in the blade, shaft, or tower. You are correct that LSSTipMzs and LSSTipMys are orthogonal shaft-bending moments in the nonrotating frame.
Thank you for your prompt and clear response. I am wondering if it is equivalent to apply the load roses to the non-rotating orthogonal moments LSSTipMyz, LSSTIMzs with the rotating bending moments LSSTipMya, LSSTipMza. Or is it one of the two pairs more ‘correct’?
Furthermore, is it sufficient to take only the angle sector 0-180 degrees, or do I need to do it for the full revolution?
You can calculate load roses using LSSTipMyz and LSSTipMzs or LSSTipMya and LSSTipMza; the former would be useful to calculating loads in the nonrotating nacelle and the later would be useful for calculating loads in the rotating shaft.
There is no need to go beyond 180 degrees because those loads will be the negative of the loads on the opposite side (angles less than 180 degrees).
I can successfully use Mlife to calculate short-term DEL based on FAST derived time-series loads and moments. Now when I change the part of Load Roses to obtain resultant bending moments (RootMxb1,RootMyb1 and TwrBsMxt, TwrBsMyt ), Matlab always shows errors like the figure below.
The related script in the file of Mlife is:
----- Load Roses -------------------------------------------------------------
2 NumRoses The number of load roses to generate.
Rose Name Units Channel1 Channel2 nSectors
“RootMxyb1” “kN-m” $RootMxb1$ $RootMyb1$ 12
“TwrBsMxyt” “kN-m” $TwrBsMxt$ $TwrBsMyt$ 12
I haven’t looked at the source code yet, but I’m curious if you can run Test09.mlif from the MLife CertTest, which considers load roses. Does this test run for you without errors?
Thanks for your quick response!
I can run Test09.mlife successfully. After comparing my code with Test09.mlife, I found that in addition to changing the Load Roses section of the settings file, the NumChans and ChanTitle, etc need to be filled manually and the Fatigue section should also be modified to add corresponding column for each sector. Now I can calculate the load roses for my purpose.
