The call you are doing to DeterminingPDE automatically enforces integrability conditions assuming the parameters - in this case A -  are arbitrary, and you get as you show:

Leading to the infinitesimals

And that is the same you obtain in one go if you directly call Infinitesimals

If you want to split into cases according to the values of the parameters involved, call DeterminingPDE with the option to not aplpy integrability conditions so that the system you obtain is not simplified and in this example includes A

Now split this system into cases taking A as a parameter

Leading to the following infinitesimals

To have this working the way you want either use p_ . p_, as you said, or in addition to Vectors also load Physics:-`^` and Physics:-`*`, as shown below, and note please that this only works this way in Maple 2015 after updating the Physics library with the one available in the Maplesoft R&D Physics webpage.

Note first that the expansion of a power of a vector is implemented, returning the square of the norm:

Introduce now the components as you did

So now H, or its expanded form, are given by

You can differentiate directly, without having to indicate that c is real:

If all what you want is to use _x, _y and _z with the following meaning:

Then you can use macro (check its help page), as in

So that now you can use  meaning

If, however, what you want is for _i, _j, and _k to be displayed as _x, _y and _z, then you can use alias (again give a look at its help page please), as in

This is a vector (postfix is an underscore - see the ?Physics,Vectors page)

Alternatively, you can also enter (1) directly specifying the function components and using compact display, as in

This is your input:

And as you noticed, it produces nothing.  This is the problem:

