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/09 19:33] 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. | ||
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 34: | Line 41: | ||
--- //[[jfsoden@mpp.mpg.de|Johann Felix v. Soden-Fr.]] 2013/06/07 18:04// | --- //[[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 ==== | ==== Discussion of June 6 ==== | ||
Line 44: | 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 60: | Line 68: | ||
Global settings like | Global settings like | ||
* ''MassiveParticles'', | * ''MassiveParticles'', | ||
- | * ''ActiveParticles'', | ||
* ''ExcludedParticles'' | * ''ExcludedParticles'' | ||
should also be possible. | 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:=== | ===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:=== | ||
allow different settings for different subprocesses | 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: | example: | ||
- | AlphasPower 2 (global setting) | + | CouplingPower QCD 2 |
- | process x AlphasPower 3 AlphaPower 1 (use these orders in alpha_s, alpha only for process x) | + | process x |
- | process y AlphasPower 4 AlphaPower 0 | + | process y |
- | This setup can be used for merged samples as well as mixed QCD/EW corrections. | + | CouplingPower QCD 3 |
- | It can also be used to pass additional information referring only to particular subprocesses, e.g. | + | CouplingPower QED 2 |
+ | process z | ||
+ | process zz | ||
+ | |||
+ | CouplingPower QCD 1 | ||
+ | CouplingPower QED 1 | ||
+ | AmplitudeType LoopInduced True | ||
+ | process xy | ||
- | process x AlphasPower 3 AlphaPower 1 AmplitudeType LoopInduced | + | |
===EW corrections:=== | ===EW corrections:=== | ||
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 103: | Line 125: | ||
The keyword "Extra" can be used to write special requirements relevant to the OLP into the order file. | 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. | 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: | Test cases to try out implementation of the new settings: | ||
Line 110: | Line 139: | ||
- | Test cases will be discussed on Monday June 10, 17h00, Auditorium. | + | Open issues coming up while starting the implementation |
+ | of the test cases will be discussed on Monday June 10, 17h00, Auditorium. | ||
Line 117: | 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) |