[xCoba] RicciScalar[cd] returns a CTensor

[Benedict]

I hope I am not spamming this group too much - I am tinkering with the same problem and trying different approaches, but I am also facing different issues with the different approaches. Thanks to Cyril Pitrou I succeeded with xPand (thanks a lot!), but I would like to cross-check my results with a slightly different approach using xCoba, where I am currently facing some issues.

Please find attached a minimal (non) working example.

I am trying to implement a flat FLRW metric + a perturbation in a scalar-vector-tensor split. I define a manifold, a chart, and scalar functions that should act as the (space- and time-dependent) perturbations of the metric. (these shall later be split into scalars, two divergence-free vectors, an a traceless tensor). I create a matrix of the form the metric shall have. Then, I set this matrix to be the metric by using:

metric = CTensor[metricmatrix, {-ch, -ch}];

SetCMetric[metric, ch, SignatureOfMetric -> {3, 1, 0}]

cd = CovDOfMetric[metric];

Now, I'd like to get some first results, i.e. the Ricci scalar, up to first order in the perturbation. But RicciScalar[cd] returns (in a series expansion) (after 30-60 minutes of calculating).

CTensor[(6 (a^\[Prime]\[Prime])[t])/a[t]^3,{},0]

-

(2 ((CTensor^(1,{},0))[(6 (a^\[Prime]\[Prime])[t])/a[t]^3,{},0] (3 (a^\[Prime])[t] (B1^(0,1,0,0))[t,x,y,z]+a[t] (B1^(1,1,0,0))[t,x,y,z])) \[Epsilon])/a[t]^3

+

O[\[Epsilon]]^2

The weird looking result and the long computation time adumbrate an deeper error somewhere along the road. Could anyone be so kind and point in the direction of the error? How can I get an actual scalar in a reasonable amount of time?

Again, thank you very much in advance!

[Pedram Karimi]

Dear Benedict 

You should have wrote RicciScalar[cd][] since it is "Scalar". That would solve the error.

About a calculation time, since your metric has a quite complex form you have to make the simplification rule more basic by the following code

$CVSimplify = Together;

In your case it gives the result in less than a minute. I added the file in the attachment.

Best,

Pedram 

[Benedict]

Thank you very much Pedram! The code runs now, thanks to your corrections. However, if I take the full metric, where all perturbations depend on time and location, MetricCompute[metric, ch, "RicciScalar"[]] fails after about 60 to 90 minutes. It looks like it quits the kernel (all "In[ ]"s and Out[ ]"s show In[*] and Out[*], even though they were evaluated before). I assume this is due to the complexity of the metric and the fact that MetricCompute takes into account all orders - which is not necessary. Can I somehow specify that anything higher than first-order (or maybe second, in case any square roots are involved) gets neglected, to reduce computation time? Globally or specifically for the evaluation of an expression or command such as MetricCompute? I have a DefConstantSymbol[\[Epsilon]] included that represents the order.

The problem arises as soon as g12, g13, g23 are non-zero, With only a diagonal matrix + g01, g02, g03 it works and gives me the (correct) result within 40 seconds. Also, if I only consider the tensorial perturbations (g01=g02=g03=0, all others !=0), the computation succeeds (not shown in the attached notebook).

I attached a notebook to show the matrix, only considering the scalar perturbations, as they do not mix with vector and tensor perturbations at first order, so I use this approach to reduce complexity (at least a little bit). Everything after "$CVSimplify = Together;" was evaluated with a somewhat reduced metric, where g12, g13, g23=0, but otherwise with all scalar perturbations. Without those components, the computation succeeds.

[Jose]

Hi,

This may be too hard to attack with the general methods, because all metric entries are different functions of all coordinates. Still, if using the general approach, I'd recommend:

1) Do not do SetCMetric[...] or cd = CovDOfMetric[metric] too early. Those are not needed. Go directly to MetricCompute right after defining metric as a CTensor object.

