Duncan

The OWC wizard is not trying to interpret the time stamp, so that probably explains why it was able to handle the file. Can you post the first line of the data part of the file here, please? Duncan.

Good points. Thank you.

Hello, thanks for your comments. We'll certainly consider a more thorough implementation in our next-but-one-release, and your thoughts will help. We did consider this question of automatic interpolation of power curves, but we were reluctant to take responsibility for that operation in our code. If the manufacturer doesn't offer the curve for that air density, then you will need to do it yourself. What we could offer is a way to do that in the turbine editor utility program, but it would then remain an explicit operation which you've invoked rather than WAsP generating the numbers automatically. Does that sound useful?

OK, I hope that everyone who has asked has now been sent the information they need. Please contact me if I've missed you somehow!

Hello, I share your frustration! We can see that the data we need are there, being used to render the terrain on our screen. But as far as we can see from the Google Earth API, these numbers are not available to our code. So we can't extract them for you, even if the licencing situation would permit that. The GE data are derived from the SRTM mission, I think, so it's the same public domain data you can get elsewhere.

I expect you'll get a proper answer from one of the scientists, but in the meantime I can say something from the technical point of view. Reducing the size of the map is by far the most effective way of speeding up calculations. But it's not easy to say how much information can be safely removed without affecting the results. It's the number of data points in the map, not the area covered by the map which is significant. For any reasonably large map, if you reduce the number of points by half, the calculation speed will double. In terms of distance from the sites, I understand that roughness change information should extend as far as possible. It's possible to construct a map in which the roughness information layer is much larger than the orographic layer, and that's fine for WAsP. The safe distance to the map edge for both orography and roughness is a function of the hub height, I think. If you want to maintain safe distances but minimise the data volume, then you can construct a circular map. (The map editor supports this). That can reduce the amount of redundant information by about 20%. But most of the redundant information will usually be contained in high-resolution elevation contour data far from the site. More distant orgraphic features are less significant for the site effects (all other things being equal), so it's worth concentrating the data around the sites. Further away, you can thin the lines: removing contours and removing points. Again, the Map Editor can help here. If you've got high-resolution roughness information, it's not so easy to thin out, but a small stand of bushes 20 km from the site is unlikely to be significant. A shoreline 15 km away is relevant.

WAsP 9.1 build 0036 is now generally available for download from the wasp web site. http://www.wasp.dk/Download/Software/PreviousInstallations.html

OK I see that the latest WAsP 9.1 has not actually been uploaded for public release yet. We'll push on with that. Meanwhile, I'll email you a link for downloading the latest one directly, and you can check to see if it helps with this problem. Duncan.

There was a bug something like this, but I think it was doing wind farm calculations twice under some particular circumstances. I have just tried on 9.01.0036 and I cannot see any behaviour like that. Can you describe in more detail what happens?

The components used are all WAsP 10 versions, so you need a WAsP 10 licence. You don't need WAsP 10 installed, though: it's a standalone program.

Sorry that your three responses have gone unanswered during our holiday time. We'll reply to you all this week with download info and instructions.

Hello, Sorry about this. The error message is a rather generic one which does not tell us very much. Do you have a full error report with more information? The best thing would be to send us the data file (or first couple of hundred lines from the top of it), and we can try to reproduce the error. Duncan.

Hi Fernando, The man who can give a definitive answer is on vacation at the moment. I'm sure he'll get back to you when he returns.

If you search for "roughness" in the WAsP help file, you will find several useful pages describing how the roughness inputs can be prepared, and how to judge different landscape roughnesses. If those don't help, post back here with some more detailed question, and we'll try to help.

Are all of the values systematically higher? That would indicate a problem. If the maximum values are different between the maps, then it's not so surprising if the nodes of the grid map fall on different co-ordinates. To check this, you can put sites on the exact co-ordinates of the maximum value node in each map, and see what the predicted speed is for each.

As far as I am aware, there is no student licence for WAsP. Sorry, Duncan.

OK. This sounds like a bug in the script. We'll investigate. Thanks for the report.

No, there's no such function built-in. Two instruments makes for two climates, I'm afraid. You need to decide how to resolve them. I'm assuming that you have two contemporary time series, one from each instrument. In general, the 30m measurements are more useful and reliable than the 10m measurements. You could use WAsP to generate two wind atlases, one from each height/OWC. All being well, these should match each other closely. If they don't, then I'd use the 30m data set. If, on the other hand, you've got a long time-series of 10m data and a short, overlapping, series of 30m data and you want to generate a long time-series of 30m data, then you're asking for something different which the WACA doesn't support at the moment.

Sorry but I don't really understand this. Did the script run without errors? After the script executed, you should have a grid map (GRD file), right? What do you mean when you say that the result showed the map was opposite direction entirely? Was the grid map up-side down and back-to-front? Which program did you use to look at the grid map?

Hello, I think we need to see the elevation map which is not being displayed. Can you right-click on the "Elevation grid" in the project heirarchy view and select 'Export the grid map to file'. Does it save OK? If so, then please email it to me at duncan.heathfield@wasptechnical.dk. If not,then just email me the whole project.

Does this happen reliably and repeatedly with particular files, or does it happen only erratically? If it's reproducable, please send us a copy of the workspace file, we'll be able to have a look at what's wrong. As far as I know, no one else has experienced this problem.

Yes. Anyone is welcome to join in.

This sounds like the installation was not successful. Did you see any error messages when you ran the installation? Can you also check that you have downloaded the latest WAsP 9 release?

Hi, I haven't looked at OpenWind for a while, but I wanted to suggest a way of trying to work out what's happening. You could make (using a text editor) a WRG which had completely uniform values: same A, K, F for each sector and site. Then any differences you see from what you expect would be easier to understand. That's assuming of course that OpenWind is using the sectorwise distributions and folding these with a power curve, and not just the all-sector AEP. But you could do the same with the AEP: same round number for each site in the grid, and see what's happening. Does that help? Duncan.

Hi. I'm not really qualified to answer this, so maybe someone else will contribute. I guess you've read the WAsP in the Forest guidelines (http://www.wasp.dk/Support/DownloadFiles/How%20to%20handle%20forest%20in%20WAsP.pdf) For what it's worth, I'd suggest that it's quite possible for a forest to have a roughness length of 1m or more. So I wouldn't get too tied to this forests=0.5m figure. Depending on the canopy structure, the displacement height could be something other than 2/3 stand height. Both z0 and dzero depend on wind speed too. What do you know about the forest? Is it slow-growing, close-packed coniferous forest (easier to model)? Or is it mixed-height, mixed-species, varying-density deciduous woodland (harder to model)?