Plugging in a metric ansatz to a xTensor expression in xCoba

[Gün Süer]

Hello everyone,

I have a long abstract expression (which is actually a Lagrangian density involving a scalar field Phi coupled to gravity in various ways) that involves terms like

Sqrt[-Detg[]]EinsteinCD[-a,-b]RicciScalarCD[]CD[a][Phi[]]CD[b][Phi[]]

where Phi[] is a scalar that I have defined on my manifold. What I want to do is, I want to evaluate this expression for a specific metric ansatz in (2+1) dimensions. My metric is given by

ds^2 = -a(r)b(r)^2 dt^2 + 1/a(r) dr^2 + r^2 dtheta^2

where a(r) and b(r) functions that depend only on the radial coordinate r. They are not given explicitly, I want to work with them symbolically.

Another important point is that my scalar field Phi[] should only be a function of the radial coordinate r.

How can I evaluate my expression by plugging in my metric ansatz and demanding that the scalar field Phi[] is only a function of the radial coordinate r?

Thanks in advance.

[Jose]

Hi,

I reattach your notebook with the additional steps needed. I added some comments too. Ask again if there is something you don't understand.

If you want to automate the final step, I recommend to read the code I posted here:

https://groups.google.com/g/xAct/c/MUSbFd0pGFE/m/7_FjvX4UBQAJ

Cheers,

Jose.

[Gün Süer]

Hello,

Thank you for your quick reply. The code works quite well. But I also have many different terms, and some of them don't seem to work with the rules you have provided. It seems to me that this might be caused by index placement. I added an example to the end of your code.

23 Ekim 2021 Cumartesi tarihinde saat 22:05:00 UTC+3 itibarıyla Jose şunları yazdı:

[Jose]

Basis contraction is not automatic in xCoba. Add ContractBasis to your final command:

expr2 //. rules // ContractBasis // Simplify

Cheers,

Jose.

[Gün Süer]

Thanks. This seems to solve the problem.

23 Ekim 2021 Cumartesi tarihinde saat 23:00:38 UTC+3 itibarıyla Jose şunları yazdı:

[Gün Süer]

I kinda have a related problem. My ultimate goal for plugging this metric into the lagrangian is to obtain the euler lagrange equations of motion.

Unrelated to the metric I have provided above, I also have the so called BTZ ansatz.

So I have a particular Lagrangian in hand as an abstract expression, and I want to plug in the BTZ black hole ansatz into it, and obtain black hole solutions by varying that lagrangian. The metric ansatz is given by (6) and the equation I expect from applying variation of calculus is (7), from the paper https://arxiv.org/pdf/2004.12995.pdf

The problem is i get CTensor expressions in the euler-lagrange equations of motion. How can I fix this? 

I am attaching my notebook

Thanks in advance

24 Ekim 2021 Pazar tarihinde saat 01:47:18 UTC+3 itibarıyla Gün Süer şunları yazdı:

[Jose]

Hi again,

Your expression LagrangianGB3 is a scalar density. If you do InputForm[LagrangianGB3] you'll see a structure of the form

    CTensor[scalar, {}, polar][]

indicating that we have a scalar density of weight +1 in the polar coordinate frame. If you want a true scalar field, you can divide by Sqrt[-Determinant[metric][]] for example, and then the CTensor wrappers will disappear, because Determinant[metric][] is a scalar density of weight +2 in the same frame.

If you want to operate directly on the scalar density expression without the CTensor wrapper then use First[Head[LagrangianGB3]] in the first argument of EulerEquations.

Cheers,

Jose.

[Gün Süer]

I see. That fixed the problem. I have another question regarding xCoba. When I plug in the metric and form the Euler lagrange equations, I get results that I do not expect. They don't match with physical expectations, they contain higher derivatives etc. Is there a chance that xCoba gives wrong results for complicated expression when plugging in the metric?

24 Ekim 2021 Pazar tarihinde saat 21:58:51 UTC+3 itibarıyla Jose şunları yazdı:

[Jose]

It's difficult to rule out the presence of bugs in software of the complexity of xAct, but before we claim there is a bug we need to identify a simple example which clearly shows that there is such a bug. Otherwise the problem may be a missing non-obvious simplification, a subtle misunderstanding somewhere, etc.

Take the notebook where you think an incorrect result is produced and simplify it as much as you can while still preserving the problem. Then we can discuss that notebook.

Cheers,

Jose.