Post-processing

Articles on this page:

• Markov Matrix gives non-integer number of cycles
• Rainflow cycle counting
• Tabulation of results from Bladed
• IEC Ultimate load sub groups
• Memory limit on number of load cases
• Automatic bin sizing
• Post-processing Linux generated results using Bladed Windows (or vice versa)
• S-N slope lookup table not working
• Combining stationary and transient cases into a single distribution

Problem

I'm calculating Markov Matrix from rainflow with 128 bins, plotting Number of cycles vs. Cycle Range but I get a table with number of cycles with decimal numbers. Why do I not get integer numbers for the number of cycles?

Solution

The Rainflow cycle counting algorithm in Bladed counts whole numbers of cycles, therefore you would end up with integers after a cycle count. This can be seen for example in the results of a single channel rainflow cycle run. However, when summing the results over a lifetime, a scaling factor is calculated for each load case and the rainflow cycle count of each load case is multiplied by its corresponding scaling factor.

The scaling factor is based on the weighting factor (e.g. user defined hours per year or Weibull distribution) and the scaling up/down to a whole year of simulation time. Therefore if the total number of hours entered into a rainflow calculation does not exactly equal the number of hours in a year, then the distribution that you provide will be scaled to match the number of hours in a year. This can lead to the non integer values for the number of cycles.

Keywords

Rainflow Cycle; Markov Matrix; Integer

Problem

What algorithm is used in Bladed to do rainflow cycle counting?

Solution

The rainflow cycle calculating in Bladed is based on the algorithm by S. D. Downing and D. F. Socie in their paper "Simple rainflow cycle algorithms".

The algorithm used is "Rainflow Algorithm II (one-pass)"

Keywords

Rainflow; Post-processing

Problem

I would like to have time series of a tower member load (Fx, Fy, Fz, Mx My Mz) for all the load cases.

I used the multiple plots option and used the option “tabulate graph data in” with a txt file.

The problem is that all time series are written in only one file (that become very big for the number of load cases). Is it possible to have them in separate txt files?

Solution

The easiest way to output selected loads data into text files for each load case is to use the "channel tabulation" option in the channel combination calculation (as shown inside the red circle below). When you have selected this option you can define the variables and load cases which you would like to consider by pressing the ‘channels and load cases’ button as shown in the blue circle above. Then you can define if you would like the outputs to be kept with the runs or put in a new directory (see green circle). If you choose that you would like a new directory for the outputs then you can define the path using the browse button.

When you run the simulation you will have the option of choosing the output style for the files, either ASCII or Binary format (see red circle below).

After the simulation has run you should find that the time series of the variables which you selected will be output in columns with one file for each load case.

Keywords

Post-processing; Channel tabulation

Problem

I would like to perform post-processing of ultimate loads following the IEC 61400-1 standard. For this kind of post-processing it is important to introduce sub groups in order to create the “mean of max” (or the “mean of top half”) of different time series belonging to one wind speed bin but differ in seeds.

Solution

It’s possible to name your simulations and folders in such a way that makes post-processing using the IEC sub groups easier.

Firstly, we suggest that you use folder names which correspond to the load cases which you would like to apply safety factors to. Each of these folders would contain the simulations which are associated with that load case. This would mean that you only have to create one group for each DLC to apply the safety factor.

Example folder structure:

Example set up in load case group window:

Then you should name your simulations so that the names are identical over all seeds which you would like to average over except for a number after the identifier (In the example above I’ve used – for the mean type sub group, and + for the mean of the top half group)

So, if you are simulating 6 wind seeds for one wind speed bin and you would like to average over these seeds you might name them as shown below. The simulations named eaa-1 to eaa-6 are all for the same wind speed bin (e.g. wind speed of 5 m/s), the only difference is the wind file used.

When all simulations are ready you can then add them the load cases window. The load case group should be automatically picked up and displayed and if you press the ‘update sub groups’ button then the sub group type will be populated.

Keywords

Post-processing; Ultimate loads; Sub groups

Problem

When running a post-processing calculation with a large number of load cases (usually in the thousands), Bladed can fail with "Program terminated unexpectedly" error message. This is caused by a memory limitation.

Solution

The way to solve this is to split up the post-processing run into subsets of load cases. This is fairly straightforward for most types of post-processing calculation but does present a problem for Rainflow cycle counting. This is because Bladed would not be able to provide meaningful values for the "Sum over lifetime" and "Damage equivalent loads" in these cases. You would then have to use Excel (for instance) to perform the last stage of the calculation outside Bladed. Download a worked example package guiding you through this process.

Keywords

Post-processing; Load cases; Termination

Problem