2) Use MetricCompute[metric, ch, "RicciScalar"[], Verbose -> True, Parallelize -> True]. This turns on informative messages that let you know what's going on. Parallelization will also take advantage of the resources in your computer.

3) Think carefully about the simplification function to use in $CVSimplify. This function is used after every step of the computation in MetricCompute. Simplifying earlier steps usually helps in later steps. For example you can force intermediate series expansions with something like

   $CVSimplify = Function[Together[Normal[Series[#, {\[Epsilon], 1, 0}]]]]

though you must be careful with this type of simplification to avoid losing some terms if you go higher order.

Anyway, that's not how I'd do this. I'd try to use the power of xPert for perturbative computations. As I've said other times, unfortunately there is not yet a smooth transition from xPert to xCoba. However, when the computations get complicated, it is still worth the trouble of guiding manually that transition. See the attached notebook for an example in your case.

Cheers,

Jose.

[Benedict]

Thank you very very much for this outstanding answer!

Points 1) & 2) allow me to compute the RicciScalar in about 10 minutes, however, it does not use all available CPU cores (there is always 1 core at 100%, a second around 60% and maybe 4-5 cores around 10%, all others are close to 0% load (out of 16 physical cores / 32 logical cores)). Is there a global option I could set, to use parallelisation whenever possible, i.e. that for every command that knows about a Parallelize flag, it is set to true?

The notebook you attached is awesome. It computes in no time. This approach is way faster - thank you very much for writing this. I have three follow-up questions:

1) Is there a reason for loading xTensor first and then xPert and xCoba? Wouldn't xPert load xTensor anyway?

2) Is it possible to set rules containing derivatives in xCoba? The metric I use contains divergence-free vectors, so I'd like to have a rule like

MakeRule[{-Derivative[0, 1, 0, 0][B1][t[], x[], y[], z[]], Derivative[0, 0, 1, 0][B2][t[], x[], y[], z[]] + Derivative[0, 0, 0, 1][B3][t[], x[], y[], z[]]}]

but like this, higher derivatives are not cancelled, e.g. a derivative with respect to time on top of the divergence of this vector is not set to zero. Can rules be generalised, maybe with placeholders inside the Derivative[ ] part?

3) I applied the expansion to some other expressions (equations of motion). The tensorial EoM to first order fails, because Simplify takes more than 300 seconds. How can I give it more time, when Simplify is part of Collect[ ]? Or is there even a more suitable command, when a tensorial expression has to be evaluated? I attached a notebook, where the very last output deals with this. I assume that the time component / zero component, will look different than the spatial components, but all the spatial components will look "the same"—can I somehow use this to have the output "look nice"?

Again, thank you very much for your answers.

PS: I had to compress the notebook, maybe using a "nice" formatting blew up the filesize. Sorry for that.

[Sergi Sirera-Lahoz]

Hello everyone,

I had a similar problem and tried using the method proposed by Jose, but it still seems to take too long. I'm trying to compute the components of the Einstein tensor in black hole perturbation theory. The background metric is normal Schwarzschild and I'm considering only the axial perturbations. The goal is to obtain the Regge-Wheeler equation. I have tried other things too (e.g.  $CVSimplify, setting by hand the background einstein and ricci to zero) but they didn't work either. I'm probably doing something wrong but I can't figure out what.  Please have a look at the notebook below.

Many thanks,

Sergi

[Jose]

Hi,

I reattach your notebook here, changing three things:

1) The indices of the definition of axperturbation were incorrectly placed.

2) Replacement rules using RuleDelayed (:>) will recompute their RHS each time they are used. It's faster to use Rule (->) which compute things once, before replacement.

3) Change $CVSimplify to use Expand instead of Simplify. With large expressions, Simplify may be slow. Using Expand or Together may lead to faster canonicalization, even if not so complete as with Simplify.

Cheers,

Jose.

[Sergi Sirera-Lahoz]

Thank you very much for your answer Jose!

I will definitely come back here with more questions at some point. This is really helpful.

Best,

Sergi