ecterrab

Use Multi-Index summation...

Answered: ecterrab 14605

September 11 2015

4 11

Hi shzan,

Besides Carl's suggestion of a loop, you can also enter your problem directly as you suggested, so as a double sum, where one of the summation index is . For that purpose you need to redefinesum through the Physics package (it just extends the syntax to what you want plus a few other enhancements). So,

>

(1)

Now go ahead as you intended, in one go, for instance,

>

Sum(Sum(2^m*(D@@k)(f)*(D@@j)(f), j+k = m-1), m = 1 .. 5)

(2)

>

2*f^2+8*D(f)*f+16*(D@@2)(f)*f+8*D(f)^2+32*(D@@3)(f)*f+32*(D@@2)(f)*D(f)+64*(D@@4)(f)*f+64*(D@@3)(f)*D(f)+32*(D@@2)(f)^2

(3)

You see this is the same result as you get using Carl's loop, or his suggested rewriting of your problem in terms of a single index j (possible in this example, but not always possible)

>

2*f^2+8*D(f)*f+16*(D@@2)(f)*f+8*D(f)^2+32*(D@@3)(f)*f+32*(D@@2)(f)*D(f)+64*(D@@4)(f)*f+64*(D@@3)(f)*D(f)+32*(D@@2)(f)^2

(4)

To know more about redefinesum, check the help page of what's new in Physics in Maple 18

Download Multi-Index_summation.mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

The results look correct to me....

Answered: ecterrab 14605

September 11 2015

2 2

Hi

The results you get in your worksheet look correct to me. I corrected anyway one or two things in your input lines, added comments, and verifications. I note that you also do not say that something is wrong anywhere, you just ask whether the results are correct. Anyway, I imagine you got in doubt due to a subtletly motivating this answer below: when you compute a covariant derivaive passing a tensor component as argument, if that tensor component gets evaluated into a scalar before arriving at D_, the command receives a scalar, so the output does not contain a Christoffel symbol. It is different when the tensor component e.g. 'N[1]' arrives at D_. The details are as follows (and I suggest you to update to the latest version of Physics in order to reproduce what you see next):

>

(1)

>

with(Physics):

>

(2)

>

$g[mu, nu] = (Matrix(4, 4, {(1, 1) = -A(r), (1, 2) = 0, (1, 3) = 0, (1, 4) = 0, (2, 2) = B(r), (2, 3) = 0, (2, 4) = 0, (3, 3) = C(r)*r^2, (3, 4) = 0, (4, 4) = C(r)*r^2*sin(theta)^2}, storage = triangular[upper], shape = [symmetric]))$

(3)

>

(4)

>

(5)

>

${Physics:-D_[mu], Physics:-Dgamma[mu], N[nu], Physics:-Psigma[mu], Physics:-Ricci[mu, nu], Physics:-Riemann[mu, nu, alpha, beta], Physics:-Weyl[mu, nu, alpha, beta], Physics:-d_[mu], Physics:-g_[mu, nu], Physics:-Christoffel[mu, nu, alpha], Physics:-Einstein[mu, nu], Physics:-KroneckerDelta[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], Physics:-SpaceTimeVector[mu](X)}$

(6)

You have already defined N, no need to define it again (changes nothing)

>

This definition of Lambda could be problematic if F contains mu because the index would appear repeated more than once - just have in mind this.

>

(7)

Here there is a mistake: you defined N[nu] in a way that depends on (r). But then you add again that functionality, so depending on the operation you do you will have N[1](r) = (-A(r)^(1/2))(r) = (A(r)(r))^(1/2). I correct here that mistake

>

(8)

>

(9)

>

${Physics:-D_[mu], Physics:-Dgamma[mu], N[nu], Physics:-Psigma[mu], Physics:-Ricci[mu, nu], Physics:-Riemann[mu, nu, alpha, beta], T[nu], Physics:-Weyl[mu, nu, alpha, beta], Physics:-d_[mu], Physics:-g_[mu, nu], Physics:-Christoffel[mu, nu, alpha], Physics:-Einstein[mu, nu], Physics:-KroneckerDelta[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], Physics:-SpaceTimeVector[mu](X)}$

(10)

>

(11)

In addition, for testing purposes I will define a H[mu,nu] tensor:

>

(12)

>

${Physics:-D_[mu], Physics:-Dgamma[mu], H[mu, nu], N[nu], Physics:-Psigma[mu], Physics:-Ricci[mu, nu], Physics:-Riemann[mu, nu, alpha, beta], T[nu], Physics:-Weyl[mu, nu, alpha, beta], Physics:-d_[mu], Physics:-g_[mu, nu], Physics:-Christoffel[mu, nu, alpha], Physics:-Einstein[mu, nu], Physics:-KroneckerDelta[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], Physics:-SpaceTimeVector[mu](X)}$

(13)

>

(14)

>

(1/4)*(diff(A(r), r))^2/(B(r)*A(r)^(3/2))

(15)

>

So your first question is about correctness of this result (15) But, is there something that makes you think is wrong?

In any case what follows below is what I would do to verify this result for correctness, but first let's agree on the meaning of this expression:

`&Dscr;`[mu](N[1]) = eval(`&Dscr;`[mu](N[nu]), nu = 1)

The relevant thing here is that the computation of the covariant derivative having a tensor component for argument will include a Christoffel term. So the operation is performed in two steps: first compute with nu, then replace nu by the number 1. Because , what I am saying is also that this is the meaning of the expression you are asking:

Lambda(N[1]) = eval(Lambda(N[nu]), nu = 1)

I will check now that the result (15) for T[1] is correct, through four different ways.

1) Expand the covariant derivatives in which is the same as rewriting it in terms of Christoffel symbols and noncovariant derivatives, then make . This is the general approach, and the important thing is that you remove all covariant derivatives D_ before introducing any tensor component.

>

(16)

>

(17)

Sum over the repeated indices

>

(1/4)*(diff(A(r), r))^2/(B(r)*A(r)^(3/2))

(18)

That is the same you got in one go in (15) for T[1]. By the way note that you can also simplify (16), then evaluate

>

(19)

>

(1/4)*(diff(A(r), r))^2/(B(r)*A(r)^(3/2))

(20)

2) A different path: sum first, then make

>

(21)

>

(22)

>

(1/4)*(diff(A(r), r))^2/(B(r)*A(r)^(3/2)) = (1/4)*(diff(A(r), r))^2/(B(r)*A(r)^(3/2))

(23)

3) This is a third way, one step at a time so that you can verify the results by eye. For that purposes use the first derivative represented by H

>

(24)

>

(25)

>

(26)

So work with (24), start expanding

>

(27)

By eye this result is correct. Next:

>

(28)

>

(29)

This result above is also correct by eye, you can check all the signs in the Christoffel symbols. Next:

>

(30)

>

(1/4)*(diff(A(r), r))^2/(B(r)*A(r)^(3/2))

(31)

Again the same result.

4) Try computing directly a TensorArray for this definition

>

(32)

>

Array(%id = 18446744078362242094)

(33)

So we have arrived to the same result going through four different paths. Is there something concrete making you think this result would be incorrect?

