Dear all,
I have been trying to construct a blockmeshdict that specifies a box with airinlet and waterinlet wateroutlet and airoutlet. this acctually consists of two blocks, one on top of the other:

verticies(
(-50.11 -20.23 -30) //0
(-50.11 20.23 -30) //1
(-50.11 -20.23 0) //2
(-50.11 20.23 0)//3
(-50.11 -20.23 30)//4
(-50.11 20.23 30)//5

(50.12 -20.23 -30)//6
(50.12 20.23 -30)//7
(50.12 -20.23 0)//8
(50.12 20.23 0)//9
(50.12 -20.23 30)//10
(50.12 20.23 30)//11
)
blocks
(
hex (0 1 3 2 6 7 9 8)
(50 20 30)
simpleGrading (0.5 0.2 1)

hex (2 3 5 4 8 9 11 10)
(50 20 30)
simpleGrading (0.5 5 1)
)
and i have patches like this:

patches
(
wall walls
(
(0 1 7 6)
(0 6 8 2)
(2 8 10 4)
(1 7 9 3)
(3 9 11 5)
(4 5 11 10)
)
patch win
(
(0 1 3 2)
)
patch ain
(
(2 3 5 4)
)
patch wout
(
(6 7 9 8)
)
patch aout
(
(8 9 11 10)
)
);

now this all looks good and i get the impression that i only end up with one region (i.e. that the patch between is erased and not there).

when i then run snappyHexMesh specifying the position by:

locationInMesh (0.12 10.1 -5.252);

what happens is that it all runs well and i get:

Found point (0.12 10.1 -5.252) in cell 15683 in global region 0 out of 2 regions.
Keeping all cells in region 0 containing point (0.12 10.1 -5.252)

and when i look at the object (a boat) it is located at the bottom of the top block. what to do?
i would like to place it somewhere in between the two blocks and let water flow by it.
what am i doing wrong?
i think it might just be a matter of a stupid mistake but i can not find it now.

thank you
Erik Ekedahl

[alexm]

Hello Erik,

good to see, that I am not alone ;-)

My blockMeshDict is similar to yours, 12 vertices and 2 blocks. snappyHexMesh identifies these mesh as only one region, without any internal patch.

Is it possible, that your locationInMesh lies inside of the object? If I choose a value like this, two regions are found by snappyHexMesh - but the resulting mesh only contains of a mesh of the object.

The location of an object according to the block is controlled by its coordinates - or by the coordinates of the block. So the best way is to choose the coordinates of the block in hexMeshDict so, that it is placed around the block(s).


Another thing: I have found that snappyHexMesh seems to prefer aspect ratios of about 1. So I don't use any gradings - for me this works much better, especially with complex geometries.

Hope this would help.

Greetings, Axel

i know, it is good!
allright, anyways, thank you! i was not using an aspect ratio of 1 now will try that in a moment.

i did on the other hand just change a bit in the blockmeshdict so that the bottom box is a bit larger than the top one (i.e. instead of -30 0 and 30 in z-axis i used -30 5 30) and now i got something that looks like a better setup.

i think in fact that no matter what the stl-object snaps to origo in the z-direction, which for me makes no sense but using the setup i just mentioned it might work anyway.

did you get you case running?

i'm pondering on what BC to use for pressure on the waterinlet/outlet.

hope thing goes well and thank you for your advice!

Erik

[zhoubinwx]

Dear all,

It's great to see your discussions.

I have tested the motorBike case, and I have some idea about it. Now I'd like to implement my simple case: uniform around a cylinder(2D case).

1. I use blockMesh to generate coarse mesh for a domain(4000*2000*1 micrometer), i.e. x: -2000~2000, y:0~2000, z:0~1; Uniform mesh along x-, y- direction. X-direction has 200 cells, y- has 100 cells, and z- has 1 cell; (This means the coarse mesh size is 20 micrometer)

2. I use Gmsh to build the STL format. Now I have 2 questions:
a. Since we need the surface information about the cylinder(object), should I output STL file after I generate 2D mesh or 3D mesh?
b. After Gmsh generates STL information, I could see that there are only "solid Created by Gmsh" and "endsolid Created by Gmsh", Can I define different patch names for the cylinder(front, back, cylinder_surface, and cylinder_axis)?

3. As we could see from: http://www.opencfd.co.uk/openfoam/do...#x26-1480005.4, in snappyHexMesh utility, there must be at least one intersection of a cell edge with the STL surface, i.e. a mesh of one cell will not work. Now my cylinder radius is 1 micrometer, so this means in order to use snappyHexMesh, I must use a background cell which is smaller than 1 micrometer?

Thank you for your attention.

Bin