BLHA Page
- - Precision setting and OLP_EvalSubProcess
  - Discussion of June 6

BLHA Page

a) An update on this is in the make.

The details are in the new version of the draft:

Suggested C/C++ and Fortran declarations (API) for the runtime interface.

Comments:

Concerning full SM corrections, they can be accommodated by the interface (possibly split into several contributions) if CouplingPower QCD, CouplingPower QED and CorrectionType can be specified on per-process basis.

PDF information (if it is available) like the number of flavours used in the running coupling can be passed from MC via OLP_SetParameter.

— Valery Yundin 2013/06/11 09:30

Precision setting and OLP_EvalSubProcess

The target accuracy the user would like to reach is set in the order file using

AccuracyTarget 0.0001

The information of whether accuracy has been reached is returned to MC via extra integer parameter rstatus

void OLP_EvalSubProcess2(const int* j, const double* pp, const double* mu, double* rval, int* status)

Also all arguments are changed to pointers to facilitate FORTRAN compatibility and allow future format extensions.

const int* j – (one element) array with channel number (previously const int)
const double* pp – momenta array (unchanged)
const double* mu – renormalisation scale (unchanged)
double* rval – array of return values
double* acc – one element array with status of accuracy check

Comments:

The Fortran 2003 standard, which is supported since at least the last 5 years by all main compilers, supports c-bindings including call-by-value. But of course to get better compatibility with older Fortran standards and to be more flexible in the future, we can change everything to call-by-reference (effectively equal to call-by-pointer) as in the current draft. The old BLHA has call-by-value for the scale.

I suggest to include exact c++/c/fortran[90,2003] declarations for all subroutines into the BLHA.

— Johann Felix v. Soden-Fr. 2013/06/07 18:04

I agree with that. — Daniel Maitre 2013/06/10 09:34

Discussion of June 6

Example order file (please comment and/or edit): order.lh

New info function

OLP_Info(char[15] olp_name, char[15] olp_version, char[255] olp_message)

called by MC after OLP_Start.

Passing Parameters:

OLP_SetParameter(char* para, double* re, double* im, int* ierr)

The keywords for the particle masses and widths are defined by their PDG codes, names for couplings are defined in the write-up, e.g. for the top mass, width, $\sin^2\theta_w$:

mass(6),
width(6),
sw2

Note that some of these parameters can be complex (two doubles as function arguments).

Global settings like

MassiveParticles,
ExcludedParticles

should also be possible.

— Daniel Maitre 2013/06/10 09:37 The int is a return status I guess. 0: fine 1: don't know this setting 2: know this setting but unhappy about value passed. You could think about having a pointer to an array instead of two arguments? Easily extensible to larger values, one could imagine passing, say, the ckm matrix entries.

Treatment of unstable phase space points:

please see new version of the draft

different powers of coupling constants:

allow different settings for different subprocesses

The new setup can be used for merged samples as well as mixed QCD/EW corrections. It can also be used to pass additional information referring only to particular subprocesses

example:

 CouplingPower QCD 2  
 process x 
 process y

 CouplingPower QCD 3  
 CouplingPower QED 2  
 process z 
 process zz 

 CouplingPower QCD 1 
 CouplingPower QED 1
 AmplitudeType LoopInduced True 
 process xy

EW corrections:

no changes wrt the last version of the draft. Importance to keep the EW Scheme option “OLPDefined” was stressed.

Polarisation/Colour:

Conventions for polarisation vectors already have been fixed at the last meeting. The keywords “ccTree” and “scTree” for colour/spin-correlated tree matrix elements have been introduced. Special terms in the colour 1/N expansion can be defined using the “Extra” flag.

Restrictions such as diagram filters, exploitation of special symmetries, etc:

Rather something where the particular OLP/MC providers (humans) should talk to each other, but can be accommodated using the “Extra” flag.

Extras

The keyword “Extra” can be used to write special requirements relevant to the OLP into the order file. Apart from transmitting them to the order file, the MC will ignore them if they are unknown/irrelevant to the MC.

— Daniel Maitre 2013/06/10 09:45 This is trying to tell the MC what to do with Extra parameters given to it through its runcard and how to generate the order file? I don't think this is the scope of what we want to do.

—Gudrun Heinrich 2013/06/10 11:15 For the moment, it is rather to write items into the order file which are relevant to the OLP only, but not to the MC. The MC does nothing but copy strings. The idea is that this way the OLP does not have to read input files other than the order file.

Test cases to try out implementation of the new settings:

W+0,1 jets; dijet/3jets

Open issues coming up while starting the implementation of the test cases will be discussed on Monday June 10, 17h00, Auditorium.

b) Implementation of corrections (in particular EW) in Monte Carlo programs (e.g. Sherpa)

c) Extension to loop-induced processes: interface for modules of NLO calculation (2-loop virtual and 1-loop Born/real)

Table of Contents