xPand: Bug in Conformal on Scalar heads

[Jolyon Bloomfield]

Hi,

I think I've found a bug in the Conformal function of xPand, as it pertains to scalar heads. Here, I load up a standard manifold etc, and define a scalar function V. Consider the following statements.

Conformal[g, gah2][-CD[-b]@\[CurlyPhi][] CD[b]@\[CurlyPhi][]]
Conformal[g, gah2][Scalar[-CD[-b]@\[CurlyPhi][] CD[b]@\[CurlyPhi][]]]
Conformal[g, gah2][V[-CD[-b]@\[CurlyPhi][] CD[b]@\[CurlyPhi][]]]

The first statement is conformally transformed correctly.
In the second statement, the conformal transformation doesn't seem to pass through the Scalar head (even though it removes it).
In the third statement, the argument of the scalar function doesn't get transformed.

The reason I care is that I'm playing with k-essence models, which include functions of this sort.

Any suggestions?

Thanks,
Jolyon

[Leo Stein]

Hi Jolyon,

Yikes, the first one of not going into Scalar is pretty bad! I think the following should do the trick. In xPand.nb, in Main functions > Conformal transformation, in the definition of Conformal, there is a block of rule transformations that starts with

res = (beforeputtingconfheads
   (* Dirty case of scalar functions *)
   /. f_?ScalarFunctionQ[ex_] :> ConfHead[metric1, metric2][f[ex]]

and so on. Conformal can be made to recurse into isolated Scalar[] subexpressions by adding a line like

res = (beforeputtingconfheads
    (* Recurse into isolated Scalar subexpressions *)
    /. Scalar[ex_] :> Scalar[Conformal[metricbase][metric1, metric2]@ex]
   (* Dirty case of scalar functions *)
   /. f_?ScalarFunctionQ[ex_] :> ConfHead[metric1, metric2][f[ex]]

Similarly, Conformal can be made to recurse into the arguments of a ScalarFunction by modifying the following rule, like

res = (beforeputtingconfheads
    (* Recurse into isolated Scalar subexpressions *)
    /. Scalar[ex_] :> Scalar[Conformal[metricbase][metric1, metric2]@ex]
   (* Dirty case of scalar functions *)
   (* Also recurse into the argument of a ScalarFunction *)
   /. f_?ScalarFunctionQ[ex_] :> ConfHead[metric1, metric2][f[Conformal[metricbase][metric1, metric2]@ex]]

Actually, the rule that is there is a bit too restrictive, since it only allows a ScalarFunction of one argument. It could be made more general like 

f_?ScalarFunctionQ[args___] :> ConfHead[metric1, metric2][ f@@(Conformal[metricbase][metric1, metric2]/@{args}) ]

There is a corresponding rule that should be replaced in RulesConf:

(* Not really satisfactory but minimalist for scalar functions *)
ConfHead[metric1, metric2][f_?ScalarFunctionQ[expr_]] :> Simplify[confa2^((ConformalWeight[f])/2), Assumptions -> confa > 0] f[expr]

should be replaced with

(* Not really satisfactory but minimalist for scalar functions *)
ConfHead[metric1, metric2][f_?ScalarFunctionQ[args___]] :> Simplify[confa2^((ConformalWeight[f])/2), Assumptions -> confa > 0] f[args]

I think this should work!

Leo

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

[Jolyon Bloomfield]

Hi Leo,

Thanks for the quick response. The Scalar head now works properly, but the ScalarFunction is now being overcompensated (picking up a^-4 instead of a^-2). Something funny is going on here, as can be seen in the output of the following commands:

Conformal[g, gah2][Scalar[RicciScalarCD[]]]
Identity @@ Conformal[g, gah2][V[RicciScalarCD[]]] // ToCanonical

I don't think this problem stems from the code you provide above.

Thanks,
Jolyon

[Leo Stein]

Oh, no! Sorry, I hadn't fully appreciated how Conformal works. You'll have to ignore most of my previous message. Recursing is not right. Sorry about that.

The problem actual problem in your context is that IndicesDown and the internal function SeparateIndicesDownOfInverseMetric are not separating out the explicit metric dependence of X=CD[-a]@φ[] CD[a]@φ[] when X appears inside of Scalar. Notice the difference between IndicesDown@X and IndicesDown@Scalar@X.

You don't run into your problem if you make the metric dependence explicit in X.

I'm not going to make any comments about getting IndicesDown to separate out the metric dependence, because I'm clearly not being very careful tonight. Somebody else will have to comment on that.

The only part of my previous message that you should retain is letting a ScalarFunction act on multiple arguments, but there should not be any recursion. So you should have

   (* Dirty case of scalar functions *)

   /. f_?ScalarFunctionQ[ex___] :> ConfHead[metric1, metric2][f[ex]]

in Conformal, and 

(* Not really satisfactory but minimalist for scalar functions *)
ConfHead[metric1, metric2][f_?ScalarFunctionQ[args___]] :> Simplify[confa2^((ConformalWeight[f])/2), Assumptions -> confa > 0] f[args]

in RulesConf.

Sorry for all the confusion.

Leo

[Cyril Pitrou]

Dear Leo and Jolyon,

Thanks a lot for testing so much the Conformal function.
Clearly the scalar function could have several arguments so I have modified the line

f_?ScalarFunctionQ[ex___] :> ConfHead[metric1, metric2][f[ex]]

according to Leo's suggestion.

Now the problem mentionned by Jolyon comes from the fact that FindIndices, and thus IndicesOf, does not
go through Scalar heads and scalar functions. This is made on purpose in xTensor, and probably for good reasons.

So a way to circumvent this is to teach IndicesDown that it should go inside Scalar heads and scalar functions.
See the notebook attached for an example where this is done by adding new rules to IndicesDown.

For the moment, we do not see any good reason why it could be bad to include these rules in xPand.
If you have an idea of the potentials problems that it could raise, we would be glad to hear it.
Otherwise, we will add these new rules in xPand, to make sure that Conformal goes inside Scalar heads and scalar functions.

Cheers,
Cyril

[Jose]

Hi,

> Now the problem mentionned by Jolyon comes from the fact that FindIndices,
> and thus IndicesOf, does not go through Scalar heads and scalar functions.
> This is made on purpose in xTensor, and probably for good reasons.

Yes. That's the key property of Scalar: it shields its indices from
the exterior, and that's precisely why you can have v[a]*Scalar[v[a]w[-
a]] without xTensor complaining that there are repeated indices. This
is implemented by making FindIndices ignore the argument of Scalar, or
the arguments of the scalar functions, or the Dir arguments (the
vectors in Dir, LieD and Bracket). I collectively call these the
"isolated" arguments.

For consistency, I typically prefer functions not to go inside Scalar.
I guess bad things could happen if two functions are working together
and one sees the internals of Scalar but the other does not, though I
cannot give you any particular example right now. There are exceptions
and some functions (mainly ToCanonical, MakeRule and
ScreenDollarIndices) do look inside Scalar and Dir arguments. If you
are interested in how this works, look for the xTensor functions
having Isolated in their name.

> So a way to circumvent this is to teach IndicesDown that it should go
> inside Scalar heads and scalar functions.
> See the notebook attached for an example where this is done by adding new
> rules to IndicesDown.

The Scalar objects are always well localized, so it is usually safer
to have additional rules Scalar[expr] :> Scalar[function[expr]] that
do whatever you need, rather than bypassing FindIndices.

Cheers,
Jose.

[Cyril Pitrou]

Hi,

You are right. It is better if functions do not go inside Scalars.
So I will use your approach

function[expression]/.Scalar[expr_] :> Scalar[function[expr]]

In the case of Conformal, the indices are separated using IndicesDown, and with this method it can go inside Scalar heads and scalar functions. I have implemented this very small change in the version of xPand which is online (if your are interested Jolyon, you can just go back to the xPand webpage and download) and it seems to work fine.

Conformal is needed for xPand because for cosmological perturbations there is an overall conformal transformation.

I have tried to implement this function in the most general way because I knew it ccould be useful in other contexts.
Basically it just coordinates the various xTensor functions which are necessary (ChristoffelToGradConformal, ChangeCovD, ChangeCurvature). OK It does a bit more than that, but there is nothing complicated in it.

Probably when the implementation is satisfactory (my coding is always a bit dirty...) and reliable (that's what the xAct user seem to be testing now!), this could be part of xTensor, because people might find strange to download a perturbation package in order to perform a task which is completely unrelated.

Have a nice Easter week-end,

Cyril