====== BLHA Page ======
a) An update on this is in the make. 

The details are in the new version of the draft:

[[http://phystev.in2p3.fr/wiki/_media/2013:groups:sm:blhaupdate.pdf|updated write-up]] 

 
[[2013:groups:sm:blha:api|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.

 --- //[[yundin@nbi.dk|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
<code>AccuracyTarget 0.0001</code>

The information of whether accuracy has been reached is returned to MC via extra integer parameter **rstatus**
<code c++>
void OLP_EvalSubProcess2(const int* j, const double* pp, const double* mu, double* rval, int* status)</code>
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.

 --- //[[jfsoden@mpp.mpg.de|Johann Felix v. Soden-Fr.]] 2013/06/07 18:04//

I agree with that.
 --- //[[daniel.maitre@durham.ac.uk|Daniel Maitre]] 2013/06/10 09:34//

==== Discussion of June 6 ====
**Example order file (please comment and/or edit): [[2013:groups:sm:blha:order1|order.lh]]**

=== New info function ===

<code c++>OLP_Info(char[15] olp_name, char[15] olp_version, char[255] olp_message)</code>
called by MC after ''OLP_Start''.

 

=== Passing Parameters:===

<code c++>OLP_SetParameter(char* para, double* re, double* im, int* ierr)</code>

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@durham.ac.uk|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@durham.ac.uk|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@mpp.mpg.de|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)