jfcorbett

Hi Duncan, sorry, I didn't mean to put you on the spot! Here's me asking again. We've resorted to having a Msgbox warn the user prior to running the script that they may see these "Script execution is taking longer than expected" messages, so they don't worry unduly and keep their guard up against accidentally pressing a keyboard shortcut for "End".

Not that I know of. Our engineers run scripts all the time and they constantly run into this annoyance.

Yes, I think this helps. The take-home message is that Utility and Report script are not treated in any way differently by WAsP, right? Or rather, the only difference is what sub-menu the script shows up in. -- nothing else

You may want to get your hands on a copy of the European Wind Atlas (Troen and Petersen, 1989). Your questions are too substantial to be answered on a forum post, but they are all addressed in Part 3 of the EWA. See the full reference on Risø's webpage.

What is the difference, if any, between "Utility" and "Report" scripts? I'm aware of the dictionary definition of those two terms, but if I write a new script, does it matter if I classify it as the one or the other type? Does WAsP treat them differently? What if my script does a bit of both?

P50 is just the mean, i.e. your energy production prediction. For the other Pxx's, you need to estimate the uncertainty on that number. Look at all the things you did in your analysis (wind measurements, modelling, calculations, assumptions etc.), estimate the uncertainty on each of these things, and finally combine them all to get a global uncertainty on the energy production. If you assume that this uncertainty represents the standard deviation of a Gaussian process, then you just need a bit of math to get P75, P90, P-whatever.

In my opinion, your questions merit more of an answer than can fit in a forum post. Sounds to me like you would benefit from a WAsP course. I should know: I attended one on my very first two days at Risø back in 2002, which was extremely useful -- and ended up teaching one during my last month working at Risø in December 2007. Have a look at: http://risoe.dtu.dk/en/WAsP/Courses.aspx GL Garrad Hassan (disclaimer: I now work at GH) also offers training that would be quite relevant to your situation. Have a look here.

@cristi.stoian: I find it much easier to draw polygons directly in Google Earth, place them in a "folder", and save that folder as a KML file. You can then read the contours from that file (by parsing the XML) and convert them to WAsP map format. I wrote my own little program to do this conversion, but I'm sure Global Mapper or some other fancy GIS program can do this as well. Exporting images from Google Earth and geo-referencing them is much more time-consuming... I've tried both methods, and I can say that KML-->MAP saves you a lot of time.

Note that I said WME saves polygons in clockwise (negative) orientation. I don't know what orientation the polygons in your input file have. It's up to you to figure that out and infer what's left and what's right.

Well, if you think about it, if your polygon points are in clockwise order, then left=exterior and right=interior. And vice-versa. By convention, Map Editor saves all polygons in clockwise order. But it can read them in either order.

Is there any particular requirement for character encoding in WEng (and WAsP) script files? If so, does it depend on the operating system? What else could be the cause of the problem described below? This one took me a while to debug: a comment was causing a "Object not set or With block variable not set" error! Turns out the compiler was tripping on the "special" character "ç" in my commented-out name: ' Author: Jean-François Corbett Error went away when comment changed to: ' Author: Jean-Francois Corbett This was on a 64-bit Windows 7 workstation. The exact same script gave no error on my Windows XP laptop.

You can usually buy very good electronic maps from the local country's geographical authority (e.g. Ordnance Survey in UK, Lantmäteriet in Sweden, etc.). As for maps made by satellite remote-sensing, aside from STRM, I've used ASTER (also download here). Creating maps "by hand" by scanning paper maps and clicking contours is a very nice hobby for masochists!

22 hours -- I like this definition of "the near future!" Thanks for this update.

Interpolation, as in weighting the masts according to distance from the turbines? That's an engineering decision, and it shouldn't be left to WAsP or any other program, really. What you can do is do all your calculations in two separate projects, one with each mast, and then post-process the results, i.e. average or weight them at each turbine location as you see fit. That's what we usually do, anyway.

That is most definitely not possible in WAsP -- at least not in any WAsP version I know of, including 9. How would WAsP know what the wind atlas should be if there's two met stations in there? I guess the question is: what do you want to do with the two met stations? What were you hoping WAsP would do exactly?

As far as I know, the right way to use two met stations is this: Add a second "project" hierarchy member to your workspace. Use the second met station in there. NB: The two projects will be completely independent from each other.

This is an excerpt from the answer I got from WAsP support: Hi Jean-François, This exactly what we have done in WAsP 10: · Max. number of roughness changes/sector from 7 to 10 · Sub-sectors in roughness map analysis from 6 to 9 · Number of roughness classes for *.lib file from 4 to 5 · Standard roughness length #5 from 1 to 1,5 m [...] Your point about covering the range of conditions is absolutely correct, see attached PDF. Cheers, Niels Niels Gylling Mortensen senior scientist Wind Energy Division Risø DTU

In the project configuration, is there any reason NOT to: * increase the number of standard roughness lengths from 4 (default) to 5 (maximum allowable) * increase the maximum number of roughness changes per sector from 7 (default) to 10 (maximum allowable) Any reason other than a slight increase in calculation time, that is. It would seem to me that unless calculation time is critical, one would want to use the least restrictive settings, i.e. max everything out. Is this correct? Note that the default settings listed above are from WAsP 8.

Is there a way to transform the projection of .maps in an automated/scripted way? Fairly often, I have to convert a large number of .map files back and forth between metric and lat-lon, in order to interface with other applications e.g. Google Earth. Being able to script this would be a huge relief.

You can do this in WAsP Map Editor... That's what WME is for! Turn on digitizing (in the Map image window, Tools|Digitizing|Enable digitizing). File|Load a background map if you have one. Another option is to do your roughness contouring on Google Earth, if you feel comfortable using the images available on GH. Make polygons (or paths) and save them as *.kml. With a bit of text file or XML manipulation, the contours in the .kml can be converted to a file readable by WME (e.g. .bna, or even .map). Once in WME, convert from Lat-Lon to the appropriate projection. Good luck

Aha! Thanks for this answer. I don't suppose there's any way to clip it in an ellipse or some other shape?

Is there any way to script/automate the Map Editor's functionality? I'm mainly interested in clipping maps into various shapes and sizes, as is possible in the WAsP Map Editor. Any alternative suggestions are also welcome!

Perhaps, but it has no influence on self-prediction errors, which is the topic of this thread.

I received the following reply from none other than Ib Troen himself. It is true that prediction and self-prediction are influenced by the truncation mechanisms mentioned. In the "up" transformation the initial (observed) speed and directional bins are redistributed and re-binned. Also in the "down" branch, when using the atlas tables to arrive at site distributions, there is a re-binning by sectors due to wind turning (orography in particular), and a renormalization. Depending on the site (especially its directional inhomogeneity roughness-wise and orographic effects) this can be seen in self-prediction errors. Also, there are (usually much smaller) effects of the interpolation within the wind atlas tables when predicting between table heights and roughnesses. This effect can be remedied somewhat in case one uses only a narrower range of heights by selecting standard heights in the range. The Weibull fitting is done at the "down" branch to give the atlas tables in terms of the Weibull parameters. The fitting procedure conserves power density, but not the mean values. Thus mean values may deviate from the original observations because of this. It’s quite gratifying to see that I was pretty much right in my initial guess!

I'm not sure what you mean by w'theta' ? Since only one vector map is used in self-prediction, a different Oreography should by definition not be an issue.