<?xml version="1.0"?>
<rss version="2.0"><channel><title>All Activity</title><link>https://www.wasptechnical.dk/forum/discover/</link><description>WAsP Forums - All Activity</description><language>en</language><item><title>Difference between effective roughness and reference roughness.</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/841-difference-between-effective-roughness-and-reference-roughness/?do=findComment&comment=2526]]></link><description>Dear Morten&#xFF0C;
 


	Thanks very much for your reply. Now I have a very clear understanding of these two concepts.</description><pubDate>Mon, 18 May 2026 14:39:05 +0000</pubDate></item><item><title>Difference between effective roughness and reference roughness.</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/841-difference-between-effective-roughness-and-reference-roughness/?do=findComment&comment=2525]]></link><description><![CDATA[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&gt; 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.]]></description><pubDate>Mon, 18 May 2026 06:31:55 +0000</pubDate></item><item><title>Licence validation</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/842-licence-validation/?do=findComment&comment=2524]]></link><description>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&#xF8; for assistance 
	    Latest thread started in: 
 


	 
 


	I&#x2019;ve tried several ways to validate my license, but the application is still not allowing me to proceed.
 


	Any suggestions would be appreciated.</description><pubDate>Mon, 18 May 2026 06:21:01 +0000</pubDate></item><item><title>Difference between effective roughness and reference roughness.</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/841-difference-between-effective-roughness-and-reference-roughness/?do=findComment&comment=2523]]></link><description>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.</description><pubDate>Tue, 12 May 2026 11:40:18 +0000</pubDate></item><item><title>WindKit 2.1.0 released</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/840-windkit-210-released/?do=findComment&comment=2522]]></link><description>WindKit v2.1.0 has been released 
	 
	Docs 
	 
	Highlights of release



	
		LinRegMCP with residual noise &#x2014; 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 &#x2014; 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 &#x2014; 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) &#x2014; 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) &#x2014; 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.</description><pubDate>Thu, 23 Apr 2026 06:38:38 +0000</pubDate></item><item><title>PROPOSAL: Addition of Weibull Params to meso</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/839-proposal-addition-of-weibull-params-to-meso/?do=findComment&comment=2521]]></link><description>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.</description><pubDate>Tue, 14 Apr 2026 08:00:42 +0000</pubDate></item><item><title>Can't download data from api</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/791-cant-download-data-from-api/?do=findComment&comment=2520]]></link><description>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.</description><pubDate>Tue, 14 Apr 2026 07:57:11 +0000</pubDate></item><item><title>How to detect recirculation zones?</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/834-how-to-detect-recirculation-zones/?do=findComment&comment=2519]]></link><description>Dear WAsP-Team,  
	could you please send an anwer, I guess it is impossible, but could you please comment?
 


	Thanks and regards 
	Gudrun</description><pubDate>Tue, 14 Apr 2026 07:00:07 +0000</pubDate></item><item><title>How do you verify output before final printing or report generation?</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/838-how-do-you-verify-output-before-final-printing-or-report-generation/?do=findComment&comment=2518]]></link><description>Hi everyone,
 


	I&#x2019;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&#x2019;t correct or doesn&#x2019;t print as expected.
 


	To reduce this, I&#x2019;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.</description><pubDate>Mon, 13 Apr 2026 18:48:30 +0000</pubDate></item><item><title>Can't download data from api</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/791-cant-download-data-from-api/?do=findComment&comment=2517]]></link><description>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</description><pubDate>Mon, 13 Apr 2026 11:17:35 +0000</pubDate></item><item><title>Can't download data from api</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/791-cant-download-data-from-api/?do=findComment&comment=2516]]></link><description>Thanks, Neil, for the clarification. Well understood.</description><pubDate>Mon, 13 Apr 2026 09:54:37 +0000</pubDate></item><item><title>Can't download data from api</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/791-cant-download-data-from-api/?do=findComment&comment=2515]]></link><description>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.</description><pubDate>Mon, 13 Apr 2026 09:29:51 +0000</pubDate></item><item><title>Can't download data from api</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/791-cant-download-data-from-api/?do=findComment&comment=2514]]></link><description>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,</description><pubDate>Mon, 13 Apr 2026 09:25:28 +0000</pubDate></item><item><title>atmospheric stability data download</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/836-atmospheric-stability-data-download/?do=findComment&comment=2512]]></link><description>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.</description><pubDate>Tue, 07 Apr 2026 13:15:23 +0000</pubDate></item><item><title>atmospheric stability data download</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/836-atmospheric-stability-data-download/?do=findComment&comment=2513]]></link><description>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.</description><pubDate>Tue, 07 Apr 2026 13:15:23 +0000</pubDate></item><item><title>atmospheric stability data download</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/836-atmospheric-stability-data-download/?do=findComment&comment=2511]]></link><description>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.</description><pubDate>Tue, 07 Apr 2026 13:12:24 +0000</pubDate></item><item><title>downloading GWA data within windkit?</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/835-downloading-gwa-data-within-windkit/?do=findComment&comment=2510]]></link><description>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</description><pubDate>Tue, 07 Apr 2026 13:10:16 +0000</pubDate></item><item><title>Can't download data from api</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/791-cant-download-data-from-api/?do=findComment&comment=2509]]></link><description>Hi, 
	it was back again a few days ago but now it is off again.</description><pubDate>Thu, 02 Apr 2026 15:23:09 +0000</pubDate></item><item><title>Convergence / steady-state verification in WAsP-CFD</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/837-convergence-steady-state-verification-in-wasp-cfd/?do=findComment&comment=2508]]></link><description>Thank you Mr. Van der Laan for the very fast reply and clear explanation 
	 
	I am a big fan of your work &#x1F604;  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 &#x2014; 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 &#x3BD;_t profiles (ASL profiles), and getting the normalization right is essential for a fair comparison.</description><pubDate>Wed, 01 Apr 2026 13:09:49 +0000</pubDate></item><item><title>Convergence / steady-state verification in WAsP-CFD</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/837-convergence-steady-state-verification-in-wasp-cfd/?do=findComment&comment=2507]]></link><description>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</description><pubDate>Wed, 01 Apr 2026 12:30:11 +0000</pubDate></item><item><title>Convergence / steady-state verification in WAsP-CFD</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/837-convergence-steady-state-verification-in-wasp-cfd/?do=findComment&comment=2506]]></link><description><![CDATA[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) &lt; −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]]></description><pubDate>Wed, 01 Apr 2026 08:01:27 +0000</pubDate></item><item><title>atmospheric stability data download</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/836-atmospheric-stability-data-download/?do=findComment&comment=2505]]></link><description>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.</description><pubDate>Mon, 30 Mar 2026 15:10:19 +0000</pubDate></item><item><title>downloading GWA data within windkit?</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/835-downloading-gwa-data-within-windkit/?do=findComment&comment=2504]]></link><description>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</description><pubDate>Mon, 30 Mar 2026 15:05:08 +0000</pubDate></item><item><title>Can't download data from api</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/791-cant-download-data-from-api/?do=findComment&comment=2503]]></link><description>Hi, same here...</description><pubDate>Wed, 25 Mar 2026 12:00:56 +0000</pubDate></item><item><title>Question about upflow calculation</title><link><![CDATA[https://www.wasptechnical.dk/forum/topic/832-question-about-upflow-calculation/?do=findComment&comment=2502]]></link><description>Thanks you so much!</description><pubDate>Tue, 24 Mar 2026 14:57:47 +0000</pubDate></item></channel></rss>
