-
-
Notifications
You must be signed in to change notification settings - Fork 487
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Natural bundles: local data (and orientations) #32974
Comments
comment:1
Possibly related: #31703. Before we introduce new bundles over manifolds, I'd suggest we should implement quite general (fiber) bundles over manifolds. The category framework should be of great use here. Punchline: there is a purely categorical description of bundles over manifolds using isomorphisms in the corresponding category. Sections can be realized by their (pre)sheaf property (see above). Based on such an implementation, natural bundles, in particular frame bundles, orientation bundles, even vector bundles and tensor bundles, become a special case. Why? We should not swing from bundle to bundle and add more and more bundles individually if there's a general description we can (probably more conveniently) make use of first. |
comment:2
Thanks for the feedback. I think sheaves are a great idea in general. However, they are perpendicular to the main idea of natural bunldes. But you are right, once sheaves are implemented one could let Note also that I didn't implement natural bundles directly, but only what would correspond to their local sections. |
comment:4
Replying to @tobiasdiez:
I see. It was just a comment. We should keep in mind, the more special cases of bundles we implement, the more work we have to refactor them into the generalized framework that will be inevitable to implement at some point. |
comment:5
Do you have references/literature? |
comment:6
Looks to me that natural bundles are already the most canonical things you can have over manifolds. Is it true that any non-natural bundle does not contain useful (geometric) information? If that is the case, natural bundles are perhaps the thing we actually need. Unfortunately, I don't know enough to form an opinion here. |
comment:7
Natural bundles are quite general. More or less everything that you can phrase in terms of frames and that behaves "naturally" with respect to changes of frames is a section of a natural bundle.
That probably depends on your definition of "geometric information". There are definitely interesting bundles that are not natural. For example, the Hopf fibration is not natural (but the tautological line bundle is). References are hard. |
comment:8
Fascinating! Thank you for the explanation and references. Replying to @tobiasdiez:
Well, I'd consider spin bundles already quite geometric. So I assume the answer is "no". |
comment:9
More feedback is strongly appreciated before I continue working on this. Thanks! |
The theory of natural bundles provides a convienent framework to specify geometric data on manifolds.
A natural bundle is a frame bundle over a manifold
M
with an action by the diffeomorphism groupM
.The frame bundle and bundles associated to the frame bundle are natural.
Thus, on abstract grounds, things like orientation, vector fields, diff forms, metrics, symplectic forms etc are all examples of sections of natural bundles.
In this ticket, we introduce the class
NaturalLocalData
which represents the data that is needed to encode local sections of natural bundles.This concept is illustrated and applied to specify orientations of manifolds as assigning +1 or -1 to a vector frame.
The implementation uses the following results about natural bundles:
E
is (under sufficiently general assumptions) an associated bundle of a jet-prolongationL^r M
of the frame bundleLM
. That is,E = L^r M \times_{\rho} V
where\rho
is an action of the jet-prolongation ofGL
on the manifoldV
.M
lifts to a bundle automorphism by taking its jet.E
.E
is just aV
-valued function.V
-valued functions defines a section ofE
iff they transform correctly under the action of diffeomorphisms.In other words, a section of
E
is specified by assigning to a frame aV
-valued function. This is what the classNaturalLocalData
is capturing.The naturality (e.g. the known transformation behavior under diffeos) is used to a) check that a collection of
V
-valued functions indeed specifies a global section (check_consistency
) and b) to calculate the representation in charts other than the ones originally used (still to be implemented).On some way, one could view this as a refactorization and genearlization of the "restrictions" and "components" functions of tensor fields using the mathematical concept of natural bundles.
The simplest example (and often sufficiently general) is the case of first-order natural bundles, corresponding to
r=1
above.That is,
E
is just an associated bundle to the frame bundle, using some action ofGL(n)
. For example, the orientation bundle is given by action ofGL(n)
onZ_2
by multiplication byA.det().sign()
.In a follow-up ticket, natural transformations are implemented.
These are diffeo-equivariant maps between natural bundles. Examples are almost all basic constructions, e.g. contractions of tensor fields, curvature maps, assigning volume forms to metrics, exterior differential, etc.
The implementation is still in its early stages, but feedback is very welcome before I continue working on this (in a 'wrong' direction).
For example, one question I had is why tensor fields etc use the concept of
restriction
, and only in a second step are represented by their components wrt to frame - instead of directly collecting only components wrt to frames.Also ideas how to best migrate existing code to these natural bundles are appreciated.
Specifying the orientation in this new framework is easy, but the other migrations will be much more involved (and I don't plan to do this as part of this ticket).
CC: @tscrim @nthiery @mjungmath @egourgoulhon
Component: manifolds
Branch/Commit: public/manifolds/natural_data @
9a6ba21
Issue created by migration from https://trac.sagemath.org/ticket/32974
The text was updated successfully, but these errors were encountered: