Opened 4 years ago
Last modified 18 months ago
#14865 new enhancement
SageManifolds: a package for differential geometry in Sage
Reported by:  egourgoulhon  Owned by:  egourgoulhon, mbejger 

Priority:  major  Milestone:  sageduplicate/invalid/wontfix 
Component:  packages: experimental  Keywords:  differential geometry, tensor calculus 
Cc:  vdelecroix, jvkersch, novoselt, SimonKing  Merged in:  
Authors:  Michal Bejger, Eric Gourgoulhon  Reviewers:  
Report Upstream:  N/A  Work issues:  
Branch:  u/egourgoulhon/SageManifolds (Commits)  Commit:  185d5b872922ebf70071bbeb553f0ba0337eb72f 
Dependencies:  #15916  Stopgaps: 
Description (last modified by )
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
 pseudoRiemannian 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.
Attachments (4)
Change History (33)
Changed 4 years ago by
comment:1 Changed 4 years ago by
 Cc vdelecroix added
comment:2 Changed 4 years ago by
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
comment:3 Changed 4 years ago by
 Cc jvkersch added
comment:4 followup: ↓ 5 Changed 4 years ago by
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.
comment:5 in reply to: ↑ 4 Changed 4 years ago by
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.
comment:6 Changed 4 years ago by
 Cc novoselt added
comment:7 Changed 4 years ago by
We have just added a tutorial introducing the package at
http://sagemanifolds.obspm.fr/documentation.html
A mailing list has also been opened:
comment:8 Changed 4 years ago by
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.
comment:9 Changed 3 years ago by
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).
comment:10 Changed 3 years ago by
 Milestone changed from sage6.0 to sage6.1
comment:11 Changed 3 years ago by
 Branch set to u/egourgoulhon/SageManifolds
 Commit set to 71b880c99f4bc3b2f2f01b07120261ce851822bd
 Milestone changed from sage6.1 to sage6.2
comment:12 Changed 3 years ago by
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
comment:13 Changed 3 years ago by
 Commit changed from 71b880c99f4bc3b2f2f01b07120261ce851822bd to 5d092dd99780397d6f5782369be10755e8afa418
Branch pushed to git repo; I updated commit sha1. New commits:
5d092dd  Updated all.py

comment:14 Changed 3 years ago by
 Commit changed from 5d092dd99780397d6f5782369be10755e8afa418 to 211421fe109d056033a3b05ef889de7c9bff1bfb
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

comment:15 Changed 3 years ago by
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.
comment:16 Changed 3 years ago by
 Milestone changed from sage6.2 to sage6.3
comment:17 Changed 3 years ago by
 Commit changed from 211421fe109d056033a3b05ef889de7c9bff1bfb to f940b6fdb33a86db9173c87b694eb726b92ba222
Branch pushed to git repo; I updated commit sha1. New commits:
f940b6f  Update to SageManifolds v0.5

comment:18 Changed 3 years ago by
 Dependencies set to #15916
comment:19 Changed 3 years ago by
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.
comment:20 Changed 3 years ago by
This is now part of SageManifolds v0.5 (see this post on sagedevel and http://sagemanifolds.obspm.fr/changelog.html)
comment:21 followup: ↓ 22 Changed 3 years ago by
 Cc SimonKing added
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?
comment:22 in reply to: ↑ 21 Changed 3 years ago by
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
orsage 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).
comment:23 Changed 3 years ago by
 Description modified (diff)
comment:24 Changed 3 years ago by
 Milestone changed from sage6.3 to sage6.4
comment:25 Changed 2 years ago by
 Commit changed from f940b6fdb33a86db9173c87b694eb726b92ba222 to 185d5b872922ebf70071bbeb553f0ba0337eb72f
Branch pushed to git repo; I updated commit sha1. New commits:
185d5b8  Update to SageManifolds v0.6

comment:26 Changed 2 years ago by
The ticket has been updated to coincide with the latest release (0.6) of SageManifolds. The main changes are listed here.
comment:27 Changed 2 years ago by
 Description modified (diff)
comment:28 Changed 18 months ago by
 Description modified (diff)
 Milestone changed from sage6.4 to sageduplicate/invalid/wontfix
comment:29 Changed 18 months ago by
This ticket is now obsolete; see the metaticket #18528 instead.
The SageManifolds? package