Next: Functions and Variables for itensor, Previous: itensor, Up: itensor [Contents][Index]
Maxima implements symbolic tensor manipulation of two distinct types:
component tensor manipulation (ctensor package) and indicial tensor
manipulation (itensor package).
Nota bene: Please see the note on ’new tensor notation’ below.
Component tensor manipulation means that geometrical tensor
objects are represented as arrays or matrices. Tensor operations such
as contraction or covariant differentiation are carried out by
actually summing over repeated (dummy) indices with do statements.
That is, one explicitly performs operations on the appropriate tensor
components stored in an array or matrix.
Indicial tensor manipulation is implemented by representing tensors as functions of their covariant, contravariant and derivative indices. Tensor operations such as contraction or covariant differentiation are performed by manipulating the indices themselves rather than the components to which they correspond.
These two approaches to the treatment of differential, algebraic and analytic processes in the context of Riemannian geometry have various advantages and disadvantages which reveal themselves only through the particular nature and difficulty of the user’s problem. However, one should keep in mind the following characteristics of the two implementations:
The representation of tensors and tensor operations explicitly in
terms of their components makes ctensor easy to use. Specification of
the metric and the computation of the induced tensors and invariants
is straightforward. Although all of Maxima’s powerful simplification
capacity is at hand, a complex metric with intricate functional and
coordinate dependencies can easily lead to expressions whose size is
excessive and whose structure is hidden. In addition, many calculations
involve intermediate expressions which swell causing programs to
terminate before completion. Through experience, a user can avoid
many of these difficulties.
Because of the special way in which tensors and tensor operations
are represented in terms of symbolic operations on their indices,
expressions which in the component representation would be
unmanageable can sometimes be greatly simplified by using the special
routines for symmetrical objects in itensor. In this way the structure
of a large expression may be more transparent. On the other hand, because
of the special indicial representation in itensor, in some cases the
user may find difficulty with the specification of the metric, function
definition, and the evaluation of differentiated "indexed" objects.
The itensor package can carry out differentiation with respect to an indexed
variable, which allows one to use the package when dealing with Lagrangian
and Hamiltonian formalisms. As it is possible to differentiate a field
Lagrangian with respect to an (indexed) field variable, one can use Maxima
to derive the corresponding Euler-Lagrange equations in indicial form. These
equations can be translated into component tensor (ctensor) programs using
the ic_convert function, allowing us to solve the field equations in a
particular coordinate representation, or to recast the equations of motion
in Hamiltonian form. See einhil.dem and bradic.dem for two comprehensive
examples. The first, einhil.dem, uses the Einstein-Hilbert action to derive
the Einstein field tensor in the homogeneous and isotropic case (Friedmann
equations) and the spherically symmetric, static case (Schwarzschild
solution.) The second, bradic.dem, demonstrates how to compute the Friedmann
equations from the action of Brans-Dicke gravity theory, and also derives
the Hamiltonian associated with the theory’s scalar field.
Earlier versions of the itensor package in Maxima used a notation that sometimes
led to incorrect index ordering. Consider the following, for instance:
(%i2) imetric(g);
(%o2) done
(%i3) ishow(g([],[j,k])*g([],[i,l])*a([i,j],[]))$
i l j k
(%t3) g g a
i j
(%i4) ishow(contract(%))$
k l
(%t4) a
This result is incorrect unless a happens to be a symmetric tensor.
The reason why this happens is that although itensor correctly maintains
the order within the set of covariant and contravariant indices, once an
index is raised or lowered, its position relative to the other set of
indices is lost.
To avoid this problem, a new notation has been developed that remains fully
compatible with the existing notation and can be used interchangeably. In
this notation, contravariant indices are inserted in the appropriate
positions in the covariant index list, but with a minus sign prepended.
Functions like contract_Itensor and ishow are now aware of this
new index notation and can process tensors appropriately.
In this new notation, the previous example yields a correct result:
(%i5) ishow(g([-j,-k],[])*g([-i,-l],[])*a([i,j],[]))$
i l j k
(%t5) g a g
i j
(%i6) ishow(contract(%))$
l k
(%t6) a
Presently, the only code that makes use of this notation is the lc2kdt
function. Through this notation, it achieves consistent results as it
applies the metric tensor to resolve Levi-Civita symbols without resorting
to numeric indices.
Since this code is brand new, it probably contains bugs. While it has been tested to make sure that it doesn’t break anything using the "old" tensor notation, there is a considerable chance that "new" tensors will fail to interoperate with certain functions or features. These bugs will be fixed as they are encountered... until then, caveat emptor!
The indicial tensor manipulation package may be loaded by
load("itensor"). Demos are also available: try demo("tensor").
In itensor a tensor is represented as an "indexed object" . This is a
function of 3 groups of indices which represent the covariant,
contravariant and derivative indices. The covariant indices are
specified by a list as the first argument to the indexed object, and
the contravariant indices by a list as the second argument. If the
indexed object lacks either of these groups of indices then the empty
list [] is given as the corresponding argument. Thus, g([a,b],[c])
represents an indexed object called g which has two covariant indices
(a,b), one contravariant index (c) and no derivative indices.
The derivative indices, if they are present, are appended as
additional arguments to the symbolic function representing the tensor.
They can be explicitly specified by the user or be created in the
process of differentiation with respect to some coordinate variable.
Since ordinary differentiation is commutative, the derivative indices
are sorted alphanumerically, unless iframe_flag is set to true,
indicating that a frame metric is being used. This canonical ordering makes it
possible for Maxima to recognize that, for example, t([a],[b],i,j) is
the same as t([a],[b],j,i). Differentiation of an indexed object with
respect to some coordinate whose index does not appear as an argument
to the indexed object would normally yield zero. This is because
Maxima would not know that the tensor represented by the indexed
object might depend implicitly on the corresponding coordinate. By
modifying the existing Maxima function diff in itensor, Maxima now
assumes that all indexed objects depend on any variable of
differentiation unless otherwise stated. This makes it possible for
the summation convention to be extended to derivative indices. It
should be noted that itensor does not possess the capabilities of
raising derivative indices, and so they are always treated as
covariant.
The following functions are available in the tensor package for
manipulating indexed objects. At present, with respect to the
simplification routines, it is assumed that indexed objects do not
by default possess symmetry properties. This can be overridden by
setting the variable allsym[false] to true, which will
result in treating all indexed objects completely symmetric in their
lists of covariant indices and symmetric in their lists of
contravariant indices.
The itensor package generally treats tensors as opaque objects. Tensorial
equations are manipulated based on algebraic rules, specifically symmetry
and contraction rules. In addition, the itensor package understands
covariant differentiation, curvature, and torsion. Calculations can be
performed relative to a metric of moving frame, depending on the setting
of the iframe_flag variable.
A sample session below demonstrates how to load the itensor package,
specify the name of the metric, and perform some simple calculations.
(%i1) load("itensor");
(%o1) /share/tensor/itensor.lisp
(%i2) imetric(g);
(%o2) done
(%i3) components(g([i,j],[]),p([i,j],[])*e([],[]))$
(%i4) ishow(g([k,l],[]))$
(%t4) e p
k l
(%i5) ishow(diff(v([i],[]),t))$
(%t5) 0
(%i6) depends(v,t);
(%o6) [v(t)]
(%i7) ishow(diff(v([i],[]),t))$
d
(%t7) -- (v )
dt i
(%i8) ishow(idiff(v([i],[]),j))$
(%t8) v
i,j
(%i9) ishow(extdiff(v([i],[]),j))$
(%t9) v - v
j,i i,j
-----------
2
(%i10) ishow(liediff(v,w([i],[])))$
%3 %3
(%t10) v w + v w
i,%3 ,i %3
(%i11) ishow(covdiff(v([i],[]),j))$
%4
(%t11) v - v ichr2
i,j %4 i j
(%i12) ishow(ev(%,ichr2))$
%4 %5
(%t12) v - (g v (e p + e p - e p - e p
i,j %4 j %5,i ,i j %5 i j,%5 ,%5 i j
+ e p + e p ))/2
i %5,j ,j i %5
(%i13) iframe_flag:true;
(%o13) true
(%i14) ishow(covdiff(v([i],[]),j))$
%6
(%t14) v - v icc2
i,j %6 i j
(%i15) ishow(ev(%,icc2))$
%6
(%t15) v - v ifc2
i,j %6 i j
(%i16) ishow(radcan(ev(%,ifc2,ifc1)))$
%6 %7 %6 %7
(%t16) - (ifg v ifb + ifg v ifb - 2 v
%6 j %7 i %6 i j %7 i,j
%6 %7
- ifg v ifb )/2
%6 %7 i j
(%i17) ishow(canform(s([i,j],[])-s([j,i])))$
(%t17) s - s
i j j i
(%i18) decsym(s,2,0,[sym(all)],[]);
(%o18) done
(%i19) ishow(canform(s([i,j],[])-s([j,i])))$
(%t19) 0
(%i20) ishow(canform(a([i,j],[])+a([j,i])))$
(%t20) a + a
j i i j
(%i21) decsym(a,2,0,[anti(all)],[]);
(%o21) done
(%i22) ishow(canform(a([i,j],[])+a([j,i])))$
(%t22) 0
Next: Functions and Variables for itensor, Previous: itensor, Up: itensor [Contents][Index]