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