Opened 16 months ago
Last modified 5 months ago
#31703 needs_info enhancement
Sheaves on manifolds
Reported by:  ghmjungmath  Owned by:  

Priority:  major  Milestone:  sage9.7 
Component:  manifolds  Keywords:  
Cc:  egourgoulhon, tscrim, ghtobiasdiez, mkoeppe  Merged in:  
Authors:  Reviewers:  
Report Upstream:  N/A  Work issues:  
Branch:  public/31703_sheaves (Commits, GitHub, GitLab)  Commit:  865d37d67e3b2a82b669fb2a818d05f05facc32f 
Dependencies:  #31785  Stopgaps: 
Description (last modified by )
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 mixin 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 (47)
comment:1 Changed 16 months ago by
 Description modified (diff)
comment:2 Changed 15 months ago by
comment:3 Changed 15 months ago by
 Description modified (diff)
comment:4 followup: ↓ 5 Changed 15 months ago by
Sounds like we should add a functorial construction.
comment:5 in reply to: ↑ 4 Changed 15 months ago by
comment:6 Changed 15 months ago by
... similar to what's happening in sage.categories.homsets
comment:7 Changed 15 months ago by
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 mixin class, we can do that all via the category framework.
comment:8 Changed 15 months ago by
The problem I see with the category approach is that the implementation will be probably too concrete.
comment:9 Changed 15 months ago by
I will upload a proposal with category approach and put it under consideration.
comment:10 Changed 15 months ago by
 Branch set to public/31703_sheaves
comment:11 Changed 15 months ago by
 Commit set to ff599d42f5b9146a921269a6fa345bd11023782f
Branch pushed to git repo; I updated commit sha1. New commits:
ff599d4  Trac #31703: first attempt using category

comment:12 followup: ↓ 13 Changed 15 months ago by
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
Replying to ghtobiasdiez:
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
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".
comment:15 Changed 15 months ago by
I think this whole category approach was nonsense after all...
comment:16 followup: ↓ 18 Changed 15 months ago by
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.
comment:17 Changed 15 months ago by
 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
Replying to ghtobiasdiez:
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
I have uploaded another approach. Feedback is welcome! :)
comment:20 Changed 15 months ago by
 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
 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
This should reveal some more of the idea.
comment:23 Changed 15 months ago by
_repr_
is probably not optimal, but at this stage I don't know how to do better.
comment:24 Changed 15 months ago by
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
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 parentelement construction is what we want here, no?
comment:26 Changed 15 months ago by
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
 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
 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
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.
comment:30 Changed 15 months ago by
 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
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
 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
@Matthias: Is that what you had in mind when speaking of functorial properties?
comment:34 Changed 15 months ago by
 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
 Commit changed from 80eba041c57d8a422b704aad3cfc49cd6ddefc0a to d4b1d331731981df6e63c889e96b25c0412ced8e
comment:36 Changed 15 months ago by
 Commit changed from d4b1d331731981df6e63c889e96b25c0412ced8e to b91fc1661d2b01d16ae5085e86893a0a7965d2df
Branch pushed to git repo; I updated commit sha1. New commits:
b91fc16  Trac #31703: semiconcrete implementation of set_restriction

comment:37 Changed 15 months ago by
 Dependencies set to #31785
comment:38 followup: ↓ 40 Changed 15 months ago by
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
 Commit changed from b91fc1661d2b01d16ae5085e86893a0a7965d2df to 865d37d67e3b2a82b669fb2a818d05f05facc32f
comment:40 in reply to: ↑ 38 ; followup: ↓ 41 Changed 15 months ago by
Replying to mkoeppe:
Perhaps instead of passing a lambda function to
Presheaf
, define subclasses such asScalarFieldAlgebraPresheaf
. Then you can replace the methodscalar_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.
comment:41 in reply to: ↑ 40 ; followup: ↓ 42 Changed 14 months ago by
Replying to mkoeppe:
Perhaps instead of passing a lambda function to
Presheaf
, define subclasses such asScalarFieldAlgebraPresheaf
. Then you can replace the methodscalar_field_algebra
with an attribute that is an instance of this class.
Replying to ghmjungmath:
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
Replying to ghmjungmath:
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 reimplement some scalar field features, in particular the handling of restrictions, in this ticket?
comment:43 Changed 14 months ago by
See also sage.schemes.toric.variety
for another place where sheaves already appear in Sage
comment:44 Changed 13 months ago by
 Milestone changed from sage9.4 to sage9.5
comment:45 Changed 13 months ago by
 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
 Milestone changed from sage9.5 to sage9.6
comment:47 Changed 5 months ago by
 Milestone changed from sage9.6 to sage9.7
See https://trac.sagemath.org/ticket/30714#comment:10.