[tomloh]

Hello everyone,

I am trying to generate a simple straight pipe using makeAxialMesh. I have a mesh that runs no problems for a 2D case, but when I try to convert using makeAxialMesh I get the following error:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Create time
Create mesh for time = 0

Using old mode. Dictionary not used
Plane of the grid: (0 0 1) (12.5 0.221403 0.5)

--> FOAM FATAL ERROR:
Patch center does not exists in mesh
Patches are
5
(
inlet
outlet
bottom
top
frontAndBack
)

From function makeAxialMesh
in file makeAxialMesh.C at line 544.

FOAM exiting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~

Can someone please help me understand this error, I'm pretty new to OpenFOAM? I'm using OF 2.1.0.

Thanks,
Tom

[gschaider]

Originally Posted by tomloh

Hello everyone,

I am trying to generate a simple straight pipe using makeAxialMesh. I have a mesh that runs no problems for a 2D case, but when I try to convert using makeAxialMesh I get the following error:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Create time
Create mesh for time = 0

Using old mode. Dictionary not used
Plane of the grid: (0 0 1) (12.5 0.221403 0.5)

--> FOAM FATAL ERROR:
Patch center does not exists in mesh
Patches are
5
(
inlet
outlet
bottom
top
frontAndBack
)

From function makeAxialMesh
in file makeAxialMesh.C at line 544.

FOAM exiting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~

Can someone please help me understand this error, I'm pretty new to OpenFOAM? I'm using OF 2.1.0.

Thanks,
Tom

Well. I think the error message is quite straightforward enough: You're specifying a patch named center as the axis (probably because it is called like that in the example http://openfoamwiki.net/index.php/Contrib_MakeAxialMesh) but there is no such patch in the mesh.

Don't know what your mesh looks like but probably you've got to specify top or bottom instead.

[tomloh]

Oh yes I solved this one, but I forgot to repost that. Such a stupid mistake.
One should always remember what they named there patches. >.>

Thanks

Tom

[rajeshkunwar]

Hi...

I have some doubts in using utility makeAxialMesh

1. Is it necssary to use collapseEdge utility for the test case given on the makeAxialMesh utility developer site???
2. After using makeAxialMesh...when I see it in paraFoam there is no unwanted nodes or edges I see. So what is the need of using collpseEdge I dont understand
3. New mesh is created for t=0.00125 in Folder 0.00125. Do I need to copy the polymesh in 0.00125 to constant folder so that the original polymesh Folder is overwritten??

Thanks
Rajesh

[gschaider]

Originally Posted by rajeshkunwar

Hi...

I have some doubts in using utility makeAxialMesh

1. Is it necssary to use collapseEdge utility for the test case given on the makeAxialMesh utility developer site???
2. After using makeAxialMesh...when I see it in paraFoam there is no unwanted nodes or edges I see. So what is the need of using collpseEdge I dont understand
3. New mesh is created for t=0.00125 in Folder 0.00125. Do I need to copy the polymesh in 0.00125 to constant folder so that the original polymesh Folder is overwritten??

Thanks
Rajesh

@1+2: collapseEdge is only needed if the axis of rotation is part of the geometry. Then a number of faces degenerate to faces of area 0 which is numerically problematic. In the example case in the SVN this is not needed, you're right. But collapseEdge doesn't do anything so that is not a problem (better safe than sorry)

