Hi nm

Mariusz Iwaniuk is correct, and the help page of pdsolve tells the same: this command returns one solution, as general as possible. As usual, the design is debatable; I designed this a long time ago having in mind that, for PDEs, the concept of a particular solution is, at the same time, useful, and there are just infinitely many ones, making little sense of the idea of "returning all particular solutions" available.

Frequently, more relevant than "many particular solutions" it is to know what kind of particular solution you are getting. E..g, whether it is a so-called complete solution, relevant in the Hamilton-Jacobi formulation of classical mechanics, or separation of variables, relevant in electrodynamics and quantum mechanics, or symmetry solutions with what kind of symmetry, the information being relevant depending on the context.

Anyway, Mathematica is not stronger than Maple to return particular solutions either. In the two PDE examples you brought, the solutions are traveling wave solutions, as you can see using infolevel[pdsolve] := 2. So for the two examples you posted, try PDEtools:-TWSolutions(pde) and you will see the two and the several many solutions you posted. 

More relevant: you can also try your two pde with the optional argument function = sech, or function = JacobiSN, or function = .... You will be surprised how many particular solutions of this kind exist - none of them returned by Mathematica, which has none of these options. You can as well try the option 'extended' - you will get not just more solutions but also more general. Example (22) of the help page is a beautiful one. All these things are explained in the help page ?PDEtools:-TWSolutions.

By the way, because for PDE particular solutions it is relevant to know what kind of solution you are getting, another  advantage in Maple is the infolevel mechanism used by pdsolve to convey that information.

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

Hi Rouben

In the documentation, first paragraph, it says "[Its purpose] is to permit a simple, compact display of functions and derivatives on the screen".

In the third paragraph it says "This scheme also displays all differentiation variables as indices, and permits declaring a prime variable so that, for functions of one variable, derivatives with respect to that declared prime variable are displayed with a prime."

So the behaviour you are showing is intended, according to the design and its documentation. The Examples section of that help page also illustrate with examples what is said in these two sentences: derivatives are displayed indexed, and the functionality of declared functions is omitted.

Now, I imagine you read this help page. What is not clear in these two sentences or in the examples that motivated your post?

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

Hi nm, Tom,

The 'method = ...' is new and only for PDE & BC problems. Implementing it for PDE with no BCs is possible, but a whole different project. So taking 'method = ...' for PDE only is not valid. Thus the error message you see: you are passing a wrong extra argument. As for your suggestion of ignoring the extra argument, I think that would be misleading: people (would be my case) would then think that 'method = ...' works, that they just passed a not good method. Regarding documentation, it is not documented in Maple 2018.2 because as said 'method = ...' is new. Attached is a first version of what would be an updated help page mentioning it.

pdsolveBoundaryConditions.mw

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

Hi nm,

D[1]*u(1, theta, t) = 0 is just the product of D[1] times u(1, theta, t), equated to 0. That is not, at all, a third notation to enter a derivative. 

From the point of view of an initial/boundary condition, factors that don't depend on the variables of the problem (would be D[1] in that product) are automatically discarded so entering D[1]*u(1, theta, t) = 0 is the same as entering u(1, theta, t) = 0. That is all about your actual question.

I realize you took this equation for the post I made (example number 8); indeed, I made a typo there, partially hidden by the mathematical notation, and pdsolve solved this problem with u(1, theta, t) = 0. I will look later this week to the same problem but with D[1](u)(1, theta, t) = 0 as a boundary condition, using the derivative, not the function itself.

NOTE: Dec/23, I corrected the typo in the original post, the two valid different problems, with and without the typo, are now solved.

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

Hi nm,

I have installed version 263 in my copy of Maple 2018.2, so apparently the problem is not in your computer or in the Update but somewhere else ... Anyway I tried now the following:

1. Input PackageTools:-Uninstall("Physics Updates") - say yes to everything towards uninstalling the package
2. Close Maple
3. Open Maple, click the MapleCloud icon on the Maple toolbar, then Packages, find Physics Updates and install it.

