StitchMesh on two patches
 

Hi
I want to use stitchMesh to combine two regions.
The first one is L-shaped. The other one's position is inside the corner.
Like this:
------------------------------------
|6......................................5|
|.........................................|
|.........................................|
|1......................2................|
|==============................|
|10...................9||...............|
|........................||...............|
|........................||...............|
|7....................8||3.............4|
------------------------------------

I build patches: 1-2, 2-3, 10-9 and 9-8.

I can either stitch 1-2 to 10-9 or 9-8 to 2-3.
If I try a second stitch I get the error:



--> FOAM FATAL ERROR : point, face or cell zone already exists#0 Foam::error::printStack(Foam:http://www.cfd-online.com/OpenFOAM_D...part/proud.gifstream&) in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#1 Foam::error::abort() in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#2 Foam::polyMesh::addZones(Foam::List<foam::pointzon e*> const&, Foam::List<foam::facezone*> const&, Foam::List<foam::cellzone*> const&) in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#3 main in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linuxGccDPOpt/stitchMes h"
#4 __libc_start_main in "/lib/libc.so.6"
#5 Foam::regIOobject::readIfModified() in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linuxGccDPOpt/stitchMes h"


From function void addZones
(
const List<pointzone*>& pz,
const List<facezone*>& fz,
const List<cellzone*>& cz
)
in file meshes/polyMesh/polyMesh.C at line 865.

FOAM aborting


I also tried with L-shaped patches: 1-2-3 and 10-9-8. In this case the error is:

....
local: 4(615 1002 1008 674) one side: 147 other side: 145
Finished face 147
local: 4(1002 616 675 1008) one side: 148 other side: 145
local: 4(616 1003 1009 675) one side: 148 other side: 146
Finished face 148
local: 4(1003 617 676 1009) one side: 149 other side: 146


--> 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#0 Foam::error::printStack(Foam:http://www.cfd-online.com/OpenFOAM_D...part/proud.gifstream&) in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#1 Foam::error::abort() in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#2 Foam::enrichedPatch::calcCutFaces() const in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libdynamicMesh.so"
#3 Foam::enrichedPatch::cutFaces() const in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libdynamicMesh.so"
#4 Foam::slidingInterface::coupleInterface(Foam::poly TopoChange&) const in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libdynamicMesh.so"
#5 Foam::slidingInterface::setRefinement(Foam::polyTo poChange&) const in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libdynamicMesh.so"
#6 Foam::polyTopoChanger::topoChangeRequest() const in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libdynamicMesh.so"
#7 Foam::polyTopoChanger::changeMesh(bool, bool) in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libdynamicMesh.so"
#8 main in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linuxGccDPOpt/stitchMes h"
#9 __libc_start_main in "/lib/libc.so.6"
#10 Foam::regIOobject::readIfModified() in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linuxGccDPOpt/stitchMes h"


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

FOAM aborting


Can somebody help me?

