@Age 

I see now clearly the issue you are pointing at, and indeed your logic is perfect. The problem was as mentioned in the third bulled of my previous response here, I still need to make complete the implementation of tetrad indices, in this example, a routine that was only working with spacetime indices, detected a contravariant index and it lowered using the spacetime metric, but the index is a tetrad one, so the tetrad metric should have been used instead. This problem would turn visible if: a) you enter the right-hand side of the definition as a matrix and b) the tetrad index is contravariant, and if any of a) or b) wouldn't happen, the problem would not be visible. It is fixed now and the fix available at the usual place, the Maplesoft R&D Physics webpage.

This latest version of Physics also has an important step in the implementation of tetrads. Say you define a tensor giving its spacetime components, as in A[mu,nu] = (some tensorial expression or a Matrix, or an Array if there are more than 2 indices, etc.). What are the components of, say, A[~a, mu]? or A[a, ~b]? or any combination of covariant/contravariant/ and spacetime/tetrad indices? It is now implemented.

It follows an image showing the fix and this novelty illustrated with your example.

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

@Age 

Thank for your feedback, it's been useful, very, and please, if this is not a burden for you, keep posting any problem you find, here in Mapleprimes or writing to physics@maplesoft.com (I prefer in Mapleprimes, because everybody interested in Physics learns something with the exchange. And the package grows more and more with yours and other's feedback.

Regarding the specific issue of tetrads, you know, it is a new development. What works already, works pretty well, I think, but not everything is implemented.

And what is and what is not yet there? Skipping the little details, the design is that now you can compute with the tensor A, as in A[mu] or A[a] in equal footing, and representing different objects: A[mu] are the components in the global coordinates (g_[mu,nu] metric) system while A[a] are the components in the local (tetrad eta_[a,b] metric) system.

This requires:

• Ability to define a tensor with spacetime or tetrad indices: implemented.
• Ability to compute the components when you raise any of these different indices: implemented - your example today actually works fine for me - please see below.
• Ability to compute the tetrad (spacetime) components when the definition was in terms of spacetime (tetrad) components: not implemented yet. Eg you define a tensor giving its spacetime components, say as in A[mu,nu] = g_[mu,nu] and you ask A[mu, b, matrix].
• Ability to perform operations (all Physics commands dedicated to general relativity) distinguishing the case (the index is spacetime or tetradic): not implemented yet, though a new Library routine for making this possible is already in place, called Library:-RewriteTypeOfIndices (see below). To mention but one example of things not implemented yet: d_[mu] and d_[nu] commute, of course, but d_[a] and d_[b] do not.

And in what is already implemented I still expect we will find things to adjust furthermore, here or there, the code is pretty new. But as said what is in place is already working very-very well, and I am happy to handle your next bug reports rapidly if there are any. Your suggestions (not necessarily bug reports) are also welcome.

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

@Age 

It is great that you are providing this early feedback on tetrads/GR - many thanks - not many people in this forum work in the area.

The problem you mentioned is now fixed. The fix is available for download in the usual place, the Maplesoft R&D Physics webpage. The extension of the tensor machinery of the package to handle tetradic and spacetime indices at the same time, will probably require some more touches here or there, it is a large portion of code.

Attached is also revision of your worksheet with some comments; mainly: you indicate which repeated indices are contravariant (you can, but there is no need for that), and you explicitate the metric for performing the contractions (also you can but do not need), or you sum over repated indices before calling TensorArray - this too is not necessary. It is true however that, when we want to verify things, doing it the way you present may be helpful to identify where is that things are not as expected.

TensorArray_Tetrads(reviewed).mw

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

@Age 

It was not a problem in your machine. The package was under a reorganization, it is adjusted now, you'd need to updated Physics again, as usual from the Maplesoft R&D Physics webpage.

With the reorganization, Tetrads is now visible when you enter with(Physics); and all of the 8 related tensors, the four that have tetradic indices as well as the four spacetime null vectors of the NP formalism are all now part of the subpackage. I reorganized accordingly the NullVectors.mw temporary presentation.

The idea for this week is to have the Ricci rotation coefficients and the Weyl NP scalars implemented. Let's see. All these GR developments are really nice and it is exciting how these otherwise complicated matters become so accesible. 

Thanks also for your feedback, Age, both for the comments about the package and the pointing to this Physics:-Print issue.

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

Hi

I do not see the system of polynomial equations you mention, nor I see the metric or related line element of the problem. If you could please clarify your post?

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

@NOh 
I don't know what you are doing but it works for me and without quoting:

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

@Alejandro Jakubi 

int(f(x),x);

type(%, 'int(function, name)');

                                             true

