Morten

Hi Matt, The GUI version of the stand-alone program is available from http://www.wasp.dk/Products/WEng/IECTurbulenceSimulator.aspx (not *.htm) The command-line version is the oldest one, but we still offer it as an alternative because some people prefer to run multiple simulations from scripts. The reason why you cannot make "simEx1.inp" work is that you don't have a LINCOM output file (*.dat) feeding terrain effects to the simulation model. For this purpose I suggest to call the turbulence simulations from within WAsP Engineering. Detailed questions on the command-line version are best adressed directly to Jakob Mann, but please bear in mind that this model is now freeware and no longer covered by the WEng license. With best regards, Morten

Hi Christian, I hope WAT did not prevent you from saving your work. Anyway, the out-of-bounds index mentioned in the error message must refer to the list of recent projects files which WAT is keeping. I wonder whether this list works correctly on your computer, e.g. do you see a list under 'files| reopen projects' when you restart WAT? If so, has it reached its maximum capacity (which is 10). Perhaps it is best you answer by email to wengsupport@risoe.dk rather than using the WAsP Forum as I might ask for test data etc. With best regards, Morten

Note that WEng3 is a replacement of WEng2 and further development will be based on the new version. In my view the most important improvements are the redesigned extreme wind model and the ability to work with larger flow domains. But maybe read http://www.wasp.dk/Products/WEng/NewsInWeng3.aspx and judge for yourself. NB: If you want to generate input data for WAT with WEng3 then you will also need a WAsP10 license. With best regards, Morten

Hi Christian, For technical reasons WEng3 and WEng2 cannot coexist on a single PC. This is similar to a WAsP9/WAsP10 incompatibility. At the help desk we sometimes have to check problems specific for WEng2. For this purpose we use a virtual environment where all files in the WEng2 distribution is built into a single exe file. It works just fine. We have not yet discussed whether to offer this special tool to the users, but do contact us if you get an urgent need. With best regards, Morten

As part of a planed maintenance job our IT department stopped most systems including the web server. It will be shut for the weekend, but normal operation is expected on Monday (Feb 6, 2012). Sorry for the inconvenience.

Hi Hans Peter, It seems like I forgot a factor of 8/(r2^4-r1^4) in the solution. The EWEC 2009 paper was written in a hurry and later I copied the solution to the help file without checking. If you or anybody else would like to see the analytical solution, then send a mail to wengsupport@risoe.dtu.dk and I shall provide a Mathematica Notebook. Thanks for reporting this. I will correct the help for the coming WAT version 3.1. Regards, 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 an automatic 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.

The there dimensions of the Mann turbulence box will ususlly differ because you want to convert the longitudional direction to time via Taylor's frozen turbulence hypothesis. The two other directions should be large enough to model all turbulent eddies hitting the turbine rotor. Thus, lower wave numbers are included for the first velocity component. k is a 3D wave number vector (k1,k2,k3) spanning the wave number space corresonding to the physical space, and k is the length of that vector.

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.