[gschaider]

I'm trying to import a mesh that was generated in Gambit (in order to compare OpenFOAM with Fluent).

It's a rather large room (>10m) with some thin walls in it (<1cm). These walls were not modelled by volumes but with surfaces: In Fluent the resulting faces can be assigned wall properties althoug topologically they are interior faces.

When I try to import that mesh with fluentMeshToFoam I get a fatal error:

--> FOAM FATAL ERROR : Trying to specify a boundary face 4(203114 207394 205234 203113) on the face on cell 185261 which is either an internal faceor already belongs to some other patch. This is face 0 of patch 16 namedbruestung_balkon.

in file: meshes/polyMesh/createPolyMesh.C at line: 375.

I looked at the source file and of course I could comment out that test and recompile OpenFOAM. But before I do that I'd like to ask: Would that make any sense? In other words: can OpenFOAM treat "interior faces" with boundary conditions (in that special case wall-boundaries)?

[gschaider]

This is a bit off topic: I just received a copy of the original posting by EMail. In the EMail some lines are missing (but on the Web-Interface the message is complete). The EMailed message doesn't make much sense. Please check the Web.

[mattijs]

No, OpenFOAM cannot have boundary conditions on interior faces.

What you can do is to make these interior faces exterior by splitting the mesh.

Either do that in Gambit (can it do this?) or use the splitMesh utility.

Tu use the splitMesh utility you will need to collect the conflicting faces in a faceSet and supply this as an argument.

Have a look at the faceSetDict (in mesh/manipulation/faceSet) to see how you can collect a faceSet.

Mattijs

[gschaider]

I've tried it using the splitMesh utility.

Just to check whether I understood this correctly:
- I imported the mesh from Gambit. The interior boundary (named obst) was converted to a faceSet (we can do that now ;-) )
- used the createPatch utility to create two wall-patches consisting of no faces (called obst_a and obst_b)
- the I called

splitMesh . innerboundary obst obst_a obst_b

This resulted in the following output (only the last part is shown, some of the debug-flags for the meshes were set):

Determining visibility from point 55
Determining visibility from point 76
Adding point and face zones

Constructed topologyModifier:

Splitter
{
type attachDetach;
faceZoneName membraneFaces;
masterPatchName obst_a;
slavePatchName obst_b;
triggerTimes 1(0);
manualTrigger off;
active on;
}

Adding topology modifiers
void attachPolyMesh::attach(): Attaching mesh
Modifier 0 named Splitter morphing
Bus error

This happens for two different geometries.

Any hints what could be wrong?

[mattijs]

Hi Bernhard,

Can you run checkMesh after you have added the empty patches?

I tried same on your testmesh.msh.

I added a halfA and a halfB patch of zero size and ran

splitMesh .. testmesh innen halfA halfB

I get lots of 'Determining visibility' messages and


Splitter
{
type attachDetach;
faceZoneName membraneFaces;
masterPatchName halfA;
slavePatchName halfB;
triggerTimes 1(0);
manualTrigger off;
active on;
}

which finishes without problems.

Does a traceback of the core in a debugger tell you anything?

[gschaider]

To be honest I havn't tried it with the testmesh.msh. Now I did. It works.

The two meshes splitMesh doesn't work with showed no problems with checkMesh (except for the fact that one of them is a pure tet-mesh; some people think that this is a problem ;-) , the other one contains all kinds of cells)

The condensed traceback of the core is:
Foam::attachDetach::detachInterface ()
Foam::attachDetach::setRefinement ()
Foam::polyMeshMorphEngine::topoChangeRequest ()
Foam::polyMesh::updateTopology ()
main()

I'll try to construct a minimal mesh that fails.

[mattijs]

Works ok for me.

I create a boundry file

boundary

and run

splitMesh .. cavity innen halfA halfB

and checkMesh tells me the domain has two unconnected regions.

There is however a intermittent pointer problem which is fixed in 1.1.1 so that might give you problems. I tried 1.1 as well and that worked as well.

[gschaider]

Mattijs, let me guess: you're working on a i386-machine?

I did the previous tests on our new Opteron (am so proud have to use it for everything :-) ). Went to one of our i386-boxes and did the splitting there: it worked without a crash.

