[Yosmcer]

I am facing a problem when I try to merge some patches.
(I'm working with OpenFOAM 2.1.1 Updated to 2.2.0)

These patches appears because I try to have different mesh resolution.

• Simplified problem:

I simplified my mesh to have only the problematic part:



It will be solved as plane (unity thickness).

CDGF, DEHG and GHJI squares will be meshed with squares.

ABEC and EBKJ trapeze will be meshed with trapezes.

Points of the meshes will be strictly the same at the interfaces CE and EJ

Overall mesh will be better in the squares than in the trapezes.



The way I generated it can be found on LShaped1.zip attachment.

The -block option gives:

paraFoam -block

The problem I have is that at the CE and EI interface, blockMesh generate a "defaultFaces" patch.

Removing the front and back faces, I would like to have this type of borders:



But the defaultFaces came and gives this:



This is really a problem because this inner face makes icoFoam having:

--> FOAM FATAL ERROR: 
Continuity error cannot be removed by adjusting the outflow.
Please check the velocity boundary conditions and/or run potentialFoam to initialise

I can remove one of the interface (CE or EI) with mergePatchPairs, but I cannot (until now) merge both (tested both at a time and one after the other).

This problem seams related to this thread (but they are using stitchMesh):
http://StitchMesh on two patches
And masb seams to have also a problem of internal patches that are not removed here:
Internal faces between blocks

• What I already tried:

1. Replacing the defaultFaces with a slave and a master patch, than merge them.
   
   If I define a slaveJunction that contain the faces CD, DE EH and HJ, and a masterJunction that contain the faces CE and EI, these two patches are identical to the defaultFaces patches automatically created before (than, this defaultFaces is not any more automatically created, so I'm rid of it, but have two new patches instead).
   
   If I than try to merge them (with mergePatchPairs at the end of the blockMeshDict, but I also tried with stitchMesh in command line), I have 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

   The code related to this test can be found in the LShaped2.zip attached.
   
   This solution work if the different patches to be merged with the master have no common points (they have common points with the master, but not between them), as seen here:
   mergePatchPairs master with few slaves
   Or even if they have common points but aligned (I tested).
2. Make two slave and two master, then merge them two by two.
   
   Instead of defining L shaped patches, I tried to define two horizontals one (one with CD and DE, the other with CE), and two verticals one (EH + HI and EI), than merging them two by two (horizontals together, and verticals together).
   
   The 4 patches are, like in the previous case, taking exactly the same place than the defaultFaces patch.
   
   When I try to merge these face 2 by two, I have this error:
   
   

   --> FOAM FATAL ERROR: 
   Face 795 reduced to less than 3 points.  Topological/cutting error B.
   Old face: 2(440 465) new face: 2(76 153)

   But If I try to merge only the horizontals one, or only the verticals ones, I works perfectly, and these patches disappear.
   
   (example when merging the two verticals faces)
   
   
   This case can be found in LShaped3.zip attachment.
3. Deleting the defaultFaces patch (that I do not want) from the boundary file after blockMesh generation.
   
   Do not work as InternalMesh remain the same.

Do not hesitate to send me private message to correct my English.

[Yosmcer]

Maybe a solution could be to change the way to generate the mesh.
Instead of making the square meshed part out of three squares, an idea could be to have a bigger square that include the empty, than removing this space.

So that would make the problematic faces "face matching" instead of "defaultFaces".


However, I'm not sure how to define the necessary in the blockMeshDict.
topoSet seams to be the way to remove the space that I do not want (but I have to define the blockMeshDict before).


Can someone guide me in this path?

[Yosmcer]

Deeper try to remove this ******* defaultFaces patch. After having ran blockMesh, all in the polyMesh directory:
1) I open "boundary" file.
2) I note the start face and the number of faces.
3) I go to "face" file.
4) I delete the faces going from "startFace" to "startFace+nFaces" (the last faces of the list in my case)
5) I change the number at the beginning of the list to remove the nFaces I have just deleted.
6) I go to "owner" file and repet step 4 and 5.
7) I come back to "boundary" file to delete defaultFaces entry, and decrement de number of boundary at the beginning of the list.


