Formulating and solving the equivalence problem for Schwarzschild metric in a simple case

In connection with the digitizing in Maple 2016 of the database of solutions to Einstein's equations of the book Exact Solutions to Einstein Field Equations. I was recently asked about a statement found in the "What is new in Physics in Maple 2016" page:

This question posed is a reasonable one: "could you please provide one example?" This post provides that example.

First of all the existing science behind: in my opinion, the main reference regarding the equivalence problem is at the paper "A Review of the Geometrical Equivalence of Metrics in General Relativity", General Relativity and Gravitation, Vol. 12, No. 9, 1980, by A. Karlhede (University of Stockholm). This approach got refined later by others and, generally speaking, it is currently know as the Cartan-Karlhede method, summarized in chapter 9.2 of the book Exact Solutions to Einstein Field Equations. whose solutions were all digitized within the Physics and DifferentialGeometry packages for Maple 2016. This method of Chapter 9.2 (see also Tetrads and Weyl scalars in canonical form, Mapleprimes post), however, is not the only approach to the problem, and sometimes simpler methods can handle the problem faster, or just in simpler forms.

The example worked out below is actually the example from Karlhede's paper just mentioned, on pages 704 - 706: "Show that the Schwarzschild metric and its form written in terms of isotropic spherical coordinates are equivalent, and derive the transformation that relates them". Because this problem happens to be simple for nowadays computer algebra, below I also tackle it modified, slightly more difficult variants of it. The approach shown works for more complicated cases as well.

Below we tackle Karlhede's paper-problem using: one PDEtools command, the Physics:-TransformCoordinates, the Physics:-Weyl command to compute the Weyl scalars and the Physics:-Tetrads:-PetrovType to see the Petrov type of the metrics involved. The transformation resolving the equivalence is explicitly derived.

Start loading the Physics and Tetrads package. To reproduce the computations below, as usual, update your Physics library with the one available for download at the Maplesoft R&D Physics webpage

To formulate the problem, set first some symbols to represent the changed metric, changed mass and changed coordinates - no mathematics at this point

Set now a new coordinates system, call it Y, involving the new coordinates (in the paper they are represented with a tilde on top of the letters)

According to eq.(7.6) of the paper, the line element of Schwarzschild solution in isotropic spherical coordinates is given by

Set this to be the metric

Check it out

In connection with the transformation used further below, compute now the Petrov type and the Weyl scalars for this metric, just to have an idea of what is behind this metric.

We see that the Weyl scalars are already in canonical form (see post in Mapleprimes about canonical forms): only  and the important thing: it depends on only one coordinate,  .

Now: we want to see if this metric (5) is equivalent to Schwarzschild metric in standard spherical coordinates

The equivalence we want to resolve is regarding an arbitrary relationship between the masses used in (5) and (8) and a generic change of variables from X to Y

Using a differential equation mindset, the formulation of the equivalence between (8) and (5) under the transformation (9) is actually simple: change variables in (8), using (9) and the Physics:-TransformCoordinates command (this is the command that changes variables in tensorial expressions), then equate the result to (5), then try to solve the problem for the unknowns ,  and .

We note at this point, however, that the Weyl scalars for Schwarzschild metric in this standard form (8) are also in canonical form of Petrov type D and also depend on only one variable, r 

The fact that the Weyl scalars in both cases ((7) and (11)) are in canonical form (only  ) and in both cases this scalar depends on only one coordinate is already an indicator that the transformation involved changes only one variable in terms of the other one. So one could just search for a transformation of the form  and resolve the problem instantly. Still, to make the problem slightly more general, consider instead a generic transformation for r in terms of all of

Transform the  coordinates in the metric (because of having used PDEtools:-declare, derivatives of the unknowns R are displayed indexed, for compact notation)

Proceed equating (14) to (5) to obtain a set of equations that entirely formulates the problem

This problem, shown in Karlhede's paper as the example of the approach he summarized, is solvable using the differential equation commands of PDEtools (in this case casesplit) in one go and no time, obtaining the same solution shown in the paper with equation number (7.10), the problem actually admits two solutions

By all means this does not mean this differential equation approach is better than the general approach mentioned in the paper (also in section 9.2 of the Exact Solutions book). This presentation above only makes the point of the paragraph mentioned at the beginning of this worksheet "... [in Maple 2016] you can also formulate and, depending on the the metrics also resolve, the equivalence problem; that is: to answer whether or not, given two metrics, they can be obtained from each other by a transformation of coordinates, as well as compute the transformation." 

In any case this problem above is rather easy for the computer. Consider a slightly more difficult problem, where . For example:

Tackle now the same problem

The solutions to the equivalence between (17) and (5) are then given by

