Opened 6 months ago

Last modified 3 months ago

#31703 needs_info enhancement

Sheaves on manifolds

Reported by: gh-mjungmath Owned by:
Priority: major Milestone: sage-9.5
Component: manifolds Keywords:
Cc: egourgoulhon, tscrim, gh-tobiasdiez, mkoeppe Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: public/31703_sheaves (Commits, GitHub, GitLab) Commit: 865d37d67e3b2a82b669fb2a818d05f05facc32f
Dependencies: #31785 Stopgaps:

Status badges

Description (last modified by gh-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.

Change History (45)

comment:1 Changed 6 months ago by gh-mjungmath

  • Description modified (diff)

comment:3 Changed 6 months ago by gh-mjungmath

  • Description modified (diff)

comment:4 follow-up: Changed 6 months ago by mkoeppe

Sounds like we should add a functorial construction.

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

Replying to mkoeppe:

Sounds like we should add a functorial construction.

What do you mean?

comment:6 Changed 6 months ago by mkoeppe

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

comment:7 Changed 5 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 5 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 5 months ago by gh-mjungmath

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

comment:10 Changed 5 months ago by gh-mjungmath

  • Branch set to public/31703_sheaves

comment:11 Changed 5 months ago by git

  • Commit set to ff599d42f5b9146a921269a6fa345bd11023782f

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

ff599d4Trac #31703: first attempt using category

comment:12 follow-up: Changed 5 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 5 months ago by gh-mjungmath

Replying to 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?

What do you mean?

comment:14 Changed 5 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 5 months ago by gh-mjungmath (previous) (diff)

comment:15 Changed 5 months ago by gh-mjungmath

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

comment:16 follow-up: Changed 5 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 5 months ago by gh-tobiasdiez (previous) (diff)

comment:17 Changed 5 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:

29b601aTrac #31703: first attempt

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

Replying to 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.

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

comment:19 Changed 5 months ago by gh-mjungmath

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

comment:20 Changed 5 months ago by git

  • Commit changed from 29b601a6cb979dfc96f7d964de76b89e5df76dfe to 7e2a6f51eb8be17d3bcbbdd4ec40d99e1c3c3e79

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

7e2a6f5Trac #31703: add sheaves

comment:21 Changed 5 months ago by git

  • Commit changed from 7e2a6f51eb8be17d3bcbbdd4ec40d99e1c3c3e79 to 939700c344f3699ad123d2e15ebbeb2f354bf4c5

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

939700cTrac #31703: add some examples

comment:22 Changed 5 months ago by gh-mjungmath

This should reveal some more of the idea.

comment:23 Changed 5 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 5 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 5 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 5 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 5 months ago by git

  • Commit changed from 939700c344f3699ad123d2e15ebbeb2f354bf4c5 to 061bda56881cef45ced093f42c32e002ab33a563

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

061bda5Trac #31703: concatenate

comment:28 Changed 5 months ago by git

  • Commit changed from 061bda56881cef45ced093f42c32e002ab33a563 to 53e4430154e6834df9db8b9f39386e06bcce1eab

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

53e4430Trac #31703: copy restriction code from tensorfield.py

comment:29 Changed 5 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 5 months ago by gh-mjungmath (previous) (diff)

comment:30 Changed 5 months ago by git

  • Commit changed from 53e4430154e6834df9db8b9f39386e06bcce1eab to 2c9c72bd818cfefbf294710d1b8bdcfba0c8d555

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

2c9c72bTrac #31703: extension graph dict

comment:31 Changed 5 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 5 months ago by git

  • Commit changed from 2c9c72bd818cfefbf294710d1b8bdcfba0c8d555 to a884da1edced4b426beb4477412dbda6a1306a16

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

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

comment:33 Changed 5 months ago by gh-mjungmath

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

comment:34 Changed 5 months ago by git

  • Commit changed from a884da1edced4b426beb4477412dbda6a1306a16 to 80eba041c57d8a422b704aad3cfc49cd6ddefc0a

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

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

comment:35 Changed 5 months ago by git

  • Commit changed from 80eba041c57d8a422b704aad3cfc49cd6ddefc0a to d4b1d331731981df6e63c889e96b25c0412ced8e

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

a5e0956Trac #31703: set_restriction is presheaf property
d4b1d33Trac #31703: update restriction graph for restrict method

comment:36 Changed 5 months ago by git

  • Commit changed from d4b1d331731981df6e63c889e96b25c0412ced8e to b91fc1661d2b01d16ae5085e86893a0a7965d2df

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

b91fc16Trac #31703: semi-concrete implementation of set_restriction

comment:37 Changed 5 months ago by gh-mjungmath

  • Dependencies set to #31785

comment:38 follow-up: Changed 5 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 5 months ago by git

  • Commit changed from b91fc1661d2b01d16ae5085e86893a0a7965d2df to 865d37d67e3b2a82b669fb2a818d05f05facc32f

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

6f9081dTrac #31703: contravariant nature of functor
865d37dTrac #31703: add a bit of documentation

comment:40 in reply to: ↑ 38 ; follow-up: Changed 5 months ago by gh-mjungmath

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.

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

comment:41 in reply to: ↑ 40 ; follow-up: Changed 5 months ago by gh-mjungmath

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 gh-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?

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

Replying to gh-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?

comment:43 Changed 4 months ago by mkoeppe

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

comment:44 Changed 3 months ago by mkoeppe

  • Milestone changed from sage-9.4 to sage-9.5

comment:45 Changed 3 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.

Note: See TracTickets for help on using tickets.