Reviewing this answer, sometimes the metric, or any other tensor, is defined through a tensorial equation that involves other tensors, that in turn where defined in terms of other tensorial equations and so on (an example of this is found in General Relativity using Computer Algebra), and using indets(T[], symbol) to resolve the dependency of the tensor T may be not efficient since T[] computes all of the components of T. For instance this can be visibly time consuming with an arbitrary spacetime metric (set using Setup(metric = arbitrary)). In these cases a less expensive way of unveiling the dependency of T, is to use the Physics:-Library:-GetTensorDependency command as in Library:-GetTensorDependency(T) (note T, not T[]). There is a section explaining GetTensorDependency in the help page for the Physics/Library) .

Edgardo S. Cheb-Terrab 
Physics, Maplesoft

@escorpsy 

Unfortunately I cannot read the image you attached. But even if I were able I would need to retype everything on a worksheet to formulate your problem. There is no need for that: you already typed it. So, please, attach a Maple worksheet to your reply or post where you include text and formulas showing your question better. Recalling, to attach a Maple worksheet: save it first in your computer, then click the green arrow that you see in the toolbar when you produce a reply here in Mapleprimes (I see one now while I am writing this reply to you), then follow instructions on the screen. Then I will be able to either show you how you could do what you want to do using Physics or, depending on what it is, we can also implement it right away and put the new functionality available for you and everyone else in the Maplesoft R&D Physics page - note that the Physics package gets updated every week based on user's feedback.

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

@escorpsy 

Yes, and again you can use `.`, or `*` followed by Simplify or by SumOverRepeatedIndices, and you do not need to worry about which repeated indices are covariant and which other ones are contravariant: just enter all of them as covariant and the system will reformat each pair of repeated indices as "one covariant the other contravariant". In particular, for Ricci you also have the keyword 'scalar', where Ricci[scalar] = Ricci[alpha, ~alpha]  = the trace of the Ricci tensor, this is explained in the help page for Ricci.

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

@escorpsy 

In Maple, as in other computer algebra systems, and more than in any other kind of software I know, it is key to consult the help pages. I find myself doing that every day I use Maple. For an overview of the Physics package see the Physics help page.

Related to your question, g_ is the metric, Ricci is the Ricci tensor, d_[mu] is the d/dx^mu operator and D_[mu] is the covariant derivative operator. To set the metric you can use Setup, or, if the metric is already in the database of metrics, you can also set it directly with the metric command g_ itself, that you can use as well to search the database. Besides the commands's help pages there is also a page with the conventions used in the Physics package and another one with Physics Examples.

More specifically to your question, a Minkowski metric is automatically loaded when you load Physics, you do not need to set it. You can query about "who is the metric?" at any moment entering g_[] at the Maple prompt.

Then to have a coordinate system using x,y,z,t, as you say, enter: Coordinates(X=cartesian), or Setup(coordinates = cartesian); you can use cylindrical or spherical as well, and also indicate the coordinates yourself as in Coordinates(X = [x,y,z,t]) or in any other ordering. You compute covariant derivatives as everything else in Maple. For example, if you define A as a tensor (see the help page for Define), then: D_[mu](A[nu](X)) is the covariant derivative of A[nu](X). You can represent this covariant derivative in terms of d_ and Christoffel symbols using convert(D_[mu](A[nu](X)), d_).

You compute with tensors using symbolic indices instead of components, and simplify tensorial expressions with regards to their repeated indices and symmetry properties of the tensors involved using the simplifier of the Physics package, Simplify (not simplify). To simplify only a subexpression use `.` instead of `*` in the corresponding product. When computing with general relativity tensors, you can re-express tensors in expressions in terms of other tensors using any of convert/d_, convert/g_, convert/Christoffel and convert/Ricci. To substitute tensors in tensorial expressions use Library:-SubstituteTensor.

