Hi, everybody, COuld anybody tell me in what software I can generate Polyhedral Meshes???

Fluent 6.3.26 and Tgrid 4.0.16 Are able to read all those kind of meshes in 3D???

Thanks

it seems like only Star-CD has that option

Hi,

I'm not sure about TGrid but in Fluent 6.3.16 you can only convert unstructured cells into polyhedra. This option is under Grid->Polyhedra->Convert Domain.

What you need to understand is that the way Fluent creates polyhedral cells is that it uses an unstructured tet mesh as a template to map the new mesh. Therefore is is highly unlikely that there is a polyhedral cell generator, it is more of a converter.

What this implies is that Fluent needs enough memory to store the original tet mesh and then have enough space to map onto the new poly mesh. Quite often Fluent cannot complete the conversion because of lack of memory (although it doesn't give a reason in the TUI). If you are using meshes of say 2 million cells or less then a gig of RAM should be adequate. However, be prepared to reduce your cell count if it wont work.

As far as I know, CD adapco (Star-CD) developed polyhedra around 2005 and so if you can get hold of that software, you might as well. If you only have Fluent then just create a mesh with as many structured hex cells as possible (these are better than poly cells for accuracy), finish off with tet cells if you really need them and then use fluent to convert these (fluent onlt converts tet to poly).

Be careful though, the convergence may be much quicker with poly cells by virtue of the reduced face and cell count but often the convergence level is higher. Therefore always check with verification and validation that your model is correct, or in the right ballpark.

Carlos.

Well...

In general FLUENT and STAR (CD >=v4/ccm+) do the same. they convert Tet-Meshes to Polys. In Fluent you have to bring a tet-mesh in FLUENT and convert it, STAR does all in one step but general procedure is the same. In my eyes for complex geometries avoid it it makes problems with retaining features or quality. Try more hex-dominant meshes instead.

Regards

Fluent's polyhedral generation algorithm sucks. My first implementation of multigrid, i used agglomoration based on vertex, that is if the mesh is all tetras , the first level grid is nothing but polyhedral. I remember my algorithm used to take around 5 - 10 % percent of time fluent takes in polyhedral generation, and it was memory efficient also. I have read meshes of around 8-10 millions on 2GB ram windows machine. And it all worked fine. I think they shall ask me how to add an efficient version of this polyhedral generation. (at least how to manage memory for it). Their version is too time consuming and fails quite often.

I agree with zxaar overall because despite the many theoretical advantages of polyhedral cells, the process does fail in Fluent quite often. Its probably not that well implemented and since there are very few pages on it in the user guide I don't think they are shouting about it just yet. I think it'll be a lot better in later versions of the program so mabye we should be patient! However, in the meantime it can be frustrating.

Carlos.

Hello guys,

It seems that the polyhedral cell generation process is a big mistery for some of the Fluent users, so I will try to explain it a bit (I a not 100 percent sure, but I think this is pretty much what's happening):

- in the grid conversion step, Fluent does this: 1. creates face and cell centroids; 2. splits the faces using centroids and nodes and creates new interior faces using cell centroids and face nodes and centroids; 3. creates new volumes (cells) with the centroid placed at a former cell node; 4. deletes the old volumes (cells) and the excess faces (some of the old cell faces, currently interior faces for the new cells).

Up to step 3, the memory requirements constantly increase, and eventually the memory needed to hold the original and the dual mesh is approx. double (if the original mesh fits into 4 GB, then at the end of step 3, approx. 7-7.5 GB are needed). I agree that this is quite a lot, and a better algorithm can be imagined, but the next Fluent version has already done that (v12.xx beta has a much improved conversion process in terms of memory requirements, and also time).

- in the grid optimization step, Fluent tries to minimize the number of faces, edges and nodes for the converted mesh.

This process is quite smooth for the interior cells, the only difficult regions being the pyramid transition layers between a hexahedral and a tetrahedral region. At such region, the number of faces cannot be optimized due to the restriction that hexahedral cells ar not to be touched (as for this aspect, anyone can see that the attempt to convert a hexahedral cell will simply result into a hexahedral cell...so why even bother? And let's not forget about the prismatic layers, where we wouldn't want Fluent to do any modifications in direction normal to the wall, wouldn't we?). As for the wall regions, the optimization is not performed if certain conditions are not met, especially if the angle between adiacent faces is greater than a specified value (default 30 degrees). So if one needs to keep certain features of the geometry after convertion and optimization, then all one needs to do is to refine the triangular mesh locally so that local angles are < 30 deg (which is very easy in my opinion, there are curvature size functions for that in Gambit), or simply use quadrilateral grids on these specific regions (if possible).

Now, I have used the polyhedral grids since the beta version of Fluent 6.3, and never, I mean NEVER had a failed conversion!! That could be due to several reasons, but I think that the main reasons are the fact that I never use a grid which does not meet certain quality levels, and that when I create a grid specifically for converting it to polyhedra, I always take a lot of care for the sensitive regions (hybrid B-L, hexa-to-tetra layers, etc.). I also want to mention something which seems that not many know: the conversion process in Fluent CAN USE VIRTUAL MEMORY!! That is, if the available RAM memory is exceeded, than it will use the virtual memory of the OS. So, if you know that you do not have enough RAM, simply ensure that you have at least 1.5 x RAM in virtual memory! Of course, in this case the process will slow down significantly, but not unacceptably (for example, a grid of 10 million cells, which does barely fit into 8 GB of RAM, will need up to 9 more GB of virtual memory, and complete the conversion and optimization in about 2-2.5 hours; I think that anyone can accept that, we are talking about a 10 million cells mesh after all!)

As for the accuracy issue, I have made extensive tests before using this kind of mesh for my projects, and the conclusion is clear: a converted polyhedral mesh is ALWAYS more accurate than the original mesh, even with 3-4 times less cells!! How much accurate? Well, I have made direct comparisons of pure hexahedral and hybrid polyhedral meshes (that is, polyhedral meshes obtained from unstructured meshes with prismatic B-L), and the accuracy was practically identical for similar number of cells (you should also know that the hexahedral meshes were perfect, no skewness, the test cases were simple geometries).

In my opininon, the polyhedral meshes are the future of CFD, and even if for the moment, the creation algorithms are not perfect, I strongly recommend you to start using them for their accuracy at least!

I hope that this was useful for everyone.

All the best,

Razvan

Hi Razvan,

Thats a comprehensive evaluation of polyhedral cells you just gave! I agree with most of what you said but I would urge caution with what you said about the accuracy.

I am due to submit a paper later in the year from some results I have found which shows the opposite effect. I havn't compared pure tet and converted poly meshes because this isn't the norm in CFD. I have performed verification on 3 different hybrid grids and find that the tet mesh is FAR more consistent.

The hybrid grid consists manily of hex cells since I am modelling flow around a vehicle inside a wind tunnel with large ducts front and rear. What I am finding in the verification process is that with the realizable k-e model the poly cells are showing reduced error but for the spalart allmaras model and the sst k-w model, the errors are up to 3 times bigger! When looking at a plot of grid independence it is clear that the tet mesh is much more consistent.

Now thats verification, I also have experimental data for the flow and the spalart allmaras model is far superior for this scenario. Yet I can't rely on the poly version of results for this model because the errors are so large and the result is effectively grid DEPENDENT!

My objective view of polyhedral cells is that for external flows, in conjunction with as many hex cells as possible, polyhedral cells are NOT as accurate as tet cells. This seems illogical at first because surely there will be less numerical diffusion with polyhedral cells! However, without being swayed by their potential, I sat down and did a full and fair comparison with an open mind to the results.

Polyhedral cells may well perform better than tet cells for simple shapes, but for non-trivial geometry of external flow, I can catagorically say (and my paper will confirm this) that polyhedral cells are NOT the ONLY way forward. Yes they could well be used in the future for verifying some designs and they may be better at predicting internal flow (which I don't look at), however it is my firm belief that it is a myth that polyhedral cells are better than tet cells. If you look at how few pages are dedicated to them in the user guide, perhaps Fluent know this also! Surely they would be shoving them down our throats if poly cells were all of a sudden the best way to perform robust, accurate CFD.

And just one more point, the JCB Dieselmax land speed record car with took the diesel powered record in 2006 was designed entirely with Fluent version 6.3. They did a comparison like mine and found a difference in drag of 6%. This is a significant result since the flow around such a vehicle is mainly attached! Incidentally then chose to use the original tet mesh because they had more faith in the results.

Carlos.

Folks, I'm not a numericist. I use codes. I dont write them. But I know many who do.

If you are going to use Polyhedra. You have to have differencing schemes which are formulated from the begining to look at N neighbors.

I suspect that the Fluent schemes (which lets face it are limited to beging with) dont deal quite as well with Polys as they should. Star CCM was writen from scratch to deal with Polys as was Open Foam.

Getting less accuracy from more neighbors is clearly an indication of an implementation problem, specific to the software in question.

We all need to be careful of statements such as polys are better/worse, differencing scheme A is better than B etc, as the implementation of those things will vary from code to code.

So perhaps we can say (for now), polys may not result in increased accuracy for some problems in a specific code.

Just my two cents - Andy

Well, I read all you write, and I'm gonna tell you my experience. Yesterday, I run I simple duct in 3D with a TET mesh and with a POLY mesh, I ran it with next conditions:

v = 2 m/s, k-e model, T = 40 C,

The results showed that TET Mesh is agree with experimental data, POLY mesh overpredict temperature velocity and pressure.

In what cases POLY mesh is able to be used??

Diego

Folks, Perhaps you missed my point. Lets say that polymeshes as implemented in FLUENT for the problem Diego tried to solve dont work as well as Tets. Perhaps for another problem or another code they may work better.

It is the blanket statements I think we should avoid.

Diego, Out of curiosity have you talked to Fluent about this? Have you tried other solver options and/or differencing schemes?

Thanks - Andy R

No, I have not talked with Fluent, that´s a good point. I did not try with other solver. I'll try it.

Thanks

P.D. I did a couple of test and I got excellent results for a Drop pressure, check it:

DP with TET MESH = 3247 Pa DP with POL MESH = 3300 Pa DP with Experimental data = 3600 Pa

I'll be trying with more cases and experimental data to test poly mesh.

The issue is not that Fluent's implementation is faulty. If it is faulty then so are OpenFOAM's and StarCCM+. Becauase they are all same. Solver descretisize the equation based on face. So it takes the face and set up the equations. So the cell can have n number of faces, this n could be 4 , 6 or a large number. The issue is not implementation but polyhedrals themselves.

It is extremelly unlikely that the details of the implementations are the same. I know for a fact that one set of developers does not code things up exactly the same as another. A lot goes more goes on than simply "coding up" something from a paper.

My 2 cents -Andy R

Well I agree with you and disagree too. The descretisation part pressure based segregated solver in StarCCM+ , OpenFOAM and Fluent is same (there is one very minute difference in equation but does not make much difference just that what they do is more stable). So how convection term is descretisize is same, diffusion term is descretisized the same way.

This I know because I have read the manuals of: StarCCM+, Fluent, Jasak's thesis, CFX5.X StarCD etc etc. And I have spent lots of time finding out how they are working. So here I disagree with you. (converged solution should be same because of this).

The part I agree with you is, how to set up and solve this system of equation which is not mentioned in documentation could be different. For example one can use Gauss Siedel solver but one could reaarange the equations in the order they are solved changing the way convergence is achieved. ect etc. These type of things could be different.

But the setting up of transport equation is same and in context of polyhedrals, the descretisation is done based on face (loop on all faces), so this part is exactly same.

[USU_CFDer]

After reading you analysis of polyhedral cells I have been very curious to read your paper. So far I have not been able to find it. Has it been published as of yet? This goes to anyone else as well, if you have found his paper can you guide me to it.

Thanks,

[Aravind M]

hi friends , does the quality of solution effects if the solution is solved in polyhedra mesh by convertion in solution tab in ANSYS fluent.

[karachun]

Yes, usually conversion to polyhedra increases solution stability. There are two main causes.
1. Polyhedral conversion simply increases element quality.
2. Polyhedral cells have more faces than tetra. Thus some bad, nonphysical, values from one face are more faster "smeared" in the element.
On the other hand polyhedral faces may be highly warped.
Usually hexa mesh is better than polyhedral mesh and polyhedral mesh is better than tetrahedral mesh.