Duncan

In WAsP 9, the air density is only used to label a WTG performance table. If you open the window for the WTG hierarchy member you should see that each performance table has an air density property. If there are multiple performance tables, then you can select which one to use for the AEP calculation. In WAsP 10 (not earlier versions), you can set the air density for a whole project. To do this, right-click on the project icon and select "Edit project configuration". Find the section called 'Ambient climate' (near the bottom of the list). There you can edit the air density. Note that this changes the displayed power density values for all members of the project. All members are affected in the same way, even though they might be at different altitudes/temperatures: we don't apply any kind of lapse rate automatically. Note also that change this will not affect calculated *production*, because the air density is a property of the power curve/ performance table selected for the WTG. The program will, however, highlight any power curves which have an air density that does not match the project setting. As well as a message to discuss the problem, the WTG hierarchy member icon is tagged with a small purple warning mark. This is a new WAsP 10 feature, and we're keen to know whether people find it useful. Would a more explicit and automatic treatment of air density be better? If so, how could it work? Everyone is welcome to make contribute thoughts on the Ideas and Suggestions forum.

OK I think I understand better now. Whatever the workspace arrangement, there might sometimes be cases where it's convenient to have the same map appearing in two different places. So saving that workspace will always mean compressing and saving redundant information. I guess we could introduce some kind of equivalence check and save just one map to file. That would be quite straightforward. Your particular case can't really be avoided by re-organising the hierarchy. WAsP rather assumes that one project/one atlas is the normal use case. But I wonder if you could pre-calculate the wind atlases, and then remove their OWCs and maps? Unless you're going to update the data, the atlases won't change.

Hi, I am just WAsP 8.03.0037 on this Win7 64 bit machine. It seems fine.

Well if you choose the wrong projection info, things will not go well in any case. But it seems that more generally there is a problem with the transformation code in some cases. Whereabouts are your data? Which projection system are you using?

Hello Malik, Thanks for the bug report. Sorry about this. There are some problems with getting the Google Earth stuff to work in some parts of the world. This error message sounds rather familiar, so I think you have encountered the one of these issues. We are working on a fix and should have something ready soon. Can you confirm that the standard Portuguese sample project opend OK with correct Google Earth display? Duncan.

I'm sure that WAsP 10 doesn't add support for what you need, so don't worry about that! But I'm intrigued by your problem, and I'm not sure I understand the workspace arrangement. WAsP doesn't offer any automatic way to reconcile multiple atlases generated by multiple masts. If you have multiple atlases, then you probably have multiple projects in one workspace. Is that right? Do you have the same arrangement of turbine sites in each of several projects: one for each atlas? Maybe I'm confused, but I think you could do it this way.. Create a workspace with a project in which you have your 2010 map. Then add an atlas, with a met station and OWC. This is one of your masts. Then insert your turbine sites as a wind farm. Right-click the wind farm, and select 'Extract locations and copy to clipboard'. Then right-click the project and choose 'insert turbine sites from the clipboard'. Do this twice to set up three wind farms with identical sites and heights. Now, under the new wind farms you can insert different maps (2020,2030). The original wind farm will use the project map, but these other maps will override the project-level map for the other wind farms. So your project can give you predictions for each decade. But so far you're only using one mast. If you drag out the current wind atlas to the workspace level the met station and OWC will go with it. They can just sit there peacefully until you need them again. Now you can insert a new atlas, and use the second mast location and data. It will pick up and use the project-level 2010 map. You can keep doing this until you've got all nine atlases and masts in the workspace, and all three decade predictions in the project. To use different masts, just drag the relevant wind atlas into the project. The one it replaces will be automatically bumped out to the workspace level, so that's a fairly convenient way to switch between different masts. Does that help/make sense? Would you actually like direct support in the software for roughness length evolution over time? How are you going to choose which of the nine mast locations to use for your AEP predictions?

Hello, none of the various version of WAsP currently available support multiple processors: each running instance of WAsP will use only one core. Upcoming versions will do a better job, and we're planning to release a utility program which will help people doing huge resource grid calculations to take full advantage of all their processors.

Hello, WAsP 8 with Win7 64 is not a combination we've tried, but I can't think of any reason why it would not work. WAsP 8 works on XP (of course) and there is an XP emulation mode for applications in Windows 7, I think. But it's not a huge job for us to try it out explicitly. We'll do that and post a comment about the outcome here.

Hello, I guess that you want to derive some corrections between the long-term regional data and the short-term site data, and then apply those to the regional data to give you long-term site data? This kind of thing is called measure-correlate-predict. There are several (even many) different ways to approach this MCP task. Sorry to say that none of our WAsP software will currently do this for you. The WACA might be helpful in getting the data parsed and calibrated, though. Is there any particular reason why you can't use the reference data to calculate a Wind Atlas in WAsP and then apply that to the project site?