@3: you're right. That is the usual undo-option of mesh-manipulation utilities in OF: write to the next timestep (and not overwritting). If you're sure that it will work you can always use the -overwrite-option. This will destroy your old mesh (you've been warned)

[rajeshkunwar]

Originally Posted by gschaider

@1+2: collapseEdge is only needed if the axis of rotation is part of the geometry. Then a number of faces degenerate to faces of area 0 which is numerically problematic. In the example case in the SVN this is not needed, you're right. But collapseEdge doesn't do anything so that is not a problem (better safe than sorry)

@3: you're right. That is the usual undo-option of mesh-manipulation utilities in OF: write to the next timestep (and not overwritting). If you're sure that it will work you can always use the -overwrite-option. This will destroy your old mesh (you've been warned)

Thank you developer for so fast reply..

Why my meshcheck is failed?????

[gschaider]

Originally Posted by rajeshkunwar

Why my meshcheck is failed?????

That is hard to tell without seeing the actual failure (of checkMesh I assume)

[rajeshkunwar]

Originally Posted by gschaider

That is hard to tell without seeing the actual failure (of checkMesh I assume)

rajesh@rajesh-OptiPlex-990:~/OpenFOAM/rajesh-2.1.1/run/axialmesh$ checkMesh
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.1.1 |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 2.1.1-221db2718bbb
Exec : checkMesh
Date : Oct 17 2012
Time : 19:03:53
Host : "rajesh-OptiPlex-990"
PID : 3604
Case : /home/rajesh/OpenFOAM/rajesh-2.1.1/run/axialmesh
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create polyMesh for time = 0

Time = 0

Mesh stats
points: 882
internal points: 0
faces: 1640
internal faces: 760
cells: 400
boundary patches: 3
point zones: 0
face zones: 0
cell zones: 0

Overall number of cells of each type:
hexahedra: 400
prisms: 0
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 0
polyhedra: 0

Checking topology...
Boundary definition OK.
Cell to face addressing OK.
Point usage OK.
Upper triangular ordering OK.
Face vertices OK.
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces ...
Patch Faces Points Surface topology
movingWall 20 42 ok (non-closed singly connected)
fixedWalls 60 122 ok (non-closed singly connected)
frontAndBack 800 882 ok (non-closed singly connected)

Checking geometry...
Overall domain bounding box (0 0 -0.005) (0.1 0.1 0.005)
Mesh (non-empty, non-wedge) directions (1 1 0)
Mesh (non-empty) directions (1 1 0)
All edges aligned with or perpendicular to non-empty directions.
Boundary openness (8.47033e-18 -8.47033e-18 -4.51751e-17) OK.
Max cell openness = 1.35525e-16 OK.
Max aspect ratio = 1 OK.
Minumum face area = 2.5e-05. Maximum face area = 5e-05. Face area magnitudes OK.
Min volume = 2.5e-07. Max volume = 2.5e-07. Total volume = 0.0001. Cell volumes OK.
Mesh non-orthogonality Max: 0 average: 0
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 1e-08 OK.
Coupled point location match (average 0) OK.

Mesh OK.

--> FOAM Warning :
From function polyMesh::readUpdateState polyMesh::readUpdate()
in file meshes/polyMesh/polyMeshIO.C at line 204
Number of patches has changed. This may have unexpected consequences. Proceed with care.
Time = 0.00125

Mesh stats
points: 882
internal points: 0
faces: 1640
internal faces: 760
cells: 400
boundary patches: 5
point zones: 0
face zones: 0
cell zones: 0

Overall number of cells of each type:
hexahedra: 400
prisms: 0
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 0
polyhedra: 0

Checking topology...
Boundary definition OK.
Cell to face addressing OK.
Point usage OK.
Upper triangular ordering OK.
Face vertices OK.
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces ...
Patch Faces Points Surface topology
movingWall 20 42 ok (non-closed singly connected)
fixedWalls 60 122 ok (non-closed singly connected)
frontAndBack 0 0 ok (empty)
frontAndBack_pos 400 441 ok (non-closed singly connected)
frontAndBack_neg 400 441 ok (non-closed singly connected)

Checking geometry...
Overall domain bounding box (0 0 -0.00436194) (0.1 0.1 0.00436194)
Mesh (non-empty, non-wedge) directions (1 1 0)
Mesh (non-empty) directions (1 1 1)
Wedge frontAndBack_pos with angle 2.49766 degrees
***Wedge patch frontAndBack_pos not planar. Point (0.005 0.06 0.00174478) is not in patch plane by 3.9962e-08 meter.
Boundary openness (-5.50709e-18 -1.26955e-16 6.44505e-17) OK.
Max cell openness = 1.94187e-16 OK.
Max aspect ratio = 2 OK.
***Zero or negative face area detected. Minimum area: 0
<<Writing 14 zero area faces to set zeroAreaFaces
Min volume = 5.45242e-09. Max volume = 2.12645e-07. Total volume = 4.38088e-05. Cell volumes OK.
Mesh non-orthogonality Max: 76.3515 average: 8.65283
*Number of severely non-orthogonal faces: 6.
Non-orthogonality check OK.
<<Writing 6 non-orthogonal faces to set nonOrthoFaces
***Error in face pyramids: 20 faces are incorrectly oriented.
<<Writing 20 faces with incorrect orientation to set wrongOrientedFaces
***Max skewness = 4.57585, 3 highly skew faces detected which may impair the quality of the results
<<Writing 3 skew faces to set skewFaces
Coupled point location match (average 0) OK.

Failed 4 mesh checks.

Time = 0.0025

Mesh stats
points: 861
internal points: 0
faces: 1620
internal faces: 760
cells: 400
boundary patches: 5
point zones: 0
face zones: 0
cell zones: 0

Overall number of cells of each type:
hexahedra: 380
prisms: 20
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 0
polyhedra: 0

Checking topology...
Boundary definition OK.
Cell to face addressing OK.
Point usage OK.
Upper triangular ordering OK.
Face vertices OK.
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces ...
Patch Faces Points Surface topology
movingWall 0 0 ok (empty)
fixedWalls 60 120 ok (non-closed singly connected)
frontAndBack 0 0 ok (empty)
frontAndBack_pos 400 441 ok (non-closed singly connected)
frontAndBack_neg 400 441 ok (non-closed singly connected)

Checking geometry...
Overall domain bounding box (0 0 -0.00436194) (0.1 0.1 0.00436194)
Mesh (non-empty, non-wedge) directions (1 1 0)
Mesh (non-empty) directions (1 1 1)
Wedge frontAndBack_pos with angle 2.49766 degrees
***Wedge patch frontAndBack_pos not planar. Point (0.005 0.06 0.00174478) is not in patch plane by 3.9962e-08 meter.
Boundary openness (-5.50222e-18 -1.26955e-16 6.44505e-17) OK.
Max cell openness = 1.35525e-16 OK.
Max aspect ratio = 2 OK.
Minumum face area = 1.09049e-06. Maximum face area = 4.36194e-05. Face area magnitudes OK.
Min volume = 5.45242e-09. Max volume = 2.12645e-07. Total volume = 4.36194e-05. Cell volumes OK.
Mesh non-orthogonality Max: 0 average: 0
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 0.330801 OK.
Coupled point location match (average 0) OK.

Failed 1 mesh checks.

[gschaider]

Originally Posted by rajeshkunwar

Time = 0.0025

Mesh stats
points: 861
internal points: 0
faces: 1620
internal faces: 760
cells: 400
boundary patches: 5
point zones: 0
face zones: 0
cell zones: 0

Overall number of cells of each type:
hexahedra: 380
prisms: 20
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 0
polyhedra: 0

Checking topology...
Boundary definition OK.
Cell to face addressing OK.
Point usage OK.
Upper triangular ordering OK.
Face vertices OK.
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces ...
Patch Faces Points Surface topology
movingWall 0 0 ok (empty)
fixedWalls 60 120 ok (non-closed singly connected)
frontAndBack 0 0 ok (empty)
frontAndBack_pos 400 441 ok (non-closed singly connected)
frontAndBack_neg 400 441 ok (non-closed singly connected)

Checking geometry...
Overall domain bounding box (0 0 -0.00436194) (0.1 0.1 0.00436194)
Mesh (non-empty, non-wedge) directions (1 1 0)
Mesh (non-empty) directions (1 1 1)
Wedge frontAndBack_pos with angle 2.49766 degrees
***Wedge patch frontAndBack_pos not planar. Point (0.005 0.06 0.00174478) is not in patch plane by 3.9962e-08 meter.
Boundary openness (-5.50222e-18 -1.26955e-16 6.44505e-17) OK.
Max cell openness = 1.35525e-16 OK.
Max aspect ratio = 2 OK.
Minumum face area = 1.09049e-06. Maximum face area = 4.36194e-05. Face area magnitudes OK.
Min volume = 5.45242e-09. Max volume = 2.12645e-07. Total volume = 4.36194e-05. Cell volumes OK.
Mesh non-orthogonality Max: 0 average: 0
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 0.330801 OK.
Coupled point location match (average 0) OK.

Failed 1 mesh checks.

OK. You're checking 3 meshes here:
- the original planar mesh
- the axial mesh (with zero-size faces on the axis)
- the collapsed mesh

You're interested only in the last one here. Seems like your problem here is the writePrecision. I guess it is set to 6 in your controlDict. set it to a bigger value (12 or so) and retry from start. Don't forget to reset it to the old value afterwards (unless you have enough disc-space)

[immortality]

Hi Bernhard
how writePrecision can help?why should return it to 6? I have set it to 16,does it mean better accuracy?
my solution has suspicious results too,what may be the cause?

[gschaider]

Originally Posted by immortality

Hi Bernhard
how writePrecision can help?

Because mesh manipulations higher precision requirements ("Are these two points the same")

Originally Posted by immortality

why should return it to 6?

Because it wastes diskspace

Originally Posted by immortality

I have set it to 16,does it mean better accuracy?

No. Only more accurately WRITTEN data (for calculation it is the same)

Originally Posted by immortality

my solution has suspicious results too,what may be the cause?

No idea.

[immortality]

No. Only more accurately WRITTEN data (for calculation it is the same)

if numbers written in less significant numbers it seems the equations use them have more round off error,do the numbers participate in calculations differ from the numbers written on the disc?(the solver doesn't use written data with lower significant numbers?)
I mean how a number like .032 and .032456789 may lead to same results by solvers?

[gschaider]

Originally Posted by immortality

if numbers written in less significant numbers it seems the equations use them have more round off error,do the numbers participate in calculations differ from the numbers written on the disc?(the solver doesn't use written data with lower significant numbers?)
I mean how a number like .032 and .032456789 may lead to same results by solvers?

writePrecision is only relevant if you restart from that data. And if you only need it for postProcessing 6 digits are sufficient (unless you claim to be able to measure the quantity with an accuarcy of more than 6 significant(!) digits)

[immortality]

in schemes like crankNicolson that uses data of current and previous time folders the accuracy of written data seems be important,they are not in your opinion at all?
you mean that the numbers written on disc don't included in calculations?

[gschaider]

Originally Posted by immortality

in schemes like crankNicolson that uses data of current and previous time folders the accuracy of written data seems be important,they are not in your opinion at all?
you mean that the numbers written on disc don't included in calculations?

During regular calculations writePrecision is irrelevant because data from memory is used.

End of discussion

[immortality]

I think you mean data are read from RAM,right?
OK,if its so writePrecision is only usable for postProcessing and showing results.
thanks.