Time-queryable WRGs can be at one or more heights. They are intended to consist of a variable number of special cases defined by time-queries plus one default overall annual average (a standard regular old non-time-queryable WRG). When we run a statistical energy capture using frequency tables, openWind will use the default annual average WRG. However, when we run time-series energy capture with one or more time-queryable WRGs then the speedups will be time and date dependent. This gives us the capability to make better use of our NWP model output, especially in cases where there are radically different speedup ratios across the site in summer/winter and/or day/night.
I just got the go ahead to show some modelling that we did recently for a client. Hopefully the video is self-explanatory but please feel welcome to post any questions you have below.
This is some of what has been keeping us busy over the summer. For a while, the WRB format has been capable of handling multi-hub-height WRGs but openWind has not supported this kind of compound object. With the next release this will all change. From now on all WRGs are time-queryable, multi-height objects with the standard single height annual WRG being merely a special case. This should allow us to simplify the setup of openWind workbooks considerably as well as allowing users to model wake effects of external projects with multiple hub-heights in an easy and convenient way. You can use one or more multi-height met masts to run adjust to masts on these objects and if they are time-queryable then the met mast data will be filtered by the same set of time-queries that are defined in the compound WRG. A lot to take in in one go I know but I will be posting more on this in the coming weeks and months. For now, here is a simple demo on how to start using the new functionality.
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: