Answers to Webinar "Wind farm flow modelling using CFD - 2012 update" Q&A session ____________________________________________________________________________ Christiane Montavon, Ian Jones Physics related Q: Should the roughness map be scaled from the normal WAsP map to the CFD analysis? A: WindModeller expects that the roughness provided in a WAsP .map file will be an aerodynamic roughness z0. For the simulation, the solver needs a roughness specified as an equivalent sand roughness. The transformation from z0 to equivalent sand roughness is taken care of within WindModeller, using a relationship between the two which is consistent with the ‘law of the wall’ applied internally in the solver. Q: Why is it necessary to run transiently when the stability model is on? A: When free stream stability is included, the solution tends to produce gravity waves which travel through the domain. Our experience is that trying to solve this in a steady state mode is not physical and can lead to a complete destabilisation of the flow even for cases where a stationary solution develops over time. When surface stability is included (representing ground heating/cooling), the process is by nature transient (giving rise in particular to the diurnal cycle) and a steady state solution rarely exists. Q: Where in the GUI do you define your stability input? A: Stability is still a beta feature (still evolving) so for now is not available from within the GUI. It can be specified in the parameter file, when WindModeller is run from the command line. The details of how to do this are available from us. Q: How is real mast data used (besides annual energy calculation)? Is it used to adjust the simulation process? A: It is only used for the annual energy calculation, and the simulations are only done at specified reference wind speeds. For cases where the solution is expected to be strongly dependent on the reference wind speed (e.g. when wakes are included, where strong separation is expected), it is worth saying that the user can prescribe more than one reference wind speed for the simulations to be carried out. Q: Is it recommended to run a simulation with different initial conditions (wind speed inlet at 5m/s and then 10m/s?) and evaluate the behaviour? A: This is very dependent on the physics included in the model. Our experience when running with neutral simulations shows that when you model wakes or forestry, the resulting normalised wind speed and normalised turbulence intensity are sensitive to the reference wind speed used. If a user wants to perform simulations at varying reference wind speeds he can do so within a single WindModeller set up (see above). Q: Does your turbine wake effect also include swirl? A: The actuator disk model in WindModeller does not take swirl into account. We have done some tests on variations of the model, to include turbulence generation, swirl, radial variation of the thrust, and also comparisons between Blade Element Theory, using supplied sectional lift and drag coefficients. Some of these variations may make their way into WindModeller in the future, once we have a better idea of which one brings consistent and significant improvement on the results, but our tests so far indicate that these effects are secondary effects, compared to the main blockage effects. Q: Can we nest a mesoscale model with ANSYS? A: We haven’t done this at the moment, but one of our customers has implemented this. Q: k- and SST (Menter) turbulence model. Have you tested both turbulence models? What were the discrepancies found? A: Because of its better reputation for capturing flow separation, and better robustness when working with high roughness values, we tend to use the SST turbulence model for complex terrain cases. The SST turbulence model is the default model used in WindModeller. For wake modelling in offshore cases however, we tend to recommend k-. The reasons for the latter are two-fold: separation is not an issue offshore, and in terms of accuracy of the multiple wakes in large arrays we find that k- tends to be more accurate than SST for downstream distances between 6 and 10 turbine diameters which are quite typical of the turbine spacing seen in large arrays. HPC, CPU time related Q: What is the approximate computational time for a typical simulation? A: This is to a large extent dependent on the physics which is used (wakes/no wakes, neutral vs stability) as well as obviously the mesh size. To provide a few examples, we shall give some required times for some of the cases shown in the presentation: 1. Harestanes, neutral simulations (steady state), without wakes, horizontal mesh resolution in central square of 50m, first cell height of 0.5m, domain radius: 15km, domain height: 4km. Mesh size: 2.16 million nodes. Elapsed time per individual simulation: ~37 minutes, running 12 parallel on CPU Type: Intel Xeon X5670 2.93GHz (RAM Memory per Machine: 48 Gigabytes). Simulations are required to converge down to strict RMS residuals of 1e-5, which in this case takes between 50 and 60 iterations. For such a case, a whole WindModeller run for 12 sectors (including pre-processing, solution and post-processing) takes approximately 9 hours. 2. Harestanes, transient simulations with stability, stationary solution reached after ~ 200 time steps. Same domain as case 1 above. Each individual simulation takes ~ 100-110 min (i.e. approximately 3 times the required time for neutral simulations). 3. Horns Rev, neutral, wake model enabled, 80 turbines. Horizontal mesh resolution in central square of 50m (before mesh adaption), first cell height of 2m, domain radius: 10km, domain height: 1km. Mesh size: 690k nodes before adaption, 2.16 million nodes after adaption. Elapsed time per individual simulation: ~ 26 min, running 12 parallel on CPU Type: Intel Xeon X5670 2.93GHz (RAM Memory per Machine: 48 Gigabytes). Q: Is there any limit to the maximum number of turbines the model can include. A: There is no hardcoded limit. The limit is the size of the machine you are running on. The largest case we ran so far had more than 1800 turbines and was run on 16 processors distributed across two machines on our cluster (each machine with 48 Gigabytes of RAM). Q: How does your simulation time scale up with mesh size? A: This to some extent depends on the selected physics. But for a basic setup (neutral, no wakes) the scaling is more or less linear. Larger mesh sizes can be accommodated by distributing the simulation across a larger number of processors. HPC packs for licenses are available for HPC clusters allowing each simulation to be run on e.g. 32 or 128 processors. Please get in touch for more specific details. Mesh, domain size related. Q: Ho do we change the size of the centre square used in the meshing section? A: The relative size of the central square to the domain radius is controlled by the parameter ‘Centre Block Radius Fraction’ which is set on the ‘Mesh’ tab in the GUI. Q: Is there any restriction to the number of cells used for higher resolution? What typical horizontal/vertical resolution do you work with? A: The only limit is the memory available on your computer and the number of CPU you have access to. The horizontal resolution of 100m used in the demo is only for demo purpose. When doing a site assessment we typically work with a horizontal resolution of 20 to 50m in the central part, using horizontal expansion factors around 1.1 in the outer domain. In the vertical, we typically set a first cell height to 1m, and ensure that the vertical expansion factor recalculated for smooth transition of the cell size is also around 1.1. In terms of the set up however, there is no lower limit to the specified resolution. For the Bolund test case, for example, we did some simulations with a horizontal resolution of 1m and first cell height of 0.1m. Q: Why ANSYS is using a "round" domain rather than a "cube" we have seen? What is the advantage?" A: Using a round domain makes it easier to specify inlet/outlet boundary conditions as a function of the wind direction when using a single mesh. With this approach, when smoothing the terrain in the outer part of the domain, we ensure that the same smoothed terrain is applied for every wind direction. This way, small changes in the upstream wind directions are treated consistently without inducing inconsistent behaviours associated with artificial changes in the treatment of the terrain. In addition, in the outer regions where the mesh is coarser, the flow is aligned with the mesh, reducing the associated numerical errors. Q: Is WindModeller able to pre-process and merge large coarse resolution SRTM map (10m resolution, 20kmX20km) and smaller higher resolution (2m resolution, 5kmX5km) map? A: Not automatically. The utility in WindModeller that reads SRTM files is able to read standard SRTM and the SRTM DTED format, and produce ASCII terrain files from both, but is not able to automatically do a merging of both types of files. In such cases, a user has however the option to manually merge the resulting ASCII files, filter the data by regions, and use this merged file as an input to the simulation. Q: It would be nice to automatically calculate the centre of the wind farm. A: While it may be a desired feature to automatically centre the simulation domain on to the centre location given by the wind farm layout, it is not always what the users want to do. In particular, the user may want some control over the centre and extent, to be able to make sure that the appropriate terrain features are included, or excluded, from the domain. Also sometimes when the masts are some distance away from the wind farm, the user may want to centre the domain halfway between some mast and the wind farm. All in all we feel that providing the user with the flexibility of setting the centre has more benefit than drawbacks. But if it is felt that automatically centring the simulation domain onto the centre of the wind farm is a must have, it could be implemented easily. Postprocessing related Q: After a WindModeller set of simulations has finished, can you go back and perform additional post-processing on the simulation? A: Yes you can. The results (.res) files from a WindModeller set up are kept and available for the user to open in our standard CFD Postprocessor. If a user wants to include additional post-processing to the standard output given by WindModeller, he can interactively create a session file in our standard post-processor which can later be called within WindModeller in order to customise the output provided by WindModeller. Examples of this are given in the WindModeller Tutorials. Q: Can we export the images/graphs of our results in eps or png or tiff files? A: Yes you can. The pictures and graphs produced by WindModeller shown in the Report html file are also saved in the Report directory. The default format is .png. Additional format options for the images from the Postprocessor would be (bmp, jpg, pbm, ps, eps). x-y graphs have a more limited range of formats (png, bmp, pbm, xpm). There is also an option to save them as 3D pictures that you can then view with the (free) viewer that comes with our post-processing tool. This allows you to zoom in/out, rotate, translate your picture in order to get a better idea of what you see in some part of the flow. It is also worth pointing out that the profile data at the masts and wind turbines corresponding to the graphs produced by WindModeller is also exported for all the individual simulations. So if users want to post-process these in another package, where they may want to compare them with measured profiles, they can do so. Others Q: What differences are there between using the CFX and Fluent solvers in WindModeller and what are the implications of each? A: New developments in WindModeller tend to make their way into the CFX version first, as the models can be implemented in the CFX Expression Language, rather than by writing User Defined Functions. This is the version that we tend to recommend by default to new users. At existing FLUENT customers’ request we have included FLUENT in the WindModeller workflow, however at this point, the forestry model and the stability implementation are not yet available in the FLUENT version. Q: Taking into account that many people use Mac are you planning to develop a version for Mac OS X? A: Unlikely in the short term, as standard ANSYS products are not available on OS X. Q: What are the differences between WindModeller and WindSim or MeteoDyn? A: Many! We don’t want to get into details of what these software packages do, as they are also evolving. We therefore prefer to focus on our features, such as the use of unstructured and adaptive gridding, the fast convergence of the Coupled Solver algorithms, when associated with the Algebraic Multi-grid method, and our state of the art turbulence models, which have been extensively validated across a wide range of problems. Please get in touch if you want to find out more about the details of our software. Q: Do you have any plans to provide an option for automatic layout optimisation? A: Various products are available to provide site optimisation starting typically from a wind resource grid (.wrg) and using empirical wake models, and various constraints for the site. We have plans to ensure that you can use the output from WindModeller in this context (e.g. through a .wrg file from a WindModeller set up that ignored wake effects). At the moment, we feel that a site optimisation while resolving the wakes via actuator disks as we do in our simulations would be too slow to be economically attractive. Q: How is real mast data compared to CFD result? By turbulence intensity or speed-up factors? Are the two comparable? A: So far, we have mostly done mast to mast cross predictions for the average wind speed not so much for the turbulence intensity. The option to transpose turbulence intensity is very new and we haven’t got a lot of experience with the level of accuracy that can be achieved from it. From the limited experience we have so far we find that average wind speed is usually better predicted that the average TI.