Hi Age

The issue you reported, that interruption when setting the algebra for Dirac matrices when using actual matrices instead of tensor notation, is fixed and the fix uploaded to the R&D Maplesoft Physics page, from where it can be downloaded to update the Physics library.

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

Hi NOh

You can define the operator the way you prefer. For example:

Download OperatorDotKet.mw

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

Hi

Note you could use tensor notation, equivalent to what you have done but more compact, as in:

> Setup(AntiCommutator(Dgamma[mu], Dgamma[nu]) = 2*g_[mu, nu])

And it works as expected.

Having said that, there are two issues to be addressed, one is a weakness in the simplification of products of Dirac matrices, for example: Simplify(Dgamma[nu] Dgamma[alpha] Dgamma[alpha]) works but if Dgamma[nu] is in between the two contracted Dgamma[alpha] the algorithm quits prematurily and the simplification is not performed. The other issue is the one you mention, there is a typo in the mechanism to detect inconsistencies, it shouldn't interrupt as you show. I will be addressing these two things probably by the end of the month.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi

Given a PDE, or a system of them, there is already a command to compute the determining equations: PDEtools:-DeterminingPDE, and also to solve the system of determining equations returned by that command: pdsolve. Or do everything in one step, including using the output to compute invariant solutions: PDEtools:-InvariantSolutions.

Of course one can also do all the steps by hands, but in the case of the symmetry approach it would be rather cumbersome; it is simpler to use the existing code for that.

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

Hi
You can use Physics; understanding you are using Maple 18, please update your version of the Physics library from the Maplesoft R&D Physics page. You then have

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

Hi nm,

There is no solution in this moment for the combo "alias & diff = dot & extended typesetting". On the other hand, if you are OK with a prime ' instead of the dot to indicate differentiation, you can use PDEtools:-declare and it works precisely as you are expecting. So, after alias(x=x(t)), input

> PDEtools:-declare(prime=t, x);

Then diff(x, t) will be displayed as x', and copy & paste work fine, etc.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Download CovariantDerivative.mw

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

Hi

I just ran the test.mw worksheet you posted, and am unable to reproduce your result, instead  I receive no solution. In case this is about installing the latest updates for Maple DE libraries, they are available for download at the Maplesoft R&D webpage for Differential Equations and Mathematical Functions.

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

Download MaplePrimes_odetest.mw

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

Hi

You pose several questions.

First of all, when Maple returns ODESolStruc it means it succeeded in reducing the ODE order, but not in solving the reduced ODE. So, unlike the DESol case you compare with, the ODESolStruc contains information about the ODE solution, a reduction of order, not just the ODE passed to dsolve. The reduce ODE is of course a simpler problem, and the tools to construct a full solution to the original problem in case you find a solution to the reduced ODE are there: DEtools[buildsol]. All this is explained in ?ODESolStruc.

Second: the output you got from odetest can be seen as an indication that something is wrong, but not necessarily with the solution - it could also be with the testing approach, any of the intermediate simplifications, etc. Computer Algebra systems are complex systems with all of their parts interdependent. In this example you posted, the reduction of order computed by dsolve is actually correct, but an intermediate call to solve within the algorithm to test ODESolStruc answers returns NULL, and from there odetest is unable to confirm the solution. Note that in the help page for odetest it tells that the command either confirms the solution is correct by returning 0, or otherwise it only means it didn't succeed in verifying the solution - not necessarily that the solution is incorrect, even when, most of the time, one thing implies the other one.

To feel the issue, try this: a) compute symmetry infinitesimals, b) use them to reduce the ODE order, and you will see basically the same solution returned by dsolve, just written slightly different (one simplification less); and this solution verifies OK via odetest. To accomplish this, enter

X := DEtools[symgen](ode);  # pair of Lie symmetry infinitesimals

sol := DEtools[reduce_order](ode, X);  # reduction of order almost identical to the one returned by dsolve

odetest(sol, ode);

                                                 0

All what happened is that sol above has one simplification less, and with that all the intermediate steps succeed - included that call to solve mentioned - and hence a full verification by odetest proceeds normally. To verify that sol above is actually the same as the solution returned by dsolve enter

simplify(normal(sol, expanded) - normal(sol_by_dsolve, expanded))

                                                 0

So: the output you got from odetest as "not zero", that you posted, reveals a weakness in the testing code only. I already fixed that weakness, and uploaded the improvement to the usual place, the Maplesoft R&D webpage for Differential Equations and Mathematical Functions. If you update your library with the download available in that page, odetest returns 0 for the solution returned by dsolve as well, instead of the "not zero" expression you posted.

Third: I see you would like to have a different typesetting for ODESolStruc. You can see 'ODESolStruc' using lprint - no need to convert to a string - I also prefer the current typesetting of it, but in any case you can always remove the current one by entering

unassign(`print/ODESolStruc`)

And that will suffice. If in addition you want to program the typesetting of ODESolStruc in any other way, you can create the corresponding routine and assign it to `print/ODESolStruc`. All this is explained in ?print.

