User Tools

Site Tools


2013:groups:sm:blha

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
2013:groups:sm:blha [2013/06/10 21:54]
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//
  
-[[http://​phystev.in2p3.fr/​wiki/​_media/​2013:​groups:​sm:​KeywordsFunctions.pdf|Pdf file]] containing defined keywords and functions, please comment 
  
 ==== 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 elementarray 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
-  * ''​intstatus''​ -- one element array with status of accuracy check+  * ''​doubleacc''​ -- 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 48: 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 64: Line 68:
 Global settings like  Global settings like 
   * ''​MassiveParticles'',​   * ''​MassiveParticles'',​
-  * ''​ActiveParticles'',​ 
   * ''​ExcludedParticles''​   * ''​ExcludedParticles''​
 should also be possible. should also be possible.
Line 73: 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 84: 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 ​+   CouplingPower QED 
-   ​LoopInduced ​ True +   AmplitudeType ​LoopInduced True 
    ​process xy    ​process xy
  
Line 103: 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 122: 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 142: 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.1370894077.txt.gz · Last modified: 2013/06/10 21:54 by gudrun.heinrich