Moreover, despite that the Weyl scalars suggest that a transformation of only one variable is sufficient to solve the problem, one could also consider a more general transformation, of more variables. Provided we exclude  (because there is  around and that would take us to solve differential equations for , that involve things like ), and also to speed up matters let's remove the change in , consider an arbitrary change in r and t

So our transformation now involve two arbitrary variables, each one depending on all the four coordinates, and a more complicated function . Change variables (because of having used PDEtools:-declare, derivatives of the unknowns R and  are displayed indexed, for compact notation)

Construct the set of Partial Differential Equations to be tackled

Solve the problem running a differential elimination (actually without solving any differential equations): there are more than two solutions

Consider for instance the first one

Compute the actual solution behind this case :

The fact that the time t appears defined in terms of the transformed time  involving an arbitrary constant is expected: the time does not enter the metric, it only enters through derivatives of  entering the Jacobian of the transformation used to change variables in tensorial expressions (the metric) in (22).

Summary: the approach shown above, based on formulating the problem for the transformation functions of the equivalence and solving for them the differential equations using the commands in PDEtools, after restricting the generality of the transformation functions by looking at the form of the Weyl scalars, works well for other cases too, specially now that, in Maple 2016, the Weyl scalars can be expressed also in canonical form in one go (see previous Mapleprimes post on "Tetrads and Weyl scalars in canonical form").  Also important: in Maple 2016 it is present the functionality necessary to implement the approach of section 9.2 of the Exact solutions book as well.

Tetrads and Weyl scalars in canonical form

The material below is about a new development that didn't arrive in time for the launch of Maple 2016 (March) and that complements in a relevant way the ones introduced in Physics in Maple 2016. It is at topic in general relativity, the computation of a canonical form of a tetrad, so that, generally speaking (skipping a technical description) the Weyl scalars are fixed as much as possible (either equal to 0 or to 1) regarding transformations that leave invariant the tetrad metric in a tetrad system of references. Bringing a tetrad in canonical form is a relevant step in the tackling of the equivalence problem between two spacetime metrics (Mapleprimes post), and it is relevant in connection with the digitizing in Maple 2016 of the database of solutions to Einstein's equations of the book Exact Solutions to Einstein Field Equations.

The reference for this development is the book "General Relativity, an Einstein century survey", edited by S.W. Hawking (Cambridge) and W. Israel (U. Alberta, Canada), specifically Chapter 7 written by S. Chandrasekhar, and more specifically exploring what is said in page 388 about the Petrov classification.

A canonical form for the tetrad and Weyl scalars admits alternate forms; the implementation is as implicit in page 388:

The transformations (rotations of the tetrad system of references) used are of Class I, II and III as defined in Chandrasekar's chapter - equations (7.79) in page 384, (7.83) and (7.84) in page 385. Transformations of Class I can be performed with the command Physics:-Tetrads:-TransformTetrad using the optional argument nullrotationwithfixedl_, of Class II using nullrotationwithfixedn_ and of Class III by calling TransformTetrad(spatialrotationsm_mb_plan, boostsn_l_plane), so with the two optional arguments simultaneously.

In this development, a new optional argument, canonicalform got implemented to TransformTetrad so that the whole sequence of three transformations of Classes I, II and III is performed automatically, in one go. Regarding the canonical form of the tetrad, the main idea is that from the change in the Weyl scalars one can derive the parameters entering tetrad transformations that result in a canonical form of the tetrad. 

(Note the Tetrads:-PetrovType command, unfinished in the first release of Maple 2016.) To run the following computations you need to update your Physics library to the latest version from the Maplesoft R&D Physics webpage, so with this datestamp or newer:

An Example of Petrov type I

There are six Petrov types: I, II, III, D, N and O. Start with a spacetime metric of Petrov type "I"  (the numbers always refer to the equation number in the "Exact solutions to Einstein's field equations" textbook)

The Weyl scalars

... there is abs around. Let's assume everything is positive to simplify formulas, use Capital Physics:-Assume  (the lower case assume  command redefines the assumed variables, so it is not compatible with Physics, DifferentialGeometry and VectorCalculus among others).

The scalars are now simpler, although still not in "canonical form" because  and .

The Petrov type

The  call to Tetrads:-TransformTetrad two lines below transforms the current tetrad ,

into another tetrad such that the Weyl scalars are in canonical form, which for Petrov "I" type happens when  and .

Despite the fact that the result is a much more complicated tetrad, this is an amazing result in that the resulting Weyl scalars are all fixed (see below).  Let's first verify that this is indeed a tetrad, and that now the Weyl scalars are in canonical form

Set (9) to be the tetrad in use and recompute the Weyl scalars

Inded we now have  and  

