@Area51 

Yes, you can define (add) tensors using tensorial expressions as definitions: the left-hand side (lhs) is the tensor being defined, the right-hand side (rhs) is the tensorial expression. And yes, the rhs can also have contracted indices - the only requirement is that the free indices of the lhs and rhs are the same, naturally. For all that, see the help page for ?Physics:-Define. I also see you used Box; there is Physics:-dAlembertian, the galilean one, but you can define one in curved spaces as explained in the previous sentence.

If you don't know how to formulate your problem on a Maple worksheet using Physics, try to approximate as much as possible the input lines representing your problem, and please post the resulting worksheet and questions here again.

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

You need to post the problem, explicitly.

@a_simsim 

Andras

I mentioned I was going to write again here regarding your suggestion concerning Den Iseger's algorithm. We gave a look at the paper, with Katherina, and the three algorithms implemented work pretty well with all the examples, Table 1: Analytical test functions, and Table 4: Continuous Nonanalytical test functions, in both cases getting better accuracy; but do not handle those of Table 2: Two Discontinuous test functions. In brief, for these two discontinuous examples it is not possible to determine whether the accuracy is or not increasing, and then the numerical evaluation routine gives up. We are short of time but will see if we can still give Iseger's algorithm a try. If so, I will post again here. Thanks again for the reference.

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

@Mariusz Iwaniuk 

Thanks for your feedback. I looked at your seven examples. Your example 5 is taken from Table 2 of the paper by Iseger mentioned by Andras, a discontinuous example. Then examples 1, 2, 4 and 7 (with regards to tackling them using the methods implemented) are basically of the same type as example 5. You see that by looking at the form of the Laplace transform being inverted, or at the exact form of the inverse Laplace transform. These examples - the one from Iseger's paper is the best representative, I think -  result uncomputable (using the implemented algorithms) because for discontinuous inverse Laplace transforms it is sometimes not possible to determine whether the accuracy is or not increasing. We were yesterday discussing with Katherina the possibility of implementing one more algorithm for this case (basically, what Andras suggested).

Then your example 6 is a piecewise branching at t < Pi, and you ask the numerical evaluation at t = Pi. Such a case is always difficult, for any numerical algorithm. Your example 3 is however, different: the expression being (Laplace) numerically inverted involves the Zeta function, whose numerical evaluation is itself a difficult problem, and the expected inverse Laplace transform is equal to harmonic(floor(exp(t)), 2). I am not a numerical analyst (more like a theoretical physicist), but I tend to think that numerical methods for problems like your 3 and 6, where you have discrete numerical functions, or where you ask for the numerical evaluation at where the discrete function branches, are not the standard problem, and in any case, not the problems I am targetting in a first implementation round.

Summarizing, if we have time, we will try to implement Iseger's algorithm as suggested by Andras and with that handle the two discontinuous examples of Table 2 of Iseger's paper (that would handle your examples 1, 2, 4, 5 and 7), Your examples 6 and 3 may or not be automatically solved at that point; otherwise they will require computing the exact transform first.

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

@a_simsim 

Hi Andras,
Thanks for the reference. Below is a worksheet with the testing example - comparing numerical inversion algorithms - of the paper you just mentioned, But the values of the numerical parameters they used are not shown. Do you have them?

Download Example_from_Laplace_transform_numerical_inversion.mw

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

@a_simsim 

At least for this release, I don't intend to work further in a numerical inversion of Laplace transforms. The three algorithms implemented are good enough. It is also unclear that Iseger's algorithm is better than the ones of section 2 of this post, and there is still work to do regarding inversion algorithms for other transforms.

That said, I looked now at the paper by Den Iseger you mentioned (it is from 2006, same year of the one we used in our implementation, see the post above) and noticed it contains a Table 1 with results for the mean absolute error for a set of 8 test functions. As soon as I find the time, we will run the same examples using the implementation we developed using Euler, Talbot and Gaver-Stehfest, then compare with the results shown in the paper and comment here again.

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

