a) An update on this is in the make.

The details are in the new version of the draft:

updated write-up

Pdf file containing defined keywords and functions, please comment

Comments:

Concerning full SM corrections, they can be accommodated by the interface (possibly split into several contributions) if AlphasPower, AlphaPower 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 threshold of accuracy below which the point should be considered unstable is set in the order file using

Precision 1e-4

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

void OLP_EvalSubProcess(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
• int* status – one element array with status of accuracy check

Comments:

The question whether both the scale and the coupling(s) should be in the argument list (as it has been in the standards so far) is not yet fully settled. If several couplings are listed, an order (alpha_s, alpha) has to be fixed. It seems safer to pass the couplings via the function Set_Parameter. It also needs to be decided whether mu should be a pointer to an array or just one number.

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(const char*, const &double, const &double, &int)

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,
• ActiveParticles,
• 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.

no changes with respect to the last 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:

 AlphasPower 2  
 process x 
 process y 

 AlphasPower 3  
 AlphaPower 2  
 process z 
 process zz 

 AlphasPower 1 
 AlphaPower 1
 LoopInduced  True 
 process xy

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

Conventions for polarisation vectors already have been fixed at the last meeting. For special options concerning colour (terms in 1/N expansion, not colour summed, etc) it was felt that this should be “hardwired” between the particular OLP/MC providers to follow the individual needs.

Also rather something where the particular OLP/MC providers (humans) should talk to each other.

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 to 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), e.g. gg -> gamma gamma