Does anybody else have problems when attempting to use polyhedral meshes?

I am currently modelling vehicle aerodynamics and having real trouble converting my domain to polyedra. Initially I tried to convert a hybrid mesh, which should have left the structured cells alone and converted the tetrahedra to polyhedra but I got the following message: 'The Fluent process could not be started'.

I then tried converting a simple unstructured mesh and it worked fine! Convregence was remarkably low (continuity less than 10^-14), each iteration was much faster and the simulation time was roughly 15 times faster.

When I try converting an unstructured only mesh to polyhedra again for a core complex problem it fails again. Does anybody know why? The Fluent manual is useless as it only devotes about 3 pages to the technique. I'm wondering if there is a link between these failures and highly skewed cells. Any Ideas?

Thanks for your help,

Carlos.

This one is for all of you out there:

USE POLYHEDRAL MESHES, PEOPLE!

Now, getting back to our problem. I remember from your previous post that the mesh you are trying to convert to polyhedra is about 6 milion elements. First of all, you must take care that you have enough memory (phisical+virtual) to run the convertion process. From my personal experience, a 6 milion hybrid grid needs about 10-12 GigaBytes of memory (remember, take virtual memory too), but a 6 milion pure tetrahedral grid will need much less, maybe only 6-8 GigaBytes. And the conversion and optimization will be much faster. So, if you will try to convert a 6 milion elements hybrid grid and you do not have all that memory, the process will CERTAINLY fail.

Some workarounds would be to minimise the interface between tetrahedral and hexahedral mesh, this is a very difficult region for the solver to convert, and it usually generates about the same or even more cells than there were before (only in these regions). Also be very careful about the aspect ratio of the quadrilateral faces when generating the initial tetrahedral mesh, because a too high aspect ratio for these cells could make the convertion process to fail.

Another thing that you must be careful about is high skewness cells. And I mean over 0.95. 0.7-0.8 is not very high and if you can obtain a max 0.8 skewness tetrahedral mesh in a complex domain, that's excellent! An effective way to eliminate these very high skewness cells before starting the convertion process, is to use swap/smooth option in Fluent. It does a very good job, but it is really effective only if the high skewness cell is not on the boundary (the situation is even worse if it is on a tetrahedral-hexahedral interface...). But again if the max skew is less then 0.9, then you don't have to worry about it.

And one last thing: very high growth ratios are damaging when trying to convert to polyhedra. Do not use a growth ratio higher than 1.33 (ideally 1.2) when constructing the original mesh.

BUT! I have to warn you that if you had difficulties to converge on the original mesh, the polyhedral will only make things worse!

Let me explain: your original thetrahedral mesh is the most dissipative mesh possible. So when dealing with unsteady phenomena like vortex shedding behind a car, a coarse tetrahedral mesh is likely to damp those unsteady phenomena and obtain a stationary solution. This is even more easily achieved when using highly dissipative turbulence models like standard k-e. But, when the mesh is highly refined and you use a low dissipative turbulence model like RSM, even a tetrahedral mesh will not be able to damp the unsteadyness of the flow. Also, when using a high quality, high density mesh, with low dissipation, like an orthogonal hexahedral mesh, even highly dissipative turbulence models will not get you a stationary solution.

The polyhedral mesh is a low dissipative mesh. That of course is true if the initial tetrahedral mesh was well constructed. But generally, it is less disipative than the original mesh. I have made tests, and found that a good polyhedral mesh with lower element count than a completely orthogonal structured mesh, can give almost identical results!

To make your problem converge you have two ways:

- convert the mesh to polyhedra using a better equipped computer (if that is an issue currently), and switch to unsteady solver formulation;

- if that is not possible due to computer resources, then you can only lower the element count on your initial hybrid mesh, convert it to polyhedra, and use second-order discretisation ONLY for momentum; all turbulence-related equations MUST be only first-order if you want a chance to stabilise the flow!

I hope this is enough for the moment. If you have any other questions, please ask.

All the best, Razvan

Hi Razvan,

What a great help you have been - certain aspects of CFD (namely Fluent) now seem much clearer so thank you very much for that. However, such a detailed response has opened up a few questions I would like to ask.

Firstly I am using a 50 processor machine with 100GB or RAM for my computations which is pretty good for my purposes. I am practically unlimited in the computational power available for the actual number crunching, its the mesh generation causing problems. Unfortunately I have to use GAMBIT on a single processor which has 4GB or RAM. Now I have produced a hybrid mesh of 13.4M elements with this but I'm not sure how much virtual memory was used in that. Am I correct in assuming from what you have told me that it is possible to generate a mesh using xGB of RAM but you need much more RAM to convert to polyhedra?

Having seen some of the meshes used on F1 cars, I will probably stay away from hybrid meshes and go for pure polyhedra. I actaully created some pure tetrahedral meshes to convert to polyhedra. Small ones convert without problem, a 2.2M cell volume converts easily (although it takes FOREVER, 1/2 hour) but a 5.5M cells volume fails with the message 'Fluent process could not be started'. Now I do have access to a 16GB processor which means I may be able to convert a larger mesh but obviously I am limited in the number of cells I can use now. I was hoping to use TGrid to use prismatic boundary layers around my vehicle and then to convert the remaining tets to polys.

