Opened 14 months ago
Closed 12 months ago
#31691 closed enhancement (fixed)
Turn mixed form algebra into de Rham complex
Reported by:  ghmjungmath  Owned by:  

Priority:  major  Milestone:  sage9.4 
Component:  manifolds  Keywords:  chain_complex 
Cc:  egourgoulhon, tscrim, mkoeppe, jhpalmieri  Merged in:  
Authors:  Michael Jung  Reviewers:  Travis Scrimshaw 
Report Upstream:  N/A  Work issues:  
Branch:  566176a (Commits, GitHub, GitLab)  Commit:  566176a74a480456b7836c13a173e217b721b70a 
Dependencies:  Stopgaps: 
Description (last modified by )
We turn the algebra of mixed differential forms into a de Rham complex and add it to the category of ChainComplexes
, see #31669.
Furthermore, we add de Rham cohomology to SageManifolds? with limited functionality. For now, the implementation will only consist of abstract elements that are given by representatives of mixed forms, i.e. we take closed mixed forms, put a bracket around it and do all computations in the algebra of mixed forms.
Change History (37)
comment:1 Changed 14 months ago by
 Summary changed from Make mixed forms to de Rham complex to Turn mixed forms into de Rham complex
comment:2 Changed 14 months ago by
 Description modified (diff)
comment:3 Changed 13 months ago by
 Branch set to public/31691_de_rham_complex
comment:4 Changed 13 months ago by
 Commit set to eeeadf5aa539af8eb994705093f9972d12281c82
comment:5 followup: ↓ 8 Changed 13 months ago by
Here is a first draft. Unfortunately I get an error with the current test:
sage: M = Manifold(2, 'M') sage: X.<x,y> = M.chart() sage: C = M.de_rham_complex() sage: d0 = C.differential(0); d0 Exception raised: ... ValueError: Algebra of differentiable scalar fields on the 2dimensional differentiable manifold M is not in Category of modules over Algebra of differentiable scalar fields on the 2dimensional differentiable manifold M
This is somewhat peculiar. Each algebra should automatically be a module over itself... Should I simply add the category to the scalar field algebra or does that need a broader fix?
comment:6 Changed 13 months ago by
 Commit changed from eeeadf5aa539af8eb994705093f9972d12281c82 to 252cb8f157e8df943f2666ae1683397adb61ff79
Branch pushed to git repo; I updated commit sha1. New commits:
252cb8f  Trac #31691: invoke derivative instead of differential

comment:7 Changed 13 months ago by
 Cc mkoeppe added
comment:8 in reply to: ↑ 5 Changed 13 months ago by
Replying to ghmjungmath:
Here is a first draft. Unfortunately I get an error with the current test:
sage: M = Manifold(2, 'M') sage: X.<x,y> = M.chart() sage: C = M.de_rham_complex() sage: d0 = C.differential(0); d0 Exception raised: ... ValueError: Algebra of differentiable scalar fields on the 2dimensional differentiable manifold M is not in Category of modules over Algebra of differentiable scalar fields on the 2dimensional differentiable manifold MThis is somewhat peculiar. Each algebra should automatically be a module over itself... Should I simply add the category to the scalar field algebra or does that need a broader fix?
See #31713.
comment:9 Changed 13 months ago by
 Commit changed from 252cb8f157e8df943f2666ae1683397adb61ff79 to ab3d601704d47453641f4e1a225a596784507a4b
Branch pushed to git repo; I updated commit sha1. New commits:
ab3d601  Trac #31691: de Rham cohomology ring

comment:10 Changed 13 months ago by
This draft should already reflect what I have in mind. Comments are welcome.
comment:11 Changed 13 months ago by
I must apologize. I was extremely sloppy here: differentials are no morphisms in the category of modules over scalar fields, they are morphisms in the category of modules over K
!
I'll fix this.
comment:12 Changed 13 months ago by
That was expected. Same problem, but now with differential form modules not considered as vector spaces.
There should be some way to define these morphisms, no?
comment:13 Changed 13 months ago by
 Commit changed from ab3d601704d47453641f4e1a225a596784507a4b to 4746ddb61e6d2da8e7d7b5e76d39772b286f56a2
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
4746ddb  Trac #31691: turn mixed form algebra into de rham complex

comment:15 Changed 13 months ago by
This is just a first step.
My idea (not for this ticket): Optimally, we want to cover our manifold by contractible chart domains. Therefore it would be helpful if we could determine whether an open subset is contractible or not. Perhaps this needs some input from the user. But then, we can probably check for exactness (I still have to think about it) and, other than that, construct Cech cohomology.
comment:16 Changed 13 months ago by
P.S. I said "simply connected" in the first place, but of course I meant contractible.
comment:17 Changed 13 months ago by
comment:18 Changed 13 months ago by
 Summary changed from Turn mixed forms into de Rham complex to Turn mixed form algebra into de Rham complex
comment:19 Changed 13 months ago by
 Description modified (diff)
comment:20 Changed 13 months ago by
 Description modified (diff)
comment:21 Changed 13 months ago by
 Commit changed from 4746ddb61e6d2da8e7d7b5e76d39772b286f56a2 to fb8331abc00f6886b511819bff1e4116bb2e6d30
Branch pushed to git repo; I updated commit sha1. New commits:
fb8331a  Trac #31691: fix doctest in manifold.py

