After a long hiatus I have come back to the issue of null tetrads in the physics package in light of the updates to  Maple in 2021. I have uploaded a document file to illustrate. See below. My first question concerns the labelling of elements of a null tetrad. After calling the metric 27,37 from Stephani et al, and using Setup to specify a null tetrad, Maple's choice is such that the elements labelled m and bar m are not complex. Rather, both these elements are in fact real, while the elements lablled l and n are complex, with one being the negative complex conjugate of the other. While these are just labels, they don't agree with the usual conventions for the Newman-Penrose formalism, which is disorienting. What convention is Maple using to label the elments of a null tetrad?

Next, I try to specify the null tetrad used by Stephani et al., first by converting it into covariant form (which I did by hand rather than in Maple). In Maple's default null tetrad, the order in which Maple listed the elements of the null tetrad is n, m, bar m, l (as rows in the matrix display for e_[ ]), so I followed that convention (in the conventions of Stephani et al., the first and fourh element should have scalar product -1, the second and third scalar product 1, and all other scalar products zero, which is the case). After entering the matrix and using Setup to specify the null tetrad by the matrix, I get an error message saying that the components of the metric with respect to my tetrad are not just 0, 1, and -1. Yet,  executing eta_[ ]  does not confirm this warning; nor does a computation by hand.

Finally, IsTetrad asserts the tetrad is not null, contrary to the fact that it is a null tetrad.

Since I have followed the conventions implicit in Maple's default null tetrad for this metric, I am puzzled as to what has gone wrong.SKMHH27_37_2021_New.mw

On the other hand, taking into account how Maple 2019 orders the coordinates in Stephani et al 27.37 and labels the null vectors in a null ttetrad, if I translate accordingly what I have in the 2021 Maple file, Maple 2019 confirms Stephani et al.'s null tetrad is indeed a null tetrad, as one would expect. See the following file.SKMHH27_37_2019_Var.mw.

Suppose I specify a metric in say the differential geometry package or Physics package that has an arbitary function f(x,y) of some of the coordinates as a component. Can I specify Maple to treat the function as real valued when Maple is asked to compute curvature etc for the metric? In some examples I have performed Maple sometimes returns expressions in f(x,y) for components that are in fact zero once one treats f(x,y) as real valued. It would be preferable to have Maple actually return '0' in such cases.

I tried the 'assume' command but Maple complained it was being applied to a protected name and I tried using

use RealDomain in simplify (5) end use

after Maple's computations, where (5) lablled Maple's output, but Maple didn't perform any simplification.

Given a metric, to compute quantities in the NP formalism one needs to specify a null tetrad. In the various examples in the help pages, sometimes the tetrad is specified simply as a list of 4 vectors, e.g., NT := [...] and sometimes evalDG is applied as in NT := evalDG({...]). Using the first format, Maple accepted NT as argument in NPSpinCoefficients but  NPCurvatureScalars(SpinCoefficients,NT) complained that the second argument wasn't a list of four vectors. When I used the second format, both commands returned the expected results. Why the difference?

RobinsonTrautmanSpinDG.mw

If I call for the metric (27.27) in Stephani et al. in the Physics package, I expected the null tetrad employed to compute say the Weyl scalars would be the one given in conjunction with (27.27) (equation (27.22) in Stephani et al.). But, Weyl[scalars] returned long expressions for each of the five scalars, whereas with respect to the null tetrad in Stephani et al one expects the first two (or last two) scalars to be zero since the null vector k in their tetrad is the multiple pnd of Weyl. e_[nullvectors] and Setup(tetradmetric=null) followed by e_[ ] seem to output the same null tetrad, which does not appear to be that of Stephani et al. I assume this null tetrad is the null tetrad associated to the orthonomral tetrad that e_[ ]  returns if one hasn't used Setup(tetradmetric=null). How does Maple select this default orthonormal tetrad? What is the best way to set the null tetrad of Stephani et al as the null tetrad to compute Weyl[scalars]?

Here is a simpler example. Calling [27, 37, 1]. Stephani et al give the null tetrad in terms of the spacetime coordinates along with the metric in their equaiton (27.37). After using Setup(tetradmetic=null), e_[ ] returns a tetrad that might, I suppose, be that of Stephani et al. in disguise. Specifically, the tetrad vector defining the null congruence should have only a component with respect to the coordinate r, yet the Maple output gives expressions for the components with respct to the u and r coordinates for both the k and l elements of the null tetrad (while the expressions for the complex element m is exactly what one would expect). As in the previous example, all Weyl scalars are given by nontrivial expressions, even though two of them should be zero (since k is a multiple pnd). So is it the case that the experssions in the Maple output where one expects zero are in fact zero in disguise? The experssions are complicated enough that it is not obvious.  I have uploaded the Maple document for these calculations. SKMHH27_37.mw

The Help page Physics/tensors-a complete guide states that spacetime metrics from Kramer et al. are referenced by chapter, section, and equation number, e.g., g_[[12, 16, 1]]. But there is no section 16 in Ch 12 and equations within each chapter are numbered sequentially without reference to section. By playing around it seems that in fact the first number is chapter, the second number is equation number, and the third number refers to subcases of the metric, when they are specified in the text. Is that correct?

Also, the output I get from say g_[[27, 27, 1]], or any other attempt  made, is just the metric, without any specification of the coordinates etc, which the Help pages susggest should be part of the output.