Started from scratch and could reproduce this. So there seems to be some processor dependence there (don't know if you like that).

[mattijs]

Think it is the pointer problem. Try and run it on your i386 under valgrind and you'll see.

[sbrahim]

hello ,

I want to import .msh file from gambit but the OpenFoam could not know the walls has the interior of a furnace, for example walls of interior mobile.
when I execute here the error of OpenFoam is:


FOAM FATAL ERROR : Trying to specify a boundary face 3(145 69 138) on the face on cell 13873 which is either an internal face or already belongs to some other patch. This is face 0 of patch 4 named surf_sup.

Function: polyMesh::polyMesh
(
const IOobject& io,
const pointField& points,
const cellShapeList& cellsAsShapes,
const faceListList& boundaryFaces,
const wordList& boundaryPatchTypes,
const wordList& boundaryPatchNames,
const word& defaultBoundaryPatchType
)
in file: meshes/polyMesh/createPolyMesh.C at line: 375.
FOAM aborting
Aborted
thank you to inform me on this problem.
sincere greetings

[hjasak]

Interior walls are not supported - group the faces you want to make into a wall in a face zone and then use a mesh modifier. I am sure this has been discussed before in this newsgroup.

Enjoy,

Hrv

[gschaider]

A nice overview on this topic (making 'internal walls') was written some time ago by Christian Jordan:

http://openfoamwiki.net/index.php/Howto_importing _fluent_mesh_with_internal_walls

The only problem with this approach is that the splitMesh-utility uses a faceSet but doesn't update the other faceSets to the new faceNumbers. So if one (me for example) wanted to make another wall 'internal' or relies on faceSets for other purposes he had a problem.

A little mutation of the splitMesh-utility that converts the faceSets to the new face-numbers after splitting can be found at:

http://openfoamwiki.net/index.php/Contrib_SplitMe shWithSets

[melanie]

hello,

I had the same kind of problems by converting a Fluent mesh into Foam, as the construction edges are understood as walls.
I tried first the splitMesh utility as is, with the advices above, and had problems on running my case:

--> FOAM FATAL ERROR : This mesh contains patches of type empty but is not 1D or 2D
by virtue of the fact that the number of faces of this
empty patch is not divisible by the number of cells.

From function emptyFvPatchField<type>::updateCoeffs()
in file fields/fvPatchFields/basicFvPatchFields/empty/emptyFvPatchField.C at line 129.

FOAM aborting

As the problem was linked to the number of faces, I tried to install the splitMeshWithSets, but unfortunately I get an error message on compilation:

~/OpenFOAM/tzntgq-1.2.1/applications/bin/linuxAMD64Gcc4Opt/utilities/splitMeshWi thSets> wmake
Making dependency list for source file regionSide.C
Making dependency list for source file splitMeshWithSets.C

SOURCE_DIR=.
SOURCE=regionSide.C ; g++ -m64 -DlinuxAMD64 -Wall -W -Wno-unused-parameter -Wold-style-cast -march=opteron -O3 -ffast-math -DNoRepository -ftemplate-depth-30 -I/appl/OpenFOAM/OpenFOAM-1.2.1/src/dynamicMesh/lnInclude -I/appl/OpenFOAM/OpenFOAM-1.2.1/src/meshTools/lnInclude -I/appl/OpenFOAM/OpenFOAM-1.2.1/src/OpenFOAM/lnInclude -IlnInclude -I. -fPIC -c $SOURCE -o Make/linuxAMD64Gcc4Opt/regionSide.o
SOURCE_DIR=.
SOURCE=splitMeshWithSets.C ; g++ -m64 -DlinuxAMD64 -Wall -W -Wno-unused-parameter -Wold-style-cast -march=opteron -O3 -ffast-math -DNoRepository -ftemplate-depth-30 -I/appl/OpenFOAM/OpenFOAM-1.2.1/src/dynamicMesh/lnInclude -I/appl/OpenFOAM/OpenFOAM-1.2.1/src/meshTools/lnInclude -I/appl/OpenFOAM/OpenFOAM-1.2.1/src/OpenFOAM/lnInclude -IlnInclude -I. -fPIC -c $SOURCE -o Make/linuxAMD64Gcc4Opt/splitMeshWithSets.o
splitMeshWithSets.C: In function âint main(int, char**)â:
splitMeshWithSets.C:325: error: no matching function for call to âFoam::attachDetach::attachDetach(const char [9], int, Foam::attachPolyMesh&, const char [14], Foam::word&, Foam::word&, Foam::scalarField)â
/appl/OpenFOAM/OpenFOAM-1.2.1/src/dynamicMesh/lnInclude/attachDetach.H:174: note: candidates are: Foam::attachDetach::attachDetach(const Foam::word&, const Foam::dictionary&, Foam::label, const Foam::polyMeshMorphEngine&)
/appl/OpenFOAM/OpenFOAM-1.2.1/src/dynamicMesh/lnInclude/attachDetach.H:165: note: Foam::attachDetach::attachDetach(const Foam::word&, Foam::label, const Foam::polyMeshMorphEngine&, const Foam::word&, const Foam::word&, const Foam::word&, const Foam::scalarField&, bool)
/appl/OpenFOAM/OpenFOAM-1.2.1/src/dynamicMesh/lnInclude/attachDetach.H:114: note: Foam::attachDetach::attachDetach(const Foam::attachDetach&)
make: *** [Make/linuxAMD64Gcc4Opt/splitMeshWithSets.o] Error 1

Could someone help me fixing the bug ?
thanks !
mélanie

[gschaider]

Hi Melanie!

@fatal error with empty patch: Look through the polymesh/boundary-file for patches of type "empty" and replace the type there with a more appropriate one ("wall" for instance)

@compilation problem: You're not using the stock-1.2-version, but a newer version? It seems that there was a change in the constructor of attachDetach. Instead of
tm[0] =
new attachDetach
(
"Splitter",
0,
pMesh,
"membraneFaces",
masterPatch,
slavePatch,
scalarField(1, runTime.value())
);

it now should be

tm[0] =
new attachDetach
(
"Splitter",
0,
pMesh.morphEngine(),
"membraneFaces",
masterPatch,
slavePatch,
scalarField(1, runTime.value())
);

(the line with morphEngine changed)

I'll write a remark to this effect on the Wiki page (I have both kinds of 1.2-versions and always have to modify that line)

[melanie]

Thanks Bernhard,

indeed I forgot to reset the patches and fields before running. When I set it correctly, I get the same error, but I think something is wrong in my procedure:

1. I import the mesh from Fluent, it creates faceSets on each internal edge (2D mesh), for example face Set int1
2. I create 2 empty patches with names int1_a and int1_b
3. I call splitMesh; the output is correct
4. I reset all the patches but int1_a and int1_b are already here, with faces defined, and set to empty, and I run the case with the fatal error.

I don't know how to tell Foam that int1_a and int1_b are nothing but an internal boundary...

should I rerun the splitMeshWithSet utility ?
thanks!

[gschaider]

Hi Melanie!

What do you mean with "internal boundary"? Something interacting with the flow (like a wall for instance)? In that case you'll have to set the type of the patches to walls (or something appropriate). Or do you need it for "diagnostic" purposes (for instance calculating the mass flow through a specific "control area"? In that case you don't have to split thew mesh but use the faceSet (this is discussed somewhere else on the MessageBoard or the wiki).

If you have a second boundary (for instance int2) that you want to split the mesh with you'll have to use splitMeshWithSet instead of splitMesh at step 3 of your description (repeat steps 2-4 for every faceSet you want to split).

[melanie]

Sorry Bernhard, I think I was not clear enough.

My conversion problems come from the fact that some interior edges, which were defined in Gambit for construction handling and that I cannot remove or I remove the mesh, these edges are understood as walls within OpenFoam. That is why I wanted to do something about it. It is like if I defined it for diagnostic purposes as you say.

[gschaider]

If I understand you correctly, the last thing you want to do is a splitMesh. Just convert it with fluentMeshToFoam. If checkMesh doesn't complain everything is good and the internal boundaries won't interfer with your simulation.

[fra76]

Hi!
I'm trying to use the splitMeshWithSets utility downloaded from here: http://openfoamwiki.net/index.php/Contrib_SplitMe shWithSets
It seems to work fine, but I have a problem: the mesh is really big.
I tried to run it on Opteron machine with 4Gb of maximum virtual memory size imposed, and it fails.
On 32bit machines, it fails as well.
On my Athlon64 PC I have "only" 2Gb of ram, Linux tries to use the swap space, and it really slows down the process.
I have exactly the same problem with the normal splitMesh utility.

The question is:
is it possible to run splitMesh (or splitMeshWithSets) in parallel? I mean, AFTER decomposePar.
Francesco

[gschaider]

I'm afraid you can't. If it's not supported in the original splitMesh, then it's not supported in splitMeshWithSets (which is only a slight extension of the original). And the original has parallel explictly switched off (I can only guess the reason without diving into the source, but one guess would be that faceSets are not supported by decomposePar).

splitMeshWithSets uses more memory that splitMesh. Does splitMesh fail too for the first faceSet?