analysisTools.LocallyFuseAssignment() gives bogus results

[kb1dds]

The Problem is that cells outside of the open set can still flow values into the open set (on its boundary) that make the various problems not independent.

This should actually be a phantom problem if a value is specified with optimization=False on the boundary, because then we don't actually have a choice for a different value there.

I tried to resolve this using Views of the Sheaf, but that seems to give strange results.

• Worst case is to deep copy the sheaf on the open set, and run it on its own
• Best case is to fix the Views... because cells outside the View should not get referenced -- and therefore not flow any values forward
• Might be able to add another knob on how the consistency radius gets computed

[Kuo-TingKai]

"Cells outside of the open set can still flow values into the open set (on its boundary)", can you explain more about this statement, thanks!

[kb1dds]

Let's say you have a sheaf diagram like so: A <- B -> C. If you populate an assignment taking values at A, B and C, and run LocallyFuseAssignment on the open set {A,C} (noticing carefully that this indeed an open set!), the values on A and C should remain the same. This is because the value at B, while it can "flow along restrictions" to A and C, is outside the open set specified.

Here's the issue: PySheaf currently has you run *FuseAssignment methods by first propagating the assignment with MaximallyExtendCell (yielding so called ExtendedAssignments) which will bring the value from B into A and C. Then, you run the LocallFuseAssignment function, which now is going to see the value from B even if you use a View to restrict to only the cells in the open set.

So my suggested strategies work as follows:

1. You can first build a deep copy of only the part of the sheaf in the open set. This forces you to rebuild everything including the assignment, and when you run MaximallyExtendCell, there simply are no cells outside the open set to cause issues.
2. By "fixing" Views, what I mean is that we track the sources of each ExtendedAssignment, and then filter these when the View is constructed.
3. Rather than fixing the View generally, it might be possible to patch the consistency radius calculation when a local consistency radius is desired. This could be done because the components of the vector of assignment values fed to the optimizer come in a definite order.

Option 1 definitely works in the current version of the code. This is what I do now if I need a local consistency radius minimization. Option 2 seems the most preferable long-term, and Option 3 is basically a hack.