Summarizing: ODESolStruc does mean the equation got solved to some point, not all the way; ODESolStruc conveys more information than DESol; the solution returned by dsolve for your example, presented as a reduction of order, is correct; to have odetest verifying it you'd need to update your library as said above; you can remove or redo the typesetting of ODESolStruc in any desired way.

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

Hi nm

Good catch. It's fixed now, the fix is available as usual in the Maplesoft R&D webpage for Differential Equations and Mathematical Functions. The zip available for download that includes the fix also includes instructions to install it.

After you install the fix:

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

Hi

Indeed, when dsolve returns DEsol, or Mathematica's DSolve returns DifferentialRoot, you can consider the system actually did not solve the ODE: the returned structure does not really contain more information than the given ODE. For linear equations, however, Maple's dsolve always returns DESol when no solutions were found, because, as it is the case of RootOf representations of solutions for non-differential solutions, in the case of linear ODEs Maple is able to do some manipulations with the DESol representation of the solution, as for instance computing series.

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

Hi

I updated the Maplesoft R&D Physics webpage with a new version of Physics, the issue is resolved. At the end it is is also a link to your worksheet reviewed, with your computation running with the fix in place.

Details.

As you noticed there was a weakness that I'd briefely describe as: SubstituteTensor(T[m,n] A[m] = B[n], T[i,j] A[j]) was not substituting because the position of the free index 'n' in  T[m,n] A[m] (this is left-hand side of the substitution equation), is not the same as the position of the free index 'i' in the target expression T[i,j] A[j].

The issue is that, as you said, T is symmetric (BTW there are two different ways of indicating symmetry, that work differently; more about this in the last paragraph), and so T[n, m] = T[m, n] and one expects that the substitution will be performed - i.e. the order of the indices in T should not be an issue.

The implementation however is not as straightforward in that we are talking of something like subs(A*B = C, A*D*F*B), a sort of algsubs operation (i.e. A*B is not an operand of A*D*F*B), and in addition there are the free and repeated tensor indices that work like different kinds of dummies, plus the symmetry properties under permutation of the indices in the substitution equation and in the target expression.

Anyway it is now working. And yes, the key to crack the problem is in the use of this new routine Physics:-Library:-RepositionRepeatedIndicesAsIn, that I still need to document.

A comment on how to indicate that at tensor is symmetric; there are three ways:

1. Define(eta, symmetric)
2. Define(eta = ... tensorial expression or Matrix, symmetric)
3. Define(eta = ... tensorial expression or Matrix)

The 1st form permits you to compute with eta[i, j] <> eta[j, i] and you can apply the symmetry afterwards, when you prefer, using Simplify, i.e Simplify(eta[i, j] - eta[j, i]) returns 0.

The 2nd form automatically normalizes eta[j, i] -> eta[i, j], it is more convenient most of the time, not all the times. But if the right-hand side of the equation passed to Define is (anti)symmetric under permutation of the indices, one would expect that it is not necessary to additionally specify (anti)'symmetric' (as you did in your worksheet).

The 3rd form does not include the word 'symmetric' in the definition, and also automatically assumes eta is symmetric if the code can prove that the tensorial expression on the right-hand side is actually symmetric, and if so this definition will work as 2. However, due to a weakness in the code this automatic determiination of symmetries was not working when the right-hand side was an (anti)symmetric matrix (2 indices) or (anti)symmetric Array (as many indices as you want).

With the changes introduced today: the 3rd form assumes (anti)symmetric automatically if the corresponding matrix or array in the right-hand-side is (anti)symmetric, so this lateral issue is fixed and you do not need to specify (anti)'symmetric' additionally (you still can do that, to override if something is not working as you expect). Substitute tensor works fine also regardless of the position of the free indices provided that the substitution equation can be mapped into the target equation using symmetries (by using this new Reposition routine), and so it works fine, in the same way, whether you entered your definition using the form 1., 2. or 3.

Maple_Question_7.7.14_(reviewed).mw

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

Hi

Thanks for pointing at this one, it is fixed, the fix is available for download at Maplesoft's R&D Physics webpage, and this is your worksheet running your computation with the fix in place: Maple_Question_7.3.14_(reviewed).mw

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

Hi

When you say that an ODE solution involves an 'arbitrary constant' - say _C1 - the only requirement on _C1 is that  d/dx _C1 = 0. So, if y(x, _C1) is a solution, y(x, _C2) where _C2 = -_C1, or for the case _C2 = F(_C1) and F is an arbitrary function (i.e. can be any function), are all different ways of expressing the same solution, because both _C1 and _C2 satisfy d/dx _C = 0. For details see ?dsolve,details, the section on Arbitrary Constants.

Having in mind what the meaning of an arbitrary constant is, going to your question, y(x)=a+_C1e^-(1/bc) and y(x)=a-_C1e^-(1/bc) are just two different ways of expressing the same solution (just replace the arbitrary constant '_C1' by the arbitrary constant _C2 = -_C1), as opposed to one being right and the other one being wrong.

Edgardo S. Cheb-Terrab
Physics, Maplesoft