@Andriy 

The summation variable cannot be assigned and this is not related to the Physics package but to how Maple works. For example, in a fresh session, try 

> G := sum(g(i), i = 1 .. f);

> i := 7;

> G; 

Error, (in sum) summation variable previously assigned, second argument evaluates to 7 = 1 .. f 

And there is no way around. Note that this is true for sum, int, limit, series, etc.

Independent of that, in your original post you also asked about a simplification N^k = N, where k is a positive integer, N = ap . am is the occupation number operator and am and ap are respectively annihilation and creation operators of fermionic particles. That simplification was missing. It is implemented now and available in the update of the Physics package just posted (today Aug/5) in the Maple Physics: Research & Development updates page. So with the updated library you have

@itsme 

You are right - I made a mistake in the input. It is corrected now in the mw just updated.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Andriy 
This one got fixed June 19, that is after 17.01. The fix should appear in the next (dot or full) release.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Mac Dude 

4-vectors are tensors with 1 index. As with tensors in general, within the Physics package, you define them using the Define command (also Setup(tensors = {...}) works). So the place to look for this is ?Physics[Define].

Independent of that, a "SpaceTimeVector related to a coordinate system" is automatically set each time you define a coordinate system using the Coordinates command. So the details for this are found in ?Physics[Coordinates] and ?Physics[SpaceTimeVector]. 

You can see these things at work in the section for "Tensors in Special and General Relativity" of the ?Physics[examples] page. It is a short section that starts with spacetime 4-vectors and the basic manipulations in special relativity, followed by how you set a curved spacetime and work with the same 4-vectors and the general relativity tensors related to having non-zero Christoffel symbols and covariant derivatives. 

Some more for 4-vectors in flat and curved spacetimes is found in ?Physics[Geodesics].

If all this doesn't answer your question or the existing functionality is not sufficient for your purposes, if you could please tell what computations you have in mind we can help you in filling the gaps.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Indeed the bug was in `simplify/sqrt/fraction`. It is fixed now in the version under development. The fix should appear in the next (dot or full) release. 

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Indeed the bug was in `simplify/sqrt/fraction`. It is fixed now in the version under development. The fix should appear in the next (dot or full) release. 

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Maybe you are using the old GUI (so called 'classic' maple interface)? If you could attach a worksheet where you illustrate the problem you are having that could help. Meantime this is what I see in the standard GUI:

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Download KretschmannScalar.mw

Maybe you are using the old GUI (so called 'classic' maple interface)? If you could attach a worksheet where you illustrate the problem you are having that could help. Meantime this is what I see in the standard GUI:

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Download KretschmannScalar.mw

@serper 

The information you provide is not sufficient for me to understand what is what you are trying to do/compute nor what could be the problem you are trying to point at. Perhaps you could attach a worksheet where you illustrate what is what you are trying to do?

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@serper 

The information you provide is not sufficient for me to understand what is what you are trying to do/compute nor what could be the problem you are trying to point at. Perhaps you could attach a worksheet where you illustrate what is what you are trying to do?

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@J F Ogilvie 

Thanks for your links, John, they will help in an ongoing revision of the SC package, which also includes a mechanism to keep up-to-date the package's databse using the information provided yearly or so by these official/standard sources.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi
The Physics package has achieved a good level of development, that is really good. The list of additional things we would like to see in place is however long and I would be happy to incorporate your feedback where possible. Also, the last leg of development for the next release is starting now - so I'd like to share a bit of the plans and hear opinions if any, or your further suggestions. Among the *candidate* improvements over the working table for the next release are:

1) Conversions between Vector and Tensor notation for 3D vectors. That would also allow us to take advantage of the existing tensor simplification routine to simplify vector expressions (convert to tensor -> simplify -> convert back to vector).

2) Vector integration in 3D Euclidean spaces using the Physics:-Vectors package vector notation and vectorial (Nabla) differential operators, as presented typically in Vector Analysis textbooks - line and surface integrals, work (circulation), flux (through curves and surfaces), etc.

3) Further improvements in the simplification of tensorial expressions.

4) Implement steps in the use of the Riemann invariants to resolve equivalences for solutions to Einstein's equations together with enlarging the database of solutions based on the book by Stephani et al.

