Follow

Polyhedral and Hex Core Display Issues

Polyhedrals in EnSight are more expensive in terms of memory than regular cells.  Only export cells as polyhedral if they are truly polyhedrals and cannot be represented as regular cells.

With regards to Polyhedral and Hex Core models (STAR-CCM+, Converge, Fluent HexCore, et. al.), there are a few options available to users of EnSight to improve the default display and calculations. Polyhedrals (or n-faced cells) are elements with some number of faces greater than 6, or more than 4 nodes defining a face (an nsided face). HexCore grids are visually similar to hexa grids, but there are hanging nodes where cell size changes occur. 

The methodology for storing and operating on polyhedrals has evolved over time in EnSight, attempting to reduce memory usage while still maintaining robustness. As such, the discussion below is organized based on this evolution over time in EnSight.

EnSight 9.0.x users:
In EnSight 9.0.x, the routines handling polyhedrals were fairly simple, tolerant of poorly defined elements.  The algorithm added a new centroid to each cell and remeshed each polyhedral using internal tetrahedral elements and internal n-sided faces.  This used large amounts of memory for polyhedrals (2GB per million cells). A clip of this geometry showed only the clip of the internal tetrahedron cells, and the original poly geometry was obscured.  Generally this was robust with some algorithmic problems for poorly formed or concave polyhedrals.

EnSight 9.1.x users:
In EnSight 9.1.x, a convex clipper routine (ear clipper) was implemented to improve memory usage (1.5GB per million cells), at the cost of robustness.  Poorly formed polyhedrals or concave polyhedrals would leave holes and/or gaps in the mesh. Clips would still show the clip of the internal tetrahedrons (not the polyhedral outline) and would show gaps and holes where the mesh had gaps and holes.
As a fallback, users can revert to the EnSight 9.0 centroidal tetrahedron methodology.  Simply set an environmental variable : setenv ENSIGHT_NFACED_METHOD 0  to revert to the EnSight 9.0 method of handling polyhedrals and hex core grids and then you must restart EnSight after setting this variable.

EnSight 9.2.x users:
EnSight retained the 9.1 more memory efficient convex clipper routine (ear clipper) but added an option for clips to show only the outline of the polyhedral elements, and not the internal tetrahedrons.  To use this, do a File>Command and in the command entry window of EnSight, type test: clip_nfaced_on . After issuing this command, users should generate a new clip through the domain. The new clip will intersect through the polyhedral elements where possible, and only revert back to clipping the tessellated grid when it encounters poorly defined elements.
As a fallback, users can revert to the EnSight 9.0 centroidal tetrahedron methodology.  Simply set an environmental variable : setenv ENSIGHT_NFACED_METHOD 0  to revert to the EnSight 9.0 method of handling polyhedrals and hex core grids and then you must restart EnSight after setting this variable.
EnSight 10.x users:
EnSight 10 has added a new option to better handle poorly formed or concave polyhedrals and has made the three methods of handling polyhedrals (center node tets, convex ear clipper, or the new concave mesh) available as a choice in the EnSight preferences.  As such, we have eliminated the need to type commands into the command window or to set environmenal variables.  Further, clipped polyhedral elements now only show the clipped polyhedral and not the tetrahedron internal elements.
The default is Convex, which is a good tradeoff of speed and memory against robustness.  If you see holes in your mesh, then you should switch to Centroid if you have plenty of memory and are not doing volumetric calculations or to Concave if you want to conserve memory or you are doing calculations that involve mesh volume.  The Concave method is slower than the other two algorithms.  Note that a change from one methodology to another will require a complete update and may take some time, similar to a timestep change with a changing connectivity mesh.
Under the Edit -- > Preferences -- > Data dialog, there is an "N-faced decomposition" pull down menu. The options are as follows:
"Centroid" -- > This is equivalent to ENSIGHT_NFACED_METHOD = 0, and uses the EnSight 9.0 method for operating with nfaced polyhedrals.
"Convex"  -- > (default) This is equivalent to the EnSight 9.1/EnSight 9.2 ear clipper/convex routine. (orENSIGHT_NFACED_METHOD = 1)
"Concave"  -- > This is a new routine for EnSight 10, which tessellates concave elements more accurately than the Convex method. It uses a similar amount of memory, but requires additional time for loading the data. This should improve the handling of concave or crescent moon shaped polyhedral elements.
See the EnSight 10 User manual for more details.

FLUENT HEX-CORE Users, EnSight 9.2.x onward:
As discussed at the beginning of this writing, the best option is to convert polyhedrals that can be represented as regular cells when exported from your solver.  Failing that, sometimes EnSight has options to convert these cells using its readers.  For example, Fluent users with substantial numbers of hex core elements, can use EnSight's native Fluent .cas/.dat reader instead of reading the .encas file exported from Fluent. EnSight's Direct .cas/.dat reader has a option to convert these hex-core elements (which are flagged as polyhedral by Fluent) back into hexahedral regular elements before passing them up to EnSight. The option can be found in the Reader Dialog under the "Format" tab as "Poly to Regular Cell" toggle.  When this is toggled on, the reader converts these polyhedrals to regular hex elements (6 faces, 8 nodes, 4 nodes per face). This can greatly reduce the memory overhead (from 1.5GB per million to 200 MB per million cells) as well as improve the rendering by using native hex elements. 
Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments