Morten

The roughness rose will cover the same area as the user-supplied map out to a radial distance of 30 km. It replaces the detailed roughness patterns of the real map. The European Wind Atlas explains how the roughness values in the sector segments are calculated. As you learnt in the WAsP course, the provided map must include a margin around any site of interest equal to 100-150 times the hub or anemometer height. For each sector, the flow model assumes a wind profile based on the far-upwind reference surface roughness, and this basic profile is corrected by internal boundary layers. You can see this in the site view>site effects view. The roughness rose is still used inside the model, but the developers choosed to remove it from the WAsP 12 user interface. I sometimes miss it for pedagogical reasons.

Correct, all turbines' wake model parameters are uniform, but you can modify wake-decay parameters for individual sectors.

Your colleague is right. WAsP simplifies the detailed surface roughness map to a local polar map around each site of interest. We sometimes call this simplified map a roughness rose, and it has common roughness values within each sector and fewer roughness changes in the radial direction. The original roughness-simplification method is described in chapter 5 of European Wind Atlas - DTU Findit around page 81. The method may have been updated later, but the principle is the same. The maximum radius of the roughness rose is something like 30 km. We recommend that the map prepared by QGIS has a margin around any site of interest equal to 100-150 times the hub height or anemometer height.

Hi Gil, The WAsP wake model applies global parameters for the entire wind farm. Right-click the main turbine site group and click the 'Edit' button to modify them. You can use the observed wind climates for two masts if you arrange the WAsP project as in the attached screen dump. Here, I inserted two nested turbine groups as child objects to the wind farm and sorted the turbine sites for their most representative met mast. I inserted two wind climates, one for each mast, and attached the second wind climate to the second sub-group. In the screen dump, Turbine cluster A is modelled by Mast 1 while Turbine cluster B is modelled by Mast 2. The WAsP flow model may not cross-predict from one met-mast to another correctly, especially if the terrain is complex and RIX numbers differ. Furthermore, be aware of the risk of mistaking annual wind climate variations for spatial variations if the measurement periods of the two met masts differ. Regards, Morten

The standard way to generate an observed mean wind climate file is to use the WAsP Climate Analyst tool. By default, this program will export to the OMWC file format, but you can also select the old TAB file format. To write a TAB file without the Climate Analyst, you will need to check the format in the WAsP help file section Technical reference>WAsP file formats>Observed wind climate>Observed wind climate (*.tab)

I see a mail address in your profile and will use that for continued discussion.

The error message suggests a problem connecting to our database. I am not sure why but you could try again another time, from another Network or from another PC. I made a small demo to illustrate the process, see https://panopto.dtu.dk/Panopto/Pages/Viewer.aspx?id=a8c6d653-53b5-4bee-8208-b21700925271. Note that I insert a turbine site before downloading the GWC to help WAsP finding the location of the process.

We updated the wind climate models and the new model parameters are not supported by the old LIB file format. If you need a LIB file for a special purpose, you must recalculate the GWC without the new model options before you can export it to file. Follow this procedure: Right-click the GWC and select Show GWC from the popup menu. Open the Stability panel and select the old EWA profile model from the drop-down menu. Open the Geostrophic shear panel and hit the Turn off button Close the GWC and recalculate it Right-click the GWC and select the Export GWC to legacy format option from the popup menu. For WAsP calculations, we definitely recommend GWC calculations by the updated model and export to the new GWC file format. Maybe you can seek advice from the WindPro developers about the best workflow for their program. Best regards, Morten

The WAsP week 2024 is a three-days WAsP course followed by two days of workshops. You can learn about our ideas for workshop topics at WAsP Week 2024 open for registration, but we are open for your suggestions too. Do you have a topic, which you would like us to discuss in depth?

Hi Pablo, The Terrain analysis (CFD) window can optimize this mosaic to cover all turbines and met stations by a minimum number of 2x2 km tiles. As you say, this will normally not result in an area of a rectangular shape. WAsP allows you to generate one or several resource grids, and they may include areas with no CFD data. To see how this work, we can open the ParqueFicticio workspace, which is part of the WAsP sample data normally stored in ..\Documents\WAsP samples\WAsP 12\Wasp, import the associated CFD data and create a resource grid, which is larger than the area covered by CFD calculations as in the first screen dump below. If we export this to a WRG file, that file will include the grid nodes without CFD data and report zero in all result columns, see second screen dump. I do not know how Windfarmer will react to a WRG file containing lots of zeros. To learn about best practice for CFD results in Windfarmer, I suggest that you consult the Windfarmer documentation or ask for their guidance. Good luck with your project!

