Opened 16 months ago

# Sheaves on manifolds

Reported by: Owned by: gh-mjungmath major sage-9.7 manifolds egourgoulhon, tscrim, gh-tobiasdiez, mkoeppe N/A public/31703_sheaves 865d37d67e3b2a82b669fb2a818d05f05facc32f #31785

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.

### comment:1 Changed 16 months ago by gh-mjungmath

• Description modified (diff)

### comment:3 Changed 15 months ago by gh-mjungmath

• Description modified (diff)

### comment:4 follow-up: ↓ 5 Changed 15 months ago by mkoeppe

Sounds like we should add a functorial construction.

### comment:5 in reply to: ↑ 4 Changed 15 months ago by gh-mjungmath

Sounds like we should add a functorial construction.

What do you mean?

### comment:6 Changed 15 months ago by mkoeppe

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

### comment:7 Changed 15 months ago by gh-mjungmath

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.

### comment:8 Changed 15 months ago by gh-mjungmath

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

### comment:9 Changed 15 months ago by gh-mjungmath

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

### comment:10 Changed 15 months ago by gh-mjungmath

• Branch set to public/31703_sheaves

### comment:11 Changed 15 months ago by git

• Commit set to ff599d42f5b9146a921269a6fa345bd11023782f

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

 ​ff599d4 Trac #31703: first attempt using category

### comment:12 follow-up: ↓ 13 Changed 15 months ago by gh-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?

### comment:13 in reply to: ↑ 12 Changed 15 months ago by gh-mjungmath

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?

### comment:14 Changed 15 months ago by gh-mjungmath

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".

Last edited 15 months ago by gh-mjungmath (previous) (diff)

### comment:15 Changed 15 months ago by gh-mjungmath

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

### comment:16 follow-up: ↓ 18 Changed 15 months ago by gh-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.

Last edited 15 months ago by gh-tobiasdiez (previous) (diff)

### comment:17 Changed 15 months ago by git

• Commit changed from ff599d42f5b9146a921269a6fa345bd11023782f to 29b601a6cb979dfc96f7d964de76b89e5df76dfe

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

 ​29b601a Trac #31703: first attempt

### comment:18 in reply to: ↑ 16 Changed 15 months ago by gh-mjungmath

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.

### comment:19 Changed 15 months ago by gh-mjungmath

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

### comment:20 Changed 15 months ago by git

• Commit changed from 29b601a6cb979dfc96f7d964de76b89e5df76dfe to 7e2a6f51eb8be17d3bcbbdd4ec40d99e1c3c3e79

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

 ​7e2a6f5 Trac #31703: add sheaves

### comment:21 Changed 15 months ago by git

• Commit changed from 7e2a6f51eb8be17d3bcbbdd4ec40d99e1c3c3e79 to 939700c344f3699ad123d2e15ebbeb2f354bf4c5

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

 ​939700c Trac #31703: add some examples

### comment:22 Changed 15 months ago by gh-mjungmath

This should reveal some more of the idea.

### comment:23 Changed 15 months ago by gh-mjungmath

_repr_ is probably not optimal, but at this stage I don't know how to do better.

### comment:24 Changed 15 months ago by mkoeppe

I think you will want to make Presheaf a subclass of Parent. PresheafSection would be its element class.

### comment:25 Changed 15 months ago by gh-mjungmath

In fact, PresheafSection shall be an element of a particular section set. For example: the (pre)sheaf of scalar fields is a family that assigns to each open subset the scalar field algebra on that open subset. Its elements, namely scalar fields, are the sections of the (pre)sheaf.

Thus, I don't think that a parent-element construction is what we want here, no?

### comment:26 Changed 15 months ago by gh-mjungmath

For the gluing property we need concrete 'empty' sections we can endow with restrictions. But those sections cannot be provided by the parent directly since the element constructor always wants an input (otherwise it returns the zero element). Using the element class is not helpful either, because the sheaf does not know the input signature.

Any ideas how to elegantly circumvent this? Everything that comes into my mind is rather complicated.

### comment:27 Changed 15 months ago by git

• Commit changed from 939700c344f3699ad123d2e15ebbeb2f354bf4c5 to 061bda56881cef45ced093f42c32e002ab33a563

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

 ​061bda5 Trac #31703: concatenate

### comment:28 Changed 15 months ago by git

• Commit changed from 061bda56881cef45ced093f42c32e002ab33a563 to 53e4430154e6834df9db8b9f39386e06bcce1eab

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

 ​53e4430 Trac #31703: copy restriction code from tensorfield.py

### comment:29 Changed 15 months ago by gh-mjungmath

To circumvent the issue stated above, I delegated the constructions to an abstract method for now where the concrete implementation can take care of this. Though there are a lot of code snippets that fit better into this sheaf implementation because otherwise they would repeat. For example, copy shares a lot of common code.

Last edited 15 months ago by gh-mjungmath (previous) (diff)

### comment:30 Changed 15 months ago by git

• Commit changed from 53e4430154e6834df9db8b9f39386e06bcce1eab to 2c9c72bd818cfefbf294710d1b8bdcfba0c8d555

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

 ​2c9c72b Trac #31703: extension graph dict

### comment:31 Changed 15 months ago by gh-mjungmath

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

### comment:32 Changed 15 months ago by git

• Commit changed from 2c9c72bd818cfefbf294710d1b8bdcfba0c8d555 to a884da1edced4b426beb4477412dbda6a1306a16

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

### comment:33 Changed 15 months ago by gh-mjungmath

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

### comment:34 Changed 15 months ago by git

• Commit changed from a884da1edced4b426beb4477412dbda6a1306a16 to 80eba041c57d8a422b704aad3cfc49cd6ddefc0a

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

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

### comment:35 Changed 15 months ago by git

• Commit changed from 80eba041c57d8a422b704aad3cfc49cd6ddefc0a to d4b1d331731981df6e63c889e96b25c0412ced8e

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

### comment:36 Changed 15 months ago by git

• Commit changed from d4b1d331731981df6e63c889e96b25c0412ced8e to b91fc1661d2b01d16ae5085e86893a0a7965d2df

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

 ​b91fc16 Trac #31703: semi-concrete implementation of set_restriction

### comment:37 Changed 15 months ago by gh-mjungmath

• Dependencies set to #31785

### comment:38 follow-up: ↓ 40 Changed 15 months ago by 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.

### comment:39 Changed 15 months ago by git

• Commit changed from b91fc1661d2b01d16ae5085e86893a0a7965d2df to 865d37d67e3b2a82b669fb2a818d05f05facc32f

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

### comment:40 in reply to: ↑ 38 ; follow-up: ↓ 41 Changed 15 months ago by gh-mjungmath

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.

Last edited 15 months ago by gh-mjungmath (previous) (diff)

### comment:41 in reply to: ↑ 40 ; follow-up: ↓ 42 Changed 14 months ago by gh-mjungmath

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.

Travis, Eric, what do you think about that?

### comment:42 in reply to: ↑ 41 Changed 14 months ago by egourgoulhon

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?

### comment:43 Changed 14 months ago by mkoeppe

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

### comment:44 Changed 13 months ago by mkoeppe

• Milestone changed from sage-9.4 to sage-9.5

### comment:45 Changed 13 months ago by gh-mjungmath

• Status changed from new to needs_info

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

### comment:46 Changed 8 months ago by mkoeppe

• Milestone changed from sage-9.5 to sage-9.6

### comment:47 Changed 5 months ago by mkoeppe

• Milestone changed from sage-9.6 to sage-9.7
Note: See TracTickets for help on using tickets.