Sheaves on manifolds

[mjungmath]

We implement presheaves and sheaves over manifolds. Parts that can benefit from this implementation are:

• charts
• frames
• vector bundle sections
• tensor fields
• scalar fields

We implement mix-in classes for the parents as well as for its elements, endowed with a restriction method and a _domain attribute. We use a qoset (poset) structure to benefit from digraphs which allow efficient relations between the restrictions. See also #31740, #31771 and #31680.

Depends on #31785

CC: @egourgoulhon @tscrim @tobiasdiez @mkoeppe

Component: manifolds

Branch/Commit: public/31703_sheaves @ 865d37d

Issue created by migration from https://trac.sagemath.org/ticket/31703

[mjungmath]

comment:2

See #30714 comment:10.

[mkoeppe]

comment:4

Sounds like we should add a functorial construction.

[mjungmath]

comment:5

Replying to @mkoeppe:

Sounds like we should add a functorial construction.

What do you mean?

[mkoeppe]

comment:6

... similar to what's happening in sage.categories.homsets

[mjungmath]

comment:7

I don't see how that might help us. We need something that is already compatible with the sheaf structure in the above classes.

Instead of a mix-in class, we can do that all via the category framework.

[mjungmath]

comment:8

The problem I see with the category approach is that the implementation will be probably too concrete.

[mjungmath]

comment:9

I will upload a proposal with category approach and put it under consideration.

[mjungmath]

Branch: public/31703_sheaves

[sagetrac-git]

Commit: ff599d4

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

ff599d4

Trac #31703: first attempt using category

[tobiasdiez]

comment:12

Does it make sense to keep track of the target category, i.e. sections of the presheaf over an open subset are objects of this category. Maybe as a generic parameter?

[mjungmath]

comment:13

Replying to @tobiasdiez:

Does it make sense to keep track of the target category, i.e. sections of the presheaf over an open subset are objects of this category. Maybe as a generic parameter?

What do you mean?

[mjungmath]

comment:14

But you are right. Strictly speaking, presheaves are families of section sets. The above proposal is very sloppy in that viewpoint. For now, it rather reflects something like the "category of presheaf section sets".

[mjungmath]

comment:15

I think this whole category approach was non-sense after all...

[tobiasdiez]

comment:16

What I meant is that your sections often have additional structure. For example, if you consider the presheaf $F$ of sections of a bundle of groups, then you can naturally multiply two such sections, i.e there are maps $F(U) \times F(U) \to F(U)$ for every open subset $U$ induced by the group multiplication. For example, the wedge product of differential forms can be described in such a way.

[sagetrac-git]

Changed commit from ff599d4 to 29b601a

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

29b601a

Trac #31703: first attempt

[mjungmath]

comment:18

Replying to @tobiasdiez:

What I meant is that your sections often have additional structure. For example, if you consider the presheaf $F$ of sections of a bundle of groups, then you can naturally multiply two such sections, i.e there are maps $F(U) \times F(U) \to F(U)$ for every open subset $U$ induced by the group multiplication. For example, the wedge product of differential forms can be described in such a way.

This behavior will naturally be captured by the corresponding parent of sections.

[mjungmath]

comment:19

I have uploaded another approach. Feedback is welcome! :)

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

7e2a6f5

Trac #31703: add sheaves

[sagetrac-git]

Changed commit from 29b601a to 7e2a6f5

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

939700c

Trac #31703: add some examples

[sagetrac-git]

Changed commit from 7e2a6f5 to 939700c

[mjungmath]

comment:22

This should reveal some more of the idea.

[mjungmath]

comment:31

Do we really want to use restriction graphs an extension graphs as dictionaries, or is there a better solution available?

[sagetrac-git]

Changed commit from 2c9c72b to a884da1

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

a884da1

Trac #31703: turn sheaves into functors + provide helper methods instead of concrete implementation

[mjungmath]

comment:33

@Matthias: Is that what you had in mind when speaking of functorial properties?

[sagetrac-git]

Changed commit from a884da1 to 80eba04

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

80eba04

Trac #31703: make copy, copy_from, set_restriction etc. entirely abstract

[sagetrac-git]

Changed commit from 80eba04 to d4b1d33

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

a5e0956	Trac #31703: set_restriction is presheaf property
d4b1d33	Trac #31703: update restriction graph for restrict method

[sagetrac-git]

Changed commit from d4b1d33 to b91fc16

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

b91fc16

Trac #31703: semi-concrete implementation of set_restriction

[mjungmath]

Dependencies: #31785

[mkoeppe]

comment:38

Perhaps instead of passing a lambda function to Presheaf, define subclasses such as ScalarFieldAlgebraPresheaf. Then you can replace the method scalar_field_algebra with an attribute that is an instance of this class.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

6f9081d	Trac #31703: contravariant nature of functor
865d37d	Trac #31703: add a bit of documentation

[sagetrac-git]

Changed commit from b91fc16 to 865d37d

[mjungmath]

comment:40

Replying to @mkoeppe:

Perhaps instead of passing a lambda function to Presheaf, define subclasses such as ScalarFieldAlgebraPresheaf. Then you can replace the method scalar_field_algebra with an attribute that is an instance of this class.

Things might still work fine with scalar fields. But as soon as we have tensor fields, things get more complicated. For example tensor field modules must be constructed via the manifold's method tensor_field_module because the result depends on whether the manifold is parallelizable or not, and those finished constructions must be communicated back to the manifold again.

[mjungmath]

comment:41

Replying to @mkoeppe:

Perhaps instead of passing a lambda function to Presheaf, define subclasses such as ScalarFieldAlgebraPresheaf. Then you can replace the method scalar_field_algebra with an attribute that is an instance of this class.

Replying to @mjungmath:

Things might still work fine with scalar fields. But as soon as we have tensor fields, things get more complicated. For example tensor field modules must be constructed via the manifold's method tensor_field_module because the result depends on whether the manifold is parallelizable or not, and those finished constructions must be communicated back to the manifold again.

Travis, Eric, what do you think about that?

[egourgoulhon]

comment:42

Replying to @mjungmath:

Travis, Eric, what do you think about that?

First of all, I think it's a good idea to introduce sheaves. Regarding the lambda function in Presheaf, I agree with Michael's argument. Do you plan to re-implement some scalar field features, in particular the handling of restrictions, in this ticket?

[mkoeppe]

comment:43

See also sage.schemes.toric.variety for another place where sheaves already appear in Sage

[mjungmath]

comment:45

I could use some opinion. Also in which direction this ticket shall now develop. Some foundations are already laid.