Duncan

Hi, I think that the general recommendation is that you should calculate and use your GWC (wind atlas) in the same project. But in principle they are portable between projects if the general conditions are sufficiently similar. So you can use part of the map in one project where you calculate the GWC, then save it out to disk and use it in another project where you use a different part of the map. The WAsP program can now handle extremely large maps, but remember that there is unlikely to be any modelling benefit from including high-density information far away from the sites of interest. Delta-RIX corrections are not performed automatically by the program. What data source is offering different winter and summer roughness? These can be very good, but you need to split the climate data into equivalent seasons, perform two calculations in WAsP and then make a weighted average of results. Have you considered attending the WAsP course? It sounds like you have a lot of questions which would be answered properly there.

Hi Imran, Thanks for your suggestions. There are several feature requests there, it seems. WASP CFD (WAsP 11) was indeed released in Spring 2013, so is now available. In WAsP 10, there is already a facility to draw turbine radius circles on the map display. There is a button on the spatial view toolbar for this. We are not yet supporting automatic Delta-RIX corrections in the program. There is on-going scientific debate about whether this should be implemented as an automatic step. What kind of situations are you hoping to see improved wake loss calculations? If there are multiple met. stations which can contribute wind climate information to a resource calculation, we still feel that the decision about how to reconcile them is an expert decisions which must be made manually: there is no automatic method that should be offered. But we could perhaps change the program to simplify the process. What's your method in such cases?

Thanks for posting about your problem - and your solution! Duncan.

The calm threshold is an interesting issue. Let's assume that both the direction and speed measurement instrument have the same calm threshold. If there are some measurements where the speed falls below this threshold, we lack information about these records: 1. The direction is completely unknown. 2. The speed is somewhere between zero and the calm threshold. These records can't be ignored, but they can't be treated in the same way as the others. The records are distributed uniformly with respect to direction (they are evenly distributed among the direction bins.) I think that the speed for these records is assumed to be half the calm threshold, but I am not completely sure. As far as I understand things, the important thing to register is the proportion of the time when the wind speed is very low. For AEP, the actual speed is unlikely to be significant. Note that in WaCA, you can specify a separate width for the first wind speed bin of the histogram. I think that you should ensure that your first (lowest) wind speed bin upper limit is at least the calm threshold, so that all calms get bundled in to the same (first) bin.

I don't know about the availability of free data. Perhaps someone else can help. WAsP doesn't display the all-sector Weibull because that is a depreciated result. For all-sector numbers, we use the 'emergent' distribution which is different combination of sector-wise results which may legitimately result in a distribution which is not Weibull-shaped. We still show the A and k parameters of the combined Weibull distribution in the graph, but these numbers are greyed and are just for reference against older data. We draw both the emergent and the combined distributions in the graph, and they are usually a good match so it's not clear that there are two lines.

Do you know why the distribution is bimodal? Is there strong seasonality in the time series data?

Hi Hans Peter, In different versions of WEng, it's been done slightly differently. In WEng 3, the slope angles are coming from the LINCOM flow model analysis somehow. I'll ask my colleague Qiangbing to add a bit more detail describing what happens. At some point in the past we were using a separate algorithm which used some spline fitting on the elevation surface, but I'm not sure which versions of WEng actually applied that. HTH, Duncan.

Hello, Thanks for reporting this. A couple of other people have experienced something similar. We are trying to reproduce it and come up with a fix. Sorry for the frustration. Duncan.

Hi Utku, No, the values are the U and PD, which are not affected by the wake modelling. Duncan.

Hello again, If you apply weights to the monthly annualised AEP figures you have calculated, then the weighted sum is about 1059K: almost a match for your 1060K value. I think that the six months for which you have two sets of data (Feb-Jul) should be doubly-weighted before summation. Month Annualised AEP /12 Data months Weight Monthly weighted Jan 85580 1 0,666666667 57053,33333 Feb 83446 2 1,333333333 111261,3333 Mar 76854 2 1,333333333 102472 Apr 76684 2 1,333333333 102245,3333 May 79044 2 1,333333333 105392 Jun 81841 2 1,333333333 109121,3333 Jul 99106 2 1,333333333 132141,3333 Aug 119908 1 0,666666667 79938,66667 Sep 114360 1 0,666666667 76240 Oct 111491 1 0,666666667 74327,33333 Nov 87186 1 0,666666667 58124 Dec 75446 1 0,666666667 50297,33333 Sum 1090946 18 12 1058614 If you also correct for the different months having different numbers of days, the match improves slightly more. Effectively, when you are using a tab created from the entire 18 month time series, you're double-weighting any tendencies which are related to the summer season. So to make the monthly numbers match, you need to replicate this bias. I think the rule is that you should only take 12 complete months when calculating an input climate for WAsP. Of the two 18-month results you've produced, I guess that the "sum of months" one is less wrong. Using an 18 month time series to calculate AEP is definitely not correct. Maybe one of the WAsP scientists can clarify this?

Can you explain what you have done here? Do you have continuous data from February 2012 to July 2013? (18 months?) Do you have no data from October, November and December 2012? (15 months?), or were these omitted from your screenshot? Are you calculating separate tab files for each month and then making separate GWCs/Atlases? Are you making per-month tabs and atlases (so you include data from March 2012 and March 2013, for example)? Are you applying weighting according to the different number of days in each month?

Have you downloaded and installed the WAsP software? The software includes a Help file (CHM) which explains the basics of WAsP and contains references to further, more detailed material.