Hello, Sorry for the delay in replying. If you go to Tools... Options... and select File operations, you'll see a setting called "Path for scripts folder". What does that say? Click the button to change it and make sure it's pointing in the right place. Then (you may need to restart the program) WEng should see the scripts. I don't know why you've had this problem. The installation should have set up the correct path for you. Good luck! Duncan.

Hello again, I did a few simple tests and (as far as I can see) roughness roses are working correctly as perfect substitutes to the equivalent map data. Note that if a roughness rose is used for a site, this overrides completely any associated roughness data from the map: it's an alternative not a supplement. You might be interested to have a look at the reference site hierarchy member. This lets you examine the roughness rose which WAsP derives from the map: click on the "Roughness survey" tab to see it. It might be useful when you want to check how WAsP is interpreting your map data. Another place to get some insight is the "Site effects" tab of the met.station, turbine site and reference site windows. Your experiment which gave AEP predictions of 13.2, 11.0 and 10.6 sounds OK to me. The reason for these differences is likely the height difference between your met station and turbine site. If you set these to be the same, then you're essentially performing a self-prediction and you should see the 11.0 and 10.6 values converge. The model might introduce a slight discrepancy in the self-prediction as the roughness changes between 0.3 and 0.03, so they may never match precisely. The surface roughness has a greater effect at lower heights. So if your met. station is at 58m and your turbine site is 80, then assigning a longer roughness length to the area will increase the predicted AEP. You write that... "When you measure wind at a mast, you are finding the wind speeds empirically. To say that they WOULD be higher if not for the given landscape is moot: the given landscape exists and is inextricable." ... which I think reveals some confusion about the principle of modelling in WAsP. (I'm assuming you are using "moot" in the US-English sense to mean practically irrelevant.) The WAsP approach is to estimate the site-specific effects and then remove them from or apply them to a wind (or more precisely a wind PDF). So I'm afraid that WAsP's calculation of a wind atlas from measured wind data is doing exactly what you regard as counter-intuitive, and that's pretty much the basic idea of the model. I hope that helps to explain the program behaviour.

Before replying, can I just check whether the heights of your met. station and turbines are the same, and how far away are the roughness change lines?

Hi JacksonLord, I'd like to try to answer part two of your question. As the aerodynamic roughness length around a site increases, the wind you'd expect to measure there decreases. The wind atlas calculation is taking observed wind data and cleaning them for site effects, so the 'cleaned' wind for a rough site will be faster than for a smooth site. For the same measured wind speed, the site-cleaned wind will be higher as the roughness length increases. For example, if you measure 10m/s just above a forest canopy, then the general conditions must be very windy to produce that measurement. The data in the wind atlas are trying to capture or express these 'general conditions'. Does that help? I hope that I understood your point correctly.

After an extraordinarily long delay (sorry), here's an answer to your question. When you call 'Execute' on an insertion object, you get a reference to the inserted hierarchy member, but only its generic type: IHierarchyMember, which has the description and other basic properties. To see the resource grid members, you need to typecast your reference. You can use the ReportingAssistant.TypeCaster to do this. The code will look something like this: Set NewMember = Project.AsIHierarchyMember.Insertions.New.ByClassID(ehmcResourceGrid).Execute Set ResourceGrid = ReportingAssistant.TypeCaster.CastMemberToResourceGrid(NewMember) To set up the grid, you need to call the method 'EditGridSpecification', passing in an IRveaGridSpecification object. To get one of those, you can use an object factory in a DLL called Rvea0086 (in WAsP 10 you could use Rvea0138). An example can be found in the Turbine Site Vertical Slice script. Set Rvea0086Factory = CreateObject("Rvea0086.ObjectFactory") Set GridSpecification = Rvea0086Factory.CreateGridSpecification(0, 0, CountOfPoints, CountOfVerticalSteps, Resolution, False) Hope this helps.

Well, you're asking a modelling question now, and I'm not really competent to advise. Maybe one of the scientists or other WAsP users will chip in with a suggestion. I can point out, though, that it's quite easy to experiment. You can set up several grids at different resolutions covering a small sample area. Then you can see for yourself what effects (if any)arise from different sampling densities. HTH.

While you're configuring the resource grid, the number of nodes is calculated. If it exceeds 10K, the displayed number turns red. But that's just a warning, not an actual constraint. You can still do the calculation. This is a vestigal feature from version 8. I think the idea was that if you increase the resolution without changing the size of the grid, it's easy accidentally to configure huge calculation task. Now our computers are more powerful, and people's projects are getting bigger. In WAsP 9, we introduced more intelligent management of the existing resource grid results which make it less of a disaster to make a mistake in your configuration. The warning colour is probably unnecessary now, I'll add a feature request for the next release of WAsP 10 to remove the threshold. (Or to increase it to some number which is huge by todays standards, not those of 2002!)

Get an iterator (ITurbineSiteGroupIterator) from the IUnstructuredTurnineSiteGroup. Each member is of type ITurbineSiteGroupMember, which has a property AsIHierarchyMember. On that interface is a Remove method. Does this tell you what you need? I can post a bit of sample script code if that helps to clarify things.