v2306: New and improved pre-processing
snappyHexMesh automatically balances the mesh when refining cells in parallel, an operation that can become expensive for high core counts. New controls in the castellatedMeshControls section of the snappyHexMeshDict input file can be used to tune the process:
- maxCellUnbalance : [optional] absolute unbalance start trigger. Used to avoid balancing in the first refinement iterations when the cell count is small. The trigger value is used to skip balancing:
- if on any processor : number of new added cells <= maxCellUnbalance
- if on any processor : (new cell count of proc - ideal cell count) <= maxCellUnbalance
- balanceAtEnd : [optional] force balancing after the mesh is completely refined since the maxCellUnbalance entry might cause the mesh to be unbalanced.
- (existing) maxLoadUnbalance : allow some unbalance; expressed as a fraction of ideal balance.
Large speed-ups in the castellation phase have been realised for large core counts using these additional controls. Note that the snapping and layer addition phases are unaffected.
checkMesh automatically filters out reporting of processor patches; however, their properties can be useful. In this release processor patch filtering is limited to parallel running only.
As an example, running in serial:
checkMesh -case processor0 -allTopology -allGeometry
Checking patch topology for multiply connected surfaces... Patch Faces Points Surface topology Bounding box front 2275 2399 ok (non-closed singly connected) (-0.572 -1 0.007621454194) (-0.17456 1 0.02497405934) .. procBoundary0to1 101 204 ok (non-closed singly connected) (-0.19184 -1 -0.008375915288) (-0.17456 1 0.008375915288) ".*" 4796 4798 ok (closed singly connected) (-0.572 -1 -0.02497405934) (-0.17456 1 0.02497405934)
Note the reporting of individual processor boundaries, which are also included in the overall boundary faces entry (".*"). When running in parallel, processor patches are excluded from the list and overall boundary faces, as in v2212.