is polyhedral elements supported?

[pei-ying.hsieh]

Dear Autodesk Sim CFD experts,

I am just wondering if Autodesk Sim CFD supports polyhedral elements.  If not, is there a plan to include this in the future release? 

Pei-Ying

[Jon.Wilde]

This is a pretty simple one. CFD was built from the ground up to work on tet elements so no, we do not support polyhedrons. 

More importantly for me, why do you ask?

[pei-ying.hsieh]

Hi, Jon,

My understanding is that, Autodesk Sim CFD uses priminary Tet elements.  For quite a few cases, using polyhedral elements can cut down the number of elements, hence, reducing simulation time.

Pei-Ying

[OmkarJ]

I would add here that technically it is possible to import meshes from commercial solvers in unv/dat/nas formats

http://help.autodesk.com/view/SCDSE/2014/ENU/?guid=GUID-4F6BAD99-F771-4933-B788-3D2AE4FD4579

I remember to have tried structured mesh file created in ICEM-CFD and exported as a dat file in the past with SimCFD. I could import it and see it in the GUI, but couldn't get it to run. It was reporting something about bad elements being formed etc. However it would be interesting if there is such a functionality.

However I have thought and read a lot on it and I believe that the choice and insistance of the type of mesh, whether it is Polyhedral or hex meshes, has to be made considering many factors. Polys have more no. of neighbouring cells, meaning more sources of information available to the cell to create the gradients and this helps information propagation faster. While, having more faces gives it more flexibility to "fill" the domain and thus element count can be smaller than required for tets. Have a look at this really interesting graphic, that shows you, in 2D, how polys are space efficient than tets (both are inverse of each other) : http://www.cs.cornell.edu/home/chew/Delaunay.html

Moreover, they are less diffusive than tets, All this makes them faster to run on simple geometries, but opinion seems divided on the dividends in accuracy for real world geometries. Many of these advantages of polys have been seen in mostly FVM codes (FLUENT, Star CCM+) that are sensitive to quality of mesh and flow alignment to mesh cells. And the fact that poly has more no. of faces means stastically the flow inclination on these faces is always more orthogonal than in tets. SimCFD is FEM based solver and generally not as sensitive to mesh. Moreover, polys are notoriously difficult to evaluate for their quality, as compared to hex/tets.

Tets are easier and quicker to create and with adequate refinement in the regions of high gradients, you can reduce the diffusion they induce. Hexes/polys may be difficult/longer to create and this offsets the reduction in run-times. At the end of the day you have to figure out how much time you have at your disposal to get the final results, the level of accuracy you need, how expensive the decision you are making is and the risk you are willing to take in the results being "not-as-accurate".  

[Royce_adsk]

Hi Omkar,

That is an excellent summary. The key point that you hit on is that element type decisions do need to consider FVM and FEA.  With FVM you are modeling flux through faces, so as you add more faces you can improve the approximation/reduce the diffusion error.  With the FEM we are looking at edges along elements from node<->node so the pro/con consideration becomes different.

Interesting conversation for sure.

Checkout the FVM vs FEM discussion in the help.

[OmkarJ · Accepted solution]

Royce

This is precisely the reason why FEM codes like SimCFD, CFX are not supersensitive to meshes as compared to FVM codes like FLUENT and Star CCM+. In my experience, mesh type, quality and orthoganility mattered less for CFX as compared to FLUENT when it comes to accuracy. Amusing fact about CFX is that regardless of the mesh type - tet/hex, it creates polys as control volumes around the nodes and then calculates the fluxes, but it does not allow import of  polyhedral meshes themselves! The fact that it is a fulyl coupled solver doesn't hurt either, once it took 10 times smaller no. of iterations than FLUENT's seggregated solver, when I was comparing - though, time/iteration was of course larger because of larger matrices to solve, but then overall stability was better. Coming back to polys, I think it was back in 2004/05 when CD-ADAPCO commercially launched polys in Star-CCM+ that these elements gained traction among wider CFD community. Some even think it is a marketting gimmick, but there it is genearlyl accpted that polys are superior in FVM codes often. 

The bottomline is that every solver has a different mathematical structure and has different set of "ideal settings" for mesh quality, orthogonality, solver algorithms and discretization numerics. And this is what makes it difficult to objectively compare different CFD codes with the similar strategy. It makes sense to hence understand the strengths and weaknesses of each code separately and optimize the approach to suit its needs for a fairer comparison. 

Cheers

[marco.mueller]

just as a side note: CFX is als FVM

[OmkarJ]

True,  however the point was to differentiate it from the other FVM solvers, in that regardless of the mesh supplied, it creates polyhedral control volumes around the nodes of the original mesh. As far as I remember from what I read in the doco, the variables are stored at nodes adn the gradients are evaluated at the integration points at the center of faces, using shape functions just like in FEM codes, as against FLUENT which uses the supplied mesh, stores values at cell centers and uses numerical algorithms for gradients. Both codes use FVM but there is difference in how they calculate gradients.

So probably it is semi-FEM or semi-FVM solver 
Regards