And in that way I re-installed the package normally, it worked fine again. I hope this helps you. By the way upcomming version 264 (later today) has further developments in PDE & BC.

Best

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

Hi

Check the PDEtools commands ToJet, FromJet, diff_table. The first two allow you to input your equations in jet notation and have the software rewriting it for you in the notation used by dsolve and pdsolve, then re-expressing back the answer in jet notation if you want. The diff_table command is different, and in some sense more convenient: it allows you to input things using jet notation and have them automatically coming out in the standard function notation used by dsolve and pdsolve to solve differential equations.

If you also use PDEtools:-declare you will see on the screen everything in jet notation, even when what you are looking at is expressed using the standard function notation.  

By the way, all the Lie symmetry commands of the PDEtools and DifferentialAlgebra packages work internally using jet notation.

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

 J F Ogilvie 

You have a very peculiar way of expressing your points of view ... I will disregard that for this one time and try to help you with the contents.

The Maplesoft Physics Updates work fine with TTY cmaple, and also with the Standard Interface distributed with Maple, maintained by Maplesoft, and also with the not-maintained-anymore-since-years, so-called "Classic," ancient interface, the one you say you want to use, that was developed in the 1990s, provided that Maple itself runs properly in that interface.

IMPORTANT: the Maplesoft Physics Updates require you to have installed the latest Maple version (2018.2.1). If that is not the case Maple will warn you and point to the webpage from where you can download a version of the Updates for your version of Maple.

Now, that there are other things in that ancient "Classic" interface not working the way you expect, as you are saying, would seem expected for me, for the reasons mentioned in the previous paragraph. That is also not related to physics or my person: as you pointed out in your post, Maple 2018.2 is already having trouble to run in that not-maintained ancient interface. Interfaces developed more than 20 years ago typically don't work 100% or at all in nowadays operative systems, a situation standard in software. You could still argue that "Classic" is included in the distribution of Maple (not for Macintosh since many years). Yes, but you know it is not maintained anymore and that is not the interface Maplesoft indicates to use with the Maple system, since years.

Then if for you, using the ancient "Classic" interface, is relevant for any reason, working with the last Maple that runs fine for your purposes in that interface would be the way to go, I suppose. Otherwise, I suggest you to start using the Standard interface, distributed with the Maple system, intended for its use, and well maintained by Maplesoft.

Maybe of help for you in that transition: open the preferences of the Standard interface, the one distributed with Maple and maintained by the company, and choose to use worksheet instead of document mode. If you prefer, also choose to use 1D math input (so-called Maple Notation). These two things already make the Standard interface distributed with Maple nowadays work primarily as that ancient "Classic" one, as said not recommended and not maintained anymore for many years. If the remaining differences are still important for you then, unfortunately, I have nothing else to suggest you.

Hi John

This difference in behaviour between `.` and Physics:-`.`, for A^n (n an integer) when A is the computational object Array of dimension 1 or 2 is not present anymore after installing the Maplesoft Physics Updates version 240 or higher. Arrays (for which type(A, Array) returns true) are now kept unchanged, not rewritten as the object Matrix.

In that sense, this is now adjusted for good, or fixed, depending on whether you see this as an undesired incompatibility (my take on this nowadays) or a bug.

As for the origin of this problem: the same way you  - somehow - found "natural" (say?) that for a 2x2 table of numbers the object A^(-1) would satisfy A . A^(-1) = Identity (number 1 in the diagonal, the rest equal to 0), I also found that natural 15+ years ago when coding this.

