Re: [xAct: 1163] MakeRule problem with covariant derivatives

[Leo Stein]

Hi Filippo,

I have only a partial solution for you, but I will at least explain what causes this problem. From the pattern point of view, the two expressions

  CD[-μ]@CD[-ν]@σ[] * something[...μ...]    and   CD[-ν]@CD[-μ]@σ[] * something[...μ...]

need to be matched by separate patterns (LHSs). You can of course do this manually with MakeRule. An example is

  MakeRule[{v[a] CD[-a]@CD[-b]@σ[], w[-b]}]

  MakeRule[{v[a] CD[-b]@CD[-a]@σ[], w[-b]}]

MakeRule has the attribute HoldFirst, and it is careful to keep the expressions held, (so no commutation of CovDs takes place) so these two commands will indeed generate unique rules. One of these rules matches the first situation, and one matches the second.

One solution to your problem, then, is to simply call MakeRule twice, once with each of the different LHSs. This is surprising, because MakeRule is supposed to generate the symmetry equivalent rules of some expression, and these two expressions are symmetry equivalents when $CommuteCovDsOnScalars is true and the connection has no torsion! However, from looking at MakeRule, it looks to me like MakeRule only considers the symmetries of tensors on the LHS, but *not* the additional symmetries from commuting covariant derivatives when possible. MakeRule is one of the most complicated parts of xTensor, so I can't give you a real solution to this problem (perhaps one of the gurus of xTensor will address this in a future version?).

In a bit more detail, MakeRule uses SymmetryEquivalentsOfTensor, not the more general SymmetryEquivalentsOf, to generate the various LHSs of all of its rules. Even SymmetryEquivalentsOf is actually prone to this issue of automatically commuting covariant derivatives. An example is:

  In[] := xAct`xTensor`Private`SymmetryEquivalentsOf[CD[-a]@CD[-b]@σ[]]

  Out[] := {CD[-b][CD[-a][σ[]]], CD[-b][CD[-a][σ[]]]}

identical expressions, because after generating the symmetry equivalents, xTensor then automatically sorts the covariant derivatives. A safer version of SymmetryEquivalentsOf is

  SetAttributes[xAct`xTensor`Private`SymmetryEquivalentsOf, HoldFirst];

  xAct`xTensor`Private`SymmetryEquivalentsOf[expr_, subsets___IndexList] := 

    With[{inds = FindIndices[expr]}, 

     PermuteIndices[xHold@expr, inds, #] & /@ 

      xAct`xTensor`Private`SymmetryPerms[Last@Last@SymmetryOf[Unevaluated@expr], inds, subsets]];

