Matrix sharps, matrix flats, subdivision, and link

[lukem12345]

This PR implements subdivision as a data migration, matrix versions of the sharp and flat operators, an alternative weighting scheme for the sharp operator, and the star, closed star, and link operators from S68 of Munkres' Elementary Algebraic Topology.

Some of these changes may need to get shifted to a different branch. In particular, subdivision cannot yet automatically compute barycenters of simplices until the attrMigr branch of Catlab is merged. Relatedly, refactoring the DualComplex schemas as a data migration that "remembers" e.g. which triangle a supporting dual triangle came from also depends on this functionality.

The star, closed star, and link operators were implemented as higher-level helper functions which will become more useful as 3D operators are becoming supported. This (not-Hodge) star essentially recursively computes cofaces, which is a common pattern in this codebase. e.g. grabbing all tetrahedra around a vertex v is simply star(v).

While developing the matrix version of the sharp operator, it was noted that the sharp of an EForm generated by a constant form would generate a primal vector field with the correct direction, but of incorrect magnitude. In particular, vectors with few neighbors would be too small, and those with many neighbors would be too large. By replacing the weighting denominator in Eq. 5.8.1 from Hirani with | star v | instead of | sigma n |, we successfully recover the original field (up to floating point error). This alternate discrete sharp operator can be selected via dispatching with AltPPSharp. Further, a sharp operator from Desbrun can be selected via DesbrunSharp.

As implemented at time of writing, the matrix-flat multiplied by a vector X of SVectors will return a vector of length 1 SArrays. When X is wrapped in DualVectorField(), this result is automatically reinterpreted to a vector of floats. This fix is a little unusual, but I am not sure how to structure the flat matrix to avoid this.

[lukem12345]

Due to scheduling, this PR consists of a few disparate features:

• Subdivision of non-embedded 1D delta sets w/o point attributes
• Star, Closed Star, and Link operators from Munkres. a.k.a. "topological helper functions"
• Matrix version of sharp
• Matrix version of flat
• Alternate weighting scheme for flat

All these features have tests.

When considering which features to merge, we should note:

• Only 1D subdivision-as-data-migration is supported. Due to outstanding Catlab PR #823, barycentric and other automatic weighting of the point attribute is blocked. Although the current subdivide functions pass tests, perhaps this feature should live on a different branch for the time being.
• Star, Closed Star, and Link are implemented for vertex input only. I believe that the current implementation is helpful as-is, however.
• See my previous comment for the return type of the matrix version of flat
• The Desbrun weighting scheme is rather poor, and I don't imagine it would be used in practice. However, it may still be nice to offer this for completeness' sake.
• Likewise, I believe that the Hirani weighting scheme is inferior to the "Alternate" weighting scheme due to behavior mentioned in my previous comment. It may be best to change the default weighting scheme to "Alternate."

[lukem12345]

Todo:

• [] Use QR decomposition in the new sharp operator

[jpfairbanks]

I think you are probably better off with GMRES or PCG because the QR decomp will be dense.

[lukem12345]

Oh, the QR decomp is just for the tiny (3×3 in R3, 3×2 in R2) matrices. For each triangle T, I compute and split this tiny matrix into its rows, and place each row in the corresponding position in the (num-triangles × num-edges) sparse matrix. Maybe QR decomposition is not what I want here, since the application of the entire operation is still just sparse matrix multiplication.

…

On Sat, Feb 17, 2024, 12:28 PM James ***@***.***> wrote: I think you are probably better off with GMRES or PCG because the QR decomp will be dense. — Reply to this email directly, view it on GitHub <#59 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQYHBYINJO6PUT3DOUZAC53YUDSCJAVCNFSM6AAAAAAZ2N2GFOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJQGI3DEOJTGY> . You are receiving this because you were assigned.Message ID: ***@***.***>

[olynch]

I've left some comments. The comments with 🟢 should be addressed in a future PR, the comments with 🔴 should be addressed in this PR.