Define the Laplace operator; use simplify/size (not mandatory, but useful in cases like this)

For readability, use compact display (derivatives are displayed indexed and the function dependency ommited - check the help page for declare)

Try first Laplace operator itself on a function of r only

The "second power" of the operator is just the composition of the operator with itself. In Maple, the composition operator is @ (check its help page)

You can also use the repeated composition operator, for instance to compose more than twice:

Just saw your post today. A symbolic matrix is just an object for which the product is not commutative. Therefore you can use any noncommutative objects to produce the result you want. The Physics package is the tool for computing with noncommutative objects, including differentiation among other things.

For example:

Set three operators (there is a one to one correspondence between a operator and a matrix; you can, if you want, but you do not need to indicate the dimension of the matrices)

Define now your matricial equation (use exponentiation with the product operator as exponent to represent the Dagger, which in the case of real matrices is the transpose)

Differentiate:

And that is essentially the result you wanted, all symbolic, it is 100% doable in Maple.

Another way of doing the same: set a noncommutative prefix:

Or you can also set many prefixes and use each one to represent one of the matrices of your problem:

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