CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Meshing & Mesh Conversion (http://www.cfd-online.com/Forums/openfoam-meshing/)
-   -   Remove internal patch(es) (http://www.cfd-online.com/Forums/openfoam-meshing/84063-remove-internal-patch-es.html)

SD@TUB January 19, 2011 08:42

Remove internal patch(es)
 
Dear FOAMers,

after searching the whole morning for an appropriate way to delete internal patches within this forum, i've decided to open a new thread according to this!
After chaining several grids together via mergeMeshes w/o stitchMesh, the associated interfaces will be left in the polyMesh description (e.g. boundary file). What would be the smartest procedure to remove them (just deleting the patches in the ./constant/polyMesh/boundary file isn't a good idea)? They aren't needed anymore, hence i don't want to specify a boundary condition for these internal patches!

Thanks in advance for helpful hints!
/Stefan

stevenvanharen January 19, 2011 11:46

Just deleting is not a good idea. Just use stitchMesh.

After using stitchMesh you will see the boundaries are still present in the boundary file bu they will contain 0 faces. You can just delete them from this file in this case (don't forget to change the number of boundaries at the top of the boundary file).

SD@TUB January 20, 2011 08:16

Thanks Steven,

but what about the following issue?
When joining two grids where the connecting interface is named equally, mergeMeshes will leave this interface in the boundary file. It is obvious that this patch will consist of several faces, points, etc. In this
case stitchMesh will not work, because the need of <masterPatch> and <slavePatch>. Selecting this interface for master and slave will cause an error:
Code:

--> FOAM FATAL ERROR:
Zero length edge detected. Probable projection error: slave patch probably does project onto master.

Is it possible to delete interfaces in the above-mentioned scenario?


/Stefan
BTW: I am using version 1.7.x !

stevenvanharen January 20, 2011 08:36

I also had this problem.

I don't fully remember how I fixed it. I know I manually changed the names of the boundaries to not have two boundaries with the same name.

I think I did this before using mergeMeshes but I am not fully sure. But I suggest you try this.

prashant.A January 20, 2011 19:44

Well, its possible.
I would prefer stitchMesh, just because of the fact that mergeMeshes would also make one zone out of two which is sometimes not desired..

Remember a few things:

1. Before you "stitchMesh", move all the *Zones files to bak
2. After you have done "stitchMesh" successfully, a faceZone should appear with a name combination of the parts you have stitched. However, these bounday names still exist in the "boundary" file which need to be removed manually.
2. A new cellZone will be created, which you can conveniently ignore. Move cellZones.bak to cellZones so that you still have the different zone info intact in your mesh.
4. Run "checkMesh" once to ascertain that you followed all the steps correct !

Write back if you still see any issues...I hope I haven't missed anything in this regard.

SD@TUB January 21, 2011 11:53

Terminating, stitchMesh plus removing the empty patches afterwards in the boundary file by hand seems to be the only way at the very least. The connecting interfaces from different grids have to be named differently! Thats a bit inconvenient. Maybe in future mergeMeshes would get an additionally option that simplify merging several grids.

/Stefan

prashant.A January 21, 2011 13:42

Okay, I understand your problem. You can rename these interfaces in the boundary file itself, i.e. you need not go back to the mesher to be changed in the native format.

Rebecca513 October 4, 2011 22:05

Hi Stefan,

I am also trying to use stitchMesh to remove internal faces. I used extrudeMesh first, then merged the extruded and original meshes. And now I need to remove the generated internal patches.

But I keep getting the error message saying that 'Duplicate point found in cut face'. I wonder how you used this utility.

Any comment and suggestion is appreciated.

Thank you!

Quote:

Originally Posted by SD@TUB (Post 291579)
Terminating, stitchMesh plus removing the empty patches afterwards in the boundary file by hand seems to be the only way at the very least. The connecting interfaces from different grids have to be named differently! Thats a bit inconvenient. Maybe in future mergeMeshes would get an additionally option that simplify merging several grids.

/Stefan


SD@TUB October 9, 2011 06:09

Hi Rebecca,

Did you use stitchMesh -perfect flag? I guess not from your posted error message...
You can use attachMesh for deleting internal faces after stitching (see if a file meshModifiers exist within constant/polyMesh directory.

Hope that helps!


Stefan

Rebecca513 October 10, 2011 11:41

Hi Stefan,

Thank you for your reply. Yes I tried -perfect flag, then it works OK. Also, thank you for the suggestion on using attachMesh~But at this stage, it seems that after stitchMesh the faces become empty, and I could manually delete them.

Best,

Attesz March 2, 2012 15:10

Hi all,

I've problems with stitchMesh. I have 3 domains, with duplicate interfaces but the mesh points are coincident. When I want to stitch the interfaces using the -perfect option, i'm getting the following error message:

Quote:

--> FOAM FATAL ERROR:
Problem : Patch AMI_INROT1 starts at 33776699
Current face counter at 33704048
Are patches in incremental order?

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

FOAM aborting
If I renumber the faces as it is said by OF, it seems to be working but why is it occurs?

Best,
Attila

ebah6 March 23, 2012 02:34

Hello Attila,

I have a similar problem with pimpleDyMFoam.

-------------------------------------
--> FOAM FATAL ERROR:
Problem : Patch AMI1 starts at 1756182
Current face counter at 213326
Are patches in incremental order?

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

FOAM aborting
--------------------------

were you able to solve this problem?

Thanks for you help.

ebah6 March 23, 2012 04:30

Hello everyone,

I think my problem is coming from the fact that snappyHexMesh is creating patches with nFaces=0 as below:

-----------------
blenderBlades
{
type wall;
nFaces 0;
startFace 211046;
}
blenderAMI
{
type wall;
nFaces 0;
startFace 211046;
}
-----------------------------

can someone help with this issue?
Thank in advance; any help is greatly appreciated.

Attesz March 23, 2012 10:47

Hi I generated the mesh in ICEM CFD, using 1 common face as internal patch. Then, I exported the stator and rotor parts separately. After that I used the fluent3DMeshToFoam app to convert it to OF format, and then I did mergeMeshes to put them together. Now it works fine. You need two patches at the same position, or you should cut your mesh there. Also it is possible for you to generate your mesh separately with snappy and then merge them.

louisgag May 17, 2012 11:49

ebah6:

If you are running your case based on a modification of the propeller tutorial, you need to adjust the starting faces for both AMI faces of the boundary file prior to running createBaffles. This is mandatory and unfortunately not taken care of by the tutorial, which will thus only work for the specific mesh given.

You can automate this process by running a command right before changeDictionary. Or if you use snappyHexMesh in a similar fashion than in the tutorial, automate the process by modifying the Allrun.pre file as follows,

Code:

# - create the inlet/outlet patches

runApplication createPatch -overwrite

# - fix the startFace value in changeDictionaryDict

AMI_startFace=`cat log.snappyHexMesh|grep "Snapped mesh"|sed s/^.*faces://|sed s/"  points.*$"//`
sed -i s/"startFace      0;"/"startFace      $AMI_startFace;"/g system/changeDictionaryDict


# - create the AMI faces by creating baffles, and then splitting the mesh

runApplication changeDictionary

(Notice that my changeDictionaryDict file initially has both startValue = 0; I think this should be added to the tutorial...


-Louis

ebah6 May 17, 2012 15:01

Thanks Louis.


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