cfmeshing hell - 30P-30N Validation Case

[oliveroxtoby]

Did you have a look at the settings in the Wolf Dynamics solver files ?

Yes - the settings I highlighted are what I feel are the most likely culprits when comparing the two.

However it would be important to be systematic here. First see if you can reproduce the correct result using the WD settings but on your mesh. If so, we know the difference lies in the settings and it can be narrowed down from there. Otherwise it's easy to speculate and go down the wrong path.

[oliveroxtoby]

But if you look at vector diagrams for a wing in a turn, the lift vector is canted, as it should be. It's all about definitions. I just need to know which one people are using.

Lift/drag should always be perpendicular/parallel to the free stream. Otherwise you are talking about the normal and axial coefficients, which are something else.

It appears WD is modifying the direction of the force result vector when changing the AoA. This is their controlDict:

My guess is they are changing the free-stream direction to achieve the change in angle of attack, rather than changing the geometry. Therefore the lift direction must be changed to remain perpendicular to the free stream.

[techGuy]

Did you have a look at the settings in the Wolf Dynamics solver files ?

Yes - the settings I highlighted are what I feel are the most likely culprits when comparing the two.

However it would be important to be systematic here. First see if you can reproduce the correct result using the WD settings but on your mesh. If so, we know the difference lies in the settings and it can be narrowed down from there. Otherwise it's easy to speculate and go down the wrong path.

OK. I'm busy on other things for the next few days. I'll get to this early next week.

[techGuy]

Lift/drag should always be perpendicular/parallel to the free stream. Otherwise you are talking about the normal and axial coefficients, which are something else.

OK.

My guess is they are changing the free-stream direction to achieve the change in angle of attack, rather than changing the geometry. Therefore the lift direction must be changed to remain perpendicular to the free stream.

OK, I never thought of that. Thanks for the reply.

[thschrader]

...
This is why I asked why WD edited nu.
...

WD tried to use sulfur hexafluoride as gas for the simulation. With the nu=2,44*E-7 and
the density given in the literature (6,63-6,18 kG/m^3 between 0-15 deg C)
https://www.messer.es/documents/2227840 ... 5858728947
you can use a very low inlet speed (around 1 m/s, which they have in the U-dict), to match Re=5000000.
But there is a mistake. The dynamic viscosity of sulfurhexafluoride according to the literature is 10 times higher,
which gives nu=2,44*E-6 and v-inlet =12 m/s.
I checked the provided stl of the multiwing, the stowed chord-length is 1 m.

sulfurhexafluoride_wrong.JPG (70.87 KiB) Viewed 1399 times

[thschrader]

This is what I get when re-running the WD-case files from the bluecfd console.

The circular mesh has a diameter of 300 m (wing-span 1200 mm unfolded), 1 m thickness.
You can adjust the freestream direction by changing the U-dict, not rotating the wing.
If you do this, you must change the cL/cD-directions in control-dict too, for reprojecting the vectors.

Even when running the same case on a different machine, I get 2% error on cL and more than 5% error on cD,
compared to the numerical results from the WD-website. The solver cuts of after 2000 iterations, no residual cutoff defined.

I tried to load the WD-mesh (msh fluent file) with gmsh, doesnt work, syntax error.

Lets try to reconstruct the mesh with FC-cfdof.

wd_case_with_bluecfd.JPG (189.51 KiB) Viewed 1341 times

[thschrader]

Some questions about cfmesh. Cant find the answer in the user manual.

I want to reconstruct the WD-mesh from above (the circle, here: quadrat),
using 6 volume refinement-levels and 1 surface-refinement. See pic below,
the wing is in the middle of the refinement cubes.

1.:
How are the integers (blue) computed?
In the GUI I can use real numbers (gray background), which I cant see in the meshdict-file.

2.:
When using the written default meshdict, cfmesh consumes > 16 GB RAM,
even without surface refinement/boundary-layers.

3.:
When editing the meshdict after writing and using the red integers, meshing works, 6GB Ram.
But the mesh is to coarse.

4.:
When using a mesh refinement number below 0,001, cfmesh shows a red warning string for a few seconds
("You should not go below 0,001 refinement", something like this), starts the mesher but hangs after a while.

5.:
When the max refinement level is 0,001, compared to max cell size, and I need a cell of 0,5 mm diameter at the wing,
my max-cell-size is 500 mm. Right?

The meshing problem looks easy, in fact very hard, for my taste...

refinementlevel_integers.JPG (138.24 KiB) Viewed 1299 times

[oliveroxtoby]

1.:
How are the integers (blue) computed?
In the GUI I can use real numbers (gray background), which I cant see in the meshdict-file.

CfdOF converts the fraction to an integer in order to make sure the mesh is at least as fine as the desired fraction of the base edge length. The refinement in cfMesh and snappyHexMesh works by successive halving of the base edge length, so it is not continuously variable.

4.:
When using a mesh refinement number below 0,001, cfmesh shows a red warning string for a few seconds
("You should not go below 0,001 refinement", something like this), starts the mesher but hangs after a while.

I guess the mesh just has too many cells to handle.

5.:
When the max refinement level is 0,001, compared to max cell size, and I need a cell of 0,5 mm diameter at the wing,
my max-cell-size is 500 mm. Right?

Yes.

CfdOF generates 2D meshes by first generating a 3D mesh and then extruding a patch. This means that you end up generating a 3D mesh with way more cells than the eventual 2D mesh has. You could try making your refinement boxes only just touch the body being meshed so that you only refine the area adjacent to the patch that will eventually be extruded, instead of the whole 3D volume.

cfMesh has a utitliy 'cartesian2DMesh' that generates 2D meshes directly, but you do need to remove any input geometry in the XY plane to use it.

[thschrader]

...
You could try making your refinement boxes only just touch the body being meshed...

That seems to work, with a tine overlap between the refinement cubes and the fluid domain (gray)
the RAM-load is reduced a lot. I will have a further look on this (and 2DcartesianMesh) at the weekend.
Thanks, Thomas.

overlap.JPG (32.32 KiB) Viewed 1184 times