[chris1980]

Hello,

I try to import my Star Mesh according to the userguide. The starToFoam convert works well but when I call checkMesh a lot of messages like this will show up:

bool primitiveMesh::checkCellsZipUp(const bool, labelHashSet*) const :
Cell 3783 has got 6 unmatched edges:
6
(
(4185 4312)
(4825 4698)
(4312 4193)
(4706 4825)
(4698 4706)
(4185 4193)
)

What can I do to get rid this ?


thanks in advance for your support.

[chris1980]

checkMesh also reports:

900 open cells found. Please use the mesh zip-up tool. Writing 900 cells with over used edges to set zipUpCells

this is the output of zipUpMesh

This edge modifies an already modified edge. Point insertions skipped.
This edge modifies an already modified edge. Point insertions skipped.
This edge modifies an already modified edge. Point insertions skipped.
This edge modifies an already modified edge. Point insertions skipped.
This edge modifies an already modified edge. Point insertions skipped.
This edge modifies an already modified edge. Point insertions skipped.
This edge modifies an already modified edge. Point insertions skipped.
This edge modifies an already modified edge. Point insertions skipped.
This edge modifies an already modified edge. Point insertions skipped.
This edge modifies an already modified edge. Point insertions skipped.
Cycle 1 changed 3090 faces.
Cycle 2 changed 62 faces.
--> FOAM Warning :
From function void polyMeshZipUpCells(polyMesh& mesh)
in file polyMeshZipUpCells/polyMeshZipUpCells.C at line 121
edge (36727 33387) in cell 28963 used 3 times.
Should be 1 or 2 - serious error in mesh structure.
--> FOAM Warning :
From function void polyMeshZipUpCells(polyMesh& mesh)
in file polyMeshZipUpCells/polyMeshZipUpCells.C at line 121
edge (36742 33452) in cell 28983 used 3 times.
Should be 1 or 2 - serious error in mesh structure.
--> FOAM Warning :
From function void polyMeshZipUpCells(polyMesh& mesh)
in file polyMeshZipUpCells/polyMeshZipUpCells.C at line 121
edge (36758 33515) in cell 29003 used 3 times.
Should be 1 or 2 - serious error in mesh structure.
--> FOAM Warning :
From function void polyMeshZipUpCells(polyMesh& mesh)
in file polyMeshZipUpCells/polyMeshZipUpCells.C at line 121
edge (36773 33578) in cell 29023 used 3 times.
Should be 1 or 2 - serious error in mesh structure.
--> FOAM Warning :
From function void polyMeshZipUpCells(polyMesh& mesh)
in file polyMeshZipUpCells/polyMeshZipUpCells.C at line 121
edge (36803 33704) in cell 29623 used 3 times.
Should be 1 or 2 - serious error in mesh structure.
--> FOAM Warning :
From function void polyMeshZipUpCells(polyMesh& mesh)
in file polyMeshZipUpCells/polyMeshZipUpCells.C at line 121
edge (36819 33767) in cell 29643 used 3 times.
Should be 1 or 2 - serious error in mesh structure.


--> FOAM FATAL ERROR : Found 6 problem cells.
Cells: 6(28963 28983 29003 29023 29623 29643)

From function void polyMeshZipUpCells(polyMesh& mesh)
in file polyMeshZipUpCells/polyMeshZipUpCells.C at line 729.

FOAM aborting

[hjasak]

Take a look at the mesh in Prostar and tell me what's going on with those cells - I bet you there's something wrong with the definition of couples.

Hrv

[chris1980]

sorry Hrv but I don't see any problems with my mesh in Prostar! All buildin mesh-checks (couple, boundary) report no errors.

I can mail you the mesh and you have a look at it. Perhaps you will see the problem ...

[hjasak]

I know that Prostar says no errors - the mesh checking in Prostar is not to be trusted anyway. Before you go any further, plot the thing on the screen, with the vertex numbers etc, plot the cpmatches and CHECK IT visually. Typically what happens is that Prostar defines a cpmatch on the wrong face (opposite of the one you intended) or some similar garbage like that.

As for looking at it, I do not usually do that (busy with my own work). The error will probably be obvoius anyway but if not please come back to me with more info (and pictures).

Hrv

[JBeilke]