The `*` is incorrect of course, not your fault but an issue with 2D, that you can avoid by going to Preferences -> Interface -> Smart Operators: uncheck it so that an invisible multiplication is not inserted automatically between ][ or )(

To make the problem evident, when you find something strange using 2D input, the first thing to do is to place the same input in a 1D input line: just open a prompt below and press F5 to go from 2D to 1D input mode, now paste:

Then look closer and you see the problem aforementioned. OK. Fix it now to obtain correct input, and hence the plot

Finally, answering the question you actually posted: by all means Heun functions can be plotted.

Hi vv,

Your system

As mentioned by Preben, this RootOf comes from solve. The expression sent to solve is, mainly,

This expression satisfies the initial conditions, also mentioned by Preben

Now, your argument to say that dsolve's solution is wrong is that

and in the above, you argue, if the solution were correct, the right-hand side should be equal to 1/10. It sounds reasonable.

My point here, however, is that I do not trust the numerical evaluation of any RootOf unless its argument is polynomial in _Z. Otherwise (as it happens in your example), there may be branch cuts in the expression entering as argument to RootOf, or multiple roots for which we have no closed formulas, and so the numerical algorithm that evaluates RootOf can end up computing "over the branch cut" and choosing one of the two values without you being aware of this arbitrariness of the numerical result, or even worse: start computing a root through one path, to suddenly jump to a different path sufficiently close but belonging to another root, leading to unexpected results without you noticing (typically resuting in a jig-saw plot for instance). In part for these reasons is that dsolve has the option 'implicit' also for ODE-IVP problems, which is rather unusual in computer algebra systems.

So le's take your example, and consider the expression (3) sent to solve (for which solve returned a RootOf) and evaluat it at , but without telling the value of

Evaluate this numerically, then solve for

And there you are, with two solutions, not just one. The first solution is, actually, your argument to say that dsolve's output is wrong. The second solution, however is, actually, which, for the same reason one could take as an indication that dsolve's output is correct. Putting all together, the only thing you can say is that, symbolically (ie exact solutions) , the expression (5) involving a RootOf is correct, in that, as shown above, if you remove the RootOf you see that the solution (3) verifies OK, exactly, as shown in (4), and for these problems you cannot verify correctness by numerically evaluating a RootOf whose argument is not polynomial in _Z.

To see that there are branch cuts in this expression you only need to check whether there is more than one value of  for a given t (ie the function is multivalued). By eye, (3) is linear in t so in this case it is easy:

Compute now the branch cuts (if any) of the right-hand side

Ie there is a branch cut for so the function is multivalued, you cannot rely on the numerical evaluation of RootOf. In these cases the only verification that I think is meaningful is the exact symbolic one, shown above, based on removing the RootOf from the solution.

ADDED AFTER POSTING THIS ANSWER: You can get the solution with LambertW using the appropriate optional argument, not obvious at all but anyway: skipimplicit

Michael

Your definition of RicciT (by the way, why don't you use the already defined Ricci tensor directly with tetrad indices?) involves d_[c] where c is a tetrad index. Then, when you invoke RicciT[1,2], that requires computing the tetrad component d_[1] which, in order to be mapped into derivatives with respect to the spacetime (global system of references) variable, it needs to be multiplied by the tetrad. It so happens that for the tetrad metric you set the corresponding tetrad has square roots and the imaginary unit, and so d_[1] where 1 is a tetrad index will appear with the imaginary unit and square roots around.

Here is how it happens

Please note that when you load Tetrads, tetrad indices are automatically set to lowercaselatin, so you do not need to set them again to lowercaselatin (you do that in your Setup command).

Copying now from your worksheet, the tetrad metric you want to use us

NOTE: you can have this for tetrad metric in place by just telling Physics that you want to work with a null (instead of orthonormal) tetrad and that the signature is +--- (instead of the default in Physics that is ---+). So instead of using the Matrix as you did, here I use these Physics commands directly that result in the same

Before proceeding, check the tetrad

You see it contains sqrt(2) and the imaginary unit. It is all correct, according to the definition

Check if the definition holds:

So all is correct. Next you define two tensors, GammaT and RicciT (I imagine that you are using 'T' to mean "in the tetrad local system of references", but for that it suffices to use the Physics Ricci tensor and Christoffel directly with tetrad indices, no need to define yet another tensor). Here I do things in both ways.

First your way, I am just copying from your worksheet:

Check your definition of RicciT

You see it involves the non-covariant derivative with tetrad indices, but if you want this to become derivatives with respect to the spacetime coordinates (from the global system of references) you will need to multiply by the tetrad. For example, define a tensor in the tetrad system of references, as you did (for that, it suffices to define it with a tetrad index)

Take now the non-covariant derivative using tetrad indices and indicate a dependency of A[a] with respect to the spacetime variables

Rewrite now the type of indices of this expression so that it can be computed in terms of derivatives with respect to the spacetime variables

Recalling now from (5) that the tetrad  involves the imaginary unit and , when you compute the components of this 2x2 matrix behind this tensorial expression (12) you can expect the imaginary unit and  around. To compute this matrix (array), use

Therefore you will see the imaginary unit in your definition of RicciT, and that is the answer to your question in this thread.

Let me show now that you do not need to define RicciT nor GammaT to compute with these tensors in the local system of references (the tetrad system). First note that your spacetime is flat, from where the same is true with respect to your tetrad system, and hence the components of the Ricci tensor in both systems of references are all equal to 0.

So to illustrate the use of tetrad indices with Ricci let's first set the curvature to something, and cannot be the standard Schwarzchild metric because in that case too the components of Ricci are 0. So how about the Tolman metric

So here are the components of the Ricci tensor in the global (spacetime) system of references

And these are the components of the Ricci tensor in the local (tetrad) system of references

To understand how one is obtained form the other one you can use the same Library routine used some lines above

This gives you an array of equations, where all the lhs (the components of ) are equal to the rhs (the components of )

Get the equations:

Check whether they are all just identities of the form A = A

Summarizing: nothing is wrong here, and for the way you defined RicciT you can expect the imaginary unit.

One last thing: is Ricci[a,b] equal to your RicciT[a,b]? To verify that take the right-hand side of (19) and express it in terms of Christoffel symbols

Simplify now the repeated indices

Compare with your definition, and I will substitute here GammaT by Christoffel in the definition just to make it more readable for comparison purposes

Let's compare the first term of Ricci[b,c] and RicciT[b,c]; if these two are equal we would have

But these two are not equal: to be equal you would need to move  within the  derivative but you cannot do that because  depends on the coordinates, it does not commute with . One could think that your GammaT is not Christoffel at tetrad indices, so let's check what Christoffel at tetrad indices is:

Summarizing about these releationships: I suggest you to check carefully whether RicciT and GammaT are the objects you want them to be, and whether you really need to introduce them or perhaps it is simpler to work with the Ricci and Christoffel symbols just using tetrad indices.

Hi Michael

Your question misses context: the d_ Physics command is an indexed differential operator that is applied onto a "derivand", you know. But your question shows nothing of that. So without further details from you, this is the basics about how it works

The above cannot be expressed in terms of diff or D because mu has not been given any value and, you know, the differentiation variable depends on the value of mu.

Then, if you perform the summation implicit in the repeated indices, the output already comes in diff format:

The same does not happen with the inert form %d_, but then you can convert to diff or D using convert (that you say it has no effect, but actually works fine as expected):

So what is the context for you question? What is the actual expression you want to convert that you say is not being converted?