spinors in general d

[Omar Z]

Hello everybody,

I would like to work with Dirac spinors in general dimension d. Basically I'd like to have access to the spin connection and the Clifford algebra without having to assume d=4.

I played around with both packages Spinor and FieldsX, but it seems to me that they require the dimensionality of the manifold to be fixed (respectively 4 and a natural number(?)) when defining the spin structure.

I understand that the constraint is there for a reason, but a lot of properties can be worked out in general dimension and arbitrary signature for a Dirac spinor. For example that the massless Dirac action is conformal invariant in any d.

Is there a known workaround which does not require breaking apart the source code of the aforementioned packages? I would be ok with somehow limited functionalities in comparison to the original codes, of course.

Thank you in advance.

Best

Omar

[Markus B. Fröb]

Dear Omar,

it is difficult to actually properly define the Clifford algebra for
arbitrary continuous d, since it becomes infinite-dimensional.
And of course there are all the problems with chirality, which is only
defined for even dimensions, and Fierz identities and reality
conditions, which really depend explicitly on the dimension.

However, if you can work in d \approx 4 dimensions (for dimensonal
regularisation purposes, say), the following can be used with FieldsX:

1. Define your manifold M and metric with d dimensions.

2. Temporarily set the dimension to 4:
DimOfManifold[M] ^= 4;
DimOfVBundle[TangentM] ^= 4;

3. Define spin structure, spinors, ...

4. Set the dimension back to d:
DimOfManifold[M] ^= d;
DimOfVBundle[TangentM] ^= d;

One thing that will not work is the automatic dispatch to the correct
generalised \gamma matrix (described on the bottom of page 5 of the
manual), so you would have to always use the correct Gammagg1, Gammagg2,
..., but this is more a nuisance than an actual problem. FierzExpand,
FlipSpinChain, SortSpinor, ... will not work since the corresponding
identities depend explicitly on the dimension. Otherwise most functions
should behave properly, even though I haven't tested them extensively
with such a workaround.

For bug fixes and new versions of FieldsX, please do check the Github
page: https://github.com/mfroeb/FieldsX

Best regards,
Markus

> --
> You received this message because you are subscribed to the Google
> Groups "xAct Tensor Computer Algebra" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to xact+uns...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/xact/06613a1e-437d-48cc-b08c-002fb1783527n%40googlegroups.com
> [1].
>
>
> Links:
> ------
> [1]
> https://groups.google.com/d/msgid/xact/06613a1e-437d-48cc-b08c-002fb1783527n%40googlegroups.com?utm_medium=email&utm_source=footer

[Omar Z]

Dear Marcus,

thank you very much with your quick reply and for putting the time on it. The problems that you mention are precisely those that I had in mind in my original question.

The solution that you suggest works perfectly fine for a continuation close to d\approx 4 in which the Clifford algebra is kept as the one in d=4. It surely will be helpful for some other application in the future!

However, it does not work with the example that I was suggesting on proving that the massless Dirac action is conformal invariant in any d. Obviously here d should be intended as some natural number, d=1,2,3,4 etc.

The reason why it does not work is because the spinor transforms with a conformal factor of weight (d-1)/2, whose exponent is pulled down by the partial derivative of the Dirac operator. The (d-1) should then be cancelled by another term coming from the spin connection, which ultimately is generated by contracting a gamma matrix (the one producing the slash in the covariant derivative) with the generator in the spin connection. A simple check reveals that this contraction correctly produces (d-1), in fact \gamma^a [\gamma_a,\gamma_b]=2(d-1)\gamma_b using the standard properties of the gammas (modulo the overall constants). If I generate the Clifford algebra at fixed d=4 then the contraction will give me d-1=3 automatically, so the proof will only hold in d=4.

I think that for this specific application it will be sufficient a poor man implementation of the spin connection.

Best

Omar

[Markus B. Fröb]

Dear Omar,

have you tried what I suggested?

After defining the Clifford algebra in the way I described, using
CollectTensors@JoinGammaMatrices[Gammag1[\mu,-A,B]
Gammag2[-\mu,\nu,-B,F]]
gives me the output (-1+d) Gammag1[\nu,-A,F], which seems exactly what
you want.

If you obtain a different result, please let me know - of course it's
always possible that there are some subtle bugs in FieldsX which I will
fix.

Or maybe I don't understand at all what you are trying to do. In this
case, please enlighten me!
I'm sure a solution can be found. For more complicated cases, a minimal
working example (i.e., a notebook with the computation you're trying to
do) would also be very helpful.

Best, Markus

[Omar Z]

I just tried from my laptop and you are absolutely right, it actually gives the correct d-1. Tomorrow I'll check from my workstation, but probably I must have made a mistake.

Thank you again

Omar

[Omar Z]

I confirm that I made a mistake before. Sorry about that...

