Polyhedral mesh generation
 

Hi,

Does anyone know if the current version OpenFOAM 1.3 has the capability of polyhedral mesh generation such that 2d cells has 6 faces or more.

The following link shows what I mean, but I dont know to what extend this link is up to date:

http://www.mfix.org/mwiki/index.php/Mesh_Handling%2C_Generation_and_Conversion#P olyhedral_Mesh_Generation

If not ready in the current version, does anyone know an open-source alternative until this blockMesh utility is made ready to handle this.

Regards, Frank

I thought that polyDualMesh mi
 

I thought that polyDualMesh might have helped with creating one from a tet mesh.
Haven't tried it myself though.
Let us know how you fare.

/mark

Hi all, I tried to convert
 

Hi all,

I tried to convert a tet mesh into a polyhedral mesh using polyDualMesh. This seems to work.

However, visualising this mesh seems to be challenging. I do not know a open source tool ou there that is capable in visualising these polyhedral meshes, am I right? Or is there an opportunity?

Hi, Convert to VTK (foamToV
 

Hi,

Convert to VTK (foamToVTK) and use latest paraview binaries 3.2.1, available at http://www.paraview.org/New/download.html

Regards

//Eric

Hi, Can someone explain exa
 

Hi,

Can someone explain exactly what polyDualMesh do? What will be the benefits of going from Tet to polyhedral mesh in this case (by combining Tets) except for fewer elements (but will have the same number of faces, correct)?

Thanks!

Pei

Not exactly! You reduce the nu
 

Not exactly! You reduce the number of cells with approximately 80% and the number of faces only with 20% which gives you a lot smaller dataset to carry around. In the same time you have almost the same accuracy since it primarily depends on the number of faces. You'll have an increase in typical dX with some 20-50% but your degrees of freedom in the mesh are almost the same.

//Eric

Thanks Erik, I will try. Is pa
 

Thanks Erik, I will try. Is paraview now able to handle Polyhedral? Is this also true for foamTovtk from OF 1.4.1?

BastiL



Hi,

Convert to VTK (foamToVTK) and use latest paraview binaries 3.2.1, available at http://www.paraview.org/New/download.html

Regards

//Eric

I get the following using foam
 

I get the following using foamToVTK of OF 1.4.1:

#0 Foam::error::printStack(Foam:http://www.cfd-online.com/OpenFOAM_D...part/proud.gifstream&) in "/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::sigSegv::sigSegvHandler(int) in "/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 ?? in "/lib/libc.so.6"
#3 Foam::polyMesh::readUpdate() in "/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#4 Foam::fvMesh::readUpdate() in "/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libfiniteVolume.so"
#5 Foam::vtkMesh::readUpdate() in "/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linux64GccDPOpt/foamToVTK"
#6 main in "/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linux64GccDPOpt/foamToVTK"
#7 __libc_start_main in "/lib/libc.so.6"
#8 Foam::regIOobject::readIfModified() in "/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linux64GccDPOpt/foamToVTK"
segmentation fault

No VTK is finally created

Hmm... strange, never had any
 

Hmm... strange, never had any problems with VTK conversion. Try -latestTime switch if you have something incompatible in the other time directories. Make sure you don't have any fields in the time directory you're trying to convert to VTK that where not created from defaults or through running mapFields.

//Eric

Here's an image of a hex/polyH
 

Here's an image of a hex/polyHedral mesh as seen in paraview 3.3.0

http://www.cfd-online.com/OpenFOAM_D...ges/1/6040.gif

Ooops... that picture didn't c
 

Ooops... that picture didn't come out very well, let's try this one

http://www.cfd-online.com/OpenFOAM_D...ges/1/6042.gif

I am sorry the picture is litt
 

I am sorry the picture is little small I can not see much... Paraview 3.3.0 is a internal development version as it can not be downloaded so far, right? However 3.2.1 should be ok?

I tried to reconstruct what is happening: I have a tetra-mesh with prism-layers. Checkmesh reports no errors. Afterwards using polyDualMesh (feature angle 90deg, do not know what this is good for?) i get warnings:

--> FOAM Warning :
From function calcDual
in file polyDualMesh.C at line 1140
Incorrect orientation on internal edge:463769(0.341353 -0.196117 0.301625)(0.341353 -0.196956 0.302462)

I get this for different edges... Afterwards CheckMesh crashes with a segmentation fault. Seems like there is a problem....

Hi Eric, thanks for the lar
 

Hi Eric,

thanks for the larger picture - your meshes look extremly nice. ehat tools do you use for generating theses hybrid hexa-poly meshes? Any ideas about my conversation problems?

BastiL

Try something smaller than 90
 

Try something smaller than 90 deg feature angle since it represents the maximum angle between two neighboring surface normals on a surface without corners. That is, the mesh will consider your surface shape a corner if the angel is larger than this value. I typically use something between 45 and 80 depending on the tet mesh resolution on highly curved surfaces. This might be the root of your problem. Looking at my picture the curved surface in the middle would (wrongly) be treated as a corner if the feature angle was set to some 30 deg. Here I used 75 degrees, but anything abowe 45 usually works. In your case virtually no corners are treated as such.

I often use Gambit or T-grid for tet/hex + tet-prism b-layer mesh generation and then convert the mesh using polyDualMesh. The result is in the picture.

Good luck!

//Eric

Btw, the latest paraview is do
 

Btw, the latest paraview is downloadable from the same site using the svn repos found at the end of the page. Compilation is really easy, just follow the instructions supplied with the distro.

//Eric

Hi Eric, thanks so much for
 

Hi Eric,

thanks so much for your great help and explanation of feaure angle. I tried different feature angles now and still have trouble with it. I found out first warnings different from the others:

Create time

Create polyMesh for time = 0

Feature:60
minCos :0.5

--> 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
--> FOAM Warning :
From function calcDual
in file polyDualMesh.C at line 1025
Incorrect orientation on boundary edge:40913(0.0449507 -0.177984 0.283496)(0.0485079 -0.180224 0.285736)

... more edge warnings ....

--> FOAM Warning :
From function calcDual
in file polyDualMesh.C at line 1140
Incorrect orientation on internal edge:463772(0.333385 -0.196118 0.301625)(0.333385 -0.196957 0.302462)
nInternalFaces:964348
nFaces:1004682
nCells:190892
nFaces:1004682 patchSizes:
11
(
172
176
5329
7507
7322
2802
4224
1362
1715
7990
1735
)
patchStarts:
11
(
964348
964520
964696
970025
977532
984854
987656
991880
993242
994957
1002947
)

Writing dualMesh to 1
End

As mentioned before: CheckMesh reports no errors on the tet-Mesh but stops with a segmentation fault while checking the poly mesh.

Seems to me that your original
 

Seems to me that your original mesh is wrong somehow .
How did you generate it?
What does checkMesh tell you about the original mesh?
Are there any strange geometrical features in your mesh, like zero thickness walls, interior faces etc.

//Eric

Hi Eric, its a tetrahedral
 

Hi Eric,

its a tetrahedral mesh with prism layers generated in GridPro. It runs well and CheckMesh thinks its ok:

Create polyMesh for time = constant

Time = constant

Mesh stats
points: 190892
edges: 964348
faces: 1412547
internal faces: 1336849
cells: 639090
boundary patches: 11
point zones: 0
face zones: 0
cell zones: 2

Number of cells of each type:
hexahedra: 0
prisms: 193036
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 446054
polyhedra: 0

Checking topology...
Boundary definition OK.
Point usage OK.
Upper triangular ordering OK.
Topological cell zip-up check OK.
Face vertices OK.
Face-face connectivity OK.
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces ...
Patch Faces Points Surface
wt-inlet 296 172 ok (not multiply connected)
wt-outlet 304 176 ok (not multiply connected)
wt-walls 10119 5231 ok (not multiply connected)
a.forebody 14611 7417 ok (not multiply connected)
a.side 14275 7322 ok (not multiply connected)
a.top 5362 2802 ok (not multiply connected)
a.bot 8138 4224 ok (not multiply connected)
a.baklite 2586 1362 ok (not multiply connected)
a.rear 3287 1715 ok (not multiply connected)
wt-sym 15332 7990 ok (not multiply connected)
wt-sym-quad:22 1388 1735 ok (not multiply connected)

Checking geometry...
Domain bounding box: (-1 -1 -0.05) (4 5.0354e-07 1.24999)
Boundary openness (1.57876e-17 1.28209e-15 6.74944e-17) OK.
Max cell openness = 3.60863e-16 OK.
Max aspect ratio = 11.0021 OK.
Minumum face area = 4.52742e-07. Maximum face area = 0.0133246. Face area magnitudes OK.
Min volume = 1.71943e-10. Max volume = 0.000443001. Total volume = 6.44374. Cell volumes OK.
Mesh non-orthogonality Max: 67.352 average: 17.3122
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 2.39857 OK.
Min/max edge length = 0.000557864 0.206334 OK.
All angles in faces OK.
Face flatness (1 = flat, 0 = butterfly) : average = 0.999968 min = 0.998242
All face flatness OK.

Mesh OK.

End

It has no special features like internal walls.

BastiL

Haven't seen this problem befo
 

Haven't seen this problem before with polyDualMesh. Can you ship the tet mesh so I can try it over here?

(m dot janssens at opencfd.co.uk)

Hi Matthijs, I sent you an
 

Hi Matthijs,

I sent you an email. Hopefully it is not to large.

BastiL

I would like to have a look at
 

I would like to have a look at it also, allthough I don't think I have much to contribute, now that you've got professional help ;-)

