Morten

Both the WindPro and WAsP programs use the file extension *.wtg for files with Wind Turbine Generator information. Unfortunately they are not the same. The WAsP WTG file is in XML format whereas the WindPro WTG is binary and usualy longer. You can open the WindPro WTG file with the WindPro program and read the information, but I don't think there is a way to convert it to WAsP format. A few turbine manufactures have supplied ready-made WAsP WTG files for download at www.WAsP.dk/download/powercurves.aspx. If you cannot find data for your chosen turbine, or in the later stages of your project when precise information is a must, you have to contact the manufacturer.

Both the WindPro and WAsP programs use the file extension *.wtg for files with Wind Turbine Generator information. Unfortunately they are not the same. The WAsP WTG file is in XML format whereas the WindPro WTG is binary and usualy longer. You can open the WindPro WTG file with the WindPro program and read the information, but I don't think there is a way to concert it to WAsP format. A few turbine manufactures have supplied ready-made WAsP WTG files for download at www.WAsP.dk/download/powercurves.aspx. If you cannot find the data for your chosen turbine, or if you want to make absolutely sure that you have the correct information, you have to contact the manufacturer.

Dear Francesco, We rarely distribute source code, though you could contact Jakob Mann and ask if he is willing to make an exception for you. But unless you have ideas for extending the model in an interesting way, I doubt that this is a clever way to spend yours and Jakobs limited time. The model is kind of complex and to make it really useful you should link it to flow model results. Read the following two papers and judge for your self: J Mann (1998) Wind field simulation, Prob. Eng. Mech.13, 269-282 J Mann (2000) The spectral velocity tensor in moderately complex terrain, J. Wind Eng. Ind. Aerodyn. 94, 581–602 You say that you have implemented Veers' model. The following paper might be of interest for your study: M Nielsen, G C Larsen, K S Hansen (2007) Simulation of inhomogeneous, non-stationary and non-Gaussian turbulent winds, available at http://iopscience.iop.org/1742-6596/75/1/012060 Regards, Morten

Hi Siniša, You ask whether it is most correct to separate the extreme wind analysis of a mixed extreme wind climate. Normally this is unnecessary but there are exceptions, see e.g. the paper by L. Gomes, B.J. Vickery (1978) “Extreme wind speeds in mixed wind climates” in Journal of Wind Engineering and Industrial Aerodynamics, Volume 2, Issue 4, January 1978, Pages 331-344. These authors investigated extreme winds in cities on the East coast of Australia. The extreme-wind climate to the North was dominated by tropical cyclones and the extreme winds to the South was dominated by mid-latitude storms. Tropical storms are extremely violent but very rare, which means that their Gumbel fit tend to be steeper than for mid-latitude storms. The key question is which Gumbel distribution dominates at the fifty years recurrence time? Gomes and Vickery were able to separate the two phenomena by looking at synoptic pressure data maps. After individual Gumbel analysis of both phenomena, it seemed that half way up the coast, at Brisbane, both kinds of storms influenced the fifty-year wind estimate. Put in another way: If you are measuring at a coastal topical site for say four years you might never observe a tropical cyclone/typhoon/hurricane, because the extreme wind field is too small to frequently pass the site. But it is very dangerous to ignore the phenomena for the U50 estimate. I am not too familiar with your Bora and Jugo winds. What you might try is to separate the phenomena and do independent Gumbel analyses to test whether the Gumbel slope parameters are significantly different. I am not sure how you can use Climate Analyst for this. Just dividing into sectors is probably not enough. You need to evaluate the meteorological situations. I mean the Bora is a kind of Katabitic wind (right?) so you should test whether there actually is a baroclinic contribution to each suspected Bora wind. Cheers, Morten

Turbine manufactures are more than welcome to submit power curves to Risø DTU for presentation at http://risoe.dtu.dk/WAsP/Download/PowerCurves.aspx Not every manufacture has chosen to do so yet, but there are additional links to manufactures information centres at the bottom of the page. Try to click on the 'Siemens' link and you will soon find a brochure on the SWT 2.3-133 turbine including the address of the Siemens Customer Support Centre. Before you contact the support centre, it might be a good idea to calculate the average air density at the site of turbine deployment with the WAsP air density calculator. Remember to ask both for power- and thrust-coefficient curves. Finally you format the turbine information with the WAsP Turbine editor and then you are ready for WAsP work.

