Prepare extension of DGLAP to QED

[felixhekhorn]

No description provided.

[felixhekhorn]

@niclaurenti please push our changes! we forgot ...

[alecandido]

I discussed with @felixhekhorn and I believe we need a different and less random naming scheme for our new basis, and then even for the anomalous dimension.

Basis of flavor space

I propose something like the following:

• gluon is g (g in code), and I guess this is just fine
• Sigma and V are untouched, that's fine (as usual in code they are S and V)
• photon might be \gamma or photon (and respectively ga or ph in code)
  • I personally prefer \gamma and ph, but it's incosistent and we can discuss
• \Delta Sigma and \Delta V of Stefano are nice names for me, but if we want to start with the correct letter, I'd say let's use Sigma_\Delta and V_\Delta (in code they might be Sdel and Vdel, or even Sdelta if preferred)
• about non-singlet I'd propose to use meaningful names: V_{u,3}, T_{u,3}, V_{u,8}, T_{d,8}, V_{d,3}, T_{d,3}, V_{d,8}, T_{d,8}, (in code Vu3, Td8, ...)
  • the idea of Tu8 is that is doing the same of T8, but only with up-like quarks (has the same coefficients for the first, second, and third elements of the family)

Basis for operators

I'd like to keep the anomalous_dimension_basis, even if we can keep only the idea, and has to be extended to QEDxQCD.
In general, we have many more coupled elements, so to me it makes sense to name them consistently with a 2-tuple.

In order to have few complicated objects at bottom level, we can even replace strings with our beloved evolution pseudo-PIDs and similar:
https://github.com/N3PDF/eko/blob/e98971aa2e6457cfd4bb834cf6192a79f5a4aa07/src/eko/basis_rotation.py#L62-L67

I propose to use 11xx, 12xx, 13xx, 14xx for the new families (and leaving a gap on 0xxx, you never know).

The only problem is how to name sectors like nsp, nsm, and nsv. I would say it's not clever to name out of a single random representative, so I would assign their own names.
Since we are looking for numbers, we can assign something in the 1xxxx range, keeping it well separated from the linear basis, and still fitting in two bytes (<6.5e4), if ever needed.
Names to be assigned to the diagonal elements in the decoupled sector are simple: nspu, nspd, nsmu, ... .

P.S.: for the numbers to put in the 2-tuple, we can decide to put both the same, (12345,12345), or to put a 0 in the second, (12345,0), to signal that it is not an to be intended as a diagonal element of a coupled sector (note that 0 is not a valid PID for us, since we uniquely define gluon as 21).

Specs

All these mappings between names/objects and numbers have to be specified both in the docs, and in the code (namely in eko.basis_rotation, that we might consider to rename eko.bases or eko.flavor at some point), in order to allow for automatic conversions later.

[niclaurenti]

@giacomomagni @alecandido We are proposing to change the identification of the matrix of the element in the DGLAP singlet matrix by a tuple of strings: for example ("S", "g") to select the singlet from gluon contributions.
We believe it to be more readable than having an arbitrary number assigned.
This is a conflict with pull request #91 .
What should we do?
We also ask if we should split the pull request in two parts: the preparation here and the actual extension to QED.

[alecandido]

We also ask if we should split the pull request in two parts: the preparation here and the actual extension to QED.

Before get to the end :) The moment it is consistent and it's quite a substantial update, then it might make sense to immediately merge, as you're saying.

[giacomomagni]

@giacomomagni @alecandido We are proposing to change the identification of the matrix of the element in the DGLAP singlet matrix by a tuple of strings: for example ("S", "g") to select the singlet from gluon contributions. We believe it to be more readable than having an arbitrary number assigned. This is a conflict with pull request #91 . What should we do? We also ask if we should split the pull request in two parts: the preparation here and the actual extension to QED.

Hi @niclaurenti , I agree that the best is to spit this PR and implement this update separately to the QED ad (so will be faster). This method is more general than what I did in #91, so I can drop that one and merge the updated develop there.
Can we pass integers (pids) to numba instead of string? This will optimise our usage of numba.

[alecandido]

About numba optimization: can you provide a snippet showing that the thing with str is slower that the same one with u1? (and maybe even u2) @giacomomagni

Furthermore, as foreseen, it is not a great idea to merge everything in feature/qed, because for example this addition @giacomomagni will like to merge into its branch, that of course is based on develop, and not on feature/qed.
Both the changes in this PR and in #89 are non-breaking, so let's merge this in feature/qed, and immediately feature/qed in develop.

Even the introduction of anomalous dimensions will be non-breaking, so also the next PR will be merged into develop.
The only problem will come when we'll try to add an actual solution for QED, and so that PR will have to be self-contained.

[giacomomagni]

About numba optimization: can you provide a snippet showing that the thing with str is slower that the same one with u1? (and maybe even u2) @giacomomagni

I read it here

Furthermore, as foreseen, it is not a great idea to merge everything in feature/qed, because for example this addition @giacomomagni will like to merge into its branch, that of course is based on develop, and not on feature/qed.
Both the changes in this PR and in #89 are non-breaking, so let's merge this in feature/qed, and immediately feature/qed in develop.

yes indeed I'd prefer to merge into develop

[alecandido]

I read it here

Thank you for the reference, it contains the snippet I was looking for. Since it looks like that str comparison is one order of magnitude slower than int comparison, it might be worth to replace str with u1, keeping the translation in basis_rotation (so it's easy to interpret the moment we need).

Most likely it's not the most expensive operation we're doing, but either we profile and we confirm that it is the case, or if we're not going to investigate, better to replace in case of doubts.

[felixhekhorn]

Most likely it's not the most expensive operation we're doing, but either we profile and we confirm that it is the case, or if we're not going to investigate, better to replace in case of doubts.

yes, let's replace with integers ...

[giacomomagni]

Most likely it's not the most expensive operation we're doing, but either we profile and we confirm that it is the case, or if we're not going to investigate, better to replace in case of doubts.

yes, let's replace with integers ...

We should do this also for ModEv, since we will have method1 and 2

[niclaurenti]

We want to close this pull request to have this in develop and continue our implementation