@maleclerc88 

The problem is resolved, you need to update your Physics library from the usual place, the Maplesoft R&D Physics webpage.

The issue: because A is a quantum opetator, A[1] operates on the first quantum number of the basis of Kets labeled A, while A[2] operats on the second quantum number of that same basis. Therefore, A[1] and A[2] commute. At the same time, the AntiCommutator rule set made A[1] and A[2] anticommute, resulting in a logical inconsistency resulting in (the absurd) A[1] A[3] = 0.

It is curious how this went undected when writing the first reply. The situation is of course unusual. Anyway the code now checks for that before concluding about commutation/anticommutation of operators, so that if A[1], A[2] anticommute, because you set a rule specifying so, then they do not commute regardless of operating on different quantum numbers of the same basis of Kets.

Then simplify(A[1] A[3]) does not return 0 (wrong) while simplify(A[1] A[3] + A[3] A[1]) does return 0 (correct). You need to update your Physics library containing this fix as said.

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

@nm 

Order is an environment variable that is assigned a number. Therefore it cannot be an optional argument: dsolve(blabla, Order = 20) would result in (arrive at dsolve as) dsolve(blabla, 6 = 20). For this reason, in dsolve,series, pdsolve,series, DifferentialAlgebra[PowerSeriesSolution], DEtools[rtaylor] - these from the top of my head but I believe that also everywhere else in the Maple system where you compute series solutions - the optional argument is called order = n, not Order = n. Just to say that Maple made its mind about this time ago, and it is consistent.

On the other hand, it is true, order = n is documented in all these help pages (pdsolve,series, DifferentialAlgebra[PowerSeriesSolution], DEtools[rtaylor], ..) but not in dsolve,series, confusing you. This is an oversight. I will make sure the option is mentioned also in dsolve,series.

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

@tomleslie 

In the help page for Physics,Vectors, I see

which shows the ordering: for spherical coordinates, phi in third place. The convention for the ranges is rather standard and found in basically all physics and vector analysis textbooks. I added an explicit sentence "where theta ranges from 0 to Pi and phi from 0 to 2*Pi right after the image in the ?Physics,Vectors help page.

VectorCalculus is not part of the Physics package. The conventions for the coordinates in the VectorCalculus package are presented in ?VectorCalculus,Coordinates and today I am not working, just perusing here, but from the top of my head (see ?VectorCalculus,SetCoordinates) you can set the ordering as you prefer, for instance via SetCoordinates(spherical[r,theta,phi]), or [r,phi,theta].

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

This new command, introduced in the library as Physics:-Library:-Assume, has more relevance than what seemed at first, so I moved it one level up, it is now one of the main commands of the Physics package. I will see if it can be made  available also as an option (e.g. redefinevariables = false) of the old assume command.

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

@Markiyan Hirnyk 

pdsolve(pde, build) returns the built form of the solution. Because a solution through separation of variables is a particular solution, it is important to make this information (the kind of separation of variables) visible. As explained in ?pdsolve, the solution is returned automatically 'built' when it is a general solution, otherwise when you receive a PDESolStruc as in this case, use the option built.. In brief: either this solution you posted, or the explicit and correct analytic-exact solution it returns when you use the option built are useful. Relevant as well, in the case of Shrodinger's equation, actually, the solutions of interest as mainly by separation of variables. 

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

@Michael_Watson 

In the reviewed worksheet I posted with the previous reply, I do not see difficulties in eqn3 - what is the problem you are experiencing? Perhaps if you share a worksheet showing the issue?

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

@acer 

The edited version you posted looks excellent Acer!

Best

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

@VicenteAtal 

I know some bits on the internals of the Maple worksheet representation but this is beyond my knowledge - I forwarded your worksheet to the Maple GUI gurus.

Best

Edgardo

Hi

Perhaps you could post a worksheet showing, say, where you are with your problem and where is that you don't know how to proceed further?

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

@J F Ogilvie 

Yes, any of these two you mentioned would serve the purpose you have, but you need to reverse the order in the equations; i.e use 

BTW, the "powerhouses" for developments like this one are the packages, that require more and more functionality.

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

@J F Ogilvie 

Replacing assume by this new Physics:-Library:-Assume would not be appropriate at this point, after so many years of existence of assume. If we were to do that, worksheets or programs already developed by people and that rely on, or make use of the redefinition of variables performed by the old assume, might then require adjustements, because removing this inconvenient redefinition is actually the main feature of this new Physics:-Library:-Assume.

