Until a general fix is provided, maybe within a dot release, this problem is fixed, and the fix is available to everybody using Maple 2022 within the Maplesoft Physics updates. I see you are somehow new to Maple 2022. To install the latest version of these updates, please open Maple and just input Physics:-Version(latest). Then restart the system.

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

@nm
The assuming command knows about the options of each Maple command. Thus, it knows that right is an option of the limit command and will not place any assumption on it. That is the explanation also for what you @Carl Love ask.

Regarding the error interruption when you used quotes in 'right', indeed it is a sort of unexpected issue. A fix for this problem, available to everybody using Maple 2022, is distributed as usual within the Maplesoft Physics Updates, v.1340 or newer.

Finally, regarding this other comment by @Carl Love, I wrote assuming and can tell you there is no problem, at all, in passing something like: something assuming some_property, without specifying variables. That is one of the most valuable and practical ways of using assuming. I use it that way all the time. If you find something unexpected, post it, and if it is something to be corrected, it will be.

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

Input dsolve(q, singsol=false) and you will get only the general solution, all the singular ones are automatically not computed.

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

Download frontend_convertAlg.mw

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

@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