Errors when performing calculations in PyWAsP

[Alexandru Guntner]

Dear PyWAsP team,

I am having problems when running calculations in PyWAsP for my own projects. Note that I have the same issues when running the tutorial notebooks.

1) When I call pw.potential_aep I get the following error:

aep_park2 = pw.potential_aep(
    wwc,
    wtg,
    wind_farm_model="PARK2_onshore",
    turbulence_intensity=0.0
)
TypeError: Passing a Dataset as `data_vars` to the Dataset constructor is not supported. Use `ds.copy()` to create a copy of a Dataset.

This is odd as I'm running the exact same command for the gross_aep, which does work. 

2) From the same function, I noticed that if I don't specify the turbulence intensity, I get:

"turbulence_intensity is not in the WWC and no explicit value was passed"

which reading from the documentation, should be automatically retrieved from the wwc. Is the TI not calculated when using the linear model?

3) I also have a question regarding the predict_wwc input parameter adapt_gwc.  From the documentation I read: "Adapt the standard heights and roughnesses in the gwc to match  those of the input and output site_effects."

But how do I know which values are being used? I would like to be able to specify my own values, similarly to what I have found in the deprecated function: 

def generalize_and_downscale(
    bwc, topo_map, output_locs, generalize_kwargs={}, downscale_kwargs={}
)

4) Lastly, I noticed that calling predict_wwc consumes 3 runs instead of the 2 specified on your website. Did you recently make any changes to this?

 

Best regards

[Neil Davis]

Hi Alexandru,

Thanks for the issue report. Can you let us know what version of pywasp you are using? We will then take a look and get back to you.

Best,

Neil

[Alexandru Guntner]

Hi Neil,

I'm using version 2.0.0.

Best regards

[Rogier]

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

 

[Alexandru Guntner]

Hi Rogier,

Thank you for the quick response. We would appreciate it if you could fix the issue with the counting runs as soon as possible, as this is important for our company.

I have a further question regarding the configuration of the climate parameters in PyWAsP. I know that the T-star stability model has been introduced in WAsp 12.8, but sometimes we still prefer to model the old heat flux over land parameter (in the EWA profile model) to match measured vertical profiles.

How can I do this in PyWAsP? I want to keep the latest flow model and change the heat flux. I tried this:

config = pw.wasp.Config("WAsP_12.10")
config.climate.set_profile_model(2) #WAsP 12.7 with EWA climate model
config.climate['off_hfx_land'] = 0

I find the explanation in the user guide a bit confusing. Sometimes WAsP 12.7 is referred to as "1", but then I also see that the numbers go from -1 to 3 (see link 1 and link 2). Can you give some clarifications on this, please?

Best regards

[Bjarke Tobias Olsen]

Hi Alexandru,

Regarding 2) above:

The linear flow model does not use or estimate TI, so potential_aep needs it from another source, either added to the WWC object as a new variable called "turbulence_intensity" or explicitly in the function call as a kwarg.

Regarding 4) above:

Yes, you are right. We will update the docs to accurately reflect this fact. It has always been like that, but I can say that going forward, we are strongly considering simplifying run counting.