[Eloise]

Hello,

I'm trying to stitch different meshes together. Here is what I found:
- internal mesh is a cylinder: no problem.
- internal mesh is a block: not possible (see here).
- internal mesh is a sphere: not possible (I did not succeeded).

Am I right? Or did one of you managed to stitch a block or a sphere inside another mesh?

Thanks for your feedback!
Eloïse

[wyldckat]

Greetings Eloïse,

I can only guess that it really depends on the meshes you've got to be stitched! Can you share simple case examples of what you're trying to do?

Best regards,
Bruno

[Eloise]

Hello Bruno,

Here are some test cases:
1) for a Cylinder: run .\Allrun_Cylinder. You can see that is works by looking at the log.checkMesh where the two internal patches have no faces.
2) for a Sphere: run .\Allrun_Sphere. The stitchMesh ends with an error.
3) for a Block: no test case, but I'd suggest to simply replace the sphere by a box in the Sphere test case.

Thanks for your interest in this case
Eloïse

[wyldckat]

Hi Eloïse,

These are awesome test cases !
But you forgot to mention that for the box and the sphere you were using snappyHexMesh!
And it's easily solved! The missing magic step if this after mergeMeshes:

rm 0/cc* 0/*Level

Those files are generated by snappyHexMesh for future reference, in case you want to do some advanced mesh manipulation and diagnosing.

In addition, you can use the "-overwrite" option in mergeMeshes as well (I'm using OpenFOAM 2.1.x and I haven't checked with 2.1.1):

#!/bin/sh
# Source tutorial run functions
. $WM_PROJECT_DIR/bin/tools/CleanFunctions
. $WM_PROJECT_DIR/bin/tools/RunFunctions
                          
cd IntDom_Sphere/
cleanCase
runApplication blockMesh  
runApplication snappyHexMesh -overwrite 

cd ../ExtDom_Sphere/
cleanCase
runApplication blockMesh 
runApplication snappyHexMesh -overwrite 
runApplication mergeMeshes -overwrite . ../IntDom_Sphere/  
rm 0/cc* 0/*Level
runApplication stitchMesh -partial -toleranceDict toleranceDict -overwrite sphere_ext_region0 sphere_int_region0

Best regards,
Bruno

[Eloise]

Hi Bruno,

Thanks for your fast answer! The sphere is indeed created with snappyHexMesh and this additional line solves it all . I haven't had time yet to work on the sphere creation in blockMesh, it will probably come soon.

It is already very good news that the stitching can work with spherical and cubic internal meshes when using snappyHexMesh!

I'm actually working with 2.0.x, so the -overwrite option is not available for mergeMeshes.

Regards,
Eloïse

[cutter]

Hi,

thanks for your test cases. I've tried them with OF 2.2.x, they're working without any problems.

Did you make any progress with the block case?! Occasionally I have similar problems that could only be resolved by preparing the whole mesh in an external tool. I therefore modified your Cylinder test case to create a Cube case by removing the arcs within the blockMesh files (see below). This causes stitchMesh to fail with the following error:

--> FOAM FATAL ERROR: 
Zero length edge detected.  Probable projection error: slave patch probably does not project onto master.  Please switch on enriched patch debug for more info

    From function void enrichedPatch::calcCutFaces() const
    in file slidingInterface/enrichedPatch/enrichedPatchCutFaces.C at line 263.

This is really strange since the two patches should match even perfectly. Can this be resolved by modifying the toleranceDict? Maybe it's even worth a bug report...

The same error has also been observed in http://www.cfd-online.com/Forums/ope...o-patches.html and http://www.cfd-online.com/Forums/ope...-openfoam.html.

Cutter

[wyldckat]

Greetings Cutter,

It's simple! Instead of "-partial", use "-perfect".

Best regards,
Bruno

[cutter]

Hi,

ok, that's true for the trivial case when the discretization of master and slave patches match.

What's the right way to do it when I change the discretization of the internal block to say 25x25x30?

blocks
(                
        hex (0 1 3 2 4 5 7 6) (25 25 30) simpleGrading ( 1 1 1)   
);

This seems to cause problems with -perfect (of course), -partial and even without both of these options (the latter should be used in my understanding).

Thanks
Cutter

[wyldckat]

Hi Cutter,

Well, from what I've managed to figure out, what you're trying to do is to weld the mesh, not stitch the mesh

In this scenario, it's necessary to add points to the faces of cells on each side of the connecting patches, so that they can be stitched together afterwards. And after adding the points, it might be necessary to split the cells as well, so that they aren't of the polyhedral variety.

The only OpenFOAM utility that I'm aware of doing this is modifyMesh: http://openfoamwiki.net/index.php/ModifyMesh - but this utility is very far from being automated.

...

Well, I wrote the above and then went on to investigate this further. I found out something interesting, based on this post: http://www.cfd-online.com/Forums/ope...tml#post183551 - post #15
So basically I had to split up the patches on both sides, so that the stitching would happen on a one-to-one basis.
Problem is that after stitching once, it breaks something and we have to rely on mesh conversion to/from Fluent format, because apparently something gets fixed in between the two. Then we can stitch another pair.

This can get pretty boring to do manually, so I'm going to keep investigating this, since it's an interesting topic .

______
edit: Nope, two of the patch pairs it can handle just fine, but the other two give this kind of error:

Face 196625 reduced to less than 3 points.  Topological/cutting error B.
Old face: 2(3066 2625) new face: 2(3066 2625)

______

Best regards,
Bruno

[wyldckat]

Hi Cutter,

First note: I created a variant of stitchMesh that allows stitching up several patches in a single run, by relying on a dictionary file to specify which patches should be stitched together and how they should be stitched: https://github.com/wyldckat/stitchMeshMultiPatch

Problem is... that this did not solve the problem

So here's what I've found out so far:

1. There is no need to rely on mesh conversion to/from Fluent format for using stitchMesh various consecutive times, it's just a matter of removing these files/folders:
   

   constant/polyMesh/meshModifiers
   
   #I'm not 100% certain about this one
   0
   
   #these are not usually necessary to be removed, but just in case
   constant/polyMesh/*Zones

2. I've used autoPatch for splitting up all surfaces into individual patches, instead of having a single patch on each side of the interface. Problem is that 2 opposite patch-pairs can be stitched, but then the other 2 cannot be stitched. For example: the North and South patch pairs can be stitched, but then the East and West patches cannot, giving the error:

   Face * reduced to less than 3 points.  Topological/cutting error B.

   as I mentioned in the previous post.
3. Attached is the modified case I'm talking about. After running Allrun_Cube, check the contents of the file "ExtDom_Cube/log.stitchMeshMultiPatch". Note: it relies on "stitchMeshMultiPatch" I mentioned above, but you can edit the script Allrun_Cube and use the normal stitchMesh instead.
4. The reason for this problem seems to be because stitchMesh (or more specifically, "perfectInterface/slidingInterface") was not designed for these kinds of "floating" interfaces, as shown in the attached image. The problem are the faces at the ends of these patches, over the Y axis. Since they are "floating", the algorithm apparently believes that these stitched faces would collapse onto themselves.
   This is probably the problem that originally was triggered when only 2 4-sided patches are used and for which the previous message is:
   

   Zero length edge detected.  Probable projection error: slave patch probably does not project onto master.  Please switch on enriched patch debug for more info

The next step would be either to:

• Report this on the bug tracker: http://www.openfoam.org/bugs/
• Or to look into the source code in "enrichedPatch.C", in an attempt to figure out how this might be solved.

Another test can could be performed would be to stitch not just 2 meshes, but 5 meshes:

1. the internal mesh + the one on the north;
2. then + the other on the south;
3. then + one on the east;
4. then + the last one on the west.

In other words, to slice up the meshes even more and stitching together in a way that the problem we're having would not occur, since the interfacing patch would always be next to 2 other patches.


This is an interesting problem, but this is as far as I can figure out for the next few weeks/months. Feel free to report this on the bug tracker, since you're more interested in this than me!

Best regards,
Bruno

[arnau1985]

Hi wyldckat,

I had this very same problem:

Face * reduced to less than 3 points.  Topological/cutting error B.

Check this thread out, I think I managed to solve it:

http://www.cfd-online.com/Forums/ope...tml#post435852

Good luck!


Arnau.

[wyldckat]

Greetings Arnau,

Nope, "-perfect" only works in some cases... if you take a look at post #7, that was my initial conclusion, which only worked for the intially presented case from post #6. But it doesn't work for the indication given in post #8.

Best regards,
Bruno

[JulytoNovember]

Does stitchMesh only work with flat surfaces? Or can you stitch 2 symmetrically curved surfaces together?

[cutter]

Hi, please have a look at the cylinder case in post #1.

[marcus85]

Hi together,

i want to stitch my mesh, but the problem is, that there are 2 different regions defined after mergeMeshing. Now i've the Problem that i can't solve the case with rhoSimpleFoam.
And there are also the Problem with my boundary conditions for my mesh in the boundary file...I need urgent help, because i've only 2 Months till i must deliver my master thesis.

Please help!

Here are my logfile for using stitchMesh in partial and perfect mode.
And a screenshot of my 2 Mesh Regions, which are already merged.

Thx all for your supply.

kind regards

Marcus

 Build  : 2.0.x-0751ac349341
Exec   : stitchMesh -case ./MergeMeshes/ -partial inlet_inlet_prt outlet_outlet_prt
Date   : Jul 24 2013
Time   : 16:34:52
Host   : cpi02968.c166.c.iav.de
PID    : 28859
Case   : ./MergeMeshes
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations


Create time

Create mesh for time = 4

Coupling partially overlapping patches inlet_inlet_prt and outlet_outlet_prt
Resulting internal faces will be in faceZone inlet_inlet_prtoutlet_outlet_prtCutFaceZone
Any uncovered faces will remain in their patch
Adding pointZone inlet_inlet_prtoutlet_outlet_prtCutPointZone at index 0
Adding faceZone inlet_inlet_prtoutlet_outlet_prtMasterZone at index 0
Adding faceZone inlet_inlet_prtoutlet_outlet_prtSlaveZone at index 1
Adding faceZone inlet_inlet_prtoutlet_outlet_prtCutFaceZone 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
Reading all current volfields


--> FOAM FATAL ERROR: 
Problem : Patch inlet_inlet_prt starts at 8008784
Current face counter at 17426001
Are patches in incremental order?

    From function polyTopoChange::polyTopoChange(const polyMesh& mesh, const bool strict)
    in file polyTopoChange/polyTopoChange/polyTopoChange.C at line 2442.

FOAM aborting

#0  Foam::error:rintStack(Foam::Ostream&) in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libOpenFOAM.so"
#1  Foam::error::abort() in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libOpenFOAM.so"
#2  Foam::polyTopoChange::addMesh(Foam::polyMesh const&, Foam::List<int> const&, Foam::List<int> const&, Foam::List<int> const&, Foam::List<int> const&) in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libdynamicMesh.so"
#3  Foam::polyTopoChange::polyTopoChange(Foam::polyMesh const&, bool) in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libdynamicMesh.so"
#4  Foam::polyTopoChanger::topoChangeRequest() const in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libdynamicMesh.so"
#5  Foam::polyTopoChanger::changeMesh(bool, bool, bool, bool) in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libdynamicMesh.so"
#6  main in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/bin/stitchMesh"
#7  __libc_start_main in "/lib64/libc.so.6"
#8  Foam::UOPstream::write(char) in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/bin/stitchMesh"

/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.0.x                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : 2.0.x-0751ac349341
Exec   : stitchMesh -case ./MergeMeshes/ -perfect inlet_inlet_prt outlet_outlet_prt
Date   : Jul 24 2013
Time   : 16:39:18
Host   : cpi02968.c166.c.iav.de
PID    : 28885
Case   : ./MergeMeshes
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 4

Coupling perfectly aligned patches inlet_inlet_prt and outlet_outlet_prt
Resulting (internal) faces will be in faceZone inlet_inlet_prtoutlet_outlet_prtCutFaceZone

Note: both patches need to align perfectly.
Both the vertex positions and the face centres need to align to within
a tolerance given by the minimum edge length on the patch
Adding faceZone inlet_inlet_prtoutlet_outlet_prtCutFaceZone at index 0
Reading all current volfields


--> FOAM FATAL ERROR: 
Problem : Patch inlet_inlet_prt starts at 8008784
Current face counter at 17426001
Are patches in incremental order?

    From function polyTopoChange::polyTopoChange(const polyMesh& mesh, const bool strict)
    in file polyTopoChange/polyTopoChange/polyTopoChange.C at line 2442.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libOpenFOAM.so"
#1  Foam::error::abort() in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libOpenFOAM.so"
#2  Foam::polyTopoChange::addMesh(Foam::polyMesh const&, Foam::List<int> const&, Foam::List<int> const&, Foam::List<int> const&, Foam::List<int> const&) in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libdynamicMesh.so"
#3  Foam::polyTopoChange::polyTopoChange(Foam::polyMesh const&, bool) in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libdynamicMesh.so"
#4  Foam::polyTopoChanger::topoChangeRequest() const in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libdynamicMesh.so"
#5  Foam::polyTopoChanger::changeMesh(bool, bool, bool, bool) in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libdynamicMesh.so"
#6  main in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/bin/stitchMesh"
#7  __libc_start_main in "/lib64/libc.so.6"
#8  Foam::UOPstream::write(char) in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/bin/stitchMesh"

[marcus85]

Or can i use another tool or function of Openfoam, that can solve this problem?

[Eloise]

Hi,

I keep working on the sphere case. During the stitchMesh process, non orthogonal faces are created at the interface between the two meshes and they have a negative impact on the simulation. Does anyone knows how to avoid them?

Regards,
Eloïse

[wyldckat]

Greetings to all!

@Marcus:

Originally Posted by marcus85

Or can i use another tool or function of Openfoam, that can solve this problem?

I've been very busy for the past few weeks, so according to your other post, you probably have less than 1 month + 1 week
Either way, the problem with your case is that the mesh seems to be badly damaged on the lower part, which leads the 2 patches to not being in full contact, which is likely why you are getting those error messages.

If you had a very simple and small example of your case that gives the same error, it would be the best. Otherwise, only by seeing the case for myself.



@Eloïse:

Originally Posted by Eloise

I keep working on the sphere case. During the stitchMesh process, non orthogonal faces are created at the interface between the two meshes and they have a negative impact on the simulation. Does anyone knows how to avoid them?

A few questions:

1. Which solver did you use?
2. Why do you need the interface?

Best regards,
Bruno

[Eloise]

Originally Posted by wyldckat

1. Which solver did you use?
2. Why do you need the interface?

Hi Bruno,

My case is actually the following: I measure the lift and drag on an object placed in a steady uniform flow for several hundreds orientations. Before, I was re-meshing the object for each flow orientation. What I'd like to do is to have the object meshed in a sphere, so that I just need to rotate the sphere and merge it to the outer mesh to get the appropriate flow orientation. It saves a lot of time!

2. I actually don't need an interface. Once the meshes are merged, there shouldn't be any influence from the interface on the flow.

1. I use simpleFoam. I compared results obtained with the previous meshing approach (which I use as reference) and the merging approach and I get some differences in lift and drag. I'm actually not sure what the differences are due to:

• is it due to non-orthogonal faces created at the interface between the two meshes? (see figure)
• is it due to the fact that, once the sphere is rotated, the cells are no longer aligned with the flow?
• is it due to the distance of the sphere to the object?

I have tested several background mesh orientations (see figures) and several sphere diameters in order to check the 2nd and 3rd points but I haven't reached any conclusion yet: there is no specific trend, the results seem just randomly spread around the reference value.

If you have any recommendations for this kind of case, they are welcome

Regards,
Eloïse

[wyldckat]

Hi Eloïse,

Nice! Although keep in mind that the quality of the mesh on the interface might interfere with the results, no matter how good it is.

Nonetheless, your description seems to be what I was hoping for, namely that you can use "cyclicAMI" patches, without the need for stitching!
Have a look at this post: http://www.cfd-online.com/Forums/ope...tml#post446517 post #184

The idea is that for using "cyclicAMI" patches, you don't need a solver that has dynamic mesh capabilities.
You only need dynamic mesh capabilities if you wanted to change the angle orientation during the simulation.
But since you don't want to, you can even use moveDynamicMesh for only moving the mesh between each run! My advice is to move only one iteration, based on the time 0; but you might even want to try and use the fields from the previous run to start them for the next simulation, as long as the angle change is small.

Although, I think using transformPoints with the option "-region" might be easier than using moveDynamicMesh.

Best regards,
Bruno