But I still do not get it (I will look in the side of "neighbour" file as I didn't change it, and that the new problem is between neighbour cells):
ould

Neighbour cells are related to internal faces.
Maybe I should not delete this faces, but add neighbour informations (and still deleting the defaultFaces patch from boundary).

I found more informations about neighbours here: owner and neighbor
So they are listed by faces, in the idea that each face have an owner cell and a neighbour cell.

As there are less faces in "neighbour" file than in "owner" file, I suppose blockMesh put all the internal faces first in the "owner" file, so that it has only to put the internal faces values in the "neighbour" file (and nothing instead of the previously -1 for the externals faces).


So, new idea:

1) I open "boundary" file.
2) I note the start face and the number of faces.
3) I note the number of internal faces (I can find it in the neighbour file) lets name it NInternalFaces.
4) I go to "face" file.
5) I copy the faces going from "startFace" to "startFace+nFaces" (the last faces of the list in my case)
6) I paste them after the NInternalFaces'th faces.
7) I go to "owner" file and repet step 5 and 6.
8) I come back to "boundary" file to delete defaultFaces entry, and decrement de number of boundary at the beginning of the list.
9) Adding the number nFaces to the startFaces numbers of the other boundary patches (their start face have been changed as we changed the order of faces)
10) Adding the neighbour needed by the internal faces I want to create (but how ?)

So, now, I'm searching how I could manage to make point 10, adding the neighbour informations.

(I wonder if it wouldn't be simpler to write a code that directly generate the needed mesh as my problem is only a 2D case).

[wyldckat]

Hi Yosmcer,

I got a bit lost in your description... even more because of the ABC nomenclature vs OpenFOAM's numeric one.

Nonetheless, my questions and respective solutions:

1. Do you want to use blockMesh's "face matching" feature?
   • If so, it's sort-of simple: when defining the trapezoids, you must include the intermediate points D and H. This has to be done in both hex blocks (you'll need 4 trapezoids) and in the patches.
2. Do you want to use the "face merging" feature?
   • If so... then you have to use stitchMesh instead. The merge patches feature seems to only work in certain specific situations and this one isn't one of them.
   • Fortunately I have had some experience on this from this post: http://www.cfd-online.com/Forums/ope...tml#post411108 post #4
   • Attached is a working case, based on the L3 one you posted. The following changes are worthy on notice:
     • In blockMeshDict I added local variable definitions, to make it easier to correlate between the original image you had with letters, versus the numbers that blockMesh needed.
     • Still in blockMeshDict, I ended up merging the two slaves and the the two masters, into a single slave and master, for easier reference by stitchMesh.
     • I added the Allrun and Allclean scripts for convenience, which are based on OpenFOAM's tutorial scripts. You can run them like this:
       

       ./Allclean
       ./Allrun

     • The first major trick is to use stitchMesh with the "-perfect" option:
       

       stitchMesh -perfect -overwrite masterJunction slaveJunction

     • The second trick, for getting rid of the now defunct temporary patches, is to use createPatch with a semi-empty dictionary file "system/createPatchDict", which is present in the attached file

Well, this was a nice exercise for the mind Have fun!

Best regards,
Bruno

[Yosmcer]

Hello wyldckat,

A big thanks to all your work.

Sorry for that ABC... I wanted to make it simple to clarify, but it seems that made the opposite. I learned a bit too late about the "paraFoam -block".

1. This is in deed a possibility. That's where we can feel solution can be too simple to think about it. It require more points and hex to define in blockMesh, but it does what I want.
2. I tried to use it.
   It seems you managed to succeed with stitchMesh where I failed (I also tryed with stitchMesh).
   I'll compare to my case 2 to find what makes the difference. Maybe a wrong oriented normal.
   Thanks for the createPatchDict trick, I didn't found it during my researches (this is my firt OpenFOAM project).

The mesh you created look exactly like I want it.


Now, I will try to understand (so don't do it ):

• what is the difference that make stichMesh working with you (I downloaded your modifications and it run well).
  => First, I didn't divide the mesh in two zones, once done, I saw that stitchMesh need an entry in the U and p's files, so I've just added it.
  The next error was about patch type. I previously set the patch type to the slave and master patches, I replaced it by empty.
  That changed, the stitchMesh command run successfully.
• why it add some boundaries about the deleted slave and master in the p, U and newly created meshPhi.
  => It seems that this boundaries conditions are needed by stichMesh, and it is this same command that create the meshPhi file.
• why icoFoam still show me the same continuity error.

Again, a big thanks for your response, even bigger because it is not your predilection domain (running CFD cases).

[Yosmcer]

Finally, I simply made more blocks to allow face matching.
With this method, I have no more continuity errors, and when done with a m4 macro, this is not so difficult, even for the more complex mesh.

I attached the result of the more complex case I done and the m4 macro I used to generate the willing blockMesDict file (I putted the .m4 in a .zip file as the forum system do not accept.m4 files; just decompress the file to have it).
At the center, there is an empty square (no fluid) surrounded by walls, this square is included in an fluid square with square-shaped mesh, and finally included in a round fluid part. My problem was to have no interface between the fluid square and the round part. Inlet and outlet are in the external perimeter.
Hope it may help other peoples.

Thanks to the moderator that renamed the title of my post, I mistyped "ege" instead of "edge".

Thanks again for all those who tried to help, especially wyldckat.

[arnau1985]

Hi Yosmcer,

I think I managed to solve the problem you report in "What I already tried", section 2. I mean the part where you get the following error message:

--> FOAM FATAL ERROR:  Face 795 reduced to less than 3 points.  Topological/cutting error B. Old face: 2(440 465) new face: 2(76 153)

Try to run stitchMeshes with the "-perfect" option. For further explanation, check this other thread out:

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

Good luck!


Arnau.

[atoof]

Originally Posted by wyldckat

Hi Yosmcer,

I got a bit lost in your description... even more because of the ABC nomenclature vs OpenFOAM's numeric one.

Nonetheless, my questions and respective solutions:

1. Do you want to use blockMesh's "face matching" feature?
   • If so, it's sort-of simple: when defining the trapezoids, you must include the intermediate points D and H. This has to be done in both hex blocks (you'll need 4 trapezoids) and in the patches.
