*.stl import, reporting function on wing

A subforum specific to the development of the OpenFoam-based workbenches ( Cfd https://github.com/qingfengxia/Cfd and CfdOF https://github.com/jaheyns/CfdOF )

Moderator: oliveroxtoby

Post Reply
justwanttoknow
Posts: 24
Joined: Fri Oct 08, 2021 9:21 pm

*.stl import, reporting function on wing

Post by justwanttoknow »

I am currently doing a simple wing study to investigate stall behavior. For this wing a publication is existing, which allows validation of the results. The actual wing of interest is a bit more complex, but apparently it makes sense to start simple.

Two items are unclear:
1) The wing is generated as *.stl from a different opensource-software and is naturally "edgy" due to a limited number of faces. Of course it is possible to rev up the number of faces until filesize is not longer acceptable. Alternatives would be .poly, tri, obj. STEP as well, but this has not worked for me.

1a) how is for example cfmesh dealing with such a situation? Is it handling the cell size in line with the faces of the object or will be chaos, when a large cell size is meeting an object with a small number of faces and the corners are not aligned?

1b) Would it make more sense to start with a native FreeCAD model, as this is handled better? This would be easy for the simple wing, but a bit of pain for the complex one.

2) Is there a clever way to assign the faces of the stl to the constraint "object"? So far I've used "select from list" "cut" "select components" "all" and then de-clicking the faces being not part of the wing. Should make sense, but so far the reporting function does not give usable results. Is it connected with the following error message?: "No artists with labels found to put in legend. Note that artists whose label start with an underscore are ignored when legend() is called with no argument."

Thanks a lot for any hints!

Code: Select all

OS: Ubuntu 20.04.4 LTS (ubuntu:GNOME/ubuntu)
Word size of FreeCAD: 64-bit
Version: 0.20.28793 (Git) AppImage
Build type: Release
Branch: (HEAD detached at 5386d4e)
Hash: 5386d4ed864cd03edd026e1d3d128cccedf568df
Python 3.9.12, Qt 5.12.9, Coin 4.0.0, OCC 7.5.3
Locale: English/United States (en_US)
Installed mods: 
  * CurvedShapes 1.0.3
  * CfdOF 1.17.0
  * Plot 2022.4.17
  * AirPlaneDesign 0.4.0
edit: there is an error message while uploading the file of 1.1MB to this post. Will try again in the evening.
edit2: upload here: https://github.com/ysopflying/CFD-learning-repository
thschrader
Veteran
Posts: 2642
Joined: Sat May 20, 2017 12:06 pm
Location: Germany

Re: *.stl import, reporting function on wing

Post by thschrader »

At first you should check the imported stl with the mesh-wb.
In my case (imported stl-wing, ingenuity heli blade) the stl has some errors
and is not a solid. The repair can be time consuming (or impossible),
so in my opinion it is better to remodel the wing.
Better for parametric studies.
When your stl is ok, you must transform it into a shape, then into a solid (part-wb),
to subtract the wing from your fluid domain.
It is not necessary to click all faces for boundary definition. Select only 1 face and
tick the default option (case writing needs a while if you have a lot of default faces)
Regards Thomas
boundary.JPG
boundary.JPG (27.96 KiB) Viewed 450 times
checkSTL.JPG
checkSTL.JPG (151.02 KiB) Viewed 450 times
justwanttoknow
Posts: 24
Joined: Fri Oct 08, 2021 9:21 pm

Re: *.stl import, reporting function on wing

Post by justwanttoknow »

Thomas,
thank you very much indeed for looking into this.

Checking one face and using as default is a good idea.

Mesh check and converting to solid was without any problems.
Maybe a bit of an issue to have such a coarse mesh and expecting anything reasonable from it. The other file with a very high resolution was clearly overdone and it was not completing meshing.
So subject to experimenting as well as using different import options (as said, would be nice!). Apart from building a native wing.

Currently mesh check is failing, not converging and forces are zero. Something to work on.

Thanks again and schönes Wochenende,
Niels
justwanttoknow
Posts: 24
Joined: Fri Oct 08, 2021 9:21 pm

Re: *.stl import, reporting function on wing

Post by justwanttoknow »

Apparently there are a multiple ways of failing meshes.
Screenshot from 2022-06-26 09-50-44.png
Screenshot from 2022-06-26 09-50-44.png (73.32 KiB) Viewed 324 times
Apart from the obvious problem, that not the correct surface used for the boundary layers, some elements fail at the root of the profile.
- does it have something to do with a part and a part-design body combined?
- Where to repair meshes for such single elements? When switching to mesh design, most of the entries are great out.

Sorry for needing a bit of help on this. But I am trying for weeks, and as it analyzing a 3D-wing is such a common task, it could be beneficial for others.
Attachments
naca4415native.FCStd
(416.16 KiB) Downloaded 6 times
thschrader
Veteran
Posts: 2642
Joined: Sat May 20, 2017 12:06 pm
Location: Germany

Re: *.stl import, reporting function on wing

Post by thschrader »

Here is my first attempt for naca4415.
I used a 2D-mesh, your profile is constant over the wingspan.
3D is an overkill, in my opinion...

Inlet speed is 45 m/s to get Re=3*10^6 like the test data in
NACA-Report 586 (Google!). See report and FC-file.
c-Lift approx 0,8, c-Drag approx 0,016 at AoA=4 degrees.
naca4415ts.FCStd
(250.22 KiB) Downloaded 4 times
NACA4415report.pdf
(497.26 KiB) Downloaded 7 times
justwanttoknow
Posts: 24
Joined: Fri Oct 08, 2021 9:21 pm

Re: *.stl import, reporting function on wing

Post by justwanttoknow »

Thanks Thomas, especially for spending time for making an extensive report on this. Highly appreciated, as turbulence and y+ is something I'll have to familiarize with.

You are right, this is overkill. Even CFD is, if the other methods deliver much faster results in sufficient efficiency. Especially for such a zero sweep, zero taper wing.

In a flight simulation project I'd like to improve the stall behavior. For this lifting line, vortex lattice method etc. fail and there are in general little data. For stall things change between 2D and 3D, for example the second "hump" of CL at abt. 35° alpha is significantly shallower. As a short term goal reliable information about the "sharpness" of the CL-curve at CLmax is needed, as long term CL,CD,CM with stall hysteresis. But apparently this is quite a journey...
Reference document is: https://ntrs.nasa.gov/citations/20140000500.

For those interested a watertight and much finer *.stl along with the STEP-file can be found in my repository.
Post Reply