Matset layout type recognition makes faulty assumptions

[JustinPrivitera]

Here in AddMatSets()

ascent/src/libs/ascent/runtimes/ascent_vtkh_data_adapter.cpp

Line 3043 in f67dc0b

VTKHDataAdapter::AddMatSets(const std::string &matset_name,

We handle three cases for matset layout types:

ascent/src/libs/ascent/runtimes/ascent_vtkh_data_adapter.cpp

Lines 3128 to 3131 in f67dc0b

	// --------------------------------------------------------------------
	// Case 1: "sparse_by_element" / material_map
	// --------------------------------------------------------------------
	if (n_matset.has_child("material_map"))

ascent/src/libs/ascent/runtimes/ascent_vtkh_data_adapter.cpp

Lines 3224 to 3227 in f67dc0b

	// --------------------------------------------------------------------
	// Case 2: "sparse_by_material" (element_ids)
	// --------------------------------------------------------------------
	else if (n_matset.has_child("element_ids"))

ascent/src/libs/ascent/runtimes/ascent_vtkh_data_adapter.cpp

Lines 3318 to 3321 in f67dc0b

	// --------------------------------------------------------------------
	// Case 3: "full" matset
	// --------------------------------------------------------------------
	else

We are not recognizing the cases properly. There are 4 cases:

• multi-buffer element-dominant ("full" case)
• multi-buffer material-dominant ("sparse by material" case)
• uni-buffer element-dominant ("sparse by element" case)
• uni-buffer material-dominant (unsupported but valid case)

All cases may include a material map; it is required for the uni-buffer cases. So checking for the existence of a material map to determine if we are in the uni-buffer element-dominant "sparse by element" case will lead to false positives.

Both material-dominant cases include element_ids, so checking for the existence of the element_ids is not going to always yield the multi-buffer material-dominant "sparse by material" case as the code assumes.

The way to determine if you are multi-buffer or uni-buffer is

conduit::blueprint::mesh::matset::is_multi_buffer();
conduit::blueprint::mesh::matset::is_uni_buffer();
// these are mutually exclusive states

The way to determine if you are element-dominant or material-dominant is

conduit::blueprint::mesh::matset::is_element_dominant();
conduit::blueprint::mesh::matset::is_material_dominant();
// these are mutually exclusive states

We also provide conversion routines in Conduit for moving between all the layout types.

We should audit the ascent code base to see if there is anywhere else where we are making assumptions about material set layouts.

I need to rewrite the conduit material set documentation to clear up the ambiguity, plus there is incorrect information in the current docs. The venn blueprint mesh example is not sufficient for demonstrating the various cases.

I am happy to work on this if need be; feel free to assign me to the ticket. Otherwise I can assist as needed.