NLO Multi-leg

From LesHouches11Wiki

Jump to: navigation, search

NLO Multi-leg


Update of BLHA accord October 2012

 - Suggestions from Valery and Simon

Summary of suggestions until October 29:

Passing Parameters:

Everybody seems to agree that a function OLP_SetParameter should be introduced.

  • Rikkert (for MadFKS & aMC@NLO):

- suggests to use the keywords defined by the UFO format instead of defining new ones.

I would support this suggestion.

- suggests that this would make OLP_GetParameter obsolete because it guarantees consistency within a certain EW scheme

I would still stick to OLP_GetParameter, because the option not to use UFO model files should still be possible, and in this case it is a useful consistency check.

Ansgar, to answer your question: the proposal was that OLP_GetParameter() would report the inconsistency for each parameter individually,
i.e. for both alpha and GF if they are inconsistently set.

- remarks that OLP_SetParameter() makes the arguments \mu and \alpha_s(\mu) in OLP_EvalSubProcess obsolete.

We need to agree on whether to leave them in there or not.

  • Simon and Valery (NJet)

- suggest to declare parameters as dynamic at the level of the order file already:

The OLP can then indicate whether particular dynamic settings are supported or not. For this purpose we propose a new keyword: DynamicParameter "PARAM".

Each runtime parameter should be specified on a separate line, for instance:

DynamicParameter   M5  # dynamic b-quark mass
DynamicParameter   M6  # dynamic t-quark mass

This would simplify output status of OLP_SetParameter, to two cases:

int=0 - change accepted (parameter successfully modified or deemed irrelevant, e.g. GF in pure QCD)
int=1 - change not accepted (parameter was not listed in order file or invalid value, e.g. negative mass)

I agree that info about dynamic parameters can be useful at the level of the order/contract files.
int=0: You suggest not to distinguish between "OK" and "Ignored, proceed"; fine with me, but probably the OLP should specify this in the conract file (as in Fig.3 of the draft).
Keywords (UFO/extra) for dynamic parameters to be agreed on.

- suggest to introduce an "Extra" flag for OLP specific parameters

I would support this suggestion.

However, it needs to be discussed whether this flag is used to pass information about the quality of the virtual corrections for each phase space point. It would be better to have a more standardised way of passing such information, even though the checks done withinn the OLP are completely OLP specific.

Rikkert suggests to add an argument to OLP_EvalSubProcess. This is also what is suggested in 3.4 of the draft, together with the global setting of TreatUnstable in the order file.

Simon and Valery, how do you control the threshold at which quadruple precision is applied? Is this threshold set "by hand" within the OLP program, or is it passed at the level of the interface?

NJet supports a few additional options to control accuracy via the BLHA. The following is taken from section 3.1.1 of 1209.0100:

 NJetReturnAccuracy [default = no]
 If set to yes, the scaling test is used to estimate the accuracy and the result is returned in the 
 output array making it three entries longer.
 NJetSwitchAcc [default = 1e-5]
 Used to set the relative accuracy at which higher precision floating point arithmetics will be used to evaluate 
 the phase space point if double precision has not produced the desired accuracy. To account for the statistical 
 nature of the scaling test it is recommended to specify 1 or 2 digits more than the required accuracy.

we also allow:

 NJetMultiPrec [default=1]
 In case you want to compile without quad. precision you can set it to 0. Not recommended though.

Powers of different coupling constants

  • There is certainly the need to be able to define coupling constants which are different from QCD alpha_s and QED alpha.
  • Fixing the powers of alpha_s resp. alpha globally is not a good idea

(having in mind combining different jet mutliplicities, QCD/EW intereferences, BSM, etc)

  • Suggestions to improve on the current settings are:

- everything imported from UFO, no coupling stripped off
- different fixed coupling constant orders, specified explicitly for different subprocesses
- in Rikkert's example, the powers of the NLO couplings are fix, but the trees are different: QED tree with QCD Bremsstrahlung and QCD tree with QED Bremsstrahlung.
We need a way to define such situations.

The suggestion below to define the coupling constant order individually for certain suprocesses if they are different from the "global" setting seems convenient to me.

Settings specific to only a subset of subprocesses

  • the flexibility to have different settings for different subprocesses is desirable.

