Is there a way to turn off automatic use of the delta tensor for the mixed indice forms of the metric?

[BillN]

Hi,

When working with the first defined metric for a manifold, xAct automatically converts its mixed indice forms g[-b,c] and g[c,-b] into the delta tensor delta[-b,c], even when attempting to give these as unevaluated inputs in Standard Form (such as when using xPrint).  Is there any way to stop this automatic behavior?

The reason I'm asking is I've found a powerful means to effectively make both metrics "active" when doing bimetric formulations, which could be significantly improved upon if this one "snag" could be overcome.  The method employs MMA's parallel computation feature, running a second local "subkernel" from the master kernel.  In essence, all of the various quantities utilized are defined twice, once on the master kernel and once on the subkernel, and $DistributedContexts = None should be set (as based on the hard fought conclusion that TB and Filippo came to in their threads about using parallelization with xAct...Many Thanks!).  Everything is given the exact same name for both kernels, with the same manifold definition used for both, including the same indices use for both.  The key difference though is that the order of metric definition is reversed between the two kernels, so one is active on the master kernel, and the other is active on the subkernel.  On a kernel where one metric is active, the other one is then frozen.  So for either kernel, xAct dutifully keeps the frozen metric separate from the active one, allowing the full force of active metric operations such as canonicalization on each kernel.  To switch between kernels, SepararateMetric is first run to explicitly separate out the active metric from the as defined "natural" forms of all tensors present, including when contained in any covariant derivatives present.  With the frozen metric already separated, all that is additionally required is to convert (using a simple MakeRule substitution) the raised indice form metric[b,c] of the active metric to its frozen inverse name Invmetric[b,c], and vice versa for the frozen metric's inverse name.  The SeparateMetric and "inverse naming" rules can be combined into a convenient single "Port" command.  The "ported" result can immediately be evaluated in the other kernel, with now the active and frozen metrics reversed.  Keeping the active metrics "straight" is easy since all operations in the subkernel are made using ParallelEvaluate, which return results wrapped in brackets.  I use a custom palette with a ParallelEvaluate template button that has faint gray background, yielding a faint gray background for all ParallelEvaluate entries in the notebook.  Also, I append the palette button ParallelEvaluate command with a Style command that also adds the same background to the output.  So everything in the notebook that is in the subkernel is immediately recognized by the faint grey background, making it obvious at a glance which metric is active for an expression.

With this setup then, the active metric is changed with a single "Port" command to switch between kernels, enabling quick back and forth use of ToCanonical and Simplification for each metric, as well as other active metric based simplifying operations.  One key element of bimetric theories is that a fair amount of the tensors utilized have symmetries based on using either one or both of the metrics to raise/lower the indices of their as defined "natural" forms.  In xAct, these symmetries are "best" given when a tensor is defined, but only the active metric applies.  With only a single kernel used, any symmetries using the frozen metric must be given using additional "symmetry rules" such as symmetrizations.  But these are "marginally effective" for abstract formulations since in many cases covariant derivatives are involved, "masking" symmetries that are present.  With use of the two kernels though, the "dual" definition of a tensor on both kernels allows its symmetry based on both metrics to be specified at definition, with one metric being the active metric for symmetry specified definition on the master kernel, and the other metric being the active metric for symmetry specified definition on the subkernel.  This is powerful since now the symmetry properties of a tensor based on both metrics being active are established, enabling full exploitation of these symmetries during all operations, including those contained in covariant derivatives.  One merely "goes back and forth" between the two kernels to apply all symmetries present, running for instance ContractMetric followed by ToCanonical in each kernel to apply.

