@tomleslie 

I have no idea why the link doesn't work for you, Tom ... perhaps try it with a different browser? I've see sometimes a browser cache compilcating things. Anyway the link works fine for me both in Safari and Google Chrome, on a Mac computer.

Regaring having fixed the problem: Tom, I design and write these programs, I like them working well, I'm perhaps the main user, most of my scientific production is based on them, independent of working for Maplesoft, and therefore I fix the bugs in these programs when they appear in the radar, ASAP. I don't see how could this add to the annoyance of any Maple user .. anyway.

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

@alfarunner 

Unfortunately I am short of time, but from the top of my head: have you tried the Setup option geometricdifferentiation ? Check it out, it is explained in ?Physics,Setup.

Likewise, the examples in the section on Electrodynamics of the ?Physics,Examples page show how to perform these derivatives without using the geometricdifferentiation option.

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

@trace 

You asked for an expansion removing higher order terms in g(r), a well defined thing. You didn't ask fo an expression smaller than something, which by the way is not a well defined thing. I only showed you what you asked, it seems easy, just use the series command, frontended to workaround the fact that the expansion variable is a function, and that is all.

As for size, did you give a look a (17) you are expanding? it has a denominator of degree 4 in g(r). Then, You will not just get something smaller, or what where you expecting in an expansion in such a case?

(17) is of the form

ee := f(x)*(1/(a*(x^4)+b*(x^3)+c*(x^2)+d));
                                 f(x)         
                  ee := ----------------------
                           4      3      2    
                        a x  + b x  + c x  + d
series(ee, x, 2);
                    f(0)   D(f)(0)      / 2\
                    ---- + ------- x + O\x /
                     d        d             

Anyway I'm sorry I cannot help you more in this thread.

Best

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

@trace 

In a previous comment of yours, here above, you asked "how can i eliminate non-linear terms like g(r)^2 from 17". That is what I showed replying you: frontend(series, [(17), g(r), 2]). Now you jumped to another branch. So not g(r). H(r) instead. I will give a look later today or in a couple of days - I'm rather busy in this moment.

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

@trace 

In your JJ.mw, you computed a series with respect to H(r), not g(r). Concretely, I read frontend(series, [(17), H(r), 2]), not frontend(series, [(17), g(r), 2]). If you compute the series w.r.t g(r) - this is what you asked - you do get a result. By the way, please read ?series: you can afterwards check the degree using 'degree', and also convert(..., polynom) if desired, to remove the 'series' computational structure and the O(g(r)^2) term.

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

@trace 

To Define k_[mu,nu] indicating its components, please do as you did for N[mu] and F[mu,nu] in Plugging in a metric ansatz, thread that you also started. If that does not resolve your problem, please let me see what you are doing to define k_[mu,nu] indicating its components and that does not work, thanks.

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

@trace 

To discard terms of degree greater than one in g(r) use series. That command however does not accept a second argument of type function (g(r)), so use it with frontend, as in 

> frontend(series, [(17), g(r), 2])

Regarding "how can i put k components" I do not understand what you mean by that - an example? Do you mean assigning values to the components of k? If so it suffices to define k (using Define) indicating its components, instead of just Define(k_[mu,nu], symmetric) as I did in the review of your worksheet, or otherwise leave that definition as it is and redefine k_ indicating its components just before (or even after) using series to discard terms O(g(r)^2).

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

@Rouben Rostamian 

As is clear from the previous replies, although I understand you think abs(x) in this context is bogus, I think it is not. However, taking as reference the previous comments, the solution with x instead of abs(x) is definitely simpler, and the introduction of complex components (abs, csgn signum) when simplifying solutions to linear equations is a pattern that can be checked at a low cost, identify the radicals that lead to these complex components through simplification, take advantage of integration contants to reabsorb constant factors, and in this way rewrite the solution in simpler form. Depending on the program, to do this kind of manipulation may be tricky, but not in this case, the symmetry routines in Maple are pretty modern code.

I implemented this change (you can install it by updating your Maple 2017.3 with the update for Physics, Differential Equations and Mathematical functions distributed at the Maplesoft R&D Physics webpage), and now we receive the one you were expecting, that I call the simpler solution:

Download solution_without_abs.mw

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

@Rouben Rostamian  

A constant doesn't need to be continuous; a piecewise constant is valid; you see however that the problem is at its discontinuity, the origin, exactly where signum(1, x) is undefined. All I am saying (have been saying) is that the solution returned for the symbolic problem without initial/boundary conditions is correct except at one point, that arbitrary constants can be piecwise constants (but for their value at that point) and that the problem of all this is in the simplifier when it changes the solution computed by the PDE symmetry routines introducing abs. That introduction is not OK but the consequence, for x::real, is only to make the solution not valid at the origin.