Also, I never use growth rates in my meshes of greater than 1.05, I figure that gradual changes are better. I understand that the numerical diffusion in a mesh is highly diffusive, particularly if cells are badly skewed and you use more and more cells. But I didn't realise how the different turbulence models varied so much. I always knew that the k-e was the most robust model out there but thats because of the inherent simplifications within its core.

I will try stabilising the flow as you said by making the turbulence model first order. However, surely the accuracy of the solution will be poor? I always thought that a pure second order solution would only be found if ALL the transport equations were 2nd order. Is that true?

You mention that I should switch to the unsteady formulation but the experimental data I have is time averaged and so I assumed that with CFD steady-state is always more likely to give better results than simply time averaging a transient solution.

Once again thanks for your advice, I am half way through my PhD and this help from you is getting my brain thinking in different ways. You might just be helping me succeed! I'm currently writing my second paper so if I can get these things to work then you're sure to be in my acknowledgements for the paper It would be great to continue this conversation and does anybody else have any opinion on polyhedral meshes? Razvan is correct, they are the way to go and frankly their performance is breathtaking. Its just a matter of time before they take over the CFD scene in the same way unstructured meshes did in the mid 1990's.

Best wishes,

Carlos.

Hi Carlos,

What can I say, computing resources don't seem to be a problem for you. Although, I am curious, is that a supercomputer (like Cray for example), or a cluster of workstations? This is an important information, because I really don't know how Fluent works on a supercomputer, or how would that influence a mesh conversion process. I always did my convertions using serial solver, I don't know if they can be done in parallel solver, but I surely wouldn't recommend that! Because I suspect that partion interfaces would be another problem to overcome, and if you brake your mesh into many partitions before convertion... I really cannot say if that would be a succesful operation.

Anyway, my advice is to only use serial solver for this job. And even if you had a supercomputer at your disposal, I recommend you to use a normal workstation instead. That remains true even if you had a cluster. Let me tell you how I work. I have a specific workstation for this job, with 4 Opteron 2,4GHz processors and 8 GB of RAM (of course, 16 or 32 GB of RAM would have been better, but what can I do?). The number of processors is irrelelvant, because only one is actually used. But the memory size is very relevant. The biggest mesh I ever tried to convert was a 6.5 mil. elements mesh. It took around 15 GB of memory (8 GB physical memory, the rest virtual memory on the HDDs) and about 90 min. Usually I convert 2-3 mil. elements meshes, which don't take more than 5-6 GB of RAM and 15 min. I also noticed that hybrid meshes containing hexahedral cells will always take more to convert than those having only prismatic boundary layers, at the same number of elements.

If I were in your place, I would do this:

- take the geometry of the car and import it into Gambit;

- construct only ground face and the longitudinal symmetry face, split the geometry in half, save the real geometry into a separate .dbs, and then go to virtual geometry merging all the unnecessary faces on the car's surface;

- mesh the car and the ground+symmetry faces with triangular mesh mostly (where not possible, like surfaces with very high curvature, quadrilateral mesh is much better adapted, with lower element count (for example, leading edge of a wing));

- export this surface mesh to TGrid, and construct (only!) the boundary layer there (maybe a 6-7 layers wall-function boundary layer mesh with 1.1 growth ratio would be enough for most cases, the last cell having H approx. half the base edge L);

- export the boundary layer mesh from TGrid (simply using Write GUI command) into xxx.msh format;

- open Gambit and load the real geometry .dbs, delete all car faces and then import xxx.msh file with Import/Mesh GUI command (specify TGrid as source, 3D mesh, 100deg as feature angle); this way you will end-up with only the boundary layer 3D mesh (the symmetry and ground faces will not be imported!);

- construct a virtual volume around the car, at a max. one L/W/H away in the corresponding directions;

- construct the rest of the domain using virtual volumes also;

- attach B-L mesh to the ground, taking care not to intersect the underside of the car;

- mesh the volume around the car using size functions to control the growth (1.1 ratio is more than enough, 1.05 is exaggerated);

- mesh the rest of the volumes using Cooper scheme;

- export the mesh to Fluent (5-6 mil elements total);

- swap/smooth the mesh;

- convert to polyhedra (a 3 times reduction of number of elements is to be expected, so the final mesh should have no more than 1.8-2.2 mil. elements).

Now, if I would have such computational resources as you do, I'd definitely go for a DES simulation. Maybe SST-kw based DES. The computational time would not be very much longer than a RSM unsteady simulation, although you need to consider smaller time steps. But the results would be significantly better, trust me. Especially if calculating moments is important. Drag or lift forces could be computed accurately enough using RSM, but it would have to be an unsteady simulation. So if you should make such effort anyway, why not aiming just a little bit higher?

But if you really want only a steady simulation, I think that the only way to do it is this:

- turbulence model: Realizable-ke;

- discretisation: PRESTO for pressure, 2nd order for momentum, 1st order all turbulence equations; after obtaining convergence, you could try to switch turbulence to 2nd order, and if that holds, switch momentum to MUSCL (you should see real improvement with this scheme, but only if it does not de-stabilise the solution...).

I guarantee you that the difference between 1st order turbulence and 2nd order turbulence will be minimal. You will see.

To make sure that you have a true steady solution, monitor drag and/or lift coefficients. If they go flat, then that's it (be sure to zoom in a little...)!

I think this is enough for now. Try everything that I wrote here, and then we will see what to do next. By the way, I would be happy to help you more directly with the meshing process, if that is not too much trouble for you, of course.

All the best, Razvan