@acer 

Excellent, and thanks, I edited now that reply and linked there a zip with the mla instead, and indeed it works.

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

@John Fredsted 

I see now that in Mapleprimes you cannot attach a mla file. I'll try sending it to you via email - for that purpose could you please write me at physics@maplesoft.com.

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

@tomleslie 

The intended result with this change was indeed to "not hang". Roughly speaking:  1) a bug (as in a wrong result or unexpected crash), 2) a hang (doubly relevant if it was not hanging recently), 3) no result for a problem we know a result exists and how to obtain it, is the order in which I prioritize tackling issues. This was of kind "2)", in a case where pdsolve was not returning a result before, but it was not hanging. I didn't investigate the solvability of the problem itself, mainly due to time constraints. These days too many things are falling on my table. But if you have an approach in mind just post it and that by itself opens a new issue of kind "3)".

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

@John Fredsted 

This is not an official Maplesoft patch but attached is PDEtoolsNormal.mla, a library file that you can place in the lib directory of your Maple 2017 (check kernelopts(mapledir) / lib). That fixes the problem, it is a rather small touch in one routine.

PDEtoolsNormal.mla.zip

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

@leostork 

The potentialities are enormous, DifferentialGeometry is a really powerful package. Could you please post a worksheet with your problem (use the green arrow) and I will try to give it a look soon.

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

@nm 

Before version 73, Physics:-Version() told you only the (latest) version found in the MapleCloud. After you install version 73, the command Physics:-Version itself is updated, so that it tells you both the version in the MapleCloud and the version installed in your computer. By the way Physics:-Version()does nothing but checking versions, it does not install or change anything.

Regarding the Warning message: it is the same you see if you install clicking the Cloud icon then packages then install. It is a bit of an extreme message ... Anyway: the update you install includes the fixes and developments (Physics, DEs and Mathematical functions related) found in the (advanced, to be the next) version of Maple we have at Maplesoft.

If you re-install version 72, you also re-install the previous Physics:-Version command, that only tells you the latest version found in the MapleCloud, and that is 73 regardless of you having reinstalled a previous version. To avoid these confusions is that I updated the command Physics:-Version itself.

How do you know which version you have installed when it is a version before version 73 ? Enter PackageTools:-IsPackageInstalled("Physics Updates").

What is this number "5137472255164416"? It is the MapleCloud ID of the package Physics Updates. The team developing the MapleCloud is considering a way to just pass the package's name, not a number. Until that is implemented, we pass the number, but I never remember this number and you do not need to remember it: just click the cloud icon (top right of a worksheet/document), then click packages, select Physics and click the icon to install it.

Now on your question: if Physics:-Version() told you: "/opt/maple2018/lib/update.mla  MapleCloud version: 72" what that means is that the active version of Physics at that point was the one found in the update.mla library of Maple 2018.1, and that the latest version found in the MapleCloud was version 72. My understanding of this output is that at that point you had no Physics Updates installed whatsoever, or that you installed the update but you forgot to enter 'restart'. For example: enter PackageTools:-Uninstall("Physics Updates"), then restart; then Physics:-Version() and you will see the same "/opt/maple2018/lib/update.mla  MapleCloud version: 73" message (now with 73).

Summarizing: after installing version 73 the potential for misunderstanding is gone since both the version in the cloud and the one in the computer are reported.

Now on the other thing, you say that you noticed a problem in version 73? What is this problem? Let me know please so that we can give it a look? Thanks.

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

@Markiyan Hirnyk 

Download NiceAndUsefull.mw

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

@Mbert 

This is a bug, in `combine/power` with respect to noncommutative objects. I'm working on a fix to be available in the next "Physics Updates" for Maple 2018.

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

@Bland3 

I didn't forget about this one - just working on several other things at the same time, hopefully, will have time to work on this one by the end of tomorrow, or first thing in the list next week.

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

@Mariusz Iwaniuk 

DifferentialThomas and some other Physics sub-projects didn't have the documentation ready for 2018.0. We are aware of that. Working on filling these gaps. One way of doing that is again the "Physics Updates" MapleCloud package, but the mechanism within workbooks to update help pages still needs a revision.

In the particular case of DifferentialThomas, to see the package working you can check ?DifferentialThomas,Examples.

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

Hi

If you could please post a worksheet instead of the comments, that is useful to help you. Copy and paste are prone to mistakes.

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

@Rouben Rostamian

I didn't feel offended (personally). But it did pass through my mind that the word unreliable is inappropriate for this case. The Maple DE software is probably the most advanced in the world, I think, and tremendously powerful, even when there is, and will always be, more and more to do. And we are doing more.

Anyway, I know you from several posts here, and I read and appreciate your comments, learn from those that include some analysis. On the particular problem you presented, not the PDE problem that started this post, I will try to make some time to review the idea of returning a solution "u = 0 for given boundary/initial conditions that restrict the general solution to only this single and trivial solution." Mind you any way that I see this more as a formality. As said, for linear homogeneous differential equations, a solution u = 0 is of no value/use..

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