What is the algorithm for automatic sizing of bins in Rainflow and DEL calculations?

Solution

The description below is written with Rainflow in mind, but the algorithm equally applies to any other post-processing case where automatic bin sizing is requested.

Essentially what Bladed does is:

1. Find the maximum and minimum in the time series (or group of time series for multiple runs);
2. Find the range by subtracting the minimum value from the maximum in the time-series (or group of time series). A small tolerance (0.5%) is added to the minimum and maximum values(see note 1);
3. Calculate the width of the bin by dividing the range by the chosen number of bin. The bin width is rounded by the following rules(see note 2);
4. The same bin size is now used for the cycle range discretization. The first bin is centred at BinSize/2 and rest of the N bins are spaced by BinSize.

Note 1:

Please see this spreadsheet for an example of the algorithm.

Note 2:

The round rules will be applied to the calculated bin width. It may cause some unused bins as it is a "rough" bin width.

If the adjusted width is expressed in normalised scientific notation m × 10n where m is the significand and is greater or equal to 1 and less than 10, then:

1. If the significand is greater than 4.5 then the width is rounded up and given to 1 significant figure.
   For example, 0.004526 would be rounded to 0.005000 and 6132 would be rounded to 7000.
2. If the significand is less than 4.5 but more than 2.0 then the width is rounded up given to two significant figures such that the second digit is 0 or 5.
   For example 0.237 would be rounded to 0.25 and 367372 would be rounded to 400000.
3. Otherwise the width is rounded up to 2 significant figures.
   For example 0.01826 would be rounded to 0.019 and 12345 would be rounded to 13000.

Keywords

Rainflow; DEL; Damage equivalent load; RFCC, Binning; Bin

Problem

Bladed errors when a user attempts to post-process a Linux simulation using Bladed Windows GUI.

Solution

The cause of the issue is the difference between Linux and Windows line ends. Text files created on DOS/Windows machines have different line endings than files created on Unix/Linux. DOS uses carriage return and line feed ("\r\n") as a line ending, which Unix uses just line feed ("\n"). You need to be careful about transferring files between Windows machines and Unix machines to make sure the line endings are translated properly.

There are two ways to resolve this:

1. Use a utility such as unix2dos, notepad++ or similar to convert the files (or do a string replace), i.e. Linux to DOS would require replacing "\n" with "\r\n"
2. Set up the post-processing configuration (folder structure etc) in Bladed Windows and then copy in the results files

Keywords

Linux; Windows; Post-processing; Line end

Problem

In the Fatigue damage post-processing screen, there is an option to enter the S-N curve as a lookup table:

This does not actually work in currently supported versions of Bladed - the lookup values are ignored by the Bladed post-processor.

Solution

There is a fairly simple workaround for this.

First you need to get hold of the "DTSIGNAL.IN" file which is the input file to the calculation engine.

To do this you first need to enable the option “Warn when starting calculation” in Tools -> Preferences.

You then need to set up your fatigue post-processing calculation as if you were intending to run as a log-log relationship, not a lookup table. You will need to enter some values for inverse slope and intercept of S-N curve. Choose any numbers you like for these, as they will not actually be used. You also need to enter the correct number of bins. Then run your calculation using the “Execute Now” button on the Fatigue Damage post-processing screen. A “Starting calculation” info box will pop up (don’t click either "Start" or "Abort" at this stage). You should then navigate to the Bladed installation directory where you can find a folder with a name starting with $$$$ (similar to the one shown below).

If there is more than one of these folders, go to the newest one. In this folder you will find the DTSIGNAL.IN file. Edit the DTSIGNAL file as per the example in the screenshot below. Save it and then start the run. Your text editor may need elevated permissions to save it, as the file lives under "Program Files".

Keywords

Fatigue; Post-processing; S-N curve; Lookup table

Problem

In any post-processing calculation where we need to combine stationary and transient load cases: Transient cases are represented in occurrences/year while stationary cases may be expressed in hours/year. How to make these equivalent so that they can be combined into a single probability distribution with all cases weighted appropriately?

Solution

Taking the following simple setup as an example:

Convert the two stationary cases to occurrences/year, as follows. Suppose the simulation time for each of the stationary cases was 3 hours, then they are 1000 occurrences each, so you would get:

Total occurrences of all three cases = 1000 + 1000 + 55 = 2055 Weighting for 1st case = 1000/2055 Weighting for 2nd case = 1000/2055 Weighting for 3rd case = 55/2055

Once you have these weighting values, you'd use them to create a weighted sum of damage over lifetime (or to calculate lifetime-weighted damage-equivalent load) in the normal way.

Keywords

Rainflow; Post-Processing; Transient; Stationary