@Alejandro Jakubi 
Nicely spotted. Debugging, the problem happens in a call to additionally below SolveTools:-Transformers:-Inequality:-IntegerVarSolver.

Note however that dsolve does not place this assumption and it is not related to the DE solving process: that call to additionally below SolveTools placing assumptions on U__0 actually returns an error (and leaves a bogus empty assumption to U__0 in place).

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

@Carl Love 
Carl, the images where there, of course, when posting. Then they were not there anymore. It looks like the old problem mentioned other times that seemed fixed recently. Apparently it is not fixed. I will see to create a worksheet with the same contents

Edgardo S. Cheb-Terrab 
Physics, Maplesoft

@Mac Dude 

Indeed you spotted an issue: when Vectors is loaded and you set geometricdifferentiation = false and you perform derivatives that return unevaluated, the setting of geometricdifferentiation should not be displayed by the typesetting routines.

I fixed this now for Maple 18 and uploaded an update to the R&D Maplesoft Physics webpage.

For Maple17, however, there are no more updates of Physics, so here is a touch that will resolve this problem within a Maple 17 worksheet too: after loading Physics:-Vectors and setting geometricdifferentiation = false, enter:

> kernelopts(opaquemodules = false)
> Physics:-Vectors:-unevaluated_vdiff := () -> ‘Physics:-diff(args)’:

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

@Alejandro Jakubi @Carl Love

You know, things evolve nonlinearly, or constructively, Maple started with 4 functions Int, Sum, Limit and Product, and now everything can be inert prefixing with %, and yes, it is a programming annoyance to always have to take into account this double cause Int and %int. Carl's suggestion, or in the form of a macro or alias, resolves part of this issue satisfactorily, but not all: there is code that checks, say, for Int, and if you alias, macro or assign Int to %int, that has not effect within those procedures that will then fail, unless these macros are set directly in the kernel or loaded before the code. So addressing this requires a bit more of work. Now that inert functions are being discovered the pressure is bigger. At some point it will be in place, you will be able to use both Int and %int, but only be concerned with %int at the time of programming.

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

@Alejandro Jakubi 

Mainly: some people thought that inert functions were not relevant in general, say beyond Int, Sum and Limit. That delayed the introduction of inert functions for almost 4 years, and you see the tail of that: it took use other 14 years to have the display of inert functions in place. Other people thought it was relevant to check the arguments for basic correctness (e.g.: Limit should have its second argument as an equation), which makes some sense, because the whole idea is to represent the mathematical operation, just without performing it, and in this frame if the arguments are not correct neither is the representation of the operation. On the other hand, when performing calculations using computer algebra it is very useful to allow deviating a bit from that somehow rigid set of mind, to take advantage of syntax side-effects, or maybe the second argument to Limit will become one of type equation later, etc., and for these purposes it is very relevant to not check the arguments for correctness. The example posted by Mac in this thread is a blackboard case of that situation. I personally started thinking that the check of arguments was the way to go (1996, when Intat entered the library) and end up changing very soon to the second point of view, which is what you see implemented today all around for inert functions.

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

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