Welcome to Cadabra Q&A, where you can ask questions and receive answers from other members of the community.
0 votes

Hi Troops,

I've noticed a change in the format of the output from an evaluate command. If you run the following code through Cadabra you will notice that the format of the output will change when the -> in the replacement rules for Chr and Rabcd are replaced with an = sign. Here is the code (sorry its a bit long)

{r,t,\phi,\theta}::Coordinate;
{\mu,\nu,\rho,\sigma,\lambda,\kappa,\chi,\gamma#}::Indices(values={t,r,\phi,\theta}, position=independent);

\partial{#}::PartialDerivative;

g_{\mu\nu}::Metric.
g^{\mu\nu}::InverseMetric.

gab := { g_{t t} = -(1-2 M/r),
         g_{r r} = 1/(1-2 M/r),
         g_{\theta\theta} = r**2,
         g_{\phi\phi} = r**2 \sin(\theta)**2 }.

# change the -> to = and note the change in the format of the output

Chr := \Gamma^{\mu}_{\nu\rho} ->
       1/2 g^{\mu\sigma} (  \partial_{\rho}{g_{\nu\sigma}}
                          + \partial_{\nu}{g_{\rho\sigma}}
                          - \partial_{\sigma}{g_{\nu\rho}} ).

Rabcd := R^{\rho}_{\sigma\mu\nu} ->
         \partial_{\mu}{\Gamma^{\rho}_{\nu\sigma}}
        -\partial_{\nu}{\Gamma^{\rho}_{\mu\sigma}}
        +\Gamma^{\rho}_{\mu\lambda} \Gamma^{\lambda}_{\nu\sigma}
        -\Gamma^{\rho}_{\nu\lambda} \Gamma^{\lambda}_{\mu\sigma}.

complete   (gab, $g^{\mu\nu}$)

evaluate   (Chr, gab, rhsonly=True);

substitute (Rabcd, Chr);

# uncomment next line with -> in rules above and Cadabra will hang

# evaluate (Rabcd, gab, rhsonly=True);

A small change in formatting is not really a problem but if you keep the -> sign and uncomment the last line then Cadabra will hang (forever).

I noticed this behaviour first in Cadabra 2.1.7 (build 1315.aee1cc86f dated 2017-11-21). However for Cadabra 2.1.7 (build 1296.62c41f3b6 dated 2017-11-14) the output format was unchanged when using either -> or = and also it didn't hang.

The culprit seems to be the code in evaluate::dense_factor. The old version of evaluate::dense_factor in (build 1296.62c41f3b6) did nothing (it's effectively a null-op). In the new version (build 1315.aee1cc86f) the evaluate::dense_factor code is non-trivial (i.e., not a null-op). When I comment-out just this code in (build 1355.89440da2c) everything works as it should. The code does not hang and the old format is recovered.

Cheers, Leo

in Bug reports by (1.6k points)

1 Answer

+1 vote
 
Best answer

I have fixed the 'arrow vs equals' issue on github now (the 'rhsonly' did not apply to '->' rules, so if you used an arrow, evaluate would apply to the lhs too).

The dense_factor thing makes rules write out components of tensors for which there is no rule at all. So you can do

{r,t}::Coordinate;
{m,n}::Indices(values={r,t});
ex:= A_{m n} B^{m n};
evaluate(ex, $B^{t r}=1, B^{t t}=3$);

to get $A_{t r} + 3 A_{t t}$, without having specified that you want to keep all components of $A_{m n}$. Of course, this also has the consequence that if you ask it to evaluate an expression which contains $R_{a b c d}$ without a rule for the components, it will happily write out all the possible combinations of $a,b,c,d$ index values. I think that's what makes things choke somewhere (it still works for $\Gamma$ in your example), but will investigate a bit further if there is something else going wrong.

by (76.7k points)
selected by

Ah, now that is a nice feature (not having to specify a rule). Looking forward to the fix. Cheers, Leo

...