Just to note that despite the non-polynomial objects found in 'eqs', both kinds of exact solutions (independent or dependent on t) exist for this problem. Here is one solution and its verification for all variables independent of t: > simplify(eval(sys, {B = 1, a = 0, b = b, g = 1, k = RootOf(2*_Z^2+1), w = w})); {0 = 0} Here is one solution allowing for instance w to depend on t: > simplify(eval(sys, {B = -1/2, a = 1/2, b = b, g = -1/2, k = k, w = 1/3*(3*ln(t)+6*ln(2)+2*ln(-k^2/(-6*t-6*t^(-1/2*b+1)+6*b*t^(-1/2*b+1)+1)))/ln(t)})); {0 = 0} I noticed yet another one with b and w depending on t but its verification is not straightforward: {B = -1/2, a = 1/8/t^(1/2), b = 2*(-1+4*t^(1/2))*LambertW(-ln(t)*g*(8*t-t^(1/2)-16*t^(3/2))*(8*g*t^(1/ 2)+3-8*t^(1/2))*t^g/(192*t^2-144*t^(3/2)+36*t-3*t^(1/2)))*(8*g*t^(1/2) +3-8*t^(1/2))*t^(3/2)/(3*t+8*g*t^(3/2)-8*t^(3/2))/ln(t)/(t^(1/2)-4*t), g = g, k = k, w = 1/3*(8*t^(1/2)*ln((-1+4*t^(1/2))*(8*t-t^(1/2)-16*t^(3/2))*(8*g*t^(1/2) +3-8*t^(1/2))*k^2*t^(g+2)*ln(t)*g/(((768+3072*g^2-6656*g)*t^(11/2+g)+( -480*g+64*g^2+288)*t^(9/2+g)+3*t^(g+7/2)-768*t^(11/2)-3*t^(7/2)-288*t^ (9/2)+(-768-768*g^2+2688*g)*t^(5+g)+(32*g-48)*t^(4+g)+(-4096*g^2+6144* g)*t^(6+g)+768*t^5+48*t^4)*LambertW(-ln(t)*g*(8*t-t^(1/2)-16*t^(3/2))* (8*g*t^(1/2)+3-8*t^(1/2))*t^g/(192*t^2-144*t^(3/2)+36*t-3*t^(1/2)))+8* ((-64*g+64)*t^(11/2+g)+(-12*g+30)*t^(9/2+g)+3/8*t^(g+7/2)+(-72+48*g)*t ^(5+g)+(-11/2+g)*t^(4+g))*ln(t)*g))-8*LambertW(-ln(t)*g*(8*t-t^(1/2)-1 6*t^(3/2))*(8*g*t^(1/2)+3-8*t^(1/2))*t^g/(192*t^2-144*t^(3/2)+36*t-3*t ^(1/2)))*t^(1/2)+(32*ln(t)+48*ln(2)-8*ln(3))*t^(1/2)-3*ln(t))/ln(t)}

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi Without the actual input that resuls in 10 min evaluation it is not possible to say what the problem could be. How about you post the worksheet that contains all the input lines?

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi Without the actual input that resuls in 10 min evaluation it is not possible to say what the problem could be. How about you post the worksheet that contains all the input lines?

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi Junji Regarding 1.: in > phi[a,b](X)*phi[alpha,d](X)*g_[e,a]*LeviCivita[e,f,alpha,d]: you have phi[alpha, d]. According to what you have set (see your post), alpha is a spacetime index but not d. In maple the notation [a,b] is used to index objects, not necessarily to represent spacetime tensors, so both indexations (spacetime and whatever else) can be represented. As we do it by hand, the idea is then that you set a convention to represent spacetime indexes (in your mind, then using Physics:-Setup in the worksheet), and then stick to your convention. But you are using two different types of indices. Trying to understand what is what you had in mind when entering phi[alpha, d] (correct me if I am wrong please) I guess that you intended to use, simultaneously, spacetime and space-only tensor indexes, as we sometimes do with paper and pencil. Unfortunately this functionality (two different kind of tensor indexes handled at the same time) is still not in place. It is in the to-do list of improvements with high priority though. Until that is in place, the error message displayed when you Simplify(%); Error, (in Check) found phi with 1 tensor indices, [alpha], contradicting a previous definition with 2 such indices. You can use Define with the 'clear' or 'redo' options to discard the previous definition. Is correct and according to the documentation. Regarding 2: the issue is a bit more subtle, but easy to understand. In computer algebra systems, some operations are automatically simplified as a way of normalizing things, almost always to permit basic zero recognition. This is not related to the Physics package. For example: if you enter sin(-x) it returns -sin(x). Although for sin(-x) the output is "session independent", in some other cases the output is "session dependent". Therefore, if in a worksheet you have a subs operation acting on session dependent output, if as you say you re-execute the session, that subs line may or not work (Murphy's law applies here ..) because the target of the subs operation may have changed, as you say. Of course this is annoying. But progress is happening: in Maple 12 (elements in a set are returned almost always in the same order) and more in Maple 13 (elements in a list are sorted almost always in the same order). Independent of that, the library code for Physics could be tweaked further (it is already) to try to keep the indexes unchaged as much as possible (provided that there is no relevant impact in performance - note that product operations are verified for consistency on background on the fly). I'll add this example you posted to the todo list. Regarding 3. In handwriting computations it is unclear to me what would be the meaning of A[mu](X)/(d_[mu](A[mu](X),[X])); where I see a dummy repeated two times (all in all the index appears three times). Perhaps you are conventioning (in your mind) that "repeated indexes in the numerator" are considered different than "any indexes in the denominator" (and the same exchanging numerator by denominator)? Until the convention you have in mind is clarified and eventually implemented, the error message is correct and according to the documentation: A[mu](X)/(d_[mu](A[mu](X),[X])); Simplify(%); Error, (in Check) found repeated indices of the denominator in the numerator Regarding 4. This is a weakness bug in the Simplify code, to be fixed.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Edgardo S. Cheb-Terrab
Physics, Maplesoft

You are correct, simplify/Heun is not there. There is a general approach in simplify for special functions though; I'm adding Heun functions there now.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

You are correct, simplify/Heun is not there. There is a general approach in simplify for special functions though; I'm adding Heun functions there now.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

This is an implementation oversight - call it bug if you prefer - Heun functions were introduced in the system after the conversion network got developed. The implementation details are tricky but in short: the setup of the network includes knowledge regarding "from which functions" can a conversion exists. For Bessel functions an update telling, that from HeunB and HeunC that conversion is possible, is missing in Maple12 and before.

To make it more concrete: if that information were in place, the network would have found that through pFq it is possible to convert to BesselI; try this convert(HeunB(alpha,0,0,0,z), compose, hypergeom, BesselI); and you see it working. The problem is fixed in the version of Maple under development

Edgardo S. Cheb-Terrab
Physics, Maplesoft

This is an implementation oversight - call it bug if you prefer - Heun functions were introduced in the system after the conversion network got developed. The implementation details are tricky but in short: the setup of the network includes knowledge regarding "from which functions" can a conversion exists. For Bessel functions an update telling, that from HeunB and HeunC that conversion is possible, is missing in Maple12 and before.

To make it more concrete: if that information were in place, the network would have found that through pFq it is possible to convert to BesselI; try this convert(HeunB(alpha,0,0,0,z), compose, hypergeom, BesselI); and you see it working. The problem is fixed in the version of Maple under development

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Conversions to most of these functions are available; it suffices to check whether convert/foo is or not assigned, where foo is any function's name. As you know Maple frequently incorporates new stuff in different areas; it could be different but in practice  the help system is always catching up a bit.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Conversions to most of these functions are available; it suffices to check whether convert/foo is or not assigned, where foo is any function's name. As you know Maple frequently incorporates new stuff in different areas; it could be different but in practice  the help system is always catching up a bit.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi,
I do not have access to the article you mention, but read your summary, the one you posted in your website as http://patrick.toche.free.fr/research/papers/abel2.pdf

Maple has what I believe are the most advanced algorithms for Abel ODE classes of equations. By most advanced I mean both with respect to other computer algebra systems and as found in the literature. By classes I mean not just one Abel ODE but the family generated from it by changing variables using x-> F(x), y(x) -> ((P+Q*y)/(R+S*y))(x);

If compared with a single ODE, the family involves five additional functions and the algorithms can solve the problem for arbitrary values of them. In practice, when these five functions involve mathematical functions, the algorithm be computationally  too expensive and the gcd and zero recognitions computations with math functions are prone to fail.

Bearing that in mind, Abel equation research splits into two different problems:

1) to find an Abel equation which does not belong to a known solvable class - let's call this ODE "a new seed"

