CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Native Meshers: snappyHexMesh and Others (http://www.cfd-online.com/Forums/openfoam-meshing-snappyhexmesh/)
-   -   snappyHexMesh inconsistent meshing (http://www.cfd-online.com/Forums/openfoam-meshing-snappyhexmesh/122662-snappyhexmesh-inconsistent-meshing.html)

Boloar August 24, 2013 23:17

snappyHexMesh inconsistent meshing
 
3 Attachment(s)
Hey all.

I'm working with a 2D rotating AMI wind turbine simulation, which is up and running for the most part.
One problem I seem to be having, though, is that if I modify my STL very slightly, the rotation region no longer remains smooth.
If you look at the attached images, you'll see what I mean - with the first iteration, the rotation mesh is smooth (normal.jpg). Then if I rotate (only) the center vanes of my turbine by a few degrees, leaving the outer blades in the same place, the outer rotation region is no longer smooth (mesh2.jpg) - and at some point of rotation it becomes crazy jagged (mesh3.jpg).

Is there something I'm doing wrong, or is snappyHexMesh hit-and-miss like that?
Although I think extrudeMesh has something to do with the mesh3.jpg problem ...

Input is appreciated!

Edit: I used Blender to rotate the inner vanes. I forgot to show the rotated vanes in the attached image, sorry - I'll attach it later if you need it.
The turbine is defined as one STL file, and the circular rotation region around it is another cylinder STL. So I don't understand how changes in the turbine file are causing the rotation surface to mesh differently.

Boloar August 25, 2013 01:58

1 Attachment(s)
Here's my case files, if anyone wants to give it a look.
All the modifications are made in a subfolder adjust/, and the Allrun script copies the edited files to the appropriate places.
adjust/VAWT.stl is the file I've been working with, only rotating the inner blades, in increments of 3 degrees at a time.

miro2000 August 25, 2013 03:31

Hello Boloar,

Unfortunately I can't help you. I will try to do something similar in the near future so am also interested in this problem. You should check out propeller tutorial.
In that tutorial I have seen that baffles are being used instead of .stl for cylinder at the rotating region boundary.
If I understand correctly, you are using sliding mesh, and not dynamic mesh (remeshing)? And if not, why not?

Also, I don't know if OF has this implemented yet, but it could be interesting to use periodic BC, so your cell count could go down by 75%.

Sorry for no help
- miro

Boloar August 25, 2013 06:10

Quote:

Originally Posted by miro2000 (Post 447870)
You should check out propeller tutorial. In that tutorial I have seen that baffles are being used instead of .stl for cylinder at the rotating region boundary.

Actually, I used that as the basis of my attempt. I took the mesh creation from that tutorial and kind of hacked at it until it became a suitable 2D mesh including baffles, etc. Actually, a OBJ cylinder is used to define the rotating boundary in order to place the baffles correctly.
Using that tutorial made things a lot simpler than trying from scratch. Then I took that mesh and used the initial & boundary conditions from the incompressible/pimpleDyMFoam/wingMotion tutorial to get airflow rather than water flow conditions.
It took over a month to figure out even with help from these forums as I'm not the most competent programmer. ... but it works for the most part. I'm not sure how dynamic meshing works - I used the sliding mesh since that was how the propeller tutorial was set up, and it's given me relatively few problems so far.

Most of my simulations have had no problem thus far, but what I can't figure out is why such a small change in one STL model is causing the rest of my mesh to get messed up. You're welcome to take a look at my files if you're interested in these simulations, it'll save you a lot of time. It should work right out of the box.

Boloar August 26, 2013 08:29

Ok, so I've figured out a part of it. I changed the extrudeModel in extrudeMeshDict to linearDirection rather than its default linearNormal. Now the problem from my third image up there is gone as far as I can tell and my mesh is perfect 2D.

I can't figure out the sHM problem though - with my original STL model, the mesh turns out beautiful and smooth, but if I rotate just the inner vanes by a tiny amount, the entire mesh turns jagged - and I can't have that since this is a rotating simulation. What gives, any ideas?

Boloar August 28, 2013 06:24

This is driving me nuts.
I have the vertical-axis wind turbine STL model (see post #1), and the *only*, repeat, only thing I do is rotate the inner vanes, w.r.t the outer blades, by 5 degrees at a time, up to a 115 degree rotation (since it'd be repeating every 120 degrees). Note that the circular outer region is defined in a completely different STL file from the turbine blades, and is left untouched for all of this.

The resulting series of meshes using snappyHexMesh has a pattern of 3 good meshes and 3 bad meshes as one goes along. That is, from the list of rotations here, the ones underlined show up jagged in ParaView and fail the checkMesh utility, while the others mesh cleanly and simulate fine.
0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, 60, 65, 70, 75, 80, 85, 90, 95, 100, 105, 110, 115

I can't figure it out for the life of me - I've gone over the STL file several times, even re-extruded it, and it's impeccable. I tried increasing sHM complexity, decreasing it, adjusting orthogonality tolerance etc. (although I don't fully understand half of the options in sHM) ... and the same pattern of good and bad meshes shows up. I can't understand why changes in one STL are messing up the meshing of the outer surface.
If you can shed some light on this, I will (figuratively) love you forever.

colinB August 28, 2013 07:26

Hi Boloar,

first of all I have to admit I have no clue how to simulate
rotating things or wind turbines.

However when looking at your list with good and bad meshes
it is striking that there is a pattern in it
(I'm not sure whether you did already or not, but draw a circle
with a 5 degree scale on it and mark those positions where
you get bad meshes)
I did and the only logic conclusion is that with the mesh in those
states sHM cannot deal for whatever reason.

sHM is actually very sensible to even small changes, e.g.
I had recently a case where my calculation crashed but adding
one row of cells in one direction solved the problem.

SO my advise for you:

- try to change the background mesh, add one row of cells or deduct one
in any direction, it might help

- increase the number of maximum cells in your sHMD
so your mesh can get finer

- do you use featureEdge? if not this might be an option.

Please try those hints one by one to see the effect of them.
If it doesn't work out, you might want provide us your sHMD
or even a case to have a deeper insight in the problem.

I hope I could contribute
regards
Colin

Boloar August 29, 2013 03:29

Thank you for your input Colin, I only just saw your reply ... I dug through the forums and found a suggestion about changing nSmoothPatch under snapControls in the sHMD. It was at 3, I lowered it to 2 and checkMesh now reports the problem meshes as OK. Of course, I don't really understand why, but I'm not complaining ... I just hope that they simulate fine. Wish me luck. :D

If you're interested in learning about rotating domains, I suggest you look at the tutorial incompressible/pimpleDyMFoam/propeller, as that was the basis for my simulation. For vertical-axis wind turbines, a 2D sim is sufficient, so I 'hacked' that 3D tutorial into a 2D form. (also my most powerful computer right now is a 5-year-old 2.1GHz Core 2 Duo, so 3D meshes are out of the question).

Quote:

Originally Posted by colinB (Post 448489)
Hi Boloar,

first of all I have to admit I have no clue how to simulate
rotating things or wind turbines.

However when looking at your list with good and bad meshes
it is striking that there is a pattern in it
(I'm not sure whether you did already or not, but draw a circle
with a 5 degree scale on it and mark those positions where
you get bad meshes)
I did and the only logic conclusion is that with the mesh in those
states sHM cannot deal for whatever reason.

sHM is actually very sensible to even small changes, e.g.
I had recently a case where my calculation crashed but adding
one row of cells in one direction solved the problem.

SO my advise for you:

- try to change the background mesh, add one row of cells or deduct one
in any direction, it might help

- increase the number of maximum cells in your sHMD
so your mesh can get finer

- do you use featureEdge? if not this might be an option.

Please try those hints one by one to see the effect of them.
If it doesn't work out, you might want provide us your sHMD
or even a case to have a deeper insight in the problem.

I hope I could contribute
regards
Colin



All times are GMT -4. The time now is 02:28.