So Weyl scalars computed after setting the canonical tetrad (9) to be the tetrad in use are in canonical form. Great! NOTE: computing the canonicalWeyl scalars is not really the difficult part, and within the code, these scalars (11) are computed before arriving at the tetrad (9). What is really difficult (from the point of view of computational complexity and simplifications) is to compute the actual canonical form of the tetrad (9).

An Example of Petrov type II

Consider this other solution to Einstein's equation (again, the numbers in g_[[24,37,7]] always refer to the equation number in the "Exact solutions to Einstein's field equations" textbook)

Check the Petrov type

The starting tetrad

results in Weyl scalars not in canonical form:

For Petrov type "II", the canonical form is as for type "I" but in addition  Again let's assume positive, not necessary, but to get simpler formulas around

Compute now a canonical form for the tetrad, to be used instead of (14)

Set this tetrad and check the Weyl scalars again

This result (18) is fantastic. Compare these Weyl scalars with the ones (15) before transforming the tetrad.

An Example of Petrov type III

The Petrov type and the original tetrad

This tetrad results in the following scalars

that are not in canonical form, which for Petrov type III is as in Petrov type II but in addition we should have .

Compute now a canonical form for the tetrad

Set this one to be the tetrad in use and recompute the Weyl scalars

Great!

An Example of Petrov type N

The original tetrad and related Weyl scalars are not in canonical form:

For Petrov type "N", the canonical form has  and all the other .

Compute a canonical form, set it to be the tetrad in use and recompute the Weyl scalars

All as expected.

An Example of Petrov type D

The default tetrad and related Weyl scalars are not in canonical form, which for Petrov type "D" is with  and all the other

Transform the  tetrad, set it and recompute the Weyl scalars

Again the expected canonical form of the Weyl scalars, and  remains invariant under transformations of Class III.

An Example of Petrov type O

Finally an example of type "O". This corresponds to a conformally flat spacetime, for which the Weyl tensor (and with it all the Weyl scalars) vanishes. So the code just interrupts with "not implemented for conformally flat spactimes of Petrov type O"

The Weyl tensor and its scalars all vanish:

How to prove the inequality  , assuming that the  variables are nonnegative? That hard question  was asked by arqady in dxdy and answered  by himself  in a complicated way. Maple proves the inequality by the LagrangeMultipliers command which is strong. I think these calculations cannot be done by hand at all. Without loss of generality one may assume . Then

 restart:with(Student[MultivariateCalculus]):

ans := [LagrangeMultipliers((a+b+c+d)*(a*b+a*c+a*d+b*c+b*d+c*d)-12*sqrt((a^2+b^2+c^2+d^2)*a*b*c*d), [a+b+c+d-1], [a, b, c, d], output = detailed)]:

We have to remove complex solutions by
ans1:=remove(c -> has(evalf(c), I),ans):

The next big output is  only partly seen in the post (look in the attached file for the whole one).

ans2:=simplify(ans1,radical);

evalf(ans2);

Indeed, the minimum value of the target function is exactly 0. Quod erat demonstrantum.

How to prove the inequality  provided , ? That problem was posed  by Israeli mathematician nicked by himself as arqady in Russian math forum and was not answered there.I know how to prove that with Maple and don't know how to prove that without Maple. Neither  nor  work here. The difficulty consists in the nonlinearity both the target function and the main constraint. The first step is to linearize the main constraint and the second step is to reduce the number of variables to one.

restart; A := eval(x^(4*y)+y^(4*x), [x = sqrt(u), y = sqrt(v)]);

B := expand(A);

C := eval(B, u = 2-v);

It is more or less clear that the plot of F is symmetric wrt  the straight line v=1. This motivates the following change of variable  to obtain an even function.

F := simplify(expand(eval(C, v = z+1)), symbolic, power);

The plots suggest the only maximim of F at z=0 and its concavity.

Student[Calculus1]:-FunctionPlot(F, z = -1 .. 1);

Student[Calculus1]:-FunctionPlot(diff(F, z, z), z = -1 .. 1);

As usually, numeric global solvers cannot prove certain inequalities. However, the GlobalSearch command of the DirectSearch package indicates the only local maximum of  F and F''.

Digits := 25; DirectSearch:-GlobalSearch(F, {z = -1 .. 1}, maximize, solutions = 3, tolerances = 10^(-15)); DirectSearch:-GlobalSearch(diff(F, z, z), {z = -1 .. 1}, maximize, solutions = 3, tolerances = 10^(-15));

The series command confirms a local maximum of F at z=0.

series(F, z, 6);

The extrema command indicates only the value of F at a critical point, not outputting its position.

extrema(F, z); extrema(F, z, 's');

solve(F = 2);

DirectSearch:-SolveEquations(F = 2, {z = -1 .. 1}, AllSolutions, solutions = 3);

DirectSearch:-SolveEquations(F = 2, {z = -1 .. 1}, AllSolutions, solutions = 3, assume = integer);