Hi, stitchmesh creates zone (
 

Hi,
stitchmesh creates zone (and maybe meshModifiers) that cause multiple stitchMeshes to fail. If you delete the *Zones (pointZones,faceZones,cellZones) files in the polyMesh directory then using stitchMesh multiple times should work.

You might have to move the mesh into the constant directory first (not sure if stitchMesh puts the combined mesh in the constant directory or a new time directory)

Cheers
Andrew

Hi Andrew, if I do want you
 

Hi Andrew,

if I do want you said ( copy mesh to constant and delete *Zones) there is a new error.

------------------
Create mesh for time = 0

Coupling patches innerpatch and outerpatch
Resulting (internal) faces will be in faceZone innerpatchouterpatchCutFaceZone

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



--> FOAM FATAL ERROR : Not all zones and patches needed in the definition have been found. Please check your mesh definition.#0 Foam::error::printStack(Foam:http://www.cfd-online.com/OpenFOAM_D...part/proud.gifstream&) in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#1 Foam::error::abort() in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#2 Foam::slidingInterface::checkDefinition() in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libdynamicMesh.so"
#3 Foam::slidingInterface::slidingInterface(Foam::wor d const&, Foam::dictionary const&, int, Foam::polyTopoChanger const&) in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libdynamicMesh.so"
#4 Foam::polyMeshModifier::adddictionaryConstructorTo Table<foam::slidinginterface>: :New(Foam::word const&, Foam::dictionary const&, int, Foam::polyTopoChanger const&) in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libdynamicMesh.so"
#5 Foam::polyMeshModifier::New(Foam::word const&, Foam::dictionary const&, int, Foam::polyTopoChanger const&) in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libdynamicMesh.so"
#6 Foam::polyTopoChanger::readModifiers() in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libdynamicMesh.so"
#7 Foam::polyTopoChanger::polyTopoChanger(Foam::polyM esh&) in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libdynamicMesh.so"
#8 main in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linuxGccDPOpt/stitchMes h"
#9 __libc_start_main in "/lib/libc.so.6"
#10 Foam::regIOobject::readIfModified() in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linuxGccDPOpt/stitchMes h"


From function void slidingInterface::checkDefinition()
in file slidingInterface/slidingInterface.C at line 85.

FOAM aborting

_______________________________________

CheckMesh says the mesh is ok.

What now?

Hi Anita, If there is a me
 

Hi Anita,

If there is a meshModifiers in the polyMesh directory you will need to delete that too. If that's not the case then I'm not sure what the problem is.

Cheers,
Andrew

Hi again, I also deleted me
 

Hi again,

I also deleted meshModifiers. Now stitchMesh starts working and stops with error.
___________________________________________
--> FOAM FATAL ERROR : Face 31033 reduced to less than 3 points. Topological/cutting error B.
Old face: 2(20971 20471) new face: 2(20971 20471)#0 Foam::error::printStack(Foam:http://www.cfd-online.com/OpenFOAM_D...part/proud.gifstream&) in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#1 Foam::error::abort() in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#2 Foam::slidingInterface::coupleInterface(Foam::poly TopoChange&) const in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libdynamicMesh.so"
#3 Foam::slidingInterface::setRefinement(Foam::polyTo poChange&) const in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libdynamicMesh.so"
#4 Foam::polyTopoChanger::topoChangeRequest() const in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libdynamicMesh.so"
#5 Foam::polyTopoChanger::changeMesh(bool, bool) in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libdynamicMesh.so"
#6 main in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linuxGccDPOpt/stitchMes h"
#7 __libc_start_main in "/lib/libc.so.6"
#8 Foam::regIOobject::readIfModified() in "/home/kienzani/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linuxGccDPOpt/stitchMes h"


From function void slidingInterface::coupleInterface(polyTopoChange& ref) const
in file slidingInterface/coupleSlidingInterface.C at line 1666.

FOAM aborting
_________________________________________________

Hmm, I'm not sure about this e
 

Hmm, I'm not sure about this error.

You might have better luck using createPatch to join patches 1-2 and 2-3 together and patches 10-9 and 9-8 together first, then use stitchMesh to join 1-2-3 and 10-9-8 together. (Or join these together in the original mesh creation step).

see OF-1.4.1/applications/utilities/mesh/manipulation/createPatch/createPatchDict for details on createPatch if you haven't used it before. Again, you'll probably have to move the mesh back to constant after each step, and remove any Zones and meshmodifiers files as well.

Regards,
Andrew

You need to use the latest upd
 

You need to use the latest updates in 1.4.1-dev: I have spent some weeks sorting out the sliding mesh algorithm you are using here.

Hrv

Hi, I now used the latest v
 

Hi,

I now used the latest version of 1.4.1-dev and received the same error (Face xxx reduced to less than 3 points.)

I also tried using createPatch like Andrew wrote above. This way the error is:

--> 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 248.


After each step I removed Zones and copied the mesh to constant.

Five to one you have messed up
 

Five to one you have messed up the definition of the patches that are supposed to be merged. These patches should be facing each other: yours are oriented 90 degrees relative to each other.

Please make a picture of the patches you are trying to merge and tell me what happened.

Hrv

Hallo Hrv, Here are two pic
 

Hallo Hrv,

Here are two pictures from the mesh. I cannot find a wrong definition.

Image of the mesh:

http://www.cfd-online.com/OpenFOAM_D...ges/1/7438.jpg

Image of the mesh with colored patches:
I want to merge red with green and blue with yellow.

http://www.cfd-online.com/OpenFOAM_D...ges/1/7439.jpg

Another problem I have is that with the 1.4.1-dev version checkMesh gives an error:
"This mesh has no valid solving directions. dirs = (-1 -1 -1). Please check mesh definition for empty patches. This is a 0-D mesh."
After using flattenMesh checkMesh says the Mesh is ok.

It is the same problem like the one I descripted in http://www.cfd-online.com/OpenFOAM_D...tml?1207732177

Maybe the stitch problem is a consequence?

You could try 2 things: - con
 

You could try 2 things:
- connect two surfaces one at a time, to see that the definition is OK.
- if you want to connect both together, you will need to use n-squared search in point projection since your surface has got a serious kink in it. There is a switch in:

.OpenFOAM-1.4.1-dev/controlDict


OptimisationSwitches
{
fileModificationSkew 10;
scheduledTransfer 0;
floatTransfer 1;
nProcsSimpleSum 0;

GGImaxIter 5;

nSquaredProjection 0;

}

Do nSquaredProjection 1; and try again.

Hrv

Hi all! I have been strugglin
 

Hi all!
I have been struggling with the same stitchMesh issues like Anita for some time and I haven't solved it yet.

I broke down the problem to the simplest possible test case in which I want to connect two pairs of "nonconformal interfaces". They are called if_a0, if_a1 and if_b0, if_b1. Can anybody explain to me how to connect if_a0 to if_a1 and if_b0 to if_b1 using the stitchMesh utility in OpenFOAM-1.4.1 ?

Here is the testcase:



regards,
Andras

Hi all! I have been strugglin
 

Hi all!
I have been struggling with the same stitchMesh issues like Anita for some time and I haven't solved it yet.

I broke down the problem to the simplest possible test case in which I want to connect two pairs of "nonconformal interfaces". They are called if_a0, if_a1 and if_b0, if_b1. Can anybody explain to me how to connect if_a0 to if_a1 and if_b0 to if_b1 using the stitchMesh utility in OpenFOAM-1.4.1 ?

Here is the testcase:
http://nic-nac-project.de/~andras/stitchTest.zip


regards,
Andras

Hallo Hrv, I can connect re
 

Hallo Hrv,

I can connect red with green or blue with yellow.
Using the switch nSquaredProjection to connect both don't change anything. It still does not work.

Anita

Hi all, I managed to solve th
 

Hi all,
I managed to solve the test case (posted above) at last...
Here is my stitchMesh recipe:

--
1. Import or generate a mesh
2. Use stitchMesh on one pair of congruent patches
3. Edit "startTime" in system/controlDict to point to the time directory containing your stitched mesh
4. Apply foamMeshToFluent to your case directory (the Fluent mesh is put in fluentInterface/)
5. Clear all meshes in constant and all time directories in your case directory
6. Import the exported Mesh with fluent3DMeshToFoam
7. Use stitchMesh on the next pair of congruent patches
8. Repeat steps 3-7 for every other stitchMesh action
--

Does anyone have a simpler solution?

regards,
Andras

Hi Andras, I just followed
 

Hi Andras,

I just followed the steps you listed, but they can't solve my problem.

Maybe first a little remark: Since fluent3DMeshToFoam always runs in a Segmentation fault, I'm using fluentMeshToFoam which works without any problem at least for the initial mesh import.

So, following your steps, I succeed until I reach point 6.
fluent3DMeshToFoam runs into a Segmentation fault as already witnessed.
The problem is that fluentMeshToFoam can't help me out of trouble this time either...

Applying fluentMeshToFoam the resulting error is the following one:

Dimension of grid: 3
Number of points: 2636330
Number of cells: 2468160
number of faces: 7571842
Reading points
Reading mixed faces

--> FOAM FATAL IO ERROR : wrong token type - expected int found on line 1 the word 'f'

file: IStringStream.sourceFile at line 1.

From function operator>>(Istream&, int&)
in file primitives/int/intIO.C at line 74.

FOAM exiting

What is actually happening there in detail and does anybody have a clue how to solve this problem?

I would appreciate that very much because stitchMesh already took a lot of my time...

Hi Andreas, Could you try run
 

Hi Andreas,
Could you try running fluent3DMeshToFoam on the small test case posted above?
By the way: did checkMesh (output of the latest time directory) complain about anything after stitching the patches?


Andras

Hi Andras, From your case I
 

Hi Andras,

From your case I created a Fluent mesh by foamMeshToFluent and tried to re-import it by using fluent3DMeshToFoam resulting in this error:

**********

/*---------------------------------------------------------------------------*\
| ========= | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | Version: 1.4.1-dev |
| \ / A nd | Web: http://www.openfoam.org |
| \/ M anipulation | |
\*---------------------------------------------------------------------------*/

Exec : fluent3DMeshToFoam . stitchTest stitchTest/fluentInterface/stitchTest.msh
Date : May 14 2008
Time : 10:38:47
Host :
PID : 22763
Root : /scratch/stitchTest
Case : stitchTest
Nprocs : 1
Create time

Dimension of grid: 3
Number of points: 6156
Number of cells: 4887
Number of faces: 15828
PointGroup: 1 start: 0 end: 6155. Reading points...done.
FaceGroup: 2 start: 0 end: 13493. Reading mixed faces...done.
FaceGroup: 10 start: 13494 end: 14618. Reading mixed faces...done.
FaceGroup: 11 start: 14619 end: 14938. Reading mixed faces...done.
FaceGroup: 12 start: 14939 end: 15338. Reading mixed faces...done.
FaceGroup: 13 start: 15339 end: 15563. Reading mixed faces...done.
FaceGroup: 14 start: 15564 end: 15663. Reading mixed faces...done.
FaceGroup: 15 start: 15664 end: 15763. Reading mixed faces...done.
FaceGroup: 16 start: 15764 end: 15827. Reading mixed faces...done.
CellGroup: 1 start: 0 end: 4886 type: 1
Zone: 1 name: fluid-1 type: fluid. Reading zone data...done.
Zone: 2 name: interior-1 type: interior. Reading zone data...done.
Zone: 10 name: wall:010 type: wall. Reading zone data...done.
Zone: 11 name: wall:001 type: wall. Reading zone data...done.
Zone: 12 name: wall type: wall. Reading zone data...done.
Zone: 13 name: if_b1 type: wall. Reading zone data...done.
Zone: 14 name: if_b0 type: wall. Reading zone data...done.
Zone: 15 name: if_a1 type: wall. Reading zone data...done.
Zone: 16 name: if_a0 type: wall. Reading zone data...done.

FINISHED LEXING

--> FOAM Warning :
From function boundBox::boundBox(const pointField& points)
in file meshes/boundBox/boundBox.C at line 52
cannot find bounding box for zero sized pointFieldreturning zero
Creating patch 0 for zone: 10 name: wall:010 type: wall
Creating patch 1 for zone: 11 name: wall:001 type: wall
Creating patch 2 for zone: 12 name: wall type: wall
Creating patch 3 for zone: 13 name: if_b1 type: wall
Creating patch 4 for zone: 14 name: if_b0 type: wall
Creating patch 5 for zone: 15 name: if_a1 type: wall
Creating patch 6 for zone: 16 name: if_a0 type: wall
Creating cellZone 0 name: fluid-1 type: fluid
patch 0 from Fluent indices: 13494 to: 14618 type: wall
patch 1 from Fluent indices: 14619 to: 14938 type: wall
patch 2 from Fluent indices: 14939 to: 15338 type: wall
patch 3 from Fluent indices: 15339 to: 15563 type: wall
patch 4 from Fluent indices: 15564 to: 15663 type: wall
patch 5 from Fluent indices: 15664 to: 15763 type: wall
patch 6 from Fluent indices: 15764 to: 15827 type: wall
Segmentation fault

**********

So it seems there's something running quite wrong... any hints?

Andreas, You are running Open
 

Andreas,
You are running OpenFOAM "Version: 1.4.1-dev". I am using 1.4.1 "vanilla" and haven't had any segmentation faults in the mesh converters until now. You could try reverting to 1.4.1 and try my recipe again...

Maybe you can do multiple stitches without using the mesh converters at all, but I don't know how.

Andras

Hi Andras, I thought this t
 

Hi Andras,

I thought this thread is all about using stitchMesh in the 1.4.1-dev version...

I'll try it your way again with 1.4.1 and will report the result to you.

Thanks,
Andreas

Ok, Andras, your test case
 

Ok, Andras,

your test case works in the way you are describing it using OpenFOAM-1.4.1

Applying the proposed steps to my case always causes problems with the stitchMesh function, normally running into the 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#0 Foam::error::printStack(Foam::stream&) in "~/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"

Maybe you can even help me out of this situation!?
I would be really interested in finally solving this problem...

Andreas, I am trying to sti
 

Andreas,

I am trying to stitch the faces that make up the surface of a cylinder (to connect inner and outer meshes for Multiple Reference Frame simulations). I can stitch either both pairs of circles or the cylindrical shell but I can't connect the shell patches, when the circles are already stitched.

I have tried creating combined patches and stitching the pairs at once and also stitching them one by one. Either way I run into "projection errors" and other strange errors like you do.

A congruent straight line edge between two or more patches stitches fine. I checked that with another test case. Congruent curved edges seem to be the troublemaker when the patches are not parallel to each other... but this is just a guess.

To cut it short: I'm stuck. Although some people say that stitchMesh is actually working fine I think there are some bugs underneath the carpet (especially concerning more complex geometries).


Andras

Hello Andras, what I'm tryi
 

Hello Andras,

what I'm trying to stitch are the diffeent mesh resolutions here:

http://www.cfd-online.com/OpenFOAM_D...ges/1/7680.jpg.

As can be seen the Interfaces aren't curvy and the geometry seems quite simple. But not simple enough for stitch Mesh...

I do not even find a starting point were to continue with a new approach of solving that problem.

So any idea for a new starting point is pretty welcome!!

Hi Andreas! You could try cre
 

Hi Andreas!
You could try creating two final patches using the "createPatch" tool with a createPatchDict that looks like this:

/*---------------------------------------------------------------------------*\
| ========= | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | Version: 1.0 |
| \ / A nd | Web: http://www.openfoam.org |
| \/ M anipulation | |
\*---------------------------------------------------------------------------*/

FoamFile
{
version 2.0;
format ascii;

root "/home/yourUsername/YourCaseRoot";
case "caseName";
instance "system";
local "";

class dictionary;
object createPatcheDict;
}

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

patches
(

{
// Name of new patch
name if0;

// Type of new patch
type patch;

// How to construct: either 'patches' or 'set'
constructFrom patches;

// If constructFrom = patches : names of patches
patches ( face1 face2 face3 ... );

}

{
// Name of new patch
name if1;
...
}

);

Then stitch the combined patches.

Have you already tried my recipe on your mesh with OpenFoam-1.4.1 vanilla?


Best,
Andras

Hello Andras, well, maybe I
 

Hello Andras,

well, maybe I did not get the point, but the patches are already defined out of the four faces.

For example if I use
stitchMesh <root> <case> IF_1_inside IF_1_outside,
my aim is to stitch the two patches surrounding the smallest square. What I'm trying to say is that e.g. IF_1_inside consists out of the faces 1, 2, 3, 4, and I do not have to stitch every single face. (As far is I understood the functionality of createPatch is to combine the faces to one single patch!?)


I already tried your recipe on my mesh with OpenFoam-1.4.1 from the opencfd page, but what is the vannila version of that?

Thanks for your time,
Andreas

Hi Andreas! When saying vanil
 

Hi Andreas!
When saying vanilla I mean the standard release without any development patches...
I'm sorry to say I have no further ideas concerning stitchMesh at the moment.


Andras

hi, I do not know if my pro
 

hi,

I do not know if my problem falls in this thread or not but it is kind of strange.

I am trying to mesh a small region between the slot and flap. I define points in sequence but point 3 should be to the right of point 2 but it comes to the left of point 2 no matter what I try.

I am attaching both the image file and the blockMeshDict with this.

Can some one please take a look and help me? I am just trying this patch individually before I put it in my main mesh.

Thanx a lot.

http://www.cfd-online.com/OpenFOAM_D...hment_icon.gif blockMeshDict

Hello, I've tried to get rid
 

Hello,
I've tried to get rid of 2 pairs of interfaces in my simulation and did so like Andras Horvarth. But when I run foamMeshToFluent I get the following error message:

--> FOAM FATAL ERROR : edgeFaces_ full at entry:16 for edge 2 0#0 Foam::error::printStack(Foam:http://www.cfd-online.com/OpenFOAM_D...part/proud.gifstream&) in "/usr/lib64/OpenFOAM/OpenFOAM-1.4.1/lib/libOpenFOAM.so"
#1 Foam::error::abort() in "/usr/lib64/OpenFOAM/OpenFOAM-1.4.1/lib/libOpenFOAM.so"
#2 Foam::cellMatcher::calcEdgeAddressing(int) in "/usr/lib64/OpenFOAM/OpenFOAM-1.4.1/lib/libOpenFOAM.so"
#3 Foam::tetMatcher::matchShape(bool, Foam::List<foam::face> const&, Foam::List<int> const&, int, Foam::List<int> const&) in "/usr/lib64/OpenFOAM/OpenFOAM-1.4.1/lib/libOpenFOAM.so"
#4 Foam::degenerateMatcher::match(Foam::List<foam::fa ce> const&, Foam::List<int> const&, int, Foam::List<int> const&) in "/usr/lib64/OpenFOAM/OpenFOAM-1.4.1/lib/libOpenFOAM.so"
#5 Foam::degenerateMatcher::match(Foam::primitiveMesh const&, int) in "/usr/lib64/OpenFOAM/OpenFOAM-1.4.1/lib/libOpenFOAM.so"
#6 Foam::primitiveMesh::calcCellShapes() const in "/usr/lib64/OpenFOAM/OpenFOAM-1.4.1/lib/libOpenFOAM.so"
#7 Foam::primitiveMesh::cellShapes() const in "/usr/lib64/OpenFOAM/OpenFOAM-1.4.1/lib/libOpenFOAM.so"
#8 Foam::fvSchemes::read() in "/usr/lib64/OpenFOAM/OpenFOAM-1.4.1/applications/bin/foamMeshToFluent"
#9 Foam::objectRegistry::writeData(Foam:http://www.cfd-online.com/OpenFOAM_D...part/proud.gifstream&) const in "/usr/lib64/OpenFOAM/OpenFOAM-1.4.1/applications/bin/foamMeshToFluent"
#10 __libc_start_main in "/lib/libc.so.6"
#11 Foam::fvMesh::readUpdate() in "/usr/lib64/OpenFOAM/OpenFOAM-1.4.1/applications/bin/foamMeshToFluent"


From function calcEdgeAddressing(const faceList&, const label)
in file meshes/meshShapes/cellMatcher/cellMatcher.C at line 202.

FOAM aborting

Aborted

Hi all, now I've played ar
 

Hi all,

now I've played around with stitchMesh in a similar configuration than Andreas Dietz, just that it is all hexa. In fact the mesh is generated with ICEM pure hexa in good old block refinement style. When going through unstruct representation in ICEM in order to use fluent format for transfer, there is no connectivity of the non-conformal patches as could have been in Multiblock representation IIRC good old TASCflow times.
SO far so good. So I went to stitch together all the patches and understood I had to do it separately, which means to fiddle around in ICEM to separate the volumes and interface regions ok. (tried the n-squared setting to 1, worked with no complaint but meshCheck complained about degenerate elements, believe he found some elements on opposite sides of the interfaces surrounding a hydrofoil). Got it to have 2x8 patches, pairing each. I put up a little shell script to automate the task. It might be neither bullet-proof neither a tutorial of efficient shell programming but it might be useful for some:

# The pairing patches from ICEM are named e.g. INT_01_E_0 INT_01_E_1 (or _Red _Green)

# The important is that two and only two patches containing the PatchList entry exist

PatchList=( INT_01_E INT_01_W INT_01_N INT_01_S INT_12_W INT_12_E INT_12_N INT_12_S )

echo ${PatchList[@]}

for PatchBase in ${PatchList[@]}; do

rm constant/polyMesh/*Zones
rm constant/polyMesh/meshModifiers
Patches=$(grep $PatchBase constant/polyMesh/boundary)
echo $Patches
stitchMesh ${Patches[0]} ${Patches[1]}

if [ -e 1e-05/polyMesh/ ]
then
rm -r constant/polyMesh/
mv 1e-05/polyMesh/ constant/
rm -r 1e-05
npatch=$(grep -P -m 1 ^[0-9]+$ constant/polyMesh/boundary)
nrm=$(grep -c $PatchBase constant/polyMesh/boundary)
nnew=$(( $npatch - $nrm ))
echo "$npatch $nrm $nnew"
cp constant/polyMesh/boundary tmpbnd
cat tmpbnd | sed "18s/$npatch/$nnew/" | sed "/$PatchBase/,+5d" > constant/polyMesh/boundary
checkMesh

else
exit
fi
done

So far I run into trouble again as soon as stitching a patch neighboring an already stitched patch. Patching N-S and N-S is fine, or E-W and E-W, as soon as a neighbor shall be stitched, I get an error:

Face 1977839 reduced to less than 3 points.
Topological/cutting error B.
Old face: 2(218300 218301) new face: 2(218300 218301)

From function void slidingInterface::coupleInterface(polyTopoChange& ref) const
in file polyMeshModifiers/slidingInterface/coupleSlidingInterface.C at line 1794.

with 1.5-dev (1095)

I ended up following another strategy that seamed more obfuscated at the beginning but showed up to be pretty feasible.

I export just a simple coarse Mesh from ICEM via fluent format into Foam. Then i got the refinement region boundaries as STL files from ICEM, I've slightly blown them up by offset. Use cellSet to define the refinement regions and refineMesh-dict on the cell sets to do the classical Hex-Cutting 2x2x2. This proved to work quite easily and avoids transferring huge fluent format files.

When using embedded refinement regions, have to start with the most outer one, because cells at the 'hanging node interface' become polyhedral and cannot be refined with the standard hex cell cutting.

Hrvoje, as you are apparently working on the invoked routines, I can provide you a more detailed description of what happens.

Cheers

Olivier

a compromise to stitching corners with stitchMesh
 

Recently, I happened to be working on stitching together interfaces (tops of boxes in fact) that contain corner points
and initially encountered some of the problems mentioned earlier on this thread cf.

Anita April 21, 2008, 13:27

lord_kossity May 15, 2008, 07:52

To take Anita's outline problem:

------------------------------------
|6......................................5|
|.........................................|
|.........................................|
|1...........................2................|
|==============................|
|10.......................9 || .............|
|............................ ||...............|
|............................ ||...............|
|7....................... 8 || 3.............4|
------------------------------------



stitching 1-2 with 10-9 prevents a similar operation for the pair 9-8 and 2-3. The problem seems
to be related to the projection of nodes from edge 9 to positions along edge 2. These projected nodes appear
as isolated points along edge 2 (when examining the interface 2- 3 in paraView for example)
which do not (necessarily) coincide with the vertices of the faces on the interface 2-3.
The algorithm (in enrichedPatchCutFaces.C) notices this and aborts.

As a possible compromise I used the schema below to resize the patches 9-8
and 2b-3 so that common edge points of (2a - 9 - 2b) are no longer included. After stitching all interfaces
i.e. initially 1 - 2a with 10-9a then 2b-3 with 9b-9 one
is left with a narrow patch one face area wide designated by "*". A "skeletal" patch, if you like, that will
require suitable boundary conditions in order to minimize its impact upon the prevailing flow.


------------------------------------
|6......................................5|
|.........................................|
|.........................................|
|1...........................2a................|
|==============................|
10........................9a *...............|
| .......................9b || 2b.............|
|............................ ||...............|
|............................ ||...............|
|7....................... 8 || 3.............4|
------------------------------------

The dimensions of the flow problem in my case meant that the presence&influence of such a "skeleton" could
be regarded as negligible. This may not always be the case though.


The following is a prescription (using either OpenFoam-1.5.x or OF-1.5-dev) to resize the relevant patches using a
combination of "faceSet" ("pointSet" could be incorporated too if required) and "createPatch" commands:

(
where
interface1 = 1 - 2 - 3
interface2 = 10 - 9 - 8
)

1)

in faceDictInterface1Faces

// Name of set to operate on
name interface1Faces;

// One of clear/new/invert/add/delete|subset/list
action new;

topoSetSources
(

// Patch to faces
patchToFace
{
name interface-1-2-3;
}

);

...issue commands
" cp faceDictInterface1Faces system/faceDict "
"faceSet"

2)

now extract faces whose normals point in the required direction

faceSetDictNormalx


// Name of set to operate on
name interface1-xDirectionFaces;

// One of clear/new/invert/add/delete|subset/list
action subset;

// Actions to apply to pointSet. These are all the topoSetSource's ending
// in ..ToFace (see the meshTools library).
topoSetSources
(

normalToFace
{
normal (1 0 0); // Vector
cos 0.01; // Tolerance (max cos of angle)
}

);

...issue commands
" cp faceSetDictNormalx system/faceDict "
"faceSet"


3)

for each set of faces aligned in a particular direction (or sitting on a component interface plane)
take those that have no vertex lying on the common edge 2-9.


faceSetDictNormalxReduced

// Name of set to operate on
name interface1-xDirectionReducedFaces;

// One of clear/new/invert/add/delete|subset/list
action subset;

// Actions to apply to pointSet. These are all the topoSetSource's ending
// in ..ToFace (see the meshTools library).
topoSetSources
(

// Faces with face centre within box
// Ensure the bounds do *not* include any common edge vertices
boxToFace
{
box (xMin yMin zMin) (xMax yMax zMax);
}

);

...issue commands
" cp faceSetDictNormalx system/faceDict "
"faceSet"


4)


createPatchDictNormalxReduced


// Tolerance used in matching faces. Absolute tolerance is span of
// face times this factor.
matchTolerance 1E-3;


// Do a synchronisation of coupled points.
//pointSync true;
pointSync false;

// Patches to create.
// If no patches does a coupled point and face synchronisation anyway.

patches
(

{
// Name of new patch
name interface1NormalxReduced;

// Type of new patch
type patch;

// How to construct: either 'patches' or 'set'
constructFrom set;

// If constructFrom = set : name of faceSet
set interface1-xDirectionReducedFaces;
}

);

...issue commands
" cp createPatchDictNormalxReduced system/createPatchDict "
"createPatch"



Then repeat steps 1)-4) for all the various interface planes. Finally, "stitchMesh" the 'reduced' interface planes
and apply boundary conditions to the remaining mesh "skeleton".


It's a painful process but might be a useful compromise in some circumstances.
When the surfaces meeting at the corner of an interface are non-planar
then greater use of "boxToFace" ( or similar pointSet directives) will unfortunately be required it seems.

With regard to cylindrical cap interfaces (cylinders with one closed end), it appears that sometimes these
can be stitched directly ( using OF-1.5dev, I didn't extensively check with OF1.5.x) and sometimes not (!). The only
noticeable difference in the two cases being the distribution of interface points along the edges. If points from
both interfaces coincide (to whatever tolerance) along the edge then the stitching process is likely to fail.
In the latter situation decomposing as above, 1) - 4), might be an alternative approach.


I hope this helps,

Richard Kenny.

Hello，Hrv,
I am trying to simulate two cars passing by each other, by moving mesh. so the geometry model is like in the attachment: block1 and block2 are the air parts, icube and ocube are two cars. block1 and block2 will move towards each other by setting their interfaces GGI.
Now, I am trying to mesh it.
I tried to used snappymultiRegionFoam case to create the mesh. so, in triSurface, there are four files: block1.stl, block2.stl, icub.stl, ocube.stl.
without icube and ocube, I got it managed to creat the mesh. Then I added the icube and ocube.
but，during snappyhexmesh, some information is givin like this:
CellZones:
block1 size:7919
block2 size:7737
icube size:0
ocube size:0
FaceZones:
iblock size:0
oblock size:1200
icube size:0
ocube size:0


Could you please help me on this? Is there some other way to creat the mesh i want? Thank you so much!!

Aqua

As this post is related to stichMesh and that I do not use it, I made a new thread:
Merging ege patches