Hello, I don't know anything about the NCDC data, but I can tell you a bit about the way WACA handles the data. The averaging interval is not actually used by our analysis code, but it's recorded and preserved along with the data so that you can check it later from the OWC reports in WAsP if you need. Typically, the averaging period (sampling period) is the same as the recording interval ("stride"), but this is not necessarily the case. Missing data are OK if they are relatively few, and more or less randomly scattered over the time series. If you've got a solid bunch of data missing then you might decide to reject the whole year in which it falls. It depends if the missing data are biased with respect to the annual climate. The minimum wind speeds and variable directions are both questions of calms. The variable wind direction probably means that the wind speed has fallen below some threshold for the vane to work properly. This may or may not be the same as the speed threshold for the anemometer to work properly, but they are often treated as the same. If the minimum wind speed in the data set is 1.5 and then you have lots of zeros, then I'd assume that the calm threshold has already been applied. So in the WACA, set the calm threshold for both data fields to be 1.5, and proceed. I would say that 1.5 is pretty high. In the WAsP system, the mast and boom shadow would be corrected for when the GWC is analysed from the OWC data. There's no directional-dependent way to adjust the data in the WACA. This doesn't answer all your questions, but I hope it helps with some. Duncan.

Hello, Yes to automate WAsP through VBA (or any other programmatic client) you need a special type of licence called a developer licence. I think that you can't create classes in VBS, but you could create your own in another COM-compatible language and then reference them from your VBS script. VBS does support subs and functions, as far as I know. I think when VBS automates Excel (for example when writing report results), the Excel application is running in its own process, and cell content updates should appear as soon as the script writes a value. HTH, Duncan.

Ok I can help with this problem. Let's take this conversation to email. Sounds like your Windows re-install fixed the WMI problem, at least. Duncan.

Hello, I don't know if re-installing windows is necessary, but it might well be the best thing to try. On Windows 7, a full OS-reinstall is almost never necessary. I must say that in 15 years of WAsP for Windows, it's never happened that a problem with WAsP has made an OS re-installation necessary. I expect that if something broke in Windows, then this caused the problem with WAsP, rather than the other way around. At least I sincerely hope so. You've tried some fixes already. WMI is a bit of a mystery to me too, to be honest. If you fire up Services, you'll see Windows Management Instrumentation listed there. Is that running ("started") and is everything OK? Sorry I can't offer any more useful help. An upcoming update to the WAsP licencing system will probably make WMI access unnecessary, but it will take a while to get ready for release. In any case, your PC problems might be more complex.

Hello again, The message "No WMI" when you try to register the licence is happening because the licence system can't talk to the WMI : the Windows Management Instrumentation. Some (only a few) users have problems because this WMI has been disabled by SysAdmins for security reasons. If it's been working OK before, and you've not made any settings, I wonder if it's worth trying simply to restart the computer. Have you done that?

Has anything else changed on your machine? Have your Systems Admins made some security setting changes? Are you seeing problems with any software?

How big is the resource grid? How large is the map? Are you using WAsP 9, 10 or 11? Please mail the contents of "Help > WAsP on this computer..." to me, and we can check some file versions. Duncan.

Hello, sorry that you've had trouble. Before these problems started, did you have WAsP 11 working and licenced OK?

Steve, I'm not sure that I understand yet what you're trying to do here. Are you planning to use multiple wind atlases to calculate predicted wind climates (PWCs) for the turbine location, and then apply distance weights to these PWCs to get some kind of weighted average PWC for the site? There are two issues. First is the 'WAsP-ology' question. Perhaps one of the scientists will clarify this. I'm not really qualified to advise, but I think that this approach is not recommended. I've heard people discussing several times the question of what should be interpolated and the answer always seems to be the generalised wind climate, not the site predictions. The second question is how to do it if you really want to. You can't extract a lib file at the turbine location: there's no such entity. The Turbine Site window has a 'Wind' results tab. You can copy all the results data into the clipboard for each lib prediction, and then assemble the data into Excel. This would give you one predicted wind climate rose from each lib. There's no tool available as part of WAsP to perform an interpolation of these data, so you would need to devise your own method. Hope that's helpful, Duncan.

No, it's done in WEng. The results of the turbulence simulation are saved to file and used by the WAT later.

Hello, WEng 3 and WACA 2 introduced a new method of calculating u50max which is not sector-based. This was to eliminate some logical inconsistencies in the old method. The u50max is no longer directional. Several (sometimes many) different directions are modelled, but only to discover the maximum wind speed from any direction during a given period. This is then used in the Gumbel extrapolation to estimate the 50 year maximum. Best wishes, Duncan.

Bepi, Morten is on holiday for a couple of weeks. I'm sure he'll get back to you with a full answer, but meanwhile I can confirm that WEng is generating simulated turbulence statistics. The velocity derivatives from the flow model (LINCOM)are used to simulate the turbulence at a site, and this is carried into the WAT calculations. Duncan

Hi Jan, I'm using 64-bit windows 7. We usually test on both, but I was reporting above only on a quick test I did on my own machine. I'm glad you managed to work it out, but sorry that you needed to jump through some hoops. To be honest, I don't understand what happened on that PC and why you needed to do anything special in that case. The dongle and driver we're targeting is really ancient. We'll be supporting WAsP 10 for another 9 months or so, but after that only WEng 3 and WAsP 11 will be officially supported: both of these use an internet-driven licencing system. We'll really be trying to forget all about the dongles, and we hope that users will upgrade to use the new licencing system.