vob

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!

Update: this will be fixed in the next release of Wasp 12.1.

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.

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!

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!

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

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!

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

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!

Thanks, Ray, using 3600 (1 hour) was enough to solve our troubles here at the moment.

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

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!

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.

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!

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!