Turn mixed form algebra into de Rham complex

[mjungmath]

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.

CC: @egourgoulhon @tscrim @mkoeppe @jhpalmieri

Component: manifolds

Keywords: chain_complex

Author: Michael Jung

Branch/Commit: 566176a

Reviewer: Travis Scrimshaw

Issue created by migration from https://trac.sagemath.org/ticket/31691

[mjungmath]

Branch: public/31691_de_rham_complex

[sagetrac-git]

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

a050f71	Trac #31691: add category and differential
eeeadf5	Trac #31691: more concrete examples

[sagetrac-git]

Commit: eeeadf5

[mjungmath]

comment:5

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 2-dimensional differentiable manifold M is not in Category of modules over Algebra of differentiable scalar fields on the 2-dimensional 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?

[sagetrac-git]

Changed commit from eeeadf5 to 252cb8f

[sagetrac-git]

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

252cb8f

Trac #31691: invoke derivative instead of differential

[mjungmath]

comment:8

Replying to @mjungmath:

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 2-dimensional differentiable manifold M is not in Category of modules over Algebra of differentiable scalar fields on the 2-dimensional 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?

See #31713.

[sagetrac-git]

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

ab3d601

Trac #31691: de Rham cohomology ring

[sagetrac-git]

Changed commit from 252cb8f to ab3d601

[mjungmath]

comment:10

This draft should already reflect what I have in mind. Comments are welcome.

[mjungmath]

comment:11

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.

[mjungmath]

comment:12

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?

[sagetrac-git]

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

[sagetrac-git]

Changed commit from ab3d601 to 4746ddb

[mjungmath]

comment:14

Ready for review.

[mjungmath]

comment:15

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.

[mjungmath]

comment:16

P.S. I said "simply connected" in the first place, but of course I meant contractible.

[mjungmath]

Author: Michael Jung

[sagetrac-git]

Changed commit from 4746ddb to fb8331a

[sagetrac-git]

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

fb8331a

Trac #31691: fix doctest in manifold.py

[mjungmath]

comment:22

Patchbot green.

[tscrim]

comment:24

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 class-level 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 over-indented. Also, remove the full-stop/period.

[mjungmath]

comment:25

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 and one?

I don't think so. That would make more sense if we can distinguish cohomology classes properly.

For the class-level 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 over-indented. Also, remove the full-stop/period.

Thanks, done.

[tscrim]

comment:26

Replying to @mjungmath:

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.

[mjungmath]

comment:27

Replying to @tscrim:

Replying to @mjungmath:

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.

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

[tscrim]

comment:28

Replying to @mjungmath:

Replying to @tscrim:

Replying to @mjungmath:

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.

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.

[mjungmath]

comment:29

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 have cup 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.

[mjungmath]

comment:30

So your idea is good. I will redirect cup to the product.

[sagetrac-git]

Changed commit from fb8331a to 566176a

[sagetrac-git]

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

566176a

Trac #31691: new file + improved doc + cup product delegates to *

[mjungmath]

comment:32

Commit pushed. Wait for patchbot.

[tscrim]

comment:33

Green bot => positive review

[tscrim]

Reviewer: Travis Scrimshaw

[mjungmath]

comment:34

Morally green?

[mjungmath]

comment:36

Thanks for the review!

[vbraun]

Changed branch from public/31691_de_rham_complex to 566176a