Duncan

I'm running Windows 7 here, and I just tested with the dongle installer. When I inserted the dongle, Windows went off and found the latest drivers. Device manager is reporting it as SafeNet Inc. USB Key, with driver version 6.56.0.0. It's working fine, and reporting the DongleID code through the licence manager program. The licence manager reports that the HASP dongle driver version is 4.102.5.22, though. I tried un-installing the drivers and re-inserting the dongle. The same version driver was again automatically installed with no problems. Does this match your experience? Are you seeing any differences between the PCs where it's working and where you've got problems? Duncan.

Hello Jan, Just to check that this is a local machine session: you're not doing this by remote desktop or anything? Duncan.

Hi Bruce, My colleague Marko has done some more recent investigations into how to setup remote access to WAsP. I think there were a couple of third-party products which might help, depending on your configuration. He's on vacation now, but when he's back in a couple of weeks. We'll update the FAQ page, as you suggest. Meanwhile, I should point out that the new WAsP - version 11 - doesn't use a hardware dongle at all. Have you considered an upgrade? We're in the process of updating the way the licence system works with network / remote desktop logins. At present, it counts as a separate installation if you run locally and over remote desktop. That's not the intention, so we're going to change things to make it more convenient. Let us know what kind of network configuration you want to get working. We can try to ensure that our upcoming changes take account of everyone's needs. Duncan.

The WAsP help file is pretty comprehensive, I think. There is a step-by-step tutorial to get you started, and a lot of material about how to use the software. I'm still confused about what you're trying to achieve here. If you just want to know the grid configuration, then download an older version of WAsP from the web site and on the tools menu, you'll find "Import from WAsP 7". This won't import the data, but you'll get the grid setup. There's no need to have a licence for the older version if you want to use it in that way. To visualise the results in a WRG, use WindFarmer or OpenWind: these are the programs which use that type of file. You could extract individual grid maps from the WRG and display them in a mapping program, but that would be tedious unless you're a programmer. The WRG does not contain any input data: just the results. The observed wind climate is not a time series: it's a statistical summary of one. If you have only the resource grid and the location of the met station from which it was calculated, then you could try to run WAsP backwards to get an idea of what the OWC looked like. You would need some kind of map, of course, but that might be very simple to create if the whole story happens far offshore. To do this, you would need to pretend that a node from the resource grid was an observation, and calculate a prediction for the met mast. Take one line of results from the WRG, and make it into a weibull-only TAB file. Add a new met station at the node location and wrg calculation height. Insert the 'TAB', and calculate a wind atlas. If you put a reference site on the actual met station location and calculate a predicted wind climate for it, then it should correspond closely to the original OWC which was used to calculate the WRG. Sorry I can't help more. It sounds like you haven't been given the files you need to do WAsP calculations.

Hi Bruno, Sorry that your message has gone unanswered for so long. 1) You could use a script to change the height of all resource grids in a workspace or project to some new value. We can post a script example of how to do this here. Where would the new height value come from? Would you want to type if in, or read it from a file? 2) Do you want to generate multiple reports in a single step, or do you want to collate them into a single report? Which report exactly are you talking about here? Is it the "Wind farm report with wake model output"? 3) We've discussed the idea of automatically converting the geographical co-ordinates in the TAB file into metric coordinates for the met. station, but the team decided that the lat/lon location for the TAB are just supposed to be indicative of the general location, not a specific site location. For example, they might be expected to be accurate to only a couple of minutes. We're planning to change the program so that you will see a warning if you enter a metric co-ordinate location for the met station which is more than a kilometre from the location implied by the TAB's geographical location and the map projection. Duncan. 3)

Sorry you've had this problem. Have you downloaded and installed the latest version 10 Map Editor? I believe that it has no licence restrictions. We have removed all licence restrictions on the auxiliary tools like Map Editor and Climate Analyst. If you continue to have problems, please email me and we'll sort something out.

Hi Phil, The WAsP scientists are strongly recommending that IBZ and CFD calculations should not be mixed together. I'm guessing that maybe your met. station is in non-complex terrain which is fine for the traditional WAsP model (IBZ), but that your turbines are in more complex terrain for which CFD calculations might be recommended. In such a case it seems like you might be able to run an IBZ calculation to generate the generalised wind climate (LIB), and then apply this LIB to the turbines using CFD flow model corrections. But the scientists are very clear that you should not do this. We even considered making it impossible in the software. You can actually set up your project that way if you want, but there is a warning symbol added to the wind atlas if you do. HTH, Duncan. PS. If your met. station is in complex terrain, then using CFD to calculate the flow corrections is a no-brainer. I would actually suggest doing the met station tile first and comparing the IBZ and CFD results for the site. You can send up the turbine site tiles for calculation later.

Hello, Sorry that you've needed to wait a while for this reply. WRG files are WAsP *outputs*. They are not something that WAsP can open. WRG stands for "WAsP Resource Grid". When WAsP had been used to calculate a resource grid, you can export the results to files of this format to use in downstream programs such as OpenWind and WindFarmer. (This is actually a legacy export format which we support only for backward compatibility. WindFarmer now makes use of the WAsP calculation engine directly.) So there is really no way to open a WRG in WAsP. What are you trying to achieve? Do you want to use the grid specification and re-perform the calculations, or do you want to use WAsP to visualise the results contained in the WRG? Duncan.

