• 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.

Download mw-6_(reviewed).mw

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

Download piecewise_solution_with_special_cases.mw

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

Hi
I see no bug here. In
> ee := (((Q(a)^3)^(5/4))^(15/7))^(6/8);

you have a four times nested anything^rational type object. So, for the call on the left-hand side of what you posted, for any P, the call

> subsindets(ee, anything^rational, P)

will be applied, from the inside to the outside, 4 times, resulting in

    P(P(P(P(Q(a)^3)^(5/4))^(15/7))^(3/4))

But then on the right-hand side of what you posted, I see subsindets applied to objects of type specfunc(Q)^rational, that is a different thing, and within ee I see only one object of that type, so the call 

> subsindets(ee, specfunc(Q)^rational, P);

results, again as expected, in

    ((P(Q(a)^3)^(5/4))^(15/7))^(3/4)

Make now P be

> P := proc(x) if type(x, specfunc(Q)^rational) then 'Q(x)' else 'x' fi end

and you see the two results you got, all this is as expected.

Note as well that if you don't want subsindets to be applied recursively, you can use its option 'flat'. Also, to see subsindets at work (after you have assigned the procedure P) it suffices to trace P, entering trace(P); then call subsindets again

> subsindets(ee, anything^rational, P);
{--> enter P, args = Q(a)^3
<-- exit P (now at top level) = Q(Q(a)^3)}
{--> enter P, args = Q(Q(a)^3)^(5/4)
<-- exit P (now at top level) = Q(Q(Q(a)^3)^(5/4))}
{--> enter P, args = Q(Q(Q(a)^3)^(5/4))^(15/7)
<-- exit P (now at top level) = Q(Q(Q(Q(a)^3)^(5/4))^(15/7))}
{--> enter P, args = Q(Q(Q(Q(a)^3)^(5/4))^(15/7))^(3/4)
<-- exit P (now at top level) = Q(Q(Q(Q(Q(a)^3)^(5/4))^(15/7))^(3/4))}

while for the other type you used you have

> subsindets(ee, specfunc(Q)^rational, P);
{--> enter P, args = Q(a)^3
<-- exit P (now at top level) = Q(Q(a)^3)}

In summary that I see no bug here.

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

Have in mind that pFq, more than most functions actually, satisfy a myriad of identities (try FunctionAdvisor(identities, hypergeom([a, b], [c], z)), each of which has an apparently different integral representation. This is the same simplification problem mentioned in your previous post, two things that are the same but look different, making zero recognition difficult, not algorithmically possible in all cases.

Besides, the solution returned by dsolve uses Intat, not Int. There is no conversion to Intat, a more intelligent comand (think of it as an integral evaluated at a point - the equivalent to a derivative evaluated at a point represented in Maple by the D command).

As for your comment about odetest "does not give zero", its help page explains that a solution could be correct but, because of zero recognition, odetest will not find zero. I thought it was clear in the replies you received for the previous post you made today. I also showed, in one of those replies, what you could do in those cases: test the solution with a plot (equivalent to saying "numerically"). You could copy the input lines I posted in reply to your previous post and try to apply them for this your hand_solution.

Note the solution by dsolve is correct, and testable via odetest, even when it is an implicit solution (use the useInt option of dsolve) >  (1) >  (2) >  (3) NOTE: odetest verifies implicit solutions. The main idea behind that is simple: isolate _C1, and differentiate with respect to x, then simplify, you must get 0. So dsolve's solution is correct, testing is not a problem in this case, and the issue you are eperiencing is about testing the computation of an integral, as vv noted: >  >  (4) If the integral is correctly computed, here I expect 0 (excluding the origin and where f is singular): >  (5) But then, as Carl Love pointed out, zero recognition is not possible in general, and this is not a Maple issue: try the same in Mathematica, , and you also don't receive 0. For these reasons is that I coded the useInt and implicit options in dsolve - so that one can test a solution beyond these integration & solve & simplification problems.   For the situation where you want to test the solution after computing the integrals (and/or isolating the dependent variable in dsolve's solution), here is my preferred numerical choice: plot the expression in three dimensions, two boxes, for the real and imaginary parts of it, the number 5 requests 5 x the number of points, and scale the range from the unit square an amount that can give you some certainty, and you see the result is equal to zero up to Digits (you can increase Digits if you want to increase the certainty)   >  >

dsolve_and_odetest_verify_OK.mw

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

The form f[a](b) is useful if you want to manipulate the index within the procedure assigned to f. For example:
> f := proc(x) [procname, [args]] end;

and now execute it you see that procname appears indexed. So for instance

> f := proc(x) if procname::indexed then idx := op(procname) else idx := NULL fi; "idx" = idx end;

upon execute will show you the value of idx, and of course, you can then do whatever you want with idx, within a procedure. In summary, t is a useful feature that allows you to work with indexed functions using the indexation as a variable.

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

Besides PDEtools:-difforder, typically, you find other tools in ?PDEtools,Library. In this particular case (degree) what you are looking for is in DifferentialAlgebra[Tools][LeadingDerivative]

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

Understanding that you do have a copy of Maple (otherwise, let me know), all you need to do is to input ?PDEtools to open the help page and, on that page, take a look under "Symmetry solution related". The infinitesimals you show are computed with the command PDEtools:-Infinitesimals. For the infinitesimal generators in operator form use InfinitesimalGenerator. The rest is pretty straightforward, I'd say more like an exercise to familiarize with the package, and can be performed with the commands listed and linked under "Symmetry solution related", plus possibly some of the ones in the PDEtools:-Library (see ?PDEtools:-Library).

If you find this suggestion too dense, I suggest you to try to put on a Maple worksheet your attempt to formulate and resolve the problem, and we take that as the departure point. Or let me know here in case you do not have a copy of Maple.

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

Write your equations on a Maple worksheet, then you can use PDEtools:-casesplit to uncouple the system.

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

Check the corresponding help page (?Physics:-Fundiff). That command computes functional derivatives of a given functional.

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

With small touches to your worksheet you see there is no formal_series solution for this problem:
 

Download dsolve_(reviewed).mw

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

Download RicciScalarKretchmann.mw

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