5) Introduce a new kind of rule (say operatorrule, or dotrule) indicating the action of a quantum operator over a quantum state (ket) (as in operatorrule = {A . |psi> = something}), allowing us to carry on information about a phase, that cannot be carried on when setting a bracketrule.

6) Implement tensorial simplification of products of Dirac and Pauli matrices taking into account the algebras they satisfy.

7) Complete the support for spinor algebra and gauge fields using tensor notation.

8) Introduce Funint for Functional integration, complementing the existing Fundiff for Functional differentiation.

9) A revamped version of FeynmanDiagrams that: a) removes the current restrictions of no more than 3 vertices, 3 loops and 9 external legs; b) plots the diagrams themselves, besides returning the expansion of the scattering matrix S (represented by the diagrams)

10) The actual computation of the Feynman integrals behind the expansion of the Scattering matrix, including dimensional regularization.

And I don't think this can all be done in one single release, so as said your opinions/suggestions are welcome, either as comments here or writing to me directly at physics@maplesoft.com - thanks.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

PS: a new update to the Physics package got posted yesterday Aug/7, available for download at http://www.maplesoft.com/products/maple/features/physicsresearch.aspx.

@Alejandro

Although - as said - without "assuming real" you do not obtain a simpler solution (perhaps a problem in Maple simplifiers .. doesn't look like that though), I also think this diagonalizing before solving that you suggest, Alejandro, elaborating on Preben's linear combination, is a good idea/step not present in the old matrixDE Maple approach used before 1997. I'll see to implement this diagonalization step in a revised version of those old routines and make the prototype available in some way so that we can play around and improve/continue from there.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Alejandro
Your generalization of what Preben has done looks correct to me. Note however two things.

1) Both Preben and you used 'assuming real' in key intermediate steps of what you show. Without "assuming real", your approach produces a solution as complicated as dsolve's solution, not simpler. On the other hand, the simpler solution presented by Markiyan when he posted this ODE system is valid in general, for complex x, y(x), z(x). So there must be a way to obtain it without "assuming real".

To the side: while "assuming real" is perfectly valid during algebraic interactive exploration, Maple's default domain is complex. "assuming real" cannot be coded into dsolve.

2) What you are presenting, a MatrixDE approach, is actually the standard way to solve linear ODE systems (google and you see it). It was Maple's approach till 1996. The related old subroutines are still in the library: write sys as a set (not a list) then enter `dsolve/diffeq/LinSysNonConst`(sys, {y, z}, x) and you see this matrixDE at work - the solution you will see is not simpler than dsolve(sys) as it happens with your presentation when not using "assuming real".

My take on this: the actual problem behind finding a simpler solution to Markiyan's ODE system, in brief, is that the solution can be written in infinitely many manners because linear combination of solutions are also solutions. This is not related to using a matrixDE approach and I do not see any algorithmic way to tell what linear combination takes you to the simpler mix of trigonometric functions.

Details
1) Markiyan's sys can be decoupled into one algebraic equation (say for z as a function of y) and a 2nd order linear ODE for y as you see if you enter

> PDEtools:-casesplit(sys);

