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.

[egourgoulhon]

The SageManifolds? package

[ncohen]

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]

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]

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]

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]

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]

Version 0.3 of SageManifolds? package

[egourgoulhon]

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]

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

[git]

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

​5d092dd

Updated all.py

[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

[egourgoulhon]

SageManifolds? 0.4 spkg

[egourgoulhon]

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.

[git]

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

​f940b6f

Update to SageManifolds v0.5

[egourgoulhon]

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]

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

[SimonKing]

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]

Replying to SimonKing:

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

[git]

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

​185d5b8

Update to SageManifolds v0.6

[egourgoulhon]

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

[egourgoulhon]

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

[chapoton]

can be closed as duplicate

[embray]

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