Developments since Kira 2.0

Last year we released version 2.0 of the Feynman integral reduction program Kira. In this contribution we first report on changes and new features since then and, secondly, on new features for upcoming releases.


Introduction
The reduction of Feynman integrals to a smaller set of master integrals is a crucial part of highprecision calculations in theoretical particle physics. This can be achieved by using linear relations between integrals as provided by integration-by-parts (IBP) identities [1,2] and Lorentz-invariance (LI) identities [3]. To this end, Kira is an implementation of the Laporta algorithm [4] and was first published in Ref. [5]. The algebraic expressions were solely handled by the computer algebra system Fermat [6]. Last year, we released version 2.0 of Kira [7], which, as headline feature, additionally offers finite field interpolation and rational reconstruction techniques (see Refs. [8,9] in the context of IBPs) provided by the library FireFly [10,11]. There are several other public implementations of the Laporta algorithm, see e.g. Refs. [12][13][14].
In this contribution we highlight some of the new features already implemented since last year's release of version 2.0 in Sect. 2 and then present some of the planned features for upcoming releases in Sect. 3. We assume that the reader is familiar with Kira and refer to Refs. [5,7] otherwise.

New and changed features since Kira 2.0
In this section we highlight some of the new and changed features implemented in the versions 2.1 and 2.2 of Kira: • We introduced a version number for the database. Databases produced prior to Kira 2.1 cannot be used for export jobs with kira2form and kira2formfill unless they are upgraded with the command line argument --force_database_format=fermat|firefly.
Three cases have to be distinguished: 1. If the database was produced with Fermat, use the command line argument --force_database_format=fermat. 2. If the database was produced with FireFly without insert_prefactors, use the command line argument --force_database_format=firefly.
3. If the database was produced with FireFly and insert_prefactors, it cannot be upgraded. Instead, remove the database and rerun the job that produced it. If firefly_saves still exists, most of the computational steps are skipped.
Export jobs with kira2math and kira2file are not affected by this change.
• With the new kira2formfill job the results can now be exported as fill statements to fill TableBase objects in FORM [15].
• The numerators of the rational functions exported with kira2form and kira2formfill are now enclosed by num().
• The prefactors submitted through the option insert_prefactors are now enclosed by prefactor[] when employing kira2math and by prefactor() when using kira2form and kira2formfill.
• We added the option run_initiate: masters to stop the reduction after the master integrals have been identified without writing the system to disk.
• The weight bits for user-defined systems with indexed integrals T[a,b,c,...] are now automatically adjusted. Before, Kira crashed if the weights did not fit into the default representation.
• We changed the output format for the master integrals to make it more readable by both humans and other programs. This mainly affects the output to the console, kira.log, and results/<TOPOLOGY>/masters(.final).
• The command line option --parallel/-p now accepts the arguments physical and logical to exploit all physical or logical cores, respectively. It is still possible to manually choose any number of threads. If the option is given to Kira without argument, it uses physical by default. Under macOS, physical refers to the number of logical cores.
Finally, we emphasize that we opened a wiki at https://gitlab.com/kira-pyred/kira/-/wikis/Home to serve as first contact point for users. It already contains sections about best practice and troubleshooting.

Features in upcoming releases
In this section we briefly present improved and new features for the upcoming releases of Kira.

Faster export of the results
The export performance of the results to different formats, especially for FORM [15], is improved significantly. This is achieved by replacing the pipe to Perl by C++ std::regex. Tab. 1 shows the improvements for the example topo7.

Reorder propagators to increase the performance
The definition of the topology can have an impact on the size of the system generated by Kira and on the performance of the reduction. Not only redefinitions of the propagators can change the performance, even a simple reordering can drastically impact it. In Ref. [16] we described rough guidelines for the topology definition, which we repeat in the following for clarity: 1. Always define top_level_sectors for the topologies. This ensures that sectors are only mapped on subsectors of the defined top-level sectors. If you are trying to find relations by reducing sectors which are higher than those in the physical problem, the higher sectors must be included in the top-level sectors or the magic_relations have to be enabled in order to symmetrize them.
2. If a topology has only one top-level sector, order the propagators such that the sector number is 2 n − 1 (if the sector has n lines), i.e. the propagators at the end of the list appear only as irreducible scalar products.
3. Define the propagators in such a way that propagators have short linear combinations of loop momenta and the shortest linear combinations appear earlier in the list of propagators.
4. Analogously, keep linear combinations of external momenta short with ascending length.

