Hi WouterSe
I adjusted the solution you posted to be, in 1D Maple input syntax,

sol_Wouter := `ξr`(r,t) = sin(1/2*Pi*r)*cos(1/2*(kappa/Mu)^(1/2)*Pi*t);

Then tried

pdetest(sol_Wouter, [eqn, ic, bc]);

              [      /1     \      /Pi \         ]
              [0, sin|- Pi r| - sin|---|, 0, 0, 0]
              [      \2     /      \2 r/         ]

So the first ic is not satisfied. Indeed, your first ic reads  `ξr`(r, 0) = sin(Pi/(2*r)), not sin(Pi*r/2). Of course, if you change  sin(Pi/(2*r)) by sin(Pi*r/2) in sol_Wouter, then the PDE (your eqn) does not cancel. 

So, the solution you are expecting is not correct for the problem you posted.

Guessing what could be wrong in your post, from the output by pdetest above, if you change the right-hand side of your first ic from sin(Pi/(2*r)) to sin(Pi*r/2), then the (corrected above) solution you posted cancels all of eqn, ic and bc. But then pdsolve also returns the simpler solution:

# change your ic from sin(Pi/(2*r) to sin(Pi*r/2)

ic := `ξr`(r, 0) = sin(Pi*r/2), D[2](`ξr`)(r, 0) = 0:

pdsolve([eqn, ic, bc], Zeta(r, t));

        `ξr`(r,t) = sin(1/2*Pi*r) * cos(1/2*kappa^(1/2)*Pi*t/Mu^(1/2))

In summary: to get from pdsolve the "simple" solution, you need to correct your input (the first ic). For the input you presented, there is no simple solution that I could see, and the infinite sum solution returned by pdsolve is correct.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Download polar_plot_of_geodesics.mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Hi

I am curious about your question ... No, you cannot define a 'tensor of rank 0' because that is a scalar, and everything in Maple is already a scalar. I mean: from the computational point of view, what distinguishes a tensor from everything else are two things: 1) its behaviour under a transformation of coordinates (only applicable to tensors of rank > 0, see ?Physics:-TransformCoordinates) and 2) the sum rule for repeated indices (also for tensors of rank > 0). So, in Maple, you do not need to define a 'scalar' (tensor of rank 0) because, generally speaking, everything is a scalar unless you indicate it is a tensor (of rank > 0).

Trying to figure out what you intend to do with Theta = varepsilon[mu, ~mu](X) , maybe you want to have Theta as a computational representation for varepsilon[mu, ~mu](X) ... ? You can achieve that also via alias(Theta = varepsilon[mu, ~mu](X) ) or assigning as in  Theta := varepsilon[mu, ~mu](X). Or if you want to compute with a scalar function, e.g. Theta(X), just use Theta(X). If you don't want to have the display showing the (X) dependency, use Physics:-CompactDisplay, or even alias(Theta = Theta(X)).

Or perhaps I am not understanding what you have in mind - if that is the case could you please give more details to frame your question and understand what you intend to do with Theta(X) that would require a tensor (of rank 0) definition?

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Hi

Thanks to all for the feedback. The sense of community grows with that. The problem is fixed and the fix is available to everybody within the Physics Updates v.430 and higher.

Comments: this problem fixed is not related to the Physics Updates or any of its versions - for instance, without it, you get the same result posted by nm. The problem was actually a combination of two facts. 

1. int(Sum(0, j = 1 .. infinity), tau = 0 .. t) returns Sum(0, j = 1 .. infinity)*t instead of 0. Although not incorrect, this is what I'd call an inconvenient weakness.
2. Unfortunately, that was happening in a place where the code checks for 0, and Sum(0, j = 1 .. infinity)*t is syntactically different from 0, an then the flow moved forward in a case where it should have stopped.

This is now tracked in the internal database as an issue in int, and it is always good to detect these cases, no matter how surprising they could seem.

Investigating this problem also helped to detect another place where the flow could be streamlined, so now pdsolve works faster in some examples. But for this problem, the result we get with v.430 is still NULL, not a solution.

I will give a look at the suggestion by Rouben, he always has good ideas; anyway, this is what I think is a general approach for this kind of problem: change variables avoiding symmetric bc's, as shown in the worksheet below.

NOTE AFTER POSTING: The approach explained in the worksheet below is already implemented within the Physics Updates version 431, so that the solution shown below as (6) is the current output for pdsolve([pde, ic, bc]).

Download fixed_in_v.440_and_approach_to_solve_the_problem.mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Download Alternative_Christoffel_without_some_terms.mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

This is fixed in V.428 or higher of the Physics Updates; you get

NOTE AFTER  THE POST: by installing the Physics Updates v.433 or higher, you get a more general form of the solution.
 

Download fixed_in_v.428.mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functuions, Maplesoft

Hi

This is fixed in the Physics Updates version 427 or higher. In version 426, unfortunately a file of the version under development got loaded inadvertently, creating an out of sync issue. Thanks for posting the problem.

Best
Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Download question_for_rif_(reviewed).mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@nm 

Your comments are valuable; it would be helpful however if you could please

• Transform your reply into a post.
• Be more specific regarding 3) and 4); itemize the three things you think are more important than anything else for each of them, be clear enough for people to understand, unambiguously, what you are talking about. Giving an example for each of your points always help.

Then, people may or not agree with you, as usual, that is natural, and Maplesoft may or may not have other plans, that is also natural, but people are listening, and chances are that your opinions (yours and others that may add material to your post) are taken into account, entirely or to some point.

Regarding the Heun functions, the original topic of this question, I agree with you nm when you say "given the small [amount of] resources ... I would prefer Maplesoft put its important resources on things that can impact many more users".