eric.lillberg@afcosult.com

/Eric

wrong e-mail, should be eri
 

wrong e-mail, should be

eric.lillberg@afconsult.com

Problem was the cellZones. The
 

Problem was the cellZones. They are not mapped so they had illegal content after the conversion. It converts ok if I remove the cellZones file.

It is not going to be trivial to map the cell zones. I assume you want to have interface inbetween the cellZones to remain the same when converting so those internal faces would have to be treated like boundary faces.

You are right Mattijs. So at t
 

You are right Mattijs. So at the moment only possiblity is to delete cellzones?

BastiL

Hi guys. Another question.
 

Hi guys.

Another question. Did anyone perform a flow simulation with a moving polyMesh. In the past I just tried icoDyMFoam on a polyMesh, but I did not get any convergence, at least much much slower compared to block structured hex-mesh.

Frank

Hello guys, I also have a pro
 

Hello guys,
I also have a problem (most likely a newbie one): although the polyDualMesh does the job, I almost get those nice looking polyhedra:
http://www.cfd-online.com/OpenFOAM_D...ges/1/6110.pnghttp://www.cfd-online.com/OpenFOAM_D...ges/1/6111.png

I converted those tetrahedra into polyhedra using:
polyDualMesh ./ testMRF 89
and then I used
foamToVTK ./ testMRF -time 0
followed by paraview-3.2.1.
Is there something I missed?

