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.