Change in default scale choice for interference contributions

Hi,

The main reason to avoid the CKKW scale for interference is that the CKKW scale is using the channel information to restrict the merging and that the channel information is related to the amplitude square. So when you compute only interference, the full algorithm that we use for determining the scale is (to my point of view) badly motivated and justify why I did change the default.

The second reason is that if you want to compare the following sigma_{sn+np} = sigma_sm + sigma_np + interference
this is not possible to do it with the CKKW scale due to the dependency in the channel and therefore you are also needed to move to a pure kinematic choice.

> Looking into the code, it looks like this case is triggered by checking for the presence of “^2” in the process definition (see e.g. around line 3596 in madgraph/various/banner.py of 2.9.9).

I have not checked the code but this makes sense to use this as a trigger even if you can select non interference term with that syntax (but typically you could use simpler syntax for selecting those). Additionally, putting HT/2 "too often", would not worry me too much , especially since this is our default at NLO.

>We believe that setting “dynamical_scale_choice=-1” (CKKW-style clustering) would be an appropriate scale choice for this matched/merged computation. (We use MLM and Pythia 8.) As a result of our process definition, however, we seem to be accidentally provoking a switch to “dynamical_scale_choice=3” (i.e. HT/2) instead.

In general, using that scale for MLM makes a lot of sense. Indeed, in presence of MLM, all radiation out of the "born" will have their own scale. So it makes sense to use the same algorithm to choose the renormalization scale for the coupling associated to the born.
But at the same time, this is not a problem if you pick Ht/2 (or some other scale choice) for those.

> Can you confirm that, for our case, remaining with the original default of “dynamical_scale_choice=-1” is a valid way forward?
> Furthermore, are there any theoretical arguments that would indicate that “dynamical_scale_choice=3” is a better, or significantly worse, scale choice for our process?

I would always argue that any scale choice is a valid way forward as long as you
1) include an estimation of the theoretical uncertainty associated with it
2) take a look (at least once) to other dynamical scale choice to be sure that you are still in agreement with other choice --given the large error-- (and I would expect that scale uncertainty are super-large for loop-induced process)

On the theory side the scale is higher order effect and by using dynamical scale, you are trying to capture higher order effect by keeping only the "easy" to catch effect. But "by construction" any reasonable choice should be within theoretical uncertainty of each other, and you are not magically gaining accuracy by doing so.

Cheers,

Olivier