Hi Heather, The wind speedup and deflection script in WAsP Engineering provides a simple lookup table, which you can use to correct an observed time series observed at a reference point to the conditions at a turbine site and maybe another height above ground ground level. We made this script a long time ago supporting people who wanted to work with alternatives to the annual-maximum method, which in those days was the only extreme-wind estimation method in WEng. In principle, you could correct your time series by the lookup table of the WEng speedup and deflection script and use it for other purposes, but be aware that the WEng flow models focus on extreme wind conditions and does not include stability corrections. The built-in standard model of WAsP (IBZ) and WAsP-CFD are more suited for prediction of energy production. When correcting a time series by these models, you must consider possible differences in upwind flow profiles and apply the geostrophic drag law. As mentioned above by Rogier.

Hi Kwak, The error handling in WAsP software is implemented by try…except statements, see this site for explanation of the concept. When the computer is asked to do something impossible, it stops execution and raises an exception which the program can react to. There is also a basic message like “divide by zero”. A programmer which foresees all problems and spend sufficient time on error handling, might add comments like “Undefined hub height of Turbine no. 001”. However, most subroutines in the programs just raise a new exception and append more information about where the problem occurred. Subroutines can call each other in a long chain, so you often see a complicated message in the final report including information from all nested sub-routines. It is not particularly helpful for the end user, but it explains the fundamental error type, approximately where in the program the first exception was raised, and the last action in the user interface. Still it may not always enough to diagnose the problem, so we often ask for additional information like A test project file reproducing the problem A description of what you were trying to do, maybe supplemented by screen dumps A WAsP installation report You can save time if you include such information already the first time you contact WAsP support.

The two most common problems with the SCM tool are The SCM server providing the long-term reference data might be down. However, I just checked and it worked OK this afternoon. If the coordinates of the reference mast or the map projection are incorrect, the SCM server might not find the data, e.g. it if the false position is in the middle of an ocean. The easiest way to check the mast location is to open a spatial view, synchronize with Google Earth (see below), and make sure that the map is displayed correctly on the virtual world. If these simple explanations does not apply, then please contact our technical support system via mail. The above error message might be enough for the programmer to understand the issue, but please also describe your actions just before the error message arrived. Screen dumps and a sample project file demonstrating the problem are also useful and sometimes even necessary. In general, it is usually better to contact the support system about specific technical problems and reserve this forum for discussions of interest to all users.

I was testing my above method and need to correct myself. It seems like the map editor does not save information about the adjusted map size to file. so I guess thise merely was intended as a way to enlarge the 'canvas' while 'painting' roughness-change lines and elevation contours manually. In most cases you can use the methods inside WAsP and WAsP Engineering as described in my post above, but not for the Prepare data for WAT tool inside WAsP Engineering. The trouble is that this tool will ask you for a WAsP vector map file and then do some WAsP calculations for mean wind climates. As you can imagine, this can fail if the map does not include an offshore wind farm. A work-around method is to open the map in the map editor adjust the map size to include the wind farm create a dummy roughness line as a polygon surrounding the offshore wind farm specify water surface roughness both inside and outside that polygon. Load the map with the amended map into the Prepare data for WAT tool and its WAsP calculations should work without problems.

The map editor limits the map domain as you describe, because it does not know for sure how far the water surfaces extends into the unknown. However, you can select Edit> Adjust map domain size in the main menu of the Map Editor main window (not the Map display window) and extend the map domain size manually. As an alternative, you can extend the map from inside WAsP. For this you right-click the vector map in the object hierarchy and select Change Extend of map from the popup menu. The domain editor of WAsP Engineering program generates a grid map based on your vector map. For coastal or offshore sites, we sometimes need to extend that map in the offshore direction. For this you first zoom out the displayed vector map and then you can select a grid map with more extend in the offshore direction. The zoom button in the WAsP Engineering domain editor window is the second one next to the line with the name of the vector map, see below.

... I saw, your second post. I am not sure what happened, but this error is probably related to the first one, and difficult to reproduce in the latter session.

