Cadabra Q&A - Recent questions and answers in Bug reports

Answered: The mystery of meld

Thu, 04 Dec 2025 21:09:24 +0000

The first issue is now fixed on the devel branch.

Strange behavior young_project_product with zoom

Wed, 22 Oct 2025 16:56:49 +0000

Hello, I found a peculiar effect of Young's projection when applied to part of an expression after using zoom. For example:

{a,b,c,d,f,e, m,n,k,l,q,r,s,t,u,v,w,x,y,z,m#, n#}::Indices(values={0..3}, position=independent);

\nabla{#}::Derivative.
h_{m? n?}::Metric.
h^{m? n?}::InverseMetric.
h_{m? n?}::Symmetric.
h^{m? n?}::Symmetric.
F_{a? b?}::AntiSymmetric.
F^{a? b?}::AntiSymmetric.
\nabla_{a}{F_{b c}}::TableauSymmetry(shape={2,1}, indices={0,1,2});
\nabla_{a}{\nabla_{b}{p}}::Symmetric;

and I have some long expression:

expr := 1/2 F_{a b} F_{c d} R \nabla_{e}(p) \nabla_{f}(p) h^{a c} h^{b e} h^{d f}
-F_{a b} F_{c d} \nabla_{e}(\nabla_{f}(p)) \nabla_{m}(\nabla_{n}(p)) h^{a c} h^{b e} h^{d f} h^{m n} 
+ F_{a b} F_{c d} \nabla_{e}(\nabla_{f}(p)) \nabla_{m}(\nabla_{n}(p)) h^{a c} h^{b e} h^{d m} h^{f n}
-F_{a b} F_{c d} R_{e f} \nabla_{m}(p) \nabla_{n}(p) h^{a e} h^{b m} h^{c f} h^{d n}
-2F_{a b} \nabla_{c}(F_{d e}) \nabla_{f}(\nabla_{m}(p)) \nabla_{n}(p) h^{a f} h^{b n} h^{c d} h^{e m} 
+ F_{a b} F_{c d} \nabla_{e}(\nabla_{f}(p)) \nabla_{m}(\nabla_{n}(p)) h^{a e} h^{b m} h^{c f} h^{d n} 
+ F_{a b} \nabla_{c}(F_{d e}) \nabla_{f}(\nabla_{m}(p)) \nabla_{n}(p) h^{a c} h^{b d} h^{e f} h^{m n};

And I want to simplify terms with \nabla{a}{F{b c}}:

zoom(expr, $Q?? \nabla_{a}{F_{b c}}$);
expr2 = take_match($@[expr2]$, $Q?? \nabla_{a}{F_{b c}}$);
canonicalise(young_project_product(expr2));

For expr I get - 4/3 F_{a b} \nabla_{c}(F_{d e}) \nabla_{f}(\nabla_{m}(p)) \nabla_{n}(p) h^{a f} h^{b n} h^{c d} h^{e m} but for expr2 I get

- 8/9 F_{a b} \nabla_{c}(F_{d e}) \nabla_{f}(\nabla_{m}(p)) \nabla_{n}(p) h^{a f} h^{b n} h^{c d} h^{e m}

Answered: vary behaves in an odd way

Mon, 06 Oct 2025 20:34:44 +0000

The trivial cases always slip the net somehow... Now fixed on the devel branch, will go into 2.5.16. Thanks for reporting.

Answered: plot example on p. 51 of The Cadabra Book require range

Mon, 21 Jul 2025 17:05:48 +0000

For the range deduction to work you need to use the devel branch; this has not made it to the master branch yet but slipped into the docs inadvertedly.

You are correct about the samples parameter not being fed through correctly; I have opened https://github.com/kpeeters/cadabra2/issues/371 to keep track of this. Thanks.

Answered: \dot command not displayed correctly

Tue, 15 Jul 2025 11:10:52 +0000

Maybe I don't write it correctly but it's not working for me

can you show me the complete line ?

Answered: Regex not working

Sun, 13 Jul 2025 20:15:49 +0000

If you have a fix please open an issue in github and attach a fix (or open a pull request).

(Regex is a feature I almost never use anymore, and was written before I started introducing rigid tests, so this does not surprise me at all).

Answered: execution problems

Tue, 08 Apr 2025 13:33:19 +0000

I don't think that we can make this work again, and I actually don't think this worked as you thought before. The python packaging logic is so terribly convoluted and broken that it is probably not a good idea to try to install Cadabra in CMAKE_INSTALL_PREFIX that does not also have the python stuff. Previously, it would just install half in /Users/leo/tmp2/bin/ and the python stuff elsewhere in /opt/homebrew/, I think.

Just sorting this out has probably already taken at least 30% of the Cadabra development time (with packaging for Windows the remaining 70%...) so it is unlikely that I wlll find the energy to give this another attempt soon.

If you just want to test, create a Python virtual environment and install Cadabra while you have that active.

Answered: cadabra2python seg fault

Tue, 08 Apr 2025 09:39:48 +0000

Now fixed in the devel branch.

Answered: curly-braces and lost indices

Tue, 08 Apr 2025 07:34:53 +0000

Yes, the general advice is to not sprinkle curly braces around if you don't need them. I agree though that this is unexpected and should at least throw an error. I have added this to the issue tracker so it doesn't get lost, https://github.com/kpeeters/cadabra2/issues/355.

Answered: simple substitute hits wrong target

Tue, 08 Apr 2025 07:28:47 +0000

You smash a bug and it appears somewhere else... This one was caused by fixing a related issue just after X-mas (I blame Santa). Hopefully it is now finally gone. Pushed a fix to the devel branch. Thanks for reporting this!

Answered: Canonicalise Kernel crash

Fri, 27 Dec 2024 11:57:57 +0000

The presence of those squares (e.g. (\partial_{t}{p})**2 trips canonicalise. In general, this algorithm cannot deal with powers; you have to write them out first with expand_power if you want this to work. I will add a test to canonicalise to prevent it from attempting to canonicalise these expressions.

Answered: c++lib fails to compile

Wed, 11 Dec 2024 08:45:09 +0000

Thanks! I have pushed changes for this to the devel branch, and have also added it to the CI pipeline so the c++lib build process is tested on every commit; hopefully that will prevent this from getting out of sync again.

There are not many people that I am aware of who use Cadabra's c++lib. Care to say a few words about what you are trying to do with it?

Answered: Kronecker delta wrong output in 2D

Tue, 10 Dec 2024 21:05:35 +0000

Ouch. The code responsible for this bug was about 10 years old, did not have the appropriate tests, and indeed produced nonsense when the range of the integer was symbolic. Thanks for reporting this.

I have pushed a fix to the devel branch on github; this will go into 2.5.10 to be released soon.

Answered: collect_factors / simplify with AntiCommuting objects

Thu, 21 Nov 2024 20:39:59 +0000

That simplify butchers the expression is expected, as no info about (anti-)commutativity currently gets passed through the sympy bridge. However, collect_factors does not use sympy and should know better. I have opened an issue on github to keep track of this, https://github.com/kpeeters/cadabra2/issues/324 .

Answered: sympy(?) errors parsing nested derivatives?

Tue, 01 Oct 2024 07:23:06 +0000

That problem comes from the fact that you wrote \sin\phi, instead of \sin(\phi). In Cadabra you have to group function arguments. (Of course I agree the error is useless and this should be caught earlier).

Answered: \partial_\theta causes infinite loop(?) in server

Mon, 30 Sep 2024 09:58:40 +0000

I guess you have your answer there: add braces. In general, Cadabra is less forgiving about not wrapping arguments in braces, so just do it always.

Cadabra should not hang of course, will investigate. I have opened an issue at https://github.com/kpeeters/cadabra2/issues/312.

Answered: Gtk error messages on startup.

Mon, 30 Sep 2024 07:15:18 +0000

I may need to see if those gtk modules should be included in the AppImage too (I have not done a lot of testing with the AppImage on systems that are truly bare, without an existing gtk installation).

The connection to server failed message happens when you restart the kernel or load a new notebook (which restarts the kernel too). This kills the existing cadabra-server first, and the client then reports that. I could probably remove that error as it sounds more alarming than it is.

Answered: Cycle freeze

Thu, 26 Sep 2024 17:01:38 +0000

I cannot reproduce this. Which "today's update" are you talking about? I did not make any new release. What is the version and build number? (start the command-line cadabra2 and look at the first line of output).

Answered: A bug of Accent

Thu, 01 Aug 2024 08:51:17 +0000

Hi Eureka.

Firstly, let me point that a semi-colon is missing at the en d of the third line. So, the correct code should be

{a,b}::Indices(vector).
\delta{#}::Accent.
ex := \delta{A^{a b}+B^{a b}};

Then, let me clarify that (to my understanding) accents are a way to differentiate symbols, i.e. it has no further properties. Why is this important? Perhaps your expression should be written as

ex := \delta{A}^{a b} + \delta{B}^{a b};

If you are expect your accent to have linearity property, give assign the property of Derivative, i.e.

\delta{#}::Derivative.

If you use the Derivative property instead of the Accent, you could apply the distribute algorithm in your original expression

{a,b}::Indices(vector).
\delta{#}::Derivative.
ex:=\delta{A^{a b}+B^{a b}};
distribute(ex);

Cheers, Dox.

Answered: substitute gives incorrect value on scalar expression

Tue, 18 Jun 2024 06:21:38 +0000

Good catch, stupid error, now fixed.

Answered: LaTeXForm fails in version 2.5.2

Tue, 18 Jun 2024 05:46:42 +0000

Properties use round brackets for their arguments, no matter how much recent C++ committees may have confused your brain with that.

Dx{#}::LaTeXForm("Dx").

works. The error message could probably be nicer, I agree.

Answered: location of bracket blocks distribute

Tue, 11 Jun 2024 14:24:28 +0000

This has been reported a number of times now, so it's time to do something about it. Now fixed in github (2.4.5.9): a newline will act as a single whitespace character and hence turn your bah into bah: = A (B+C).

Answered: leading scalar expression blocks canonicalise

Tue, 11 Jun 2024 14:16:31 +0000

This was because canonicalise was a bit too careful. If a term in an expression contains a sum as factor, and that factor has indices, then you have to distribute first. E.g.

(A_{m n} + B_{m n}) R_{p q}^{m n};

But canonicalise was rejecting any sums inside a factor, like in your example, even if it has no indices. That's not necessary.

Now fixed in github (2.4.5.9).

Answered: imp package was removed from python 3.12

Mon, 20 May 2024 12:53:29 +0000

Can one of you please test the current 2.4.5.8 now on github? You will most likely need to clean your cadabra notebook cache (Tools > Clear package cache).

Answered: bug of unwrap

Tue, 23 Apr 2024 09:46:30 +0000

Hi Eureka.

I don't thing it is a bug, just a misunderstanding of the philosophy of cadabra.

According to the unwrap documentation:

Derivatives will be set to zero if an object inside does not depend on it.

Hence, the command is not a computational aid... I mean, stricktly speaking you have not declare any dependence for u! So the algorithm set its derivative to zero.

My advice would be to use first a substitution rule, e.g.

rl := \partial_{u}{u} -> 1;
ex:=\partial_u{u f};
product_rule(_)
substitute(ex, rl)
unwrap(ex);

or if your calculation is "simple", call the sympy module:

from cdb.sympy.calculus import *

ex := u f;
d_ex = diff(ex);

NOTE the absence of the colon in the last assignation (it is a python assignation not a cadabra one).

Hope this would be useful!

Cheers, Dox.

bug of stop evaluation

Sun, 21 Apr 2024 11:50:54 +0000

When I use stop evaluation to stop evaluation, but it never works.

bug of function keep_weight

Wed, 17 Apr 2024 09:38:20 +0000

The following code:

{u,v}::Weight(label=field,value=1);
ex:=(u v)**{1/2};
keep_weight(_,$field=1$);

I get the wrong result $0$, while the following code

{u,v}::Weight(label=field,value=1);
ex:=(u v)**{1/2}+u u;
keep_weight(_,$field=1$);

work fine. It seems a bug.

Answered: The output is lost in WSL2

Wed, 17 Apr 2024 07:50:59 +0000

If you know the absolute path to the file you can always use that in the open call, no? What do you mean with "I can't get the output there"? Does the open call fail or does reading from that file fail?

Answered: unwrap of partial derivatives

Thu, 28 Mar 2024 08:32:42 +0000

Hi Arina. Great question!

I believe that the mismatch between the expected and actual behaviour of the unwrap algorithm is due to the "phylosophy" of CADABRA, i.e., it is a software centred in manipulation rather than calculation.

The "calculation" component of CADABRA came with the release of version 2.X, through the interaction with PYTHON (in particular with sympy).

Note that if instead of unwrap, you pass your expression to SYMPY, using map_sympy, as follows

map_sympy($\partial_{t}{a}$);

you get the expected result (of executing a calculation).

Hope this can help you!

UPDATE

I understand the point in your comment, hahaha.

It seems to me that unwrap is useful to "move objects out" because they are constant.

Example

In General Relativity the metric is covariantly constant, but its partial derivative is nonvanishing in general. So, you should assign a dependence on the partial derivative but not of the covariant derivative.

{l,m,n}::Indices.
\partial{#}::PartialDerivative.
\nabla{#}::Derivative.
g_{m n}::Depends(\partial{#});
\Psi::Depends(\partial{#},\nabla{#});

Now if you define the derivatives of $g \Psi$, and unwrap, the difference is noticeable.

ex1 := \partial_{l}{ g_{m n} \Psi };
unwrap(ex1);
ex2 := \nabla_{l}{ g_{m n} \Psi };
unwrap(ex2);

Answered: meld returns zero where it shouldn't?

Thu, 08 Feb 2024 18:44:43 +0000

There is a bug in the logic that sets terms to zero when overlapping symmetry sets contain multiple identical indices. I have disabled that logic in meld for now, as I don't have time to think this through carefully. It shouldn't influence anything else as this was strictly a shortcut to find zeroes in particular situations, which meld will still find now, only slower.

Answered: Operations with fractional powers of negative numbers

Tue, 16 Jan 2024 19:15:49 +0000

It's not the fractional power, it's the '-1' inside the square root (any factor except '+1' leads to the same problem). This indeed should have returned unevaluated, I'm not sure why I left the hard assert in the code which makes it bail out, other than to indicate to myself that this code was unfinished. I have filed an issue so we do not lose track of this again, https://github.com/kpeeters/cadabra2/issues/290.

The sympy bridge can help with this,

simplify($(-X)**{-5/2} X$);

returns what you want.

Answered: Interaction between 'canonicalise' and vector spinors

Thu, 11 Jan 2024 20:02:55 +0000

Well spotted. Effectively, what went wrong here is that the canonicalise function would incorrectly treat \psi^a \bar{\psi^b} as having the spinor line contracted (so as if the Dirac bar would be sitting on the first factor). The niceties of implicit notation...

I have pushed a fix to github now. If you need an updated binary package let me know.

Answered: remove_zero_components and components_to_subrule fail with AttributeError

Tue, 09 Jan 2024 08:46:02 +0000

You have a mixture of two installations, one in /usr/lib/python3.10/dist-packages/ and one (packages only) in /home/gpn/.config/cadabra_packages/.

I would remove (or temporarily move into a different location) the /home/gpn/.config/cadabra_packages/ folder and then try again.

Answered: Negative powers of 0

Tue, 12 Dec 2023 20:02:48 +0000

Picky ;-) But yes, you are right. I have pushed a fix to github (it will now raise an exception).

Answered: meld sets to zero when it shouldn't?

Wed, 06 Dec 2023 14:21:02 +0000

Hi GNP. I was playing with your code (thank you for sharing it!), and I noticed that the problem is not with the meld algorithm, but with the previoussort_product.

If you comment the sort_product the result of both codes is the same (and nontrivial).

Cheers, Dox.

Answered: Manually fiddling with multiplier on \sum

Fri, 01 Dec 2023 16:39:26 +0000

If you modify the tree, you are required to leave the tree in an internally consistent state. One of the conditions is that the multiplier of a \sum node is not allowed to be anything except 1.

On the C++ side there are various functions in Cleanup.cc|hh which help to turn an inconsistent tree into a consistent one, but these are not exported to Python. It should not be too hard to export these as it's all individual functions.

The reason why ex2:=@(ex) works is that any new expression input will run the cleanup routines.

(In all honesty, apart from Dom, you are the first person I am aware of who has done some serious work like this on the Python side, so there are bound to be other missing pieces).

Answered: WeightInherit type=additive thinks operator is \sum

Wed, 29 Nov 2023 16:40:25 +0000

Yeah, this is fishy. The drop_weight algorithm is trying to be clever to determine where it can apply, and then fails miserably in this situation. Your particular problem can probably be solved by not treating f as a sum with one term, but the general problem is more complicated.

What we really want is to restrict this algorithm to "terms in a sum". But the question is now whether that sum is allowed to appear somewhere deeper down the tree, e.g. in f(x+y+z) if the full expression reads f(x+y+z)+g(a+b). I obviously didn't think this through fully. Suggestions welcome.

To a certain extent this issue also arises for zoom: when is a non-sum node to be treated as a single-term sum? zoom ignores this altogether (and never works except in an explicit multi-term sum).

Answered: substitute crashes with empty replacement rule

Sun, 26 Nov 2023 20:01:05 +0000

Now fixed, thanks.

Answered: Bug with Ex.matches() for indices in opposite positions

Sun, 26 Nov 2023 20:00:53 +0000

Pattern matching has a lot of different branches to handle these days... The underlying C++ matcher returns a variety of more subtle answers (not just true or false) and I did not map that to true/false correctly.

Now fixed in github.

Answered: Empty expressions fail to match

Wed, 22 Nov 2023 18:39:41 +0000

Thanks, this is now fixed in github.

Answered: Problem with substitute and powers

Tue, 14 Nov 2023 22:26:30 +0000

This is fixed in 2.4.5 which is now on github. If anyone needs a binary package for a system other than Ubuntu 22.04 (which is already available from the download page), let me know.

Answered: Substitution after map_sympy(*, 'simplify')

Wed, 25 Oct 2023 13:30:08 +0000

Ah, that's a good one. Internally, cadabra always writes X**(0.5) even when you write \sqrt{X}. But somehow this canonicalisation does not get applied when the \sqrt{X} comes back from Python. And then the substitute does not match anymore.

This requires a cadabra fix. It may be possible to convince sympy to output as X**(0.5) as a temporary workaround; I don't know off the top of my head.

Answered: InverseMetric is not symmetric?

Tue, 24 Oct 2023 08:47:40 +0000

Hi GPN.

I was not able of reproducing your results. Let me show you my trial code.

First, I assign some basic properties:

{\mu,\nu}::Indices;
g_{\mu\nu}::Metric;
g^{\mu\nu}::InverseMetric;

Then I check if the inverse metric is symmetric:

if Symmetric.get($g^{\mu\nu}$):
    print("True")
else:
    print("False")

I'm getting that it is True!

Just as a cross check I ask if it is antisymmetric:

if AntiSymmetric.get($g^{\mu\nu}$):
    print("True")
else:
    print("False")

And I got False!

If you are not getting the same results it might be that you are using an older version of the software, were the inheritance of the symmetries was buggy or miscompiled.

Regards, Dox.

Answered: function evaluate output a wrong order of SelfAntiCommuting objects

Fri, 06 Oct 2023 11:04:19 +0000

The evaluate algorithm does not preserve the order of factors in a product at present. I am working on a fix for this; if there's anything new to test/try I will report here.

Answered: Module "cdb.core.component" cannot be imported

Fri, 08 Sep 2023 17:40:08 +0000

Sorry for the wait. Just to explain the logic: this function get_component used to be implemented in Python (the commented-out bit you noticed), but was at some point rewritten in C++ for a number of reasons. Since then, the cdb.core.component Python module just imports cdb.core._component (with underscore). This is a separate C++ library, which should have been installed with the build, but either wasn't, or is not in a path where Python looks for it.

I cannot reproduce it on my macOS machine either, but will do some digging on a clean machine to see what might be the problem (Python search paths are notoriously tricky to get right across multiple platforms).

Autocomplete on Jupyter Notebook acting weird

Tue, 25 Apr 2023 11:04:30 +0000

Whenever I try to use autocompletion on Jupyter notebooks it always autocompletes with "a.echo1" or by appending "ho1" to the last "a.echo1" it autocompleted. Has autcomplete been integrated in the Jupyter kernel yet or is there something wrong with my setup? Thank you

Answered: eliminate_metric - avoid partial differential

Thu, 06 Apr 2023 08:09:06 +0000

I know that Kasper already answer the question, but I'd like to comment some additional points:

The metric should depend on the partial derivatives (perhaps the covariant derivative, if you are working with nonmetricity).
It is useful to denote the indices of the metric as subindices, with the _ sign, e.g. g_{m n} instead of g{m n}. Same for the Kronecker delta and the derivatives.
The eliminate_metric algorithm requires an argument, in this case either (test), or the customary (_) to apply it to the pravious expression.

The modified code

{x1,x2,x3,x4}::Coordinate;
{k,l,m,n,p,q,r,s,t}::Indices(position=fixed,values=[x1,x2,x3,x4]);
\nabla{#}::Derivative;
\partial{#}::PartialDerivative;
g_{m n}::Metric;
g^{m n}::InverseMetric;
g_{m}^{n}::KroneckerDelta;
g^{m}_{n}::KroneckerDelta;
{g_{m n},g^{m n}}::Depends(\partial{#});
test := Q^{s}_{r m n} -> g^{s k} \partial_{r m}{g_{k n}};
eliminate_metric(_);

Answered: Incorrect Derivative Free Index Behaviour For User-Defined Symbols

Sun, 12 Mar 2023 18:33:04 +0000

You cannot use x_\mu or x_\m in the derivative like that. Current github HEAD will report $x_\mu$ and $\mu$ (twice) as free indices in both cases. However, if you use

D_{\mu}{ \theta_\mu }

or in the 2nd case

D_{\m}{\theta_\m}

then things work and (again with current github HEAD) will report no free indices.

Please let me know if this is still a problem with github HEAD (2.4.3.5).

Answered: Broken link in manual: `Weight`

Thu, 16 Feb 2023 08:32:45 +0000

Thanks, now fixed.

Answered: exponents problems

Mon, 13 Feb 2023 15:05:56 +0000

Use a substitution like

 substitute(ex, $\exp(A??) \exp(B??)-> exp(A??+B??)$)

Add the , repeat=True if necessary to make it repeat the process until the expression no longer changes.