You can always also compute with components of tensors by indexing the tensors with numbers from 0 to D, or from 1 to D+1, where D is the space dimension and D+1 is the spacetime dimension, and 0 works the same as D+1; for example Ricci[0,1] = Ricci[4,1]. You can define tensors themselves, or in terms of tensorial expressions, with no restrictions, and you can change the dimension of spacetime using Setup(dimension = N) where N is a positive number. To perform the sum over repeated indices use SumOverRepeatedIndices. To get, in one go, all the tensorial components of a tensor expression using Library:-TensorComponents.

Finally, in general: repeated indices can be entered both as covariant and they are automatically reformatted by the system as one covariant one contravariant. This saves a significant amount of time as well as input mistakes - for details about this see the page for the conventions used in the Physics package.

Anyway, any question is welcome, Mapleprimes is a wonderful resource with many Maple-skilled users.

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

@escorpsy 

I posted the worksheet with the computation shown, there is a download link at the end of the answer. Have you downloaded and executed it? Also, the computation shown was performed using Maple 18 and the latest update for Physics available on the Maplesoft R&D Physics webpage. What version of Maple are you using? To help you further it would as well be useful if you post the worksheet with the input/output and corresponding error interruption that you are referring to. To post a worksheet, you can click the green arrow you see when you produce a post or answer, and then follow the instructions.

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

@shingy 

Unfortunately this problem with the formulas that suddenly appear or dissapiear keeps biting. The post also has a link at the end for you to download the worksheet, but somehow that link also stopped working. To upload everything again and again will not solve the problem. I will send you the worksheet by email.

Edgardo

@acer 

Indeed, radnormal handles this one perfectly. I forgot completely about this command. Perhaps the simplify code for radicals could take advantage of this too.

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

@Markiyan Hirnyk 

Expressing sum's output in elementary form is one thing. I understand that is the topic of this thread. It can be accomplished in more than one way, and one that is direct is to enter conver(..., elementary).

Being able to simplify expressions with radicals is another thing. I understand not the main topic of this thread.

It is apparent from your reply that in your opinion the conversion to elementary form would be a good thing if the simplifier were able to simplify further the result of the conversion. In my view these are just two different things.

So switching to this other topic, the simplification of radicals, I think it can be improved, here is a sequence of steps that takes the output of convert/elementary into the simplified form. The starting point is the output by sum

> sum(sum(binomial(n-1, i)*x^(n-i-alpha)*(-a*n)^i*c[n]*GAMMA(n-i+1)/GAMMA(n-i-alpha+1), i = 0 .. n-1), n = ceil(alpha) .. M)

Then you convert to elementary (I understand this is basically what Usman asked):

> convert(%, elementary);

The following sequence of steps simplifies this output (what you mentioned as being relevant now):

> convert(%, RootOf); # the simplification of RootOf is more powerful
> simplify(%);           
> convert(%, radical); # bring back to the more usual form with radicals
> simplify(%);

(PS after posting: the above is the same image shown by Carl, but somehow the Mapleprimes website presents a broken link for it, this is the lprint(%) output: (2/3)*(4*x*c[2]+3*c[1]-6*c[2])*x^(1/2)/Pi^(1/2) ).

From this I would not conclude that the conversion to elementary is inconvenient but that the simplification of radicals can be improved.

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

@shingy 

Hi Shingy. I guess you are more-or-less new to this thing; in computer algebra, for someone to help you with some input/output problem, you need to show the input because, we know, the output depends on the input. For example: I showed what is the input that produces the output you asked, that is: to obtain the determining system for the symmetries of your PDE equ you enter PDEtools:-DeterminingPDE(equ, integrabilityconditions = false). 

Could you please then show the input you are entering that produces no output? Indicating the version of Maple you are using (current is Maple 18) is also helpful.

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

@shingy 
You seem to have missed my answer? The liesymm package is definitely not the right tool nowadays - use the PDEtools commands for symmetries. For your example, use

> PDEtools:-DeterminingPDE(equ, integrabilityconditions = false);

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

@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