Hi Rainer, Thank you for reporting this. I assume that you are using the new WAT 4.7, and I also used this for testing. Your method is correct, and I don’t think you misunderstood anything. I can reproduce the first reported problem, where the map is placed outside the project tree. Furthermore, WAT gives error messages when I try to move it or delete it. This is clearly wrong and something which needs fixing. You wonder whether the error affects the results. The terrain elevation data are used for evaluation of terrain complexity and thereby the Cct factors and turbulence results. If the map is missing WAT will use the maximum Cct factor of 1.15. In my test, the misplaced map object does not affect the results at first, but when I select new turbine sites, WAT found the map object even though it was misplaced. Maybe you can use this as a temporary work-around, while waiting for an amended WAT version. To check the Cct used for the turbulence calculations you can look at Reports for selected turbine> Terrain complexity. I do not fully understand the second reported problem where you imported two sets of WAsP/WEng data and observed NaN values for effective turbulence results. Most likely the data were not imported correctly, but I you like me to check, then please send the resulting WAT project as an attachment of a mail to waspsupport@dtu.dk. You do not need to explain much, just refer to this discussion thread. Cheers, Morten

Mert sent us some WindPro and WAsP project files demonstrating these wake loss difference. Thanks for this, it is always easier to discuss possible problems when we have test data! My former DTU colleague Tobias Ahsbahs, now working for the WindPro developers at EMD, spotted that the Ct curve used in WAsP project was much lower that the Ct curve in the WindPro project. We all agreed that this must be the reason for the different wake loss predictions.

We rewrote the homepage, so the WAT AEP link is changed to https://www.wasp.dk/software/windfarm-assessment-tool/wataep. It does not explain that much about the models, but I once made some videos about this for DTU students The latest WAT version enhanced the AEP model with an option for different uncertainties and technical losses for individual turbine groups, see Windfarm Assessment Tool version 4.7 released - WAsP

Hi Mert, The implementation of the wake models in WAsP and WindPro are independent, so it is quite possible that the programmers made different choices. I made a third implementation in WAT and compared it with WAsP. The agreement was reasonable in flat terrain, but the differences were larger than expected in complex terrain. This must be because I handled speedup and deflection between the wind at the wake-shedding and wake-exposed turbine sites differently. Other reasons for model deviations could be the number of calculated wind directions within each wind sector the interpolation in the power and thrust-coefficient curves when looking up data for a speed-up corrected wind speed - especially near the cut-in wind speed possible air-density correction of the thrust-coefficient curve in WindPro? - we decided to ignore this in WAsP and WAT So you see, even though the PARK 2 model is really simple, there are undocumented details, which programmers might handle differently. Kind regards, Morten

I wonder whether Jins and Johnathan is the same person? Anyway, it is best to discuss technical issues like this via WAsP - Support.

The short answer is no - WAsP does not present local wind climates in this form. WAsP prefers to use a Weibull distribution and frequency of occurrence for each sector. It is relatively easy to calculate bin frequencies from the Weibull parameters and I can send you the formula, if you like. WAsP wind statistics are available in the turbine site view - right-click the site and select show> wind for an example. It is also available in various reports and tools> utility scripts. Try to find a report or script which suits you - e.g. tools> utility scripts> custom windfarm output file - but beware that the precision (number of digits) often is less than ideal. If you need these matrices in a specific format for many projects, you may want a programed solution. There are several options: Get a PyWAsP license, see WAsP - PyWAsP. Create your own utility script. This requires visual basic programming skills and the typecasting can be tricky. It is usually better to tweak an existing script than to start from scratch. Read the data from the WAsP workspace file. This is actual a zip folder containing a file called inventory.xml, which has objects called <PredictedWindClimate>. Please note that the workspace file must be saved in a state where all calculations are valid.

I am not sure, but this might have something to do with the map projection. More details in my answer in the WAsP support system.

I read your post via Google translate. I suggest that you start by checking the wind resource at your site via Global Wind Atlas. If this is promising, then contact a local wind energy consultant in Turkey. Maybe (3) Ferhat Bingöl | LinkedIn, who is a professor at Izmir Institute of Technology, can guide you in the right direction.

AEP losses in WAT production result tables include wake effects and additional technical losses selected in the check-box list under the object hierarchy on the left-hand side of the WAT GUI. The best way to detect the effects of specific technical losses is to compare result tables for different selections of technical losses. Doing so, you will discover that loss components do not add completely linearly. That is why they are not reported separately in WAT. In complex terrain, the background turbulence for individual turbine sites is multiplied by individual Cct factors and the IEC standard tells us to use the same factor for all directions. However, the effect on wake turbulence from neighboring turbines is different, so the effective TI will not be quite proportional to the Cct factor.