SageManifolds: a package for differential geometry in Sage

[egourgoulhon]

** This ticket is now obsolete: see the metaticket #18528 instead **

This is the first draft of SageManifolds, a project to implement differential geometry and tensor calculus in Sage. It is still at a very early stage; current functionalities include:

• differentiable mappings and submanifolds
• standard tensor calculus (tensor product, contraction, (anti)symmetrization)
• exterior calculus (wedge product, exterior derivative of differential forms)
• Lie derivatives
• affine connections
• curvature and torsion
• pseudo-Riemannian metrics
• Hodge duality

More details on the page http://sagemanifolds.obspm.fr

The package is still very preliminary. Future developments will focuss on

• the implementation of Sage !Parent/Element scheme for a better integration in Sage
• adding new functionalities (e.g. extrinsic geometry of submanifolds, spinors)
• producing faster code by migrating some parts to Cython
  Volunteers are welcome !

Note (added on 18 Jul 2014): this ticket contains now version 0.5 (in the associated git branch) and the attached spkg are obsolete.

Note (added on 13 March 2015): SageManifolds has been updated to version 0.7; the git branch associated with this ticket is (provisory) obsolete; the ticket should be reorganized soon.

Depends on #15916

CC: @videlec @jvkersch @novoselt @simon-king-jena

Component: packages: experimental

Keywords: differential geometry, tensor calculus

Author: Michal Bejger, Eric Gourgoulhon

Branch/Commit: u/egourgoulhon/SageManifolds @ 185d5b8

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

[egourgoulhon]

Attachment: manifolds-0.1.spkg.gz

The SageManifolds package

[nathanncohen]

comment:2

Hellooooooo guys !!

