@mehdi jafari 

The Physics package is a large one, it has 67 commands, one of which - Physics:-Library - is actually a programming library specialized in physics with other 151 commands, one of which - Library:-PhysicsType - is actually a package of types specialized for programming in physics with 81 types. One of these type is 'Tensor'.

So suppose you define some coordinate system as when entering Coordinates(X). Then entering type(d_[mu](psi(X)), Library:-PhysicsType:-Tensor) returns true. Likewise, if you Define(A[mu]) (i.e. define A to represent a tensor) then type(A[mu], Library:-PhysicsType:-Tensor) returns true, while the same for B[mu] returns false because B[mu] is not defined as a tensor (so being indexed is not sufficient to be a tensor). Etc.

From the number of Physics commands, programming commands in its Library, and types in its PhysicsType subpackage, you realize that using the Physics framework requires giving a look at the documentation. All the above is documented. Check D_ for covariant derivative, the page for d_, and the page for Physics:-Library, and within there how to list the Physics types. The help page for Physics,Examples has a section on tensors and relativity that can jump-start you. All the tensor notation in the context of the Physics package is indicial. There are commands to work with tensor components and also with abstract tensorial expressions (i.e. involving A[mu], not just its components).

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

@mehdi jafari 

Of course there are things I am not aware of, but I am aware of this one. The thing is, however, and at the same time easy and difficult to understand, that a computer algebra system is something alive, as alive as it can get, changing and growing every single day in many many directions. So, there will always - just always - be too many things to be done, and yet a finite number of people working on them. It requires a pretty "zen" attitude to see the big picture (which is also never the whole picture) and remain calm, just prioritizing things in some way (which is also never perfectly done). I'm not sure I am passing well the idea ... nor whether you are open to think about this outside of the framework of "what you want". Anyway.

Having said all that, it is true as well - of course - that prioritizing in software is something directly related to listening to people (which nevertheless not always say things that sound reasonable). And I personally worked in making various functions sensitive to assumptions years ago (GAMMA, pochhammer and the Ei functions are but a few examples from the top of my head). And in this exact moment, I am deeply involved in developing more "Mathematical Functions" stuff (upcoming post in Appell double hypergeometric functions in a few days ...). If I find some time I will see that more mathematical functions - starting with the elementary ones - take into account assumptions on their arguments.

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

@Preben Alsholm 

Yes, simplify with assume equality is not eval, but the issue here is another one. Try for instance GAMMA(a+b+c) assuming a+b+c = 0 and you see it working as eval. Why the difference? Because some functions test the their arguments for assumptions and others don't - GAMMA does, exp doesn't. In principle, all of them should test for assumptions on their parameters before returning, and if exp were doing that we would have exp(a+b+c) assuming a+b+c = 0 returning 1.

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

"... when destroying all quantum operators, the pre-defined commutation rules still apply, which should not be the case."

Indeed, the mechanism for removing hanging algebra rules after removing previous definitions of quantum operators had a problem in the case of tensor quantum operators. Nicely spotted Pascal!

As usual, the fix is available to everybody in the Maplesoft R&D Physics webpage.

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

PS: I see also that your post doesn't quite fit within the Mapleprimes framework, I need to scroll horizontally in order to read a whole line. You can fix this by setting your Maple preferences (options) -> Export -> Math linebreakingwidth to 6.5. Then, when you post a worksheet, the wrapping will happen within the Mapleprimes framework.

@PhysicsTom 

What is the version of Maple you are using? Under Product, you posted Maple 2015, but I tried now with it and it works fine, although the first line, defining 'g' in terms of 'A Y Y' takes too much time also in Maple 2016 - that deserves a closer look this week; but as said the rest works fine.

Note the day after: the reason it takes time defining 'g' in terms of 'A Y Y' is that 'A Y Y' involves 260 symbolic constants (the components of A[mu, nu, alpha, beta]) and, when you define 'g' (the metric), the defining process in this particular case involves computing the determinant and the inverse of 'g', then simplifying the result 'in size', and all that is what takes time due to the large size of the expressions involved. I'll adjust the option to set the tensor simplifier (Setup(tensorsimplifier) in Maple 2016 + R&D Physics library) to handle this situation more efficiently.

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

@Bachatero 