Dragos

Hi Dragos, The easiest way is
 

Hi Dragos,
The easiest way is to add -allPatches to your foamToVTK command line
foamToVTK . testMRF -time 0 -allPatches
and read allPatches*.vtk.

Takuya

Indeed it works great! http:/
 

Indeed it works great!
http://www.cfd-online.com/OpenFOAM_D...ges/1/6116.png
Thanks Takuya!
...if I only had the courage to look with paraview at some of the patches that it creates by default...
Though, I'm curious now: what do I see in the above picture, from the previous message, if not the polyhedral cells? Actually I can give a part of the answer: there are the polyhedra but with some extra lines. What are those lines?

Dragos

What you were seeing in the pr
 

What you were seeing in the previous post was the polyhedra decomposer in foamToVTK working perfectly http://www.cfd-online.com/OpenFOAM_D...part/happy.gif

foamToVTK decomposes a polyhedron into tetrahedra and pyramids since currently VTK can't handle polyhedra perfctly as is (which is what the native reader for ParaView3 I posted a while ago also still suffers from).

Takuya

Matthijs, Eric, Bastil, I h
 

Matthijs, Eric, Bastil,

I have exactly the same problem as Bastil described in december. I have a tet mesh which checkMesh says is ok, nil errors nor warnings.
Converting it using polyDualMesh, trying different aspect angles, gives warnings regarding edge orientations. The utility concludes its work anyway but than using checkMesh, the new mesh contains errors and warnings. The error I see returning everytime is wrongOrientedFaces. But also warnings regarding warpedFaces and concaveFaces return regularly. I tried this sequence with different models and within each model with different meshes. Note that I have no cellZones or faceZones.
So in short: checkMesh says my original tet mesh is perfect. Nevertheless polyDualMesh is not succesfull in converting it in a polyhedral mesh.