Very recently a very large amount of code dealing with matroids was accepted into Sage (#7477). This project had been developped outside of Sage for a while (it was 21 000 lines long), and the authors then wanted ot make it a real part of Sage.

The problem is that the source code that makes it into Sage normally gets reviewed before, and we were not able to review the matroids code as we usually do as it was really, really too large.
(And appeared to be VERY clean, too).
Now it appears that your code is already 16 000 lines long, and so it would be very very very nice if you could begin to think right now of how it should be split into small "reviewable" pieces if you ever want to have you code included into Sage, not as a spkg but as a real standard code.

I personally felt very guilty to see all this code make it into Sage without discussions and reviews ^^;

Have fuuuuuuuuuuun anyway !!

Nathann

[egourgoulhon]

comment:4

Dear Nathann,

I see your point. However note that it was difficult to submit the package at an earlier stage for it was very fluctuating: various trials were performed and new classes/functionalities were introduced and then removed. The current version is, I think, the first one showable and to be discussed. It can be considered as a more or less stable root for expanding the package. To have a minimum of chart/frame flexibility and a minimum of tensor calculus (with symmetries/antisymmetries properly delt with), it required these 16,000 lines. Not however that not all of them are Python code: there is a lot of docstrings. Maybe the Python code is only one third of the total. If, hopefully, SageManifolds is integrated into Sage some day, it should be much larger than 16,000 lines.

[nbruin]

comment:5

Replying to @egourgoulhon:

However note that it was difficult to submit the package at an earlier stage for it was very fluctuating

+1. Larger/more experimental projects need a more nimble approach to experimenting and trying out their interface. Including little tidbits into sage early on takes away the ability to easily change API/interface/design (that's hard enough without all the bureaucracy the sage patch system imposes).

The development system of sage is geared towards stable, production quality code (regardless of whether that's attained), and that is incompatible with experimental, fast development.

I suspect we'd get the best quality if someone would first write a package independently (building on sage or another computer algebra system) and, once that system proves its worth, reimplement it as sage library code. The duplication of effort in that system is a bit unfortunate and, in practice, probably prohibitive. I don't think we know yet what the best solution is.

Note that for attracting funding, the "independent package" system is better: First you may be able to attract funding for developing a brand new package with revolutionary functionality. Later you can attract funding for ensuring that this revolutionary package gets integrated with other math software, so that it can interoperate with other systems. It also helps the authors more, because there's the independent entity to point to as accomplishment, rather than just an amorphous set of patches or files in the sage library.

[egourgoulhon]

comment:7

We have just added a tutorial introducing the package at

http://sagemanifolds.obspm.fr/documentation.html

A mailing list has also been opened:

http://sagemanifolds.obspm.fr/contact.html

[egourgoulhon]

New version of the SageManifolds package

[egourgoulhon]

comment:8

Attachment: manifolds-0.2.spkg.gz

Hi all,

During the summer, we have improved the SageManifolds package, resulting in version 0.2. The changelog is here. For the end user, the main change regards the declaration of a chart: the range of each coordinate has to be passed as an invertal (the default being R = (-oo, oo)).
More details on the tutorial.

[egourgoulhon]

Attachment: manifolds-0.3.spkg.gz

Version 0.3 of SageManifolds package

[egourgoulhon]

comment:9

Hi all,

We have just released a new version (0.3) of the SageManifolds package. With respect to the previous version, the main changes are

• features for a better integration into Sage: Parent/Element used for Manifold/Point, factory methods instead of direct call to constructors, use of the preparser trick <x,y> to set chart coordinates in the global namespace
• introduction of new classes Domain and OpenDomain to deal with subdomains on a manifold: mappings and tensor fields can now be defined on subdomains only.
  The complete list of changes is here.

See the project home page for examples and documentation.
See also the git repository to access to the latest development version (follow these instructions to install from git instead of the spkg).

[egourgoulhon]

Commit: 71b880c

[egourgoulhon]

Branch: u/egourgoulhon/SageManifolds

[egourgoulhon]

comment:12

Hi All,

The latest development sources have been migrated to github, in a fork of Sage 6.0 master branch, see http://sagemanifolds.obspm.fr/install_from_git.txt

[sagetrac-git]

Changed commit from 71b880c to 5d092dd

[sagetrac-git]

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

5d092dd

Updated all.py

[sagetrac-git]

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

0e21120	First version of SageManifolds within main Sage new git settings
7e1e42c	Updated all.py
5e68a81	corrected doc
60ee078	Merge branch 'master' into sagemanifolds
d5ef294	Merge Sage 6.1.1 into SageManifolds
2dff92f	Corrected symmetrization/antisymmetrization in case of preexisting symmetries
211421f	Merge SageManifolds 0.4 into trac branch

[sagetrac-git]

Changed commit from 5d092dd to 211421f

[egourgoulhon]

SageManifolds 0.4 spkg

[egourgoulhon]

comment:15

Attachment: manifolds-0.4.spkg.gz

Hi,

We have released a new version (0.4) of SageManifolds. There are almost no new functionalities in this version, but the internal code has been seriously amended with respect to version 0.3. In particular the coordinate charts and the vector frames have been made hashable and are used as keys in various dictionaries (like the dictionary of sets of components of a given tensor field with respect to various vector frames).
Besides, Sage's Parent/Element scheme has been implemented for Domain/Point, with Domain in the category of Sets.
For the end user, the main modification lies in a simplified syntax for chart and frame declarations. More in the changelog. Example worksheets based of version 0.4 are here and the main documentation is here (including the reference manual)

The sources of version 0.4 are available in the branch u/egourgoulhon/SageManifolds of trac.sagemath.org.

The development version is at https://github.com/sagemanifolds/ and can be installed according to these instructions.

[sagetrac-git]

Changed commit from 211421f to f940b6f

[sagetrac-git]

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

f940b6f

Update to SageManifolds v0.5

[egourgoulhon]

Dependencies: #15916

[egourgoulhon]

comment:19

This ticket contains now only the "differential" part of SageManifolds (manifolds and tensor fields); the pure algebraic part (tensors on free modules) is in ticket #15916, which must be pulled first.

[egourgoulhon]

comment:20

This is now part of SageManifolds v0.5 (see this post on sage-devel and http://sagemanifolds.obspm.fr/changelog.html)

[simon-king-jena]

comment:21

Do I understand correctly: The project is not intended to be an optional/standard spkg (so, the attached spkg is obsolete), but is purely in the Sage library?

Are the installation instructions from comment:15 really relevant? After all, there is a branch attached to this ticket, so, git trac checkout 14865 or sage --dev checkout ticket=14865 should do the job, isn't it?

[egourgoulhon]

comment:22

Replying to @simon-king-jena:

Do I understand correctly: The project is not intended to be an optional/standard spkg (so, the attached spkg is obsolete), but is purely in the Sage library?

Yes the ultimate goal is that it is fully integrated into Sage library.
Indeed the attached spkg are obsolete.

Are the installation instructions from comment:15 really relevant? After all, there is a branch attached to this ticket, so, git trac checkout 14865 or sage --dev checkout ticket=14865 should do the job, isn't it?

The branch attached to this ticket is sticked to version 0.5 (until version 0.6 is released), while the github repository mentionned in comment:15 contains the development version. See also the section "Installing the latest development version" in his page. If you want version 0.5 only, git trac checkout 14865 is indeed sufficient (after you have installed #15916 of course).

[sagetrac-git]

Changed commit from f940b6f to 185d5b8

[sagetrac-git]

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

185d5b8

Update to SageManifolds v0.6

[egourgoulhon]

comment:26

The ticket has been updated to coincide with the latest release (0.6) of SageManifolds. The main changes are listed here.

[egourgoulhon]

comment:29

This ticket is now obsolete; see the metaticket #18528 instead.

[fchapoton]

comment:31

can be closed as duplicate

[embray]

comment:32

Closing tickets in the sage-duplicate/invalid/wontfix module with positive_review (i.e. someone has confirmed they should be closed).