Smooth manifolds, charts and scalar fields
This woksheet accompanies the lecture Symbolic tensor calculus on manifolds at JNCF 2018.
Click here to download the worksheet file (ipynb format). To run it, you must start SageMath with the Jupyter notebook, via the command sage -n jupyter
NB: a version of SageMath at least equal to 7.5 (8.2 for the SymPy part) is required to run this worksheet:
First we set up the notebook to use LaTeX display:
Starting with a manifold
Manifolds are constructed via the global function Manifold
:
By default, Manifold
returns a manifold over :
Other base fields must be specified with the optional keyword field
, like
We may check that is a topological space:
Actually, belongs to the following categories:
As we can see, by default, Manifold
constructs a smooth manifold. If one would like to stick to the topological level, one should write
Smooth manifolds are implemented by the Python class DifferentiableManifold
:
The type of M
appears as DifferentiableManifold-with-category
because it is actually a subclass of DifferentiableManifold
, which is dynamically generated by SageMath's category mechanism:
The class DifferentiableManifold
inherits from TopologicalManifold
:
Coordinate charts
We declare a chart, along with the symbols used to denote the coordinates (here and ) by
Open subsets are implemented by a (dynamically generated) subclass of DifferentiableManifold
, since they are manifolds in their own:
Points on are created by passing their coordinates in a given chart:
The syntax U(...)
used to create as an element of reflects the parent/element pattern employed in SageMath; indeed is the parent of :
Points are implemented by the class ManifoldPoint
. The principal attribute of this class is a Python dictionary storing the point's coordinates in various charts:
Of course, we can recover the point's coordinates by letting the chart act on the point:
Let us introduce a second chart on :
and declare that is covered by only two charts, i.e. that :
Transition map
We define the transition map XU
XV
on as follows:
The value of the argument restrictions1
means that , where is the point of coordinates , while the value of restrictions2
means that , where is the point of coordinates . Since , we have then
The transition map XV
XU
is obtained by computing the inverse of the one defined above:
At this stage, the smooth manifold is fully specified, being covered by one atlas with all transition maps specified. One may have recognized that is nothing but the 2-dimensional sphere: with XU
(resp. XV
) being the chart of \defin{stereographic coordinates}\index{stereographic!coordinates} from the North pole (resp. the South pole ).
Since the transition maps have been defined, we can ask for the coordinates of the point :
This operation has updated the dictionary _coordinates
:
Smooth maps
As a example of smooth map, let us consider the canonical embedding of into . We need first to introduce as a 3-dimensional smooth manifold, endowed with a single chart:
The embedding is then defined in terms of its coordinate expression in the two charts covering :
We may use for graphical purposes, for instance to display the grids of the stereographic charts XU
(in red) and XV
(in green), with the point atop:
Scalar fields
Let us define a scalar field, i.e. a smooth map :
Scalar fields are implemented by the class DiffScalarField
and the function chart representations are stored in the attribute _express
of this class, which is a Python dictionary whose keys are the various charts defined on :
One may wonder about the compatibility of the two coordinate expressions provided in the definition of . Actually, to enforce the compatibility, it is possible to declare the scalar field in a single chart, XU
say, and then to obtain its expression in chart XV
by analytic continuation from the expression in , where both expressions are known, thanks to the transition map XV
XU
:
The representation of the scalar field in a given chart, i.e. the public access to the directory _express
, is obtained via the method coord_function()
:
Both fU
and fV
are instances of the class ChartFunction
:
Mathematically, chart functions are real-valued functions on the codomain of the considered chart. They map coordinates to elements of the base field (here ):
while scalar fields maps manifold points to :
Internally, each chart function stores coordinate expressions with respect to various computational engines:
SageMath symbolic engine, based on the Pynac backend, with Maxima used for some simplifications or computation of integrals;
SymPy (Python library for symbolic mathematics);
in the future, more symbolic engines (e.g. Giac) or numerical ones will be implemented
The coordinate expressions are stored in the dictionary _express
, whose keys are strings identifying the computational engines. By default only SageMath symbolic expressions, i.e. expressions pertaining to the so-called Symbolic Ring (SR
), are stored:
The public access to the dictionary _express
is performed via the method expr()
:
Actually, fU.expr()
is a shortcut for fU.expr('SR')
since SR
is the default symbolic engine. Note that the class Expression
is that devoted to SageMath symbolic expressions. The method expr()
can also be invoked to get the expression in another symbolic engine, for instance SymPy:
This operation has updated the dictionary _express
:
The default calculus engine for chart functions of chart XU
can changed thanks to the method set_calculus_method()
:
We can have better (i.e. LaTeX) rendering of SymPy objects with
We don't use it here to make clear the distinction between SR
objects and SymPy ones.
Reverting to SageMath's symbolic engine:
Symbolic expressions can be accessed directly from the scalar field, f.expr(XU)
being a shortcut for f.coord_function(XU).expr()
:
Algebra of scalar fields
The commutative algebra of scalar fields on is
As for the manifold classes, the actual Python class implementing is inherited from DiffScalarFieldAlgebra
via the category mechanism, hence it bares the name DiffScalarFieldAlgebra-with-category
:
The class DiffScalarFieldAlgebra-with-category
is dynamically generated as a subclass of DiffScalarFieldAlgebra
with extra functionalities, like for instance the method is_commutative()
:
Let us have a look at the code of this method; it suffices to use the double question mark:
We see from the File
field that the code belongs to the category part of SageMath, not to the manifold part, where the class DiffScalarFieldAlgebra
is defined.
Regarding the scalar field introduced above, we have of course
Actually, in Sage language, CM
= is the parent of f
:
The zero element of the algebra is
while its unit element is
Implementation of algebraic operations on scalar fields
Let us consider some operation in the algebra :
We are going to investigate how the above addition is performed. For the Python interpreter h = f + 2*CM.one()
is equivalent to h = f.__add__(2*CM.one())
, i.e. the +
operator amounts to calling the method __add__()
on f
. To have a look at the source code of this method, we use the double question mark:
We see that the method __add__()
is implemented at the level of the class Element
from which DiffScalarField
inherits, via CommutativeAlgebraElement
. In the present case, left
= f
and right
= 2*CM.one()
have the same parent, namely the algebra CM
, so that the actual result is computed in the line
This invokes the method _add_()
(note the single underscore on each side of add
). This operator is implemented at the level of ScalarField
, as it can be checked from the source code:
This reflects a general strategy in SageMath: the arithmetic Python operators __add__
, __sub__
, etc. are implemented at the top-level class Element
, while the specific element subclasses, like ScalarField
here, implement single-underscore methods _add_
, _sub_
, etc., which perform the actual computation when both operands have the same parent.
Looking at the code, we notice that the first step is to search for the charts in which both operands of the addition operator have a coordinate expression. This is performed by the method common_charts()
; in the current case, we get the two stereographic charts defined on :
In general, common_charts()
returns the charts for which both operands have already a known coordinate expression or for which a coordinate expression can be computed by a known transition map, as we can see on the source code:
Once the list of charts in which both operands have a coordinate expression, the addition is performed at the chart function level. The code for the addition of chart functions defined on the same chart is (recall that fU
is the chart function representing in chart XU
):
We notice that the addition is performed on the symbolic expression with respect to the symbolic engine currently at work (SageMath/Pynac, SymPy,...), as returned by the method expr()
. Let us recall that the user can change the symbolic engine at any time by means of the method set_calculus_method()
, applied either to a chart or to an open subset (possibly M
itself). Besides, we notice in the code above that the result of the symbolic addition is automatically simplified, by means of the method _simplify
. It invokes a chain of simplification functions, which depends on the symbolic engine (See here for details).
Let us now discuss the second case in the __add__
method of Element
, namely the case for which the parents of both operands are different. This case is treated via SageMath coercion model, which allows one to deal with additions like
A priori, f + 2
is not a well defined operation, since the integer does not belong to the algebra . However SageMath manages to treat it because can be coerced (i.e. automatically and unambigously converted) via CM(2)
into a element of , namely the constant scalar field whose value is :
This happens because there exists a coercion map from the parent of , namely the ring of integers (denoted ZZ
in SageMath), to :