All Activity

Dear Morten， Thanks very much for your reply. Now I have a very clear understanding of these two concepts.

The effective roughness is the parameter used in the geostrophic drag law that links surface winds to winds above the boundary layer (EWA chapter 8.1). This effective roughness is a simplification of the surface roughness map, and it is calculated for each turbine or reference mast position and each wind sector. In addition, the wind atlas model includes a sub-model for the effect of surface roughness changes (EWA chapter 8.3). The wind atlas categorises the terrain by a reference roughness value (EWA Figure 3.1). WAsP will calculate generalised wind climate statistics for a set of reference roughness values and standard heights, and you can see this table if you right-click a generalised wind climate (GWC) object in WAsP. As discussed above, the WAsP model depends on climate statistics for effective roughness values for each site and wind sector. It therefore interpolates the GWC using data at the reference roughness values and standard heights. You can avoid the associated interpolation errors if you modify the reference conditions, i.e. right-click the project object and select edit configuration> wind-atlas structure. We recommend inclusion of the turbine hub height and the height of the reference anemometer in the set of standard heights. You might also include the most typical surface roughness of your area.

Dear Users, Have you ever faced this type of issue while launching the application? Exception report produced at 2026-05-18 11:50:41 Local exception: No product licence found for component Rvea0334 raised at: 2026-05-18 11:49:49 2026-05-18 11:49:49: Message added: Could not refresh the licence information 2026-05-18 11:49:49: Exception raised in: Rvea0334: cLicenceInformation:Refresh 2026-05-18 11:49:49: Message added: Could not refresh the licence status 2026-05-18 11:49:49: Exception raised in: WAsP: cLicenceInformation:Refresh 2026-05-18 11:49:49: Message added: Could not display the splash startup window 2026-05-18 11:49:49: Exception raised in: WAsP: fNoLicenceSplash:DisplayAndPerformLicenceCheck 2026-05-18 11:49:49: Message added: Could not start the application 2026-05-18 11:49:49: Message added: Please contact the WAsP team at Risø for assistance Latest thread started in: I’ve tried several ways to validate my license, but the application is still not allowing me to proceed. Any suggestions would be appreciated.

Dear WAsP team By using wasp and reading (1989)European_Wind_Atlas,I found two concepts about roughness appear repeatedly, one is "effective roughness" and the other is "reference roughness". would you help to explain the difference between these two roughness? Thank you for your help. Best regards.

WindKit v2.1.0 has been released Docs Highlights of release LinRegMCP with residual noise — new LinRegMCP.predict_with_noise() samples Gaussian residuals per sector to recover realistic wind-speed distributions that preserve variance. MCPRegressor.predict(return_std=True) exposes the per-timestep residual standard deviation, and LinearRegression.residual_std is computed and stored during fit(). New windkit.io.wasp low-level subpackage — read and write .tab, .lib, and .owc / .omwc files as plain dicts with numpy arrays, without xarray overhead. read_tab / write_tab / format_tab, read_lib / write_lib / format_lib, read_owc / parse_owc_element. Correlated synthetic TSWC data — create_tswc(not_empty=True) now generates temporally and spatially correlated wind data using an AR(1) / Weibull model (one year at 10-minute frequency by default). New create_tswc_pair creates correlated TSWC pairs with configurable speed bias, directional bias, and target correlation. windIO format support (experimental) — new windkit.io.windio subpackage adds readers and writers for the IEA windIO format, covering BWC / WWC / TSWC wind climates, wind turbines / WTGs, and full plant composition. Top-level readers and writers (read_wwc, read_bwc, read_tswc, read_wind_turbines, read_wtg, and their *_to_file counterparts) now accept YAML. See New features below for the full API. Dependency minimum bumps (breaking) — minimum supported versions raised: numpy 2.0, xarray 2024.9, pandas 2.3, scipy 1.13, geopandas 1.0, rasterio 1.4, pyproj 3.7, lxml 5.2, netcdf4 1.7. Users on older versions must upgrade.

Dear NEWA team, Sometimes I download full period time series just to postprocess them and obtain some statistics. One recurring thing is to get omnidirectional as well as by sectors (12 and 16 direction sectors) Weibull A and k parameters. In order to avoid the download of these time series it would be nice to download only the post-processed products. I'm thinking in something that may be of general use, A, k: Omnidirectional in 12 sectors in 16 sectors For the different available heights For a period covering complete years (20y, 25y or 30y) Pros: Reduce data transfer drastically. Cons: Increase 'slightly' the storage size and the task to get these values ready to download. Kind regards.

Hi Vittorio, Thanks for reaching out. Yes we were overwhelmed with requests last week and had to implement some changes to avoid impact on our systems. We have currently set a limit of 4 requests per minute. If you are in need of a larger area from the timeseries, rather than trying to download it point by point, please reach out via the contact form, and we will see if we can create the subset for you. This will in part depend on how many requests we get and how big of a dataset you are requesting.