Massless propagators should appear earlier in the list.
These guidelines are based on experience and will not always produce the best definition. However, they should serve as a good starting point. If the topology definition is crucial to complete the reduction, one should run smaller jobs first to experimentally find the preferred definition. In Ref. [17] one of the authors of this contribution encountered some extreme examples in the calculation of four-loop on-shell integrals for the relation of a heavy quark defined in the MS and the on-shell scheme allowing for a second non-zero quark mass in the loops. We show one example topology in Fig. 1. The setup used in Ref. [17] automatically defines its propagators as Figure 1: Example topology from Ref. [17]. The double line represents quarks with mass m 1 , the single line quarks with mass m 2 , and the dashed line massless quarks. Produced with FeynGame [18]. 2 , P 5 = (p 3 − p 4 ) 2 , P 6 = (p 3 + q) 2 , P 7 = (p 2 + p 4 ) 2 , P 8 = p 2 2 − m 2 2 , P 9 = (−p 1 + p 2 + p 3 − p 4 + q) 2 − m 2 2 , P 10 = p 2 3 , P 11 = p 2 4 , P 12 = (p 1 + p 3 ) 2 , P 13 = (p 1 + p 4 ) 2 , P 14 = (p 1 + p 2 ) 2 , (1) where p i are the loop momenta, q is the external momentum, and m 1 , m 2 are the two quark masses. P 3 , P 6 , P 7 , P 12 , P 13 , and P 14 are auxiliary propagators which only appear in the numerators. With this definition, Kira generates 10 204 834 linearly independent equations with 436 973 786 terms in total to reduce the selected integrals and one reduction over a finite field with pyRed takes about 12 771 s. Following the guidelines above and reordering the propagators to only 3 752 490 equations with 57 696 557 terms are generated, corresponding to a reduction by 63 % and 87 %, respectively. The runtime of a reduction with pyRed reduces to 43 s, i.e. the performance increases by a factor of 297. We want to stress that this is certainly an extreme example and the performance gains can even be negligible for other examples.
For the convenience of the users of Kira, we plan to implement the option to reorder the propagators internally, i.e. to allow the internal order to differ from the definition in integralfamilies.yaml. This allows for reaping the potential performance gains without keeping track of the order when communicating with other programs. We plan to implement two versions: first, allow the users to set the ordering manually and, secondly, automatically reorder the propagators according to the guidelines above.

Generate a system of equations for later reduction as user-defined system
With the option run_initiate: input, the generated system of linearly independent equations is stored in the Kira readable .kira format for further processing. In contrast to the existing option generate_input, which was introduced to reduce the memory requirements by considering only a subset of the sectors at the same time, with the option run_initiate: input the user is able to select equations to reduce only requested integrals. One idea is to use these files .kira in combination with additionally generated .kira files containing extra relations provided by the user. The additional relations can be extra symmetry relations, a system of differential equations, or amplitudes.

Set variables to rational numbers and/or choose a prime field
The complexity of reductions can be greatly reduced by setting some or all of the variables to rational numbers. While the result is no longer general, it might be helpful to first reduce the simpler problem to get a feeling for the reduction and the structure of the result. We plan to allow the users to set the variables to rational numbers at different stages of Kira so that, for example, the system can be generated in full generality and then be solved with the variables replaced by rational numbers.
Additionally, we want to allow the users to choose a prime and solve the system one or several times over that prime field. By storing these results to disk, they could then be processed by other programs if the users are only interested in the solutions over specific prime fields but not the algebraic result.

Conclusions
In this contribution we presented the new and changed features already implemented since the release of Kira 2.0 and some of the features planned for upcoming releases. We hope that these, together with the ever-present bug fixes, will improve the experience of users of Kira.