Next you ask

>

To answer this other question, again, it is key here that the covariant derivative operator knows whether its argument is or not a tensor. So Let's first agree on the meaning:

Lambda(Phi(r)*N[1]*N[1]) = eval(Lambda(Phi(r)*N[alpha]*N[beta]), {alpha = 1, beta = 1})

Then start with

>

(34)

>

(35)

>

(36)

>

(1/2)*(-Phi(r)*(diff(A(r), r))^2+2*A(r)^2*(diff(diff(Phi(r), r), r)))/(B(r)*A(r))

(37)

Now, you will not get the same result if you enter

>	Lambda(Phi(r)N[1]N[1])

(B(r)*((diff(A(r), r))*Phi(r)+A(r)*(diff(Phi(r), r)))*Physics:-d_[mu](Physics:-g_[`~2`, `~mu`], [X])+(diff(diff(Phi(r), r), r))*A(r)+(diff(diff(A(r), r), r))*Phi(r)+(Physics:-Christoffel[`~mu`, mu, nu]*A(r)*B(r)*Physics:-g_[`~2`, `~nu`]+2*(diff(A(r), r)))*(diff(Phi(r), r))+Physics:-Christoffel[`~mu`, mu, nu]*Phi(r)*(diff(A(r), r))*Physics:-g_[`~2`, `~nu`]*B(r))/B(r)

(38)

>

(1/2)*(2*(diff(diff(Phi(r), r), r))*A(r)^2*B(r)*r*C(r)+2*(diff(diff(A(r), r), r))*Phi(r)*A(r)*B(r)*r*C(r)+(diff(A(r), r))^2*C(r)*B(r)*Phi(r)*r+5*A(r)*(r*B(r)*C(r)*(diff(Phi(r), r))+(2/5)*(-(1/2)*r*C(r)*(diff(B(r), r))+B(r)*((diff(C(r), r))*r+2*C(r)))*Phi(r))*(diff(A(r), r))+2*A(r)^2*(-(1/2)*r*C(r)*(diff(B(r), r))+B(r)*((diff(C(r), r))*r+2*C(r)))*(diff(Phi(r), r)))/(A(r)*B(r)^2*r*C(r))

(39)

And why is that? Because when you input Lambda(Phi(r)*N[1]*N[1]), N[1] gets evaluated into a scalar function before D_[mu] could perceive it is a tensor:

>

(40)

You can check this with a simpler example:

>

(41)

>

(42)

>

{--> enter Physics:-D_[mu], args = -A(r)^(1/2)

<-- exit Physics:-D_[mu] (now in Upsilon) = -(1/2)*(diff(A(r), r))*Physics:-g_[mu, ~2]/A(r)^(1/2)}

You see: a scalar function entered D_, and so the result has no Christoffel symbols. N[1] gets evaluated into a scalar function before D_[mu] can touch it. Compare with passing N[1] to D_[mu]

>

{--> enter Physics:-D_[mu], args = N[1]

<-- exit Physics:-D_[mu] (now at top level) = -(1/2)*(diff(A(r), r))*Physics:-g_[mu, ~2]/A(r)^(1/2)-Physics:-Christoffel[~alpha, 1, mu]*N[alpha]}

Now you see N[1] arrives at D_[mu], allowing for perceiving that it is the first component of a tensor, so that there is a Christoffel symbol in the output, and in this way we have the correct meaning, as said lines above, repeating here:

`&Dscr;`[mu](N[1]) = eval(`&Dscr;`[mu](N[nu]), nu = 1)

Summarizing: all the results you get look correct to me, and you need to remember, when passing tensor components to procedures that then call D_: those procedures (e.g. your Lambda) will evaluate the tensor component (e.g you N[1]) before forwarding it to D_, so that D_ will receive a scalar instead of the component of a tensor and you will miss the Christoffel symbol.

Download tensor_correct_(reviewed).mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

simplify(expression, size)...

Answered: ecterrab 14605

September 10 2015

4 2

Hi Rouben

Try please simplify(your_expression, size) and you get what you want.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

PDEtools:-dcoeffs...

Answered: ecterrab 14605

August 31 2015

3 0

Check the help page of PDEtools:-dcoeffs, it does what you are looking for, just enter

PDEtools:-dcoeffs(PDE, u(x,y)).

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Ordering of free indices - improvement...

Answered: ecterrab 14605

August 19 2015

3 0

Hi

The issue: in a tensorial expression, there is no way to tell which free index comes first. The TransformCoordinates command was using Maple's sort command, and sort([~a, b]) returns [b, ~a]. Therfore, the result you obtained coincides with the transpose of what you expected. This doesn't mean you are wrong in what you were expecting but rather that TransformCoordiantes was in need of a new optional argument, to indicate the ordering of the freeindices, as in freeindices = [~a, b]. It is also true that when you are transforming a tensor, not a tensorial expression, one can assume that the ordering of the indices is exactly the one found in the tensor, so for a case like the one you posted, it should not be necessary to indicate the ordering of the free indices: transforming A[~a, b] should automatically take [~a, b] as the ordering of the free indices.

All this is now implemented, see my comments below, italized, with input in 2D format to distinguish from yours that is in 1D format. As usual, the improvement is available for download at the Maplesoft R&D Physics webpage.

>

restart

>	with(Physics):

>	Setup(mathematicalnotation = true):

>	ds := dx[1]^2+dx[2]^2+dx[3]^2:

>	Setup(coordinates = (X = [x[1], x[2], x[3]]), dimension = 3, metric = ds, spacetimeindices = lowercaselatin, quiet):

>

g_[]

g[a, b] = (Matrix(3, 3, {(1, 1) = 1, (1, 2) = 0, (1, 3) = 0, (2, 2) = 1, (2, 3) = 0, (3, 3) = 1}, storage = triangular[upper], shape = [symmetric]))

(1)

>	A[a, b] = Matrix(3, 3, {(1, 1) = 2, (1, 2) = 1, (1, 3) = 3, (2, 1) = 2, (2, 2) = 3, (2, 3) = 4, (3, 1) = 1, (3, 2) = 2, (3, 3) = 1})

A[a, b] = (Matrix(3, 3, {(1, 1) = 2, (1, 2) = 1, (1, 3) = 3, (2, 1) = 2, (2, 2) = 3, (2, 3) = 4, (3, 1) = 1, (3, 2) = 2, (3, 3) = 1}))

(2)

>	Define(%):

(3)

>

A[]

A[a, b] = (Matrix(3, 3, {(1, 1) = 2, (1, 2) = 1, (1, 3) = 3, (2, 1) = 2, (2, 2) = 3, (2, 3) = 4, (3, 1) = 1, (3, 2) = 2, (3, 3) = 1}))

(4)

>

A[`~`]

A[`~a`, `~b`] = (Matrix(3, 3, {(1, 1) = 2, (1, 2) = 1, (1, 3) = 3, (2, 1) = 2, (2, 2) = 3, (2, 3) = 4, (3, 1) = 1, (3, 2) = 2, (3, 3) = 1}))

(5)

>	A[`~a`,b,matrix]

