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/)
-   -   Patch Names in STL file for snappyHexMesh (http://www.cfd-online.com/Forums/openfoam-meshing-snappyhexmesh/84654-patch-names-stl-file-snappyhexmesh.html)

Kattie February 4, 2011 14:24

Patch Names in STL file for snappyHexMesh
 
1 Attachment(s)
Good Day Everyone,

I'm trying my first hand at snappyHexMesh, using a simple cylinder inside a rectangular prism domain. The cylinder is an stl file output from HyperMesh. I've named the component in HyperMesh, but that does not seem to show up in the STL file.

My problem arises when I attempt to run snappyHexMesh using this STL file. When it is to add layers to the geometry it writes out:

No layers to generate ...
Layer mesh : cells(local):720 faces(local):2436 points(local):1029
Cells per refinement level:
0 720
Writing mesh to time 14
Written mesh in = 0.01 s.
Layers added in = 0.02 s.
Finished meshing in = 0.19 s.
End


A patch is added during the process of meshing, as far as I can tell:

Adding patches for surface regions
----------------------------------

Patch Region
----- ------
cylinder:

5 cylinder_part

Added patches in = 0 s



I am using OpenFOAM 1.7.1. I think that I have the correct patch names, but is there a function within OpenFOAM to tell you the names of all the included patches? This would be particularly useful for those contained in the STL file.

My best guess is that I have the incorrect patch name in my snappyHexMeshDict file, but could there be another reason for snappyHexMesh not producing a mesh?

I've attached my snappyHexMeshDict file for reference.

Any ideas or suggestions would be much appreciated.

Kattie

Tobi February 5, 2011 07:50

Hi Kattie,

in your STL File you have to name your boundary's. I am working with Catia and have to generate the boundary's with Salome. Here an example:

Catia STL
Code:

CATIASTL solid
 facet normal -6.087614e-01  7.933533e-01  0.000000e+00
  outer loop
    vertex  3.974695e-03  2.625305e-03  6.000000e-02
    vertex  4.275000e-03  2.855737e-03  6.000000e-02
    vertex  4.275000e-03  2.855737e-03  0.000000e+00
  endloop
 endfacet
.
.
.
ENDSOLID

Without other boundary's. If you want more you have to generate them with SALOME.

In this example you got the whole STL Surface with just one boundary called "solid" if you don 't know how the boundary is called do the follow:

this name you have to use in your sHMD :)
after Meshing you have to make a Slice in paraFoam to make that visible.

Hope it 's helpful
Tobi

Kattie February 7, 2011 09:04

Hi Tobi,

Thanks for the reply.

I tried to name the patch "solid" as you suggested in my sHMD, but even then it wouldn't construct any layers. My STL file is just one part (a cylinder) as well, so it should only be one part (or patch).

My STL file starts as:

solid part
facet normal 0.0 0.0 1.0
outer loop
vertex -6.132972E-03 -5.692454E-03 0.000000E+00
vertex -8.145442E-03 -5.839178E-03 0.000000E+00
vertex -6.511647E-03 -7.611832E-03 0.000000E+00
endloop
endfacet


Any ideas on how the naming should be reproduced in sHMDict would be welcome.

Thanks in advance,
Kattie

Tobi February 7, 2011 14:25

Quote:

Originally Posted by Kattie (Post 293965)
Hi Tobi,

Thanks for the reply.

I tried to name the patch "solid" as you suggested in my sHMD, but even then it wouldn't construct any layers. My STL file is just one part (a cylinder) as well, so it should only be one part (or patch).

My STL file starts as:

solid part
facet normal 0.0 0.0 1.0
outer loop
vertex -6.132972E-03 -5.692454E-03 0.000000E+00
vertex -8.145442E-03 -5.839178E-03 0.000000E+00
vertex -6.511647E-03 -7.611832E-03 0.000000E+00
endloop
endfacet


Any ideas on how the naming should be reproduced in sHMDict would be welcome.

Thanks in advance,
Kattie

Your name is "part" :)
I ll make a sHM + STL file for you - there you 'll see it.

Kattie February 7, 2011 14:59

Hi Tobi,

That is very kind of you - thank you!

It seems very odd that the cylinder doesn't show up in my mesh, but perhaps with your example files I'll find out I've been naming a patch incorrectly.

Have a good evening,
Kattie

Tobi February 7, 2011 16:24

1 Attachment(s)
Hey Kattie,

here the files :)
hope it 's helpful.

Greetings Tobi

Kattie February 7, 2011 17:30

Hi Tobi,

Thank you so much. I've run your files and they work perfectly. I think it's also helped me to identify the root of my own error.

I am trying to simulate a cylinder within a rectangular prism of fluid, so I thought that the blockMesh would create the extents of the domain of fluid, and the cylinder would be a solid within that fluid volume. I'm now thinking that the volume domain must also be specified in the STL file to create the outer edges (inlet, outlet, etc.).

Kattie

Tobi February 7, 2011 17:47

Hey ...

no problem :)
maybe that would be very helpful

http://www.discretizer.org/node/21

check it out - i am working with that discretizer too - but just for generation of mesh.

Tobi

mfiandor October 12, 2011 18:35

