jfcorbett

I'd like to know what the sources of self-prediction error are. Here is what I think they are. 1. Directional rebinning. Due to turning, some numbers are pushed back and forth between adjacent sectors during the wind atlas methodology up-and-down process. This causes some "blurring" between sectors. 2. Interpolation of wind atlas statistics (especially if mast height is not among the standard heights) Am I right, and is there anything else? Does Weibull fitting have anything to do with it? (A similar question was asked previously on this forum but got no reply. I therefore sent the above question to WASPSUPPORT@risoe.dk yesterday... will post reply if and when it comes.)

I'd say the EWA is a pretty essential book to have on your shelf, so it might be a good idea to secure a copy (e.g. order on wasp.dk), or find someone who has one. However, I have to say, it's a pity this technical information isn't included in the WAsP help manual. It really should be.

Stability model: There is a four-page explanation in the European Wind Atlas (Troen and Petersen, 1989). The following four parameters are taken into account. You can change their value in the project configuration. Average heat flux over land. Default is -40 [Wm-2]. Average heat flux over water. Default is 15 [Wm-2]. Rms heat flux over land. Default is 100 [Wm-2]. Rms heat flux over water. Default is 30 [Wm-2]. There isn't really any place to input the "measured gradient of Vertical component of velocity". Friction velocity: This is an intermediate result. It appears in the geostrophic drag law -- in its modified form in the stability model. So I guess you could say that this is where it's calculated. See same reference as above for more details.

(I'm trying desperately to make time to finish adding the WAsP scripting interfaces to the RveaScripting documentation CHM. Hope to achieve that this month.) This is great news! I thought this was way beyond the horizon.

Aha, module-level variables work fine. I'm not sure I understand why WEng accepts re-declaration of variables but not of constants... Oh well! Thanks for the help.

I guess I will have to use a normal variable. This unfortunately defeats the purpose of module-level constants, visible by all procedures in the module. No big deal. I just thought I would make you aware of this quirk rather than keep it to myself. Let me know if my posting volume gets too high!

It seems WEng does not handle module-level constants properly. It looks like WEng remembers user-defined constant names even after the script has terminated, and wants to keep them as constants until the user exits WEng. For example, if I declare "Const MyConstant = 123" at module level (i.e. before Main()), the script runs fine the first time around. However, when the script is run a second time, WEng complains that “Name redefined: 'MyConstant'” and stops. Using "Private Const" changes nothing. Is this a known issue? Here's an example script that triggers this error, and the exception report generated upon the second run attempt. Utility epmtAny 2004-06-17T11:00:40 Exception report produced at 2011-01-18 11:03:33 Name redefined: 'MyConstant' raised at: 2011-01-18 11:03:25 2011-01-18 11:03:25: Message added: Failed to execute the script Testing12.wes2 Modified: 18/01/2011 11:02:37 2011-01-18 11:03:25: Exception raised in: WAsP Engineering:cScripter:Execute 2011-01-18 11:03:25: Message added: Could not invoke the script 2011-01-18 11:03:25: Exception raised in: WAsP Engineering:cMainform:InvokeScript Latest thread started in: WAsP Engineering:cProgressMonitor:Class_Terminate

I would certainly like to get a developer license, as it would make life a bit easier. Still, for most purposes, WAsP scripting works fine, and I can distribute the resulting script for use across our organisation. Thanks for your answer!

There is an apparent contradiction between the following table and text in the Selectors section: The table below lists all the selections and shows where they belong. Description Site ? Grid ? [...] Speed X [...] Horizontal speed X [...] We've noticed that the Speed and HorizontalSpeed are the most confusing [JFC: indeed!]. Speed is a point-only value, and HorizontalSpeed is a grid-only value.

I thought it would be useful to post any errors found in the scripting documentation, for reference by current scripters and to help the WAsP team correct any future release of the scripting help file. Here's my first contribution: In the "Selectors" section: All this can be collapsed into a single line Set DataSelection=CurrentProject.Class.AllSelections.ItemByID(TypeCaster.idForElevation) A "DataSelectionLists" property is missing in the chain, right after the project class object. The code should read: Set DataSelection=CurrentProject.Class.DataSelectionLists.AllSelections.ItemByID(TypeCaster.idForElevation)

Does anyone know of an "official" or elegant way of displaying script progress? I'm running scripts that cycle through a large number of small variations in various parameters. I'd like to keep the user posted with some kind of progress monitor, e.g. by displaying a string defined in the script, such as "Calculating case 451/2120, 21% done, approx. 1.2 hours left". In Excel, I would put that string in the status bar (Application.StatusBar). Is there something analogous in WAsP and WAsP Engineering? Right now I'm using a quick and dirty solution: I post the progress string in some dummy object's description (project in WAsP, site group in WAsP Engineering). This trick works fine, but it's not quite obvious and a bit confusing for the user. NB: MsgBox won't do, since it halts script execution.

Sounds like a good solution!

A user-defined timeout would definitely be a step forward. When I want to stop a script, I just press "Cancel" on whichever progress box is currently showing. What exactly is the use of the timeout? Is it for cases when one accidentally programmed e.g. an infinite loop? (e.g. Do Until False = True : Loop)

Partial answer to my own sub-question: ... is this the same as Lines thinning with a 2.0 m precision?) No. Lines thinning doesn't care how close or far consecutive points on a given line are from each other. It looks at how much the line will move laterally (i.e. perpendicular to its orientation) if points are removed (and/or moved?). For example, if three points in a given orography line are placed in a straight line, the middle point will be removed regardless of how long far it is from its two neighbouring points, because the resulting line segment will have moved exactly 0m relative to the previous line segments.

