@ecterrab 

Thanks for your patience with my questions. I am not disputing that a null tetrad remains a null tetrad no matter how it is ordered or labelled. In the NP formalism, which Stephani et al. follow, the null tetrad labels reflect the construction of a null tetrad from a basis of spinors (a spin frame). ell and n (or k and ell in Stephani et al.) are constructed as the products of one of the spin basis elements with its complex conugate, whence are always real vectors. m and mbar are constructred as one of the spin basis elements times the complex conjugate of the other one, so are complex and complex conjugates of each other. Applying a null rotation does not alter this arrangement (a null rotation is best thought of as adding a multiple of one of the spin frame elements to the other).This labelling is just a convention of course but it is the convention of the NP formalism and underlies all the other notaion of the NP formalism (which is how the NP formalsim is implemented in the Differential Geometry package of Maple (see Tensor[NullTetrad]). Reversing the signature only reverses the sign of the non-zero scalar products of the tetrad elements so neither the signature nor the ordering of coordinates affects the convention by which the NP formalism labels the elements of the null tetrad.Given the labelling of the elements of the default null tetrad computed by the Physics package for the Stephani et al. metric 27.37, the convention the package is using to label the elements cannot be based on the NP convention reflecting the underlying spin frame since the elements labelled ell and n are not real.

@ecterrab 

Thanks for that link. In clarifying the documentation, is the labelling of null tetads by l, n, m, mbar, meant to mimic the NP formalism? If so, it's odd that in the default null tetrad produced, for example, for Stephani et al. 27.37 m and mb are not complex, but rather l and n are. But perhaps the labels are not meant to suggest the NP formalism?

@ecterrab 

Thank you! That does resolve that wierd warning I was getting. So now my code works, but I'm still curious why Tetrad labels the elements of null tetrads the way it does (e.g., not necessarily having m and mb complex but rather l and n, as in the default null terad for the metric (27.37) from Stephani et al.). It would also be useful if the help on Tetrads specified the labels assigned to the elements of a null tetrad, especially as this order changed in Maple 2021, from l, n, m, mbar to n, m, mbar, l, i.e., given a matrix that specifies a null tetrad, the command e_[nullvectors] in Maple 2019 labelled the first row l, the second n, the third m, and the fourth mb while  Maple 2021 lablled the first row n, the second row m, the third mb, and the fourth row l. I assume Maple 2022 follows 2021. Maple 2023?

Have a great weekend.

@ecterrab 

Hi:

Thanks for responding. l look forward to hearing your responses to my querstions. I appreciate that Maple 2021 is an older version now. I will be interested to hear whether my problem with Tetrads in 2021 was a bug that has either been fixed in 2022 (i.e., does my code run properly in Maple 2022?; My routine did work in Maple 2019, as you will see from the files I uploaded) or will be in 2023 or something else. I do think Maple should label the members of a null tetrad in a way consistent with the NP formalism so that m and bar m are both complex (and conjugate) and ell and n are both real. 

After a long hiatus I have come back to the issue of 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 (even though it is not standard it should suffice that the first and fourh element 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

@ecterrab 

In my last response I failed to declare the Physics package.I now have syntax that works and the result is what I hoped for.

GenRobinsonTrautmanDGSpin.mw

Thanks! 

@ecterrab 

I have attached an example, it's the calculation of spin coefficients and curtature spinors for metric (33.5) in Stephani et al (amneded to suit my conventions; but I have simply given a null tetrad rather than the metric explicitly) done in DifferentialGeometry. The functions H, P, and chi are real valued but the output involves terms in the complex conjugate of chi. For Psi1, one easily sees the expression is zero (as it should be for this example) when chi is real. It would be nice to get Maple to treat chi and the other functions as real valued so the output is in fact zero.

Setup has 'realobjects' as a parameter option but I couldn't find an example of how to use it. You will see I tried one possibility, but it didn't do anything. But it would seem knowing how to use it might solve my problem.GenRobinsonTrautmanDGSpin.mw

As you can see from the example, the issue is getting Maple to treat a symbol representing a fucntion as real valued, not getting Maple to treat a variable as real in a numerical computation.

@ecterrab SKMHH27_37.mw SKMHH27_37_Modified.mw signature.mw

Many thanks for your post responding to my query. As a result I have resolved  most of my issues, though it has raised more questions for me. In your post you put in the metric (27,37) by hand and specified the order of the coordinates as in Stephani et al (hereafter Steph). Note that Setup(metric=[27,37,1]) does not give Steph's ordering of the coordinates, but rather specifies (u,r,z,zb) (as in SKMHH27_37.mw).This is why my definiiton of null tetrad (co)vectors looks different to what one might expect from Steph.  I did have a couple of extraneous minus signs, and removing those has helped. Nevertheless, my .mw files (all three start with a call of [27,37,1]) and your metric are the same, only trhe coordiantes are ordered differently. Yet, when I use Setup(tetrad=null) in SKMHH27_37 the tetrad Maple returns is different to the one you get using the same command. Why would Maple give different results in these two cases, that seemingly only differ by the ordering of the coordinates?

Continuing in my SKMHH27_37 worksheet, I did get TransformTetrad(canonicalform) to output a result, though it's not the null tetrad of Steph. and still quite complicated.

I then defined the null tetrad of Steph directly, in covector form, and Maple now recognizes it as a null tetrad and returns the expressions for the Weyl scalars I expected. So, my remaining question on this worksheet is why Setup(tetrad=null) gave a different result to what you obtained? Despite the non-uniqueness of null tetrads, I would assume that this command applies some default procedure to the metric to construct a null tetrad and so, given the same metric I would have expected the same result from the same command, even though the coordinates are ordered differently.

In KSMHH27_37_Modified, I started by calling [27,37,1] and tried to follow your procedure for introducing a null tetrad, defining the contravariant vectors. It seemed to start okay, but when I wrote the equivalent of your line 'Define(16)' (my line 'Define(4)') the output I get differs from yours, and seems a bit bizzare, and then when I ask for the components of the covariant forms as you did I don't get an output. So something has gone wrong in my worksheet, even though I believe I have followed your syntax. Why is the line 'Define(16)' even ncecessary? Doesn't the previous 'Define' command define l, n, m, mb as tensor objects and then the following line specifies their components; what purpose does 'Define(16)' serve?

I then resorted to the same syntax I used in SKMHH27_37, introducing a matrix whose rows are the covector components and then specifying that as a tetrad, and checking it's null. So my question here is, why does my 'Define(4)' not do what your 'Define(16)' does? For some reason, my syntax has failed to define the four vectors l, n, m, mb I assume, which is why the comamnd l[ ]; n[ ];m[ ];mb[ ]; didn't return the covector components. Yet my equaitlon (4) looks okay.

My next question is about the commands l_[ ] etc in Tetrads. Am I right that calling those commands just returns the current null tetrad, which will be the same as Setup(tetrad=null) if no other null tetrad has already been specified?  When I called l_[ ]  etc at the end of SKMHH27_37_Modified, the null tetrad I had defined was returned, correclty labelled. I am surprised, however, in your worksheet that the first element of the null tetrad created by Setup(tetrad=null) is labelled n, the second m, the third mb, and the fourth l, with m clearly not the complex conjugate of mb. In fact, the n and l of your (8) and (13) would be the complex conjugate pair for Steph. I wonder if this seemingly odd labelling has something to do with the question I ask in the last paragrpah below?

In your worksheet you chose the default spacetime signature (---+), whereas the default signature of Steph is (+++-). One can set the signature with Setup, but when Itried to do so after calling [27,37,1] I got an error message that I could find no help on despite searching the Help and forrums. It's in the signature.mw worksheet. I get this error whether I place the Setup command to specify the signature before or after calling the metric. I couldn't find an actual example of the use of this comamnd in Help. So my last question is how does this command work? Can it be applied after the metric is called or only before? And why am I getting this error message.

Adding to my confusion is your choice of the default signature (---+) together with Steph's form of the metric. In Steph, the coordinates z and zb are complex conjugates and their coordinate plane is positive definite while the u coordinate is negative definite, in accord with their signature of (+++-). In your worksheet Maple states that all the coordinates are real (equation (2)).  If z and zb are interperted as real, their coordinate plane would be of signature (+-), given the metric. The coordinate plane of (u,r) is orthogonal to that of (z,zb) according to the metric, and contains a null vector (the coordinate vector of r) while, generically, the coordinate vector of u is non-null and not orthogonal to that of r, which would make the signature of this coordinate plane also (+-), whence the metric would be of neutral signatuer (+-+-). I know from experience with the Physics package that one can set up a metric of, say, neutral signature, and Maple will compute all the ususal differential geometry quantities correctly without complaint (which is a good thing since neutral signature is not an option in Setup). So I'm assuming these symbolic computations are performed independently of the specified signature, i.e., Maple doesn't assume a signature for the purposes of calculating any metric-dependent quanity, it just uses the metric. Though the specified signature would affect Maple's interpretation of the coordinates?

@ecterrab 

SKMHH27_37.mw

Thank you for responding to my question about computing with metrics called from Stephani et al. 

I have attached a .mw file that attempts to do what you requested (SKMHH27_37.mw) . Here I am using the metric [27,37,1] as it is simpler in form than [27,27,1] and still involves the same issues. I was aware that there were functional constraints on the metric [27,27,1] and also that null tetrads are not unique.  I did assume that the null tetrad that Maple used as default with a metric from Stephani et al. would be the one stated in association with the metric when one is given. But I suppose Maple is using a procedure applicable to any metric to return a null or orthonormal tetrad for a given metric. Is that so?

In the attached worksheet, I have called metric [27,37,1], then called for a null tetrad, and then for the Weyl scalars. Stephani et al. specify a null tetrad (in contravariant form) in conjunction with the metric (27.37). The covariant form of this null tetrad is readily computed:

m_a = (0,0,0,-r/P(u,z,zb))

\bar m = (0,0,-r/P(u,z,zb),0)

ell = (-H(X),-10,0)

k = (-1,0,0,0).

Before trying to use these, I used the TransformTetrad(canonicalform) command, but as you see in the worksheet, Maple only returned that text, rather than outputting a null tetrad. Is the syntax incorrect?

Since that attempt failed, I then tried to set the null tetrad 'manually'. As I understand it, the matrix format for a null tetrad in Maple is for each row to consist of the coordinate components of a given tetrad covector. The ordering in Stephani et al is m, \bar m, ell, k, as listed above, so these would be the first through fourth rows. So, I created a matrix accordingly and used Setup to specify the null tetrad by this matrix. Again, is this syntax not correct, since the IsTetrad command did not return an answer. So I think there must be a simple syntax  misunderstanding on my part as regards TransformTetrad and attempting to set a tetrad 'manually'.

As regards the output for the null tetrad and Weyl scalars that Maple did give for metric [27,37,1], the ell and k elements of Maple's null tetrad are much more complicated than those used by Stephani et al (i.e., those above). Using the null tetrad of Stephani et al., I computed the spin coefficients myself and then the Weyl scalars. I obtained that Psi_0 = Psi_1 = 0 as expected and also the vanishing of the Ricci scalars corresponding to Stephani et al (27.2). For Psi_2 I obtained

Psi_2 = -(P_u/P*r) - (H_r/r), where the subscripts denote partial derivatives with respect to coordinates.  This result agrees with the special cases obtained subsequently in Ch. 28, viz., in (28.10) and (28.38). It is much simpler than the result returned by Maple for Psi_2.

I am guessing that the Physics package uses some universally applicable routine to produce a null tetrad for any metric and thus not typically the null tetrad that is associated to a metric in Stephani et al. But it sounds like TransformTetrad(canonicalform) should yield a null tetrad at least adapted to the null geodesic congruence the metrics of Part III in Stephani et al admit, for which the Weyl scalars will take their simplest form. But I don't understand why that command is not working for me. I assume it's a simple fix of some kind though. If so, then that effectively solves my problem. But I would also like to know the simplest syntax for specifying a tetrad (null or orthonormal) 'manually', as I don't seem to have the correct syntax for that either.

Thanks for your attention

@ecterrab 

My attempt to insert the contents of the worksheet trial.mw failed for some reason so only the link inserted.

Trial.mw

Trial.mw.pdf

Following is a copy and paste of the contents, the formatting is messed up but you can see that only the metric ittself is outputted. In your response you seem to have a colon following g_[[27,27,1]], but a colon suppresses output. Could it matter that I am using diocument mode rather than worksheet mode? No, I just treried that and got the same, just the metric.

with(Physics)  :

g_[ [27, 27, 1]];

g      = [[-2H(X)    -1

1

(-2H(X) L(u,z,zb)  p(u,z,zb)  +L(u,z,zb)  (  :.                      (1)

µ,v                                  '           '     p( u,  z, zb)                                
                                                        vu

rO(u,z,zb))  p(u,z,zb)  -   (        rO(u,z,zb))  p(u,z,zb)  -           L(u,z,zb)),

-2H(X) Lb(u, z, zb)  -   Wb(u, z, zb)}

-1,  0, -L(u,z,zb),  -Lb(u,z,zb)   ,

1

H(X) L(u, z, zb)  p(u, z, zb)  +L(u, z, zb)  (         rO(u, z, zb))  p(u, z,

p(u, z, zb)

zb)  -   ( ! rO(u,z,zb))  p(u,z,zb)  -   ! L(u,z,zb)),  -L(u,z,zb),

1

p(u, z, zb)

1

zb)  (         rO(u,z,zb)  -H(X)))) ),                                                              
    2   (

OU                                                      rho_b(u,z,zb)  p(u,z,zb) P(u,z,zb)

-2 H(X) Lb(u, z, zb) L(u, z, zb) rho_b(u, z, zb)  p(u, z, zb) P(u, z, zb ) 2 +Lb(u, z, zb) L(u,

z, zb)  ( ! rO(u, z, zb))  rho_b(u, z, zb)  p(u, z, zb) P(u, z, zb ) 2 -   L(u, z, zb)  Wb(u, z,

zb)  rho_b(u,z,zb)  p(u,z,zb) P( u, z, zb ) 2 -   L b( u, z, zb )  ( ! rO(u,z,zb))  rho_b(u,z,

2                                   !                      2

[ -2  H(X) Lb(u, z, zb)  -   Wb(u, z, zb),  -Lb(u, z, zb),

l               (-2 H(X) Lb(u, z, zb) L(u, z, zb)  rho_b(u, z,

2rho_b(u, z, zb)  p(u, z, zb) P(u, z, zb)

zb)  p(u,z,zb) P( u, z, zb ) 2 +Lb(u,z,zb) L(u,z,zb)  ( ! rO(u,z,zb))  rho_b(u,z,zb)  p(u,

z,zb) P(u,z,zb) 2 -L(u,z,zb)  Wb(u,z,zb)  rho_b(u,z,zb)  p(u,z,zb) P(u,z,zb) 2 -Lb(u,

My question is not really  specific to a particular metric as I have several examples in mind. I'm really interested in how many arbitary functions the KillingVectiors command in DifferentialGeometry is likely to be able to handle and some idea of how long it might take Maple to output a response.

I haven't as yet used the physics package so i'll have to acquaint myself with the syntax for setting up the metric.

I see that KillingVectors in the Physics package seems to have more options for the output, which is useful. But I would assume that KillingVectors is likely to have the same resources in both packages as far as actually finding Killing vectors ?