Tet meshes have been generated with gid and exported using unv format.

Why I all need this:
I am trying to model sailing ships using VOF interFoam. The water-air interface is of great interest to me as a ship designer.
In order to gain experience I played with the damBreak tutorial. I remodeled the geometry and generated the mesh with the tools I would like to use for the ship-problems as well. Also here I find the same problems, however I finally manage to make the solution run to an end with the polyhedral mesh. The tet mesh gives unstable solutions. To my knowledge I have tried all possible solver settings and scheme options:
-max Co, as low as 0.1
-cGamma, Gamma subcycles upto 4
-with and without momentumpredictors
-nCorrectors 1-4
-nonOrtho correctors, upto 10
-tolerances, upto E-9
-PCG and GAMG pressure solvers, different preconditioners, different U solvers.

and more.
Making the step to my ship models, I cant run any solution successful. After a few tenths of runtime seconds, some high velocity spikes appear, whatever I try.
I tried potentialFoam, which returns a velocityfield without unstabilities. However, the velocityfield does not seem very regularor smooth.
Velocity spikes appear mostly on boundaries, just above the water interface. On the model, different boundary conditions apply: pressureOutlet and symmetryplane. I also tried extrapolatedOutlet. All the same.
I suspect my mesh quality to be the showstopper, though I read a couple of threads where Henry states that, though hex meshes are preferred, even on tet meshes interFoam should work.
Other possible causes (hope someone can comment):
-my boat is 16 m long and sails at 5m/s. This gives Re of order e-6 in the air. Should I use turbulence models? I hope not, as I am only interested in the water.

Probably the best solution is to make hex meshes. However presently I have no tools at hand which can do this.

Concluding:
-Instability in VOF solution;
-Suspect mesh quality/mesh type (tet);
-Improper conversion of my (perfect?) tet mesh into polyhedral.

In fact the second half of my questions belong to another place of this forum. Apologize for that.

Any comments will be greatly appreciated,

Mark

Hello All, Any comments abo
 

Hello All,

Any comments about the polyDualMesh issue? (having a pure tet mesh which checkMesh says is perfect, which fails with polyDualMesh. Giving error about wrong edge orientation and checkmesh gives errors about face orientations).
Any help would be greatly appreciated.

Mark

In order for polyDualMesh to w
 

In order for polyDualMesh to work, your tet mesh must be Dealuney. If it was made using marching front, it will probably fail.

Hrv

Hi, I've also been having tr
 

Hi,
I've also been having trouble with polyDualMesh and edge/face orientations.

Generally it always happens for at the edges of 'concave' patch boundaries.

the image below shows a simple case, with the incorrect faces highlighted (using checkMesh).

http://www.cfd-online.com/OpenFOAM_D...ges/1/7560.png

