prldb

40 Reputation

One Badge

2 years, 25 days

MaplePrimes Activity


These are replies submitted by prldb

@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.

with(Physics)

NULL

g_[[27, 27, 1]]

Physics:-g_[mu, nu] = Matrix(%id = 18446745763104129142)

NULL

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 ?

Page 1 of 1