@Carl Love, @Preben Alsholm, @acer, @vv,
Download handling_diff_complex_components.mw

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

Download FactorSum_and_RemoveCommonFactors.mw

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

Input Typesetting:-Settings(':-useprime' = false) and you disable the prime notation to represent a derivative with respect to x. But then if you input x', you receive an error message: it is - syntactically - not valid. That is of course a convention, it could be re-coded so that: when useprime = false, entering (using 2D math notation) the combo x' is interpreted as `x'` (I will take a look at the feasibility of this), what @Carl Love suggests you in his answer for you to use regardless of the value of useprime.

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

Download spherical_derivative_using_Physics_Vectors.mw

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

The answer to this question is the same one I gave to a question you asked yesterday about the same thing. Recalling the gist of that answer, "If your ODE is solvable using the method for class XXX of ODEs, then the ode is classified as of class XXX." From your two questions about the same, I suppose this sentence should be written explicitly on the odeadvisor help page.

The issue underlying your question here: there is, of course, a distinction between "computer syntactic" versus "mathematical normal form in a solving context." You seem to be disregarding this distinction, while all solving commands make this distinction and take the second one as representing your input expression. The ODE you are presenting now to an ODE solving (classifying) command,  (x+y(x))*diff(y(x),x) = 0, as an ODE, it is normalized to diff(y(x),x) = 0, and therefore of course it is solved by dsolve using the method for linear ODEs (try dsolve(ODE, [linear]) to see that), thus classified as linear by the odeadvisor, no bug here.

A not-equal, however similar situation you have when algebraically solving ee := (a*y^2 + b*y)/y = 0 with respect to y. Is this an expression linear in y? From the computer syntactic point of view, of course not. Input type(ee, linear(y)) , the answer is false. But in the solving context, when you pass it to solve, it is first normalized; as such, ee represents (a*y+b) = 0 and therefore is solved as a linear equation.

Moving then to the other question of your post: you could check whether the "ODE input expression" is syntactically linear in y' and if so, isolate y' before sending it to DEtools:-convertAlg. There are, of course, many other possible ways of addressing your computational need, but that one will match what dsolve does (and therefore what the odeadvisor does, given the first paragraph above).

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

Hi
First, the references for most of the classifications are at the end of the help page ?odeadvisor, and in particular, for this "classify ODEs" project, which is a subproduct of the new dsolve for Maple of 1997, I used Kamke's book. I say "most of the classifications" because the odeadvisor contains all those found in the textbook references but also several other ones - e.g. using symmetry patterns, or for Abel ODEs - that we identified ourselves as more general - entirely solvable - classes, that were (still are) not mentioned in textbooks, only in our scientific published papers - see ?dsolve,references.

And then there is what in Education is called "instrumental knowledge" which I summarize here - e.g., as: if the method for systematically solving dAlembert ODES can solve your example, then your example is of dAlembert type. That doesn't mean "Maple uses its own definition of dAlembert ODEs." The definition, as said, is the one shown in Kamke's book. In this context, to suggest - e.g. - that f = 0 or g = 0 are impediments to classify the ODE as dAlembert is not appropriate. If those values of f or g make the ODE solvable by other methods (e.g. missing x), that changes nothing: the ODE is solvable by more than one method, belongs to more than one class.

And how is the odeavisor used "instrumentally" in Maple? When writing dsolve (1997), I organized the computational flow around a table of methods (see ?dsolve,setup), where new methods could be plugged, removed, or their ordering changed at will, even by a user. Each method consists of three subroutines:

• The manager routine (receives the problem in some established format, returns NULL or a solution)
• The odeavisor routine (tells whether the problem passed is or not solvable by the method, and if so, on the way it collects the relevant solving information)
• The integrate routine (given the OK by the odeavisor routine of the method and relevant information, it proceeds to integrate the ODE using instrumental formulas).

For example, for dAlembert ODEs, these routines are: `odsolve/dAlembert`, `odeadv/dAlembert` and `odsolve/dAlembert/integrate`. You can display these routines on your screen. The odeadvisor only uses the odeadv routine to tell you whether an ODE is or not of that type.

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

Hi @Rouben Rostamian, @vv;

Download SpecializeArbitraryFunctions_-_fixed.mw
 

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