The mesh was generated with netgen using the delauney scheme. If the truncated corner is removed polyDualMesh works fine (ie a normal cube).

So far this has meant I haven't been able to use polyhedral meshes for anything useful (apart from making pictures of polyhedral meshes). Any advice would be greatly appreciated.

Cheers
Andrew

Hrv, Thanks for your reply. T
 

Hrv,
Thanks for your reply. The meshing tools I have available do not tell me Dealuney or marching front (?). However I assume that will be the root cause of the problem. I read on the forum that you state it WILL be possible to have stable solutions with interFoam and tet meshes. I am struggling now for weeks on some boat problem with a tet mesh. I am now able to run it quiet far but sooner or later some velocity spike appears, mainly just above the water-air interface, only on the boundaries. I have varied the boundary conditions. On the free patches they are p=0 and zerogradient for U and gamma. This must be ok.
Solvers I varied, with mostly only slight succes. Now I am more focussing on schemes. I found that upwind on div(rho*phi,U) was a huge improvement in stability. However after some longer time a velocity spike appeared again.
Now I am testing with limiters and linearUpwind. I will attach my current fvSchemes. Hopefully someone can comment on it.
I will also add some snapshots of my case.
http://www.cfd-online.com/OpenFOAM_D...hment_icon.gif fvSchemes
http://www.cfd-online.com/OpenFOAM_D...hment_icon.gif SnapshotU.pdf.tar.gz
http://www.cfd-online.com/OpenFOAM_D...hment_icon.gif Snapshotgamma.pdf.tar.gz

Thanks for any comments,

Mark

Update: I used gmsh to genera
 

Update:
I used gmsh to generate delauney meshes, nil errors/warnings with checkmesh. PolyDualMesh runs on these meshes but checkmesh than returns with errors as indicated by Andrew King.
Using the mesh anyway for solving gives unstable results very soon.
Besides that: I hoped that I could use refineMesh on these polyHedral meshes. However this introduces even more errors in the mesh. I thought that refineMesh shuold work on polyHedral. It does not in my case. All kinds of skew faces, wrong orientations, concave faces etc etc appear. Am I doing something wrong or is my mesh just one step too challenging?

Brgds,

Mark

Use of polyDualMesh on a 'good
 

Use of polyDualMesh on a 'good' tet mesh (by checkMesh's standard) generates the same errors for me as Mark and Bastil.

Has anyone else encountered difficulties? Has anyone found any work around for this? Is this possibly a bug in polyDualMesh?

Chris

Hi Chris, I have never had
 

Hi Chris,

I have never had reliable success with polyDualMesh, except for domains that have very simple boundary surfaces. (I was not surprised to see that Andrew King's case was ok with a single cube, but failed when the corner was truncated.)

I am not sure if this was a bug, or lack of functionality for the cases that are of interest to me.

Kevin

Thanks for the reply Kevin.
 

Thanks for the reply Kevin.

Including myself that's four people in this thread that seem to agree that polyDualMesh only works for simple cases.

I was interested in comparing the setup, run-times, memory usage and results of a tet mesh and it polyhedral dual. Perhaps I will try on something simpler than I have been testing with.

For the dual mesh to work, the
 

For the dual mesh to work, the underlying tet mesh must be Dealuney. If this is so, the algorithm will work fine; otherwise it will fail.

It would be nice to have a check which would make sure that the tet mesh is actually Delauney before starting. Chris, do you happen to know a tool like this, or would we have to write it from scratch?

Hrv

Hrv, I don't know of any 'D
 

Hrv,

I don't know of any 'Delaunay checkers'. I believe the tet mesher in Gridgen/Pointwise is Delaunay based but I don't know how strict it maintains it.

With regard to my failure, I have to admit it is probably not the most appropriate mesh to try polyDualMesh with (~300 surfaces and ~2mi tets with cell sizes vary several orders of magnitude). I am going to try it on a more 'intermediate' type problem this week.

Chris