You can also use the "ngeom" command in prostar to export a face based mesh and import it into OpenFOAM using the "ccm24ToFoam" converter.

[chris1980]

thanks Hrv for this information.

>cpmatch on the wrong face (opposite of the one you intended)

what is the expected "correct" face?

I think I have found some couple failures. There are more slaves defined than needed for the couple. I have tried to correct these things but zipUpMesh now complains 12 problem cells (6old one + 6 new ones)!


My Star mesh is using couples because of mesh refinement (one cell -> two cells). But there is a litte gap (because the couple face is not convex) between the master cell and the two slave cells. Star doesn't not care about this irregularity. Perhaps the starToFoam has a problem with this "mesh-failure"?

What are the relevant mesh/cell failures for me (checkMesh messages or zipUpMesh messages)?

[chris1980]

I have tried another mesh. The same errors as described above happened but when I do "zipUpMesh" than the following warning message (but no error messages) show up:

--> FOAM Warning :
From function bool primitiveMesh::warnCommonPoints(const label, const Map<label>&, bool&) const
in file meshes/primitiveMesh/primitiveMeshCheck.C at line 1607
Face 23644 vertex labels 5(17353 17784 17786 17788 17359) and face 537163 vertex labels 5(8897 8903 17788 17786 17784) share 3 vertices.
This mesh should only be used with faceDecomp finiteElement decomposition.
Further face-face warnings will be suppressed.

Is this a way to go?

[hjasak]

That last message is all fine - it means you should use the face decomposition in the tetFEM solver becase 2 cells share 3 points.

Apart from that, all is well, you've got a valid mesh.

Hrv

[hjasak]

Regarding the other mesh, I cannot give you a clear answer: you will need to look at the couples by hand and study the pictures. The face distortion does not matter; however, the couple definition MUST be correct according to the manual. I know exactly how and why the couples are used (I've worked for CD-adapco between 1996 and 2000) and my PhD (also sponsored by CD) is in error-driven adaptive mesh refinement.

In short, the couple algorithm in Star will give you errors because it is tolerance-based rather than topological and errors (almost certainly) cannot be avoided. For my taste, the mesh you are starting with is invalid and you only see the problem in OpenFOAM because the mesh check is done properly. I cannot help you with fixing the mesh and anyway it's not an OpenFOAM problem.

Hrv

[chris1980]

thanks hrv for your support

one thing I don't understand:

According to your posting my last mesh is fine (valid) why does checkMesh complain about 1602 open cells ans ask for running the mesh zip-up tool. Is there really no problem with the mesh?

I hope you could help me with my last question to the star mesh import procedure.

[hjasak]

Let me try to explain. For starters, two definitions. A cell is geometrically closed if the face area vectors for all faces of the cell sum up to zero to machine tolerance. A stronger requirement is a topologically closed cell. Here, when you take all the faces that make a cell and decompose them into edges, each edge should be used in exactly two faces. When you draw some pictures, you will see that a topologically closed cell is also geometrically closed, as the same points are consistently used in the calculation of the face areas.

Now, consider a hex cell on which we want to put a 2-1 (i.e. two cells connected to one side of the hex) cpmatch - draw some pictures, it may help you. What we will do is take one of the original quad faces, throw it away and replace with two new quad faces. In the best situation, the original and the two new faces are flat and match exactly and all seems well.

Looking at the tests above, the cell may now be geometrically closed, but topologically it is not. If you draw the picture of what I described, you will see that the two faces left and right of the cpmatch should actually be pentagons. In shape-based CFD meshes like the one you are looking at, this is not corrected: basically, you have a cell that looks closed but is not. The situation can get immensely worse if the faces are not flat as the result may look like an open cardboard box, i.e. not geometrically closed either. Looking at it closer, you will find there are 6 edges in a cell that are not shared by 2 faces, 3 on each side of the cpmatch.

Now you've got two choices:
- fix the mesh
- put a lot of rubbish into your discretisation to handle cells that are not closed (in slang, this is called the Marooney Manoeuvre) :-)

Since I do not allow rubbish in my discretisation, the choice in OpenFOAM is to fix the mesh. The second reason for fixing this is the automatic mesh motion. Even if the covered face looks OK statically, the use of automatic mesh motion will not move the loose point consistently with the rest of the cell and will make the cell open, which would be terrible!

