@John Fredsted 

1) The algebra rules for the Pauli and Dirac matrices are now implemented automatically, ie they are known to the system as soon as you load Physics

The update is available to everybody at the Maplesoft R&D Physics webpage.

2) The Dirac matrices do not commute with anticommutative variables (and there is no need to declare the spinor as a non-algebraic Vector construct). But you need to use `*`, not `.`.

BTW: for any A, B, after loading Physics, Library:-Commute(A, B) will tell you whether A*B = B*A.

3) The use of `.` in this case should have used the same commutation rules of `*`; I will give a look at this and fix it.

Finally, could you please post the cases you either feel you "hit a roadblock" or you find them to be "non-intuitive formalism", or simply you get frustrated for whatever reason.

The Physics project is really original in its attempt to bring alive, within a computer algebra worksheet, very^2 dense mathematical notation and methods. A project like this requires concrete, frequent and sufficiently detailed feedback. At this point several Maple users (mostly physicists) are providing this feedback. And then from the development side, we are providing frequent updates, extensions, revisions, etc. at the Maplesoft R&D Physics webpage, that end up being useful for everyone.

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

@Markiyan Hirnyk 
 

Download trustable_pdsolve_and_pdetest_(II).mw

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

@Markiyan Hirnyk 
 

Download trustable_pdsolve_and_pdetest.mw

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

@Pascal4QM 

Just to note that you can use notation that starts at 0, as in 0, 1, 2, 3, and the 0 as a tensor index is automatically mapped into the number 4 (when the signature has the timelike component in position 4, e.g. (- - - +)). Then when you actually display the matrix (or Array) form of a tensor, the first column is the column number 1, an the column "0" is actually the column 4.

It is a bit tricker when you work with signatures that place the timelike component in position 1, e.g. (- + + +); in this case the number 0 actually points to position 1, but then the value 1 of a tensor index points to position number 2, and so on. This is difficult to remember and so not the default signature.

For any of the four possible values of the signature, you can still set the system to "use coordinates as tensor indices" (see the Physics:-Setup option usecoordinatesastensorindices) and in this way, suppose your coordinates are [r, theta, phi, t], then just write g_[r,r] or g_[r, t] and they will have the natural meaning, without having to remember the position of r and t in the list of coordinates (the computer remembers that position when you set the coordinates).

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

@Arny 

After these corrections youwill have the problem formulated in a way the computer understands it. Regarding your use of DotProduct and CrossProduct it made me think that it may be convenient for you to give a further look at the help page ?Physics,Vectors and pages linked therein to see what are the names of the commands representing the operations.

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

@Arny 

To get the right display, enter Setup(mathematicalnotation = true). But mostly: you need a more modern Maple.

Time ago, these integrals were computed as undefined. Nowadays they are computed as a distribution (Dirac). I don't remember in which version I introduced Diracs but probably Maple 2015, or Maple 18. Note as well that there are updates for the Physics library distributed in the Maplesoft R&D Physics webpage. Physics is almost duplicating its size at every release till 2016 ... and it is still growing in many directions.

These updates are posted basically every week, sometimes several times per week. These updates started being distributed with Maple 18 and there is a link for updating Maple 18 in that R&D page - I don't remember if it contains this change that makes int return Diracs. Anyway there is no update for Maple 17, that is by now somewhat old.

PS: a note on my previous reply, you can save some typing using [x, y, z] =~ -infinity..infinity instead of repeating the integration range three times as I did in the reply worksheet.

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

@Arny 

Download VectorIntegral.mw

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

@Louis Lamarche,  tomleslie

I misread here! Sorry. The problem you mention was indeed an issue. In Physics, the order for spherical coordinates is [r, theta, phi] while in VectorCalculus is [r, phi, theta], this is taken into account in one of the conversions (to Physics) but was not taken into account in the other conversion (to VectorCalculus).

This issue in the conversion to VectorCalculus of a vector of the Physics package in spherical coordinates is fixed now. The fix is available to everybody within the updated Physics library distributed in the Maplesoft R&D Physics webpage.

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

Very nice everything!

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

@_Maxim_ , Axel Vogt,

Big oops. You are both right, this conversion of MeijerG to hypergeom has a problem for abs(z) > 1 in general, regardless of Re(z) < 0, case p=q and m+n<=p. Have you noticed any other case, so that when fixing this conversion I can check them as well. Thanks

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

@_Maxim_ 

The plots, as well as the original example of this post, are correct for Re(z) < 0 or abs(z) < 1, not just the latter. The problem is in rather ancient code from 1996 ... I will give this a further look.

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

@Markiyan Hirnyk 

The improvements mentioned by Eithne are in the computation of symbolic (so exact, not numerical) solutions to "PDEs & Boundary Conditions" problems. I just posted a set of examples illustrating these improvements.

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

@MrMarc 

The article behind this map of topics, linked in the post, is what gives context to the map. It says right after in its title:  "Explore the deepest mysteries at the frontier of fundamental physics, and the most promising ideas put forth to solve them". The theories mapped, thus, refer to fundamental physics only, as the map itself shows. This map is indeed an excellent summary of the ideas being explored in the area, that not surprisingly revolve around general relativity in one way or another. Mainly on how to unify this theory of spacetime with quantum mechanics, the topic of Nima's presentation, Quantum Mechanics and Spacetime in the 21st Century, also linked in the post.

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

@Pascal4QM 

:) Thanks. This problem you indirectly focused, however, after some discussion, we agreed at this end that it is indeed unexpected behavior in the kernel. Not OK. In the example mentioned F[1,2](x,y) should return f[1,2](x,y). The issue is now tracked to be fixed in the kernel. Meantime, and only for Physics tensors, the library (not kernel) tweak I introduced yesterday works around the issue.

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

@_Maxim_ ,  Pascal4QM,  vv

Yes, your suggestion works, but there is a consistency problem. Consider

with(Physics);
Define(F[mu, nu] = Matrix(4, symbol = f));

Now, without defining f as a procedure, just enter

F[1,2]
                  f[1,2]

Good. Next:

F[1,2](x,y)
                 F[1,2](x,y)

I was expecting f[1,2](x,y). This is the problem I referred to in my previous reply, perhaps not clearly. I expect F[1,2] to be evaluated, so become f[1,2], then f[1,2] to be applied to (x,y).

Indeed this problem is not visible when you define f itself as a procedure, what you _Maxim_ and PascaQM are saying, eg one that makes use of its indices for the purpose of Pascal's example (see vv's reply, many Maple procs are defined that way, for instance, Physics:-d_),

So why my fuzz? Perhaps because these things, if let in place, for me they attempt against the intuition on how the language works.

Anyway, I fixed this now, as explained in the previous reply, so that we now receive f[1,2](x,y) even when f is not a procedure. The adjustment in the code is available to everybody now, as usual in the Maplesoft R&D Physics webpage.

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