VectorFieldModule, TensorFieldModule, DiffFormModule: Add methods tensor_product, tensor_power, update category of TensorFieldModule

[mkoeppe]

... as previously done for FiniteRankFreeModule etc.

We introduce abstract base classes ReflexiveModule_* to unify the implementations of VectorFieldModule... and FiniteRankFreeModule/VectorFieldFreeModule...

Follow-up: #34621 Method dual_pairing for modules in sage.tensor

CC: @egourgoulhon @tscrim @mjungmath

Component: manifolds

Author: Matthias Koeppe

Branch/Commit: 74601e6

Reviewer: Eric Gourgoulhon

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

[mkoeppe]

Dependencies: #34448

[mkoeppe]

Branch: u/mkoeppe/vectorfieldmodule_tensor_product

[mkoeppe]

Commit: 31b17b5

[mkoeppe]

comment:3

Probably best to create a class VectorFieldModule_abstract

---

Last 10 new commits:

620df16	src/sage/tensor/modules/tensor_free_submodule.py: Remove tensor_factors, add doctest for construction
4c9be6b	src/sage/manifolds/differentiable/diff_form_module.py: doc: add that the case p=1 of M parallelizable is implemented via VectorFieldDualFreeModule
06710c1	src/sage/manifolds/differentiable/diff_form_module.py, vectorfield_module.py: Update copyright using 'git blame -w --date=format:%Y FILE.py | sort -k2', add to AUTHORS
bb614c1	Merge #34501
4a4a29d	Merge tag '9.7' into t/34448/put_tensor_modules_of_finiterankfreemodule_in_modules___tensorproducts__
1f4fb90	Merge tag '9.8.beta0' into t/34448/put_tensor_modules_of_finiterankfreemodule_in_modules___tensorproducts__
7c04959	src/sage/manifolds/differentiable/diff_form_module.py: Fix typo in docstring
fc31cbf	Merge #34501
f0def92	src/sage/tensor/modules/tensor_free_module.py: Remove redundant method
31b17b5	WIP

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

e10f9cf	src/sage/manifolds/differentiable/vectorfield_module.py: Revert change to VectorFieldModule.tensor (not needed yet)
ff00c11	VectorFieldModule: Add tensor_product, tensor_power
8d753dc	src/sage/manifolds/differentiable/vectorfield_module.py (VectorFieldModule_abstract): New

[sagetrac-git]

Changed commit from 31b17b5 to 8d753dc

[sagetrac-git]

Changed commit from 8d753dc to 6bada9f

[sagetrac-git]

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

2830ebc	TensorFreeModule.tensor_factors: Go through methods tensor_type, base_module
6bada9f	TensorFieldModule.tensor_factors: New

[sagetrac-git]

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

347ffc0

TensorFieldModule: Put it in the category Modules.TensorProducts

[sagetrac-git]

Changed commit from 6bada9f to 347ffc0

[sagetrac-git]

Changed commit from 347ffc0 to 7194893

[sagetrac-git]

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

7194893

src/sage/manifolds/differentiable/tensorfield_module.py: Update copyright according to git blame -w --date=format:%Y FILE | sort -k2

[mkoeppe]

Author: Matthias Koeppe

[mkoeppe]

comment:11

This new base class is of course not very pretty

+class VectorFieldModule_abstract(UniqueRepresentation, Parent):
+    r"""
+    Abstract base class for modules of vector fields.
+    """
+
+    tensor_power = FiniteRankFreeModule_abstract.tensor_power
+
+    tensor_product = FiniteRankFreeModule_abstract.tensor_product
+
+    tensor = FiniteRankFreeModule_abstract.tensor

It could be better to have a common base class for VectorFieldModule_abstract and FiniteRankFreeModule_abstract.