With the ability to specify common sharing of variable and function values when using xCoba (using SetSharedVariable and SetSharedFunction), then a very powerful system is yielded to perform both abstract and component valued bimetric formulation, since the xAct system is used with effectively both metrics being active.  The only fly in this ointment is that in its present incarnation, xAct is so "aggressive" in wanting to use the delta tensor when it sees g[-b,c] and g[c,-b] for the active metric g in the master kernel, that this behavior spills over to the subkernel as well.  This occurs even though g is the frozen metric in the subkernel, with the "absolute metric" a the active metric.  This is a problem then since g[-b,c] in the subkernel should be interpreted by xAct as g[-b,-d] a[d,c], not delta[-b,c].  Evidently, conversion of g[-b,c] into delta[-b,c] happens first before anything else, preventing its proper interpretation.  Note that on the other hand, the subkernel active metric forms a[-b,c] and a[c,-b] do not convert into delta[-b,c] automatically, staying in the a[-b,c] and a[c,-b] forms until operated on.  So in the master kernel a[-b,c] and a[c,-b] remain in these forms and properly convert to a[-b,-d]g[d,c] when SeparateMetric is run.  It is only then the active metric for the master kernel that has this problem.  All that is really required is that the "run first" automatic conversion of g[-b,c] and g[c,-b] into delta[-b,c] not happen in the subkernel where it is supposed to be frozen and equal to g[-b,-d] a[d,c], so if it happens in the master kernel where it is active then OK (though I would prefer to stop this behavior altogether).  I would be quite willing to modify the xTensor source code if someone could provide the changes.  I believe this would be a worthwhile endeavor due to the growing importance of bimetric theories.  Yes, there are workarounds, but they aren't pretty, and certainly less convenient.

Thank you in advance for any help.

Regards,

Bill

[Jose]

Hi,

Just remove the corresponding definitions for the metric in question. For example:

In[2]:= DefManifold[M, 4, {a, b, c, d}]

In[3]:= DefMetric[-1, g[-a, -b], cd]

These convert to deltas:

In[4]:= {g[a, -b], g[-a, b]}

Out[4]= {xAct`xTensor`delta[-b, a] , xAct`xTensor`delta[-a, b]}

Unset the definitions for g:

In[5]:= g[a_?UpIndexQ, b_?DownIndexQ] = .

           g[a_?DownIndexQ, b_?UpIndexQ] = .

You need to evaluate that pair for every metric tensor for which you want to eliminate automatic conversion to delta.

Now these stay unevaluated:

In[7]:= {g[a, -b], g[-a, b]}

Out[7]= {g[a, -b] , g[-a, b]}

Note that now with something like g[a, -b] v[b] you will need to use ContractMetric explicitly.

Cheers,

Jose.

[BillN]

Hi Jose,

Thank you so much.  That worked perfectly!

Unsetting the mixed indice definitions for the active metric in each kernel gives the results exactly as you described.  It also stopped the master kernel active metric to delta conversion from "spilling over" into the subkernel as I had described above, which led to erroneous results. I spent a while systematically running through the various cases involving this use of the metrics, with all working as expected on both kernels.  Now the master kernel and subkernel are "mirrors" of each other but with the active metrics reversed.  I never would have thought to do this, so your help has been invaluable.

One minor problem (not a "big problem" like the above one) is that xAct for some reason uses dollarindices in the subkernel when ever dummy indices need to be generated.  This occurs even when either $PrePrint=ScreenDollarIncices or $Post=ScreenDollarIndices is first run in the subkernel (with of course one of these run for the master kernel).  Explicitly using though ScreenDollarIndices when ever a subkernel evaluation is made (applied to an expression within the ParallelEvaluate command), returns an output without dollarindices.  So for some reason, the automatic setup of ScreenDollarIndices for the subkernel is "not taking," even though the output of ParallelEvaluate[$PrePrint=ScreenDollarIncices] is {ScreenDollarIndices}, as expected for this automatic set up on the subkernel.  This is not a "showstopper" though since ScreenDollarIndices can always be added (in a convenient shortened name form) to a ParallEvaluate template button in a custom palette.  Just thought you should know about this.

Regards,

Bill