This is the input of your worksheet:

Look closer: you type mr, not . Hence for the computer you metric depends on the symbol mr, not on the coordinate r.

One way of verifying this problem without being 'by eye' is to get the indeterminates of type symbol, as in

Correcting this problem (just open a space between m and r) the Ricci scalar is not 0

Hi Gerard

Understanding that you are talking about Poisson's brackets and that your canonical variables are

you can define the procedure directly, as in

These are your functions

And this is their Poisson bracket

Detail: in Maple you have two commands to perform addition: add and sum; their differences are explained in the

corresponding help pages but basically add adds terms one at a time while sum uses symbolic methods to perform

for instance infinite sums. Although in PoissonBracket you do not need something like sum, if you use it, for historical

reasons you have a problem known as 'premature evaluation': the derivatives are evaluated before the summation index

has a value, thus returning 0 (which is of course incorrect in this context). In situations like this one you can still use

sum if you use it with the more modern handling of arguments that comes with the Physics package and is free from

premature evaluation problems. You turn that ON entering

Hi

Besides the thorough DifferentialGeometry package mentioned by Torre, you can also use the Physics package, simpler to use in cases like yours.

Set the dimension, coordinates and metric as said in your post

This is the contracted Riemann: you can multiply and simplify in one step using the `.` operator instead of `*`, as in

To compute the Riemann and Ricci tensor components, just indicate these components giving numerical values to the indices. For example, R_φθφθ is

You can also see all the components at once. For example, this shortcut notation shows you the all-covariant Ricci components:

For the general case of the Schwarzschild metric shown by Torre, you can enter the coordinates and metric using the same procedure indicated above. But this metric is well know and already present in the database of metrics, so it is simpler to use it directly from there. For details on how to access the database and set the metric as shown in the next line see the help page for the metric g_

The contraction of the Riemann tensor mentioned

Use this to simplify in significant ways the display of formulas - note that derivatives will then be displayed indexed.

The Determining PDE, without using integrability conditions to avoid a difficult differential elimination process involving symbolic powers of r

Try now processing this taking beta as an independent variable, that simplifies the problem significantly

Solve it now to compute the infinitesimals symmety generators themselves

Verify that this indeed solves the Determining system for the symmetries= (note that I test directly against (3), not the simplified form (4), that is also canceled by (5)):

So, for an infinitesimal of this form,

This is a symmetry group involving three arbitrary constants

Alternatively you can also verify that this is indeed a symmetry directly against the PDE equ

Time to compute solutions. You can do that without specializing the symmetry, arriving at a solution involving Airy functions and the solutions of a 2nd order linear ODE that the system fails to solve (you'd need to specialize beta to obtain something more concrete)

Typically (not in this case), specializing the symmetry helps, and for this purpose you can use the PDEtools:-Library:- Specialize_Cn command  (see ? PDEtools:-Library )

Verify these symmetries

You can now use each of these to generate different kinds of invariant solutions, although as said in this example all of them lead to solutions to equ that depend on the solution of a 2nd order linear ODE that the system fails to solve (you'd need to specialize beta to arrive somewhere more concrete). For example:

You can also play around directly with the options of InvariantSolutions. For example,

But in this example I think it is improbable that you will obtain an actual solution to equ without specializing the constants.

Hi Glowing

Interesting example yours. First: given an ODE & ICs, the "mandate" of dsolve is to find one solution that solves the problem, assuming, generally speaking, that this solution is unique, because, generally speaking, an nth order ODE with n initial/boundary conditions has only 1 solution.

There are examples, however, where the solution is not unique, there is more than one solution, the additional ones typically associated with the existence of singularities of the ODE, or branches (e.g. sqrt in your example).

What you can expect from dsolve in these more tricky cases, where the system of an nth order ODE & n ICS has more than one solution, is one solution only, the one dsolve can find faster. This is so because dsolve counts the initial conditions, checks the differential order, and if these numbers are the same it automatically runs for the simpler solution to the problem, as said, assuming that in these cases the solution is unique...

In this framework, the solution returned U(t) = 0 is correct, it cancels the ODE and the ics. Nothing wrong with that.

But then: how do you compute the other solutions? Although in general you do not need to use optional arguments, in cases like this one you need: use the 'usesolutions = ...'. This optional argument is explained in the help page ?dsolve,details, the section on Optional Arguments. The possible right-hand sides are explained in the help page and to get the solution you want you can use "general", as in

This is the same solution you derived step-by-step. To get both solutions use "particular via symmetries and general", as in

So up to here: the solution returned by dsolve without optional arguments is correct, it cancels the ODE and ics, so it is not a hidden bug; the problem passed is special, admits more than one solution, to get the other solution you can use dsolve's optional argument 'usesolutions'.

There is still one things: how can you move away from this situation where the set of a nth order ODE & n ICs has more than the one unique solution? Generally speaking, the answer is to avoid constructing the ODE through differentiation of expressions with branches, as for instance sqrt(U(t)) is. In your example you constructed your ODE via

You can verify the existence of branches using FunctionAdvisor(branch_cuts, expression), say as in

You see that the cut starts at 0, precisely where you gave your initial condition. Not a good a idea. So, in this example you posted an easy manner to move away from this situation is to replace, before constructing the ODE through differentiation, any occurrence of sqrt(U(t)) by - say - V(t), then U(0) = 0 becomes V(0) = 0, then the system ODE + ICS becomes well defined and has a unique solution - corresponding to the one you were expecting. In your example, constructing the initial condition for V is trivial; in non-trivial situations you can use dchange, for instance for your example it gives

In summary: all OK with the solution by dsolve without using optional arguments and you can use the usesolutions option to get the other solution. You can avoid these situations by not constructing the ODE problem through differentiation of an expression with a branch cut while giving the initial condition at the origin or over the cut.

Edgardo S. Cheb-Terrab

Physics, Maplesoft