Jump to content

vob

Members
  • Posts

    28
  • Joined

  • Last visited

Everything posted by vob

  1. Hi all, perhaps a very stupid question, but how many sectors are allowed for well-formatted WRG/RSF files? The WAsP documentation appears to put no limit to the sector count as long as it fits into columns 70-72, while freq/A/k entries are specified for exactly 12 sectors in columns 73-228. Does it mean that WRG files should always have 12 sectors (then why do we need to specify the sector count)? Or may we use arbitrary numbers of sectors? Then the documentation should indicate that more columns may be added beyond the k value for sector 12. Thanks!
  2. Update: this will be fixed in the next release of Wasp 12.1.
  3. Dear all, this is just to announce the results of a recent issue solved in close collaboration with WAsP support (thanks, Morten): When trying to open old TAB files (still generated by Wasp5) with Wasp12 we obtain error messages saying: "[...] could not open the OWC data file because ... sorry. WAsP can only work with OWCs where the sector one centre angle is zero because ... the system reported that: 'Invalid sector 0 offset.' " It turned out that this was caused by the third line in the TAB files, where Wasp5 has added lots of space characters to separate the entries, in order to align them nicely. However, Wasp12 apparently can only handle TAB files which contain no more than four space characters between the first and the second entry (i.e. sector count and wind speed scaling factor must be separated by four space characters or less). This problem has already been forwarded to the developers, so probably it will be fixed soon. In the meantime, if you don't want to edit old TAB files manually, it's also possible to use Wasp11.6 for opening Wasp5 generated TAB files.
  4. Dear all, while experimenting with a power curve that is shut down (power = 0) for a certain wind speed range I have come across a puzzling issue: The gross AEP as calculated by IRveaProductionRose.SectorForIndex(SectorIndex).GrossContribution for a given sector is greater than the sectorial AEP calculated from IRveaProductionDistribution.ProductionForSpeed (of course after accounting for the sector frequency). In my example I used a power curve that cuts in at 19m/s. For sector 2, the calculated .ProductionForSpeed values are: 19 m/s: 15705 kWh/y 20 m/s: 2099 kWh/y 21 m/s: 237 kWh/y 22 m/s: 23 kWh/y 23 m/s: 2 kWh/y and zero above 23m/s. The sector frequency is 7.497%. This results in a gross AEP of (15705+2099+237+23+2)*0.07497 = 1354.4 kWh/y, but the .GrossContribution is reported as 3215 kWh/y, almost 40% higher. For other sectors with higher wind speeds, the difference is only in the order of some 20%, but .GrossContribution is always greater than the sum of the non-zero .ProductionForSpeed bins. When I use a non-curtailed power curve (cut-in at 3 m/s) the difference is less than 0.2%, for high-yield sectors even down to 0.01%. I always thought the AEP is simply the sum (or integral) of the production values determined in each wind speed bin (based on the power curve and the bin frequency), but apparently this is not the case. Could someone please explain in detail how AEP is calculated? Thanks in advance!
  5. Just to close this topic: it turned out that there was a bug in the PreserveToFile function, which has been fixed by the developers in WAsP version 11.6.0018 and all newer releases. Thanks again for the great support!
  6. Hi again, I did some more research and discovered that it's not the calculation itself that's causing the problem. The problematic step actually is when after the calculation I also write the respective Project to a file using Project.AsIRveaPreservableObject.PreserveToFile. This method appears to work well for the first three times it is called, but then fails for whatever reason. After that failure, wake calculations fail for all subsequently evaluated projects. Is there any in-depth documentation about the WAsP scriptig environment and what happens when we save parts of the workspace? The latest info I have is from a post by Duncan in May 2011... Thanks
  7. Dear all, I have a workspace with three identical projects, each consisting of a 'Terrain analysis (IBZ)', a 'wind farm' and a GWC (plus some notes). I also have a script, which iterates through the projects and calculates the respective windfarm using the DoAllPossibleCalculations method. The weird thing is that the wind farm calculation works well for the first two projects, but fails for the third (and all further) wind farms. More specifically it fails to calculate the wake losses and net AEP, while the free AEP is calculated for each turbine and the wind farm. By default, each wind farm is calculated by issuing WindFarm.AsICalculatingHierarchyMember.DoAllPossibleCalculations(False). This works as expected for the first two projects/wind farms. However, in the third project nothing happens. I then check the properties of WindFarm.AsICalculatingHierarchyMember.CalculationByType(ectWakeLosses). In the third wind farm I find that: .Status = 3 (i.e. echmsResultsDirtyCanRecalculate) .AreResultsDirty = True .CanCalculate = True .AreThereResults = False However, when I then run the WindFarm.AsICalculatingHierarchyMember.CalculationByType(ectWakeLosses).Calculate method immediately after checking these variables, still nothing happens, and the variables keep the same values a as before. I have no clue what happens here and how to resolve that. As I said, the three projects/windfarms are identical (checked this by exporting the projects to w.p files and compared the resulting Inventory.xml files, which differ only in the ID strings and the references to the .tmp files). Why does the WindFarm refuse to calculate in the third project? I also checked to put all three farms inside of one project, but the result is the same, so I suppose that this issue is related to the wind farm calculation method. Any suggestion is welcome. Thanks in advance!
  8. Hi there, I'm running Wasp 11.4 and I've noticed an apparent inconsistency in the wind farm power curve generation, which appears to produce greater output under partial load than for a single turbine. I've checked that with a Bonus 2MW turbine included in Wasp. I set up a wind farm that contains only one turbine, define a reference site and calculate the wind farm power curve. The results I get are P(4m/s)=0.054MW, P(5m/s)=0.149MW, P(6m/s)=0.286MW, ... for the win dfarm power curve, while the Bonus 2MW power curve holds these values P(4m/s)=0.043MW, P(5m/s)=0.133MW, P(6m/s)=0.237MW, ... What's more, the wind farm power curve seems to direction dependent, which makes no sense for a single turbine with out wake shading, because 5m/s should be 5m/s no matter if wind comes from North or West. I also checked this with more than one turbine (N>1) and the wind farm power curve delivers power greater than N times the power of the single turbine power curve for several sectors. Here, the number of sectors with excess power seems to increase with wind speed. Is there something wrong in the implementation of the wind farm power curve, or am I getting something seriously wrong here? Kind regards
  9. Dear all, we have a Reference Site with a Generalized Wind Climate calculated from an OWC, which calculates fine on most of our computers. However, one colleague in our French office encounters a 'Type mismatch. ' error when he does the calculation. Do you have any idea what might be causing this error? The exact error message is: Could not process the menu action because ... could not do all calculations for a member because ... unable to perform all the pending calculations because ... could not do the reference site calculation because ... could not perform site assessment for a reference site because ... the system reported that: 'Type mismatch.' There must be some relation to the specific setup of this computer, since the same .wwh file calculate without error on most other machines. Thanks for any suggestion!
  10. Thanks, Ray, using 3600 (1 hour) was enough to solve our troubles here at the moment.
  11. Hi Duncan, thanks for keeping this issue on the list, even though it's a pity that it didn't make it into the next release. But if it will be in 11.5 this would still be appreciated :-) One "other use" might be e.g. to use that matrix to roughly correct wind speed measurements for a wake affected met mast. But I'm sure that people will find even more ways of utilizing this information... Thanks, and best regards, vob
  12. Thanks, Duncan, for letting us know. I'll test that. Is there any upper limit for the timeout? And is there any special value to disable the timeout completely? Thanks again!
  13. Anyone?... I would be really greatful if someone could point me to the correct way of implementing that setting. We currently have a couple of calculations with large wind farms that frequently run into that problem and it would really ease our life if this message could be suppressed. Thanks for any reply.
  14. Thanks for integrating this into Wasp, from the changelog I take it that this has already been included in build 58 of Wasp11.2. Nevertheless I still don't know _how_ to activate the timeout settings. Has this been documented somewhere? What exctly needs to be written in the script header to set (or completely deactivate?) the timer? BTW: Has there been any update of the Rvea_scripting.chm help file? The version I have dates back to 2011... Thanks!
  15. vob

    WAsP 11.2

    Hi Duncan, we are also experiencing this problem. Is there already a timeline by when this Lib extrapolation tool can be expected to be available? Thanks!
  16. I'd like to raise this issue again - we've already come across requests to report average wake affected wind speed and distributions (Weibull A, k) at each turbine position, and it would be great if this could be simply exported from Wasp. If this is really not possible to extract from existing versions, I'd like to add this to the 'wish list' for upcoming releases.
  17. Thanks, Ole, for pointing that out - automatic changing the object type from 'wind farm' to 'turbine site group' appears to be quite a handy feature. Have a nice weekend!
  18. Hi Duncan, thanks for your clarifying reply. Seems I was not fully aware of the use of Turbine Site Groups - my fault! Making the separation in this twofold way (wind farms and turbine site groups) makes perfect sense to separate the wind farms that interact from those that are not supposed to interact. Thanks again!
  19. Dear all, I've noticed that when I set up a project with two wind farms, the wake effects of one wind farm do not affect the other farm. That is, the energy yield of farm_1 does not change when I have farm_2 nearby (5 rotor diameters distance) or not. It looks as if wake effects are only modeled for the turbines _within_ a single wind farm (either farm_1 or farm_2), but I have not found a confirmation for this in the Wasp11 help or in the forum. Is this a bug or a feature? If this is intended, how do I assess the wake effect of neigbouring wind farms? Do really I have to put all turbines into one large wind farms? Thanks in advance!
  20. Thanks, Ray, that was helpful. I'd appreciate if this could be added to an upcoming version of Wasp.
  21. Dear all, I'm struggling with an annyoing feature when I import a GWC from file to my turbine site. At the moment I do that as follows: Call Workspace.ReEnableChangeRipples(True) Set Member = TurbineSite.AsIHierarchyMember.Insertions.FromFile.ByClassID(ehmcWindAtlas).Execute(PartialGWCName,Nothing) Call Workspace.DisableChangeRipples When that code is executed, the imported GWC is automatically displayed in a new window in the right hand side of the main window. If you do repeated imports via script, the GUI will get cluttered soon, and closing these windows by hand is not what you really want when you are writing a script to automatize things... Therefore my question: Is there a way to prevent that window from getting displayed after the import, or to close it automatically after is has been displayed? Thanks for any suggestions!
  22. Dear all, I've just noted something that looks weird, or perhaps like a subtle error: When exporting a wind farm as an RSF file via the context menu (right click->Export xxx to file'), I get in the 8th column an energy yield figure (in Wh/y). When I do that for the wind farm as a whole, the value reported is the gross energy yield. However, when I export an RSF for each individual turbine (using the utility script 'Turbine site results to RSF.was9'), the 8th column reports the net energy yield. Is there a reason for this seemingly inconsistent behaviour? The RSF format only says that the 8th column should hold an energy yield (or a power density), but I would have expected that Wasp alwys exports the same figure... Best regards!
  23. Dear all, when calculating a single wind farm in Wasp I keep getting the error "Could not do all calculations for a member". The details say: Exception report produced at 2014-09-08 11:45:08 Element '0' des Steuerelementfelds existiert nicht raised at: 2014-09-08 11:33:55 2014-09-08 11:33:55: Message added: Could not refresh the progress indicator display 2014-09-08 11:33:55: Exception raised in: WAsP:fProgressMonitor:ReportProgress 2014-09-08 11:33:55: Message added: The project could not calculate all wind farms 2014-09-08 11:33:55: Exception raised in: Rvea0176:cProjectCalculator:DoAllJobs 2014-09-08 11:33:55: Message added: Failed to end a job on the progress monitor 2014-09-08 11:33:55: Exception raised in: WAsP:cProgressMonitor:EndJob 2014-09-08 11:33:55: Message added: Could not do all calculations for a member 2014-09-08 11:33:55: Exception raised in: WAsP:cProjectCalculator:DoAllJobs 2014-09-08 11:33:55: Message added: Could not do all calculations for a member 2014-09-08 11:33:55: Exception raised in: WAsP:cProjectCalculator:DoAllJobs Latest thread started in: WAsP:fProgressMonitor:Form_Load The German text in the first line translates to something like "element '0' of the control element field doesn't exist". I have no clue where to look for the origin of that error in my Workspace. When I insert a second windfarm identical to the first, I don't get that error. Apparently, the error message does not seem to affect the calculations and the results, but the message is a little disturbing and I would like to investigate that a little further. Thanks for enlightenment!
  24. vob

    Using the software

    Dear Mengesha, I think Niels was quite clear: the map that you need for your calculation should of course include both the mast site and the wind farm site. Furthermore, the map should cover at least a 10 km margin to either side of the combined area around the wind farm and the mast. Usually, you set up your map in such a way that the combined mast/farm area is at the map center. As an example consider a case where the mast is centered 9.5km south of the southern wind farm border, and the farm shape is a square with 4km boundary length. Then your map should have a north-south extension of 10km + 4km + 9.5km +10km = 33.5km, and an east west extension of 10km + 4km + 10km = 24km. If your mast and/or your hub heights are very large (100m and above), then the wind conditions at this height are less 'localized' than for, say, a 10m mast, simply because distance between land surface and anemometer/turbine is larger. Therefore, the higher you get, the more you need to take the larger surroundings into account. That's why Niels suggested to replace the standard 10km recommendation by the larger value '100*height + 50%'. For example, if your hub height is 100m this would translante to '100*100m + 0.5*(100*100m)', i.e. 10km+5km=15km. You should replace each occurence of "10km" in my formulas for the map extension above by this new value, so that the north-south extension would then be 15km + 4km + 9.5km + 15km = 43.5km, and the east-west extension becomes 15km + 4km + 15km = 34km. Of course, all these margin extents are rules of thumb, so please use your own scrutinity to judge if perhaps an even larger area would be required. The 10km margin should, however, be considered as a minimum value, so even though your mast is only 10m high (beware of the caveats already mentioned by Niels) you should still create a map with 10km margins. Hope this helps.
  25. Hi @all, I am looking for a method to export a *.rsf file for a wind farm (aka TurbineSiteGroup) from VBS. Of course I can do this via right click -> export, but this is error-prone as I then have to select a directory and enter a filename manually, and if I have several TurbineSiteGroups in my project it's getting tedious. So, I'd like to write a small routine that exports the RSF files for all TurbineSiteGroups using predefined names so that the exported RSF files can be used in a consistent manner by other (non-Wasp) programs. Any ideas? Thanks in advance! UPDATE: I've just discovered that there is a way to export a wrg file described in the standard script 'Do all resource grid calculations and export.was9'. This relies on Rvea0178.ObjectFactory and uses the CreateResourceGridWrgFilter method. I think if there were something like a "CreateResourceGridRsfFilter" method, this might solve my problem. Unfortunately, I didn't find documentation about Rvea0178, so I'm stuck here at the moment. - EDIT: this doesn't help, because the .rsf file I'd like to create is rather a replacement for a .wwf file than for a .wrg file. UPDATE 2: Looks like I didn't do enough research - shame on me! There's a standard script 'Turbine site result to RSF.was9', which shows me how to do what I want. Apparently there's no direct method to export RSF, rather the required info is collected on the fly and written to a text file.
×
×
  • Create New...