Good to hear that you were able to solve the problem.

Cheers, Morten

]]>Hi,

The ‘Prepare data for WAT tool’ calls some WAsP DLLs to add mean climate predictions (Weibull distributions) to the result table for each turbine site. That is why it asks for a wind atlas file and a map in vector format. The format of the wind atlas file has changed over the years and I suspect that this could be the reason for the problem. I did some experiments and it seems like the WAT launcher tools reads the old LIB format without problems. It also reads a GWC file exported from WAsP 11 correctly but I did not manage to get it to read a GWC file exported from WAsP 12. The GWC format differences are the barometric reference data added in WAsP 12.0 and parameters for the background flow profile added in WAsP 12.1. Since you write about temperature and pressure information, I am guessing that you are in fact using WAsP 12, so your problem is probably related to the modified GWC file format. A work-around solution could be to apply the LIB format instead. If you are worried about the accuracy, then try to compare the Weibull distributions in your WAsP project and the ones which are written in the input file for WAT.

I am not sure about the technical reason for the problem, and I rather not ask the programmer who is on vacation right now. Maybe WEng 4 can only work with the DLLs from WAsP 11 or maybe it gets confused when you, like me, both have WAsP 11 and WAsP 12 installed on the same PC. Anyway, thanks for reporting this. I shall forward the message to the programmers.

Cheers,

Morten

Hi Morten

Thanks for your quick answer.

Now, I made a project with Wasp 11.6, and i exported *gwc file.

And it works :)

Like you said, my problem related to Wasp version.

Sorry again for the delay. I finally had time to look into this properly.

IRveaProductionRose.SectorForIndex(SectorIndex).GrossContribution is calculated by folding the power curve with the Weibull distribution for that sector, using a gamma function integration. The result is multiplied with the number of hours in a year, and then multiplied by the sector frequency.

IRveaProductionRose.SectorForIndex(SectorIndex).ProductionDistribution.ProductionForSpeed(Speed) is the probability of that speed (from the Weibull distribution), multiplied by the power for that speed (read off from the power curve), multiplied by the number of hours in a year.

If I understood your message correctly, you wanted to emulate the GrossContribution but summing ProductionForSpeed for a range of speeds and multiplying by sector frequency. In principle, that will give a similar value, but in practice the emulation result will be sensitive to the integration step if you’re looking at an extreme part of the Weibull distribution and have a funny power curve.

I tried to show this by doing something similar to what you reported. I made a power curve where there was uniform power delivered only between 15 and 19 metres per second. Then I applied this (with no air density correction) to a site from the Canela sample workspace. I have uploaded the workspace here

http://wasptechnical.dk/Services/Redire … 46f31af590

and I have put a screen shot of the site power prediction here

http://wasptechnical.dk/Services/Redire … 06325c5496.

I guess this is a slightly less extreme case than yours, because more of the Weibull distribution will intersect with the range 15-19 m/s compared with >19 m/s. It’s also clearer because the power curve is perfectly rectangular (if you remember to turn off air density corrections): either there is no power, or there is exactly 1MW.

Let’s look at sector 4, where the Weibull A, k and f are 9.982139, 2.529297 and 0.097123 respectively. For sector 4 the gross contribution is 46483550 Wh. This is confirmed in the WAsP user interface. This is the ‘official’ answer.

We can ask the production rose about the production for speeds from the sector. If we iterate from 14 to 20 metres per section we get the following yields:

Speed: 14 0000000000

Speed: 15 0251475900

Speed: 16 0168905800

Speed: 17 0107288600

Speed: 18 0064389630

Speed: 19 0036474820

Speed: 20 0000000000

One can try to emulate the sector gross contribution by summing these values and multiplying by the sector frequency. In this test case, the result is 61045199 Wh. This is indeed quite different.

There’s nothing wrong with the method, but the numbers don’t match because the integration step in our emulation here is far too wide at 1 m/s. This step cannot hope to capture the actual shape of the Weibull distribution as it overlaps with the power curve in this speed range.

When I reduced the arithmetic integration step, the summation result started to converge with the GrossContribution result. At a step of 1/10000, the production summed to 46483685 Wh. This is very close to the ‘real’ gamma function version.

Does this explain what you have observed? I think that if you have a more normal power curve - and are concentrating on a wider part of the Weibull distribution - the correspondence is closer. But when you are looking at a strange part of the distribution, and applying a funny power curve, then you can see this divergence.

I hope this answers your question about how the values are calculated and that this explains why the numbers differ. If you’ve got some data that can’t be explained by this, then send them to me and I’ll run the same analysis on your numbers to check I’ve got things right.

Best wishes, Duncan.

]]>The extrapolation is done in two steps. First we correct the wind speeds of the reference points of the original power curve. For a decrease in air density, this shifts the power curve to the right, but we take care of not moving the point at the cut-out wind speed.

We then interpolate the shifted power curve and find new values at wind speeds with regular spacing. I have seen one case where this interpolation failed because the interpolation function was forced into unrealistic undulations. The problem was an unconventional additional reference point near cut out inserted by the user. It did not use to disturb WAsP but fooled the air density correction method. If you like me to investigate the problem then please send a WAsP workspace file illustrating the problem to waspsupport@dtu.dk.

Best regards,

Morten

Have you updated your software to the latest version?

http://www.wasp.dk/Download/WAsP12-Suite-Installer

Best regards,

Niels]]>

Sorry I wasn't explicit enough... I was actually asking about anemometer classes according to IEC 61400-12-1 Ed.2 (Annex I, Table I.1) in which anemometer class depends on turbulence structure.

Thank you once more!

Regards,

Sinisa

Further, would you know if a site (url) that identifies the level of error or deviation at each stage of WAsP’s calculation, if the calculations are within the operational envelope?

]]>WAsP CFD is not free. However, if you are a student at DTU then please ask your supervisor to contact the WAsP group about your needs.

Unfortunately, I am not DTU student.

It means that, I can not use it as far as I understand.

]]>Issue #2: Problem not solved. But since the cross points and nodes are less, the map image refreshing is not a big deal.

Issue #3: Would really appreciate if you could assure that those warnings are handled correctly by me.

Last issue:

Add and replace function did not work when I tried to combine KML file and the SRTM file. So I converted the KML file as a standard map file. Then added that file to the SRTM file. And simply saved it.

Oh I have reduced the SRTM map size. So the process is faster.

New doubts:

I have digitalized the map in GE (drawing polygons - the terrain was disabled) and created a KML file. I have fed roughness info to the downloaded KML file - after converting it to a standard map file.

My issue is, the polygons do not contain orography information (assuming since the terrain is disabled while drawing those polygons).

So my question is, should I enable terrains while drawing those polygons on GE? Or no need?

]]>Changing the WTG density to 1.17 is an option. But that power curves were not estimated at that density. So I am kind of lost here. I am worried about the errors in estimation.

Any methods to solve this?

]]>