I am trying to evaluate the fatigue life of the wind turbine system, specifically the drive train components. For this I am using TurbSim to generate wind data and Fast for the loads. Next, I used MCrunch for post processing the Fast output to generate the rainflow counts, equivalent loads and the life time damage to the system
According to what I know so far, MCrunch uses the Miner’s rule and calculates the lifetime damage only for the (fast output) files we are running. This Damage generally ranges from 0 to 1, where 1 means complete failure of the system. However, I believe, in practice this damage ranges between 0.79-1.6 to account for all the uncertainties. Now, I understand that, MCrunch calculates the number of cycle counts for the fast output files files we run and weighs it with the probability density of the site specific wind speed distribution.
Can anyone please suggest any current tools I can use to analyze the fatigue life of the turbine system other than MCrunch.
How can I extrapolate the fatigue damage done to the turbine during a simulation to analyze the lifetime fatigue damage (Say we hope a 20 year life of the turbine)?
If I have to analyze a already running wind turbine how can I use MCrunch to account for any damage already done to the system beforehand?
How many MCrunch simulations do I need to run to get a stable enough data to the Lifetime damage.
I received your email. I am responding on the forum in the hope that whatever little insight I have into MCrunch may prove beneficial to other users of the forum. First of all, I am no expert on MCrunch or fatigue. I dabbled with it a little bit, because of the nice plotting features that Marshall Buhl has incorporated into it, which Crunch doesn’t have. And Marshall would be the best person to answer your questions since it is his code, although I believe that he has not actively worked on it for a while. Because of memory issues with large files, I also haven’t used MCrunch for a while. Referring to your questions below.
You can use Crunch and Fatigue codes that NREL distributes to analyze fatigue. I am sure there are other codes out there but these codes read the data directly from FAST output files and will save you an extra post processing step.
You may wish to refer to IEC 61400-1 standard. Annex G of the standard has a description for the methodology to extend the fatigue loads from simulations to the entire lifetime of the turbine.
I am not sure how you would do this.
I assume you mean FAST simulations. IEC has recommendations for these too. I believe it varies based on load cases for turbulent wind between 6 to 12 simulations at each wind speed. Someone with more experience will have to tell you if this is sufficient or more simulations are required.
You also had emailed me regarding the question I had posed in the topic [url]MCrunch issue with Rainflow Cycle Exceedance plot]. Marshall pointed me to the MCrunh theory draft manual which has some explanation on the fatigue life calculation. The link is available in the topic. I hope this helps.
Thanks for pitching in. I’ve answered his questions in email as best I could considering I’m not an expert in fatigue, either. I suggested he post here.
I not only have not worked on MCrunch in a long while, I’ve never actually used it to do real work. I don’t get to do much fun stuff any more.
We are now contracting with Greg Hayman to work on our postprocessing tools. He is working on a new program called MLife, that will take the lifetime features from MCrunch, use the one-file-at-a-time feature of MExtremes to reduce dramatically the memory requirements. He is also adding a few new features to it. He currently has a rough alpha version that duplicates the features of MCrunch, so we may have something for our users in the next month or two.
I can’t believe you don’t get to do fun stuff anymore. Everything you guys do at NREL seems fun and interesting to me
It is good to know that someone is working on a one-file-at-a-time code. That would make life so much easier.
Since the code is in alpha right now, can I make a suggestion for an additional feature. One of the things I have come up against is the request from bearing vendors for some sort of loads for calculating bearing life, something along the lines of number of revolutions at a certain load level. Not sure if that would be a much sought after feature or not.
I ended up writing a code, which for most part was a rehash of your Mextremes and Mcrunch code to read in FAST files one at a time and bin the loads. Because of the limited time I had to come up with the code, it is pretty crude and probably buggy. It also requires an initial crunch or Mextremes run to estimate bin extremes. I am sure you guys can come up with something more elegant.
Let me know if you decide to implement the feature and would like to take a look at the code I wrote.
I’m not into bearings, myself, but it sounds as if it is a fundamentally different problem than what we use the rainflow analysis for. It also sounds more like a histogramming problem, where one computes the fraction of time at a certain load level. I guess that it’s not quite what you want in that revolution rate probably varies. Anyway, I’ve added it to our list of things to consider.
Thanks for the response. You are correct in the statement that it is a fundamentally different problem. The reason I mentioned it is because the methodology can borrow some aspects from existing NREL codes(i.e reading one file at a time and binning loads). One suggestion I have had to come up with the revolutions at a certain load level is to assume that the load and rpm stays constant between time steps. This is not going to produce exact count of revolutions especially if one uses a larger timestep, but should at least give an idea of what to expect. In any case it may not be something too many people are interested in and may not be worth your time and effort.
I don’t get to do much fun stuff any more. 