In actuality I don't know if the Unevaluated is needed in the call to SymmetryOf. The xHold keeps the covariant derivatives from being commuted but then you are left with held expressions. However, this at least gives

  In[] := xAct`xTensor`Private`SymmetryEquivalentsOf[CD[-a]@CD[-b]@σ[]]

  Out[] := { xHold[ CD[-a][CD[-b][σ[]]] ], xHold[ CD[-b][CD[-a][σ[]]] ] }

Anyway, for now the quick solution is to just call MakeRule twice with the two different index orders by hand. Sorry I can't help more! Only a big change to MakeRule can automate this.

Best

Leo

On Sat, Mar 23, 2013 at 8:37 AM, Filippo <guarnier...@gmail.com> wrote:

Hi all,

I found a problem with the definition of rules with MakeRule in the case of two covariant derivatives acting on a scalar.

I would like to define a Rule which implements the following identity

(CD[-μ]@CD[ν]@σ[]) (ICD[τ]@ICD[ρ]@ICD[μ]@σ[]) = (ICD[τ]@ICD[ρ]@ICD[ν]@σ[])

where CD is a covariant derivative and Sigma[] is the Synge's world-function. The only contraction is on the μ index.

The rule is not correctly applied for example to the expression with the lower v index :

(CD[-μ]@CD[-ν]@σ[]) (ICD[τ]@ICD[ρ]@ICD[μ]@σ[])

Thomas found that the problem is here with the commutation of covariant derivatives acting on scalars. MakeRule tries to commute the covariant derivatives to define the new rules but the symmetry automatically commute back the two derivatives, not allowing the rule to be defined.

Cheers,

Filippo

--
You received this message because you are subscribed to the Google Groups "xAct Tensor Computer Algebra" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xact+uns...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Thomas Bäckdahl]

Hi everyone.

I think this issue makes it clear that it is a bad idea to have automatic rules that rearranges indices. From a design point of view it is better if only the canonicalizer changes the orders of the indices. In the current version of xAct one can turn off the automatic rule for commuting derivatives on scalar by setting $CommuteCovDsOnScalars=False, but this also removes this symmetry from ToCanonical. My suggestion is to remove the automatic rule from xTensor, but still allow ToCanonical to commute derivatives on scalars if $CommuteCovDsOnScalars is set. Unfortunately this would change the behaviour of xTensor so evaluating old notebooks with a new version of xTensor could possibly give a different result. After ToCanonical it should be the same though.

The problem that MakeRule does not take into account symmetries of derivatives, is more difficult to fix. One can of course manually construct all left hand sides, but there might be many of them. If one runs ToCanonical before applying the rule this number can probably be reduced a bit. Another way is to replace the derivative with a tensor with the correct symmetry. This can be done manually or with Implode.

Regards
Thomas

[Jose]

Hi,

Thanks Filippo for this interesting thread. I have several comments:

1) I have mentioned other times how unhappy I feel about MakeRule. It
should have never existed in the first place, but now you all use it,
so I cannot remove it. In any case, as explained in http://www.xact.es/faq.html
, it is unlikely that MakeRule will be improved. Only bugs (meaning
actual wrong rules) will be fixed.

2) Commuting derivatives on the LHS of a rule when there are several
derivatives and a metric is dangerous. In the example shown, it is not
obvious to me which indices can be moved up and down. To test this I
have assumed that CD is the LeviCivita of the metric, but ICD is not.
Then, for example, you could want to write the rule as

MakeRule[{CD[ν]@CD[-μ]@σ[] ICD[τ]@ICD[ρ]@ICD[μ]@σ[],
ICD[τ]@ICD[ρ]@ICD[ν]@σ[]}, MetricOn -> All, ContractMetrics -> True]

and then MakeRule would print a message "** MakeRule: Potential
problems moving indices on the LHS." Note I have flipped the indices
in the first double derivative, to avoid the problem you mention.
xTensor wants to sort indices in postfix notation so it helps to start
with them sorted.

3) Thanks Leo for the careful diagnosis of this case. Note that
something weird in MakeRule is that it holds the LHS. That's bad for
the sort of thing we are discussing: if MakeRule was HoldRest we would
let the derivatives move automatically before start processing the
rules, and then they would match the expressions in which that
reordering has happened. In fact Rule and RuleDelayed, and IndexRule
and IndexRuleDelayed, do not hold their first argument. MakeRule was
given attribute HoldFirst to make it work properly with AutomaticRules
(another bad idea) and because it has options and conditions. Instead
of MakeRule[{LHS, RHS, conds}, options], the correct syntax should
have been something like MakeRule[ LHS :> RHS /; conds, options ],
with no attributes at all. Then it would be clearer that the objective
of MakeRule is to take one rule without patterns and return a list of
equivalent rules with patterns. Actually, I've seen some of you
writing your own interfaces to MakeRule, evaluating in advance parts
of the input.

4) I like Thomas' suggestion of decoupling what ToCanonical does from
the rest, concerning commutation of derivatives on scalars. Actually
there is a third player to consider in this game, which is
SortCovDsStart[covd]. I would say that ToCanonical should know what to
do independently of $CommuteCovDsOnScalars, and let the global
variable only control the automatic behavior. Perhaps, at most,
ToCanonical could have an option to control this locally in each
operation. Is there any case in which ToCanonical should not commute
torsionless derivatives on scalars?

Cheers,
Jose.

> >     <mailto:xact%2Bunsu...@googlegroups.com>.
> >     For more options, visithttps://groups.google.com/groups/opt_out.