Duncan

Wow. This doesn't sound good. I haven't heard of anyone having this problem before, though. You have a network drive for My Documents. What happens to that when you are offline? Does some local folder become the My Documents folder? I cannot understand why the program would become unresponsive in this case. It might be making a system call to that disconnected network folder, and be waiting for a response. But that would happen in any program (like Explorer) which tried to access the network folder, and eventually the wait should time out. You could try a registry edit to work around the problem. I suggest finding the key called HKEY_CURRENT_USER\Software\Risoe National Laboratory\Wasp\Version 10\User settings\File broker\Paths And deleting all values in that key. Also do the same with HKEY_CURRENT_USER\Software\Risoe National Laboratory\Common\Paths Then in the HKEY_CURRENT_USER\Software\Risoe National Laboratory\Wasp\Version 10\User settings\File broker\Paths key, add a value called "Path for any file" and set this to some reasonable existing path. The My Documents folder is only used as a fallback if WAsP can't find any other place to look for files. Setting this value explicitly should intercept that My Documents call, but I can't guarantee it. Please, let me know how you get on. This sounds like some rare case which we have not designed for properly. Duncan.

It's not a known issue, since we've never used Consts in these scripts, but in the context of a loaded workspace, this would constitute a re-definition of the constant, I suppose. Re-loading the workspace should clear the scripting context. What about just using a normal variable instead of a constant?

I have added this as a feature request for 10.1

Is it only this one project, or are you seeing the same error with other projects too?

Thanks for these. We'll fix the documentation. Meanwhile, I can confirm that HorizontalSpeed is the site-only variable, and Speed is for grids, so the text is wrong.

Hi, We were discussing your questions here in the office last week, and thought we should check that you know about developer licencing for WAsP. If the scripting environment is too constraining for what you're trying to achieve (which seems to be true in your case), then you could use a developer licence and get direct programmatic control of the WAsP Workspace object model. The developer licence lets you work with all these classes and interfaces without going through the WAsP GUI. So for example, you could start an Excel VBA project, add references to the WAsP DLLs and do the entire exercise there. This has an extra advantage of giving you a proper code editor and debug environment. This licence doesn't allow you to distribute what you build to others, but it sounds like you're just trying to do a big automation/experiment job on your own machine, and for that, it's perfect. To answer your question, though, I'm afraid there's no method you can call from a script to report progress back to the user. If your script is outputting to Excel, then you could update one cell to display the current progress.

How about putting it in the header part of the script file as an optional attribute to override the default? Then we can all be happy..!

OK Thanks for reporting. We'll check that our installation includes the latest drivers. I thought we were, but maybe there's been an update we haven't noticed. Duncan.

The message which appears is part of Windows, and is not under our control. But we can adjust this timeout setting. I have checked the code and it's set to 60 seconds. Of course the script might take longer to execute, but this is how long the scripting engine will wait when it thinks the script is hanging. You are the first person to experience this as far as I know, but most people are not doing what you're trying to do. Perhaps the best thing is simply to remove the timeout completely. This means that if the script hangs, then the whole WAsP session will need to be killed off, losing any unsaved work. We can put that change into the next WAsP 10 release (10.1).

Hi. Yes this is supposed to be an optional argument, but for some reason you sometimes need to pass explicitly "Nothing". It's not a programming error in WAsP, it's some kind of mix-up in the COM interfaces. You get the same problems if you invoke methods like this from Delphi or C# client languages.

Tab files should be OK. Have you previously used that variable hmowc? You could also try this Set hmOwc = Ins.Execute(tabpath, Nothing) If that works, I'll explain why, but I hope that's not needed.

This is a windows scripting feature. We might be able to change the setting to change the timeout. How long are your scripts taking?

WAsP 10.1 (due soon) will improve the way that land/water roughness mixtures are handled. It's also going to be *much* faster, so if you're waiting around for resource grids to calculate, you can have some of your life back in 2011.

Yes, we should disseminate this tip more widely. It has been mentioned in various places, but to be honest I can't remember where. I am just now updating the RveaScripting documentation, so I will put this information in there. There are lots of Rvea****.dlls and .tlbs. Some are for WEng, some for various versions of WAsP, and some are used by more than one client. Rv72 is actually about time series datasets, and is not used by the main WAsP program. For WAsP 8, you should be looking at Rvea0044.tlb, and Rvea0053.dll for the reporting assistant stuff. Have you considered upgrading? WAsP 8 is more than 5 years old now.

Did you know that you can browse all these interfaces for yourself, using (for example), the VBA code editor in Excel? In Excel, goto 'Tools... Macro... Visual Basic Editor...'. This will launch a lightweight old-fashioned visual basic editor. On this window, go to 'Tools... References..' You'll see a long list of check-able items. If you're using WAsP 9, then select Rvea0104Interfaces.tlb for the WAsP hierarchy member interfaces and Rvea0103.dll for the reporting assistant interfaces. Check those files, and press OK. Then back in the editor, press F2 to bring up the Object Browser. Now select Rvea0103 in the drop-down list. You'll see the WaspReportingAssistant object at the bottom of the list of classes which appears. Select it in the left hand side list and a list of the members (methods and properties) of the class appears on the right.

For this map reference thing, you could either have all the different maps in the workspace root and move them into the project in turn as needed, or you could keep them externally on disk and insert them from files in turn as needed. One makes for a big, self-contained workspace, and the other for a small workspace with map files outside. Which sounds better?

Hi Trenton, Sorry to hear about this. Dongle recognition problems are rather rare nowadays. Can I ask what changed? Presumably you were once happily using WAsP without problems. Did you get a new PC with Win7/64? Is this a USB dongle or do you have an ancient artefact in the form of a parallel port dongle?

In WAsP, the met station height is taken from the TAB file, but I think you can actually change it in a script. Try ... MetStation.AsIWaspSite.WorkingHeightAgl = 34 (Assuming you have got a correctly-typed reference to your MetStation object.) For TurbineSites, just assign a new value like this TurbineSite.HubHeightAgl =75 more later... D.

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

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.

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.

If ReportingAssistant.CastableSelectedMember.AsIWindFarm is nothing then 'It's not a wind farm. Does that help?

In the latest WAsP 10, you can use CTRL-C keyboard combination to copy the entire Wind Farm Power Curve to the clipboard. Then you can paste it to Excel or something.

Hi Adam, I'm sorry that you're having this hassle. Getting WAsP and WEng to work together and invoke WAT has been quite a headache and it's not always working perfectly. We're going to make some improvements in this regard for WEng 3. If the Excel script is completing sucessfully, then most of the usual causes are ruled out. Perhaps the quickest way to isolate the problem is for you to send the Excel spreadsheet to us, and we'll try to open it in WAT and see what's going wrong. In this case, the email to use is wengsupport@risoe.dk

I'm sorry to say that I can't reproduce this. The extreme grid map output seems correctly layed out to me.