
muTENSOR and REDTEN 


1) Introduction

  muTENSOR and REDTEN are computer algebra systems specializing in
General Relativity and tensor algebra. Each of these systems is
overlayed onto a basic computer algebra system that provides the
algebraic capabilities required. muTENSOR exists in a muMATH
environment on a variety of personal computers (eg. IBM AT, DEC
Rainbow), while REDTEN exists in the more powerful REDUCE environment
on larger, generally faster machines (eg. SUN, VAX). Both systems have
essentially the same syntax and capabilities, and use the same data
structures and algorithms. That both muMATH and REDUCE are lisp based
allows a great similarity in the internal details of muTENSOR and
REDTEN. As far as possible, both systems will respond in the same
fashion to equivalent inputs; exceptions occur where one must interact
directly with the underlying system.

2) Interface

  The user interface to these systems is intended to facilitate the
entry of tensor expressions directly without the need of translation
into some form adapted to the machine; object indices are enclosed in
square brackets, indicies may be raised or lowered and derivatives
taken by the appropriate operators in the index. For example, to
compute the Riemann curvature tensor from the first and second
Christoffel symbols (here named C1 and C2 respectively) one could type
(in muTENSOR):

R[a,b,c,d] :: C1[b,d,a,|c] - C1[b,c,a,|d]
                + C2[e,b,c]*C1[a,d,e] - C2[e,b,d]*C1[a,c,e];

where `|' indicates normal differentiation (and, similarly, `||'
indicates covariant differentiation); note the repeated index
indicating a contraction.

  In fact, the user ought never need to type the above expression,
since a function exists to determine the Riemann tensor given a
predefined metric. Functions also exist to compute most other objects
of interest in General Relativity, including the Christoffel symbols,
the Ricci, Weyl and Einstein tensors, Killing and geodesic equations,
Lie and covariant derivatives and others.

3) Indexed Objects and Symmetries

  The basic entity of these systems is called an `indexed object'; it
is composed of a name and a number of attached properties which
describe features of the object (eg. number of indices and their
location, either contravariant or covariant, etc.), it has also a list
of values of the components of the object. Of special importance is a
property describing the symmetries that exist among the indices of the
object; these symmetries can be used to significantly reduce the time
and space required to compute the elements of a particular object. In
the example above, what is missing is a description of the symmetries
of the Riemann tensor, which reduces the number of independent
components of this tensor from 256 to 21 (ignoring a final cyclic
symmetry). The built-in Riemann function automatically sets the
correct symmetry for this tensor; the user could have set it as well
by calling the function `mktnsr' to create the object:

mktnsr ('R, '(-1 -1 -1 -1), '((-1 1 2) (-1 3 4) (2 1 3)));

The first list describes the index structure of the object (four
covariant tensor indices), and the next the intrinsic symmetry. This
list may be read as "anti-symmetric in the first and second indices,
anti-symmetric in the third and fourth indices, and symmetric in pairs
of indices beginning with the first and third index".

  The system uses the information provided by the symmetry list to
determine a canonical index of each symmetrically related group of
indices, and stores and retrieves values for this canonical form only.
Values stored for the canonical index then have the appropriate sign
change and complex conjugation applied to produce a value for a
related index.

4) Virtual Memory

  As noted above, muTENSOR runs on smaller personal computers, and, in
particular, the limitations of muSIMP are currently such that it can
use no more than 256k bytes of memory, of which all but about 160k are
taken up by the basic muSIMP, algebra, and tensor systems. The
available work space is sufficient to complete many problems, but can
easily be filled by intermediate expressions of larger problems. To
overcome this difficulty, and noting that most personal computers now
have either more than 256k of main memory or a fast hard drive or
both, a virtual memory sub-system has been added to muTENSOR (which
does not exist in REDTEN). This system allows the user to specify that
some or all of the objects being handled by the system are to reside
either on disk or on a virtual memory drive. This frees up a large
fraction of the available internal muTENSOR memory to be used for the
calculation at hand, rather than simply being used to store objects
which are perhaps not even involved in the calculation.  Whenever an
element of an object is required, the system reads it in from the
secondary storage, uses it, and then discards it; it never becomes a
permanent resident in memory. The speed of the system when using the
disk for storage is not significantly slower than usual, since the
time to retrieve an element from disk is generally much less than the
time to do algebra with it.

5) Differences between systems

There are a few syntax differences between muTENSOR and REDTEN,
necessitated by the underlying system. These are noted below.


        muTENSOR                REDTEN               notes

          ::                      ==            indexed assignment
						(== valid in mutensor as of
						v3.83)

          :                       :=            normal assignment
                                                  (built-in to base system)

          ^                       @             raise or lower indices

          dif                     df            differentiation 
                                                  (built-in to base system)
						(df valid in mutensor as of
						v3.83)

          pdif                    pdf           partial differentiation
                                                  of indexed expressions
						(pdf valid in mutensor as of
						v3.83)

     mostly upper case      mostly lower case    

      (not required)        must pre-declare     for left side of ==
                               indexed objects

     lacks frame and        lacks virtual memory
       spinor packages       system
      (stubs present)        (not required)


      various differences between names for objects,
      eg. `R' vs. `ri' etc.


See the respective user manuals for more information about these systems.



 Permission to use this software without fee is granted subject to 
 the following restrictions:

 1. This software may not be used or distributed for direct commercial
    gain.

 2. The author is not responsible for the consequences of use of this
    software, no matter how awful, even if they arise from flaws in it.

 3. The origin of this software must not be misrepresented, either by
    explicit claim or by omission.

 4. This code may be altered to suit your need, but such alterations
    must be plainly marked and the code must not be misrepresented
    as the original software.

 5. This notice may not be removed or altered.


Suggestions and bug reports can be sent to:


John harper                    or       Charles Dyer
harper@manitou.astro.utoronto.ca        dyer@manitou.astro.utoronto.ca