@Mariusz Iwaniuk 

That is not what the post says. You can use evalf to numerically evaluate %invlaplace (as well as any other inert mathematical function)- that is what the post says. You can use MathematicalFunctions:-Evalf to select one numerical method among several ones implemented, for the mathematical functions that have this feature implemented - certainly the case of %invlaplace as the post says. Giving a look at ?MathematicalFunctions:-Evalf you see it is also the case of the four AppellF functions and the ten Heun and HeunPrime functions.

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

@nm 

Inert stuff: everything preceded by % is an inert representation of the object not preceded by %, and can be executed using the value command. It is a fantastic Maple feature. The diff, series, evalf, simplify and several other commands understand inert representation and can compute with them taking into account the mathematical properties of these objects even when they are unevaluated (inert).

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

@nm 

Download more_general_solution_in_v.433_and_higher.mw

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

@J F Ogilvie 

As I already said, the Maple Heun functions include numerical evaluation routines for them, actually sophisticated ones. That these routines can be improved, as everything else, does not change that fact. I also know that you are well aware of the existence of those numerical evaluation routines - you actually reported a couple of problems with them. Writing here in "fake-news" style saying things you know that are not true does not help your point. Anyway I am out of this conversation.

@Jayaprakash J 

Open Maple, and give a look at the help page. To open the help page, input ?PDEtools,dchange.

@Ribeyre 

Regarding an update for Maple 2018, you already have the last one. The "Physics Updates" is an interesting project, useful for everybody, but it is a significant amount of extra work, we cannot afford that for more than the current version of Maple.
 

Download correct_results.mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations andMathematicalFunctions, Maplesoft

@nm 

Both dsolve and odetest are large software projects, not reduced to "do one thing", and if this is a generic conversation don't expect all the details. Generally speaking things are as said, and trust me: I wrote both dsolve and odetest. If you want to know about the internals the two routines you may want to trace are `odetest/implicit` (returns FAIL for your example, because you removed _C1) and `odetest/explicit`. Also, in this same example, even if you don't remove _C1 from the input to odetest, `odetest/implicit` fails in finding 0,

So, what if one approach fails? Naturally, try other things. There are exactly 1800 lines of code distributed into 20 subroutines below odetest, implementing different catch-up strategies accumulated along the years, taking into account feedback from Maple users. In some cases the catch-up approaches work, in other cases they don't. In this your new (third example) the catch-up works.

Summaryzing again: if you want to test with odetest, don't change the conventions of this code and let it do its job. If you change the conventions, don't expect it to do its job properly, even when, depending on the example, it may still succeed.

Anyway, I can't continue in this thread, need to move to other pending things.

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

@nm 

There is nothing like random behavior with software. If the solution is explicit, like the one you show now in your 'reply', then there is no need to isolate the integration constant, and so you can change _C1 by whatever (not depending on x). The behaviour that called your attention (that you cannot change _C1 by C[1] and expect odetest to handle the problem) happens only with implicit solutions, for the reasons explained (in those cases the testing approach starts by isolating the integration constant, etc.).  

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

@nm 

As mentioned in a previous thread with you, there is a distinction between essential and non-essential singular solutions. dsolve's default is to return only essential singular solutions, i.e. those that  cannot be obtained from the general solution by specializing (possibly piecewise) integration constants.  On the other hand, casesplit's default is to return all singular solutions unless you explicitly indicate  singsol = essential . When you solve(ode, y(x)) you are splitting (kinda manually) the original problem into two problems not having essential singular solutions.

I realize as well that you are not familiar with essential singular solutions or that distinction - in the previous thread I mentioned you could give a look a the help pages ?DifferentialAlgebra,RosenfeldGroebner, or the old ?diffalg where this distinction between essential and non-essential singular solutions - not mentioned in your posts in this thread - is explained and is at the root of the difference in behaviors you are pointing at.

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