Hello, sorry I haven’t posted anything in a while. I have been buried in the depths of openWind code, reworking it to allow a whole stack of new modelling functionality which I hope to be able to show you soon. In the meantime, here is a fun and worthwhile project we just completed to allow openWind to calculate terrain complexity and for us to be able to see exactly what it did in order to get there.
In order to get the most out of the video below I recommend going to full screen and clicking on the HD button.
We have been busy working with industry partners to improve and validate our optimisation for cost of energy functionality and the cost model in particular. The following video shows some of the new functionality that we are planning to release before the beginning of July.
If you’re heading to Las Vegas for WINDPOWER 2014, why not take an extra day and spend an afternoon looking at some of the more advanced functionality in openWind.
Click here to visit the registration page
Although shadow flicker analyses are necessarily done as a time-series, because we have to consider every minute of at least one year, originally we coded up mitigating factors as probabilistic terms. Factors that can reduce or mitigate shadow flicker are:
- cloudy skies – if the sun isn’t visible then there wont be strong shadows;
- turbine orientation which varies with wind direction;
- turbine cut-in and cut-out speed;
- turbine curtailment.
The problem with using probabilistic estimates of shadow flicker mitigation is that they don’t really make sense when displayed as a chart or in a calendar format as the mitigating factor is effectively flickering on and off randomly from minute to minute. This is why we report lower numbers in terms of shadow flicker minutes but still show the worst case scenario in the chart and calendar report.
In the latest versions of openWind, it is now possible to use the met data and turbine scheduling to inform items 2 to 4 above. We also have provided an interface through which you can enter hourly clear skies information. For each hour you can enter a 1 for clear skies (when shadow flicker can happen if the sun is above the horizon) and 0 for cloudy skies.
The use of met data means you need to set the year in the shadow flicker settings to a year for which you have met data. If you don’t have a neat calendar year then openWind will look for consecutive data from adjacent years.
In terms of the clear skies field, this requires the user to interpret solar insolation data in whatever way you think makes most sense.
The video below shows how inclusion of wind speed and direction data can affect the shadow flicker assessment.
Turbulence intensity, in the form of the standard deviation of the wind speed over the measurement period, can impact turbine performance.
In general, TI can be thought of as a standard distribution of wind speeds around the ten minute mean
At the lower end or ankle of the power curve, deviations above the mean give more energy than deviations below the mean lose.
At the upper end or knee of the power curve then deviations above the mean do not compensate for deviations below.
Now some level of TI is assumed in the power curve supplied by the manufacturer. More TI than this assumed level will result in more power at the ankle and less power around the knee.
Less TI than the assumed level will result in the opposite.
This complicated only slightly by whether the turbine manufacturer specifies a power curve at 10% TI to mean 10% across all wind speeds or whether they mean 10% TI at 15m/s and assuming a normal turbulence model as described in the IEC standard
At present openWind has two ways of dealing with the effects of TI on energy production:
1) Is to switch between power curves defined by the manufacturer at different TI values
2) Is to modify the given power curve according to the consensus method of the power curve working group.
The following video shows the basic functionality from a user perspective:
The notion of rotor equivalent wind speed attempts to address cases in which the shear across the rotor disk is non-standard. Non-standard can include cases of very high or negative shear but the effects of non-standard shear are most pronounced when there is a significant change in shear between the upper and lower portions of the rotor disk.
Standard power curves assume a constant moderate shear across the entire rotor disk. The implicit shear exponent can generally be assumed to be around 0.2. Clearly, if in reality, the shear relaxes above hub height, then it is easy to appreciate that there is less energy in the wind impacting the rotor disk than has been assumed in the power curve.
In order to assess the impact of the difference between the assumed and actual shear profiles across the rotor disk, we use the following method:
- Split the rotor up into a number of horizontal slices which can be determined by the user (>14 is recommended)
- Calculate the area and centre height for each slice
- Calculate a profile based on the wind speed at hub height and a constant shear of 0.2 say so that we have velocities at the centre of each slice
- Query the met mast multi-height data so that we have velocities at the centre of each slice
- For both the sheared and measured profile, take the fractional area of each slice and multiply it by the wind speed at the centre of that slice cubed and sum them before taking the cube root
- Call these numbers Vshear and Vdata
- The rotor equivalent wind speed is then the hub height wind speed multiplied by the ratio Vdata/Vshear
For instance, if we assume that the most standard shear case would fit an exponent of 0.2 from the bottom to the top of the rotor disk, changing the shear to 0.1 would result in a difference of less than 0.03% in rotor equivalent wind speed. Changing the shear from 0.2 to 0.4 would result in a difference of 0.4%. However, keeping the top of bottom half of the rotor at 0.2 and changing the shear over the other half of the rotor would result in a change of around 2%.
The video below shows some examples of shear profiles that are not well represented by the standard single hub-height wind speed value.
So we finally pushed out a new version with multi-height met masts and a version of TI adjustment that we’re relatively happy with. The biggest upset to the code was definitely the multi-height met mast and this was the main reason behind no updates for the second half of last year. However, the benefits from this change already include time-series rotor equivalent wind speed estimation and more benefits should continue to accrue over the coming year.
The multi-height met mast has the following format:
The wind speed, direction, temperature, density and TI fields are repeated for each height with just one date stamp and one Monin-Obukhov value per record. This means that we can have a vertical profile for each ten-minute interval and then use these profiles to adjust for the actual energy in the wind. It may also be practical to extract stability information from these profiles.
Within openWind, the met mast layer properties have been expanded to allow in place editing of the time-series data as well as copy and paste. In order to allow the fast display of such huge datasets, we had to rework the underlying interface which has resulted in some changes in the way it works. The new Copy is now all data for either all or just one level. Paste works the same as before. In addition to these we have the ability to add, remove and change levels as shown in the video below.
At present, unless the user specifically shears a new level, data is linearly interpolated between met levels. This is simply a performance issue and might change depending on the application in future.