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 

@Rouben Rostamian

Reliable = not wrong results. And unreliable for me means the opposite. Regarding "always" returning a solution (when a solution exists), that is entirely another game. We know that neither computers nor humans can solve all the problem for which a solution exists, because, simply put, people don't know how to do it - or in the case of a computer because a known method is not implemented. That does not make software unreliable.

Beyond semantics, I've said in this forum, several times: to be useful, criticism regarding something that could work better is respectful and has contents. So, no sarcasm, no irony, no disqualifications, and, no matter how "easy" the problem could be, the "criticism" shows how to solve the problem or a reference where something of the like is found. When these conditions are met, we frequently code the method, sometimes right away. The software grows, and everybody benefits from the comment.

The Physics Updates - these include, on equal footing, updates to the Differential Equations (symbolic code) and Mathematical Functions - are not included in a current release. They are advanced in time, the updates and fixes present in the version under development, that will be the new release in the future, but tested and merged into the current release. In the example of this post, I see "eval(diff(u(x, t), x), x = 1)", a minor thing, that makes Maple 2018.0 fail in solving the problem, showing the error message posted. With the Physics Updates, that problem disappears, it is fixed in the version under development, and these Updates make this fix available to everybody right away instead of having to wait for the next release.

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

@Rouben Rostamian

I find pdsolve very reliable. Not returning u = 0 is not a sign that it is otherwise. Think about. All linear homogeneous equations have the (so-called: trivial) solution u = 0. What would be the purpose of returning that? What would be your impression if, at any linear homogeneous problem posed, pdsolve and dsolve say "well, here is a solution: u = 0". Well, I'd think "we all know that, come on, I'm obviously interested in a solution that is not trivial".

More specifically on the reliability of software, If you find bugs, that all software have, either they are fixed sufficiently fast, so that their occurrences happen rarely, or they are not fixed fast enough, in which case I'd agree with you, such a software would not very reliable. But that is not the case of pdsolve.

It is also the case that this PDE problem posted is solved entirely by pdsolve. For that, you need to have installed the latest Physics Updates (version 34) - see the Maplesoft R&D Physics webpage. and follow the Installation instructions on the linked webpage. The Physics Updates is now distributed through the MapleCloud. As is known, this Updates package contains the advanced version of updates for Physics, Differential Equations and Mathematical Functions.

Attached is a worksheet with this PDE problem and its solution as returned by pdsolve, tested with pdetest.

Download PDE_solved.mw

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

@nm 

The link you mention is 8 years old. Nowadays filenames with blank spaces are 100% standard.

Note as well that the main technical reason pointed out everywhere in this link you posted, is that filenames with blank spaces require special care when used from a command line. That is a terminal in UNIX/Linux or a DOS command line window. Perhaps that is the reason. I am skilled with UNIX, and also with DOS, and Macintosh is UNIX, but I almost never use a command line, and in Macintosh, when I use it, I use tab to retrieve file names, that handles blank spaces perfectly well. And then GUI programs are for me simpler, I learn how to use them rapidly, and work with them orders of magnitude faster. I tend to believe that the vast majority of users also access this Maple update not from a command line, but through the MapleCloud, or the Maple input using PackageTools:-Install. Eventually, through an OS file manager, that in all the three OS are GUI style and handle spaces in filenames natively and flawlessly.

Nowadays this feels to me more like a matter of preference. Although not the same issue, it somehow reminds me of the preference for working with 1D or 2D Math input. Many people prefer 1D Math input. After working 15 years with 1D Math input, since 2008 I prefer 2D Math input.

Still, as said, if someone points to a concrete problem, a real one in installing the Physics Updates due to the space between the two words, I'm open to reviewing this.

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

@nm 

... I have a more recent Maple (the version under development), so I don't see this problem you are showing. I imagine that, in 2018.0, what you show is related to the MapleCloud issue: the "Physics Updates" package is installed one subdirectory down, in toolbox/2018, and the PackageTools commands assume this extra layer (2018, indicating the release where this update works) does not exist - they scan for packages just below toolbox. For example, try PackageTools:-ListInstalledPackages()  and see whether it reports Physics Updates - it does not.

Until this issue with the MapleCloud and related PackageTools gets fixed, I suggest you to just give a look at the date returned by Physics:-Version(), March 28, versus the date of the latest update shown in the MapleCloud, 2018-04-13.

Regarding the name: I understand linux handles blank spaces in filenames out-of-the-box. It is more readable in general. So unless there is a more concrete problem that you could mention, I prefer it this way.

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

@digerdiga 

3. After doing F[mu,nu]  :=  D_[mu](A[nu](X)), you do not have F[1,2] returning the component 1,2, to mention but one, or any of the things I show in the worksheet I posted. Of course if you enter F[mu,nu] you get what you assigned to it but what is the value of that if F[alpha,beta] is not equal to D_[alpha](A[beta](X)). Try type(F[alpha, beta], Physics:-Library:-PhysicsType:-Tensor). It returns false. Try with mu,nu, it returns true, all this is natural, but definitely not what you intended, which is to define a tensor F[mu,nu] whose components are given by D_[mu](A[nu](X)) and the definition is not valid only for the values mu and nu of its indices. If you still think it works then please before posting more on this take a minute reading the help page for Define. And no, it does not expand when you write g_[mu, nu].F[`~mu`, `~nu`] because you assigned to F[mu, nu], not to F[~mu, ~nu].

