MC Subtraction term

Dear Stefano,

the file madfks_mcatnlo.inc is precisely where you can set parameters for the MC scale.

Parameters frac_low and frac_upp set the boundaries (in units of the reference scale
sqrt(shat*(1-xi))) of the range where the MC scale is picked.

Parameter scaleMCdelta sets the minimum width (in GeV) of the above mentioned range,
namely if (frac_upp-frac_low)*reference_scale is smaller than scaleMCdelta, the range
gets reset to scaleMCdelta.
Parameter scaleMClow is a minimum safety value (in GeV) for the MC scale.

In order to achieve a 'sharp' MC scale you would thus need to set frac_low = frac_upp = f,
(f of order one, typically) and scaleMC_delta = 0d0. I write 'sharp' in quotes because, as
you correctly say, in this case the MC scale is still dynamical, equal to f*sqrt((1-xi)*shat).

I highly recommend **not** to set dampMCsubt = .false. as this makes the code skip
the part linked to this dampening function, and to use instead what I wrote above in
order to get a 'sharp' MC scale.

To answer your first question, yes, it is reasonable to vary these parameters in order to
study higher-order effects, provided you vary them in a sensible range, as you would do
to estimate resummation-, or renormalisation-/factorisation-scale uncertainties.
Note a technical subtlety: if you modify any *.inc file, it is better if you remove the *.o
files in your process folder (and subfolders as well), in order to be sure the next compilation
will update the objects.

As for your second question, in principle the reference scale could be a fixed scale, with
some caveats/considerations:
- you have to use a scale that is a sensible reference scale for the process you're considering,
  which is up to you;
- using a fixed reference scale and a sharp setup (i.e. frac_low = frac_upp, and scaleMCdelta
  = 0d0) may result in a slightly kinky behaviour in the matching region for some observables,
  in particular in processes, like p p > H, that feature a lot of radiation. This kinky behaviour is
  perturbatively acceptable, in the sense that it is indeed the effect of higher orders and does
  not spoil the formal accuracy of the simulation, but may be undesirable;
- you have to make sure that the replacement sqrt(shat*(1-xi))) --> fixed scale is done consistently
  all over the montecarlocounter.f code. In particular, there are two places where this replacement
  has to be: in subroutine assign_emsca, line 2520, and in subroutine assign_scaleminmax, line
  2551; even in this case, it may still happen (depending on the fixed value you choose) that
  the final SCALUP will be lower than this fixed value due to a resetting at a later stage in the code;
- in processes with jets at the Born level, the picture is complicated, and this sharp scale will
  often be reset (depending on the kind of event and on the kinematics) by dynamical scales
  linked to the jet hardness.

Cheers,
Paolo

Dear Paolo,

Thank you very much for your clear answer. I am trying the options you suggested to implement a dynamically 'sharp' MC scale.

The point is that to study the sensitivity to the MC scale, is easier, at first, to have only one parameter, rather than both mininum
and maximum of the fractional scale.

I am running p p > t t~ production, what does sqrt(shat*(1-xi)) corresponds to in this case?
Does it corresponds to the invariant mass of the ttbar system?

Cheers,
Stefano

Dear Stefano,

> The point is that to study the sensitivity to the MC scale, is easier, at first,
> to have only one parameter, rather than both minimum and maximum of the fractional scale.
Yes, in the dynamically ‘sharp’ case, this would indeed be the ref_scale.

> I am running p p > t t~ production, what does sqrt(shat*(1-xi)) corresponds to in this case?
> Does it corresponds to the invariant mass of the ttbar system?
Yes.

Cheers,
Paolo

Dear Paolo,

thanks again. I tried the fixed scale, but it works slightly worst, so will keep using the dynamic scale.

As as side comment, I found that some observables have sensitivity to these parameters, and I would suggest to include them
in one of input cards, so as to make it easier to vary them, without the need of recompiling the code.

Cheers,
Stefano

Dear Stefano,
your suggestion is very valuable. Indeed we have a private
branch, under development, that implements the shower-scale
variation automatically.
This should become available in a not so far future.
Cheers.
Paolo

On 21 Jan 2015, at 15:06, Stefano Camarda <email address hidden> wrote:

> Question #260776 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/260776
>
> Status: Answered => Solved
>
> Stefano Camarda confirmed that the question is solved:
> Dear Paolo,
>
> thanks again. I tried the fixed scale, but it works slightly worst, so
> will keep using the dynamic scale.
>
> As as side comment, I found that some observables have sensitivity to these parameters, and I would suggest to include them
> in one of input cards, so as to make it easier to vary them, without the need of recompiling the code.
>
> Cheers,
> Stefano
>
> --
> You received this question notification because you are a direct
> subscriber of the question.