Dear Cristi, WAsP is designed to take data from one level and make predictions at another one using its built-in flow model. Power-law extrapolation based on profile measurements may produce realistic results, e.g. when orography and roughness changes are insignificant. However, it is not our recommended general-purpose method. We prefer to let WAsP do the extrapolation.

Hans Peter and I have discussed this at technical support. Scripts activating both the flow- and turbulence-model for many turbines/sectors/heights can run into different types of problems. When the calculation simply no longer progress, the usual reason is the turbulence model having difficulties with integrals involving velocity gradients upwind of the site, see equations 14 and 17 in the paper by Jakob Mann, Journal of Wind Engineering and Industrial Aerodynamics, vol. 88 (2000) p. 153-169. That turbulence-model problem could be provoked by a faulty flow solution, which in turn could be caused by problems related to the elevation or roughness map. So, if anyone runs into problems like this, it a good idea to inspect the flow and velocity gradients in the field view for the direction causing problems. Look out for strange velocities directly upwind of the site giving problems. There is also a memory limitation, like HPJ suggests. WEng attempts to store about 20 different 2D fields with various flow properties in memory, and it is doing so for all the wind directions you calculate in a session. WEng is a Win 32bit program, which means that it can only work with 1½ GB memory, and thus the limitations of about 512x512 sized grids for twelve directions. Our main programmer, Duncan, made an experimental version, where flow solutions were stored as temporary files. With this we could work with 1024x1024 sized domains and have as many of them as we liked in a session. The file operations did not slow down the program significantly. The plan it to provide this feature for the users later. I should say that by 512x512 sized grid, I mean grids including a buffer zone, which WEng adds to the specified domain in order to work with FFT and thereby with cyclic boundary conditions. If you want a 15% buffer zone you should specify something like 460x460 grid points in the domain editor.

Sarah submitted her data to wengsupport@risoe.dtu.dk The unrealistic Weibull distributions in the interpolated wind atlas occurred in a sector with very low wind speed and frequency of occurrence, so the error would probably not disturb WAsP predictions much. It was possible to work with the interpolated Wind Atlas in WAsP itself, but Sarah had a problem using it in Windfarmer (WF). I suspect WF simply rejects very strange Weibull distributions. I suggested a crude correction for Sarah, but I do not yet know whether it worked, so I will skip it from this reply. The explanation for the strange interpolation results lies in the LibInt method, which is to 1) calculate first and third moments of wind speed in each sector by reference station A and k values 2) make a directional interpolation of frequency and wind speed moments 3) find A and k values matching the interpolated wind speed moments The k values at the site of interpolation are bounded by kmin=0.5 and kmax=40 and a problem may occur if the interpolated third order moment is incompatible with the interpolated first-order moment. In this case the solution will be impossible or clearly out of range, so LibInt sets the k value to the nearest default boundary value and reports an A values matching this and the mean wind speed. Finally, a little warning about LibInt taken from the help file: “The method is just a mathematical interpolation unrelated to physics and it is difficult to describe its credibility in an objective manner. However, I suggest that the following questions are checked: • Are the data from the reference sites measured with similar equipment? • Are measurement periods and sample intervals comparable? • Are the WAsP RIX numbers of the reference sites comparable? • Are the wind atlases of the reference sites comparable? • Are other climates parameters, e.g. temperature, humidity, and height above sea level, comparable? • Finally, are the conditions at the new site expected to be comparable to conditions at the reference sites? Obviously, it is a good thing if you truly can ask YES to all these questions. Unfortunately, we have no guidelines as to how much you could violate the ideal conditions.” Sarah’s data seemed to be of good quality and the terrain was not complicated. But the observation periods for the reference wind atlases did not match and two of these did not even overlap. The frequency for the sector giving trouble was only 3%, so the corresponding Weibull distribution may not represent the long-term distribution well, even for a two-year observation period. This is probably what causes the problems for the interpolation.

This is a fairly usual problem, which can have several explanations. Try to read the guidelines at http://www.wasp.dk/Support/FAQ/WENGmaps.html and, if that does not help, then please mail wengsupport@risoe.dk with the problematic map as attachment.

