So this issue is fixed for Maple 18, details at "DEs and Mathematical Functions Updates"

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

So this issue is fixed for Maple 18, details at "DEs and Mathematical Functions Updates"

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

Regarding your actual problem (not the related ones but the one you mention explicitly), intat(A*V*B, u) is not correct syntax, so the inert form Intat will not perform properly if it were evaluated. Hence, unlike "...cannot get Maple to accept this, no matter what type I make u to be", just make u be an equation and it will work. Have in mind, this is not just about intat: limit and other commands have the same syntax, where the second argument must be of type equation. Besides that, if you pass the correct syntax, convert(Intat(xxx, u=v), Int) works fine as useInt.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Michael_Watson 

I gave a look again at this problem today and am unable to reproduce your error message or issues. Some updates happened since you posted your question, so perhaps that is the reason ... don't know. I still need to simplify two times, so Simplify(Simplify((rhs((17)) - rhs((15))) returns 0, and it shouldn't be necessary to simplify twice, but besides that: no error messages or indices repeated more than once.

I may also be missunderstanding your question, so just in case: the replacement of dummy indices in order to achieve simplification is necessary, and the replacement introduced by SubstituteTensor to avoid repeating indices more than once is also necessary. These replacements of dummies sometimes make the identification of zeros by eye more difficult - is this the issue you are pointing at?

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Mac Dude 

Besides assuming, in Maple 18 there is a new Physics:-Setup keyword: realobjects, that you can use to indicate objects that are real. This works different from the standard assume facility in that objects set to be real using Physics:-Setup do not change after you indicate them as real (they do change when you use assume) so that you can reuse previous expressions involving them. Moreover: even if you do not use this option all the geometrical coordinates are automatically set to be realobjects as soon as you load Physics:-Vectors.

All in all: in modern Maple you do not need to use assuming or setting anything in order to have Maple working with the cartesian, cylindrical or spherical coordinates as real. The same is true for any system of coordinates set using Physics:-Coordinates.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi Michael

First I would suggest you to use the latest Physics, that as usual you can get from the Maplesoft R&D Physics webpage - there were many changes in the tensor routines in the last 10 days. Then if you could please make your point more clear. Concretely: there is nothing wrong in renaming dummy indices in order to simplify taking into account Einstein's sum rule for repeated (dummy) indices. Now: if you think that one of the simplifications is wrong, then if you could please tell, precisely, which one would it be, and mainly what is the result you expected, that will help. (For example: you say "there is no combination of alphas that is consistent". I do not figure out what do you mean by that.)

Looking forward for your details.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@maplelearner 
Indeed, I meant to write 10^2 and end up writing 10^(1/2) by looking at the last argument, 1/2 on the lhs. Correcting that typo, the identity is 
MeijerG[{{0, 1/2}, {}}, {{0, 1}, {-1, -1}}, 10, 1/2] = MeijerG[{{0, 1/2}, {}}, {{0, 1}, {-1, -1}}, 10^(2)]

% // N

True

The rhs exists in Maple.

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

@Michael_Watson 

Good to know then that you've found a way to formulate the problem. I also updated Physics as mentioned, fixing that glitch in Physics:-Library:-SubstituteTensor. With the new code your expression l[mu] l[mu] R[~mu, ~nu] simplifies to 

And I haven't tried further to check whether this is already zero (at first sight I'd say it is not) - perhaps the issue has to do with this sign that you are mentioning, or the determinant of the metric ... Anyway, just to say that the discussion around your post was useful also at this end, including some improvments in the code.

Edgardo S. Cheb-Terrab
Physcs, Maplesoft

@Michael_Watson 

I gave a look at your worksheets. There is nothing wrong with the inverse of the metric.

By the way you can see its components entering g_[~mu,~nu,matrix] (will show the contravariant components) instead of g_[] (which is equal to g_[mu,nu,matrix] and shows the covariant components). All this is explained in the help page for ?Physics/g_. Then to verify the contravariant components for correctness just compute simplify(rhs(g_[~mu, ~nu, matrix]) . rhs(g_[])) and you will see the indentity matrix, as expected. Nothing wrong.

There are two problems in your worksheet though. One is that you use algsubs, which does not understand tensors. The correct command to use here is Physics:-Library:-SubstituteTensor, which does substitute subexpressions. The second problem is that there is a glitch in Physics:-Library:-SubstituteTensor that turns evident with your example. I will fix that tomorrow and upload the update to the Maplesoft: R&D Physics page. so that everybody can take advantage of the fix. Note also that all the computations I am referring to happen in Maple 18 plus the latest Physics update (I am saying this because I see your post indicates "Product = Maple 17").

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

@Michael_Watson 
Hi, unfortunately I am still unable to retrieve the files you uploaded. Can you retrieve them? That is the test: after uploading, try retrieving them. If it continues not working could you please send the mw to physics@maplesoft.com, it will arrive at my mailbox. Thanks.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Michael_Watson 
I am receiving "404 - File or directory not found.", maybe a problem in Mapleprimes server? Can you retrieve it?

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

@Alejandro Jakubi 

Unfortunately, it sometimes happens that images of equations, that are there when I post, get lost afterwards. The input was like dchange(n = m-1, Sum(f[n],n=a..b)). Regarding renaming PDEtools:-dchange into something else: yes, it would makes sense. I added this functionality for "changing variables in general" in PDEtools in 1997. Actually there are a couple of things in PDEtools that would be more useful if they were more visible, among them: PDEtools:-<Solve, casesplit, declare>. Perhaps if there is some spare time this could be done. At this point anyway I am sufficiently happy with having all this functionality in the system.

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

@bao 

Rules can be set for Commutator and AntiCommutator of objects, that typically are not commutative. That does not prevent you to set a rule for a couple of commutative objects indicating it as an AntiCommutator rule, you know, where, when A and B commute, AntiCommutator(A, B) = 2 AB, so multiply by 2 both sides of the equation you show and replace the left-hand side by  AntiCommutator(A[i], A[j]); there is also more than one way to do this, depending on whether you define A and/or Q as tensors, which mainly tells the system that it should (or not) use Einstein's sum rule for repeated indices.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Carl Love 
Hi Carl, yes, you are correct, the whole issue here is in expand/Sum, that is not doing the expansion, and then for some historical reason got coded in the wrong place as IntegrationTools:-Expand. See for instance the reverse operation, combine: we have the sum and int cases coded together there. It is easy to fix expand/Sum anyway (but for the time-available issue, you know ...). I will give this a look and post a fix in the Maplesoft R&D DEs and Mathematical Functions webpage hopefully this week, together with some other recent developments in the FunctionAdvisor.

But this expand/Sum issue deviated the focus from the main issue: the general command for changing variables in Maple, in everything (not just integrals, nor just sums, nor just limits, nor just derivatives, etc.) is in fact PDEtools:-dchange.

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

@Carl Love 
Note that IntegrationTools:-Change is just a wrapper around PDEtools:-dchange. Also, you see you do the Expand step separated, subbing Sum = Int. It shouldn't be that way. expand(A) should work. fixing expand/Sum will also make this work within PDEtools:-dchange passing the optional argument expand (dchange accepts a simplifier - it is explained in the help page).

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