Regarding your not numbered question on how comments work, digerdiga, please don't take me wrong but this is a forum for questions that are beyond the documentation, or at least these are the questions I'm happy to spend my time answering.

4. Yes it is mandatory to use the argument (X). But again this is something you can check by yourself: enter without the argument X. What you see? Have you checked that. The rhs is equal to zero, because the derivand does not depend on the coordinates.

On your other not-numbered question, with this you exhausted the ones that I answer but you could check by yourself (you really need to get into checking things before asking): if you define F[mu,nu] correctly, of course F[~mu, ~nu] works.

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

@Arny 

Hold on: in the Mathematica input/output you also integrate over p1, not just p3. In the maple input/output you integrate only on p3. Therefore these two things cannot be compared. And your image does not show any Mathematica output for the integral, only the input. In addition, in your last worksheet attached you use some nonexisting commands DotoProduct and CrossProduct.

So go back to the worksheet you attached first, correct your wrong integration range replacing the duplicated range on p__3y by one in p__3z, add integration ranges for each of the three p1__<x,y,z>, and you now have the problem set. Then expand the integral, using expand, to remove occurrences of unit vectors. Tackle now with 'value' and after a little while you receive "undefined", which in my opinion is correct, or maybe I am missing something here that I don't see what would that be.

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

@digerdiga 

1) When working with a curved space, the signature is relevant with regards to transformations of coordinates from the curved spacetime to a locally Minkowski orthonormal system of references (this transformation is key in general relativity, the resulting system of references is also called the tetrad system). So depending on whether the signature is (+ -) or (- +) the transformation (or tetrad, see the help page ?Physics,Tetrads,e_) will be different, as well as the corresponding Minkowski metric. So, no, the signature is not irrelevant. Having said that, if you do not work with tetrads, setting the signature here makes no difference.

2) The notation and conventions used in this package are as said in the help pages: we follow the Landau book. In this book (and actually in most general relativity textbooks - albeit not all of them), what distinguishes the Christoffel symbols of the first and second kind is the covariant/contravariant character of its first index, not the third one.

3) No, an assignment as in F[mu,nu] := D_[mu](A[nu](X)), does not work as you intended, at all. That is at the core of why the computations in you worksheet don't work. And no, using assignment for the purpose you want was never intended to work. More important, and general advice when using computer algebra: read the documentation. Never use a command without giving at least a look at its help page, and in the one for Define this is explained: you do not define the components of a tensor using assignment. Instead, you use an equation definition.

4) As you realize in your comment, D_[~mu](A[mu](X)) with the contravariant index in the covariant derivative operator, is, of course, the same as D_[mu](A[~mu](X)) with the contravariant index in A. Now, in Physics, there is the friendly approach where in cases like these you can enter both indices covariant (or contravariant) and the system will make one of them be the other way around so that you have one covariant the other contravariant. But you can always indicate this, for example entering D_[~mu](A[mu](X)) or D_[mu](A[~mu](X)), in which case the system will never change your choice. In your example you are using a definition F[mu,nu] = D_[mu](A[nu](X)), so when you compute the trace there is no way the system could guess that you want the first or the second index contravariant. Still, if you want to have the trace expressed using the contravariant components of A, one way of achieving that is to tell that to the system. Make your definition of F explicit regarding A being contravariant. For instance as in F[mu, nu] = g_[nu, alpha]*D_[mu](A[~alpha](X)); Define(%);  and now when you input F[trace] you will see it expressed as you indicated, using the contravariant components of A.

PS: I wonder what is the meaning you intend with your several uses of ??, ??? and the like. Mind you, they do not look polite.

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

Hi Digerdiga

It is always helpful to upload a worksheet with your input/output. For that purpose you can use the green arrow; note as well that you can write the text directly on it, and when you upload it you can request to show the contents, besides you sharing the worksheet so that others can reproduce the problem and give suggestions. 

Without a worksheet, to try to help you implies on more work, it is prone to mistakes through copy and paste, etc. Could you please upload your worksheet?

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

@rahinui 

Thanks for your kind comments :) Just to say that the fix for Maple 2018 is already uploaded to the MapleCloud, distributed within the Physics Updates, that contains updates to all of Physics, Differential Equations and Mathematical Functions.

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

@peter137 

I implemented yesterday the d straight and in bold, and included this change in the Physics Update - the last one for Maple 2017, and also in "The First Physics Update for Maple 2018".

I thought, like you, that not bold is closer to ideal, but distinguishing what you see from d(x) only by straight versus italic could be missed easily. The grey is in use for inert, everything that starts with %, and at this moment we distinguish between %d_(x) an d_(x) precisely using grey for the former. Using a completely different colour could also help - I considered that - but we already have several colours (commutative, anticommutative, noncommutative and inert). I prefer to not add one more colour only for this.

The collision with bold for vectors (the default is an arrow, but someone could choose bold as you correctly pointed out) is something to think, maybe using a different font could help removing bold. Anyway the improvement is in place, refining it, if necessary, is for a second round.

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