A[`~a`, b] = (Matrix(3, 3, {(1, 1) = 2, (1, 2) = 1, (1, 3) = 3, (2, 1) = 2, (2, 2) = 3, (2, 3) = 4, (3, 1) = 1, (3, 2) = 2, (3, 3) = 1}))

(6)

>	A[`a`,~b,matrix]

A[a, `~b`] = (Matrix(3, 3, {(1, 1) = 2, (1, 2) = 1, (1, 3) = 3, (2, 1) = 2, (2, 2) = 3, (2, 3) = 4, (3, 1) = 1, (3, 2) = 2, (3, 3) = 1}))

(7)

>

>	[y[1] = x[1]-x[2], y[2] = x[2]-x[3], y[3] = x[3]]

(8)

>	solve((8), {x[1], x[2], x[3]})

(9)

OK; # note however that you only need to pass these fewer arguments to perform the computation

>

B[a, b] = Matrix(%id = 18446744078235230446)

(10)

I comment here your 1D input

>	# B[a,b] = TransformCoordinates((9), A[a, b], [y[1], y[2], y[3]], [x[1], x[2], x[3]], simplifier = `@`(`simplify/size`, simplify))

OK

>

B[`~a`, `~b`] = Matrix(%id = 18446744078235279598)

(11)

>	# C[a,b] = TransformCoordinates((9), A[~a,~b], [y[1], y[2], y[3]], [x[1], x[2], x[3]], simplifier = `@`(`simplify/size`, simplify))

OK

>

B[a, `~b`] = Matrix(%id = 18446744078235269590)

(12)

>	# D[a,b] = TransformCoordinates((9), A[a,~b], [y[1], y[2], y[3]], [x[1], x[2], x[3]], simplifier = `@`(`simplify/size`, simplify))

>

Was "unable to decide the ordering of the free indices", now it is deterministic when the object being transformed it is a tensor - itself- i.e. not a tensorial expression and there is a new optional argument, freeindices of type list, so that you can not only specify the ordering of the new indices but also indicate less of them, to only transform a restricted number of them, perhaps one at a time, a useful new feature.

>

B[`~a`, b] = Matrix(%id = 18446744078235257782)

(13)

>	# E[a, b] = TransformCoordinates((9), A[~a,b], [y[1], y[2], y[3]], [x[1], x[2], x[3]], simplifier = `@`(`simplify/size`, simplify))

should be
> LinearAlgebra:-Transpose(rhs())

Matrix(3, 3, {(1, 1) = 0, (1, 2) = -2, (1, 3) = -3, (2, 1) = 1, (2, 2) = 2, (2, 3) = 5, (3, 1) = 1, (3, 2) = 3, (3, 3) = 4})

Check the new functionality, transform only one index at a time

>

Vector[column](%id = 18446744078272589566)

(14)

>

Vector[column](%id = 18446744078272580414)

(15)

>

Download Transformation_tensor_components_(reviewed).mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

