Jump to content

Mark Kelly

WAsP team
  • Posts

    48
  • Joined

  • Last visited

Everything posted by Mark Kelly

  1. Hi Vera, you should enter the windfarm as turbines. Cheers, --Dr. Mark Kelly, DTU Wind Energy on behalf of WAsP
  2. Oops--I recall now that we still don't allow z>200m, because we have not yet released an updated stability/extrapolation treatment for this regime. However, we have implemented a number of "tall wind profile" forms now in the code and validated them for numerous sites. I expect the next release in (early) 2016; it includes geostrophic-shear and height-dependent influences in this "tall" regime.
  3. Hello, have you tried setting the maximum wind-atlas height (standard height #5) to the desired extrapolation height?
  4. Hello Fabien, The WAsP-CFD results (in the implementations we've released up to 2015) are Reynolds-number independent; the speedup should not depend on the wind speed. Indeed files such as Angle_270_a_0100m.grd give a grid of speedup (in this case for winds from the west, at z=100m). To get the mean wind speed in a given direction you take the generalized mean wind speed in that direction (from the GWC), at the appropriate height over the appropriate roughness (e.g. 100m over z0=3cm mesoscale-roughness), and multiply it by the speedup for that {direction,height}. For non-standard meso-roughnesses, it gets a bit more complicated... Why not just export the resource grid of mean wind speeds, from WAsP?
  5. Hello (to user Chlee), The use of z0 roses is obsolete, and maps are used/preferred; however one can inspect the z0-rose to see what WAsP is doing. How are you assigning "individual" z0 "to each wind turbine"? -- with kind regards, Mark Kelly, DTU Wind Energy / WAsP team
  6. Yes, simply click on the show/hide contours icon, use the drop-down menus to show the resource-grid quantity of interest and direction, and zoom as you like. With kind regards, --Mark, DTU Wind Energy
  7. Do you have WAsP Engineering installed?
  8. The terrain elevation-induced speedup (flow-model correction) is done in thin sectors, but the correction is essentially wind-speed independent. If you have a bi-modal distribution in a sector, you could try to narrow the sector, for example to get a "one bump" fittable distribution in every sector (or at least in the sectors where you will have significant AEP).
  9. Hello, the help file is included with WAsP, you can simply look into that facility. For more documentation on the models within WAsP, the best current reference is the European Wind Atlas book (Troen and Petersen,1989), and for the flow-model it is the 1990 conference paper by Ib Troen, "A high resolution spectral model for flow in complex terrain". A general list of references (including the main 2 above) can be found under 'References' in the WAsP helpfile, as well as the 'DTU Wind Energy readings' section of the WAsP helpfile. Check the latter for those most connected with WAsP.
  10. Hello, when does this error occur? When starting WAsP, when loading a project, or other? Do you have a local or network installation?
  11. Hello Kendall, in v10.2 this is a way of changing the upper-ABL damping of the stability correction. It controls how 'sharply' the damping is done, as it is the factor p in the damping exp[-(z/zg)^p].
  12. Hello Kendall, which version are you using?
  13. It appears that you have rather unstable conditions, and perhaps this is partly due to flow from offshore (which tends to be more unstable, on average). The offset heat flux is the main parameter you would adjust, but it also depends on how far from the coast that your sites lay. There is not an official process for this, as it is non-standard. One recommendation that we _do_ give is to double-check (or triple...) that _all_ of your roughness and terrain data are well-represented, and that you are using good wind data with high recovery rate. One thing you did not mention, is how much are you needing to extrapolate. Also, what 2 heights are measuring at, and what is the magnitude of terrain variations, distance of coast (and terrain features) from sites, etc. There are a number of things you can do with multi-point measured data, but not automatically within WAsP.
  14. As "elbigkonan" mentioned above, for an on-shore site, one can get a classic measure of the stability (the Obukhov length) from the heat and momentum fluxes, measured by a sonic anemometer in the surface layer. While the popular alternative to this is to measure vertical temperature gradients, these can cause issues: the lower sensor will fall within the atmospheric surface layer a different fraction of the time than the upper temperature sensor, giving results that are not reliably relatable to temperature fluxes or proven theory. The temperature differences can be used qualitatively, however, e.g. to sort data into un/stable regimes. Again the sonic also gives a better idea of turbulence, so if you have the money to install more than just the near-surface (10m) sonic, then one higher up can potentially be useful as well (it depends on things such as terrain complexity)... Our statistical implementation using sonic fluxes in WAsP must be further improved before we release it, as AEP depends not only on the mean wind speed, but also the distribution (Weibull-k). I would also recommend always adding a dedicated temperature sensor along with each sonic anemometer, because the mean temperature from the 'sonics' can e.g. drift (this does not really affect the fluxes).
  15. Hello Carlos, it is still not clear what you are doing--you write that you "perform some statistical analysis for different thermal stability ranges and afterwards we select the most likely heat flux offset and RMS values for land and water, taking in consideration the wind regime that WASP is prepared to work"; if by "most likely fluxes" you mean the ones that correspond to desired shear statistics for given stability ranges, then you might be able to improve results some by using option 3. Again, since the offset heat flux in particular may not directly correspond to the meso- fluxes, it is the shears that are most important; maybe you get some improved (e.g. seasonal) results by breaking the meso fluxes into groups and matching shears that way. However, because you have 2 rather different wind climates, depending on how you use the meso data (it is not quite clear), the uncertainty of 'bending' the Wind-Atlas method (perturbed geostrophic drag law) in this way is likely to be comparable to (or maybe larger) than the 2.4% spread that you quote. In other words, WAsP was not really intended to be used this way; unfortunately the new stability model implementation is not released.
  16. Hello, generally the WAsP heat flux parameters do not correspond to physically measured fluxes (although for very coarsely averaged mesoscale output they might begin to converge in some cases). It is not clear how you are using the mesoscale simulation output--do you mean that you are adjusting WAsP's offset heatflux based on the mesoscale shear output, or what? I can respond further based on your response. --Mark
  17. For the extreme wind report by Kristensen et al (1999), try http://www.risoe.dtu.dk/rispubl/VEA/veapdf/ris-r-1068.pdf
  18. Recall that roughness changes closer than ~10-12 times hub-height do not matter so much, and neither do roughness lines farther than 100-150 times hub-height. Does this help reduce your issue?
  19. Mark Kelly

    MCP error

    This question should go to EMD/WindPro, as WAsP does not (yet) endorse or use any MCP method.
  20. how big is it? Have you checked it in another program?
  21. Hello lavisura and all--- 1. Currently, splitting the data is not generally recommended within the current WAsP (v10.1) framework: WAsP is designed to put stable- and unstable-condition observations together to give a representative long-term estimate. (However, one can in general divide into stable and unstable subsets, which is in part what the forthcoming improved WAsP-11 alternate stability model does; see Kelly and Gryning 2010, Boundary-Layer Meteorology.) Within the current framework (v10.1) one would need to make separate "stable" and "unstable" wind-climate (.tab/.owc) files, and then tune the offset and RMS heat flux parameters for each set, compared to the observed profiles for stable and unstable conditions--but again I stress that doing so basically falls outside the design envelope of currently available (up to v10.1) WAsP. 2. If you are trying to improve self-prediction, you hopefully have multiple measurement heights; note that the stability parameter should not alter anything for the same height. You can first vary H_offset and secondly H_rms to optimize the self-prediction, but beware of extrapolating much beyond Delta z above the target height (where Delta z is the difference in height agl between the 2 sites), and beware/caution for the case of extrapolating beyond z_m if both measurements fall below z_m (where z_m~=65-75m over land, see European Wind Atlas Ch.8). If you did use this, it would only apply to this particular site/wind-climate, but again would work much better with 2 met masts--more uncertain with just one. 3. Including measured and hub heights in the standard heights can reduce numerical (log-)interpolation uncertainty, but this is rather small compared to the (unrelated) effect of modifying stability parameters. Again as Gregor commented earlier, the WAsP parameters in the current framework do not correspond directly to measured heat fluxes, so they do not necessarily reflect reality--contrary to the EMD/WindPro description (though the new [yet unreleased] alternate/v.11 treatment uses measured fluxes). Otherwise the EMD recommendation 4.3.2 is good: adjusting the heat-flux parameters to fit one measured vertical profile can sometimes make flow modelling results worse than using WAsP standard parameter settings (especially if only one mast, 2 heights, see #2 above); H_off and H_rms might be changed only for very cold/warm climates.
  22. Two things here: The current (v10) WAsP climatalogical stability treatment uses two parameters (offset and rms heat flux, either over land or water), but these parameters are not physical---so they do not correspond directly to measured surface fluxes. (For details, see Chapter 8 of the European Wind Atlas.) There is a new stability and "tall profile" treatment scheduled to be included in version 11, which will allow input of measured heat fluxes (or measured flux statistics). Thus to answer mipa: if you have already checked everything you can regarding the terrain and roughness maps, it is possible to then empirically adjust H_offset to be more negative in order to represent the more stable (in the mean) conditions. But this would be based on wind measurements at multiple heights (e.g. LIDAR). {side note @Mkevin: I do not believe that commercial wind LiDAR gives usable theta' (yet)...}
  23. Hello "WAsP101," 1) In the Map Editor you can join 3 lines together, for example, by holding down the CTRL key, and clicking each one near the point at which they are to be joined. Then you can right click near/on the joining point and choose "anchor lines." 2) If you are wishing to use a displacement height and digitize "on top of" a terrain elevation map, then indeed you can add the ZPDH to the local elevation as you wrote. Note however that the transition from forest to non-forest area is difficult to model (most flow models cannot capture all the physics), and so there is more uncertainty around the edges of the forest, particularly when incorporating ZPDH into a terrain map. If you are only considering a few locations above forested area, instead you may consider simply subtracting the displacement height from the height AGL of these locations' hub heights (for example), i.e. instead of digitizing modified height contour lines. I imagine if you are familiar with Dellwik et al, you are also familiar with Raupach (1994), which can be useful -- reminding that the effective/usable displacement height and roughness depend on the sparseness or denseness of the forest. Again also the transition near forests can be difficult, see e.g. Ferhat Bingöl's work from this year (and last). --Mark Kelly, Risø / WAsP team
×
×
  • Create New...