[dhruv]

Hi Foamers,

I am having some problems with stitchMesh utility. May be could suggest me a correct or a better way.

I am having 5 different geometries, which are to be meshed independently, and then merged together. i generate these geometries in Salome 6.0 and then export it as .stl files to be meshed by sHM. Now, say that I have patch 1 in geometry 1 and patch 2 in geometry 2 which are to be merged and stitched. Since these must be identical patches, I have a single .stl file for both these patches, that I use it in both the geometries. After the sHM has been done, I find that they are not exactly the same, but there is an overlap. So, when i use stitchMesh (I have tried the -perfect flag, the -partial flag and without any flag and these are the results of stitchMesh without any flag, as the other two threw some errors), i do not get both nFaces for both as 0, but some faces are left in the patches. How can I avoid this situation?

I am attaching the figures below of the patches to be stitched and the mesh after it is stitched

[tomislav_maric]

Hi dhruv,

why don't you generate the meshes with shM, then use mergeMesh to merge them, and then stitch patches? I've described this for a very simple case here:

http://www.cfd-online.com/Forums/ope...hes-p-t-u.html

Let me know if this is of any help...

Best regards,
Tomislav

[dhruv]

Hi Tomislav,

I had checked your post earlier, and this is exactly what I did. I just made the geometry in Salome, and generate the mesh in Snappy. However, when I stitchMesh between the two patches, there are always some residual faces. Although, they are few in number, I guess it would not be correct to delete them altogether.

Originally Posted by tomislav_maric

Hi dhruv,

why don't you generate the meshes with shM, then use mergeMesh to merge them, and then stitch patches? I've described this for a very simple case here:

http://www.cfd-online.com/Forums/ope...hes-p-t-u.html

Let me know if this is of any help...

Best regards,
Tomislav

[Arnoldinho]

I haven't checked whether this has already been mentioned: You could have a look at stitchMeshToleranceDict, e.g. the one attached (remove the .txt), which has to be put in the constant folder and controls whether points on the boundary patch are moved for stitching.

Arne

[tomislav_maric]

Originally Posted by dhruv

Hi Tomislav,

I had checked your post earlier, and this is exactly what I did. I just made the geometry in Salome, and generate the mesh in Snappy. However, when I stitchMesh between the two patches, there are always some residual faces. Although, they are few in number, I guess it would not be correct to delete them altogether.

Hm....

have you tried the build compound mesh option in salome? This way you can merge the meshes before exporting them to .stl, and have multiple merged stl surfaces. If you do this, the internal overlapping patches should be gone (through the compounding) and shm can mesh the interior....

Check this out:

http://docs.salome-platform.org/salo...unds_page.html

The algorithm should allow for compounds without 3D algorithms, and even if it does not, if I remember correctly, exporting to .stl will only export the surface mesh anyway.

Tomislav

[dhruv]

Originally Posted by Arnoldinho

I haven't checked whether this has already been mentioned: You could have a look at stitchMeshToleranceDict, e.g. the one attached (remove the .txt), which has to be put in the constant folder and controls whether points on the boundary patch are moved for stitching.

Arne

Hello Arnoldinho,

Thanks for your reply. I did what you said, and placed the file in case/constant folder but it seems that the file is not being read by stitchMesh. I am attaching here the logfile for stitchMesh. I did not make any changes to your file. Do I have to provide any other changes to the file, to make it working (like case name, or the path, etc. ). Moreover, these values suggest that there is a default stitchToleranceDict file located somewhere. How can I find that?

Coupling patches geo_wallsfan and geo_wallsfan1
Resulting (internal) faces will be in faceZone geo_wallsfangeo_wallsfan1CutFaceZone

Note: the overall area covered by both patches should be identical ("integral" interface).
If this is not the case use the -partial option


Adding pointZone geo_wallsfangeo_wallsfan1CutPointZone at index 0
Adding faceZone geo_wallsfangeo_wallsfan1MasterZone at index 0
Adding faceZone geo_wallsfangeo_wallsfan1SlaveZone at index 1
Adding faceZone geo_wallsfangeo_wallsfan1CutFaceZone at index 2
Sliding interface parameters:
pointMergeTol : 0.05
edgeMergeTol : 0.01
nFacesPerSlaveEdge : 5
edgeFaceEscapeLimit : 10
integralAdjTol : 0.05
edgeMasterCatchFraction : 0.4
edgeCoPlanarTol : 0.8
edgeEndCutoffTol : 0.0001

Regards,
Dhruv

[Arnoldinho]

Hi Druv,

indeed, the command has an addition, e.g.

stitchMesh -overwrite -toleranceDict stitchMeshToleranceDict st ts

with "-overwrite" overwriting the current time step, "-toleranceDict stitchMeshToleranceDict" giving the command and name, "st ts" are the patches.
Also, you might need to make some adjustments in the dict to see some changes in your case.

