The claim that one can write the solution for any (all) Abel equation is 100% false. As explained in ?odeadvisor,Abel, only when the invariants are constant (see eq (2)) is that the solution is always possible. 

For reference, these 3 papers present the problem, collected all the solutions available scattered in the literature (many by Abel and Liouville themselves), represented a change in the status of things for Abel equations (the discovery of the AIA class, and its connection with hypergeometric equations using non-point symmetry transformations that involve derivatives, then the development of the AIR algorithm, implemented in Maple), and are relatively easy to understand

• Cheb-Terrab, E.S., and Roche, A.D. "Abel ODEs: Equivalence and  integrable classes." Computer Physics Communications. Vol. 130. (2000): 204-231.
• Cheb-Terrab, E.S., and Roche, A.D. "An Abel ordinary differential equation class generalizing known integrable classes." European Journal of Applied Mathematics. Vol. 14. (2003): 217-229.
• Cheb-Terrab, E.S. "A connection between Abel and pFq hypergeometric differential equations." European Journal of Applied Mathematics. Vol. 15. (2004): 1-11.

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

PDEtools:-Solve is a unified command for solving equations: symbolically, numerically, in series, differential (ODES and PDES) or not,  solutions freeof(variables), etc. Besides providing more functionality than all those commands together, a single interface, and a unified form of the output, this output is also free of that (annoying for me) nuance that you are pointing at: "x =" is missing in the output of solve or otherwise it puts curly brackets, or undesired square brackets around each solution, etc. So you get

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

In Maple, perhaps more than in other systems, known-function calls are normalized. This really makes life easier regarding simplification and zero recognition in general. In brief, in the case of known-function calls, to normalize means writing things always the same way (as much as possible, e.g. what you show). So for example, sin(p - a) + sin(a - p) automatically returns 0. It makes sense to me. What you are asking, although possible and also reasonable design (make normalizations only within the simplilfier), it is against Maple's design. So the answer is no, in Maple you cannot avoid normalization of known-function calls. You can still use inert functions, as mentioned in Kitonum's reply.

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

I couldn't reproduce your "The solution I obtained is", that appears after eval(sol[2]). But about your question, in situations like this one, using the odeadvisor frequently helps:

For a description of "dAlembert ode" input odeadvisor(ode, help). For the use of methods see ?dsolve,details (under Options); for the methods available ?dsolve,setup. Most of these methods will be indicated by the odeadvisor. The idea: once you know the types the ode matches, you can ask for the use of just one or any sequence of those types in the order you prefer. Using infolevel[dsolve] := 3 also tells which method dsolve used to solve a problem. In this case, the equation is also "missing x" so it can be solved in terms of an integral right away, but as you show, the internal heuristics, although extremely tunned over the years, not always get the simplest solution.

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

Nm,

