Oxidation roadmap

[felixhekhorn]

ekore

• ad.u.s.as1 Introduce Rust extension #189
• ad.u.s.{as2,as3} Rustify ekore part 2: ad.u.s.{as2,as3} #369
• ome.u.s.as1 and ome.u.s.as2 + VFNS Rustify ome.u.s.{as1, as2} #385
• recover SV Recover SV, ev method, backwards method #394
• ad.p.s.{as1,as2} Rustify ad.p.s.{as1,as2} #406
• recover solution methods + backward method: step 1 Pass evolution + backwards method internally via int #395, actual implementation Recover SV, ev method, backwards method #394
• ad.u.s.as4 and ad.u.s.as4.fhmruvv just rebranded as ad.u.s.as4, since we will give up the in-house parametrization Rustify N3LO Ad #443
• ad.u.s.*aem* + QED Rustify QED #416
• ad.p.s.as3, ome.p.s.*
• ad.u.t.*, ome.u.t.*
• ome.u.s.as3 -> try to rely on https://gitlab.com/libome/libome

The conjecture is that porting the hard math we get a significant speed up. The LHA benchmarks seem to confirm that. This will also solve the "feature" of the first run taking forever. Once we have feature parity we give up the Python ekore and use the Rust implementation instead.

after that

Mid-term we can aim to replace the whole integration kernel with Rust. This requires more stuff:

• ekopolation crate
  • mirrors interpolation
  • eko crate will depend on that
  • yadism may depend on that
• ekoupling crate
  • for beta functions and their solutions
  • ekore may depend on it (as discussed in Add some pol tests #418 ) if e.g. formulas depend on explicit beta coefficients
  • yadbox may depend on that (or other HEP packages)
• eko crate
  • will hold all solution strategies and all the linear algebra related to that
  • depends on explicit beta coefficients

even after that

• port basis_rotation? PineAPPL may depend on that or other HEP packages
• move integration routine to Rust? https://github.com/alecandido/quad can potentially meet Vectorial integration #54