Answers to Webinar "Wind farm flow modelling using CFD

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
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
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
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
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
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.
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
Q: Taking into account that many people use Mac are you planning to develop a version for Mac OS
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.