For example, this year is one with a heavy dedication to the integral transforms (the inttrans package) in connection with further developments on the exact solutions of PDE & Boundary Conditions, where these transforms are a key part of the strategies. The integral transforms numerical evaluation, differentiation rules, and several fixes and improvements (all that included some versions ago in the Physics Updates for Maple 2019 - and there is more coming) have the potential for significantly bumping up the utility of these valuable functions.

The Heun functions, by the way, are implemented - I wrote the Maple implementation many years ago, and I think it is a thorough implementation. True, their existing numerical evaluation routines can be improved at this point, and the Lame and spheroidal wave functions are not implemented. I know all that. Nobody forgot. What is happening is that other things pop up year after year that appear to me more relevant and of more impact than enhancing the existing (and in my opinion already sophisticated) numerical evaluation routines of Heun functions, or implementing Lame. I realize others may not agree with me, and that is also natural.

And about that comment "... esoteric parts of the physics package", it looks to me highly subjective - despite the way the comment is written as if it were an indisputable truth. My opinion is that nothing currently found in the Physics package is esoteric. We all need to be respectful of others opinions. And that is all that I'll say in this thread about the original question.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

The command for applying a change of variables (transformation) to an algebraic expression (differential or not) is PDEtools:-dchange

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

The convention explained in dsolve's help page is that the integration constants introduced by dsolve are of the form _Cn with n an integer. If you change that by something else, odetest has no way to know what is the integration constant that dsolve introduced. That information is relevant to test implicit solutions, as the one you show in your question. As explained in an answer to another of your questions, the technique is simple: solve for the integration constant introduced by dsolve (_C1, identified by odetest because of the _Cn convention) then differentiate with respect to the independent variable (in your example that is x) and you will get 0 modulo the ODE.

In summary: no bug here, and if you want the code to work as indicated in the help page, you cannot change its conventions. Alternatively, you change the conventions, and then test this result manually, not using odetest. The technique is simple, explained in the previous paragraph.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft.

Download It_works_fine_in_2019..mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations andMathematicalFunctions, Maplesoft

• When odeavisor returns a list of types (or classifications) of an ODE. This must mean the ODE can be of any one of these types?

Yes, when odeavisor "returns a list of types (or classifications) of an ODE" it means the ODE is of all of those types.

• When Maple is given an ODE to solve, and it can be of number of types, how does it select which type to use to solve the ODE?

See the help page ?dsolve,setup. That page is old, by now incomplete, for instance it does not mention the method of integrating factors for ODEs of differential order > 1, a method as powerful as the Lie symmetry method. See also ?dsolve,education and ?dsolve,algorithms.

• Is there any detailed document that explains more how odeadvisor determines the type of the ODE? This is a very powerful and a useful command but I can't find in help any hints on how it determines the type of ODE.

I wrote the odeavisor to be a sort of interactive e-book for ODEs: you pass an ODE and it not only determines the ODE types but also pops-up help pages explaining the solving methods available for those types. The point is that I wrote dsolve and the odeavisor at the same time, structuring the code so that the latter could take advantage of the subroutines of the former. The odeadvisor is thus a sort of "dsolve half of the way" plus the set of explanatory help pages on the corresponding solving methods for the ODE you passed, and its ability to pop-up these pages automatically. The implementation details are too many, and also this is not public software, even when at Maplesoft we are incredibly open regarding that - you can always read the code.

In general, about possibly more questions on the structure of Maple commands or the help pages mentioned above: I don't intend to make the help pages mentioned more complete/detailed. The competition copied some of our algorithms, for dsolve, pdsolve and also other stuff, e.g. the assuming and FunctionAdvisor commands, albeit they did a poor job at all that in my opinion. 

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

As pointed out by you, Oliveira, this was an issue visible only when the Physics setting assumingusesAssume was equal to true . The problem was actually within assuming, not  Physics:-Assume, and not noticed before because the old assume command redefines assumed variables, something that the more modern Physics:-Assume does not do. The issue is now fixed at its root and so assuming works as expected with the Physics setting assumingusesAssume. The adjustment is distributed for everybody within the Maplesoft Physics Updates v.416 or higher.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Hi

First of all: no, there is no leakage with regards to use and any other package  (Physics included). What this is: most packages have initialization files that set a few things here and there. That is not always documented properly. When you invoke use Package that initialization is executed, and whatever got set remains set after end use. That accounts for what Rouben Rostamian mentioned, about the use of the dot to display derivatives with respect to t . Historically, this was a Maple default, which however changed one or two releases ago, and I decided to keep that default in place when you load Physics, for natural reasons.

Second, there is a bug, not a leakage, with regards to the Physics's default setting 'assumingusesAssume'. When you load (or use) Physics, that setting is set to true, also for obvious reasons (Physics:-Assume does not redefine assumed variables, representing a significant advantage all around). This bug was mentioned as such yesterday, in this other Mapleprimes post by you, Oliveira. But this has nothing to do with leakages or use .

It is important to recall here that the implementation of both old and more modern ideas (e.g. assuming using either assume or the more modern Physics:-Assume), as every portion of code, is only as good as the amount of hours tested / debugged. Finding an issue in the interaction of assuming and Physics:-Assume is rare, I'm glad that the problem got uncovered. I noticed, however, that were not for Carl Love extra comments, you (Oliveira) were not going to mention the origin of your problem (that dsolve was returning only one branch instead of three, in connection with loading Physics and its automatic setting assumingusesAsume = true). Having good mathematical software is a collective endeavour. Reports of things not working as expected, with the necessary details for reproducing them, is perhaps the most important thing / contribution to the project. 

Note after post: That problem in assuming when using Physics with the setting assumingusesAssume is fixed and the adjustment distributed for everybody within the Maplesoft Physics Updates v.416 or higher.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft.