“Exact solutions to Einstein’s equations” is one of those books that are difficult even to imagine: the authors reviewed more than 4,000 papers containing solutions to Einstein’s equations in the general relativity literature, collecting, classifying, discarding repetitions in disguise, and organizing the whole material into chapters according to the physical properties of these solutions. The book is already in its second edition and it is a monumental piece of work.

As good as it is, however, the project resulted only in printed material, a textbook constituted of paper and ink. In 2006, when the DifferentialGeometry package was rewritten to enter the Maple library, one of the first things that passed through our minds was to bring the whole of “Exact solutions to Einstein’s equations” into Maple.

It took some time to start but in 2010, for Maple 14, we featured the first 26 solutions from this book. In Maple 15 this number jumped to 61. For Maple 17 we decided to emphasize the general relativity functionality of the DifferentialGeometry package, and Maple 18 added 50 more, featuring in total 225 of these solutions - great! but still far from the whole thing …

And this is when we decided to “step on the gas” - go for it, the whole book. One year later, working in collaboration with Denitsa Staicova from Bulgarian Academy of Sciences, Maple 2015 appeared with 330 solutions to Einstein’s equations. Today we have already implemented 492 solutions, and for the first time we can see the end of the tunnel: we are targeting finishing the whole book by the end of this year.

Wow²! This is a terrific result. First, because these solutions are key in the area of general relativity, and at this point what we have in Maple is already the most thorough digitized database of solutions to Einstein’s equations in the world. Second, and not any less important, because within Maple this knowledge comes alive. The solutions are fully searcheable and are set by a simple call to the Physics:-g_  spacetime metric command, and that automatically sets the related coordinates, Christoffel symbols , Ricci  and Riemann  tensors, orthonormal and null tetrads , etc. All of this happens on the fly, and all the mathematics within the Maple library are ready to work with these solutions. Having everything come alive completely changes the game. The ability to search the database according to the physical properties of the solutions, their classification, or just by parts of keywords also makes the whole book concretely more useful.

And, not only are these solutions to Einstein’s equations brought to life in a full-featured way through the Physics  package: they can also be reached through the DifferentialGeometry:-Library:-MetricSearch  applet. Almost all of the mathematical operations one can perform on them are also implemented as commands in DifferentialGeometry .

Finally, in the Maple PDEtools package , we already have all the mathematical tools to start resolving the equivalence problem around these solutions. That is: to answer whether a new solution is or not new, or whether it can be obtained from an existing solution by transformations of coordinates of different kinds. And we are going for it.

What follows is a basic illustration of what has already been implemented. As usual, in order to reproduce these results, you need to update your Physics library from the Maplesoft R&D Physics webpage.

Load Physics , set the metric to  (and everything else automatically) in one go

And that is all we do :) Although the strength in Physics  is to compute with tensors using indicial notation, all of the tensor components and related properties of this metric are also derived on the fly (and no, they are not in any database). For instance these are the definition in terms of Christoffel symbols , and the covariant components of the Ricci tensor

These are the 16 Riemann invariants  for Schwarzschild solution, using the formulas by Carminati and McLenaghan

The related Weyl scalars  in the context of the Newman-Penrose formalism

These are the 2x2 matrix components of the Christoffel symbols of the second kind (that describe, in coordinates, the effects of parallel transport in curved surfaces), when the first of its three indices is equal to 1

In Physics, the Christoffel symbols of the first kind are represented by the same object (not two commands) just by taking the first index covariant, as we do when computing with paper and pencil

One could query the database, directly from the spacetime metrics, about the solutions (metrics) to Einstein's equations related to Levi-Civita, the Italian mathematician

These solutions can be set in one go from the metrics command, just by indicating the number with which it appears in "Exact Solutions to Einstein's Equations"

Automatically, everything gets set accordingly; these are the contravariant components of the related Ricci tensor