But if A is represented using the computational object called Array, then A . A^(-1) is not equal to the Identity but to a square table of numbers all of them equal to 1. The first time I saw this I thought it was a bug. As Pascal4QM says, for the computational object Array, `.` is performing elementwise multiplication. As a physicist, I thought this behaviour was undesired, prone to mistakes. Whether you represent the square table of numbers using the computational object called Array or the one called Matrix (and both are displayed the same way on the screen - as a square table of numbers), in mathematics, the dot product of square tables of objects is called matrix multiplication, not elementwise multiplication. So, in Physics:-`.` day one I also coded a convert(A, Matrix) when A was the object called Array before proceeding with the "multiplication" of square tables of numbers.

And nobody ever complained about this or found it unnatural for 15+ years, but today (this post by you).

Looking at this design issue today, it also seems to me relevant to keep the differences in behaviour - sometimes unavoidable - to a very^2 strict minimum. So the adjustment mentioned at the beginning. 

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

Download solution_-_not_hanging.mw

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

Download Fixed_in_Physics_Updates_version_201.mw

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

Download Find_dimension_of_underlying_symmetry_group.mw

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

Hi guru

Copy and paste is not convenient. It is prone to errors and extra work for whoever would like to get involved with your computation. So next time could you please just use the green arrow you see when you prepare your post and attach a worksheet with your problem?

In the meantime, at the end I am posting what I could understood of the pasted lines you posted: the tensor you define is not identically zero. Regarding tensorial simplification, you could give a look at the help page of Physics:-Setup, the section on tensorsimplifier. I paste here the section of that help page for convenience. You set is as in Setup(tensorsimplifier= your_simplifier).  

• tensorsimplifier
   Any procedure to be automatically applied when tensor components are computed (e.g. for the general relativity tensors)
  The default tensor simplifier, automatically applied when computing the components of the predefined general relativity tensors, and also of any user-defined tensor, is Physics:-TensorSimplifier, a general simplifier withemphasisin handling radicals. Depending on the problem, however, other kinds of simplification may be more convenient. When the tensor components involve large algebraic expressions, for speed reasons, one may also prefer to only apply a (fast) normalization - for this purpose use tensorsimplifier= normal (see normal). One can also set tensorsimplifier= none in which case no simplification is applied but for some unavoidable zero recognitions performed in a few intermediate steps (e.g. when you set a spacetime metric, to verify that its determinant is different from zero). To restore the tensor simplifier to its default value use tensorsimplifier= default or Setup(redo, tensorsimplifier).

Download Cotton_tensor_and_simplification.mw

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

Download Fixed_in_version_208.mw

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

Hi

There is partial information. There are the two Mapleprimes posts, Maple 2018: Updates to Physics Differential Equations and Mathematical Functions and Tensor Product of Quantum State Spaces. There are also several answers I gave in this forum that have the word "Fixed" in the title (you can give a quick look at these clicking my name in this answer - a page with a summary of my participation in this forum will open - and there click on "Answers").

As a summary, the current version of the Maplesoft Physics updates for 2018 (version 193), actually means quite more than 193 changes posterior to the release of Maple 2018, divided into three categories:

1. Fixes and adjustments all around, in code that is relevant to Physics, Differential Equations and Mathematical Functions.
2. Significant developments in the computation of exact solutions for PDE & Boundary Conditions problems - some of these posted here, see for instance Solving PDEs with initial and boundary conditions: Sturm-Liouville problem with RootOf eigenvalues.
3. Significant developments in the quantum part of Physics, mainly several improvements in the handling of Dirac's notation that allowed for the introduction of tensor products of quantum states in a much more general way, including setting disjointed Hilbert spaces using Setup, also a full implementation of coherent states, including their typesetting, a myriad of improvements in the normalization of expressions involving quantum operators, Bras and Kets (using Physics:-Normal) and in the handling of commutation rules, including those for the Pauli matrices.

Anyway the information publically available is incomplete, I didn't have the time to present the improvements in a more complete and organized manner. That typically happens in the "What's new in Physics" help page of each Maple release, whose contents summarizes the changes of the whole year and I frequently post here in Mapleprimes before the release is out.

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

casesplit_and_pdsolve_ok.mw

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