Mark Kelly

Hi Feng, as Bjarke mentioned you can use pyWake; there is an example for yaw-misalignment in pyWake's web-documentation (which you can also run from the webpage via Colab). It employs Fuga within pyWake, and basically just models using the cosine of the misalignment-angle. with kind regards, --Mark Kelly, Assoc.Prof. @DTU / WAsP sci.-dev. team

Hi Lakshmi, If you search the WAsP-forum (for e.g. "rsf"), you may find topic 437: There, it is written that: Are you able to get a wind farm calculation result, and right-click on the wind farm to do this only after the result is calculated successfully? With kind regards, --Dr. Mark Kelly, Wind Energy Dept., Danish Tech. University [DTU]

Hi Gururaj, indeed this works in earlier MapEditor versions, but there seems to be a glitch in importing orographic grid-maps. What is the exact error you get, when importing using "orographic grid-maps"? with kind regards, --Mark Kelly, DTU Wind Energy Dept.

Hello, that "rule of thumb" was intended to simply ensure that for WAsP calculations there is adequate resolution of the terrain. It is merely stating that for increasing distances farther away from the site(s) of interest, the vertical resolution of the terrain elevation data becomes less crucial (not as fine resolution needed at distances >4-5km away from the site). Although one could draw contours in Map Editor in order to make the vertical resolution finer in the region of interest, doing such "manual interpolation" can be time consuming (and is typically not recommended, unless the engineer decides they can do this reasonably and quickly enough). There are numerous sources for maps, and other map-processing utilities (e.g. qGIS, Surfer, etc.) which may be used to do operations which produce vertical interpolation or height contours or pixels. Nowadays most digital elevation maps have resolutions fine enough (∆z<10m). with kind regards, --Mark Kelly, Assoc. Prof., Wind Energy Dept., Danish Technical University

Hello Inés, for vertical extrapolation in resource assessment, to use only 3 months of lidar to "help" can be quite tricky due to the seasonality (depending on the site). A first step is to get an idea of how much the shear exponent between 80m and 120m varies throughout a typical year, and by sector. It appears you may only have measurements at 40m and 80m heights, so you can start by checking how much that varies. If the prediction location is over non-flat/inhomogeneous terrain, then of course the alpha may change quite a bit from 80 to 120m compared to 40-80m, and vary by sector. You can at least check how the mast's alpha looks during those 3 months, and then evaluate how much variation there is over 12 months compared to those 3, considering also the sector-wise (directional) aspect. I made a M.Sci. project a few years back, where the student (Niels Waars) looked at using MCP on alpha, for just this situation. Within the context of that work, the trick is to "guess" alpha for the other 9 months in your case, if you know the long-term distribution of alpha. We looked at uncertainty in doing this per length of lidar campaign (Link to M.Sci. project at DTU, thesis link is there.) I can upload the thesis if you're not able to download it from the link. with kind regards / saludos / med venlig hilsen, --Mark

Hello Andrés, I should first note that WAsP does not use a shear exponent for vertical extrapolation. Rather, it uses geostrophically-perturbed similarity theory (i.e. roughness-based with 2 stability parameters, also an adjustment for the upper atmospheric boundary layer). The WAsP method does vertical extrapolation for both the Weibull-A and k parameters, which are linked; it is not a "wind profile" per se. It is not designed for shear. However, if you like, you could simply output the speed (or Weibull-A) at 2 heights, and then calculate the shear using alpha = ln(U_2/U_1)/ln(z_2/z_1) . Indeed it is dependent on roughness and height, as well as e.g. the offset heat flux parameter; the above expression/method is much simpler than trying to use the complicated equation which results from the theory. with kind regards, --Mark Kelly, DTU Wind Energy

Hi Stefan, it looks like perhaps the number of heights is having a mismatch, but we can't be sure without seeing the data. Have you used the script successfully with other data (or previously with this same data)? I'd recommend sending an email to WAsP-support, to also get the case in our system there.

Hi Furkan, you would need to look at the GlobalMapper documentation.

Hi Furkan, are you sure that the GlobalMapper output is a WAsP .map file?

If you wish to see the effect of the terrain, you need to use MapEditor to make a map. It facilitates download of SRTM elevation data for most of the world, and can also import various data formats from e.g. GlobalMapper. Note you will also need to digitize roughness-change contours, which are not typically given. You can try e.g. the CORINE dataset, or use the Google-Earth image (overlaid) to guide you in digitizing roughness-change contours. With kind regards, --Dr. Mark Kelly Wind Energy Dept., Danish Technical University for WAsP support

Hello Roella, You can use the power curve values from the Turbine Editor to calculate AEP, if you enter the Weibull parameters (use 'Tab' after entering each) appropriate for the wind "seen" by the turbine. However, if you do this, then you will be neglecting all of the incoming surface-induced flow perturbations—as well as ignoring variations of the Weibull parameters per sector. With kind regards, --Dr. Mark Kelly, Wind Energy Department, Risø Lab/Campus, Danish Tech. University

Hello Victoria, this sounds like a WindPRO DLL problem, though we will respond further via WAsP-technical help.

Hi Ysga, basically if your values of z_0 are all reasonable, and the contours are in the correct places then I would say that's all. This is of course assuming that your map really does match the terrain (e.g. check satellite pictures or site visit), that you have not modified any WAsP parameters from their defaults. But one can not definitely say that your map is "ok" without checking it. with kind regards,

