Problems meshing an impeller with snappyHexMesh
3 Attachment(s)
Hello,
I designed this impeller in order to be as simple as possible but I am having so much trouble meshing it I'm worried what I'll do with complicated ones... After countless experiments with snappyHexMesh settings I managed to get a good enough surface fit and mesh works with AMI but the simulation fails because there is one edge that the mesh can't snap to. A case without turbulence modelling somehow works, but with k-Epsilon the epsilon goes berserk. I know the STL are OK because I made a 2D mesh on a STEP model first, using Salome and Netgen 2D. I got a set of watertight surfaces with very little deflection from the original model... Here is my snappyHexMeshDict: Code:
/*--------------------------------*- C++ -*----------------------------------*\ I have searched all over this forum and the internet and I can't get a good mesh. I haven't even started with adding layers; does adding layers refer to the original STL surface or to the existing (bad) mesh? Do you have any advice for me? Thanks! |
Try larger values for nSmoothPatch, nSolveIter and nRelaxIter
|
1 Attachment(s)
Hello,
thanks for your suggestion. i tried with nSmoothPatch 30; nSolveIter 30; nRelaxIter 30; nFeatureSnapIter 30; (that took quite some time :) ) but the results aren't better, a bit worse actually. see the attached mesh. increasing refinement level should produce better meshes, but in my case it's not snapping well for any refinement level at all, it just makes the edges more finely chipped. i'm asking for help here for two reasons, first because i'm running out of things to try and second, because i'm not very fond of my trial-and-error approach. i have plans for the future to automate some things (just like that's already done in commercial packages) and it won't go with my current "workflow"... |
Why do you use these values: resolveFeatureAngle 1 and featureAngle 180?
I have had quite good meshes with values: resolveFeatureAngle 30 and featureAngle 60. |
1 Attachment(s)
those values were a part of one of a million experiments. i changed them back to what you suggested. here's the whole snappyHexMeshDict if you find any clues.
Code:
/*--------------------------------*- C++ -*----------------------------------*\ Code:
/*--------------------------------*- C++ -*----------------------------------*\ - one block / a cube - five blocks that form a cylinder with this 'try' i used the first mesh. see the attached result. |
I would lower back patch smoothing and whatnot to what you had before. These settings rarely help getting better feature capturing for me.
To me it looks like that airfoil approaches the wall at a sharp angle, is that true? If so, the problem is probably that you need to refine that edge more than other edges. I would make sure to have just an edge available for the airfoils and refine those a bit. Otherwise your only choice is to lower the size on the airfoil itself. |
2 Attachment(s)
hello,
thanks for your suggestions. I have split the geometry of the impeller walls into blades and shroud so I could increase refinement on the blades only. And I changed back snapping iteration settings back to values from the flange tutorial. Although the mesh conforms a little better now it's still not good. The very important AMI patches don't snap to geometry at all and the blade corners are still chipped but on a smaller scale. I think I'll be giving up on snappyHexMesh very soon since I've been wrestling with this for the past few weeks and I obviously haven't found the very magic combination of all the parameters for a good mesh on a relatively simple geometry. I used Netgen with viscous layers in Salome and a got a perfect (though tetrahedral) mesh within a minute. Interestingly, I was explaining to my brother what I've been doing and his question was why is it so hard to divide a model into small pieces? I couldn't answer him. |
Quote:
I think the answer to this is obvious. It is easy to divide a model into small pieces, but it's hard to do so well. If one were to rank the popular meshers out today I'm sure snappy would be somewhere near the bottom, but it's free and has few developers. This geometry is very easy to mesh in commercial meshers, but you have to pay for them. CAD packages and meshers are two types of programs where there aren't really any good generalized open-source packages available. |
I tried using exactly the same settings as in flange tutorial and it seems that refinement messes things up, particularly on edges. I simply made an insanely fine blockMesh and no refinement and it's all good now. My simulation runs now.
I wonder why there's nothing going on with foamyHexMesh, it looks much more promising than snappy. If I was to write a mesher I'd start from the surface, like foamy, not from the inside, like snappy. Anyway, thanks for your help. You know, every beginner is difficult. |
I tried cfMesh.
I wasted a month on snappy and couldn't get it to make a mesh that works in my MRF case but after a few hours with cfMesh, voila, everything runs with no problems. Just sayin'. |
Hi,
cool Avatar, reminds me of me. Is it possible to have cfMesh directly create the cellZones needed for the MRF or how did you do it? I think it is possible with some OF utility to use cylinders and so one. I am asking because I have a case with a cylinder-conus shape MRF region and was wondering about using cfMesh. Thanks, André |
hello,
i create zones with topoSet. in my case impeller itself is meshed separately and the whole mesh is in its own zone so i just have to use a box big enough to fit everything inside. here's my topoSetDict: Code:
/*--------------------------------*- C++ -*----------------------------------*\ topoSet setsToZones and that's it. [as for the avatar, Kudos go to xkcd.com :)] |
I see,
as you were using AMI together with MRF I guess meshing two meshes can work. I think it would be nicer to mesh in one go as the mesh would then be on piece, just different cells would have a certain zone. |
if you can describe your mrf zone with simple geometry like cylinder, that would certainly be better.
one of my problems was memory consumption - with finer background meshes, blockMesh ate my RAM very happily. so by dividing mesh into smaller regions I could achieve better resolution with the same amount of RAM. sort of. |
All times are GMT -4. The time now is 21:48. |