2. Do you want to use the "face merging" feature?
   • If so... then you have to use stitchMesh instead. The merge patches feature seems to only work in certain specific situations and this one isn't one of them.
   • Fortunately I have had some experience on this from this post: http://www.cfd-online.com/Forums/ope...tml#post411108 post #4
   • Attached is a working case, based on the L3 one you posted. The following changes are worthy on notice:
     • In blockMeshDict I added local variable definitions, to make it easier to correlate between the original image you had with letters, versus the numbers that blockMesh needed.
     • Still in blockMeshDict, I ended up merging the two slaves and the the two masters, into a single slave and master, for easier reference by stitchMesh.
     • I added the Allrun and Allclean scripts for convenience, which are based on OpenFOAM's tutorial scripts. You can run them like this:
       

       ./Allclean
       ./Allrun

     • The first major trick is to use stitchMesh with the "-perfect" option:
       

       stitchMesh -perfect -overwrite masterJunction slaveJunction

     • The second trick, for getting rid of the now defunct temporary patches, is to use createPatch with a semi-empty dictionary file "system/createPatchDict", which is present in the attached file

Well, this was a nice exercise for the mind Have fun!

Best regards,
Bruno

Dear Bruno,

That post was very useful for me. But I have a question. If we have different mesh distribution in each patch, how can we merge them together? For example, I've made 4 blocks that have interfaces by each other (please find the blockMeshDict in the attachment). I want to merge the patches in the interfaces by using mergePatchPairs , but I encounter to the following error:

Zero length edge detected.  Probable projection error: slave patch probably does not project onto master.

and when I use stitchMesh to stitch each interface, I get the following error:

Points on patch sides do not match to within tolerance 1.17982e-07

    From function perfectInterface::setRefinement(polyTopoChange& ref) const
    in file perfectInterface/perfectInterface.C at line 220.

I've attached the blocks and the mesh resolution in each block, too.

Thank you in advance,

Hossein
Domain.zip

blocks.png

[atoof]

[QUOTE=atoof;519293]Dear Bruno,

That post was very useful for me. But I have a question. If we have different mesh distribution in each patch, how can we merge them together? For example, I've made 4 blocks that have interfaces by each other (please find the blockMeshDict in the attachment). I want to merge the patches in the interfaces by using mergePatchPairs , but I encounter to the following error:

Zero length edge detected.  Probable projection error: slave patch probably does not project onto master.

and when I use stitchMesh to stitch each interface, I get the following error:

Points on patch sides do not match to within tolerance 1.17982e-07

    From function perfectInterface::setRefinement(polyTopoChange& ref) const
    in file perfectInterface/perfectInterface.C at line 220.

I've attached the blocks and the mesh resolution in each block, too.

Thank you in advance,

Hossein

[atoof]

I think that when patchA is merged to patchB and patchD is merged to patchC, the name of each vertex is changed and therefore the third mergepair is not allowed.

Solving above problem is very for me. Any hint is very welcome.

[atoof]

Any hint or suggestion?

[wyldckat]

Greetings atoof,

Originally Posted by atoof

Any hint or suggestion?

Hints:

1. Posts with information and new findings would have been enough. Trying to bump the thread up isn't very welcome on these forums, as indicated on the forum rules: http://www.cfd-online.com/Forums/misc.php?do=showrules - see rule #8
2. Make the tolerance even smaller for using stitchMesh. I can't remember how it's done in stitchMesh
   Try using "-help".

Suggestions:

1. Do not use this kind of mesh. Transferring mass flow from 5-10 cells to a single cell will cause serious non-physical flow disturbances. See "Case two" on this blog post of mine to see what I mean: OpenFOAM: Interesting cases of bad meshes and bad initial conditions
2. Use refineMesh or refineHexMesh (I can't remember which one is which) to increase the resolution locally where you need it. In other words, have a coarser mesh on those blocks and then refine later one where you need to refine. And try to make it gradual changes between each refinement level.

Best regards,
Bruno