For your ode example, ode2 := denom(rhs(ode))*diff(y(x) ,x) - numer(rhs(ode)) = 0 is indeed exact, but by chance only. In the general case of a rational ode, an ode2 constructed as you are showing is not exact. The determination of a multiplicative factor (in this example of yours: denom(rhs(ode)) that makes the ODE exact is 100% equivalent to solving the problem entirely. You realize that solving an ODE is not just about taking the denominator of the right-hand side. This unknown multiplicative factor is actually the solution to a system of partial differential equations - see details in the help page of DEtools[intfactor].

In summary, and especially when discussing exact equations, the multiplicative factors you are using to multiply all the equation are extremely relevant, as in "you know the solution already" (when the equation is exact, generally speaking, it means the ODE is just an integral in disguise).

By the way: you have this same information if instead of odeadvisor(ode2) you input odeadvisor(ode2, help), in which case it will automatically open the help page for exact equations where you see the same information written here.

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

Good catch, nm, thanks, the fix for everybody is distributed as usual within the Maplesoft Physics Updates v.723 or newer. After installing this version of the Updates, you get:

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

Computer algebra systems (CAS) have conventions. It is not correct to expect a CAS to work "the same way" if you don't follow the conventions. In Maple, integration constants returned by dsolve are of the form _Cn where n is an integer. Not _C[n]. Not _C. The algorithms in odetest scan for these integration constants: if you isolate one of them to the left, the right-hand side must be a constant with respect to the independent variable - say x; i.e. differentiating it with respect to x must result in zero (modulo the DE itself) upon simplification. But if you change the integration constant to whatever-else, naturally the routines inside odetest will not detect them anymore (they have no way to know what convention you have invented). I already answered the same or very similar question (probably by you?) here in Mapleprimes.

So there is no bug here. If you expect the computer algebra system to work as it says in its help pages, you must follow its conventions to represent mathematical objects.

Two additional remarks. First, you mentioned "conflicts if using _Cn", but there is no conflict at all in you using _Cn within the ODE or PDE. Maple's commands detect that and will not use those that were found in the DE when constructing or testing a solution. Second, Maple has a programming language, so you can program a wrapper to odetest if you prefer: replacing your convention (_C or _C[n] or whatever else) by _Cn. See the ?PDEtools,Library help page were you can find Library subroutines that can help you in programming anything you want about DEs; they are the same internal routines used in dsolve, pdsolve and PDEtools.

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

Vectors expressed using each of these two packages can be rewritten using the format of the other package using convert. So, if the VectorCalculus version of a Physics F_ is plottable, then you can convert(F_, VectorCalculus) and plot it. This could actually be done automatically within fieldplot/fieldplot3d (not implemented yet).

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

Hi, could you please close Maple, entirely, then open Maple, and enter Physics:-Version() again. If it still tells you that the installed Updates is not active, then please enter libname; press enter and post here the output.

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

Hi Tom,
Could you please open Maple and, clicking the MapleCloud icons, install the Physics package. Then close, then reopen Maple (not just 'restart'), and input 'Physics:-Version()', everything should work. If not, then also input 'libname', and reply here showing a picture with the output of Version and libname. With that info we can figure out what is going on at your end.

Generally speaking, 'is installed but not active' means another version of Physics is active, as shown by the ordering in libname (found in the directory mentioned in the message) - that would mean either you need to close and reopen Maple or that there may be something wrong in your libname (unlikely, I'd need to see it to tell what could that be). 

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

Good catch, though I only noticed this one today. It is fixed and the fix distributed for everybody using Maple 2020 within the Maplesoft Physics Updates v.692 or newer. With the fix, all the Normal, Expand and Simplify Physics commands, also the lowercase expand and simplify commands, return the same and correct.

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

IMPORTANT: note that using a product operator `*` with objects that do not commute, like, differential operators and corresponding differentiation variables, is not correct unless that product operator handles noncommutativity (as it is the case of Physics:-`*`, the product operator that gets loaded after you load the package - not the case of the standard default Maple `*` operator)

products_of_differential_operators.mw

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

Download cov_diff_bug_1_(reviewed).mw

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

The topic of your question is a good one. I decided to write a post about, see "The equations of motion in curvilinear coordinates, tensor notation and Coriolis force". The three steps you mention appear in that post as equations (25), (26) and (30).

One other comment regarding the type of your question: computer algebra is an extremely powerful environment to formulate and explore, and with that to learn and discover. It may sound obvious, but the guidance is always given by the person behind the keyboard. You can only formulate things that you understand or know how to do with paper and pencil, completely or partially. And then, yes, even In the latter case, through exploration it very frequently takes you to a new and deeper understanding. I agree with you entirely in that it can revolutionize the teaching of Physics.

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

As tomleslie said, "Maple now has two "modes" (Worksheet and Document) and two "input methods" (1D input and 2D input) - so overall you have four choices of "user interface""

Unlike his and other's opinions, I think that worksheet mode + 2D-Math display of input is the best option, together with the (preferences) option: “How should Maple handle the creation of a new Math Engine?” definitely: “Ask each time a new document [or worksheet] is created”.

My rationale: 

Unlike document, in worksheet mode, it is clear where the text is and the math. Visually, right away, because of the prompts. And you can still have math within the text (press Shift+F5 within text to write math, or write it as text using Maple syntax, then mark with the mouse and convert to 2D Math). The fonts are also times new roman italics, which resembles LaTeX standard math concretely more than courier new and fonts like that one.

Then let me say that there is the Maple syntax. Not 1D Maple syntax and 2D Maple syntax. But then, unlike in "1D Math input", when you use "2D Math input" the single Maple syntax is displayed in a way that resembles the way we write formulas with paper and pencil. E.g. exponents are displayed as superscripts, fractions as fractions and, automatically, there is a space surrounding the +, *, =, :=, ->, etc. symbols. Altogether, my brain reads formulas faster and clearer. 

Note this my opinion has nothing to do with whether I write programs. As most people here know, I do write programs, since 1996 till today. In fact, I have this opinion after writing a significant amount of Maple programs when there was no 2D-math, and after realizing (in 2008) that on average I understood significantly faster (therefore code ideas also faster) when deriving knowledge using 2D-Math display of input. About the bugs mentioned by others in 2D-Math: post them, they are being fixed, nowadays faster than in the past.

About “Ask [whether to share an existing computational engine or start a new one] each time a new document is created”, with the (non-default) choice of “Ask each time a new document is created”, you have an implementation of the paper and pencil concept of draft computation. You can have a clean worksheet-computation, and in the middle, you may want to try something regarding the next step, using all the assignments and intermediate results you already have: just open a new worksheet sharing the kernel (computational engine) where you can (draft) experiment all you want. Then switch back to the main clean worksheet to continue. Other times the experiment needs to be done with a completely clean, new engine, so choose 'new engine' and again you can do experiments without messing your clean worksheet-computation.

Another good choice (doesn't work right in current Mac OS, the system I use) is to open new worksheets in new windows, which allows you to compare two computations side by side.

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