1 Attachment(s)
Sorry guys, but i do have the same problem, instead of a cylinder i have an sphere that doesn't show up after executing 'snapHexMesh' and then 'paraFoam'.

I have checked names of the patches of my STL and of my sHMD, and they seem okey. I think is that my sphere has coordenates outside the boundaries, but I don't know how to check that.

I attach my stl and bMD and sHMD in case you can show me where is the error.

Thanks in advance!

Kattie October 13, 2011 12:07

Hi Miguel,

It would seem that your blockMesh has z-coordinates from 0 to 8, but your sphere STL contains negative z-coordinates.
My first suggestion would be to extend the bounds of your blockMesh to much further than they are now. Perhaps try z from -8 to +8 first, and to be even more careful, try y from -7 to +7 and x from from -10 to +15.
If you still don't see the sphere, double check that your locationInMesh point lies outside of the volume the sphere occupies.

Hope this helps,
Kattie

mfiandor October 15, 2011 12:41

It worked Kattie!, thanks a lot :)

Now I can see the little icosphere after sHMeshing in paraFoam. But since i didn't remember the solvers from the motorbike case (now I see it executes potentialFoam and simpleFoam). I ran ./Allrun script, and then paraFoam and the icosphere wasn't there!, it blew away hehehe.

Looking for the error there must be sth wrong in my sHMD, because actually in the output of the sHD i see 2 warnings, here ->

Code:

miguelfg@laptopubuntu:~/OpenFOAM/miguelfg-2.0.1/run/mis_casos/icosphere1_motorbike$ cat sHMout5.out | grep 'Warning' -A 3
--> FOAM Warning : Displacement (-0.0179286 0.0108571 -0.00502026) at mesh point 2403 coord (0.588107 -0.22063 0.00119238) points through the surrounding patch faces
Smoothing displacement ...
Displacement smoothed in = 0.01 s

--
--> FOAM Warning :
    From function layerParameters::layerParameters(..)
    in file autoHexMesh/autoHexMeshDriver/layerParameters/layerParameters.C at line 378
    Reading "/home/miguelfg/OpenFOAM/miguelfg-2.0.1/run/mis_casos/icosphere1_motorbike/system/snappyHexMeshDict::addLayersControls::layers" from line 218 to line 218

And in the new directories 0, 1, 2 and 3, there missing data comparing with the real motorbike case. Look, the 300 directory of motorbike case looks like:

Code:

miguelfg@laptopubuntu:~/OpenFOAM/miguelfg-2.0.1/run/mis_casos/icosphere1_motorbike$ ll ../../tutorials/incompressible/simpleFoam/motorBikeBACKUP/300/
total 13208
drwxr-xr-x  3 miguelfg miguelfg    4096 2011-10-15 14:23 ./
drwxr-xr-x 14 miguelfg miguelfg    4096 2011-10-15 14:23 ../
-rw-r--r--  1 miguelfg miguelfg 1331188 2011-10-15 14:23 k.gz
-rw-r--r--  1 miguelfg miguelfg 1416266 2011-10-15 14:23 nut.gz
-rw-r--r--  1 miguelfg miguelfg 1359652 2011-10-15 14:23 omega.gz
-rw-r--r--  1 miguelfg miguelfg 1280176 2011-10-15 14:23 p.gz
-rw-r--r--  1 miguelfg miguelfg 4201623 2011-10-15 14:23 phi.gz
-rw-r--r--  1 miguelfg miguelfg 3916712 2011-10-15 14:23 U.gz
drwxr-xr-x  2 miguelfg miguelfg    4096 2011-10-15 14:23 uniform/

Code:

miguelfg@laptopubuntu:~/OpenFOAM/miguelfg-2.0.1/run/mis_casos/icosphere1_motorbike$ ll 3/
total 20
drwxr-xr-x 3 miguelfg miguelfg 4096 2011-10-15 18:25 ./
drwxr-xr-x 8 miguelfg miguelfg 4096 2011-10-15 18:25 ../
-rw-r--r-- 1 miguelfg miguelfg  971 2011-10-15 18:25 cellLevel.gz
-rw-r--r-- 1 miguelfg miguelfg 1389 2011-10-15 18:25 pointLevel.gz
drwxr-xr-x 2 miguelfg miguelfg 4096 2011-10-15 18:25 polyMesh/

I am missing all the variables to be created, U, p, k nut, ...
And I tried running 'potentialFoam' instead ./Allrun , and it yells at me because it can find /3/p subdirectory.

(Maybe i should post this in a new one)

Toorop October 18, 2011 11:05

Hi All,

I created a dummy case for testing the naming convention in different file formats and fortunately OpenFOAM can process OBJ files with named faces. I would like to specify a layer where snappyHexMesh should add some prescribed number of layers. Everything works fine when I define a boundary from the blockMesh, but OpenFOAM gives an error with surfaces in sHM geometry list. Tested with OBJ and STL as well.

Code:

Wildcard layer specification for "objGeom_patchName" does not match any patch.
Valid patches are
12
(
...
objGeom_patchName
...
)

So it's listed, quite strange!

There's some information about the issue in the official documentation - 5.4.1 The mesh generation process of snappyHexMesh. I didn't specify any patch name but the result is the same with "objFile.obj_pathcName".


All times are GMT -4. The time now is 14:22.