On the other hand, after a week using this new Physics:-Library:-Assume, the advantages are so obvious that Physics:-Library:-Assume could better be a user level command, instead of one somehow hidden two package-levels within Physics.

A similar situation happens with this new functionality, automaticsimplification, as well as the redefinesum and combinepowersofsamebase, all of them current computing-mode options of the Physics package, that introduce functionality very useful also outside the framework of Physics. 

Likewise, PDEtools:-declare, PDEtools:-Solve and PDEtools:-casesplit have highly regarded functionality useful beyond differential equations, as well as the commands for performing Union and Intersection of regions of the complex plane expressed algebraically, both currently within the MathematicalFunctions package.

But things also change with time. The originally internal solver of ODEtools, called `ODEtools/Solve` ended up as a useful addition to solve; the code under `ODEtools/first_integral` got renamed as int/homotopic and is nowadays an important part of int, the same way as internal DE code formerly developed to compute certain kind of elliptic integrals, and the current `int/parallel`, also former DE code for integration. In the same line, IntegrationTools:-Change is actually a wrapper around PDEtools:-dchange. Or more important, the internal DE code to manipulate assumptions related to DE parameters ended up as the skeleton of the current assuming command, the internal DE conversion routines for mathematical functions related to DE special function solutions are today the skeleton of the FunctionAdvisor, the routines for compacting DE solutions are now known as simplify(expresion, size), also now at the core of this new automaticsimplification of Physics, and etc. the list is large.

All this is to say that the Physics, PDEtools and MathematicalFunction packages are also, somehow, small powerhouses for these developments. That is good, as opposed to "bad because of happening within packages". Let's see the filled part of the cup. And when the development is very good it often ends up available as a user-level command in one way or another.

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

@Markiyan Hirnyk 

{1+I*y : y>=0} union {-1+I*y : y<=0} is not a branch cut of sqrt(1-z^2). Just clarifying. Having said that, yes, a command of the form is(..., branch_cut of ...) would be useful. All the tools for developing it are already in place; these are the hidden exports of MathematicalFunctions, `&Intersect`, `&Minus`, `&Union`, that I still need to document.

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

The reference you are mentioning actually corresponds to the work of the U.Bath group previous to Maple 17. The actual reference describing the Maple 17 implementation is:

"England, M., Cheb-Terrab, E., Bradford, R., Davenport, J. and Wilson, D. (2013) Branch Cuts in Maple 17. ACM Communications in Computer Algebra, 48 (1). pp. 24-27. ISSN 1932-2232"

The main reference for computer algebra implementations of the computation of branch cuts is anyway 

"A. Dingle and R.J. Fateman. Branch cuts in computer algebra. In Proceedings of ISSAC ’94, pages 250–257, 1994."

The method used by the U.Bath group, that is the departure point for the Maple 17 implementation, is in fact mentioned in this paper from 1994.

In both papers, the one from 1994 and the one from 2014, it is pointed out that the difficult part is the detection of spurious cuts (in order to not return them as if they were actual cuts). Despite the terminology, spurious cuts are easy to understand: they basically happen when different sub-expressions of one expression have cuts that intersect over some segments but with opposite signs, cancelling each other over those intersecting segments. Ie over those segments there are no branch cut. All the computer algebra implementations of computation of branch cuts previous to Maple 18 have trouble in detecting these intersecting segments.

New in Maple 18, however, spurious cuts that are over the real axis are actually detected (ie are not returned). The algorithm implemented in Maple 18 is new, so not described in any of the two papers above. This algorithm was developed entirely at Maplesoft. Through rotations, this algorithm can be extended to cover straight segments anywhere over the complex plane, and there is a way (more complicated, but doable) to also cover non-straight segments.

I still need to find the time to do the writeup of the algorithm implemented in Maple 18, then present the resulting description for publication elsewhere, as well as to finish extending the implementation as said in the previous paragraph. Not so soon ... For now I'm rather busy with the Physics package, mainly new developments for general relativity and covering some gaps in functionality for particle physics.

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

@Andriy 

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

@nm 
Other people already requested the automation of the installation of Physics updates by means of a mini-installer. Tha would save having to unzip, read installation instructions, move files around etc. These requests were forwarded to the people who take care of that at Maplesoft.

Note anyway that there are two different things: having a mini-installer for the update and having a button to check for updates. The latter is more complicated in that it requires a change in the GUI ... perhaps in a future release. Also, currently, updates hare happening mostly everyday, so a button to 'check for updates' would be redundant. The relevant step ahead today, I think, would be to have a mini-installer for these updates.

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