Breaking equivalent items

One of the conditions for "items" to be considered "independent" is that they different VariableFillPattern types.

https://github.com/LLNL/SAMRAI/blob/develop/source/SAMRAI/xfer/RefineClasses.cpp#L392

 equivalent &= (!data1.d_var_fill_pattern ==
                  !data2.d_var_fill_pattern);
   if (equivalent && data1.d_var_fill_pattern) {
      auto& d1 = *(data1.d_var_fill_pattern);
      auto& d2 = *(data2.d_var_fill_pattern);
      equivalent &= (typeid(d1) == typeid(d2));
   }

Multiple source/dest/scratch sets can be registered to a single RefineAlgorithm and be non equivalent in that regard.
Refine items will be stored in the RefineClasses as non equivalent.

However, when creating the internal patch level during schedule execution, the VariableFillPattern that may have been provided by the user is replaced by a BoxGeometryVariableFillPattern to fill the entire temporary patch data.

here : https://github.com/LLNL/SAMRAI/blob/develop/source/SAMRAI/xfer/RefineSchedule.cpp#L996

  for (int nd = 0; nd < num_refine_items; ++nd) {
         RefineClasses::Data item = d_refine_classes->getRefineItem(nd);
         item.d_var_fill_pattern = bg_fill_pattern;
         coarse_schedule_refine_classes->insertEquivalenceClassItem(item);
      }

While I understand that in that internal context the entire PatchData needs to be filled, replacing the user VariableFillPattern has the side effect to now treat all registered variables as equivalent.

Contrary to SAMRAI that encodes the geometry with the type of PatchData, we have a single PatchData override for all geometries that are rather handled in a third party object. As a result, we have a single BoxGeometry, and a single kind of Overlap, Variable etc. all delegating geometrical details to that other object.

The internal replacement of the user VariableFillPattern by the BoxGeometryVariableFillPattern therefore results in the overlap being calculated by the geometry of the first registered item, which in our case is wrong for all others...

I think we somehow abuse the VariableFillPattern trick but that is the only way we found to register several items to the algorithm and not having only the geometry of the first used.

Start by reading the equivalence logic in source/SAMRAI/xfer/RefineClasses.cpp around line 392 and the internal item replacement in source/SAMRAI/xfer/RefineSchedule.cpp around line 996. Reproduce a schedule with multiple registered items and verify that internal schedule construction does not make distinct VariableFillPattern geometries equivalent or calculate overlaps using only the first item’s geometry.