Hi Christian, It is always wise to make this kind of tests, and I fully agree that it is strange that representative TI (IEC 61400-1 Ed.3) results are higher that the characteristic TI (Ed.2) when wake effects are turned off. However, this is actually what you get from WAT with turbulence category A wind turbine classes. I shall explain why. As a model for background turbulence WAT simply adapts the IEC NTM turbulence model and adjust it by an offset to make it match WEng TI predictions at high wind speeds. The reason for your strange results is simply that IEC 61400-1 (Ed.2) specifies a different wind speed dependence for category A turbulence. If you have edition 2 of the standard at hand, you can see that the so-called slope parameter in the formula of paragraph 6.3.1.3 is a=2 for category A and a=3 is for category B turbulence. In Edition 3 the NTM model is written differently, but you can detect that it corresponds to a=3 for all categories. My current feeling is that the IEC NTM model is too conservative in most cases. As a supplement the coming WAT 3.0 will offer use of observed turbulence statistics. You could also claim that WEng ought to model these variations in turbulence intensity. These variations are typically caused by variable atmospheric stability and trends in the mean wind signal, so WEng both need improvements in its flow and turbulence models and a new statistical weighting between different stability conditions. All very difficult I think, but we actually have a Ph.D. student working on stability effects on the turbulence model. Cheers, Morten

Users with similar problems might like to read the explanation we found for Server after contacting WEngSupport: WAT2Launcher tries to extract a grid map around the turbine sites, which extends 25 time the hub height from any turbine site or approximately 2.5 km in this project. The likely reason for the script failure is that turbines are less than 1 km from the edge of the project map, so it is not possible for the script to extract the data needed for the terrain assessments in WAT. If you don’t care about terrain corrections, you could try to work with WAT2Excel instead. It would however be best if you could find a better map for your WEng project. Read more about maps in WEng at http://www.wasp.dk/Support/FAQ/WENGmaps.html

The wind distribution in WAsP is modelled by a statistical model based on 2-parameter Weibull distributions for each wind sector. You can fit Weibull distributions by many methods matching different properties. The WAsP fitting method matches two properties 1) the mean of the cube of the wind speed 2) the probability of winds higher than the empirical mean wind. If you compare with histograms for individual sectors, you will often see a very good fit to the upper part of the distribution and some deviation at low wind speeds. This is intentional as accuracy is most critical in the range of turbine operation. The mean is however not always accurately reproduced if the observed data does not follow an exact Weibull distribution. This may not be a problem but you should check whether you have measured long enough or whether there is an unusual wind phenomenon at your site which could significantly disturb the Weibull fits (in the range of turbine operation). Read more about this at these two pages: www.wasp.dk/Support/FAQ/WindDistributions.html www.wasp.dk/Support/FAQ/EmergentExample.html

Hi Tim, Try to right-click on a wind farm in the object hierarchy and then select 'reports| wind farm report'. RIX numbers will be included in a table called 'Site wind climates' in the resulting report. In WAsP 10 this table will even include Delta-RIX numbers, which are defined relative to the met. station of your reference wind atlas - at least if this station is included in the WAsP project, i.e. that the wind atlas is not imported from a pre-calculated file.

An observed extreme wind climate (OEWC) represents wind conditions at the site of observation. You can use it as input to WEng and predict extreme wind climates at turbine sites within the same flow model domain as the reference site. An OEWC may be transformed to a regional extreme wind climate (REWC), which applies to a standard height of 10 m above ideal flat terrain with a uniform surface roughness of 5 cm. Site-specific effects are removed from the REWC and we are left with conditions representative for a larger region. The extend of that region could be something like 100x100 km as long as you are sure that the overall wind climate is the same as at the site of observation. The REWC is typically saved on file and may be used in other WEng projects modelling wind conditions far from the site of observation. A REWC is equivalent to a WAsP wind atlas (LIB file) and the conversion to and from the REWC also relies on the wind atlas method. OEWC and REWC files does not contain turbulence information, but some of the WEng scripts calculating turbulence for several directions applies these files as input, mainly as a way to iterate over different winds. In most projects the WEng turbulence intensity is independent of wind speed, because WEng only predict turbulence for neutral atmospheric stability. The exception is offshore projects where wariable surface roughness over water induces a wind-speed dependence.

'New gridding' or 'Triangulation' refer to the same method, and it is documented in www.risoe.dtu.dk/rispubl/reports/ris-r-1564.pdf The interpolated terrain model generally becomes smoother with the new method and therefore it should lead to better flow modelling. The code is however not completely stable, and this is why we maintain the old method as an option. The coming WEng3 will be able to import a Cartesian grid directly without interpolation from a WAsP contour map. We hope that this will ease the work for users who already have terrain data in grid format. Furthermore, the accuracy should improve if we avoid interpolating to contours and back to grid format.

