Skip to content

Hxt major update with colors to 32 bits

Célestin Marot requested to merge hxt_update into master

This merge request fixes lot of stuffs:

  • colors are now on 32 bits
  • change from .colors to .color because all ohter fields in the HXTMesh structure were singular .node, .neigh, .flag
  • removed unnecessary stuffs in HXTMesh (hexahedra, prisms etc.)
  • fix a compilation bug (predicates needs to have different compiler options, or -march=native breaks it) and set_source_files_properties() apparently does not work in a CMake subdirectory
  • fix a bug in hxt_vertices.c where it would loop forever if bbox->max[i] = 0.0
  • the mesh size are handled differently (as explained below)

Initialization of the mesh size

Now, HXT receives as input a mesh size for each nodes, placed in the "4th coordinate". If a mesh size is invalid (<= 0.0) and the node is part of a triangle or a line, then HXT will set the mesh size to the average length of the segments that contain the node. Then, the callback is called on all nodes. It can either choose to keep the values computed by HXT or to overrides them.

New point creation

During the mesh refinement, HXT computes a new mesh size at each new nodes, as an average of the mesh sizes at the vertices of the tetrahedron in which the point is created. Then the callback is called on all new nodes. Again, it can either choose to keep the interpolated values computed by HXT or to override them.

Delaunay insertion

If a mesh size is invalid (<=0.0) during the insertion of a node into the mesh*, then HXT sets its mesh size to the average mesh size of the Delaunay cavity.

*it can happen in two cases:

  • it was not set to a valid value by the callback
  • no callback function was given, the node was not given a valid size as "4th coordinate" and is not part of a triangle or a line.

EDIT: The callback is now called with an additional array of colors (the volume IDs).

Edited by Célestin Marot

Merge request reports