Hi mwahab

Unfortunately, Mapleprime's mechanism for uploading and displaying the contents of a worksheet is not working, so below, you have only the link to this reply.

In brief, what you have done incorrectly is to assume that splitting the determining system into cases concerning k (so, not pde, but its determining system) would take you to the symmetries of each case of splitting pde into cases with respect to k. Although that may work in some cases, it is not assured that it will work in all cases.

In the worksheet attached I show three things: 1) and 2) are concretely different -however equivalent - approaches to split the symmetries into cases with respect to parameters, then 3) is how to tell when the approach you used will work. 

When the Mapleprimes mechanism to upload and display the contents of a worksheet is restored, I will repost this answer with the contents visible. Your question is indeed interesting for a wider audience, I think.

Download How_to_split_symmetries_into_cases.mw

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

Download grtensor_v2_(reviewed).mw

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

It suffices to equate to 0 the functional derivative, which you can compute with Physics:-Fundiff. Now, the Maple input line you show is not correct on several counts; for one you are using [] as () (in Maple, [] are used to enter lists of objects), then e^ is probably meant to be exp(). I'd suggest you to try to write the problem correctly, then give a look at the help page ?Physics,Fundiff.

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

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