it’s already a couple of weeks I’m facing the issue, so that I decided to open a thread here on the forum.
The question is pretty easy: I’m trying to write a tool enabling the user to get fatigue post-processing out of BLADED output.
To do this, I make use of MATLAB and of the rainflow count function provided within the MathWorks newsreader. If I understood it right, MCrunch handles the same function.
I already had a look a the following post: http://forums.nrel.gov/t/treatment-of-residual-half-cycles-in-rainflow-count-fatigue/400/1.
There (i.e. in the above post), it seems to be clearly pointed out and recommended to count half cycles as they come out of the RFC.
Let’s come now to the “funny” thing: cross-checking BLADED binned rfc and MATLAB binned rfc, the difference resides ecactly on how Bladed processes the half-cycles; Bladed rounds down (floor) or up (ceil) the half cycles. But I am not able to figure out which criterion BLADED uses.
The bottom line is how to thoroughly treat half cycles in order to calculate realistic RFC: note that I stated “realistic”, which does not mean matching BLADED outputs.
Fatigue is quite a well-known topic, I don’t really see that need for discrepancies in the generation of a RFC.
I really look forward to having a feedback: any criticism or support are welcome.
Are you comparing your code to Bladed for a single time series, or are you analyzing a large number of simulations to predict lifetime with some sort of weighted distribution?
My MCrunch does not use the RFC algorithm from The MathWorks, but one I wrote myself based upon someone’s algorithm. Greg Hayman’s MLife however, uses the C program from The MathWorks as a MEX function and seems to be much faster than the MATLAB function I wrote. Our four tools have been checked against each other and against standards. I have not compared them to Bladed.
When you said: “Bladed rounds down (floor) or up (ceil) the half cycles,” did you mean that you do not know which of the two methods Bladed uses or that it can use one or the other method? Our tools allow you to choose a value between 0 and 1. Choosing 1.0 tells our codes to count half cycles as full cycles, and setting it to 0 throws them away. I usually set it to 0.5.
Have you tried tried comparing your code to one of ours? The nice thing about our codes is that they are open source–you can see what it is we are doing, so there are no mysteries.
I’ve been told that any cycles that happen after the largest cycle are left unclosed. Apparently, in the early days the recommended practice was to reorder the time series so that the largest cycle is closed at the very end. This ensures that all cycles are closed, which is conservative.
I don’t know if this helps at all. I’m really not an expert in fatigue, so maybe someone who is can provide more insight.
first of all I’d like to thank you for the ready reply.
At the moment, I’m comparing MATLAB results and BLADED results for only one run. Btw, I already came up with a procedure accounting for the Weibull/Rayleigh wind distribution.
I stumbled on this MATLAB/BLADED issue absolutely by case: the first 5 runs I processed in Matlab led exactly to the same results as Bladed. But then, I happened the mismatch.
When looking at binned amplitudes-cycles lists,Matlab rfc stores half cycles as they come; I believe Bladed counts half cycles too, but then there’s sort of further processing in order to round them to full-cycles, since in the Bladed list only full cycles can be spotted.
What I am not able to grasp is how Bladed rounds the half cycles: some of them are rounded down (i.e. 340.5 → 340) and some others up (i.e. 340.5 → 341).
At the beginning, I thought that Bladed takes couples of half-cycles, rounding down those cycles corresponding to the smallest amplitude in the couple (respectively up those with the highest amplitude): the physical meaning would be that higher amplitudes with less cycles have a major impact than lower amplitudes and high number of cycles. But, unfortunately, this procedure did not compansate for the mismatch.
So I wonder if there is any bibliographic referement closely looking into the treatment of half-cycles.
I look forward to hearing from you again.
The reference I use is Sutherland’s paper that was mentioned in a previous thread: [url]http://forums.nrel.gov/t/treatment-of-residual-half-cycles-in-rainflow-count-fatigue/400/1]
I have checked the GL and IEC 61400-1 standards and found no mention of how to deal with half cycles. The ASTM E1049-85 “Standard Practices for Cycle Counting in Fatigue Analysis” talks about obtaining half cycles, but does not say what to do with them.
Have you talked to Bladed Support at GL-GH to find out what they are doing?
I count them as half cycles because it’s half way between being conservative and unconservative.
I really have no more advice to offer you, as I am not an expert in this area.
sorry for the late reaction.
I tried asking GH concerning this matter, but I don’t expect that much from them: they make money out of their business, thus I assume they are not that willing to disclose their own tools or ideas with externals.
Btw, I will not give up and hopefully I will come up with a decent compromise.
I really thank you for your kind answers and support.
Do you have any follow up on this matter? Any GH positions at all?
Thats actually pretty intriguing for me as well. Hope to hear good news about that MATLAB script!