jfcorbett

Fabulous. This will save us loads of time and make WAsP that much more powerful. Thanks, JF

I was not aware of this. This will help a lot. I'm actually using WAsP 8. I'm guessing Rvea0072.tlb has the hierarchy member interfaces? However I can't tell which .dll contains the reporting assistant interfaces -- there are a lot of rvea####.dll's there. Any hints? Perhaps this very useful tip should be advertised more widely? I'm guessing that this resource may have been overlooked by some who have requested WAsP scripting documentation on this forum and elsewhere. I suppose that in most cases, the Object Browser trick would be enough to figure things out on one's own.

Is there an analogous way to test whether the currently selected hierarchy member is a workspace?

The self-contained workspace option sounds cleaner and safer. The larger file size isn't really a problem. It sounds like this is the way to go. If you could show me some example code to move maps back and forth as you suggest, then that would be great. Merry Christmas! Jean-François

Thanks, looking forward to the rest. JF

Forgot to add: 4. Adjust the standard heights (so that they match the mast and turbine heights).

I'd like to perform the following manipulations on workspace objects: 1. Change height of met station 2. Change hub height of turbine sites 3. Change map reference (If I include, say, 5 .map files in the .wwh archive, can I change which one the map object references to? The idea is that the roughness length values used change from map to map.) Would it be possible for you to show me some example code to do the above? Thanks!

Sorry, I wanted to be a bit more specific: The manipulations I'd like to do on workspace objects are: - Change height of met station - Change hub height of turbine sites - Change map reference (If I include, say, 5 .map files in the .wwh archive, can I change which one the map object references to? The idea is that the roughness length values used change from map to map.)

Hi Duncan, Yes, I am referencing the same .map from multiple places in the inventory. I knew that this wasn't the expected way of doing things, but I tried it out and it works, so at least I save disk space and a bit of zipping time. If you're running a vast number of generally similar calculations to experiment with small variations, then scripting might be a better way to go. That is indeed what I am doing. WAsP scripting would be smart... But since there is no documentation (or is there?), I find progress is slow and difficult. Nevertheless, I would like to do this. I've written a script to do all calcs and export results. But I don't know how to manipulate workspace objects. Do you have any pointers? I couldn't find any examples to emulate in the WAsP internal scripts (except "Set all projects' parameters to this project's values.was" but that is pretty limited.)

It does indeed look like it's a memory issue. I had a closer look at memory usage when opening the workspace. It grows and grows until WAsP occupies about 1 GB. I guess the above error message is WAsP's way of saying, not enough memory. In my earlier post, I forgot to add that this error occured for a workspace of 95 projects each contain a map, a wind atlas (with met station and OWC), and a wind farm (usually containing 2-5 turbines sites). However, I only actually include one .map file (7 MB when uncompressed ASCII) in the .wwh archive. But I guess WAsP makes an internal copy of this map for each project, thus filling up the memory? Still, 1GB is a lot.

Hi Duncan, I copied the error details below. On other occasions, I've been able to open a workspace and do calculations, but not save the calculated workspace. I'll see if I can reproduce this so I can copy the error details here. Thanks, Jean-François Exception report produced at 2010-12-09 10:53:17 bad allocation raised at: 2010-12-09 10:52:37 2010-12-09 10:52:37: Message added: Could not create a new WAsP machine 2010-12-09 10:52:37: Exception raised in: Rvea0044:cWaspProject:Class_Initialize 2010-12-09 10:52:37: Message added: (Class ID was 2) 2010-12-09 10:52:37: Message added: Could not restore a hierarchy member 2010-12-09 10:52:37: Message added: Could not open one hierarchy member 2010-12-09 10:53:11: Message added: Could not create a new WAsP machine 2010-12-09 10:53:11: Exception raised in: Rvea0044:cWaspProject:Class_Initialize 2010-12-09 10:53:11: Message added: (Class ID was 2) 2010-12-09 10:53:11: Message added: Could not restore a hierarchy member 2010-12-09 10:53:11: Message added: Could not open one hierarchy member Latest thread started in: Rvea0044:cUnstructuredTurbineSiteGroup:Class_Initialize

Hi, Is there an upper limit, formal or otherwise, on the number of projects that can be included in a WAsP workspace? I've been automatically generating WAsP workspaces by modifying the inventory XML code. I can add many projects to a workspace, and everything works fine, but at some point the hits hits the fan and the workspace won't open and WAsP spits out an error. This seems to happen at around 50-ish projects, but I haven't been able to put my finger on what the limiting factor is exactly. Any suggestions? Best regards, JF

Works like a charm. Thanks!

Hi Duncan, I wrote a WAsP report script that only applies to wind farm hierarchy members, so it requires a wind farm to be selected. However, I'll be distributing this script to many "civilians", and to pre-empt a million questions and "bug" reports, I'd like the script to appear in WAsP's Reports menu even when no wind farm is selected, in which case it would return a helpful MsgBox when run. I tried the code below, but this doesn't capture the error in VBScript but rather in the WAsP Script Debugging Assistant, hence no civilan-friendly MsgBox. Any suggestions? Is there a method that returns the class of the currently selected hierarchy member so I can test for it in the script? On Error Resume Next Set WindFarm = ReportingAssistant.CastableSelectedMember.AsIWindFarm On Error GoTo 0 If Err.Number 0 Then MsgBox ("Please select a wind farm in the hierarchy.") Exit Sub End If