Hello, in order to check whether the map is prepared correctly, one would basically need to see it. But, lacking that, a quick check is to first make sure (in the main MapEditor window) that there are no dead-ends, cross-points, and especially no LFR errors. LFR (line-facing roughness) errors cause dramatic non-physical changes in the results; these errors occur when the map has ambiguous/inconsistent roughness lengths [z0] in some region, due to an area being bordered by z0-change lines having different z0.

Thanks, this is something we have been considering, for future releases.

Good Afternoon, My question today involves the wind speed discrepancy between the mean speed from my measured met tower and the mean speed (U) in the observed wind climate. My observed wind climate is showing a mean speed (U) that is around 2% to 3% (or .20 m/s) lower than my measured met tower mean wind speed. I understand that WAsP forces the measured data to fit a standard Weibull frequency distribution, however, is there a way to correct this 2-3% discrepancy? And how much is this discrepancy affecting my AEP? I noticed that the observed wind climate has a "Quality-Speed Discrepancy" table, which I assume shows the discrepancy between these two for each sector. Thank you. Hello, We remind that the power-density is generally more important than the mean wind speed in the Weibull-fit. You may notice that the Weibull-fit power density is likely within 1% of the raw/histogrammed data's power density. This impacts the AEP more than the mean wind speed, as documented (somewhat) in the help file--and as we teach in the WAsP course. Look at the bottom of the OWC table in WACA, and you can see (yellow) boxes showing the power-density numbers; to the far right in this table a the 'quality' is shown for power-density, i.e. dimensionless error in percent (%). With kind regards, --Dr. Mark Kelly Wind Energy Dept., Risø Lab/Campus, Danish Tech. University

Hi, again A is the Weibull scale factor, and U is the mean wind speed. Recall that for a Weibull distribution, U = A*Gamma(1+1/k), where Gamma is the gamma-function and k is the Weibull-shape factor.

Hello, WAsP performs vertical extrapolation using the logarithmic law as a basis, which means that the roughness length determines the shear. The vertical extrapolation modeling also accounts for long-term stability, through the parameters Hoffset and Hrms; the model is most sensitive to the parameter Hrms (which is negative by default, because stable conditions dominate on average). Thus the extrapolation also depends on Hoffset, which can be modified to change the (implicit) shear. One must also ask: how does Windographer obtain the shear exponent? If you have measurements at two heights above the surface-layer (at least 40-50m), then this makes some sense. The Weibull-distribution is fit to the 1st and 3rd moments, above the peak--thus a compromise for matching power-density as together with mean wind speed, as well as possible. With kind regards, --Dr. Mark Kelly, Wind Energy Dept., Danish Technical University for WAsP support support@wasptechnical.dk

Another thing to note is that the 'default' WAsP offset heat flux is for slightly stable on average values (-40 W/m^2, since stable stratification affects the profile more than unstable stratification). So a value of -10 W/m^2 for Hoffset, for example, gives less shear (less change in speed with height) than the default settings. [For more details one can also check Kelly & Troen (2016) "Probabilistic stability and 'tall' wind profiles: theory and method for use in wind resource assessment", Wind Energy, 19(2), 227–241.] With kind regards,

You can insert a note that mentions the real density (via right-clicking an object in the project hierarchy at left), but keep the project density at 1.15 kg/m^3. With kind regards,

Hello Thierry, WAsP was indeed developed originally for turbines in the surface layer, so generally heights down to 10m (or less) are usually ok. There are a few problems that arise when going below 10m: 1) there tend to be many more obstacles, which need to be individually modelled; 2) obstacles tend to induce more turbulence, which is not modelled by WAsP. So approaching the ground, one has to rely on the obstacle model, which is designed for obstacles that are (appreciably) lower than hub height (or far enough away); this model gives wind speed reductions, but has quite a bit of uncertainty--particularly as the distance to obstacles decreases. We also have had a side project with EMD for smaller turbines called WAsP Online, where one can use a web interface to do simplified WAsP calculations (http://www.mywindturbine.com ). At any rate, I would exercise caution regarding any obstacles for small turbines, as well as considering what kind of turbine you are using (e.g. HAWT, with/out yaw drive). with kind regards,

Hola Javier, Wasp11 should be able to import the projects from v9.4--does this happen with all? Otherwise, try opening the v9 project in WAsP-10, and then saving it; thereafter you are able to load it with v.11.

Hello, this seems to currently be the most reasonable way forward, though it can depend on the terrain. Vertically extrapolating from 40m to 105m (height ratio of ~2.6) has much less uncertainty that extrapolating from 10m to 105m (height ratio >10); you can see this in the Wind Energy article by Kelly+Troen (2016). That article gives a form to estimate the expected uncertainty, though I note that such estimation requires having a reasonable roughness length assignment and pretty simple terrain (otherwise the uncertainty increases, no matter what the method you use). Further, doing vertical-shear extrapolation from a {10,40}m pair up to 105m is more uncertain (avoid it in this case), especially if the terrain is not uniform/flat [see/search e.g. for DTU report of Kelly from 2016 for this]. Cheers, --Mark

Hi "windmueller", You can just make a loop to find the maximum value, then report that. As you write above, you can see the power variable, and loop through its members/components (as seen in other bits of the script for e.g. other variables). So I don't think that you would need to worry about HTML per se, as you can set the max value to an arbitrary variable via if statement and a loop (over speed bins). Hope this helps, --Mark

Hi Windmueller, for Excel, one could simply make a new column and multiply by 1000, or use a VBscript to do so. For e.g. HTML, I am not sure if one can alter the value of GetAepUnits; thus one could multiply by 1000 in the script/code as you paste above. Perhaps Duncan can confirm. Cheers, --Mark