Rogier

Yes, we keep the strings like "WAsP_12.10" to make it simple to compare with WAsP GUI / WindPro. They are only set behaviour related to the fortran core. In practice, nothing has changed in the fortran between "Wasp 12.8" and "WAsP_12.10", because they were only impacting the WAsP GUI. So I understand it can be a bit confusing. But anyway, so you are nearly doing the right thing, but you want to use: conf.climate.set_profile_model(1) print(config.climate['off_hfx_land']) if you use set_profile_model(2) it will read the heat flux values instead from the mesoclimate that you pass in the generalize and downscale routines, e.g. https://docs.wasp.dk/pywasp/latest/api_reference/wasp_autogen/pywasp.wasp.generalize.html This is because the WAsP "EWA model" use constant heat fluxes, that were still set by the parameter arrays in the fortran, whereas the new model treats them a spatially varying inputs in the routines. You can see a little bit in the docstring of set_profile_model, but admit the documentation is not super clear so will update it. The default value of config.climate['off_hfx_land'] == -40. The script you included will set config.climate['off_hfx_land'] = 0 (you set the mean stability to zero, but the profile will still tend to the stable side because you have not set the rms_hfx_land to 0), see: https://link.springer.com/article/10.1007/s10546-023-00803-3 Generally, I would not recommend using the old profile model, since it one of the easiests way to detoriate your modelling, see the distributions here: https://zenodo.org/records/17668633/files/07 RogierFloorsDTU.pdf?download=1

Hi Alexandru, Regarding 1), this is an issue with xarray 2026.04, I think downgrading to 2026.02 should solve it temporarily. The next release of pywasp will also work with xarray 2026.04 Regarding 3), it is best to use generalization_method="geostrophic" in predict_wwc, because that eliminates truncation errors related to the generalized heights and roughnesses entirely. If you really want to use it anyway, the values that are internally chose are not accessible, but you can know what they are by looking at https://docs.wasp.dk/pywasp/latest/api_reference/wasp_autogen/pywasp.wasp.derive_gen_roughnesses.html and https://docs.wasp.dk/pywasp/latest/api_reference/wasp_autogen/pywasp.wasp.derive_gen_heights.html and passing in the variables height and z0meso from your input and output locations. Since they are already the best possible values based on your input there is generally no point in changing them though. The others ones are in our error tracking system, I am not yet sure about the solution. Regards Rogier

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.

No these data have unfortunately "passed away" with our file server being closed. Which specific files do you need? We might still have them but it will be a manual process.

The coordinates from the original WRF projection are already stored in the west_east and south_north coordinates and the spatial reference is already stored in the crs variable. So to make a tif you can do: import xarray as xr ds = xr.open_dataset("mesoscale-ts.nc") ds_proj_mean = ds.WS.mean("time") ds_proj_mean.rename({"crs":"spatial_ref"}).rio.to_raster("ws_150.tif") That opens it in the right place for me: or to get it in 2157: ds_proj_mean = ds.WS.mean("time") ds_proj_mean = ds_proj_mean.rename({"crs":"spatial_ref"}).drop_vars(["XLAT","XLON"]).rio.reproject("EPSG:2157") ds_proj_mean.rio.to_raster("ws_150_2157.tif")

Hi Lidia, All GWA/WAsP servers were impacted by a major IT issue at DTU. They should now all be working again. Regards

Hi, 1) The new IBZ can also deal with displacement heights in case of forests. It is probably most easy to understand the differences from Fig 1 and 2 in this paper: https://wes.copernicus.org/articles/6/1379/2021/. If you are not using displacement heights the results should be nearly identical, although the new routines also solves some problems with the old routines where "dead pixels" were occurring in the resource grid in some rare cases. You can how to use it here: https://panopto.dtu.dk/Panopto/Pages/Viewer.aspx?id=0394a399-d5c2-4a71-9954-b0d800dbcb7f 2) Yes you can also right click on the GWC now, because that was a more logical place to edit this. You will have to recalculate the GWC after you have changed the heights, because the results will be different. 3) Yes the T* model uses modelled stability parameters from ERA5 to get a overview of sectorwise stability based on the location of the site. It will lookup the nearest ERA5 grid point and retrieve the related stability and boundary layer height. This approach was validated to be better then the old method, see here: https://www.wasp.dk/news/nyhed?id=ea5c4c79-c096-4cc4-a771-ad5314b837ef https://link.springer.com/article/10.1007/s10546-023-00803-3 4) Yes these changes are described here: https://www.wasp.dk/news/nyhed?id=662f23ca-b559-418a-8879-e6b281b7a31f Regards

Yes, there was recently another case that had this problem. The solution there was like this:

There is ways to do that, but I guess the first question is whether you really need a map this big? Usually a distance of about 20 km from yours turbines/mast is more than enough and anything more will not have a significant effect on the flow modelling results, but will make the computations significantly slower.

I tried to open your map, but I can see you have used 50 m resolution, so it takes hours to open in the map editor. I would recommend just using the default 100 m resolution, because it will be much faster to open and it will likely make very small differences only for WAsP, which is anyway simplifying the roughness map afterwards. I couldn't detect any errors in the map editor though, see below. Maybe make sure you use the latests version of the map editor and the QGIS plugin?

Yes we recommend always checking with the map editor, but in principle there should be no errors. Could you share your map? Sometimes errors can be solved with "snap geometries to layer" in qgis.

I see, this is a simple bug that I fixed now. The new version will be available soon. This can be when you use the polygonize script in QGIS or other tools. Those scripts don't insert extra nodes where several polygons meet. You can insert those by searching for the script "Snap geometries to layer" and running that. You can also install windkit and use the script poly2lines: https://docs.wasp.dk/windkit/io/topo_autogen/windkit.map_conversion.poly2lines.html

Hi Doha, the papers you mention are indeed the right references. This paragraph in the paper 1 you mention probably explains it best: The original zooming grid is just a grid where the grid cells increase in size further away from the site: The roughness lengths in these cells are then multiplied with a exponentially weighted distance. From those transformed cell values the most significant ones are found with a simple algorithm where you just loop over all roughness changes until you have explained enough of the initial variance in all transformed roughness changes in a certain sector.

Hi Heather, it is not possible yet to do what you describe but we are planning to develop it some time in the future. You can get part of the model chain by applying the speedups but the geostrophic drag law part is currently always converting to histograms (time-independent). If it is just about automating the process you could look at the pywasp or windkit (https://docs.wasp.dk/pywasp/ https://docs.wasp.dk/windkit/) where there is functions to convert from time series to histograms (https://docs.wasp.dk/windkit/io/wc_autogen/windkit.binned_wind_climate.bwc_from_timeseries.html).

I think you can just add the gaps as you want, the significance algorithm is quite robust. Regarding roughness for forest I would for sure not use a standard roughness of 0.5 m. That is generally too low in Europe, where a typical forest has h>10. The rule with z0=h*0.1 will give you usually a much better estimation. The displacement height is automatically calculated since WAsP Release 2022-A-1, if you specifiy them in a .gml file (you can use treeheight *(2/3), see paper I linked before). There is a video about using displacement heights and creating a GML file here: https://panopto.dtu.dk/Panopto/Pages/Viewer.aspx?id=0394a399-d5c2-4a71-9954-b0d800dbcb7f