Request for blade geometry CAD file

[mfkiwl]

Hi there,

Thanks you very much for providing such an amazing project. I am involved in a research project and is trying to model the wind turbine in ANSYS Workbench. Importing the STL file into ANSYS SpaceClaim is absolutely OK, resulting many facets. But meshing the huge number os facets cause problems: the mesher reported "an unexpected error" (I check my computer's memory while meshing and can confirm the RAM memory is enough). Tried many settings/sizing and all result the same.

So I am wondering if it convenient for you to share the original CAD model (OpenSCAD?) and see if it makes difference in meshing. I also believe the original CAD model will be much easier to use in ANSYS Workbench, such as selecting surfaces.

Thanks.

Regards, Xing

[gbarter]

Hello Xing,

We are very glad to hear that the CAD models are useful to the community. This is a capability that is still under development and we continue to chip way at it.

The CAD model generation from the turbine geometry description is being formalized in the WindIO2CAD repository: https://github.com/IEAWindTask37/windio2cad where WindIO is the name of the ontology definition of the turbine: https://windio.readthedocs.io/en/latest/

The README on the WindIO2CAD should be enough to get you started with the IEA Wind 15-MW yaml file. It sounds like you want a coarser resolution of the blade. You can find those settings here: https://github.com/IEAWindTask37/windio2cad/blob/main/windio2cad/__main__.py#L37

Let me know if you run into issues. I am also tagging @akey7 who is the chief developer for future input.

[mfkiwl]

Many thanks for info. The windio2cad tool is very useful and helped me to understand how the blade was modelled.

[T-Wainwright]

Hello,

To follow up on this I have been doing some high fidelity CFD work on the blade for a while now, getting a high quality, smooth surface which can be used to produce a surface then volume mesh has proven a bit of a sticking point. The provided .step files aren't watertight, which has meant they can't really be used, I know a number of other people have attempted to rectify this, but no established fix has been presented yet.

The work around I have been using is by modifying the windio2cad script, to intercept it after the generate_lofted() method, then outputting the lofted structured blade shape to use as a patch file for one of our in house surface mesh generators. This works well for generating surface meshes, but it remains all dependent on the quality of the original patch file. The Issue we're having is during the calculation of coord_xy_interp a kink is introduced in the 20-30m span region (see image, dotted are aerofoils bounding problem region, green and purple are interpolated surface), which has a clear effect on the flow over the root at that section. Changing the interpolator to a linear one such as interp1d removes it, but obviously results in a poor reconstruction of the rest of the blade, higher order interpolants behave even more bizarrely, inverting that particular section of the blade, which makes me suspect it could be something in the original geometry.

I have attached some images demonstrating the problem. Once we have our smooth surface file I am more than happy to submit it to the repository for others wishing to perform high fidelity analysis of the blade.

All the best,

Tom.

[gbarter]

@T-Wainwright Thank you for carefully illustrating the problem. I have not seen similar comments from others or experienced them myself. I just tried a fresh install of windio2cad and generated the blade stl-file with the commands here and the yaml-files in this repo, but couldn't recreate the problem. Can you specify more clearly what steps you are taking? Are you working with the OpenSCAdd generated stl-files or something else? If so, are they air tight?

[T-Wainwright]

Hi Garrett,

Sure, I'll take some steps to illustrate my process too to highlight why I'm taking certain steps etc. So the ultimate goal is to get a clearly defined, smooth surface geometry we can used to produce a high fidelity aerodynamic mesh from.

So in the original .stl and subsequent .stl files the resolution is defined by curvature, rather than ensuring a good total surface coverage. This leads to issues when trying to use this to form any kind of surface mesh, as shown here:

Additionally pointwise will identify multiple subsurfaces, spitting the surface domains. This issue is the same whether a new .stl is generated using then aforementioned commands in windio2cad, or downloading from the repository.

Attempted surface mesh generated from .stl

Splitting of surface meshes.

In general I think this is more an underlying issue of using .stl files to attempt to define a smooth surface, hence why I've been looking at higher fidelity CAD options.

The original CAD step file located here firstly has the aforementioned issues of being non watertight. The CAD itself is pretty messy to use for CFD, with a few curves simply disappearing towards the tip, and the tip guide curves aren't closed, hence the watertight issues, see below:

To attempt to rectify this I've tidied up the CAD and redefined the surface in terms of b-splines to create a single, piecewise surface definition, which fixes the watertight and vanishing curve issues:

This surface would be suitable then to build the surface mesh on, if it weren't for the other issue- the notch in the 20-30m span region- see earlier aerofoil stack. Examining the new, smoothed file we still get that issue, meaning it is present in the original blade .step geometry from the repository:

The behaviour of the guide curves seems to point to what could the underlying issue- the aerofoils in the .yaml file have a different number of points and a different distribution depending on where they are. As such this notch appears during the generate_lofted() method of the blade class, specifically L157-L163. Our current theory is whatever interpolator is used struggles with the reduction in thickness gradient at this point, as well as the varying number of points at all adjacent sections, which causes a number of guide curves to coalesce, resulting in the notch in the geometry. The fact higher order/ any other interpolant inverted the section only here also points to the interpolant in generate_lofted() struggling to handle the geometry in this part of the blade.

From generate_lofted() we output just original cross sections, along with a few extra sections towards the tip to ensure the geometry is captured accurately round there- these are scaled, translated and rotated etc... We then resample the points to give a constant number and distribution around the surface, before fitting a surface through the sections using b-splines. The resulting surface is seen below, and as you can see the guide curves:

I'm continuing to work on a bit of CAD tidy up for this section, but once I am done we should have a smooth, well defined surface which will be suitable for CFD.

All the best,

Tom.

[gbarter]

Hi Tom,

Thank you for the extended writeup and detailed figs! We would welcome your contribution to the repository to support more CFD analysis of the 15-MW turbine in the broader community. If you have suggestions as to how the windio2cad scripts could do better (different spline interpolations, different point distributions, etc.), we are definitely open to them.

Cheers, Garrett

[T-Wainwright]

Hi Garrett,

Without getting too much under the hood of windio2cad we created the new surface by taking the given control sections (from the yaml file), as well as a few towards the tip obtained by running generated_lofted() and assuming they are far enough from the centre section to avoid the seam issue- high fidelity CFD has shown a good pressure distribution round the tip so we're relatively confident to use though points. Then convert those curves into cubic splines, and fit the surface through those as a bi-cubic. This then allows the surface to be defined in parametric space, and an arbitrary distribution of points can be used to build the surface whilst maintaining the exact shape.

Correct me if I'm wrong but it looks like windio2cad redistributes the points for the aerofoils first (in the AirfoilShape.redistribute() method), then converts them back into cartesian space and uses those for the spanwise interpolation, which I think could be causing the seam issue? Although this might require some clever enforcement of the chord and thickness constraints to ensure the geometry is maintained at the tip!

Additionally it might be worth looking if there are alternative output formats to output the curves- a y+ = 1 CFD mesh for the turbine blade requires a first cell height of approx 1e-5 by our calculations (and again checked in CFD), which would enforce a rather obscene .stl resolution to ensure smoothness at this level! Generally .step or .iges would be best for CFD.

I've finished the blade surfaces so will open up a PR for you to check over!

All the best,

Tom.

[gbarter]

Hi Tom,

Unfortunately, with OpenSCAD, the available export file formats do not include STEP or IGES files. I am aware of how ill-suited STL files are for CFD meshing and am open to suggestions of other workflows to arrive at a STEP or IGES file. Maybe using the OFF file format and converting with a program like FreeCAD?

Cheers, Garrett

[gbarter]

Here is an attempt at a STEP and IGES files using OpenSCAD and FreeCAD. . . IEA-15-240-RWT_blade-hull.step.zip IEA-15-240-RWT_blade-hull.iges.zip

[T-Wainwright]

Hi Garrett,

Same issue with those files as the .stl unfortunately, it appears the the limiting factor for this is the output from OpenSCAD.

It's worth noting that even if the OpenSCAD->FreeCAD toolchain works, it'll still have the interpolation issue at the 20-30m span region.

The way we're handling the geometry is outputting then raw sectional data plus a couple of tip sections in .icms format, then using our software to convert to .iges, then rhino to convert to .step, it's not a clean, reproducible process for a standard user, but the curves are parameterised in terms of curves so should be scalable at least?

All the best,

Tom.