2013:groups:sm:blha
Differences
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 09:57] daniel.maitre [Summary of June 5 meeting] |
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 45: | 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 61: | Line 68: | ||
| Global settings like | Global settings like | ||
| * ''MassiveParticles'', | * ''MassiveParticles'', | ||
| - | * ''ActiveParticles'', | ||
| * ''ExcludedParticles'' | * ''ExcludedParticles'' | ||
| should also be possible. | should also be possible. | ||
| Line 70: | 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:=== | ||
| 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 109: | 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// | ||
| + | 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 116: | 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 123: | 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) |
2013/groups/sm/blha.1370851049.txt.gz · Last modified: 2013/06/10 09:57 by daniel.maitre
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: Public Domain