Perhaps that could be called ModuleWithDual_abstract? (see also #13372)

[mkoeppe]

comment:12

Algebra question - do we know / do we assume that a VectorFieldModule is reflexive?

[mkoeppe]

comment:13

(in this case, we could call it ReflexiveModule_abstract - for such modules the pair tensor_type makes sense.)

[egourgoulhon]

comment:14

Replying to Matthias Köppe:

Algebra question - do we know / do we assume that a VectorFieldModule is reflexive?

I would say that the vector field modules are indeed reflexive for the cases we can treat with Sage, namely those for which the manifold M can be split into a finite number of parallelizable manifolds N_i, i.e. there is a finite open cover of M, (N_i)_{1\leq i \leq p} (p finite), such that for each i, N_i is parallelizable. Let then consider an element f of X(M)**, where X(M) is the C^oo(M)-module of vector fields on M. For a in X(M)*, f(a) can be reduced to f_i(a_i) on each N_i. Since N_i is parallelizable, X(N_i) is a free module of finite rank and thus reflexive. There exists then a unique v_i in X(N_i) such that f_i(a_i) = a_i(v_i). Then the vector field v in X(M) defined as being equal to v_i on each N_i obeys f(a) = a(v), which shows that the canonical map X(M) --> X(M)** is bijective. This is a first quick thought and this should be double checked...

[egourgoulhon]

comment:15

Replying to Matthias Köppe:

(in this case, we could call it ReflexiveModule_abstract - for such modules the pair tensor_type makes sense.)

Indeed, if we confirm that the vector field modules are reflexive.

[mkoeppe]

comment:16

Replying to Eric Gourgoulhon:

I would say that the vector field modules are indeed reflexive for the cases we can treat with Sage, namely those for which the manifold M can be split into a finite number of parallelizable manifolds N_i, i.e. there is a finite open cover of M, (N_i)_{1\leq i \leq p} (p finite), such that for each i, N_i is parallelizable.

Is this splitting into parallelizable manifolds explicitly done somewhere in the code?

I guess a subtlety is that in sage.manifolds a manifold M is thought to be immutable but new submanifolds on it can be declared imperatively. At any point, of course only finitely many submanifolds have been declared in M as a Python object, but it's not clear that M as a mathematical object is really assumed to be covered by only a finite number of parallelizable submanifolds...

[egourgoulhon]

comment:17

Replying to Matthias Köppe:

Replying to Eric Gourgoulhon:

I would say that the vector field modules are indeed reflexive for the cases we can treat with Sage, namely those for which the manifold M can be split into a finite number of parallelizable manifolds N_i, i.e. there is a finite open cover of M, (N_i)_{1\leq i \leq p} (p finite), such that for each i, N_i is parallelizable.

Is this splitting into parallelizable manifolds explicitly done somewhere in the code?

Not explicitly, but DifferentiableManifold's have the attribute _parrelizable_parts; for instance:

sage: M = manifolds.Sphere(2, coordinates='stereographic')
sage: M._parallelizable_parts
{Open subset S^2-{NP,SP} of the 2-sphere S^2 of radius 1 smoothly embedded in the Euclidean space E^3,
 Open subset S^2-{NP} of the 2-sphere S^2 of radius 1 smoothly embedded in the Euclidean space E^3,
 Open subset S^2-{SP} of the 2-sphere S^2 of radius 1 smoothly embedded in the Euclidean space E^3}
sage: M._open_covers
[[2-sphere S^2 of radius 1 smoothly embedded in the Euclidean space E^3],
 [Open subset S^2-{NP} of the 2-sphere S^2 of radius 1 smoothly embedded in the Euclidean space E^3,
  Open subset S^2-{SP} of the 2-sphere S^2 of radius 1 smoothly embedded in the Euclidean space E^3]]

Actually the parallelizable parts are declared on the fly, in the same spirit as the charts and other structures on the manifod. Even the parallelizable aspect of the manifold can appear quite late after the manifold instanciation. For example, in this notebook about S^1, the manifold is (implicitly) declared parallelizable only in cell no. 21, by declaring a vector frame on it. This action creates the object X(M) as a VectorFieldFreeModule. Previously, only the modules X(A) and X(B) had been instanciated. However, one could imagine to add the keyword argument parallelizable to the manifold constructor (with default being False).

I guess a subtlety is that in sage.manifolds a manifold M is thought to be immutable but new submanifolds on it can be declared imperatively. At any point, of course only finitely many submanifolds have been declared in M as a Python object, but it's not clear that M as a mathematical object is really assumed to be covered by only a finite number of parallelizable submanifolds...

You're right, this should be stated in the manifold documentation. The whole idea is described in Sec. 3.2 and 3.3 of this document.
Note that the finite number of parallelizable pieces is not a very severe limitation. For instance this holds for any compact manifold. Actually I don't know any manifold that is not of this type, not that I doubt that some examples can be constructed...

[sagetrac-git]

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

d5e715e

sage.tensor.modules.reflexive_module: New, refactor finite rank free modules and vector field modules through the new classes

[sagetrac-git]

Changed commit from 7194893 to d5e715e

[mkoeppe]

comment:19

Here's a draft of refactoring along these lines. (Of course src/sage/tensor/modules/reflexive_module.py would still need more documentation.)

[sagetrac-git]

Changed commit from 2a7b445 to 05daeee

[sagetrac-git]

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

05daeee

src/sage/tensor/modules/tensor_free_module.py (TensorFreeModule): Make MRO consistent with FiniteRankFreeModule

[mkoeppe]

comment:33

1. Thanks for catching this, fixed.

[mkoeppe]

comment:34

2. I guess I was planning to move some methods from VectorFieldModule to VectorField_abstract. Candidates would be domain, ambient_domain, and perhaps some others. But I agree that the name VectorFieldModule_abstract is misleading... Would you have a suggestion for a better name? It also doesn't have to happen on this ticket -- I can just back it out.

[egourgoulhon]

comment:35

Replying to Matthias Köppe:

2. I guess I was planning to move some methods from VectorFieldModule to VectorField_abstract. Candidates would be domain, ambient_domain, and perhaps some others. But I agree that the name VectorFieldModule_abstract is misleading... Would you have a suggestion for a better name?

Maybe FieldModule_abstract?

It also doesn't have to happen on this ticket -- I can just back it out.

OK.

[egourgoulhon]

comment:36

May I ask what do we choose? Renaming VectorFieldModule_abstract to FieldModule_abstract (or something similar) or backing it out for this ticket?

[mkoeppe]

comment:37

I'll back it out

[sagetrac-git]

Changed commit from 05daeee to ebc2f27

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. Last 10 new commits:

610545e	TensorFreeModule.tensor_factors: Go through methods tensor_type, base_module
a6ba101	TensorFieldModule.tensor_factors: New
8e0bf36	TensorFieldModule: Put it in the category Modules.TensorProducts
20bd0d3	src/sage/manifolds/differentiable/tensorfield_module.py: Update copyright according to git blame -w --date=format:%Y FILE | sort -k2
38e6b3e	sage.tensor.modules.reflexive_module: New, refactor finite rank free modules and vector field modules through the new classes
04a4daa	src/sage/tensor/modules/reflexive_module.py: Make all classes subclasses of ..._abstract
53e944a	src/sage/tensor/modules/reflexive_module.py: Add documentation
f107a77	src/doc/en/reference/tensor_free_modules/tensors.rst: Add reflexive_module
d2228bd	src/sage/tensor/modules/tensor_free_module.py (TensorFreeModule): Make MRO consistent with FiniteRankFreeModule
ebc2f27	WIP get rid of VectorFieldModule_abstract

[mkoeppe]

Changed dependencies from #34448 to none

[sagetrac-git]

Changed commit from ebc2f27 to 8a2866b

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

8a2866b

get rid of VectorFieldModule_abstract

[egourgoulhon]

comment:42

Replying to Matthias Köppe:

I'll back it out

Thanks!

One minor last thing: as revealed by the patchbot, ReflexiveModule_abstract is imported by unused in vectorfield_module.py.

[sagetrac-git]

Changed commit from 8a2866b to 74601e6

[sagetrac-git]

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

74601e6

Remove unused import

[egourgoulhon]

Reviewer: Eric Gourgoulhon

[egourgoulhon]

comment:44

Thanks!

[mkoeppe]

comment:45

Thank you!

[vbraun]

Changed branch from u/mkoeppe/vectorfieldmodule_tensor_product to 74601e6