First of all in terms of powers of the coupling, but also concerning e.g. active particles, masses, etc.

  • example from NJet:
AlphasOrder 2
Process 3 AlphasOrder 3
Process 4 AlphasOrder 4
Process 5 AlphasOrder 4

Tree only, no tree

  • NJet:

Since OLP can also compute tree-level amplitudes, there is no reason not to provide an interface for them.

 AmplitudeType   Tree

This parameter would also work well with per-process scheme suggested above:

 Process 2 AmplitudeType Tree
  • for processes without tree level, the keyword LoopInduced in the order file should be defined


  • NJet:

It is hard to come up with a generic definition of "leading colour". The OLP may decide to implement this in many different ways as to include more or less of the sub-leading effects. As a result using the "LeadingColour" option for different OLPs with the same BLHA accord could yield different results.

Maybe LeadingColour should be considered an additional feature of a given OLP and therefore associated with the keyword 'Extra'.

The questions arises as what to do when no full colour result is available from the OLP since this invalidates the use of the 'Extra' flag.


  • Peter Skands:

Concerning spin-dependence. From our point of view, helicity (massless) and chirality (massive) is all you need. That also seems to correspond to the most elementary amplitude structure. We hope this simple option will not be excluded by the structure of the updated accord?

The special case of polarized massive vector bosons, which I am not sure anyone gave a physical example of where would be needed, would then be dealt with as a special case, if needed, as it is already in the accord.


  • Function signatures

should be explicitly specified, at least for C++. At the moment the most common convention for C/C++ is

 void OLP_Start(const char* filename, int* status);
 void OLP_EvalSubProcess(int mcn, double* pp, double mur, double* alphas, double* rval)
  • implicit/explicit use of symmetries

Please comment on the following item raised by Simon/Valery:

The OLP may like to provide faster versions of colour sums in case there is a bose symmtery in the final state. The correctness of this method relies on the MC program NOT implementing any symmetry constraints on the phase space. If it is not supported it can be safely ignored and the full sum used instead. In NJet we used:

AmplitudeType   loopds

where the "ds" suffix means de-symmetrized. It should be possible to apply it on per-process basis.

Discussions at Les Houches 2011

  • Higher order (NLO) calculations and techniques
 - comparisons (real/virtual) for specific processes 
 - numerical stability issues
 - automation
 - availability of public computational tools
 - output format(s) (Root ntuples) 
 - examples of BLHA at work


  • NNLO techniques


  • wishlist
 - more NLO? 
 - EW corrections (vs pdf fits)
 - accuracy
 - use of available NLO calculations by experimentalists 
   (format, assessment of systematics)


  • NLO/Parton Shower matching:
 - Systematics study: NLO codes versus Powheg versus Menlops vs MEPS
 - Merging of NLO samples (W+1,2,3,4 jets) without/with(?) shower 

Step by step uncertainty study NLO parton shower merging


  • Systematic studies of
 - impact of choice of scales, alphas, pdfs, jet algorithms/cone size
   (concrete study e.g. for W/Z + jets ?)
 - inclusive jet uncertainties


  • Higgs observables
  - heavy Higgs: reference for gg (-> H) -> ZZ interference effects hep-ph/9511414
  - correlations
  - interferences

Higgs Info


  • Prompt Photons
 - isolation



  • Jetology:
       - pileup subtraction
       - jet Observables
       - boosted objects tagging
       - Connections/differences between LO, NLO and MC jet clustering 
          for complex n-parton final states
       - Variations in NLO multi-parton cross sections with jet algorithms, jet sizes and scales
       - estimate of non-perturbative corections
       - impact of jet vetos on scale dependence 
         (e.g. process gg->H->WW, H b-quarks associated production)
       - Rivet

Jetology possible topics


  • PDF's
 - assessment of errors (NLO jet production,...)
 - interplay with EW corrections
 - PDF fits exclusively to HERA/Tevatron/LHC data
 - nuclear PDFs & impact on Flavor differentiation 
 - comparison of NLO and resummed predictions for inclusive jet cross sections
 - progress toward full NNLO 
 - (extended) benchmark comparison of Heavy Flavor scheme (using Les Houches Accord PDFs)
 - use of PDF error sets in MC


PDFs and jets

  • "Anomalies" in data
  - Wjj
  - ttbar asymmetry


Personal tools