It is not possible to perform an OEWC calculation in WAsP Engineering without a licence. You could ask the sales team for a temporary licence to allow you evaluate the new version. Duncan.

The four types of file should be almost exactly equivalent, especially the three which have actual data and not the Weibull parameters. They are simply three different ways of recording equivalent data to the file. If you open them in WAsP, you'll see that the data have been interpreted in the same way (so should look the same when displayed in the OWC window).

Hi Niel, There's no need to use fixed-width format. Each line in the file is parsed character-by-character to extract the numbers. Spaces and TAB (ASCII 9) are treated as separators. Duncan.

Hello WAsP users... I'm wondering whether anyone still uses the Library. This was introduced back in 1998 as a way of smoothing the workflow for people with their data organised so as to fit well with the old DOS WAsP way of working. Meanwhile, Windows now includes some vaguely equivalent functionality in the built-in Windows Explorer. So is this software feature vestigal now? Could we remove it one day, or is someone out there depending on it? Duncan.

Hi HPJ, There are some changes, mostly to the extreme winds model. We updated some scripts for release, but most required very minor changes. The documentation was updated to match, so I suggest that you download the latest scripting documentation from http://wasp.dk/Download/Software/Weng3_Installation.aspx Best of luck... Duncan.

I'm delighted to hear that this problem was resolved, Ricardo. Your installation report arrived by email and everything looks clean and fine and up-to-date.

Hello, I wonder if your problem is indeed related to the fact that you're using two dongles with a different licence installed on each one. In WAsP Engineering, when you go to 'This installation' on the help menu, what does it say? Does it say that both products are licenced, or only WAsP Engineering?

Hi Ricardo, This error is arising out of the WAsP calculation core. It might happen even if there are no problems with the map data. Could you email us the report information from 'Help... WAsP on this computer', please? Duncan.

Hi NK, Sorry that you are having problems. It certainly sounds as though it's a map problem. You could send me one of the maps to look at (duncan.heathfield (AT) wasptechnical.dk. Does the map open OK in the WAsP map editor? Does it contain any strange (non-ascii) characters in the header line? In WEng2, the project creator code is using an old DLL which is not so internationally flexible.

Sorry: long time with no reply about your problem. I simply have no idea what is causing your this. Has anyone else experienced anything similar?

So, if we offered 'export as KML' with a list of locations, would that be OK? Or do you need the turbine models too?

What kind of format output would you need? A list of points? Can you provide an example?

Hello, According to our current plans, the next version of WAsP (version 11) will not allow you to provide grid maps as input data for modelling, but this feature is definitely on the way and I expect you will be able to do that in the next WAsP after WAsP 11. Sorry to say that the vector-to-grid map utility is one-way only, and doesn't generate contours or roughnesses from grid input data. Duncan.

Yes, that's right.

Hello, it's a rather arbitrary distinction: any script can just describe itself as one or the other, and will be presented accordingly. Generally, the idea was that reports would be more standardised and should usually produce something to see or save (word, excel, html, etc). But we thought that there might be all kinds of useful tricks and automations which people would need or create, and so we have these 'utility' scripts for those. They might be less reliable, and might actually change something in the workspace hierarchy. Does that help? Hope so. D.

Hi Jean-François, I'm actually surprised you got this problem, and I'm sorry you had to diagnose it yourself. As you can imagine, we usually flush these issues out early because of the 'ø' in 'Risø'! I think we've seen something similar with the '°' degree character in report text on Chinese systems, and so have sometimes needed to replace these with character codes. But getting caught out with a code comment just seems unfair... The VBScript code in a script is in a CDATA Block, so the XML parser should be blindly taking what's there without parsing it. The XML is tagged as UTF-8, so it should handle these characters without problem. I guess that when we load that VBScript into the scripting runtime, passing it as a string, that's where things go wrong. I have logged this as a bug to investigate. Thanks for the report.

Hi HPJ, If it's an actual script running inside WAsP, then you have a ReportingAssistant object in context, which you can get to help with this kind of thing. Look at the standard WAsP report called "Resource Grid Report (HTML).was9". You'll see lines like this: ReportingAssistant.Illustrator.Width = 5000 ReportingAssistant.Illustrator.DrawResourceGridResultInMap(ImageFilename, VectorMap, ResultMap.Map, VariableIndex, , False) Getting all the objects you need is fairly complicated, but once you have them, the illustrator can generate an image file for you. The variable index is a selector to describe which result you are drawing from the resource grid. There is an enum for this index, with the prefix "ergm", for example "ergmMeanSpeed" The result map is arrived at thus (in this report script)....: Set VariableResult = ResourceGrid2.Results.PredictedClimateResults.ResultByID(VariableIndex) This code gets the currently selected resource grid reference. Then the results of this, and from the PWC part, selects the results for a particular variable selector. Set ResultMap = ReportingAssistant.TypeCaster.CastObjectToResourceGridResultMap(VariableResult.OmniDirectionalResultMap) This code gets the all-sector result map for the result and typecasts it into the right type of object for the illustrator. ResultMap is a resource grid result map wrapper object with meta-data. To get the actual results map, you need to refer to ResultMap.Map (sorry that's confusing!), so that's what gets passed in to the illustrator. So, Hans Peter, the answer to your question is 'Yes'. But I'm afraid it's not perfectly straightforward. The complexity is largely due to the fact that a resource grid object is has lots of information and may be in many different states. Hope that helps, Duncan.