This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
2013:groups:sm:blha [2013/06/10 11:24] gudrun.heinrich |
2013:groups:sm:blha [2013/08/13 09:33] (current) gudrun.heinrich |
||
---|---|---|---|
Line 4: | Line 4: | ||
The details are in the new version of the draft: | The details are in the new version of the draft: | ||
- | [[http://phystev.in2p3.fr/wiki/_media/2013:groups:sm:blhaupdate2013.pdf|Pdf file]] of the updated write-up | + | [[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 ==== | ==== Precision setting and OLP_EvalSubProcess ==== | ||
- | The threshold of accuracy below which the point should be considered unstable is set in the order file using | + | The target accuracy the user would like to reach is set in the order file using |
- | <code>Precision 1e-4</code> | + | <code>AccuracyTarget 0.0001</code> |
The information of whether accuracy has been reached is returned to MC via extra integer parameter **rstatus** | The information of whether accuracy has been reached is returned to MC via extra integer parameter **rstatus** | ||
<code c++> | <code c++> | ||
- | void OLP_EvalSubProcess(const int* j, const double* pp, const double* mu, double* rval, int* status)</code> | + | 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. | 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 int* j'' -- (one element) array with channel number (previously ''const int'') |
* ''const double* pp'' -- momenta array (unchanged) | * ''const double* pp'' -- momenta array (unchanged) | ||
* ''const double* mu'' -- renormalisation scale (unchanged) | * ''const double* mu'' -- renormalisation scale (unchanged) | ||
* ''double* rval'' -- array of return values | * ''double* rval'' -- array of return values | ||
- | * ''int* status'' -- one element array with status of accuracy check | + | * ''double* acc'' -- one element array with status of accuracy check |
//Comments:// | //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. | 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. | ||
Line 46: | Line 52: | ||
called by MC after ''OLP_Start''. | called by MC after ''OLP_Start''. | ||
- | ==== Summary of June 5 meeting ==== | + | |
=== Passing Parameters:=== | === Passing Parameters:=== | ||
- | <code c++>OLP_SetParameter(const char*, const &double, const &double, &int)</code> | + | <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, | The keywords for the particle masses and widths are defined by their PDG codes, | ||
Line 62: | Line 68: | ||
Global settings like | Global settings like | ||
* ''MassiveParticles'', | * ''MassiveParticles'', | ||
- | * ''ActiveParticles'', | ||
* ''ExcludedParticles'' | * ''ExcludedParticles'' | ||
should also be possible. | should also be possible. | ||
Line 71: | Line 76: | ||
===Treatment of unstable phase space points:=== | ===Treatment of unstable phase space points:=== | ||
- | no changes with respect to the last version of the draft | + | please see new version of the draft |
===different powers of coupling constants:=== | ===different powers of coupling constants:=== | ||
Line 82: | Line 87: | ||
example: | example: | ||
- | AlphasPower 2 | + | CouplingPower QCD 2 |
process x | process x | ||
process y | process y | ||
- | AlphasPower 3 | + | CouplingPower QCD 3 |
- | AlphaPower 2 | + | CouplingPower QED 2 |
process z | process z | ||
process zz | process zz | ||
| | ||
- | AlphasPower 1 | + | CouplingPower QCD 1 |
- | AlphaPower 1 | + | CouplingPower QED 1 |
- | LoopInduced True | + | AmplitudeType LoopInduced True |
process xy | process xy | ||
Line 101: | Line 106: | ||
no changes wrt the last version of the draft. | no changes wrt the last version of the draft. | ||
- | Importance to keep the EW Scheme option "UserDefined" was stressed. | + | Importance to keep the EW Scheme option "OLPDefined" was stressed. |
===Polarisation/Colour:=== | ===Polarisation/Colour:=== | ||
Conventions for polarisation vectors already have been fixed at the last meeting. | Conventions for polarisation vectors already have been fixed at the last meeting. | ||
- | For special options concerning colour | + | The keywords "ccTree" and "scTree" for colour/spin-correlated tree matrix elements |
- | (terms in 1/N expansion, not colour summed, etc) it was felt that this should be | + | have been introduced. Special terms in the colour 1/N expansion can be defined using |
- | "hardwired" between the particular OLP/MC providers to follow the individual needs. | + | the "Extra" flag. |
+ | |||
===Restrictions such as diagram filters, exploitation of special symmetries, etc:=== | ===Restrictions such as diagram filters, exploitation of special symmetries, etc:=== | ||
- | Also rather something where the particular OLP/MC providers (humans) should talk to each other. | + | Rather something where the particular OLP/MC providers (humans) should talk to each other, |
+ | but can be accommodated using the "Extra" flag. | ||
===Extras=== | ===Extras=== | ||
Line 120: | Line 127: | ||
--- //[[daniel.maitre@durham.ac.uk|Daniel Maitre]] 2013/06/10 09:45// | --- //[[daniel.maitre@durham.ac.uk|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. | + | 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// | ---//[[gudrun@mpp.mpg.de|Gudrun Heinrich]] 2013/06/10 11:15// | ||
Line 140: | Line 147: | ||
b) Implementation of corrections (in particular EW) in Monte Carlo programs (e.g. Sherpa) | 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. [[http://arxiv.org/abs/hep-ph/0206194|gg -> gamma gamma]] | + | c) Extension to loop-induced processes: interface for modules of NLO calculation (2-loop virtual and 1-loop Born/real) |