At the moment I am defining a frame bundle first and then the spin bundle. Defining the spin structure I get the error messages that AChristoffel and FRiemann are already defined, is it a problem? I am confused on which is the expected order of the definitions.

Also, I noticed that DefFrameBundle uses the first metric on TangentM by default and there is no option to choose another one. I circumvented the problem by defining another frame for another metric separately and adding the orthogonality and covariantly constant properties manually using xTagSetDelayed as in your package file. If would be nice to have an option such as UseMetricOnTangent -> "chosen metric" or to add another frame.

[Markus B. Fröb]

Dear Omar,

Am 2021-08-18 15:23, schrieb Omar Z:
> I confirm that I made a mistake before. Sorry about that...

no problem!

>
> At the moment I am defining a frame bundle first and then the spin
> bundle. Defining the spin structure I get the error messages that
> AChristoffel and FRiemann are already defined, is it a problem? I am
> confused on which is the expected order of the definitions.
>

Expected order is first spin structure, then frame bundle, then spin
connection (if needed). Sorry if this isn't clear from the manual, I'll
add it.

> Also, I noticed that DefFrameBundle uses the first metric on TangentM
> by default and there is no option to choose another one. I
> circumvented the problem by defining another frame for another metric
> separately and adding the orthogonality and covariantly constant
> properties manually using xTagSetDelayed as in your package file. If
> would be nice to have an option such as UseMetricOnTangent -> "chosen
> metric" or to add another frame.

In xAct, it's always the first metric on the tangent bundle that is used
to raise and lower indices. Compatibility with the frame requires that
this metric is the one used for the frame bundle as well. Otherwise, you
would run into problems of the following sort: e^\mu_a is by definition
(e_\mu^a)^{-1} as matrix inverse, i.e., one has e^\mu_a e_\mu^b =
\delta_a^b. On the other hand, e^\mu_a = g^{\mu\nu} \eta_{ab} e_\nu^b by
raising and lowering indices, and these two must agree. One could
circumvent this by defining the inverse frame field as a separate tensor
Inve, but then would need additional definitions to implement Inve^\mu_a
= g^{\mu\nu} \eta_{ab} e_\nu^b. I'll think about it, but if you have
found a solution that works for you, great!

Best, Markus

[Omar Z]

> At the moment I am defining a frame bundle first and then the spin
> bundle. Defining the spin structure I get the error messages that
> AChristoffel and FRiemann are already defined, is it a problem? I am
> confused on which is the expected order of the definitions.
>

Expected order is first spin structure, then frame bundle, then spin
connection (if needed). Sorry if this isn't clear from the manual, I'll
add it.

But if I define the spin structure with DefSpinStructure[] first and then the frame with DefFrameBundle[] it gives the error:

"Cannot define frame bundle if a spin structure is already defined."

I can circumvent the problem by setting temporarily

SpinBundleQ[SpinM] ^= False

then perform the definition and then

SpinBundleQ[SpinM] ^= True

[Markus B. Fröb]

Dear Omar,

sorry, this was a mistake on my part! Your original order was right, I
just checked again.
So first DefManifold/DefMetric, then DefFrameBundle, then
DefSpinStructure, then (if needed) DefSpinConnection.

However, there should not be any error messages. Which version of
Mathematica and FieldsX are you using?
Newest version of FieldsX is 1.1.3
(https://github.com/mfroeb/FieldsX/tree/v1.1.3).

If you attach your notebook I could also check how the error messages
arise.

Best, Markus

[Omar Z]

Hello,

I replied two days ago, but the mail did not go through, probably because I attached a nb.

Summary: I am using FieldsX last version from github and mathematica 12. The problem was that I was defining the spin connection before the spin bundle (as it seemed more natural to me). Now that I follow the order 1) frame, 2) spin bundle, 3) spin connection everything works fine. Thank you!

I am now confused by the use of CenterDot[]...

Shouldn't

\[Psi][-A1]\[CenterDot]bar\[Psi][A1]

be the negative of

bar\[Psi][A1]\[CenterDot]\[Psi][-A1]

?

Omar 

[Markus B. Fröb]

Dear Omar,

I received your message, but it didn't contain any question.

The reason for the (maybe non-natural) order is that in many
applications, the explicit spin connection is not needed.
FieldsX takes it into account automatically in variations/perturbations
through the variation of the covariant derivative acting on a spinor.
It seems to me that only in supergravity, where it has a quite
non-trivial BRST/supersymmetry transformation, does one need the spin
connection explicitly.
Otherwise, one can work without ever defining it.

Regarding your question: for anticommuting spinors, that is true, yes
(those are defined using DefOddSpinor). You can use ToCanonical to sort
the factors of the non-commuting product in canonical order
(alphabetical according to Mathematica), this will give you the explicit
minus sign.

Best regards,
Markus