[z(x) = … (trigs and y(x)), y'' = a(x) y' + b(x) y]

where a(x) and b(x) also involve trig functions. Get now the equation for y(x) and solve it

> dsolve(ode_y);

y(x) = C1 s_1(x) + C2 s_2(x)

where the two independent solutions s_1(x) and s_2(x) also involve trig functions. If you now substitute this solution into z(x) = … (trigs and y(x)) you get the solution for z(x).

Now: you can rewrite this solution as y(x) = C1 s_3(x) + C3 s_4(x), where s_3(x) and s_4(x) are linear combinations of s_1(x) and s_2(x), and s_3(x) and s_4(x) may be simpler, or more complicated than s_1(x) an s_2(x). Likely, if you now substitute y(x) = C1 s_3(x) + C2 s_4(x) into z(x) = … (trigs and y(x)), the resulting solution for z(x) may also be simpler or more complicated than the solution you get when you use s_1(x) and s_2(x).

Summarizing: The actual problem behind "obtaining a simpler solution" is to decide on what linear combination between s_1(x) and s_2(x) among infinitely many is the most appropriate - I think it has no systematic solution. The matrixDE approach you suggest is standard, it was Maple's default 15+ years ago, and has advantages in some cases; we may even revamp it for when it is advantageous, but I does not take you systematically to a simpler solution.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Alejandro
A matrixDE approach was the default in Maple for tackling systems of linear ODEs in 1996 before I rewrote dsolve. In 1997 I changed that to using diffalg. Both approaches work in all cases, with respective advantages/disadvantages depending on the example - and as I said it is possible to come up with a heuristics suggesting the use of this or that approach depending on the example in order to get a simpler solution. The old matrixDE approach is still there: write sys as a set (not a list) then `dsolve/diffeq/LinSysNonConst`(sys, {y, z}, x). As you can see the solution returned is not simpler than dsolve(sys). You mentioned some further tuning. I look forward for your next comment.

About the problem - itself - of obtaining a "simpler" solutions for a linear ODE or a system of them: you know, linear combinations of solutions are also solutions, so depending on: 1) the mathematical functions entering the system and 2) the default way of simplifying them (e.g. Maple and Mathematica work differently), some linear combinations of solutions will result in simpler solutions than others. That is what Preben did for this example. Nice, but just for this example, based on educated human exploration around it.

Regarding the transformation suggested by Markiyan *for this example*, i.e. tan instead of cos used by dsolve, recall we are talking of an algorithm, for a general problem, not for one ODE. The approach used in dsolve *for the general problem* is to first normalize the equation (different problems map into one and the same) to decide what is (heuristically) a more convenient transformation among many possible. In Markiyan's example, after decoupling, the system reduces to one equation: diff(diff(y(x), x), x) = (sin(x)*(diff(y(x), x))*cos(x)^3-5*y(x)*cos(x)^2+27*sin(x)*(diff(y(x), x))*cos(x)+9*y(x))/(cos(x)^4-6*cos(x)^2-27). You normalize it via convert(%, NormalForm, simplifier = simplify); and receive y'' = f(x)*y where f(x) only involves cos. It is then natural to use t = cos(x). For this example (not others) using t = tan(x) rationalizes this ODE the same way as t = cos(x) (try it - you have PDEtools:-dechange for that). By the way providing an option to indicate the transformation is in the plans since some ages ...

The summary is as said in previous comments: A) no one has identified here, so far, a class of problems for which the matrixDE decoupling instead of a direct differential algebra approach, or the tan instead of cos transformation, is more convenient. By class of problem, Alejandro, I do not mean "the linear ODE system class of problem" (obvious) you said, but a subclass of them for which one method is more convenient than the other one, being that *both work in general* (unlike what you said it might be). B) This is just about returning another solution, simpler than the already correct solution returned, in a context where any linear combination of solutions is also a solution - there are infinitely many possible. C) dsolve has good heuristics in general for returning simpler and from times to times I invest more time in simplicity - it is important. The possibility of taking advantage of using a matrixDE approach, even if in some seldom cases, is in my mind since I changed that into using differential algebra. I may even return to this motivated by your comments. But, honestly, this is not top priority for me in the context of so many directions into which the current DE solvers can be enhanced.

To the side: besides the Physics package, it is certainly exciting and *extremely* challenging for me to be on top of the development of the DE and PDE symbolic solutions and special functions code of a project as big at the Maple project. Two non-obvious important remarks: it is just silly to approach this challenge as a only-one-person endeavor - your feedback and ideas (include here the arxiv repository) are of the uttermost importance, even when I may disagree with you. You are also not sitting in this cockpit, you can't imagine how many things can still be done. Literally, the "more" I augment the methods, simplifications, etc. in use, the "10x more" I see further things and methods that can be derived and implemented. To add complexity: the interconnection between methods for ODEs, PDEs, special functions and simplification is, well, just brutal, I'd say impossible to present just in written. This post on "ODEs, PDEs and Special Functions" all-in-one is in part motivated by my perception of that connection, as you see it also in the examples of the attached worksheet.

Edgardo S. Cheb-Terrab
Physics, Maplesoft