2) to develop an algorithmic way to solve the whole Abel class defined around this seed (ie: to determine the values of the functions F, P, Q, R, S so that a given ODE is reduced to the "new seed"

If you have 1), you can claim that have discovered a new solvable seed. If in addition you have 2), you can fairly claim that a new Abel class is now solvable (in both cases you cannot claim that "Abel ODEs were solved").

Now regarding the ODE example you post,in your pdf, y' y - y = f(x), you do not show anything for 2) and also do not show anything for 1). Regarding 1), it is necessary, first of all, to show a verifiable solution (you have not) - that is a solution in explicit or explicit form that either cancels the equation or that can be used to reconstruct the equation using different approaches; then you need to show that this ODE does not belong to one of the already known solvable classes AIL, AIR, or to one of the solvable AIA subclasses, all of them defined in "Cheb-Terrab, E.S., and Roche, A.D. "An Abel ordinary differential equation class generalizing known integrable classes." European Journal of Applied Mathematics. Vol. 14. (2003): 217-229.".  Years have passed since that paper, that actually report results presented in FOCM in the year 2000, and I have not yet found a "new" seed that does not belong to this class, and algorithm (ie: item 2) above) regarding all these solvable classes already exists in Maple.

Note that your ODE is already AIL or AIR for various values of f(x), for instance f(x) = x, 1/x., 1/x^2 ... (not for x^2), .... So here is the simplification I propose you: can you show how you derive a verifiable solution for f(x) = x^2, that is for y' y - y = x^2, using the method you are presenting? if so we have a good starting point regarding 1).

Edgardo S. Cheb-Terrab
Physics, Maplesoft

I recently replied about this topic in a different thread, see http://www.mapleprimes.com/forum/convertrationalvsidentify#comment-17582

Summarizing: dsolve's option "convert_to_exact = ..." now accepts (in the development version) the keyword `identify` in the rhs, and we are considering moving the default used by dsolve in the presence of floats from using convert/rational/exact to using convert/rational.

Edgardo Cheb-Terrab
Physics, Maplesoft