Dear WAsP-Team, could you please send an anwer, I guess it is impossible, but could you please comment? Thanks and regards Gudrun

Hi everyone, I’ve been thinking about how to avoid small issues that only show up at the final stage when printing documents or generating reports. Sometimes everything seems fine during the process, but the final output isn’t correct or doesn’t print as expected. To reduce this, I’ve been trying a simple approach where I do a quick output check before running the final print or report. For example, generating a basic test output first to confirm everything is working properly. In another use case, I tested this idea using a simple test page approach (like printing a basic page just to confirm printer response before the final document). It helped catch issues earlier instead of troubleshooting after failure. I wanted to ask: Do you follow any validation steps before final output or printing? Are there better ways to catch output issues earlier in the workflow? Would appreciate any suggestions.

Hi all, I am receiving "too many requests" errors, with status 429. Is this a new behavior? Can you give us any detail on this? E.g. how many requests can we make? Thanks. Best regards, Vittorio

Thanks, Neil, for the clarification. Well understood.

Hi Kiko, The mesoscale time-series is not available for download by bounding box, only the atlas data. We hope to return this functionality soon, but it will come with registration and a limit on the amount that can be downloaded. We are currently testing this functionality and hope to roll it out within two months.

Hi all, I can't download mesoscale data today using a bounding box. Also, elevation data is not available since a while. My previous post in this thread was from 2 months ago and during this period I have tried to get data several times with no luck. I have no idea if some endpoints have been removed. KR,

For access to ERA5 data, you could also try to make use of the Earth Data Hub, which is part of the DestinE project, which might be faster than the ECMWF direct access.

Hi Breizhmg, For ERA5, https://cds.climate.copernicus.eu/datasets/reanalysis-era5-single-levels-timeseries?tab=download is probably the best place to download the time-series. It should have everything you need for RMOL. See, e.g., https://confluence.ecmwf.int/display/CKB/ERA5%3A+How+to+calculate+Obukhov+Length.

Hi, you could take a look at the "meso download" at https://map.neweuropeanwindatlas.eu/. There you can download the inverse obukhov length. You can also calculate it yourself from instantenous heat fluxes and friction velocity etc from ERA5. In ERA6 it will be one of the downloadable "standard" variables.

Hi Breizhmg, I believe you are referring to https://github.com/jules-ch/wind-stats. This is not a DTU Wind-affiliated package, no. Not currently. Most likely, PyWAsP will be the package that gets this feature, and will probably involve a paid API license. We don't have a concrete timeline for this yet. Best regsards, Bjarke

Hi, it was back again a few days ago but now it is off again.

Thank you Mr. Van der Laan for the very fast reply and clear explanation I am a big fan of your work 😄 Two quick clarifying questions: 1. Is the residual sum unweighted (\sum_i |R_i|) or volume-weighted (\sum_i V_i |R_i|)? With the WAsP-CFD grid (14 km domain, ~5 m mean vertical resolution, structured stretching), the volume ratio between top and bottom cells is very large — this distinction matters for interpreting -4.3. 2. Is R_i the algebraic residual of the linearized system (the Ax - b imbalance before the linear solve), or something else? Context: I'm implementing an equivalent convergence monitor in OpenFOAM (unstructured, SIMPLE) on a 12 km domain with similar ν_t profiles (ASL profiles), and getting the normalization right is essential for a fair comparison.