type(f(1), 'f(integer)')

                                    true

So, no design problem here. On the contrary, this is one of the fantastic things in the maple system: you can test if an object is a certain function with arguments of certain types. That is also what Andriy was testing. Now if you allow int(function,name) to be executed, you receive function*name, making the type test fail, of course. for that reason you quote it, as in 'int(function,name)' when passing it as a second argument to type. By the way this also works with indexed objects:

type(A[j], 'A[symbol]')

                                        true

and here again: if A is a table such that A[symbol] returns a value, for example '2', then you need to quote it when passing it as second argument to type, or otherwise the type test will not work - you would be testing if A[j] is of type '2'.

For details see the help page ?type,structured. Here I only wanted to clarify that  there is no design problem and this is not related to names that collide with procedures or alike. This has to do only with a way to perform type testing in the Maple system, very useful, and described in the help page mentioned.

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

@w-Teilchen 

It would be great to see your post (I'd suggest to presente it separated, as a new post, instead of as an answer to this post). I'm looking forward.

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

@Alejandro Jakubi 

The computation shown illustrates precisely how to perform the derivative, whether you call the matrix in the middle by A, by B or by Inverse(A) -- in all cases it is just a matrix. By the way, note also the Physics:-Inverse command, useful when working without indices and not actually with matrices.

Regarding working with linear algebra using tensor notation: I find this natural, specially if you want to compute regardless of the dimension, or taking into account symmetries under permutation of indices, etc.

Regarding working with linear algebra also without tensor notation and not with matrices, depending on what you want to do, using noncommutative variables implemented within the Physics package serves the purpose well. The implementation of Dirac's notation within Physics, for "quantum mechanics vector calculus", is an example.

My 2 cents ...

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

@Age 

Just to confirm that I tried now your examples using a more recent Physics library, that you can download from the R&D Maplesoft Physics page, and the results come all correct (the ones you expected).

Edgardo S. Cheb-Terrab 
Physics, Maplesoft

@NOh 

This seems to be a different question, although I do not see the images, probably a problem in Mapleprimes website. Could you please upload a worksheet instead so that I give this a look? Thanks.

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

@Age 

I'm out of town in this moment, and unable to check things further, but I suggest you to update your Physics library from the R&D Maplesoft Physics page and try your examples again. I will return to this topic in one week.

Best

Edgardo

@w-Teilchen 

Unfortunately, I didn't have time to look at your post yet, I've been coding the tetrad formalism of General Relativity, it is mostly finished. Your post, together with 2 other posts made here in Mapleprimes that, like yours, I couldn't address faster, are first in the list of things I plan to give a look starting Oct/15.

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

@Alejandro Jakubi , @rlopez

The problem is in the use of alias, as expressed by nm, or otherwise in the use of 2D input mode versus 1D input mode, as indirectly expressed by you two.

If you use alias, Robert, Typesetting:-Supress is of no use and things happen as mentioned by nm in this post. If on the other hand you do not use alias, AND input in 2D mode, things happen as you mentioned, Robert, and diff(g, t) returns not 0; otherwise if you use 1D input mode as I understand you use, Alejandro, then diff(g, t) returns 0 unless you use alias, in which case we are back to square one: things happen as said by nm. Alternatively, PDEtools:-declare is free of all these nuances, working OK with or without alias, and regardless of using 1D or 2D input - I mentioned it for that reason; but then we do not have the dot to indicate derivatives.

This requires a fix in Typesetting, as suggested by nm.

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

@nm 

Note that, unfortunately, the steps you would like to see automated are however not possible to be automated. When dsolve returns ODESolStruc it is because the computer algebra system as a whole does not know how to solve the reduced ODE. Therefore, one cannot automate 'returning a final solution' as you suggest in your third and fourth paragraphs.

Likewise, odetest can only test the solution you give to it. Any automatic replacement of your solution or of your ODE by something else would be inappropriate. And the option useInt is an option of dsolve, not odetest, so this too cannot be automated. Think more about: you pass a solution and instead of testing it, odetest, automatically, would first compute another solution using dsolve's option useInt, test this other solution, then return 0. Would you accept that result? I wouldn't. It didn't test the solution I passed to it.

All this points to a relevant thing: computer algebra is of enormous value but you should not think of it as a "complete solution". There is no complete solution. There will always be cases that require your human-skilled approach. Whether you have the skillls to do better than the computer is another story, with which I agree with you, few people have those additional skills, but that doesn't change the facts, there will always be situations where you will need to guide the computer.

Yes, more examples in the help pages are always useful. I will see if I can add some of these of this post to the help page of odetest.

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