## Maxima – 142 – itensor – 1 Continuo da qui, copio dal Reference Manual, PDF scaricabile da qui, sono a p.427.

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

Panico? 😐 Forse, si vedrà 😋

Nota: nuova notazione per tensor
Earlier versions of the `itensor` package in Maxima used a notation that sometimes led to incorrect index ordering. Consider the following, for instance:

``````(%i1) load(itensor)\$

(%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(%))\$
l k
(%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!

Posta un commento o usa questo indirizzo per il trackback.