a) An update on this is in the make.

The details are in the new version of the draft:

updated write-up

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

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

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

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

called by MC after OLP_Start.

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.

please see new version of the draft

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

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

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.

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

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:

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)