Thanks and regards
Gudrun

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

it seems the latest updated version of WAsP CFD viewer has a few bugs.

- WAsP CFD Result Viewer  (Version 1.3.0.55)

following the link in https://www.wasp.dk/software/wasp-tools/wasp-cfd-result-viewer,

i am refering to video files uploaded in Youtube channel : 

<Flow field>

video file: ShowCFD demo 1 – Introduction file
the file was loaded from ...\WAsP samples\WAsP 12\Wasp workspaces\ParqueFicticioCfdFiles\ 

however the figure in the software is not the same that is shown in the video file while figure matches with manual.
for example, turbulence intensity, flow inclination and sigma U has NO transect view of the main view in the rectangular box.

in addition, if i click wind direction, it shows pop-up error message.

furthermore, there are some errors when the screen is zoomed-in and -out saying.
//
Exception occurred in showCFD 'plotScaleChange' routine 
TTransect.scale>Invalid floating point operation
//<Site assessment>
video file: ShowCFD demo 3 - Map-based site assessment
the relevant file from Helpfile has already expired.

//

Each data set contains one WAsP CFD result file and additional site assessment input from one measurement station (except the first data set which includes data from the nearby PORT07 measurement station).

PORT06 (71.3 MB) 
PORT08 (71.4 MB) 
PORT09 (66.5 MB) 
PORT10 (68.6 MB) 
All four dataset (277.8 MB) 
The download links will expire in September 2024.
//

it would be better if you could provide these files in the webpage or again in the link as those are used in help file.
currently it did not work as it is specified. if possible could you please share those files here again?

regards,

Gyeongil

i am doing resource assessments in forest site with multi-masts mainly based on WAsP.  Western and southern parts of the site have a steep slope > 16.7 degree, so that I ordered WAsP-CFD. i read most of forest issues in this forum and also from webpage: https://www.wasp.dk/software/wasp-cfd/flow-model to understand better of WAsP-CFD.

However I still did not fully understand. I have some questions below. 

(Question 1) Are there any benefit of WAsP-CFD focusing on forest area? based on webpage above, it seems to me that WAsP-CFD use/interpret roughness data differently.

(Question 2) if WAsP-CFD has zero benefit compared to WAsP in terms of forest, should I apply same displacement heights in WAsP-CFD that were applied to WAsP?

(Question 3) based on WAsP, three main inputs are oro + rou + obs. How are obstacles dealt with in WAsP-CFD if they are not a part of input before run?

My last WAsP course was long time ago and i have used 3rd party CFD tools to handle forest. i think that could be the reason why I am still confused to understand how WAsP-CFD works. Could you please advise/guide me with details?

Thanks

Gyeongil

I am making a big "mosaic" consisting of fifteen 2x2 km CFD tiles. The mosaic does not have a rectangular shape. Nevertheless, Windfarmer uses WRG files which are rectangular in shape.

Should I create within Wasp fifteen 2x2 km WRGs to feed into Windfarmer?

Or,

Will WAsP allow me to create a single rectangular WRG although not all the area will be covered with CFD results?

Additional info: All my turbines will be placed within CFD results area, which is guaranteed through appropriate windfarm boundaries set out within Windfarmer.

Thanks very much!    

I need a wind resource grid (wrg) at 112m high (turbine hub height) as an input to Windfarmer. Wasp CFD calculates wind resource at fixed heights (5, 10, 20, 33, 48, 65, 80, 100, 120, 150, 200, 250 and 300 m). How is the mathematical process of interpolation from these fixed heights to the required wrg height within Wasp CFD? 

Thanks!

Approx. 25km.

In this case, can the traditional wasp calculation be used?

Nor can WASP-CFD estimates more accurate results?

As you can see in https://www.wasp.dk/waspcfd/flow-model in section "Preparing the height countor map":

"..., the CFD model uses a fixed domain size (radius of 15 km) and grid resolution (grid size of 20 m) irrespectively of the digital map.""

"The zooming grid of the IBZ model as well as the CFD model indicates that the countor line description close (within 2km or so) to the prospected site(s) should be as detailed and accurate as possible (countor separation of less than 10 m)...."

I would like to understand if WAsP CFD have a limit to "accurate as possible" in terms of height contour lines discretisation. Like 30 cm, 1 m, 5 m or less than this... And if I use the less one, my result gonna be better?

Thank you.

I was trying to do some calculation for wind farm and the area around it is very rugded (i'm getting some RIX's over 10 % and I can't calculate a resource grid) so I thought I'd use the CFD terrrain analysis to do so but I keep getting an 'Automation error'. It is my first time using any CDF based software so, how can I go about it?

Kind Regards,

Lidia

I am planning to do a WASP CFD calculation. I saw in the wasp course that the met mast must be covered with a tile too (besides covering the wind turbines). I am guessing that for validation purposes it is useful, but since the CFD solver only takes into account terrain features, do I really need to cover the met mast with a tile?

Also, I have several met masts for this particular case.

Thank you!