Anyway,  arguments went back and forth, I enjoyed the exchange, but need to return to other matters.

Best

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

@Rouben Rostamian  

Hold on: the problem posted has no initial conditions, leaving a lot of freedom in the choice of the arbitrary constants _C1 and _C2 to overcome almost any argumentation. On the other hand, the example you are presenting as argument has initial conditions. With (please!) no offense, I think you cannot compare one thing with the other one. More concretely, look at the solution, with the term under focus of the form _C2*erf(abs(x)) where x::real. You know erf(-x) = -erf(x); reabsorb now that sign within _C2 and you can even say that for x >= 0 you have _C2*erf(abs(x)) = _C2*erf(x) while for x < 0 you have _C3*erf(x), and there you are, watching at a solution arguably valid all around x::real.

The key observation here is that a problem without initial conditions has some extra freedom that a problem with initial conditions (provided it is well defined) has not.

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

@Rouben Rostamian  

I'm happy to see exploration to the sides, the PDEtools symmetry commands are really powerful, and have a ton of options. By the way, SimilaritySolutions, the one you used, an approach frequently presented in symmetry textooks, is a rather restricted and watered-down version of InvariantSolutions, in turn only presented in full in more advanced symmetry textbooks. 

Now on the sqrt(x): this is not really "a bug", if you pdetest(sol, pde) assuming x::real, you see the remainder has signum(1, x) as a factor, which is equal to 0 for all nonzero real x. So this solution returned could be seen as not appropriate when x = 0 only.

But more important: from where is this abs(x) coming? It is from simplify. The solution actually computed by SimilaritySolutions is 
sol_0 := u(x, t) = _C1+erf((1/2)/(t/x^2)^(1/2))*_C2, which tests OK right away, even with something as simple as normal(eval(pde, sol_0)). Try now simplify(sol_0) assuming x::real; and you see abs(x) in the output, which, when testing generates signum(1, x).

Best

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

@_Maxim_ 

I see now there are two assuming constructs in the same item 3. First of all: from the explanation in the previous reply, what works is assume; your comment can then only be applied to it (whether it tries to place assumptions on 0), and my take on this one is that assume(x(0)>0) should be a valid assumption, because in general nothing is known about x. Regarding why "the first construct does not interrupt with an error", it is because assuming notices that abs(x(0)) has no indets of type name, therefore shortcuts the computation without calling assume at all.

So one thing to think about: assume could handle assumptions on x(0), at least when x is not assigned; I will forward this comment to the person taking care of assume (I wrote assuming but am not involved in assume itself).

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

@illuminates 

Now it is clear. This is fixed for Maple 2017. The updates of the Physics package, including fixes and the new material being developed are distributed at the Maplesoft R&D Physics webpage. So in Maple 2017 + updates you get -6, not -24.

This Maplesoft R&D Physics webpage also includes updates for Maple 2016 that I recommend, containing fixes and Physics developments that entered Maple 2017, but the last update for Maple 2016 happened Apr/15. Only updates for the current release get posted every week. A workaround in Maple 2016 for this example you posted is to use SumOverRepeatedIndices, as you indicated.

@digerdiga 

The answers are on the help pages.

For the signature, see Physics:-Setup, search for the word signature on the page; in more recent versions of Maple you can just search for signature within the whole help system, and Physics:-Setup is one of the options that come close to the top. For D_ see ?D_, for Christoffel see ?Christoffel. To express covariant derivatives in terms of Christoffel symbols also see Christoffel.

I am not sure how familiar you are with using computer algebra ... Help pages are a very core part of it. There are so many commands that it is meaningless to try to remember everything. You just consult the help pages, always, and you rapidly remember things about those commands you use the most. Otherwise, without consulting the documentation computer algebra systems are of little use.

@digerdiga 

differentialoperators is a new feature of Maple 2017 (this is four releases after Maple 17), so it doesn't work in Maple 17. The ability to work with any of the four signatures mentioned in the first answer (above) was introduced in Maple 2015 or the next one, so that also doesn't work as such in the older Maple 17. Without this differentialoperators feature, you can compute with D_[mu] and A(X) but not as operands of a product: D_[mu] is a differentiation operator, to use it you need to apply it, as in D_[mu](A(X)). Of course the interesting thing is to have this working properly also when you use multiplication (with `*`, not `.`) instead of just application, but that requires you updating to the lastest Maple.

Regarding your question about Physics:-Simplify, recall that all these commands have a corresponding help page. The answer to your question is in that help page: Simplify is physics oriented, performs simplifications of noncommutative products taking into account algebra rules, as well as simplification of contracted indices taking Einstein's rule and tensor's symmetries into account, plus some other stuff. So it is complementary to the standard simplify.

In summary, some of the topics presented in today's IOP talk work in Maple 17 but several only work in newer or the latest release Maple 2017.3.