Definition of interior product with an index

[alej...@gmail.com]

Hello everybody,

I am currently working on gravity in the language of differential forms. One of the limitations I have found when using xTerior is the interior product. I have noticed that there are already other posts in this group concerning the use of something like Int[Frame[M][a]][<differential form>]. But (at least one of) the problem is that the indices inside the first argument of Int are not taken into account in xTerior.

I have thought that maybe a "simpler" way (in quotation marks because I do not know in detail the internal structure of xTerior) could be to introduce something like

IntD[<index>][<differential form>]

The natural index position should be IntD[-a][...] since the interior product is performed in the direction of some vector 'e_a'' of the frame that is associated to the family of indices {a,b...}.

---

A first attempt could be to introduce a graded derivation. According to Alfonso's suggestion (thanks!), this can be easily done as

xAct`xTerior`Private`DefGradedDerivation[

IntD[v_], Wedge, -1, PrintAs -> "\[Iota]"

];

where "v_" can be anything; actually, "v_" is, as far as I know, completely invisible for xAct. This last fact is the limitation of this approach because we need "v_"...

1)... to be seen as an index.

Example: If we execute IntD[a][Test[b,c]] // FindIndices, "a" does not appear in the list. This is problematic in many situations, e.g. when canonicalizing.

2)... and to be manipulated as an index.

If one tries IntD[a][Test[b,c]], the index "a" appears as a lower index. Similarly, in IntD[-a][Test[b,c]], we get a lower index "-a"  (with the minus). Of course the metric cannot raise/lower indices.

I do not know how difficult these points can be. I think "1)" can be solved by asking with the appropriate command whether "v_" is an index of the tangent bundle. If not, an error should be printed. On the other hand, "2)" looks quite non-trivial.

----

Of course, once these technical issues are solved one can start introducing the fundamental properties of this operator: antisymmetry, the reduction of the rank of the differential form,... but these are surely much more simple to define. The problem is the very definition of the operator.

Thanks a lot for reading this. Any suggestion is welcome.

Best regards,

Alejandro Jiménez Cano

[Jose]

Hi Alejandro,

Declaring a new index argument is no small thing in xAct unless it can be incorporated into one of the existing types. It would require teaching every fundamental operation about that argument. These are things like finding indices, replacing indices, metric contractions, typesetting, etc. Let's say 20 very internal definitions or so.

I have the impression that this is a case in need of a new tensorial argument, not a new index argument. Right now xTensor has two general purpose types: inert-heads ih[tensor, indexlists] and products prod[tensor1, tensor2, ...] and it seems this requires something like a "tensorial inert head" tih[tensor1][tensor2] such that we can extract indices from both objects. Is this correct?

A question to everyone: Would this concept have other applications in any other area?

Cheers,

Jose.

[Thomas Bäckdahl]

Hi!

I agree that adding indices in several places like that seems to be a complicated thing to do.

I don't know if this helps, but over the last few years, I have worked on operators taking one or several tensor heads and returning tensor heads with index slots and symmetries that can be computed from the index slots and symmetries of the given tensor heads (and possibly extra information given). I know that this suggestion is basically going in the opposite direction to the suggestion, but it might be possible to handle the kind of computations you need. I have not looked into the details what you want, but in general what I am suggesting is something like this:

MyTensorOperator[Tensor1, Tensor2, extrapropery][indices]

The main things to implement would be:
xTensorQ[MyTensorOperator[T1_?xTensorQ, T2_?xTensorQ, prop_]] ^:= True;
SlotsOfTensor[MyTensorOperator[T1_?xTensorQ, T2_?xTensorQ, prop_]] ^:= some code
SymmetryGroupOfTensor[MyTensorOperator[T1_?xTensorQ, T2_?xTensorQ, prop_]] ^:= some code
PrintAs[MyTensorOperator[T1_?xTensorQ, T2_?xTensorQ, prop_]] ^:= some code
Tex[MyTensorOperator[T1_?xTensorQ, T2_?xTensorQ, prop_]] ^:= some code

You can also add code for DependenciesOfTensor, DefInfo, HostsOf, TensorID etc, but the ones above are the most important ones.

With this all the indices would be displayed after everything else. If you want the indices to be displayed at other positions you would probably need some more complicated code following the style

xTensorFormStop[Tensor];
MakeBoxes[MyTensorOperator[T1_?xTensorQ, T2_?xTensorQ, prop_][inds___], StandardForm] ^:= some code
xTensorFormStart[Tensor];
Tex[MyTensorOperator[T1_?xTensorQ, T2_?xTensorQ, prop_][inds___]] ^:= some code

I have not tested this idea for your case, but I have used these ideas for many other operators.
The drawbacks are that you have to enter all the indices last in the input form and that you have to write "some code" above which can be a bit complicated. You might also have to write extra code to impose your operator on something that already has indices. A fairly extreme case of an operator like this is the SymH operator in SymManipulator.
The method is general though and can handle basically any tensorial operations without modifying core functions in xTensor. You are only adding code for your special operator.

Regards
Thomas

--
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/ec56f577-36df-44c6-b454-3a1f7a9cab4en%40googlegroups.com.

[alej...@gmail.com]

Hello,

Thank you both for your comments, and for your proposal, Thomas. I will take a look at it. 

Indeed, it would be nice to include, as Thomas suggests, some extra code that allows to use an operator of this kind, instead of modifying at a very fundamental level the code of the basic packages. But, in the direction of your comments Jose, I have a (probably very naive) question. At the end of the day, what I am trying to find is something very similar in behaviour to the object that results from DefCovD, with the differences:

1) It should act on (tensor-valued) differential forms instead of just tensors.

2) It must present a graded Leibniz rule with respect to the wedge product.

3) Everything related to curvature, torsion, expansion in terms of PD and the Christoffel symbols, etc can be dropped.

Could it be a possibility to recycle part of the defining code of CovD? Or, this is what you have thought that requires ~20 changes in the basic packages (?) 

Best wishes,

Alejandro