Gdelta in a basis

[Torsten Schoenfeld]

Aloha,

in a computation involving xCoba, I'm encountering problems with
products of epsilon tensors:

Needs["xAct`xCoba`"]
DefManifold[M, 3, IndexRange[{a, h}]]
DefMetric[-1, \[Eta][-a, -b], CD]
DefBasis[B, TangentM, {0, 1, 2}]

epsilon\[Eta][{1, -B}, {a, B}, {0, B}] epsilon\[Eta][{b,
B}, {2, -B}, {0, B}]

The last line throws an error about an unknown index B. I think this is
because expandGdelta recurses into the basis indices, so a fix would be
to tell Outer[] not to do this:

expandGdelta[metric_][indices___]:=Module[{semil=Length[{indices}]/2},
If[!IntegerQ[semil],
Throw@Message[Gdelta::error,
"Found Gdelta with odd number of indices."]];
Det@Outer[
metric,{indices}[[Range[semil]]],{indices}[[Range[semil+1,
2semil]]],1]];

(Patch against xTensor.m attached. [1])

But even with this fixed, the above line still results in an error:
"Recursion depth of 256 exceeded." Stack trace:

epsilon\[Eta][xAct`xTensor`Private`inds1$__]*
epsilon\[Eta][xAct`xTensor`Private`inds2$__]

SignDetOfMetric[\[Eta]]*ExpandGdelta[Gdelta[{1, -B}, {a, B}, {0, B},
{b, B}, {2, -B}, {0, B}]]

ExpandGdelta[Gdelta[{1, -B}, {a, B}, {0, B}, {b, B}, {2, -B},
{0, B}]]

ExpandGdelta[expr_]

Gdelta[{1, -B}, {a, B}, {0, B}, {b, B}, {2, -B}, {0, B}] /.
Gdelta[xAct`xTensor`Private`inds__] :> expandGdelta[delta][inds]

expandGdelta[delta][{1, -B}, {a, B}, {0, B}, {b, B}, {2, -B},
{0, B}]

expandGdelta[metric_][indices___]

...

Det[Outer[delta, {{1, -B}, {a, B}, {0, B}, {b, B}, {2, -B},
{0, B}}[[Range[semil$4003]]],
{{1, -B}, {a, B}, {0, B}, {b, B}, {2, -B}, {0, B}}[[
Range[semil$4003 + 1, 2*semil$4003]]], 1]]

Outer[delta, {{1, -B}, {a, B}, {0, B}, {b, B}, {2, -B}, {0, B}}[[
Range[semil$4003]]], {{1, -B}, {a, B}, {0, B}, {b, B},
{2, -B}, {0, B}}[[Range[semil$4003 + 1, 2*semil$4003]]], 1]

Outer[delta, {{1, -B}, {a, B}, {0, B}},
{{b, B}, {2, -B}, {0, B}}, 1]

{{delta[{1, -B}, {b, B}], delta[{1, -B}, {2, -B}],
delta[{1, -B}, {0, B}]}, {delta[{a, B}, {b, B}],
delta[{a, B}, {2, -B}], delta[{a, B}, {0, B}]},
{delta[{0, B}, {b, B}], delta[{0, B}, {2, -B}],
delta[{0, B}, {0, B}]}}

{delta[{a, B}, {b, B}], delta[{a, B}, {2, -B}],
delta[{a, B}, {0, B}]}

delta[{a, B}, {b, B}]

delta[xAct`xTensor`Private`a_, xAct`xTensor`Private`b :
{_, _Symbol}]

Basis[{a, B}, {b, B}]

Basis[xAct`xCoba`Private`a : {_, _Symbol}, xAct`xCoba`Private`b_]

SymmetryOfIndex[{a, B}]*Basis[{b, B}, {a, B}]

Basis[{b, B}, {a, B}]

Basis[xAct`xCoba`Private`a : {_, _Symbol}, xAct`xCoba`Private`b_]

And at this point it goes into an endless loop, swapping the indices of
Basis[{a, B}, {b, B}] again and again. You can see the same behavior
with just this:

Basis[a, b]

Does anyone know a way to fix this or get around it?

-Torsten

[1] By the way, how do you guys develop xAct? It seems that you modify
the .nb files which then causes the .m file to be regenerated. But when
I do this, the formatting of the .m file changes completely (maybe due
to version differences), so that's not useful for sending patches.

And the .nb files are not really human-readable, so version-controlling
them is not easily possible, right?

And when you modify an .nb (or .m) file, how do you cause a running
session to use the modified definitions? The only I came up with is to
restart the kernel, but that's very inconvenient.

[JMM]

Hi,

Very good two points. They certainly need fixing!

> epsilon\[Eta][{1, -B}, {a, B}, {0, B}] epsilon\[Eta][{b,
> B}, {2, -B}, {0, B}]
>
> The last line throws an error about an unknown index B. I think this is
> because expandGdelta recurses into the basis indices, so a fix would be
> to tell Outer[] not to do this:
>
> expandGdelta[metric_][indices___]:=Module[{semil=Length[{indices}]/2},
> If[!IntegerQ[semil],
> Throw@Message[Gdelta::error,
> "Found Gdelta with odd number of indices."]];
> Det@Outer[
> metric,{indices}[[Range[semil]]],{indices}[[Range[semil+1,
> 2semil]]],1]];

Exactly. This is indeed the proper fixing. Let me point out (for those
xAct users not familiar with diff language) that the difference is
adding the ,1 near the end. That avoids Outer getting confused with
lists of basis-indices and arrays.

> But even with this fixed, the above line still results in an error:
> "Recursion depth of 256 exceeded."

> ...

> And at this point it goes into an endless loop, swapping the indices of
> Basis[{a, B}, {b, B}] again and again. You can see the same behavior
> with just this:
>
> Basis[a, b]
>
> Does anyone know a way to fix this or get around it?

This is another problem, and completely unrelated. The problem is in
lines 546 and 547 of xCoba.m. You find

Basis[a_Symbol,b_]:=...

Basis[a:{_,_Symbol},b_]:=...

And they should be changed to

Basis[a_Symbol,b_?DownIndexQ]:=...

Basis[a:{_,_Symbol},b_?DownIndexQ]:=...

which checks that only when the second index is a lower index the
definitions will act.

> [1] By the way, how do you guys develop xAct? It seems that you modify
> the .nb files which then causes the .m file to be regenerated.

Exactly

> But when I do this, the formatting of the .m file changes completely (maybe due
> to version differences), so that's not useful for sending patches.

That's Mathematica. This is an old complaint from Mathematica users.
There are less changes in newer versions, but still too many.

> And the .nb files are not really human-readable, so version-controlling
> them is not easily possible, right?

Indeed. It is difficult.

> And when you modify an .nb (or .m) file, how do you cause a running
> session to use the modified definitions? The only I came up with is to
> restart the kernel, but that's very inconvenient.

This is what I do as well. You can also enter the private context, say

Begin["xAct`xCoba`Private`"]

(*Execute your new definitions*)

End[]

and that should have loaded your new definitions. There is the problem
of whether it was necessary to remove the previous ones. To avoid
bothering about this, I Exit[] the kernel and restart.

Thanks!
Jose.

[Torsten Schoenfeld]

JMM wrote:
> And they should be changed to
>
> Basis[a_Symbol,b_?DownIndexQ]:=...
>
> Basis[a:{_,_Symbol},b_?DownIndexQ]:=...
>
> which checks that only when the second index is a lower index the
> definitions will act.

Ah, I see. This does indeed seem to solve the problem. Thanks for this
fix, and for confirming the other one!