@Mariusz Iwaniuk 

I don't see in Wolfram's output the infinitely many non-trivial solutions mentioned in this thread.

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

Hi John,

I didn't forget about this one. There are a couple of design issues, however, that require further thoughts. One is that, in curved spacetimes, the galilean LeviCivita is not a tensor, at all. So why not making nongalilean be the default when the spacetime is curved? I'm currently inclined to make this change. But then the galilean LeviCivita is used in other contexts as well even within a curved space (e.g. in quantum mechanics, or vector analysis, both areas with commands within Physics to work on them). So another command maybe ... as you suggest. Note something never documented: LeviCivita[j,k,l,m, galilean] works as the returns the galilean value when j,k,l,m have nonnegative correct values, even when Setup(levicivita = nongalilean). But we do not have the symbolic representation for this (would be unevaluated 'LeviCivita[j,k,l,m, galilean]' ... that doesn't work today).

Anyway, this post is getting to the top of my list.

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

@vv 

Determining whether a differential equation has a solution (and of what kind? expressed with what type of functions?) is, if we are to talk with any generality, a problem as difficult as to solve the differential equation itself. So, no, both dsolve and pdsolve return NULL (as solve does), and do not say "solutions may have been lost". That maybe helpful for you but sounds not useful to me, because it would apply to, basically, or mostly, every single case where these commands return NULL.

Regarding returning with PDESolStruc, I think there is only one exception: travelling wave solutions, which are a kind of particular solution, not the most general one, but are not returned within a PDESolStruc, for some reasons that I skip here for brevity. Not being TWS, please show one case of a particular solution not returned as a PDESolStruc and I will fix it.

More important, you missed, in pdsolve's help page, prominent and relevant, the option "generalsolution", and the relate pdsolve's infolevel: it automatically tells whether a solution returned is or is not the most general one. You are a mathematician. Right. I am a physicist, and not surprisingly the author of the differential equation software of the Maple system. Why? I suppose that because we physicists use DEs all the time. 

NOTE: there is a relevant distinction between ODEs and PDEs (and of course also with regards to algebraic-non-differential equations). In the case of PDEs, there are a ton of useful methods for computing particular kinds of solutions, that are relevant in physics, and that are more useful than the general solution. 

To mention but one, with the Hamilton-Jacobi PDE in analytical mechanics you can formulate ALL classical mechanics - nothing less! - in connection with variational principles and Legendre transformations. Well, in this Hamilton-Jacobi PDE formulation, we are only interested in complete solutions, not the general solution . And why is that ..?? Because all the integration constants happen to be conserved quantities. Their determination is formally equivalent to have the whole trajectory in the phase space of the system, ie you solved the problem entirely. This is also related to Noether's theorem (you probably know about that).

Long blablabla. Just to say that PDEs are a very special kind of "equations". More often than otherwise, we are interested in different forms of particular solutions only. This is at the core of the design of this command, which allows computing different kind of solutions (see its option HINT, in place since day 1). BTW for the same reason you have, in Maple, PDEtools:-TWSolutions, PDEtools:-InvariantSolutions, PDEtools:-PolynomialSolutions and PDEtools:-FunctionFieldSolutions, all of which serve the same and single purpose of returning (really a myriad of ) different kinds of particular solutions.

Summarizing, I don't find "unrealiable" any of this, I don't find returning nothing as indicating the opposite, I don't find returning u = 0 for every linear homogeneous DE of any value (generally speaking); if you find a bug (eg a particular solution which is not TWS and is not returned with PDESolStruc) please report it; I don't see (don't take me wrong) useful to say "solutions may have been lost"  (we would be returning that message all the time ...);, there is a "generalsolutions" option for who only needs general solutions; turn infolevel[pdsolve] := 3 and you will see a message informing you about that ALL THE TIME anyway; and regarding FAIL versus returning nothing (NULL), well, the Maple system has designed its solvers to return nothing when they have nothing to return, so dsolve and pdsolve just follow this design, it would be inconsistent otherwise.

Regarding constructivity: your reply is respectful, I like that. I sometimes read some posts that seem to me unbelievable, how could someone have so poor communication style. Your suggestions of displaying a warning message all the time these solvers returns NULL, and to return FAIL instead of NULL don't seem convenient for me, as explained. 

Yet I learn from posts or reply with contents all the time. It doesn't matter how many things I juggle in my mind, on different areas, I'm always surprised with something else I didn't know. Please let's concentrate on that: do you have something to suggest about this PDE mentioned by Rouben? If so, please post it. And couldn't I find something for this PDE myself? Of course, I could. But I already have a list with too many things that I could do. You need to understand this side of the equation. In a situation like this one, either you indicate something concrete to give a look at, or the chances that I will start looking at the problem are really small, no matter how easy the problem may seem.

Best

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