comment:22 Changed 13 months ago by
Patchbot green.
comment:23 Changed 13 months ago by
 Cc jhpalmieri added
comment:24 followup: ↓ 25 Changed 13 months ago by
I think it would be best to split off the cohomology ring into a separate file.
Do you want to give a special (latex) name to zero
and one
?
For the classlevel docstring of DeRahmComologyRing
:
Define the de Rham cohomology ring of a de Rham complex.
The de Rham cohomology ring of a de Rham complex.
I don't think you should assume that the parents are the same for cup
(unlike what you can do for _mul_
).
In your cohomology()
method, you have both \left.
and \right.
. I don't understand the point of this.
The input block to differential()
is overindented. Also, remove the fullstop/period.
comment:25 in reply to: ↑ 24 ; followup: ↓ 26 Changed 13 months ago by
Replying to tscrim:
I think it would be best to split off the cohomology ring into a separate file.
Sounds reasonable.
Do you want to give a special (latex) name to
zero
andone
?
I don't think so. That would make more sense if we can distinguish cohomology classes properly.
For the classlevel docstring of
DeRahmComologyRing
:Define the de Rham cohomology ring of a de Rham complex. The de Rham cohomology ring of a de Rham complex.
Thanks, done.
I don't think you should assume that the parents are the same for
cup
(unlike what you can do for_mul_
).
What do you mean?
In your
cohomology()
method, you have both\left.
and\right.
. I don't understand the point of this.
The point is that \middle/
has the appropriate size.
The input block to
differential()
is overindented. Also, remove the fullstop/period.
Thanks, done.
comment:26 in reply to: ↑ 25 ; followup: ↓ 27 Changed 13 months ago by
Replying to ghmjungmath:
Replying to tscrim:
I don't think you should assume that the parents are the same for
cup
(unlike what you can do for_mul_
).What do you mean?
If you take the cup
with something the coerces in (perhaps 2
?) but is not actually an element of the same parent, then it will either fail or could end up with an element that is not actually in the ring. However, for _mul_
, this can never happen because the coercion framework would make sure both arguments belong to the same parent.
comment:27 in reply to: ↑ 26 ; followup: ↓ 28 Changed 13 months ago by
Replying to tscrim:
Replying to ghmjungmath:
Replying to tscrim:
I don't think you should assume that the parents are the same for
cup
(unlike what you can do for_mul_
).What do you mean?
If you take the
cup
with something the coerces in (perhaps2
?) but is not actually an element of the same parent, then it will either fail or could end up with an element that is not actually in the ring. However, for_mul_
, this can never happen because the coercion framework would make sure both arguments belong to the same parent.
Currently, there is not even a natural coercion implemented. The only coercion that would be admissible is the one from closed differential forms (and everything that is contained in it) into cohomology, but we don't have that subspace implemented. Therefore, it wouldn't even work with _mul_
.
comment:28 in reply to: ↑ 27 ; followup: ↓ 29 Changed 13 months ago by
Replying to ghmjungmath:
Replying to tscrim:
Replying to ghmjungmath:
Replying to tscrim:
I don't think you should assume that the parents are the same for
cup
(unlike what you can do for_mul_
).What do you mean?
If you take the
cup
with something the coerces in (perhaps2
?) but is not actually an element of the same parent, then it will either fail or could end up with an element that is not actually in the ring. However, for_mul_
, this can never happen because the coercion framework would make sure both arguments belong to the same parent.Currently, there is not even a natural coercion implemented. The only coercion that would be admissible is the one from closed differential forms (and everything that is contained in it) into cohomology, but we don't have that subspace implemented. Therefore, it wouldn't even work with
_mul_
.
However, it will fail with a much more reasonable message and it will be all setup for when there is a coercion implemented. Most importantly, it will handle the natural coercion from the scalar field into the ring, but cup
will not. You should have cup
simply redirect to *
. This will also make it easier if this ever gets subclassed too.
comment:29 in reply to: ↑ 28 Changed 13 months ago by
Replying to tscrim:
However, it will fail with a much more reasonable message and it will be all setup for when there is a coercion implemented. Most importantly, it will handle the natural coercion from the scalar field into the ring, but
cup
will not. You should havecup
simply redirect to*
. This will also make it easier if this ever gets subclassed too.
It will get subclassed. My idea is that a characteristic class becomes a subclass of DeRhamCohomologyClass
with a dedicated representative
method.
comment:30 Changed 13 months ago by
So your idea is good. I will redirect cup
to the product.
comment:31 Changed 13 months ago by
 Commit changed from fb8331abc00f6886b511819bff1e4116bb2e6d30 to 566176a74a480456b7836c13a173e217b721b70a
Branch pushed to git repo; I updated commit sha1. New commits:
566176a  Trac #31691: new file + improved doc + cup product delegates to *

comment:32 Changed 13 months ago by
Commit pushed. Wait for patchbot.
comment:34 Changed 13 months ago by
Morally green?
comment:35 Changed 13 months ago by
 Status changed from needs_review to positive_review
comment:36 Changed 13 months ago by
Thanks for the review!
comment:37 Changed 12 months ago by
 Branch changed from public/31691_de_rham_complex to 566176a74a480456b7836c13a173e217b721b70a
 Resolution set to fixed
 Status changed from positive_review to closed
Branch pushed to git repo; I updated commit sha1. New commits:
Trac #31691: add category and differential
Trac #31691: more concrete examples