The update for the Physics package is distributed in the  Maplesoft R&D Physics webpage. There, below the "Download the research version of Physics", you read a date; in this moment: "Files updated on July 28, 2016", and the first zip, Physics.zip is for Maple 2016. There you also have the latest update for Maple 2015 (that includes most of the Physics developments done for Maple 2016) and the latest update for Maple 18 (that includes most of the Physics developments for Maple 2015).

I heard of some people having trouble with this page in connection with caches in the browsers - maybe that is the problem you experienced? If so try flushing the cache, or with a different browser.

Best

Edgardo

@Bachatero 

Sorry that I can't help with that. Unfortunately, it is very difficult to fix things retroactively, ie to make a fix work also for previous releases. The issue is that every package - in this case Physics - changes in sync with (relying on) other changes that happen in the library. Making a fix work retroactively thus would require also change the old library in other parts, which in turn would require making more changes in more other parts, etc. It is almost impossible.

Having said that, you can install the Physics update for Maple 2016 in a Maple 2015 installation, and many things will work (all those not relying on other changes). So depending on the computation you want to do, you may want to try - just be aware that some things will behave unexpectedly strange or just won't work.

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

@Bachatero 

So, now d_[mu](Dagger(Phi(X)) returns in terms of diff whenever mu is a numerical index, covariant or contravariant, and regardless of whether the spacetime is flat or curved.

As usual, the adjusted Physics library is available for download to everybody at the Maplesoft R&D Physics webpage, and only works in Maple 2016.

In case you are curious, the underlying issue: although with paper and pencil Dagger(Phi) or conjugate(Phi) is not a composite function, the computer algebra representation is, and so the code needs to decide (conventionally) on a canonical form (say diff@Dagger or Dagger@diff), an issue that of course does not exist with paper and pencil. In connection with that convention, d_ was returning without proceeding further to avoid contradicting it. In the case of a numerical index, however, the computation can be performed to the end regardless of that convention so there is no point in holding the computation.

By the way: there are no "programmer boys" at Maplesoft. Unless you want to call me a boy :) :) :) If the Physics package were stuff that could be done by programmers without understanding of the mathematical methods used in physics, we would probably have had it in place and finished a long time ago, and also in the competition, where still today nothing even partially similar exists. Somehow the same is the story of the Maple differential equation programs, the FunctionAdvisor, and of some newer special functions, the conversion network for mathematical functions, the assuming command, etc. No programmer boys.

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

@Bachatero 

This is a different problem, not related to the display of Phi(X) instead of the expected Phi, but about the design: why d_[1](Phi(X)) is automatically converted to diff but not d_[1](Dagger(Phi(X))). I will revise this and write here again.

And thanks for pointing to these issues. One thing is to put code together, another entirely different is to have the feedback that permits polishing this code again and again, as much as necessary.

Best

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

@Bachatero 

You are correct - I will give a look at this and write again here soon.

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

@Kitonum 
Just to recall, because is good news, that a fix to this issue is being brewed. For instance, in the example of this post, what we are considering would result in: when willmoss entered D(x) (0), directly in the input he would see D(x)*(0), so the `*` becomes visible, automatically. From a design point of view that aims at using a blank space as `*`, to have it displayed when it would be ambiguous (generally speaking, when the blank is followed by an open parenthesis) seems to resolve the problem well.

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

@Mariusz Iwaniuk 

"Exact solutions for PDEs with Boundary Conditions", not etc., is the topic of this post. I think the developments mentioned are fantastic, also that this is another area where Maple's performance is indisputably better, and independent of your or my opinion about the relative strengths of Maple and Mathematica in general.

Perhaps this is philosophical but I think there are two ways of reading a post. A) Is there progress? Growth? Are the novelties useful? Is the material presented interesting? Instructive? Is this post about facts? Or statements, without supporting facts? Or, alternatively, B) Is there anything else not done yet? Are there others who have done more in perhaps other areas?

Please don't misunderstand me, but I personally feel reading using B) glasses doesn't take you far, doesn't help you achieving long-term success. Regarding A), I wrote the post so it reflects my opinion about how to read and write one.

Anyway, regardless of the above I forwarded your statements.

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

@vv 

I understand u(0,t) is a typo. Otherwise, u(0, t) would be a "boundary condition" but then, generally speaking, there would be no meaning for the question "how to determine the PDE symmetries".

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

@John Fredsted 

symgen is for ODEs only. For PDEs, use the symmetry commands of the PDEtools package (check ?PDEtools, the section on symmetries)

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

Hi Арина Козлова

I am curious about this material. Is there a version in English? Thanks

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