One works with the Newman-Penrose formalism frequently using tetrads (local system of references); the Physics subpackage for this is Tetrads

This is the tetrad related to the book's metric with number 12.16.1

One can check these directly; for instance this is the definition of the tetrad, where the right-hand side is the tetrad metric

This shows that, for the components given by (12), the definition holds

One frequently works with a different signature and null tetrads; set that, and everything gets automatically recomputed for the metric 12.16.1 accordingly

The related 16 Riemann invariant

The ability to query rapidly, set things in one go, change everything again etc. are at this point fantastic. For instance, these are the metrics by Kaigorodov; next are those published in 1962

The search can be done visually, by properties; this is the only solution in the database that is a Pure Ratiation solution, of Petrov Type "D", Plebanski-Petrov Type "O" and that has Isometry Dimension equal to 1:

Set the solution, and everything related to work with it, in one go

The related Riemann invariants:

To conclude, how many solutions from the book have we already implemented?

:)

One of the interesting things about the Physics package is that it was designed from scratch to extend the domain of operations of the Maple system from commutative variables to one that includes commutative, anticommutative and nonocommutative variables, as well as abstract vectors and related (nabla) differential operators. In this line we have, among others, the following Physics commands working with this extended domain: `*` , `.` , `^` , diff , Expand , Normal , Simplify , Gtaylor , and Coefficients .

More recently, Pascal Szriftgiser (from Laboratoire PhLAM, Université Lille 1, France), suggested a similar approach to factorize expressions involving noncommutative variables. This is a pretty complicated problem though. Pascal's suggestion, however, spinned around an idea beautiful for its simplicity, similar to what is done in the experimental Physics command, PerformOnAnticommutativeSystem , that is, to transform the problem into one that can be treated with the command that works only with commutative variables and from there extract the result for noncommutative ones.The approach has limitations but it is surprising how far one can go using imaginative algebraic manipulations to extend these commands that otherwise only work with commutative variables.

In brief, we now have a new command, Physics:-Factor, with already powerful performance for factorizing algebraic expressions that involve commutative, noncommutative and anticommutative variables, making Maple's mathematical capabilities more advanced in very interesting directions. This command is in fact useful not just in advanced theoretical physics, but for instance also when working with noncommutative symbols representing abstract matrices (that can have dependency, and so they can be differentiated before saying anything about their components, multiplied, and be present int  expressions that in turn can be expanded, simplified and now also factorized), and also useful with expressions that include differential operators, now that within Physics you can compute with the the covariant and noncovariant derivatives D_  and d_ algebraically. For instance, how about solving differential equations using Physics:-Factor (reducing their order by means of factoring the involved differential operators) ? :)

What follows are some basic algebraic examples illustrating the novelty, and as usual to reproduce the results in this worksheet you need to update your Physics library with the one available in the Maplesoft R&D Physics webpage.

First example, because of using mathematical notation, noncommutative variables are displayed in different color (olive)

A more involved example from a physics problem, illustrating that the factorization is also happening within function's arguments, as well as that we can also correctly expand mathematical expressions involving noncommutative variables

So first expand ...

Now retrieve the original expression by recursing over the arguments and so factoring the integrand

This following one looks simpler but it is actually more complicated:

The complication consists of the fact that the standard factor  command, that assumes products are commutative, can never deal with factors like  because if products were commutative these factors are equal to 0. Of course we not just us factor but include a number of algebraic manipulations before using it, so that the approach handles these cases nicely anyway

This other one is more complicated:

When you expand,

you see that there are various terms involving the same noncommutative operands, just multiplied in different order. Generally speaking the limitation (n this moment) of the approach is: "there cannot be more than 2 terms in the expanded form containing the same operands" . For instance in (13) the 1st and 4th terms have the same operands, that are actually also present in the 5th term but there you also have  and for that reason (involving some additional manipulations) it can be handled:

Recalling, in all these examples, the task is actually accomplished by the standard factor  command, and the manipulations consist of ingeniously rewriting the given problem as one that involves only commutative variables, and from extract the correct result for non commutative variables.

To conclude, here is an example where the approach implemented does not work (yet) because of the limitation mentioned in the previous paragraph:

In this expression, the 1st, 2nd, 4th and 5th terms have the same operands  and then there are four terms containing the operands . We do have an idea of how this could be done too ... :) To be there in one of the next Physics updates.

The PDE & BC project , a very nice and challenging one, also one where Maple is pioneer in all computer algebra systems, has restarted, including now also the collaboration of Katherina von Bülow.

Recapping, the PDE & BC project started 5 years ago implementing some of the basic methods found in textbooks to match arbitrary functions and constants to given PDE boundary conditions of different kinds. At this point we aim to fill gaps, and the first one we tackled is the case of 1st order PDE that can be solved without boundary conditions in terms of an arbitrary function, and where a single boundary condition (BC) is given for the PDE unknown function, and this BC does not depend on the independent variables of the problem. It looks simple ... It can be rather tricky though. The method we implemented is a simple however ingenious use of differential invariants  to match the boundary condition.

The resulting new code, the portion already tested, is available for download in the Maplesoft R&D webpage for Differential Equations and Mathematical Functions (the development itself is bundled within the library that contains the new developments for the Physics package, in turn within the zip linked in the webpage).

The examples that can now be handled, although restricted in generality to "only one 1st order linear or nonlinear PDE and only one boundary condition for the unknown function itself", illustrate well how powerful it can be to use more advanced methods to tackle these tricky situations where we need to match an arbitrary function to a boundary condition.

To illustrate the idea, consider first a linear example, among the simplest one could imagine:

Input now a boundary condition (bc) for the unknown such that this bc does not depend on the independent variables ; this bc can however depend on arbitrary symbolic parameters, for instance

With the recent development, this kind of problem can now be solved in one go:

Nice! And how do you verify this result for correctness? With pdetest , which actually also tests the solution against the boundary conditions:

And what has been done to obtain the solution (4)? First the PDE was solved regardless of the boundary condition, so in general, obtaining:

In a second step, the arbitrary function  got determined such that the boundary condition  is matched. Concretely, the mapping _F1 is what got determined. You can see this mapping reversing the solving process in two steps. Start taking the difference between the general solution (6) and the solution (4) that matches the boundary condition

and isolate here

So this is the value  that got determined. To see now the actual solving mapping _F1, that takes for arguments  and  and returns the right-hand side of (8), one can perform a change of variables introducing the two parameters  and  of the _F1 mapping:

So the solving mapping _F1 is

Wow! Although this pde & bc problem really look very simple, this solution (12) is highly non-obvious, as is the way to get it just from the boundary condition  and the solution (6) too. Let's first verify that this mapping is correct (even when we know, by construction, that it is correct). For that, apply (12) to the arguments of the arbitrary function and we should obtain (8)

Indeed this is equal to (8)

Skipping the technical details, the key observation to compute a solving mapping is that, given a 1st order PDE where the unknown depends on  independent variables, if the boundary condition depends on  arbitrary symbolic parameters , one can always seek a "relationship between these parameters and the differential invariants that enter as arguments in the arbitrary function _F1 of the solution", and get the form of the mapping _F1 from this relationship and the bc. The method works in general. Change for instance the bc (3) making its right-hand side be a sum instead of a product

An interesting case happens when the boundary condition depends on less than  parameters, for instance:

As we see in this result, the additional difficulty represented by having few parameters got tackled by introducing an arbitrary constant _C1 (this is likely to evolve into something more general...)

Finally, consider a nonlinear example

Here we have 2 independent variables, so for illustration purposes use a boundary condition that depends on only one arbitrary parameter

All looks OK, but we still have another problem: check the arbitrary function _F1 entering the general solution of pde when tackled without any boundary condition:

