search

gituliar / fuchsia

A tool for reducing differential equations for Feynman master integrals to an epsilon form.
http://gituliar.net
ISC License
14 stars 5 forks source link

NameError: Unknown variable: 'sqrt' #12

Closed gituliar closed 5 years ago

gituliar commented 7 years ago

Let us improve I/O functions, so that Fuchsia deals correctly with matrices which contain sqrt(?) and Sqrt[?] objects.

magv commented 7 years ago

You can add something like [1] to the main branch.

[1] https://github.com/gituliar/fuchsia/commit/58388a97d98021ba5e7c5ddcff7d63a90bbc399c

ChristophDl commented 5 years ago

Is this implemented in the newest version? Unfortunately I cannot get past this error:

NameError: Unknown variable: 'RootOf'

Edit: I should mention that the matrix I am working with does not contain square-roots, but has a high degree in eps and x.

vsht commented 5 years ago

I'm not a fuchsia dev, but from my experience the appearance of square roots might signal that your matrix requires a nonlinear variable transformation before it can be turned into a canonical form. The CPP version of Fuchsia (github.com/magv/fuchsia.cpp) has an option suggest-changevar that will analyze the matrix and suggest the appropriate transformation, if required. Perhaps you could try that first.

magv commented 5 years ago

The original issue here was fixed in a6db3aa544f6dde2f98d00bd18ffd4c42458171f.

What you're seeing is probably due to using --use-maple and a having a polynomial in the denominator that Maple can not solve with just roots -- it returns RootOf(poly, x) in these cases. Probably a spurious pole with a mixture of x and eps, right? Such poles usually happen either because your IBP routine gave you more masters than it should (i.e. there are linear relations between the masters), or because of an unfortunate master selection (i.e. you can choose different masters, and this spurious pole will go away).

Unfortunately the underlying CAS we're using -- Sagemath&Maxima do not have an equivalent of Maple's RootOf (AFAIK), so just importing that function will be of little benefit overall, as the reduction will choke a few steps later.

There is a somewhat better strategy of dealing with such spurious poles: they can be transformed away separately without the need for solving the polynomials. Think of it this way: if choosing different masters can remove this pole, then we know that a rational transformation exists that does it for us. At the moment we don't have it implemented though, and rotating the master selection is what we do in practice.

In any case, these poles is a problem many people have run into (Vladyslav have been asking about it in #16 for example), so I'm bound to fix it at some point. I've opened issue #17 for this, and I'll close this issue since the original problem is fixed.