...I have just fixed the above link

Hi Hans Peter, We reorganised the domain editor a little, so now you have to set a check the option called 'use new gridding method' to use the triangulation method.

These errors are probably related. Good you also found the error related to the length scale. This will make it easier for me to motivate the programmers.

Hi Emil, The Alpha parameter, which refer to the group Alpha*Epsilon^(2/3) in the articles of Jakob Mann, is a spectral energy scale. So increasing this parameter with a factor of 10 should increase the velocity perturbations in your time series by a factor of sqrt(10). The turbulence simulator is a windows wrapper around Jakob’s software and I think the mistake is in this software layer. The convention of the FLEX format is to normalise data so here you should actually not see a difference – although I find it strange that the turbulence simulator can produce results when I set Alpha=-1. Something funny is going on here. I am not a HAWC user but I have the HAWC2 manual. By default HAWC2 calls a DLL of Jakob Mann to produce turbulence files and conveniently take care of the file bookkeeping. However you can also use Mann files created by the Turbulence Simulator or from inside WEng, where you can include terrain and roughness-change effects on the turbulence. In either case the HAWC2 user also specifies a turbulence intensity and I am 99% sure that this implies a rescaling of the turbulence simulations. So you would see no effect of changing the alpha parameter in the ‘Turbulence simulator’. The reason why load simulation programs like FLEX and HAWC2 wants to scale the time series is that the variance of simulated time series is random and will vary among realisations. With rescaling you avoid that kind of variability.

WEng estimates the shear exponent from calculations at just one height. The flow is modelled in Fourier space, so a convenient way to calculate fields of velocity gradients is to multiplying wave numbers with wave vectors and then do inverse FFT. You can get the full matrix of velocity gradients - from dU/dx to dW/dz - in this way. Having found the velocity and velocity gradient fields, WEng is able to extract velocities and vertical gradients at any site and estimate shear parameters by the formula alpha=dU/dz*z/U Here, the gradient and velocity corresponds to the selected height. This alpha exponent is a good fit near the selected height. However, if the real profile is not an exact power law you will get slightly different alpha values if you select other calculation heights.

WAsP 8.4 is OK, but I think your WAT scripts are out of date, please download the latest WAT 2.5 install package. Then check that you are able to run either WAT2Excel or WAT2Launcher. If not, then please report to wengsupport@risoe.dk. When the software is installed correctly you can find a little guidance in the start of the section called 'working with WAT' at http://www.wasp.dk/Products/wat/WAThelp/

As you probably suspect, this problem is related to program versions. However, the WAT2Excel script is not distributed with WEng, but with WAT. Please go to http://www.wasp.dk/Download/Software.html and download WAT version 2.5.0.125

There can be several reasons for a strange extreme-wind estimate. I would start by checking the input data in the input OEWC or REWC files. If you analysed your data by the WACA program they should include an uncertainty estimate, and a record of yearly extreme winds observations. Check that these are OK. In case of trouble you may have to check the data used to produce the OEWC file. Older files may not include this information, but you can assume that when an alpha parameter is very large >>1, the Gumbel fits will have high uncertainty.

The WEng extreme-wind estimates depend on terrain-induces speed-up factors, which are calculated by the flow model. Using a too low resolution will typically result in too little terrain speed-up factors. Setting up a terrain model in WEng is a compromise between grid resolution and domain size with restrictions imposed by the available computer memory. Read more about this at http://www.wasp.dk/Support/FAQ/WENGmaps.html

WEng is working with terrain data in grid format and therefore needs to convert the WAsP contour map to grid format before calculate anything. We have two alternative methods for this and they can both fail. This is the most common user problem with WEng. There can be several possible reasons: First, you have to use ASCII format. There could also be a small map inconsistency, which did not disturb your WAsP project, but makes one or both WEng map conversions routines crash. I must also admit that sometimes we see problems even with seemingly perfect maps. Best advice is first to check with the WAsP Map Editor, maybe try the alternative WEng Map conversion routine, and if you still have problems, then mail the map to wengsupport@risoe.dk plus a screen dump showing the grid coordinate and resolution settings just before the crash.