Remove this RootOf to see the underlying algebraic expression

So this is a pde where the general solution is implicit, actually depending on an arbitrary function of the unknown  The code handles this problem in the same way, just that in cases like this there may be more than one solution. For this very particular bc (23) there are actually three solutions:

Verify these three solutions against the pde and the boundary condition

:)

In connection with recent developments for symbolic sequences, a number of improvements were implemented regarding symbolic differentiation, that is the computation of  order derivatives were n is a symbol, the simplest example being the  derivative of the exponential, which of course is the exponential itself. This post is about these developments, done in collaboration with Katherina von Bülow, and available for download as usual from the Maplesoft R&D web page for Differential Equations and Mathematical functions (the update itself is bundled with the official updates of the Maple Physics package).

It is important to note that Maple is pioneer in having an actual implementation of symbolic differentiation, something that works for real, since several releases.  The development, however, was somewhat stuck because we were unable to compute the symbolic  derivative of a composite function . A formula for this problem is actually known, it is the Faà di Bruno formula, but, in order to implement it, first we were missing the incomplete Bell functions , that got implemented in Maple 15, nice, but then we were still missing differentiating symbolic sequences, and functions whose arguments are symbolic sequences (i.e. the number of arguments of the function is n, a symbol, of unknown value at the time of differentiating). All this got implemented now within the new MathematicalFunctions:-Sequence package, opening the door widely to these improvements in  differentiation.

The symbolic differentiation code works as mostly all other computer algebra code, by mapping complicated problems into a composition of simpler problems all of which are tractable; what follows is then an illustration of these basic cases.

Among the simplest new case that can now be handled there is that of a power where the exponent is linear in the differentiation variable. This is actually an easy problem

More complicated, consider the  power of a generic function; the corresponding symbolic derivative can be mapped into a sum of symbolic derivatives of powers of  with lower degree

In some cases where  is a known function, the computation can be carried on furthermore. For example, for  the result can be expressed using Stirling numbers of the first kind

The case of sin and cos are relatively simpler, but then assumptions on the exponent are required in order to proceed further ahead from (2), for example

The case of functions of arbitrary number of variables (typical situation where symbolic sequences are required) is now handled properly. This is the pFq hypergeometric function of symbolic order p and q 

The case of the MeijerG function is more complicated, but in practice, for the computer, once it knows how to handle symbolic sequences, the more involved problem becomes computable

Not only the mathematics of this result is correct: the object returned is actually computable to the end (if you provide the values of n, p, m and q), and the typesetting is actually fully readable, as in textbooks, including copy and paste working properly; all this is new.

The  derivative of a number of mathematical functions that were not implemented before, are now also implemented, covering the gaps, for example:

In the same way the fundamental formulas for the  derivative of all the 12 elliptic Jacobi functions  as well as the four elliptic JacobiTheta functions,  the LambertW , LegendreP  and some others are now all implemented.

Finally there is the "holy grail" of this problem: the  derivative of a composite function  - this always-unreachable implementation of Faa di Bruno formula. We now have it :)

Note the symbolic sequence of symbolic order derivatives of lower degree, both of of f and g, also within the arguments of the IncompleteBellB function. This is a very abstract formula ... And does this really work? Of course it does :). Consider, for instance, a case where the  derivatives of  and  can both be computed by the system:

This is the  derivative expressed using Faa di Bruno's formula, in turn expressed using symbolic sequences within the IncompleteBellB  function

These results can all be verified. Take for instance

Compute now the inert functions: on the left-hand side this is just the (now explicit) 3rd order derivative, while on the right-hand side we have a sum of IncompleteBellB  functions, where the number of arguments, expressed in (13) using symbolic sequences that depend on the summation index k and the differentiation order n, now in (14) depend only on , and get transformed into explicit sequences of arguments when the summation is performed and k assumes integer values

Take left-hand side minus right-hand side

:)