Elementary mathematical objects in xTensor`.
Symbols defined with type ConstantSymbol represent constants with respect to all kinds of derivatives. In particular, they are given attribute Constant.
Constant-symbols are defined with DefConstantSymbol and undefined with UndefConstantSymbol. Possible options at definition time are Dagger and those generic for all Def-commands: Info, Master, ProtectNewSymbol and PrintAs.
The list of all currently defined constant-symbols is stored in the global variable $ConstantSymbols.
Any symbol defined as a constant-symbol is given a True upvalue for the function ConstantSymbolQ, which is defined as False on any other input.
A constant-symbol is a particular kind of constant. A constant is either a constant-symbol, a numeric symbol or a number. We use the function ConstantQ to check that something is a constant. Do not confuse ConstantQ and ConstantSymbolQ. Replacing constant-symbols by constants is safe. For instance, there is no problem in using a rule like Mass->2.
Symbols defined with type Parameter represent real parameters with some undefined range of values. Essentially they will be used as dependencies of other objects (tensors, for instance), and we will be able to take parametric derivatives of expressions (see ParamD below).
Parameters are defined with DefParameter and undefined with UndefParameter. There are no particular options at definition time, apart from those generic for all DefType commands: Info, Master, ProtectNewSymbol and PrintAs.
We do not expect parameters to be master symbols (i.e. have servants). However they can have objects, those objects which depend on the parameter. A parameter cannot be undefined if it has objects.
The list of all currently defined parameters is stored in the global variable $Parameters.
Any symbol defined as a parameter is given a True upvalue for the function ParameterQ, which is defined as False on any other output.
The parameter dependencies of a generic expression expr are obtained applying ParametersOf on expr. This is just a call to DependenciesOf on expr and then a selection (using Select and ParameterQ) of the parameters. Parameter dependencies of a tensor are obtained, following a parallel path, using the private function ParametersOfTensor. Note that the latter function expects a symbol (the tensor head), but the former expects a generic expression.
4.3. Manifolds and vector bundles
4.3.1. Manifolds
A symbol manifold with type Manifold represents a smooth, differentiable manifold of fixed dimension.
Manifolds are defined with DefManifold and undefined with UndefManifold. The syntax for definition of manifold is
DefManifold[manifold, dim, indices], where:
manifold is the symbol to be defined,
dim is a nonnegative integer or a constant-symbol, and
indices is the list of abstract indices associated to the tangent vbundle of manifold.
The list of all currently defined manifolds is stored in the global variable $Manifolds. All of them have associated upvalues True for the function ManifoldQ, which is defined as False on any other input.
The dimensionality of the manifold is stored as an upvalue of manifold for the function DimOfManifold. 0-dim and 1-dim manifolds have not been fully implemented yet.
4.3.2. Product manifolds
Given several manifolds it is possible to define their "product-manifold" structure. This is done using again DefManifold, but now the second argument is a list of the (previously defined) submanifolds. The list of submanifolds is stored as an upvalue for the function SubmanifoldsOfManifold,and give True when asked by SubmanifoldQ. The list of all defined product-manifolds is stored in the global variable $ProductManifolds, which is a subset of $Manifolds.
4.3.3. Dependencies
The manifold dependencies of a generic expression expr are obtained using applying ManifoldsOf on expr. This is just a call to DependenciesOf on expr and then a selection (using Select and ManifoldQ) of the parameters. Manifold dependencies of a tensor are obtained, following a parallel path, using the private function ManifoldsOfTensor. Note that the latter function expects a symbol (the tensor head), but the former expects a generic expression.
Dependencies are specially relevant for derivatives, where it is always important to know whether a derivative on some expression shares dependencies with that expression. This is computed via the function DisjointManifoldsQ.
4.3.4. Vector bundles ("vbundles")
Each manifold has an associated vbundle (its tangent bundle) with the same dimension, whose name is formed by joining the symbol Tangent and the name of the manifold, and which is stored as an upvalue for the function TangentBundleOfManifold.
However, in xTensor` it is possible to define more general ("inner") vbundles, of the type that are used in gauge theories. As usual in xTensor` we only worry about local properties, and therefore all our vbundles are considered products of an inner vector space and the base manifold. This is a new type of symbol:
A symbol vbundle with type VBundle represents a smooth vector bundle of fixed dimension.
Vbundles are defined with DefVBundle and undefined with UndefVBundle. The syntax for definition of vbundle is
DefVBundle[vbundle, manifold, dim, indices], where:
vbundle is the symbol to be defined,
manifold is the base manifold of vbundle,
dim is a nonnegative integer or a constant-symbol, the dimension of the vector space, and
indices is the list of abstract indices associated to vbundle.
The list of all currently defined vbundles is stored in the global variable $VBundles. All of them have associated upvalues True for the function VBundleQ, which is defined as False on any other input.
The dimensionality of the vbundle (that is, that of its vector space) is stored as an upvalue of vbundle for the function DimOfVBundle. 0-dim and 1-dim vbundles have not been implemented yet. The base manifold is stored as an upvalue of the vbundle for the function BaseOfVBundle.
4.3.5. Sum vbundles
Given several vbundles it is possible to define their "sum-vbundle" structure. This is done using again DefVBundle, but now the third argument is a list of the (previously defined) subvbundles. The list of subvbundles is stored as an upvalue for the function SubvbundlesOfVBundle,and give True when asked by SubvbundleQ. The list of all defined sum-vbundles is stored in the global variable $SumVBundles, which is a subset of $VBundles.
Dummy pairs in a vbundle can be converted into sums of dummy pairs of its vbundles using the function TraceProductDummy (with infix notation CircleDot).
4.3.6. Indices and vbundles
The list indices is stored as the first element of two in the list IndicesOfVBundle. The second element will be the list of indices internally generated when the number of registered indices in not enough. See the function NewIndexIn. Indices can be added to the first list (AddIndices) or removed from it (RemoveIndices), even though the latter is very dangerous because previous expressions are likely to get corrupted if they contain removed indices. We can get any number of abstract indices using the function GetIndicesOfVBundle. Unique (dollar-) dummy indices can be generated using DummyIn. A list of respective dollar-indices on the subvbundles of a vbundle can be obtained with SubdummiesIn.
4.4.1. Type
A symbol tensor with type Tensor represents a smooth tensor field living on some manifold. If manifold is 0-dim, then tensor is actually not a field but an algebraic object.
Tensors are defined with DefTensor and undefined with UndefTensor. The syntax for definition of tensor is DefTensor[tensor[indices], dependencies] for a tensor without symmetries and DefTensor[tensor[indices], dependencies, symmetry] in general, where:
indices is the a sequence of abstract indices denoting the type of tensor
dependencies is a list (or a single symbol) containing the manifolds tensor lives on, and/or parameters it depends upon.
symmetry is a generating set or a strong generating set describing the symmetry properties of the tensor.
The list of all currently defined tensors is stored in the global variable $Tensors. All of them have associated upvalues True for the function xTensorQ, which is defined as False on any other input. Note the difference between this function and the Mathematica built-in TensorQ (new in Mathematica 5.0).
4.4.2. Properties and options
The slot structure of the tensor (SlotsOfTensor) is stored as {-M1, M1, M2, ...}, such that the first slot is a covariant index on manifold M1, the third slot is a contravariant index on M2, etc.
The list dependencies of manifolds and/or parameters is stored as an upvalue of tensor for the function DependenciesOfTensor. The order in the list is irrelevant because it is overwritten using the private function SortDependencies, which sorts parameters before manifolds, and uses lexicographic order in both sets.If the tensor has no dependencies then use {}.A tensor is always a tensor field on the manifolds corresponding to its indices; that is, we consider that a nonscalar tensor cannot be a constant on a given manifold. This is because we need additional structure to show that a tensor field does not depend on that manifold (for example a vector field, in order to take Lie derivatives). The list of parameter dependencies can be obtained with the private function ParametersOfTensor; the list of manifold dependencies can be obtained with the private function ManifoldsOfTensor.
Using option WeightOfTensor (default value 0) we can define tensorial densities, defined as a linear combination of bases. The weight is stored as an upvalue of tensor for the function WeightOfTensor. Tensor densities are represented in output using Ashtekar's notation: weight n positive (negative) is represented adding n tildes above (below) the name of the tensor. The tildes are colored according to the bases they represent. The weight of a generic expression is computed using WeightOf.
The symmetry description of the tensor is assumed to be a generating set (head GenSet) or a strong generating set (head StrongGenSet) of the symmetry group of slot permutations. Simple cases can be constructed using the functions Symmetric, Antisymmetric and RiemannSymmetry. The information is always stored as a strong generating set being an upvalue of tensor for the function SymmetryGroupOfTensor. Handling of multiterm symmetries through Young tableaux is under development, and will be stored using the function SymmetryTableauxOfTensor. Any perm notation can be used on input, but it will always be changed to Cycles notation on numeric slots. Different slots belonging to the same orbit of the symmetry group must have the same slot structure (same manifold and same up/down character) at definition time, but this can be overwritten using the option ForceSymmetries (default is False).
Under complex conjugation (with Dagger) tensors can behave in four different ways. They can be
- Real (the default): the tensor is invariant under complex conjugation.
- Imaginary: the tensor changes sign under complex conjugation.
- Hermitian: the tensor is invariant under simultaneous complex conjugation of indices and exchange of indices between a vbundle and its conjugate.
- Complex: generic case.
This is given through the option Dagger and stored as an upvalue of Dagger for the tensor.
Apart from the usual DefType options (Info, Master, ProtectNewSymbol and PrintAs), there are other options:
FrobeniusQ: not functional now
OrthogonalTo: vectors to which the tensor is orthogonal
ProjectedWith: projectors leaving the tensor invariant
TensorID: information on how to compute components
VanishingQ: if a tensor vanishes, a delayed definition of the form tensor[___]:=0 is set.
4.4.3. Special tensors
There are three heads with special tensorial meaning. Two of them are the delta and the "generalized delta" Gdelta tensors:
delta[a, -b] is the identity tensor on the vbundle of its indices. There is no difference between this object and delta[-b, a] and actually delta is defined as symmetric (though not orderless), even though its indices are always staggered. If both its indices have the same character, then delta is inmediately converted into the (first) metric tensor of the vbundle of its indices. If one of its indices is a basis index then delta is converted into Basis, which is formally equivalent, but with the Orderless attribute.
Gdelta[a1,...,an, -b1,...,-bn] is the generalized delta tensor on any vector bundle. Its first half of indices is antisymmetric, and so it is the second half, independently. The function ExpandGdelta converts the Gdelta tensor into a linear combination of products of n delta's, as given by a determinant.
The other one has been created only for convenience: Zero represents the 0 tensor, for any indices.
4.4.4. Name generation
There are a number of tensors which are automatically defined. They are associated to other objects (vbundles, bases, connections, etc.) and their names are constructed using the function GiveSymbol, with syntax GiveSymbol[tensor, object], where tensor is one of the following reserved words:
epsilon metric totally antisymmetric tensor covariantly constant with respect to the metric
Christoffel covd Christoffel symbol associated to the connection covd and the fiducial PD
AChristoffel covd internal Christoffel symbol associated to the connection covd
Torsion covd torsion tensor associated to the connection covd
Riemann covd curvature tensor associated to the connection covd
FRiemann covd internal curvature tensor associated to the connection covd
Ricci covd Ricci tensor associated to the connection covd
TFRicci metric-covd Trace-free Ricci tensor associated to the connection metric-covd
RicciScalar metric-covd Ricci scalar associated to the metric connection metric-covd
Einstein metric-covd Einstein tensor associated to the metric connection metric-covd
Weyl metric-covd Weyl tensor associated to the metric connection metric-covd
Projector induc-metric Projector tensor on a codimension-1 surface with induced metric induc-metric
ExtrinsicK induc-metric Extrinsic curvature tensor of a codimension-1 surface with induced metric induc-metric
Acceleration vector Acceleration of vector
The symbol Christoffel can be also associated to two different covds.
4.5.1. Internal format for covariant derivatives
The format for a covariant derivative is CD[-a][expr]. The double pair of brackets roughly follows Mathematica's structure for derivatives: f'[x] is represented as Derivative[1][f][x], separating the derivative operator Derivative[1] from the object being differentiated. However we do not want to distinguish between the differentiation operator (D) and the internal representation for a derivative (Derivative). Nor we can separate the abstract object being differentiated (f) from the field variable or the indices (that would require a complete change of philosophy in xTensor`). All this means that higher derivatives must be stored as nested derivatives: CD[-a][CD[-b][expr]]. This is natural with respect to the multiple possible derivative operators, but has several drawbacks:
1. Many pairs of brackets are needed. This is partially alleviated using the prefix notation CD[-a]@CD[-b]@expr.
2. Even though CD[-a][T[-b]] is a tensor, as well as T[-b], the notations are very different. Every function acting on tensorial inputs must be prepared to receive a covariant derivative.
3. Rules for T[-a] will be replaced in derivatives of T[-a]. This can be considered a drawback or an advantage, depending on the case.
4. Because of the depth restriction in Mathematica, rules for second-or-higher derivatives of T[-a] cannot be upvalues for T.
This could be extended to other simpler formats in future versions if required by a large fractions of the users of xTensor.
4.5.2. Type
A symbol covd with type CovD represents a smooth connection or covariant derivative living on some manifold, and acting on tensor fields with indices in some vbundle having that manifold as base. If manifold is 0-dim then connections are not allowed. Rather than working with a single derivative operator and Christoffel symbols for different derivatives, we define different derivative operators for different connections, following Wald.
Covariant derivatives are defined with DefCovD and undefined with UndefCovD. The syntax for definition of covd is DefCovD[covd[-a], symbol] or DefCovD[covd[-a], vbundle, symbol], where:
a is an index on a tangent vbundle which identifies the manifold where the covariant derivative lives.
symbol is a list containing two strings: the first / last one gives the Postfix / Prefix output in StandardForm.
vbundle is the vbundle on which the covariant derivative acts. If not given it is assumed to be the (tangent) vbundle of the index a.
The list of all currently defined covariant derivatives is stored in the global variable $CovDs. All of them have associated upvalues True for the function CovDQ, which is defined as False on any other input. Do not confuse CovDQ with FirstDerQ, to be explained below.
4.5.2. Properties and options
The manifold on which the connection lives is stored as an upvalue for covd of the function ManifoldOfCovD. It is currently not possible in xTensor to define a parameter dependency for a connection. The list of vbundles on which the connection acts is stored as an upvalue for covd of the function VBundlesOfCovD (the first one is always the tangent vbundle of that manifold). The symbol of covd is stored as an upvalue of SymbolOfCovD. Which of the Postfix / Prefix formats is used is decided by the global variable $CovDFormat. A number of options are possible at definition time, concerning whether the covariant derivative has or not Torsion, Curvature or derives FromMetric, among other. The information related to these options is stored as upvalues for covd of the functions TorsionQ, CurvatureQ and MetricOfCovD, respectively. Another option is CurvatureRelations, which determines whether the contractions of the Riemann tensor must be replaced by the Ricci tensor, and the contractions of Ricci by the RicciScalar. When this option is set to False then those relations must be explicitly implemented using the function ContractCurvature. Another option is ExtendedFrom, which allows defining a derivative acting on an inner vbundle and whose action on the corresponding tangent vbundle is exactly that of a previously defined covariant derivative. Finally, Levi-Civita connections can be modified to act on densities associated to a given basis, specified through the option WeightedWithBasis, typically used through DefMetric.
All connections are assumed to be real, and so there is no need to use the Dagger option.
As usual, there are also the options ProtectNewSymbol, Master and Info.
4.5.3. The fiducial derivative
The space of covariant derivatives is an affine space, with no preferred point. It is customary, however, to choose as origin for this space a particular but unspecified ordinary derivative. We will call it PD. It has zero torsion and zero curvature. By convention, it is the origin for Christoffel tensors, as we will see below. These "partial derivatives" are not automatically commuted (see below how to do it). The canonicalization process has the option CommutePDs (default True) to control this issue. There is no metric associated to PD by default, but the user can add it.
4.5.4. Associated tensors
A number of tensors are automatically associated to each derivative: Torsion, Riemann, Ricci and the Christoffel tensor relating it to the fiducial PD. If the derivative comes from a metric then we have additionally: TFRicci, RicciScalar, Einstein, Weyl. If the derivative acts on an inner vbundle then the tensors FRiemann and AChristoffel are also automatically associated. What follows is valid for all those tensors but we use the example of Torsion: the torsion tensor associated to a connection CD is denoted with the symbol TorsionCD and this is done by calling the function GiveSymbol[Torsion, CD], whose behaviour can be freely chosen. We can also use Torsion[CD][inds], which is automatically converted into GiveSymbol[Torsion, CD][inds] and hence, by default, into TorsionCD[inds].
The Christoffel tensor is special because it is actually associated to two covariant derivatives and can be denoted as Christoffel[CD1, CD2][inds] (antisymmetric in the derivatives), which we call the Christoffel of CD1 from CD2. By Christoffel[CD][inds] we understand Christoffel[CD, PD][inds]. The expression Christoffel[CD1, CD2][inds] is automatically converted into the tensor ChristoffelCD1CD2[inds] if {CD1, CD2} are sorted lexicographically or into -ChristoffelCD2CD1[inds] in the opposite case. The tensor is defined during the process if it did not exist before. The derivative PD is always sorted last. Any Christoffel tensor (of CD1 from CD2) can be rewritten using the function BreakChristoffel as the sum of two Christoffel tensors, the first of CD1 from CD3 and the second of CD3 from CD2, for any CD3 on the same manifold as CD1 and CD2.
Not any two covariant derivatives can be related via a Christoffel tensor. This is only possible if the derivatives are "compatible" (checked with the private function CompatibleCovDsQ): they act on the same base manifold and they share the vbundles or at least one of them does not act on any inner vbundle.
We need several commands to change the order of derivatives acting on a tensor. The command CommuteCovDs exchanges the order of two (equal) derivatives identified by the user through their respective indices. SortCovDs brings the derivative operators to canonical order of their indices. Commands SortCovDsStart and SortCovDsStop turn on and off, respectively, the automatization of the function SortCovDs. The canonicalization routines commute equal covds on scalars by default, but this behaviour can be changed using $CommuteCovDsOnScalars.
There is a number of commands which change some tensors into equivalent expressions. These are: ChangeCovD (previously known as CovDToChristoffel), ChangeTorsion (previously known as TorsionToChristoffel), ChangeCurvature (previously known as RiemannToChristoffel), and the pairs RiemannToWeyl / WeylToRiemman, RicciToEinstein / EinsteinToRicci and RicciToTFRicci / TFRicciToRicci. When there is a metric we also have the pair ChristoffelToGradMetric / GradMetricToChristoffel (the first of the pair was previously known as ChristoffelToMetric).
Finally, there are several variables controlling convention signs: $RiemannSign, $RicciSign, $TorsionSign. We will find some more of these later.
4.5.5. Dependencies
Each derivative lives on a given manifold. On objects not having that manifold as a dependency the derivative gives zero. Checking this fact takes some time and xTensor does not do it automatically. The function CheckZeroDerivative is in charge of that, and its action can be automatized using CheckZeroDerivativeStart and CheckZeroDerivativeStop. The global variable $CheckZeroDerivativeVerbose turns on/off the messages reporting when CheckZeroDerivative is being used and on which object.
4.6.1. Type
A symbol metric with type Metric represents a smooth 2-symmetric field living on some manifold.
Metrics are defined with DefMetric and undefined with UndefMetric. The syntax for definition of metric is DefMetric[signdet, metric[-a, -b], covd, covdsymbols], where:
signdet gives information on the signature of the metric: it is either 0, 1, -1 or a list of integers {pluses, minuses, zeroes}
-a, -b are covariant abstract indices on the vbundle where metric is being defined
covd is the Levi-Civita connection associated to metric, with symbols covdsymbols
The list of all currently defined metrics is stored in the global variable $Metrics. All of them have associated upvalues True for the function MetricQ, which is defined as False on any other input.
4.6.2. Properties and options
A metric is always defined on a given vbundle (that of its abstract indices at definition time), which is stored as an upvalue for the function VBundleOfMetric. However, a vbundle can have several metrics (stored in the function MetricsOfVBundle). A vbundle with at least one metric gives True under the function MetricEndowedQ, and False if it has not got any metric. If there are several metrics only the first one will be used to raise and lower indices; all other metrics are called "frozen" and do not have all the expected properties for the first-metric. In particular, the inverse of a frozen metric frozen[-a, -b] is not frozen[a, b] (which is actually g[a, c] g[b, d] frozen[-c, -d], with g being the first-metric), but is defined as Invfrozen[a, b], using the head Inv.
Every metric has a unique torsionless covariant derivative, called its Levi-Civita connection and stored as an upvalue of the metric for the function CovDOfMetric. Covariant derivatives can be or not associated to a metric, and this is stored in the function MetricOfCovD, which returns Null if the connection does not derive from a metric. If this associated connection is flat then we say that the metric is flat, and this can be specified at definition time with the Boolean option FlatMetric, whose value is stored as an upvalue for FlatMetricQ.
The only invariant information associated to a metric is its signature, defined as a list of +1's, -1's and 0`s, which can be specified at definition time as the first argument of DefMetric, and is stored as an upvalue for the function SignatureOfMetric. The product of those numbers is the sign of the determinant of the metric (in any basis), and is given by the function SignDetOfMetric.
Associated to the metric we have the epsilon tensor, the uniquely defined (up to global constant) totally antisymmetric tensor. Its global sign is given by the variable $epsilonSign. The curvature tensors associated to the metric are actually those associated to its Levi-Civita connection (Riemann and Ricci). Having a metric gives us a number of additional curvature tensors: RicciScalar, Einstein, TFRicci and Weyl.
4.6.3. Product metrics
Given a number of vbundles with their respective metrics, it is possible to define a block-form "product-metric" of them using the syntax DefProductMetric[metric[-a, -b], { {vbundle1, scalar1[]}, {vbundle2, scalar2[]}, ... }, covd, covdsymbol], where:
metric[-a, -b] is the metric being defined, with indices on a previously defined sum-vbundle
scalar1[] is a scalar field on the base manifolds of vbundle2, ..., but not of vbundle1
covd is the Levi-Civita connection of metric
covdsymbol is the pair of symbols used for covd in StandardForm
The defined metric is, essentially,
scalar1[]^2 metric1[., .] + scalar2[]^2 metric2[., .] + ...
with metric1 being the first-metric of vbundle1, etc. The scalars are stored using the function MetricScalar. The list of defined all product-metrics is given by the global variable $ProductMetrics and it is always a subset of the metrics in $Metrics.
The function ExpandProductMetric converts objects associated to the product-metric into combinations of the objects associated to the sub-metrics.
4.6.4. Induced metrics
Given a metric field g and a surface-orthogonal (see FrobeniusQ) vector field v, it is possible to induce a metric h on that surface. This structure can be defined using the option InducedFrom of DefMetric. The association with the vector field v is stored in VectorOfInducedMetric. It is only possible to associate induced metrics to the first-metric of a vbundle. Induced metrics are never considered frozen metrics.
Working with induced metrics is based on the use of four objects:
- The projector onto the hypersuface. There is an inert-head acting as a formal projector, and this is constructed using the head Projector and the name of the induced metric. The projector h[a, -b] can be introduce using ProjectWith[h], and can be converted into a tensorial expression g[a, -b] - v[a] v[-b] / norm (where norm is the norm of v in the metric g) using ProjectorToMetric and its inverse MetricToProjector. Any tensor can be decomposed in parts which are parallel or orthogonal to v using InducedDecomposition.
- As with any other metric, h has an associated Levi-Civita connection, but in this case this operator is a true derivative only when acting on tensors orthogonal to v. This connection can be expressed in terms of the connection of g and projectors using ProjectDerivative.
- The Acceleration vector of v. Its sign is given by a convention stored in the variable $AccelerationSign.
- The extrinsic curvature of h, formed with the symbol ExtrinsicK. Its sign is given by a convention stored in the variable $ExtrinsicKSign. It is possible to change from the extrinsic curvature tensor to derivatives of v using the function ExtrinsicKToGradNormal and its inverse GradNormalToExtrinsicK.
4.6.5. Metric contraction
Given the metric g[-a, -b] and the vector field T[b], it is customary to denote the expression g[-a, -b]T[b] as T[-a], and the change from the former to the latter is called "contraction" in xTensor`. Contractions with a metric are never automatic (compare with the automatic contraction of delta), and are inforced using the command ContractMetric. The inverse operation is implemented in SeparateMetric. When there are several metrics on the same vbundle, only the first-metric can be contracted and separated. All other metrics are called "frozen".
There are two options for ContractMetric: OverDerivatives and AllowUpperDerivatives, with obvious meanings.
A second form of separating metrics is using the function SetCharacters, which introduces metric factors to change the characters of the indices of one or several tensors.
It is not always enough to arrive at an abstract tensor field expression. Very often we need to introduce a basis of vectors, or even a chart, in order to get the final result of a computation. xTensor` has been designed as a manipulator of abstract expressions, and therefore we need to implement bases and charts in an abstract way as well. This is implemented in the companion package xCoba`, but the types Basis and Chart have been already implemented here:
A symbol basis with type Basis represents a basis of vector fields on a given vbundle. The list of all currently defined bases is stored in the global variable $Bases. All of them have associated upvalues True for the function BasisQ, which is defined as False on any other input. The functions DefBasis and UndefBasis are defined in the package xCoba`.
In parallel, a symbol chart with type Chart represents a smooth chart on a given manifold. The list of all currently defined charts is stored in the global variable $Charts. All of them have associated upvalues True for the function ChartQ, which is defined as False on any other input. The functions DefChart and UndefChart are defined in the package xCoba`.
Apart from covariant derivatives there are other types of derivations currently supported by xTensor`:
Lie derivatives are denoted using the head LieD. The general syntax is LieD[ vector ][ expr ] where vector is any tensorial expression with a single upper abstract free index. That index is not relevant except for its character and associated vbundle; we call it an ultraindex. Lie derivatives can be expanded using a covariant derivative with the function LieDToCovD.
Lie brackets are denoted using the head Bracket. The general syntax is Bracket[a][vect1, vect2] where vect1 and vect2 are two contravariant vector fields with free ultraindices. The index of the resulting vector field is a and not the ultraindex. Lie brackets can be expanded using a covariant derivative with the function BracketToCovD.
There are two kinds of parametric derivatives in xTensor`, for historical reasons. The operator Mathematica builtin OverDot has been overloaded as a derivative with respect to an arbitrary parameter. Every tensor field is assumed to depend on that parameter, unless stated otherwise. The recommended parametric derivative is, however, ParamD, with syntax ParamD[par1, par2, ...][ expr ] where par1, par2, ... are parameters (defined with DefParameter) with respect we differentiate.
A variational derivative VarD is planned for future versions.
The command FirstDerQ identifies single derivatives: it gives True on expressions of the form covd[-a], LieD[v], OverDot or ParamD[par], and False otherwise (in particular on multiple parametric derivatives).
A variational derivative VarD is planned for future versions.
| Created by Mathematica (May 16, 2008) | |