2D Cylinder mesh problems with Snappy
2 Attachment(s)
Hi Foamers,
I'm trying to mesh a 2D cylinder (1 cell in z direction) using snappy, following the tutorial tutorials/incompressible/pimpleDyMFoam/wingFlutter, where a 2D airfoil is meshed with snappy. It seems that with my settings snappy is not capable to recognize correctly the cylinder (that is an stl surface obtained with gmsh), and it doesn't cut the mesh. I attach the resulting mesh, blockMeshDict and snappyHexMeshDict. Could anybody help me to fix it? Thanks, Ivan http://img547.imageshack.us/i/snappycyl.jpg/ http://img821.imageshack.us/i/snappycylonly.jpg/ http://img547.imageshack.us/i/snappycylzoom.jpg/ |
Hi Ivan,
It looks like there is a problem with your stl file. The surface cylinder is not closed. Also your refinement boxes seem messed up. If you're doing 2D they should be like this: refinementBox1 { type searchableBox; min (-1 -0.5 -0.1); max ( 1 0.5 0.1); //changed 0.06 to 0.1 } refinementBox2 { type searchableBox; min (-0.05 -0.05 -0.1); max ( 0.05 0.05 0.01); //changed -0.01 to 0.1 } otherwise with the old settings you will probably get more than one cell in the z-direction. |
Hi Ziad,
I am running into a problem that you might have an answer to, given your last response to Ivan. I am trying to make snappyHexMesh produce a 2D mesh on the airfoil in the wingMotion tutorial. I tried changing the snappyHexMeshDict refinement box as follows: Code:
refinementBox I posted this issue first a couple of days ago in another thread (http://www.cfd-online.com/Forums/ope...-tutorial.html) before I saw your post. Thanks, Dan |
Hi Daniel,
I tried once to make a 2D mesh with sHM but got more than one cell in the z direction. I think this is due to the fact that sHM divides whatever you have initially in blockMesh in the z direction by the specified number of levels. Not sure how to get around that. Since it was a simple rectangular shape I ended up using blockMesh which is quite good for simple cartesian shapes. Try maybe meshing only one of the empty bc planes with sHM and then extrude the mesh in the z direction? You should only have one z coordinate throughout sHMDict. Let me know how it works. Ziad |
Hi Ziad,
Thanks for the response. The z-coordinate only appears twice in sHMdict, where the boundingbox is defined. Unfortunately, I do not think the extrude function will not work for me because I have divided my geometry (airfoil) into two patches (a wing and a flap), but since there is one continuous object, extrude followed by autoPatch would recognize the airfoil as only one patch. Is it possible to delete the offensive points, blocks and edges from the polyMesh directory manuallly? I imagine this might be next to impossible. I'll keep working this. Thanks again, Dan |
Quote:
|
Hi Daniel,
I've answered you about 2D in SHM on your other thread. Can you give me in more details your problem in extruding an unconnected boundary like a wing with a slat? I have a very similar problem, for which I'm managing to use extrude... Quote:
|
Quote:
|
2 Attachment(s)
Hi Ziad,
I tried setting the boundingBox coordinates in the same xy plane, however this just eliminated the effect of the boundingBox. I am very interested in using the extrusion to cut the mesh. Can you please provide some detail about how to do this? Looking at the extrudeProperties dictionary, I do not see how it is possible to cut the mesh. I have attached pictures of the side view of the mesh. The zoomed-out pic shows the majority of the domain as 1-cell deep, with a white square in the center. The zoomed-in pic shows the upper-left corner of this white square, which is in fact a highly resolved mesh of the front/back of the airfoil. If I extrude the empty front patch one cell, will it cut one "airfoil thickness" cell, or one "majority of the domain" cell deep? Thanks, Dan |
Hi Dan,
The extrude/cut process involves using extrudeMesh (which doesn't cut) first and then splitMesh (which cuts) to make the internal boundary external. splitMesh is a bit tricky to use. Will take a look at both later tonight and post what I can come up with. Just a thought about using sHM in pure 2D mode, you'll probably have to start up your domain in blockMesh with blocks consisting of one flat plane. You'd have to collapse one empty plane into the other, or in other words, use exactly the same physical points on both empty planes. Ziad Quote:
|
Hi Ziad,
There is also another tool called "removeFaces" which, from the brief description in the user guide, should merge cells. If I could do this to all of the cells across the z-axis, then I would arrive at a 2-D mesh. Have you used removeFaces before? I have looked at the code and scanned the boards, but documentation on using it appears to be scarce. Code:
Usage: removeFaces <faceSet> [-overwrite] [-parallel] [-case dir] [-help] [-doc] [-srcDoc] Dan Thanks, Dan |
SnappyHexMesh in 2D
1 Attachment(s)
In case anyone is interested, I have attached a script that can be run in Octave that will read the points and faces files of a mesh and output all of the internal faces parallel to the empty patches into a faceSet file. Place the faceSet file in the polymesh/sets directory, run removeFaces remFaces -overwrite, and you will transform your snappyHexMesh from 3D into a 2D mesh. I just tried it on the movingWing tutorial and it appears to have worked. Note that the z-coordinates of the empty patches must be entered in the script - it is hardcoded for z = +- 0.1 now. Enjoy.
Dan |
creating a 2D mesh with snappyHexMesh
5 Attachment(s)
Hi Daniel,
I finally got to spend some time on this and figured out how to do it using only OpenFoam tools. The procedure outline is the following but does not require splitMesh:
|
Hi Ziad,
I cannot thank you enough. What you have done is far easier than the method I had attempted. I really appreciate you taking the time to explain everything in such detail as well. Regards, Dan |
You're quite welcome Daniel. I've been promising myself to formalize this for a while now so thanks for providing a little nudge. This is all going towards creating a wiki page.
what are you working on by the way? |
I am trying to create a simulation of a wing with an oscillating flap. I began with a basic c-grid using blockMesh, but I could not get the diffusivity to work and the mesh turned itself inside out at the trailing edge. The diffusivity works fine on the movingWing example, but I could not create the same mesh in 2D until now. Apart from creating the wiki, what are you working on?
Dan |
Interesting problem. Are the oscillations self-induced or operator driven?
My work is on snow, ice and rain simulations using two-fluid formulations. I've done some work in aircraft icing as well. |
The oscillations are operator-driven. Aircraft icing and multi-phase simulations sound very interesting as well!
|
Quote:
Any idea how to manage this? |
It sounds like your dict file is not properly set up. Can you post your case as a tar.gz attachment?
|
Right now I'm not at work so I can't post it, but I can tell it fails with an error of different areas in faces of cells on the boundary of the processors. Something like
"face # area does not match neighbour # by %" |
Sounds like a boundary mismatch. Anyway, post it when you have a chance.
|
1 Attachment(s)
I don't get what you mean by "boundary mismatch".
If I run the case without decomposing it, it runs without any errors. If I run it decomposing it first, it gives the error you can see in the log attached. Thanks. |
1 Attachment(s)
I ran it serial and it went okay except for some weird faces in your borde_ataqe and borde_salida regions. The ones in the jpg are for the trailing edge on the Front plane. There area few others. I think they are not connecting properly with their equivalent faces between the Front and Back planes. Their general location corresponds to the error reported in your log file.
There are some warnings in your log file regarding possible wedges between the Front and Back planes as well. Might be related... Code:
--> FOAM Warning : Oh yeah, the trailing edge is warped too in the z direction but this won't matter once you extrude as per the procedure I suggested above. It's the snappy bug for CAD edges but apparently they fixed it in the next release. |
Ran it in parallel and snappyHexMesh finishes similarly to the serial run. The mesh also fails two checkMesh tests in both serial and parallel.
Code:
***Number of edges not aligned with or perpendicular to non-empty directions: 38872 |
How did you run it in parallel?
I always get the same error. I've tried a few combinations, even without the boxes and always fails. |
|
I think you have to do
mpirun -np snappyHexMesh -parallel so it really runs it in parallel. Am I wrong? |
That's how I run all my OF executables in parallel for OpenMPI. Use it and you'll see that it works. I just tried the -parallel option and it failed like it did for you. They provide this option in the user guide for 1.7.x but I am not sure when it was introduced. Personally I never used it. You might want to search the forum on this topic.
Anyway, both parallel and serial checkMesh fail so the problem is in the specific settings at the leading/trailing edges. I am not sure but I think I've seen something like this a few months ago with snappy when preparing the 2D procedure. A simpler refinement box around the entire airfoil and extending to the exit plane could work better. |
By the way you don't have to reconstruct your parallel case anymore. Just process it as you would a serial run. That part of the user guide is outdated.
Definitely skip the -parallel option. It might actually be the (very) old way of doing things. |
That way you don't to decompose your case either. I don't think that's the right way of doing it.
http://www.cfd-online.com/Forums/ope...-parallel.html |
It's up to you. All I can tell you is that -parallel is not needed and it's been a while that you don't have to reconstruct your case anymore. Used to be like that with the older parallel implementation but not anymore.
Wouldn't hurt to try it :) |
Ok, I just tried and it does not work the way you say.
It takes the same time to perform, and twice the ram. It is say doing both processors perform the same case. It even works without decomposing. |
Oops my bad! Just checked our execution scripts and it is implemented with the -parallel option.
|
Hi all,
I've been reading through this topic and practicing a bit on the method discribed by Ziad but I struggle to understand one thing: In order to create the 2D mesh starting from a sHM mesh, we need to make a 3D mesh with the face of interest that has sufficiently enough cells to be usefull to us. So for example, in my case, I need to mesh a foil section with about 4M cells to obtain a mere 140k cells once 2d'ed. Am I missing something there or is is there a way to avoid spending a fair bit of time making a big mesh to get a dumb coarse 2D mesh? Thanks, |
extrudeMesh
The method for me does not seem to work. I have tried to find a solution. To no avail. The problem is as follows:
I am trying to model a multi element wing cross section. First I create the blockMesh and run sHM in parallel. Subsequently I use reconstructParMesh to view it in paraview. In paraview it looks good. Then I copy the polyMesh directory from time3 to constant and I run extrudeMesh. However it does not create new patches. Needless to say, autoPatch does not work either. My model is in the y-z plane. However I don't quite understand how to edit the extrudeMeshDict so that it works. (I am assuming this is the same file as the extrudeProperties file posted by ziad?) I did try several combinations of the wedge properties, but this did not help. Any thoughts? Thanks in advance, Nick |
OpenFOAM version
Apologies I forgot to mention OF and ubuntu version. I am running OF 2.01 (I think, the latest version in the ubuntu software center) and Ubuntu 11.04.
|
Quote:
Code:
// What to extrude: |
All times are GMT -4. The time now is 13:31. |