plots:-plotcompare(function_or_expresssi...

Answered: ecterrab 14605

August 16 2015

3 1

In my opinion, the best visualization you can have of a complex function, or for the case an arbitrary complex expression, is the one that you get using plotcompare; check its help page, use the option 'expression_plot'. In brief, you will see two 3D plots side by side: the first one shows the real part of the function on the vertical axis versus the real (x) and imaginary (y) parts of the complex variable (z) on the horizontal (complex) plane, while the second 3D plot shows you the imaginary part of the function on the vertical axis against x and y.

I find these two 3D plots much easier to rapidly decipher with my brain than the corresponding plots you can get using conformal3d, complexplot3d.

The options provided by plotcompare to zoom, shift or scale ranges, manipulate each plot and automatic assignment to a variable _P for further manipulations without having to recompute things are also valuable extra features. The way this command interacts with assuming (real or imaginary) is also very handy. Finally, the possibilty to in addition compare complex expressions visually (in which case you receive four 3D plots instead of two) is for me fantastic.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Definitions are equivalent and bug fixed...

Answered: ecterrab 14605

August 05 2015

3 0

Hi Jschulzb

Defining tensors as arrays is equivalent to defining them as algebraic expressions that, in turn, frequently involve other tensors, as in the example you posted. There was however a bug, subtle, not less of a bug though. This bug is fixed, and the fix is available for download for everybody in the usual place, the Maplesoft R&D Physics webpage.

Details: the Lie derivative of h[a, b], involving three covariant derivatives with all of their indices covariant, is defined as LKh. Then your expression rho (the one within the worksheet you posted) involves some of the derivatives with contravariant indices in the derivand. All that is OK. But then to compute the actual value of these expressions you need to expand these covariant derivatives into the corresponding non-covariant derivatives d_[mu](...) plus Christoffel terms, you know. These Christoffel terms, in turn, have a sign that depends on the character of the indices (covariant or contravariant) of the derivand. The bug: there was one place where these covariant derivatives (in LKh) were first expanded, so that the terms involving christoffel symbols were appearing with a sign corresponding to the covariant character found in the definition of LKh, and then they were evaluate at contravariant values of some of these indices (those of the derivand), but at that point the sign of the Christoffel terms were the ones corresponding to covariant instead of contravariant indices of the derivand.

Not so easy to cross with this bug. Nicely spotted, thanks for posting about the problem. As said the fix is available for download for everybody in the usual place, the Maplesoft R&D Physics webpage.

Regarding the actual difference betrween the two ways of defining tensors, using algebraic expressions:

the defintion of tensors is more natural (similar to paper and pencil computations)
you can define tensors in terms of tensorial expressions that involve other tensors, possibly defined in terms of other algebraic tensorial expressions involving yet other tensors and so on. This is a very flexible way of defining tensors.
if you change the definition of a tensor entering any of these nested levels of definitions, the change is taken into account everywhere.
You can compute with the algebraic definitions, including simpification taking Einstein's sum rule into account, in ways you cannot do with Array definitions.

Depending on what you are working on, these features of the definition of tensors in terms of algebraic tensorial expressions can be relevant and simplify your work in significant ways.

By the way: I see you introduced a Killing Vector. Maybe you already know, maybe not: within Physics there is already a command very easy to use to compute Killing vectors, also with a number of features; if you were not aware, it is worth giving a look at the corresponding help page. (Physics:-KillingVectors).

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

use Physics:-Assume, not assume...

Answered: ecterrab 14605

July 28 2015

4 7

The problem is in your use of 'assume'. I don't mean you are doing something "wrong", just that the assume command is incompatible with VectorCalculus, DifferentialGeometry, Physics, etc. . From you post it is clear that this should be emphasized more. The problem: assume redefines the variables. So, after you input "assume(theta::whatever)", the variable theta is different from the variable theta "before that call to assume " (i.e. when you defined the metric check the order of your input lines below).

For this reason, in Maple 2015, a new command, Physics:-Assume, that is compatible with VectorCalculus, DifferentialGeometry, Physics, etc., got introduced. A discussion about this is present in the page for what is new in Physics in Maple 2015 .(check please the section on the new command Assume, and the related examples).

Likewise, if you updated your Physics library with the one available on the Maplesoft R&D Physics webpage, you will see that now you can use the `assuming` command with Physics:-Assume (open the Physics:-Setup() applet and tick the corresponding box), so that now `assuming` is also fully compatible with all these Maple packages.

Below you find the results using Physics:-Assume instead of assume, but in this case you get the same without using any form of assumptions. My text is italized and my input is in 2D format, so you can distinguish it from yours (that I kept untouched) because yours is in 1D input format (the maroon ASCII letters).

>	#Error in D_[] restart: with(Physics): Setup(mathematicalnotation = true): ds2 := 1/(r^2cos(theta)^2)(-dt^2 + dr^2 + r^2*dtheta^2);

(dtheta^2*r^2+dr^2-dt^2)/(r^2*cos(theta)^2)

(1)

>	Setup(dimension = 3, coordinatesystems = (N = [t, r, theta]), metric = ds2):

$`Detected \`t\`, the time variable, in position 1. Changing the signature of the spacetime metric accordingly, to: + - - `$

$`Default differentiation variables for d_, D_ and dAlembertian are: `*{N = (t, r, theta)}$

(2)

So in the above you entered the metric with variables . But if you now call assume, the variable that is part of the metric (entered before calling assume) will be different than the variable after you call assume.

So: do not use assume. Use Physics:-Assume instead. Please see also the explanation about the difference in the third paragraph of the Description in the help page of Physics:-Assume. Here I comment your input that uses 'assume' and replace it with a call to Assume. It does all the same, just without redefining the variables, without changing them into something else.

.

>	Assume(theta<Pi/2, theta>-Pi/2); # assume(theta<Pi/2, theta>-Pi/2)

(3)

Continue now with your computation

>	Setup(spacetimeindices = lowercaselatin);

(4)

>	W[a,b] = Matrix(3,3, {(1, 1) = mu, (2,2) = musin(theta)^2, (3,3) =mur^2cos(theta)^2, (2,3) = mursin(theta)cos(theta)}, shape = symmetric): Define(%):

(5)

The simplest way to give a look at the components of W is actually this one:

>

W[a, b] = Matrix(%id = 18446744078437576702)

(6)

or, for the contravariant components:

>

W[`~a`, `~b`] = Matrix(%id = 18446744078437571510)

(7)

>	TensorArray(W[a,b]);

$Matrix(3, 3, {(1, 1) = mu, (1, 2) = 0, (1, 3) = 0, (2, 1) = 0, (2, 2) = mu*sin(theta)^2, (2, 3) = mu*r*sin(theta)*cos(theta), (3, 1) = 0, (3, 2) = mu*r*sin(theta)*cos(theta), (3, 3) = mu*r^2*cos(theta)^2})$

(8)

>	B[d,e,f] = D_[d](W[e,f]);

(9)

>	Define(%, quiet):

The simplest input to generate the nonzero components of a tensor is, for instance in the case of B,

>

$B[a, b, c] = {(1, 1, 2) = mu/r, (1, 1, 3) = -sin(theta)*mu/cos(theta), (1, 2, 1) = mu/r, (1, 3, 1) = -sin(theta)*mu/cos(theta), (2, 1, 1) = 2*mu/r, (2, 2, 2) = 4*mu*sin(theta)^2/r, (2, 2, 3) = mu*(4*cos(theta)^2-1)*sin(theta)/cos(theta), (2, 3, 2) = mu*(4*cos(theta)^2-1)*sin(theta)/cos(theta), (2, 3, 3) = 2*mu*r*(2*cos(theta)^2-1), (3, 1, 1) = -2*sin(theta)*mu/cos(theta), (3, 2, 2) = 2*mu*(2*cos(theta)^2-1)*sin(theta)/cos(theta), (3, 2, 3) = mu*r*(4*cos(theta)^2-3), (3, 3, 2) = mu*r*(4*cos(theta)^2-3), (3, 3, 3) = -4*mu*r^2*cos(theta)*sin(theta)}$

(10)

You see that

>

(11)

>

(12)

And this lhs is indeed what you were looking for. The right-hand side is also correct, just sum over the repeated index d

>

(13)

This is how I'd test all the components at once, in steps

>

RTABLE(18446744074180911102, anything, Array, rectangular, Fortran_order, [], 3, 1 .. 3, 1 .. 3, 1 .. 3)

(14)

>

${(1, 1, 1) = (0 = 0), (1, 1, 2) = (mu/r = mu/r), (1, 1, 3) = (-sin(theta)*mu/cos(theta) = -sin(theta)*mu/cos(theta)), (1, 2, 1) = (mu/r = mu/r), (1, 2, 2) = (0 = 0), (1, 2, 3) = (0 = 0), (1, 3, 1) = (-sin(theta)*mu/cos(theta) = -sin(theta)*mu/cos(theta)), (1, 3, 2) = (0 = 0), (1, 3, 3) = (0 = 0), (2, 1, 1) = (2*mu/r = 2*mu/r), (2, 1, 2) = (0 = 0), (2, 1, 3) = (0 = 0), (2, 2, 1) = (0 = 0), (2, 2, 2) = (4*mu*sin(theta)^2/r = 4*mu*sin(theta)^2/r), (2, 2, 3) = (mu*(4*cos(theta)^2-1)*sin(theta)/cos(theta) = mu*(4*cos(theta)^2-1)*sin(theta)/cos(theta)), (2, 3, 1) = (0 = 0), (2, 3, 2) = (mu*(4*cos(theta)^2-1)*sin(theta)/cos(theta) = mu*(4*cos(theta)^2-1)*sin(theta)/cos(theta)), (2, 3, 3) = (2*mu*r*(2*cos(theta)^2-1) = 2*mu*r*(2*cos(theta)^2-1)), (3, 1, 1) = (-2*sin(theta)*mu/cos(theta) = -2*sin(theta)*mu/cos(theta)), (3, 1, 2) = (0 = 0), (3, 1, 3) = (0 = 0), (3, 2, 1) = (0 = 0), (3, 2, 2) = (2*mu*(2*cos(theta)^2-1)*sin(theta)/cos(theta) = 2*mu*(2*cos(theta)^2-1)*sin(theta)/cos(theta)), (3, 2, 3) = (mu*r*(4*cos(theta)^2-3) = mu*r*(4*cos(theta)^2-3)), (3, 3, 1) = (0 = 0), (3, 3, 2) = (mu*r*(4*cos(theta)^2-3) = mu*r*(4*cos(theta)^2-3)), (3, 3, 3) = (-4*mu*r^2*cos(theta)*sin(theta) = -4*mu*r^2*cos(theta)*sin(theta))}$

(15)

Take the rhs of each object in (15), and check for equality (using evalb ), they all return true

>

$map(`@`(evalb, rhs), {(1, 1, 1) = (0 = 0), (1, 1, 2) = (mu/r = mu/r), (1, 1, 3) = (-sin(theta)*mu/cos(theta) = -sin(theta)*mu/cos(theta)), (1, 2, 1) = (mu/r = mu/r), (1, 2, 2) = (0 = 0), (1, 2, 3) = (0 = 0), (1, 3, 1) = (-sin(theta)*mu/cos(theta) = -sin(theta)*mu/cos(theta)), (1, 3, 2) = (0 = 0), (1, 3, 3) = (0 = 0), (2, 1, 1) = (2*mu/r = 2*mu/r), (2, 1, 2) = (0 = 0), (2, 1, 3) = (0 = 0), (2, 2, 1) = (0 = 0), (2, 2, 2) = (4*mu*sin(theta)^2/r = 4*mu*sin(theta)^2/r), (2, 2, 3) = (mu*(4*cos(theta)^2-1)*sin(theta)/cos(theta) = mu*(4*cos(theta)^2-1)*sin(theta)/cos(theta)), (2, 3, 1) = (0 = 0), (2, 3, 2) = (mu*(4*cos(theta)^2-1)*sin(theta)/cos(theta) = mu*(4*cos(theta)^2-1)*sin(theta)/cos(theta)), (2, 3, 3) = (2*mu*r*(2*cos(theta)^2-1) = 2*mu*r*(2*cos(theta)^2-1)), (3, 1, 1) = (-2*sin(theta)*mu/cos(theta) = -2*sin(theta)*mu/cos(theta)), (3, 1, 2) = (0 = 0), (3, 1, 3) = (0 = 0), (3, 2, 1) = (0 = 0), (3, 2, 2) = (2*mu*(2*cos(theta)^2-1)*sin(theta)/cos(theta) = 2*mu*(2*cos(theta)^2-1)*sin(theta)/cos(theta)), (3, 2, 3) = (mu*r*(4*cos(theta)^2-3) = mu*r*(4*cos(theta)^2-3)), (3, 3, 1) = (0 = 0), (3, 3, 2) = (mu*r*(4*cos(theta)^2-3) = mu*r*(4*cos(theta)^2-3)), (3, 3, 3) = (-4*mu*r^2*cos(theta)*sin(theta) = -4*mu*r^2*cos(theta)*sin(theta))})$

(16)

When there is D_ around and you are in doubt, it is always convenient to convert to d_ first, to make explicit the Christoffel symbols, then proceed as in above:

>

(17)

>

(18)

>

(19)

>

(20)

>

(21)

With the following input/output you can compare all the components of B after replacing that call to "assume" by a call to Physics:-Assume, with the components you were receiving using "assume" (my input: 2D format, your former input: afterwards in 1D format):

>

$B[d, e, f] = {(1, 1, 2) = mu/r, (1, 1, 3) = -sin(theta)*mu/cos(theta), (1, 2, 1) = mu/r, (1, 3, 1) = -sin(theta)*mu/cos(theta), (2, 1, 1) = 2*mu/r, (2, 2, 2) = 4*mu*sin(theta)^2/r, (2, 2, 3) = mu*(4*cos(theta)^2-1)*sin(theta)/cos(theta), (2, 3, 2) = mu*(4*cos(theta)^2-1)*sin(theta)/cos(theta), (2, 3, 3) = 2*mu*r*(2*cos(theta)^2-1), (3, 1, 1) = -2*sin(theta)*mu/cos(theta), (3, 2, 2) = 2*mu*(2*cos(theta)^2-1)*sin(theta)/cos(theta), (3, 2, 3) = mu*r*(4*cos(theta)^2-3), (3, 3, 2) = mu*r*(4*cos(theta)^2-3), (3, 3, 3) = -4*mu*r^2*cos(theta)*sin(theta)}$

(22)

>	simplify(B[d,e,f,nonzero]);

$B[d, e, f] = {(1, 1, 2) = -mu*(cos(theta)^2-2)/r, (1, 1, 3) = mu*sin(theta)*cos(theta), (1, 2, 1) = -mu*(cos(theta)^2-2)/r, (1, 3, 1) = mu*sin(theta)*cos(theta), (2, 1, 1) = 2*mu/r, (2, 2, 2) = 2*mu*sin(theta)^2/r, (2, 2, 3) = 2*mu*sin(theta)*cos(theta), (2, 3, 2) = 2*mu*sin(theta)*cos(theta), (2, 3, 3) = 2*mu*r*cos(theta)^2, (3, 2, 2) = 2*mu*sin(theta)*cos(theta), (3, 2, 3) = mu*r*(2*cos(theta)^2-1), (3, 3, 2) = mu*r*(2*cos(theta)^2-1), (3, 3, 3) = -2*mu*r^2*cos(theta)*sin(theta)}$

(23)

Finally, in typical situations you may want to experiment using assuming; if so, please remember to set it up so that it uses Physics:-Assume instead of its default use of assume. You achieve that entering, at the prompt,

>

(24)

Or likewise, open the Setup applet using

>

and check the corresponding box in the lower left side of the applet.

Edgardo S. Cheb-Terrab

Physics, Differential Equations and Mathematical Functions, Maplesoft.

>	# Results from GRTensorII version 1.79(R4)

W[r*r*`;`*r] = 4*mu*sin(theta)^2/r

W[theta*r*`;`*r] = mu*sin(theta)*(3*cos(theta)^2-sin(theta)^2)/cos(theta)

W[r*theta*`;`*r] = mu*sin(theta)*(3*cos(theta)^2-sin(theta)^2)/cos(theta)

W[r*r*`;`*theta] = 2*mu*sin(theta)*(cos(theta)^2-sin(theta)^2)/cos(theta)

>

Download NoErrorsInD_(reviewed_using_Assume).mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

No, and no bug...

Answered: ecterrab 14605

July 20 2015

4 0

Regarding your first question: no, there is no way to indicate indices that run for part of the dimension (but for space and spacetime, as you noticed).

Regarding your second question, a but report, below is your worksheet reviewed, using Maple 2015 and the latest Physics update: I cannot reproduce any bug. There are a couple of observations though, all written italized, intercalated with a few additional input lines, all entered in 2D math input mode, so you can distinguish your original lines (in 1D input mode) from my comments.

>	#Bug in Physics

>	#Restart and load packages restart: with(Physics): Setup(mathematicalnotation = true):

>

(1)

>	#Set up 3D metric with coordinates N = [t,r,theta] ds2 := 1/(r^2cos(theta)^2)(-dt^2 + dr^2 + r^2*dtheta^2); Setup(dimension = 3, coordinatesystems = (N = [t, r, theta]), metric = ds2);

(dtheta^2*r^2+dr^2-dt^2)/(r^2*cos(theta)^2)

$`Detected \`t\`, the time variable, in position 1. Changing the signature of the spacetime metric accordingly, to: + - - `$

$`Default differentiation variables for d_, D_ and dAlembertian are: `*{N = (t, r, theta)}$

$[coordinatesystems = {N}, dimension = 3, metric = {(1, 1) = -1/(r^2*cos(theta)^2), (2, 2) = 1/(r^2*cos(theta)^2), (3, 3) = 1/cos(theta)^2}]$

(2)

>	#Define h, and V tensors Define(h[mu,nu](N), V[mu](N));

${Physics:-D_[mu], Physics:-Dgamma[mu], Physics:-Psigma[mu], Physics:-Ricci[mu, nu], Physics:-Riemann[mu, nu, alpha, beta], V[mu], Physics:-Weyl[mu, nu, alpha, beta], Physics:-d_[mu], Physics:-g_[mu, nu], h[mu, nu], Physics:-Christoffel[mu, nu, alpha], Physics:-Einstein[mu, nu], Physics:-KroneckerDelta[mu, nu], Physics:-LeviCivita[alpha, mu, nu], Physics:-SpaceTimeVector[mu](N)}$

(3)

>	Setup(spaceindices = lowercaselatin);

(4)

>	#Complicated expression expression := D_[c](D_[~c](V[mu](N))) + D_[c](D_[mu](V[~c](N))) - D_[mu](D_[c](V[~c](N))) + D_[c](h[~c, mu](N)) - 1/2*D_[mu](h[~c,c](N));

Physics:-D_[c](Physics:-D_[`~c`](V[mu](N)), [N])+Physics:-D_[c](Physics:-D_[mu](V[`~c`](N)), [N])-Physics:-d_[mu](Physics:-D_[c](V[`~c`](N)), [N])+Physics:-D_[c](h[`~c`, mu](N), [N])-(1/2)*Physics:-d_[mu](h[`~c`, c](N), [N])

(5)

>	Check(expression);

(6)

In your worksheet, you show an Error message, that I keep here to compare, but right after I run the same computation and receive no error message

>	SumOverRepeatedIndices(expression); # this is the error message you show

Error, (in Physics:-SumOverRepeatedIndices) unable to handle tensor expressions as Physics:-D_[c](Physics:-d_[mu](V[`~c`](t, r, theta), [t, r, theta]), [t, r, theta])+Physics:-D_[c](Physics:-Christoffel[`~c`, 1, mu]*V[`~1`](t, r, theta), [t, r, theta])+Physics:-D_[c](Physics:-Christoffel[`~c`, 2, mu]*V[`~2`](t, r, theta), [t, r, theta])+Physics:-D_[c](Physics:-Christoffel[`~c`, 3, mu]*V[`~3`](t, r, theta), [t, r, theta])

>

Physics:-D_[1](Physics:-D_[`~1`](V[mu](N)), [N])+Physics:-D_[2](Physics:-D_[`~2`](V[mu](N)), [N])-Physics:-d_[mu](diff(V[`~1`](N), t)+V[alpha](N)*Physics:-Christoffel[`~1`, 1, `~alpha`]+diff(V[`~2`](N), r)+V[alpha](N)*Physics:-Christoffel[`~2`, 2, `~alpha`], [N])+Physics:-D_[1](h[`~1`, mu](N), [N])+Physics:-D_[2](h[`~2`, mu](N), [N])-(1/2)*Physics:-d_[mu](h[`~1`, 1](N)+h[`~2`, 2](N), [N])

(7)

At this point you perform an operation over one expression, then over another, then you expect to be able to perform the same operation over their sum. BUT: the free indices of both expressions are not the same, so the error message you see is correct, and points to the problem. Let's see:

>

(8)

These are the repeated (not relevant here) and free indices (relevant)

>

(9)

>	#Part 1: okay, no error SumOverRepeatedIndices((8));

(10)

Now the expression you use in Part 2 a couple of lines below:

>

(11)

>

(12)

You see that the free indices detected in (9) , that is , are not the same as the single free index detected in (12), that is So while summing over thre repeated indices of (11) alone or (8) alone is fine, summing over the repeated indices of the sum is not fine because the two subexpressions have not the same free indices. Hence the following two results

>	#Part 2: okay, no error SumOverRepeatedIndices((11));

(13)

>	#Both seem to be okay, but if we add them it breaks #Part 1 +2: SumOverRepeatedIndices((8) + (11));

Error, (in Physics:-CheckIndices) found different free indices in different operands of a sum; in operand 1: [mu, ~c], in operand 2: [mu]

>	#Why is SumOverRepeatedIndices adding things with different free indices? 'expression' clearly has the correct number of indices

As said, (8) + (11) is an incorrectly formed tensorial expression, because the free indices of each subexpression are not the same. For that reason, if you check the addition of subexpressions itself, you receive the same message, indicating what the problem is

>

Error, (in Physics:-Check) found different free indices in different operands of a sum; in operand 1: [mu, ~c], in operand 2: [mu]

>

>	#This didn't work in Maple 18 (newest Physics package) but works in Maple # 2015. expression2 := D_[nu](D_[~nu](V[mu](N))) + D_[nu](D_[mu](V[~nu](N))) - D_[mu](D_[nu](V[~nu](N))) + D_[nu](h[~nu, mu](N)) - 1/2*D_[mu](h[~nu,nu](N));

Physics:-D_[nu](Physics:-D_[mu](V[`~nu`](N)), [N])-Physics:-d_[mu](Physics:-d_[nu](V[`~nu`](N), [N]), [N])-Physics:-d_[mu](Physics:-Christoffel[`~nu`, alpha, nu], [N])*V[`~alpha`](N)-Physics:-Christoffel[`~nu`, alpha, nu]*Physics:-d_[mu](V[`~alpha`](N), [N])+Physics:-D_[nu](h[`~nu`, mu](N), [N])-(1/2)*Physics:-d_[mu](h[`~nu`, nu](N), [N])

(14)

>	Check(expression2);

(15)

The Physics package is changing substantially at every release. I cannot explain at this point why it didn't work in Maple 18, nor I have Maple 18 at hands. But I see everything working correctly in current Maple (that is Maple 2015) and, in the material presented in this worksheet, I see no bug.

Regarding the length of this summation: you can always apply a simplifier. This is what you obtained:

>	SumOverRepeatedIndices(expression2);

(16)

This is what I obtain by just simplifying by size

>

(17)

This answer is actually small enough

>

(18)

Tip: you can compact this further, one line less, by using the display implemented in PDEtools:

>

(19)

>

Download Physics_(no_Bug)_reviewed.mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Physics...

Answered: ecterrab 14605

July 13 2015

1 3

I don't know what is the type of computation you are trying to perform, but if it where just from your post I'd say it is simpler using the Physics package - check for instance the help page for Physics,Christoffel; you see the answer to your question in the Examples section.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

PDEtools and details...

Answered: ecterrab 14605

July 09 2015

3 1

In Maple, the packages that implement symmetries are DEtools (restricted to symmetries of 1 ODE) and PDEtools (more general, can handle PDE systems). Both supersede the old and limited liesym, as well as DESOLV (which by the way is not official Maple).

Now, if the ODE, or for the case a PDE system, is not of higher degree in the highest derivatives, the determining equations are of course always linear in the infinitesimals and their derivatives. Otherwise the answer involves more details but, for the case of a single ODE, the determining PDE system can always be written linear in the infinitesimals and their derivatives, and radicals of the right-hand side of the ODE (this is equivalent to isolating the highest derivative in ODE in terms of radicals or RootOf).

You can try with one example, for instance this equation of degree 2 in y'': ODE := diff(y(x), x, x)^2 = f(x, y(x), diff(y(x), x)). Try now DEtools[gensys](ODE, [xi, eta](x,y)) for the determining PDE for point symmetry infinitesimals, and you see it is linear in [xi, eta](x,y) and their derivatives, but involve fractional powers of f(x, y(x), diff(y(x),x)). If you want to avoid the presence of these fractional powers when ODE is of higher degree in the highest derivative, then you will necessarily get higher degree in the infinitesimals and their derivatives in the determining PDE system. To see this, enter for instance PDEtools:-DeterminingPDE(ODE, integrabilityconditions = false).

Both DEtools and PDEtools have a large number of detailed help pages regarding all of their symmetry commands, which also cover all the steps of the symmetry approach.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

convert(...,

Answered: ecterrab 14605

July 09 2015

1 0

Hi ClearBlueSky (what a name! :)

In Maple you can attempt converting to elementary functions, to Sum, to Int, using the convert command. The details and myriad of options are explained in the help page convert,to_special_function.

Now, there are two relevant things to take into account

By all means, most functions do not have an elementary form representation, unless perhaps their parameters have very special values. For example, enter FunctionAdvisor(specialize, BesselJ, sin) and you will see that the elementary form (i.e. in terms of the elementary function sin) happens when the first parameter is equal to 1/2. You can also try FunctionAdvisor(specialize, GAMMA) for instance, so without specifying the target function, and you will see all the specializations and related conditions that are known to the system.
When you convert using the convert command, the conversion will happen only if the conditions shown by the FunctionAdvisor are met. For example, convert(LambertW(z), Sum) does not perform any conversion, but then if you enter FunctionAdvisor(sum_form, LambertW(z)) you see there is a condition to be met: abs(z) < 1/exp(1). So try now convert(LambertW(z), Sum) assuming abs(z) < 1/exp(1) and you will see the conversion happening.

In summary: you can convert expressions to elementary or sum or int, etc forms in many cases, Maple is excellent at that, but not all functions admit that conversion, and the way to go is to interactively investigate the specializations using the FunctionAdvisor while performing the conversions using convert and perhaps also assuming.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

two issues...

Answered: ecterrab 14605

July 08 2015

1 1

Hi CytochromeC

The first one is that in the procedure ppwaveNP you define in your worksheet (at the end, in equation (8)), you wrote pdsolve(Sys, ...) while it should be pdsolve(Syst, ...). The second problem is that you are sending the tensor structures constructed with DifferentialGeometry directly to pdsolve - I believe you intend to send the coefficients of D_u, D_w, etc. instead? Note that although you see the DifferentialGeometry structures as algebraic sums, that display is obtained through display routines only, the actual structures are not sums but functions, say as in "_DG([[tensor, ...], ...])".

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

missing information?...

Answered: ecterrab 14605

July 04 2015

2 1

Hi

If in your worksheet I enter Gamma[~1,1,2] * Gamma[~1,2,1], I do not receive Gamma[~1,2,1]^2. Then if I enter gamma_[~a,b,c], that is, that tensor whose components are the Ricci rotation coefficients, it has all the components equal to 0 because the spacetime metric is of Minkowski (i.e. Galilean) type. So I suppose your post misses some piece of information?

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Results are actually correct and handles...

Answered: ecterrab 14605

June 08 2015

1 0

Hi Age,

I thought, as said in my previous answer, that SumOverRepeatedIndices was not handling noncommutative products. Looking at this now, however, I see that I implemented noncommutative tensors 3 years ago. So there is no issue about this (details below).

Besides that, there was this other issue, where you used the letter a as a parameter in the spacetime metric, but also as a tetrad index, causing a level of ambiguity in the definition of tensors where the same letter is useed with these two different meanings. This problem, however, is detectable whithin Define (when you define the tensors) - I implemented this detection last Friday.

In summary:

•	SumOverRepeatedIndices does handle noncommutative products of tensor components, and the result it returns is actually correct (unlike what you suggested, see details below)

•	The issue of using one letter with two different meanings, although I recommend against doing that, it is now worked around automatically within Define when you define a tensor.

So could you please revise the material below? Mainly, I show, step by step, that the results returned are actually correct, unlike what you suggested. Your input/output is as found in the worksheet you posted (you use no "Execution group boundaries", i.e. the document mode) while my feedback does have "Execution group boundaries" (typical of worksheet mode), is italized and in blue color. My first feedback starts after equation (17).

Note the version of Physics is as of today, you need this to have in place that workaround to using one letter with two different meanings.

(1)

(2)

(3)

eta[a, b] = (Matrix(2, 2, {(1, 1) = 1, (1, 2) = 0, (2, 2) = -1}, storage = triangular[upper], shape = [symmetric]))

(4)

g[mu, nu] = (Matrix(2, 2, {(1, 1) = 1, (1, 2) = 0, (2, 2) = -1}, storage = triangular[upper], shape = [symmetric]))

(5)

Coords := [t, x];

(6)

(7)

Physics:-Setup(metric = a^2*x^2*Physics:-d_(t)^2-Physics:-d_(x)^2);

$Physics:-Christoffel[mu, nu, alpha] = {(1, 1, 2) = a^2*x, (1, 2, 1) = a^2*x, (2, 1, 1) = -a^2*x}$

(8)

eta[a, b] = (Matrix(2, 2, {(1, 1) = 1, (1, 2) = 0, (2, 2) = -1}, storage = triangular[upper], shape = [symmetric]))

(9)

`&efr;`[a, mu] = (Matrix(2, 2, {(1, 1) = x*a, (1, 2) = 0, (2, 1) = 0, (2, 2) = 1}))

(10)

(11)

eta[a, b] = (Matrix(2, 2, {(1, 1) = 1, (1, 2) = 0, (2, 2) = -1}, storage = triangular[upper], shape = [symmetric]))

(12)

(13)

$g[`~mu`, `~nu`] = (Matrix(2, 2, {(1, 1) = 1/(a^2*x^2), (1, 2) = 0, (2, 2) = -1}, storage = triangular[upper], shape = [symmetric]))$

(14)

(15)

$Matrix(2, 2, {(1, 1) = a^2*x^2, (1, 2) = 0, (2, 1) = 0, (2, 2) = -1})$

(16)

Set up my own tetrads

$eNew_[`~a`, mu] = (Matrix(2, 2, {(1, 1) = x*a, (1, 2) = 0, (2, 1) = 0, (2, 2) = 1}))$

(17)

The problem: in the definition above you used the letter a as a parameter, but also as a tetrad index, that is prone to problems, although now the situation is detected within Define, and so handled as one would expect when computing with paper and pencil.

"`&efr;`[a]^(mu)=[[[1/(x a),0],[0,-1]]]"

(18)

$eNew_[a, `~mu`] = (Matrix(2, 2, {(1, 1) = 1/(x*a), (1, 2) = 0, (2, 1) = 0, (2, 2) = 1}))$

(19)

$g[mu, nu] = (Matrix(2, 2, {(1, 1) = a^2*x^2, (1, 2) = 0, (2, 2) = -1}, storage = triangular[upper], shape = [symmetric]))$

(20)

The following computation within TensorArray was getting corrupted because this double meaning of the letter a. As said this situation is now detected when you define your tetrad and so not a problem anymore, and the result by TensorArray is now correct:

Matrix(2, 2, {(1, 1) = 1 = 1, (1, 2) = 0 = 0, (2, 1) = 0 = 0, (2, 2) = -1 = -1})

(21)

# Have I done something incorrect here? Should these not match?

Matrix(2, 2, {(1, 1) = 1 = 1, (1, 2) = 0 = 0, (2, 1) = 0 = 0, (2, 2) = -1 = -1})

(22)

$Matrix(2, 2, {(1, 1) = a^2*x^2 = a^2*x^2, (1, 2) = 0 = 0, (2, 1) = 0 = 0, (2, 2) = -1 = -1})$

(23)

Calculate the Spin-Connection Gamma_mu:

$[algebrarules = {%AntiCommutator(g[`~a`], g[`~b`]) = 2*Physics:-Tetrads:-eta_[`~a`, `~b`]}]$

(24)

Note that the meaning of this rule is:

>

Matrix(%id = 18446744078569396334)

(25)

That is: , and the same for .

S_[`~a`, `~b`] = Physics:-`*`(Physics:-`^`(4, -1), Physics:-Commutator(g[`~a`], g[`~b`]))

S_[`~a`, `~b`] = (1/2)*Physics:-Tetrads:-eta_[`~a`, `~b`]-(1/2)*Physics:-`*`(g[`~b`], g[`~a`])

(26)

$Physics:-Christoffel[`~gamma`, mu, nu] = {(1, 1, 2) = 1/x, (1, 2, 1) = 1/x, (2, 1, 1) = a^2*x}$

(27)

Define spin connection:

(28)

${Physics:-D_[mu], Physics:-Dgamma[mu], Physics:-Psigma[mu], Physics:-Ricci[mu, nu], Physics:-Riemann[mu, nu, alpha, beta], Physics:-Weyl[mu, nu, alpha, beta], Physics:-d_[mu], eNew_[`~a`, mu], Physics:-Tetrads:-e_[a, mu], Physics:-Tetrads:-eta_[a, b], g[`~a`], Physics:-g_[mu, nu], Physics:-Tetrads:-gamma_[a, b, c], Physics:-Tetrads:-l_[mu], Physics:-Tetrads:-lambda_[a, b, c], Physics:-Tetrads:-m_[mu], Physics:-Tetrads:-mb_[mu], Physics:-Tetrads:-n_[mu], omega_[a, b, mu], Physics:-Christoffel[mu, nu, alpha], Physics:-Einstein[mu, nu], Physics:-KroneckerDelta[mu, nu], Physics:-LeviCivita[mu, nu], Physics:-SpaceTimeVector[mu](X)}$

(29)

$omega_[a, b, mu] = {(1, 2, 1) = -a, (2, 1, 1) = a}$

(30)

(31)

Gamma_[mu] = (1/4)*omega_[a, b, mu]*Physics:-`*`(g[`~a`], g[`~b`])

(32)

$Gamma_[mu] = (Matrix(1, 2, {(1, 1) = (1/2)*a*g[`~2`]*g[`~1`], (1, 2) = 0}))$

(33)

Your sentence could be read ambigously: This result (33) by SumOverRepeatedIndicdes is not wrong nor it is the case that the command is wrong swapping noncommutative tensor components.

In steps:

>

(1/4)*omega_[a, b, mu]*Physics:-`*`(g[`~a`], g[`~b`])

(34)

>

(1/4)*omega_[1, 1, mu]*Physics:-`^`(g[`~1`], 2)+(1/4)*omega_[2, 1, mu]*Physics:-`*`(g[`~2`], g[`~1`])+(1/4)*omega_[1, 2, mu]*Physics:-`*`(g[`~1`], g[`~2`])+(1/4)*omega_[2, 2, mu]*Physics:-`^`(g[`~2`], 2)

(35)

You see SumOverRepeatedIndices is not swapping the noncommutative .

Next,

>

omega_[a, b, 1] = Matrix(%id = 18446744078678529438)

(36)

From the above, you see that (35) at is indeed equal to

>

(1/4)*a*Physics:-`*`(g[`~2`], g[`~1`])-(1/4)*a*Physics:-`*`(g[`~1`], g[`~2`])

(37)

In turn, this can be simplified using (see (25)); so applyking this Anticommutor to the second term of (37) we have

>

(1/2)*a*Physics:-`*`(g[`~2`], g[`~1`])

(38)

Therefore, this following result is not wrong but actually correct:

>

Gamma_[mu] = Array(%id = 18446744078679920998)

(39)

Now, if you prefer to see on the lhs of , you can always sort the operands in products accordingly, the way you prefer, for example (see the help section for SortProducts within the help page for Physics:-Library ):

>

Gamma_[mu] = Array(%id = 18446744078680654542)

(40)

-(1/4)*(Physics:-`*`(g[`~1`], g[`~2`])-Physics:-`*`(g[`~2`], g[`~1`]))*g[`~1`]/x

(41)

(42)

I would expect g[1] g[2] g[1] / 2x = - g[2]/2x

I think however that (41) is actually correct. In steps:

>

-(1/4)*Physics:-`*`(g[`~1`], g[`~2`], g[`~1`])/x+(1/4)*Physics:-`*`(g[`~2`], Physics:-`^`(g[`~1`], 2))/x

(43)

The expansion is OK by eye. Simplify now each operand separatedly

>

[-(1/4)*Physics:-`*`(g[`~1`], g[`~2`], g[`~1`])/x, (1/4)*Physics:-`*`(g[`~2`], Physics:-`^`(g[`~1`], 2))/x]

(44)

The second one:

>

(45)

This result is correct, because

Now the first one

>

(46)

This result is also correct.

In steps, from (25),

>

(47)

>

(48)

>

(49)

Substitute now (49) in the second operand of (44) and you see you get (45). Alternatively, sort the operands of altogether

>

[(1/4)*Physics:-`*`(g[`~2`], Physics:-`^`(g[`~1`], 2))/x, (1/4)*Physics:-`*`(g[`~2`], Physics:-`^`(g[`~1`], 2))/x]

(50)

And taking into account that you again arrive at (45)

In summary: in my view, unlike what you suggested (am I missing something?), everything actually works correctly and as expected, and SumOverRepeatedIndices handles noncommutative operands, unlike what you suggested might be the case in your post.

>

Download Correcting_-_Tetrads_(reviewed).mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

E-Mail Address:
Password:
Remember Me:	Automatically sign in on future visits

E-Mail Address:
Password:
Remember Me:	Automatically sign in on future visits

Ask a Question

Create a Post

14605 Reputation

24 Badges

MaplePrimes Activity

These are answers submitted by ecterrab

Use Multi-Index summation...

The results look correct to me....

simplify(expression, size)...

PDEtools:-dcoeffs...

Ordering of free indices - improvement...

plots:-plotcompare(function_or_expresssi...

Definitions are equivalent and bug fixed...

use Physics:-Assume, not assume...

No, and no bug...

Physics...

PDEtools and details...

convert(...,

two issues...

missing information?...

Results are actually correct and handles...

Save this setting as your default sorting preference?

Ask a Question

Create a Post

Generating PDF…

Save this setting as your default sorting preference?
Note: You can change your preference any time in your account settings
Don't show this again