Hi @fabienfarella, Thanks for your questions and analysis. As an EllipSys3D developer, I can answer some of your questions. The residuals in EllipSys3D are computed for each equation as an absolute error, summed over all cells. The results are normalized by the initial solution and then we take the logarithm. The WAsP CFD complex terrain setup is designed to be robust and efficient in terms of CPU effort. The prior is achieved by starting with an initial solution that has a relative high eddy viscosity. The latter is a result of the initial condition and not converging to machine precision. The WAsP CFD convergence limit of -4.3 is expected to be good enough for the speed up factors at the heights above ground where modern turbines operate. However, if one is interested in the flow near the ground, then the chosen convergence limit may not be strict enough. In our wind farm flow CFD framework PyWakeEllipSys, which also uses EllipSys3D, we converge to -4 for annual energy production runs that contain many flow cases (https://doi.org/10.5194/wes-4-645-2019), -5 for flow case runs, and -6 for grid convergence studies. Best regards, Paul

Summary I'd like to understand how WAsP-CFD defines and evaluates convergence, and suggest a small addition to the convergence report that would help users assess result reliability on complex terrain. Context I'm running WAsP-CFD (v1.11.2.1 via WindPRO 4.2) on a site in the Austrian Alps with very complex terrain — deep valleys, ridgelines, and strong channeling. The convergence report shows all 36 directions marked "Ok? yes" with log(r) between −4.30 and −4.31. WAsP-CFD convergence table screenshot This is impressive, but it raises a question: what exactly is the residual log(r) measuring? Specifically: Is it the equation residual (Ax−b) or the iteration-to-iteration field change (Δφ)? Is it an L2/RMS norm (averaged over all cells) or something else? Is the "max of all variables" the max over fields, or the max over cells? What is the normalization — initial guess, current field magnitude, reference values? Why this matters On terrain like this, a few percent of cells (in valleys and behind ridgelines) can oscillate between two flow regimes while the vast majority of the domain is well-behaved. A volume-averaged norm will be dominated by the ~98% of cells in the far-field and on smooth terrain, masking local non-convergence in exactly the region where the turbines are. (attach: hillshade of terrain showing channeling geometry) hillshade of terrain showing channeling geometry My experience with OpenFOAM on the similar terrain I've been running the similar sites in OpenFOAM v2512 (k-epsilon, ~15M cells, low non-orthogonality, quasi-structured, SIMPLE). I acknowledge the grid, solver, and numerics differ from EllipSys3D, so direct comparison of residual levels isn't fair. But two observations: Initial residuals plateau, not drop: Ux ~5×10⁻³, p ~8×10⁻², k/ε ~10⁻³ — nowhere near −4.3 in log scale. This is consistent across schemes (LUST, QUICK, linearUpwind) and initialization methods. Residuals Probes U Probes k Probes relative direction On channeled sectors, probes inside the area of interest oscillate even after 2500+ iterations with flat residuals. Wind speed swings of several m/s, direction changes of ±10° — a genuine physical limit cycle that steady RANS cannot resolve. Oscillating probes U Oscilatiing probes - Relative direction The channeling is visible in the WAsP-CFD results themselves. The two figures below show the WAsP-CFD turbulence intensity and speedup fields at 100 m, sorted by local flow direction at the site (not inflow case). Panels are labeled "Dir: X° - Case: Y°" where Dir is the resulting local direction and Case is the simulated inflow sector. Two things stand out: - 14 of 36 inflow cases (roughly 50°–190°) collapse to the same local direction (~110°–130°), producing nearly identical flow patterns. This is the terrain channeling — the valley forces the flow regardless of the synoptic direction. - The TI fields on these channeled cases show values of 0.30–0.50 in the valley — physically implausible for neutral RANS, and likely a sign that the solver is averaging over an oscillating solution rather than converging to a single state. WAsP-CFD @100m - TI WAsP-CFD @100m - SpeedUp (relative to green location) This is not surprising — when multiple inflow directions map to the same local flow regime through terrain channeling, RANS has no mechanism to select one. The solution oscillates between attractors. The question Given the terrain complexity shown, I find it remarkable that all 36 directions reach log(r) < −4.3. Could you help me understand: Is this level of residual typical for EllipSys3D on complex terrain, or does it reflect a different residual definition than what OpenFOAM reports? Does the convergence check include any assessment of whether the flow field has actually reached a steady state (e.g., monitoring point values), or is it purely based on the global residual norm? Feature suggestion The current report PDF shows the convergence table and the terrain/speedup maps — which is very useful. To help users evaluate physical convergence (not just numerical), two additions would be valuable: Optional monitoring point upload Currently, the WAsP-CFD submission only accepts a MAP file (terrain + roughness data). It would be useful to allow an optional upload of monitoring locations — a simple text file with columns `X Y H Name` — specifying points where the solver should record field values (U, k) at every iteration during the solve. This is a lightweight addition on the solver side (probe interpolation at a handful of points costs nothing compared to the PDE solve), and would give users direct visibility into whether the solution has actually reached a steady state at the locations that matter to them. Convergence data in the report and CFDRes file If monitoring points are provided: - Probe time series in the report PDF: plot U and k at each monitoring location over the full iteration history. This would immediately reveal whether the solution has settled or is cycling — something that global residual norms cannot show. - Attach probe convergence data to the CFDRes file: even just the final N iterations of U, direction, and k at each monitoring location would let users make their own convergence assessment downstream. Even without user-supplied points, the solver could monitor a few automatically chosen locations within the inner domain (e.g., terrain peaks, saddle points) as a built-in sanity check. This would be especially helpful on complex terrain where global residual norms can mask local behavior. It doesn't require changing the solver numerics — just exposing data that's already available during the solve. Thank you for a great tool — this is meant as a constructive suggestion to improve interpretability for challenging sites. PS: I am sorry i couldnt render image attachements, so i have attached them as hyperlinks to a public github repo

Hello, I managed to download ERA5 data with Windkit, but it does not contain enough data to be able to compute a stability metric (MOL, or Ri). Apart from a direct ERA5 download from the ECMWF (slow), can anyone suggest any other way to download time-series of stability? Or alternatively, atmospheric stability statistics? Thank you.

Hello, I saw a "wind-stats" python package which seems to be able to retrieve GWA wind climate. 1. Is this package independent from DTU's? 2. Is there any alternative within Windkit to do something similar? Thank you

Hi, same here...

Thanks you so much!