Would you agree that in the course of normal use, it "never hurts" to do the following to a .map file: 1. Lines thinning using the most conservative precision available (just over 1 m) 2. Saying "Yes" to removing consequtive (sic) polyline points closer than 2.0 m upon opening a .map file. (Also, is this the same as Lines thinning with a 2.0 m precision?) These two simple things take no time at all and can sometimes reduce file size dramatically if the original .map file is overly detailed. I am also aware of the following filesize-reducing tactics, requiring careful consideration as well as more time and effort: 3. Clip map, perhaps in an ellipse 4. Slash and burn in the far field: 4a. Increase the height contour interval 4b. More agressive Lines thinning Any other suggestions? Cheers, Jean-François

I am also annoyed at the fact that the roughness property cannot be edited for multiple lines at a time. This does prevents careless folks from doing things they do not understand and seriously messing up their maps, but it also prevents careful folks from doing things quickly and efficiently. I would advise writing your own script/program that loads the .map text file, edits the roughness lengths (and any other line properties) as appropriate, and saves the result in a text .map file. I did this myself a few months ago using VBA. Sorry if this is more daunting a task than you had hoped for!!

I think that by "on-line" the WAsP Team actually means "off-line". Back in the early 90s, on-line meant on-screen as opposed to on-paper... If you download and install WAsP, then go to Help --> Contents and index.

As far as I know, this feature is only available in WAsP Map Editor 9 and later versions. The .map format has not changed between versions.

It does work with the Nothing argument! Could this this a programming error in WAsP? It looks like the default value for the optional FileFilter argument should have been Nothing instead of zero, which isn't a valid value for type IRveaFileFilter. [ByVal FileFilter As IRveaFileFilter = 0] Perhaps a historical leftover... The same type mismatch occurs in three other methods in Rvea0134Interfaces. This would explain why you hoped this wouldn't be necessary :-) In any case, this is no big deal for the scripting user, just have to remember Nothing. Thanks for your help!

Perhaps a quick and dirty solution would be to change the default button to Continue (instead of End) and remove the keyboard shortcuts, if this is at all possible. This would greatly reduce the likelihood of accidentally ending a script when the message pops up while typing in another application. Right now "End" is triggered upon typing "e", space, or return, which are all quite frequent keystrokes. If the changes above could be implemented, then no single keystroke could end the script (though still certain combinations such as left arrow + space, but these are a couple of orders of magnitude less frequent).

A few to several minutes. But the timeout seems to be random. Sometimes the message pops up after under a minute, sometimes several minutes, sometimes twice in quick succession, sometimes not at all. So it's a bit difficult to request a specific timeout.

Is it because I'm trying to insert from a .tab file and now an .owc file? .tab files are all I have...

I've been struggling to insert an OWC from a .tab file into a Met station. I've tried my best to figure out how insertions work, but I'm stumped. Would you have sample code that does this? I tried: tabpath="C:\M1_Mat60_M2.tab" Set MetStation = WindAtlas.MetStation Set Insertions = MetStation.AsIHierarchyMember.Insertions Set Ins = Insertions.FromFile.ByClassID(ehmcObservedWindClimate) Set hmOwc = Ins.Execute(tabpath) But this last line gives me a Type Mismatch error: Script control reported the error: Type mismatch: 'Ins.Execute' The last execution line attempt was for line number: 90, which reads: Set hmOwc = Ins.Execute(tabpath) Cheers, Jean-François

Is there a way to suppress or tame the "Script execution is taking longer than expected" message box? What is the criterion for this expectation? Some of my scripts take sort of a long time to run, though not really "longer than expected". More often than not, WAsP brings up a "Script is taking longer than expected. End / Continue" message box, sometimes multiple times during script execution. This box pops up on top of other applications, which is a minor annoyance. Also, the keyboard shortcut for the "End" option is "E", which I've accidentally pressed a few times, meaning the script was terminated and I had to restart it from scratch. Any tips are appreciated! Jean-François

Well, I would personally love to upgrade due to the nice new functionalities, but there is some inertia to overcome... In the meantime, WAsP 8.4 works adequately, considering we at GH use it almost exclusively in combination with WindFarmer, meaning we only use WAsP as a bare-bones calculation engine for the "up and down" WA methodology. I understand the calculation engine in WAsP 9 is identical. As for WAsP 10, I think the general stance is wait-and-see: I heard through the grapevine that there are upcoming updates to the WAsP 10 way of determining roughness roses, with expected changes in results for coastal and offshore sites. Looking forward to the updated scripting documentation! And thanks again for the above tips.