Arne

[dhruv]

Hi Arnoldinho,

Thanks for the reply. I tried running my case with the new stitchMeshToleranceDict. However, the results are still bad. One of the patches gets stitched nicely (6 faces still remains as residual, but its better that 120 faces previously), however, the other one shows no effect. (190 and 200 faces as residual in the two patches). I tried a range of values for the different entries, but the effect is quite negligible in the second case. I am not able to understand, whether it is the problem due to Salome or OpenFoam. I tried to model my surface in a different way in Salome, however the results are pretty much the same. I am now confused how to proceed further

Originally Posted by Arnoldinho

Hi Druv,

indeed, the command has an addition, e.g.

with "-overwrite" overwriting the current time step, "-toleranceDict stitchMeshToleranceDict" giving the command and name, "st ts" are the patches.
Also, you might need to make some adjustments in the dict to see some changes in your case.

Arne

[Arnoldinho]

Hi dhruv,

when using stitchMesh, you have to make sure that all of your patches get stitched (number of faces on the previous patches must be zero in the boundary file), a reduced number does not help you. Otherwise the solver will crash somewhen. You also have to make sure that your patches have (exactly) the same dimensions in x, y and z.

I tried a very (very) long time using Salome meshes, also in combination with engrid meshes for the boundary layer. Even after mergeMeshes and stitchMesh have worked, the results were very bad! Therefore, I changed back to sHM, which really works nice! The new 2.0 version seems to have edge mapping now, so it might be worth trying it!

Arne

[dhruv]

Hi Arne,

The problem is that I am using a mesh which has been generated in sHM using the edge feature of OF 2.0. I create only the geometry in Salome. Then, i export it as .stl in OF, and mesh it with sHM. Everything is exact till I do the meshing. After the meshing, the two adjacent faces (which are to be merged and stitched together), which have even the same .stl file for two cases, doesn't come out exactly the same.

Originally Posted by Arnoldinho

Hi dhruv,

when using stitchMesh, you have to make sure that all of your patches get stitched (number of faces on the previous patches must be zero in the boundary file), a reduced number does not help you. Otherwise the solver will crash somewhen. You also have to make sure that your patches have (exactly) the same dimensions in x, y and z.

I tried a very (very) long time using Salome meshes, also in combination with engrid meshes for the boundary layer. Even after mergeMeshes and stitchMesh have worked, the results were very bad! Therefore, I changed back to sHM, which really works nice! The new 2.0 version seems to have edge mapping now, so it might be worth trying it!

Arne

[Arnoldinho]

Sorry, but then I don't get what you are doing... Using sHM and an .stl file e.g. to 'cut out' things from a surrounding mesh, creates only one mesh. Where are the others coming from? Can you upload a case including the meshes that you want to merge?

Arne

[dhruv]

Hi Arne,

sorry for the late reply. I got all things in order, after modifying the stitchMeshToleranceDict several times. Thanks for the advice. I am however concerned that I had to do a lot of manipulations, for a relatively simple geometry, and one set of conditions were not enough to do the stitch for different faces.

Regards,

dhruv.

Originally Posted by Arnoldinho

Sorry, but then I don't get what you are doing... Using sHM and an .stl file e.g. to 'cut out' things from a surrounding mesh, creates only one mesh. Where are the others coming from? Can you upload a case including the meshes that you want to merge?

Arne

[tomislav_maric]

Hi,

I'm curious, why don't you use the compound mesh in Salome, since you are already using it to generate STLs for the shm, and feed the compounded stl surface to shm thus avoiding having to stitch the patches in the first place?

T.

[tanzil]

Hello,

I also have a problem with stitchMesh and it could be related to this thread. Im working about flow simulation on a Tunnel and making my mesh purely with OF. Since i have a large number of cells, i managed to split the calculation area in two parts. The big box contains purely of hexaedra and will be generated with blockMesh. The small box located in the middle of the big box and contains the Object, that completely meshed with snappyHexMesh (exclusive the layer). Merging both boxes works well and stitching the patches at time directories 0 and time step 1 are fine. Issue is im not able to stitch patches with my latest meshtime directory. The geometry dimensions are identic and i've tried all flags from stitchMesh. Two different Errors occurs depend on the flag and they are:

- Zero length edge detected. Probable projection error: slave patch probably
does not project onto master.
- Points on patch sides do not match to within tolerance 2.561e-06 (this one
with -perfect)

I've played around with the toleranceDict but also without success. Indeed i found out in paraview that my slavepatch deviate from my masterpatch line when i enough zoom in. As you can see in the picture, the red line display the slavepatch, while the white one the masterpatch.

I dont understand why stitchMesh works fine before snapping procedure or why this small different line appear after snapping stage? Have anyone encounter such problem? Any reply is welcome