Limit on number of projects in a workspace?

[jfcorbett]

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

[Duncan]

Hi JF,

There's no deliberate limit set in the code on the number of projects. We never envisaged there being more than a handful in one workspace, though. Maybe if you report the error message here I'll be able to work out what's going wrong.

Do these projects contain much data or are they fairly light? Do they have lots of sites? You could try just adding lots of empty projects and see whether you hit a limit. If not, then it points at some kind of memory limitation.

Best wishes, Duncan.

[jfcorbett]

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

[jfcorbett]

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.

[Duncan]

Hi again,

WAsP doesn't have any smart code to detect replicate data and save only one copy to disc. Are you doing that yourself? Just referencing the same map file in the wwh from multiple places in the inventory? For sure, when you open this workspace, each map will be loaded into memory as a new instance.

It does sound as though we could reorganise the code a bit to save some memory in cases like this, but to be honest I've never heard of anyone else using the program in this way. It's not wrong, of course, but definitely unexpected.

I wonder it's worth re-considering the approach. 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. The scripts can manipulate workspace objects as well as simply generating reports. Your script can link to and from an Excel spreadsheet, so it's possible to set up a list of different input values and work through them all, dumping results back to the spreadsheet as you go.

Or could you perhaps re-organise the hierarchy, so that all the work is done in the same project, with different turbine clusters associated with different wind atlases. Whether this works depends on what you're varying between different projects. Of course if it's model parameters, then you need a script.

[jfcorbett]

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.)

[jfcorbett]

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.)

[Duncan]

Hi JF. We have documented the WEng scripting interfaces, but unfortunately there is no equivalent documentation for WAsP. But some of it is generic so you might like to have a look at the WEng documents (http://www.wasp.dk/Download/DownloadFiles/WEng/RveaScripting.chm). Note that if you download a CHM file you may need to 'Unlock' it in the file properties dialog before you can read it.

Meanwhile, our strategy is to just help people directly (and if possible publicly) with any WAsP scripting questions they might have. So could we perhaps take this converstation to the 'Scripting' part of this forum and continue working there? If you could explain what you want to achieve, then we can try to post some useful snippets of code to show how it can be done.

I think that absolutely anything that can be done in the WAsP GUI can be done in a script. It's just a question of how...