The zip-up code you run on the resulting mesh (after cpmatching) looks for such sets of loose edges and fixes the mesh - in this case, it will make the left and right face a pentagon and the cells will be topologically closed. All attached faces (not just the ones in the cell you're looking at) will be fixed and the mesh will be fully consistent.

Hope this helps,

Hrv

[chris1980]

thanks Hrv for this very detailed answer. You are really CFD expert!

Sorry for my ignorance but when I try to start my solver the following error occurs:

--> FOAM FATAL ERROR : face 0 and 3002 areas do not match by 72.1012% -- possible face ordering problem

From function cyclicFvPatch::makeWeights(scalarField& w) const
in file fvMesh/fvPatches/derivedFvPatches/cyclicFvPatch/cyclicFvPatch.C at line 58.


What can I do?

[chris1980]

is there really nobody who can help me with my mesh problem?

[chris1980]

I have imported a Star mesh into Foam. But now there are problems with the cyclics. I have two faces using for cyclic boundary condition.
So I try to use createPatch to create one cyclic patch out of the 2 cyclic faces which I have imported from Star.

This is the output from createPatch

Reading createPatchDict

Copying patch WALL1 at position 0
Copying patch WALL2 at position 1
Copying patch WALL3 at position 2
Copying patch CYCL4 at position 3
Copying patch CYCL5 at position 4
Adding new patch cyclic of type cyclic as patch 5
Moving faces from patch CYCL4 to patch 5
Moving faces from patch CYCL5 to patch 5

Removing empty patch CYCL4
Removing empty patch CYCL5
Compacted patches:
WALL1 size:2064 start:533876
WALL2 size:2592 start:535940
WALL3 size:3840 start:538532
cyclic size:0 start:542372

--> FOAM Warning :
From function min(const UList<type>&)
in file /home/dm2/henry/OpenFOAM/OpenFOAM-1.3/src/OpenFOAM/lnInclude/FieldFunctions.C at line 362
empty field, returning zero

Why is the size of the new patch named cyclic (type cyclic) zero (see above)?

Any help would be appreciated. I have tried for 2 weeks now to import my Star mesh but it seems to be a big problem

[stefanke]

I have successfully imported my star mesh into FOAM 1.3! But some some reasons I have to use OF1.2. So I imported my star mesh into OF1.2 but now the following error (in contrast to 1.3) shows up when the solver is starting:

--> FOAM FATAL IO ERROR : cannot open file

file: /data/home/stefanke/OpenFOAM/stefanke/run/starTest/system/tetFemSolution at line 0.

From function regIOobject::readStream(const word&)
in file db/regIOobject/regIOobjectRead.C at line 68.

FOAM exiting

In OF1.3 I don't need this file! What can I do?

[hjasak]

This file is related to the tetFemMesh or tet FEM solvers - every time a tetFem mesh is created, it will look for this file. Thus, depending on what solver or utility you are using, you may or may not need this file. It's quite easy - just steal it from the tutorial directory.

If you wish to check it, try running checkMesh in 1.3 and 1.2 and it will be the same.

Hrv

[stefanke]

Hrv,

when I run checkMesh the following warning shows up (in OF1.2 and OF1.3)

--> FOAM Warning :
From function bool
...

This mesh should only be used with faceDecomp finiteElement decomposition.

But this shouldn't matter because I don use a FEM solver.

I have to stress that I use the same solver as before (dieselEngineFoam) and with OF1.3 I do not need the tetFemSolution file. All works fine!


So why does the same solver (and exactly the same case) now need this file in OF1.2?

[hjasak]

Find out which part of your code needs the tetFem mesh and why and you will be able to answer your own question. If you cannot think of a better way, run the solver from gdb and trace back the core, which will tell you exactly who, where and why needs to create the tetFem mesh, which requires the file.

Hrv

[stefanke]

Ok I can do this and I will know more details but these procuedure do not solve my problems.

It has something to do with my mesh because with a similar kiva mesh the solver (dieselEngineFoam) does not complain about a missing tetFemSolution file!

So I think the solver uses a mesh depending meshMotion solver. But is there any difference in behavoir of meshMotion between OF1.2 and OF1.3?

Do you still think it is useful to do a backtrace why the solver uses the FEM meshMotion solver?