This was a subtle bug in the routines deciding a convenient ranking to tackle the system. The problem is fixed, and the fix is distributed as usual for everybody using the latest Maple version (2022) within the Maplesoft Physics Updates v.1312 or newer. With the fix in place, pdsolve returns a solution. I also see you are using Maple 2018. Unfortunately, I have no way to make the fix retroactive to previous Maple versions, so in your case I think Carl's solution is the way to go.

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

Download Physics_tensors.mw

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

Hi

The package you mentioned is not a Maplesoft package but one coded by Maple users. I am not sure how well know that package is, but I am not familiar with it. On the other hand, Maple comes, right from the box, with three packages for these purposes you mention: CalculusOfVariations, DifferentialGeometry and Physics. I suggest you try your calculations with the existing Maple package, and if you find something missing, please post that as a question about the existing Maple packages. Most probably, you will receive answers right away.

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

The transformation y(x) = arccos(u(t)) (see ?PDEtools:-dchange) removes the cos(y(x)) from the problem. Still, it remains sqrt(1 - u(t)^2); you'd need to experiment further to remove that to obtain a purely rational equation. In any case, after removing cos(y(x)) you see this equation admits point symmetries (see ?DEtools:-gensym). That doesn't solve the problem but is a good prognostic: if you happen to compute a solution to the output of gensym, that is, if you find a symmetry, you can use it to construct a solution, either using dsolve with one of its symmetry options (see ?dsolve,details) or directly PDEtools:-Invariant solutions (check its help page). You may also want to consider the determination of an integrating factor (here too, see ?gensym), and if you succeed, see ?dsolve,options to use it to compute a solution.

In general, you 1) always try to find a transformation that makes the ODE simpler. Then either you find 2) a symmetry or an integrating factor, and if you succeed, 3) you can use it to integrate the problem. You can use the computer for all 1), 2) and 3).

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

Use dsolve's option useint and you get a solution. However, instead of combine, use simplify(solution, size). The solution is large in size. The reason for using this option: some integrals appear in the solution without the option useint, and those integrals make it difficult to solve for the integration constants to match the initial conditions.

I note as well that a solution involving the integrals (so without the option useint) is at reach if you pass only 4 of the 6 initial conditions, then you may want to compute the integral using value, finally adjusting the two remaining integration constants interactively.

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

This is as @acer said; for this problem, solve returns something that, unfortunately, results in RootOf(0) when simplified. The problem is caught now, and PDEtools:-Solve returns NULL. This change is distributed to everybody using Maple 2022 within the Maplesoft Physics Udpates v.1288 or newer.

About this other issue, PDEtools:-Solve(sin(t)^2 + cos(t)^2 - 1, t);, mentioned by @Carl Love, that is an entirely different problem, with no RootOf involved. This other problem is also fixed. The fix is distributed in the same Physics Updates v.1288 or newer.

By the way, PDEtoosl:-Solve does not have another solver within. What PDEtools:-Solve has is several additional strategies extending the applicability of solve and some other solving Maple commands. Recalling from it's help page,

The PDEtools:-Solve command computes the value of solving_variables that solves a system of equations sys. The system being solved can involve algebraic or differential equations, or both. You can request an exact (default), numeric, or series solution (respectively use the option numeric or series). In this sense, Solve is a unified command that understands when to call solve, fsolve, dsolve, or pdsolve according to your input, also facilitating the analysis of different types of solutions by just adding the keywords series or numeric.

In addition ....[etc].

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

Hi Rouben,

After with(Vectors), type(A_, PhysicsVectors) works as you expect. I need to document all the Physics:-Library:-PhysicsTypes ... for which nops(with(Physics:-Library:-PhysicsTypes)) -> 114. These are the types used internally by the Physics package routines and are made available for programming purposes together with the Physics:-Library (this one is documented), which contains the internal routines of the Physics package, also documented for programming with them.

By the way, this type should also be mentioned in the Physics:-Vectors help pages - at this moment, it is mentioned on the page ?convert,PhysicsVectors.

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

You know the form of Dirac matrices in a Minkowski space with metric  (+++-) , either in a flat spacetime or in the local system of references implemented as the tetrad system.

So take the transformation that transforms the eta_ Minkowski metric (+++-) into (++--), you asked about the same in a previous question I answered a week or so ago, and apply it to the standard form of each Dirac matrix; then use Physics:-Define to define a new tensor (with spacetime or tetrad indices, depending on your problem) whose components are those transformed Dirac matrices. See the page ?Physics,Define and ?Physics,Tensors for the different ways of defining such a tensor.

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