NLO techniques/Standardization/automation

From Wiki Les Houches 09

(Difference between revisions)
Jump to: navigation, search
Current revision (13:54, 18 April 2010) (view source)
m
 
(21 intermediate revisions not shown.)
Line 4: Line 4:
People signed up for this group:
People signed up for this group:
-
* Fawzi
+
Fawzi, Peter, Gudrun, Giampiero, Ian, Tanju, David, Rikkart, Nicolas, Laura, Stefano, Stefan, Nikolas, Ruth, Thomas (R), Maria Vittoria, Duc Ninh, Marcus, Sunhao, Isabella, Son, Vittorio, Lorenzo, Daniel, Darren, Simon (B), Achilleas, Carlo
-
* Peter
+
-
* Gudrun
+
-
* Giampiero
+
-
* Ian
+
-
* Tanju
+
-
* David
+
-
* Rikkart
+
-
* Nicolas
+
-
* Laura
+
-
* Stefano
+
-
* Stefan
+
-
* Nikolas
+
-
* Ruth
+
-
* Thomas (R)
+
-
* Maria Vittoria
+
-
* Duc Ninh
+
-
* Marcus
+
-
* Sunhao
+
-
* Isabella
+
-
* Son
+
-
* Lorenzo
+
-
* Daniel
+
-
* Darren
+
-
* Simon (B)
+
-
* Achilleas
+
-
* Carlo
+
-
[[Draft]]
+
'''Les Houches accord for a standard interface between leading order Monte-Carlo tools and one-loop programs (OLPs)'''
 +
 
 +
A view slides which are related to the discussion on standardization
 +
can be found here (June 2009) [[http://www.ph.ed.ac.uk/~binoth/LH_09_nlo_accord.pdf]]
 +
The starting point for a concrete interface was provided by Tanju and
 +
Daniel in this [[Draft]] (June 2009).
 +
 
 +
After extensive discussions and exchange of ideas we have formulated this (preliminary) proposal [[http://www.ph.ed.ac.uk/~binoth/NLOLHA_CURRENT_VERSION.pdf]] for a
 +
MC/OLP interface in December 2009. Several groups and individuals
 +
have provided input for this document and work on implementations now.
 +
First working examples are expected to  be documented in the Les Houches
 +
proceedings. We will try to collect relevant program fragments
 +
on this page which may serve as guidelines and help for users and
 +
providers of MCs and OLPs.
 +
 
 +
''' Report from CPC on the BLHA'''
 +
 
 +
Reviewer #1:
 +
 
 +
The authors of the manuscript ``A proposal for a standard interface between
 +
Monte Carlo tools and one-loop programs'' propose an interface for the
 +
communication between programs for the calculation of one-loop amplitudes
 +
(OLP), and programs dealing with anything else necessary in a next-to-leading
 +
(NLO) order calculation. Since this communication is bound to be non-trivial,
 +
the existence of such a standard interface would be of great help in the
 +
development of full NLO Monte Carlo programs.
 +
 
 +
Except for a few points, the paper is clearly written.
 +
 
 +
= Point A =
 +
The first point that
 +
may need clarification is related to the proposed MatrixElementSquarType, in
 +
case it is not set to CHsummed. In this case, the MC has to perform color
 +
and/or helicity summation, and necessarily has to provide color and/or
 +
helicity configurations to the OLP. In the discussion about OLP_EvalSubProcess,
 +
it is suggested that the OLP can provide ''more color and helicity
 +
information'', but is not mentioned whether the OLP could take such information
 +
as input. Only momentum configurations are mentioned as input.
 +
 
 +
 +
== Suggestions for Point A ==
 +
 
 +
*  Suggestions and comments from Rikkert. In the interface between MadFKS and Rocket, we used a Monte Carlo sum over the helicities, i.e. for a given phase space point we calculated the contributions only for 1 helicity configuration. We simply did this by putting an extra array with the helicities of the external particles in the argument of the call to the OLP_EvalSubProcess(..) subroutine. This was for us by far the easiest solution, in particular because we were looking at process with only massless external particles, so there are no ambiguities in the definition of the spin/helicity, see also the proceedings arXiv:1003.1241. We could, maybe, stress a bit more that the arguments of this call (as written in the paper), are the minimum requirements. It should be left free to the users to extend it if necessary.
 +
 
 +
*  Question from Daniel: Don't we want to have a common function call? The way this can be handeled in C is to add an opaque pointer to the additional data that is needed (but I don't know if one can do that in Fortran). We can also use the "result" array to pass information to the OLP, and not only to get information back from the OLP.
 +
 
 +
* Answer/suggestion from Nikolas: Good point. In principle yes, but we have already some ambiguity in the current text: one scale as d.p. number or alternatively several scales as array --> different function calls.  The opaque pointer solution works in C/C++, but not in Fortran77, and there's no simple way to make sure that both implementations agree on what object this pointer points to.  (A similar issue arises for common blocks in Fortran77.)  In my opinion, the natural solution would be that the OLP offers several function calls: OLP_EvalSubProcess(..) should correspond to the minimal interface with MatrixElementSquareType=CHsummed.  For the case MatrixElementSquareType=NOTsummed, I would define a different function OLP_EvalSubProcessNotSummed(..) that has the hel./col. configuration as additional input argument.  I consider this structure natural, because one can then implement OLP_EvalSubProcess(..) simply as loop that calls OLP_EvalSubProcessNotSummed(..) for all configurations, resulting in little extra code and no code duplication.  I've added a sentence to my response suggestion below that recommends to give the function an extended name if there are additional arguments.
 +
 
 +
* Answer from Daniel: If the functions have different name I'm happy.
 +
 
 +
 
 +
Suggestions and comments from
 +
 
 +
----
 +
 
 +
= Point B =
 +
Secondly, the paper propagates, eg. at the beginning of page 9, the
 +
philosophy for the OLP to provide un-subtracted information, and not only
 +
subtracted information. This seems to conflict with the last paragraph of page
 +
15, where it is mentioned that ''The OLP directly subtracts the collinear and
 +
soft divergences....'' This probably has to do with the discussed mass
 +
regularization, and could be clarified more.
 +
 
 +
 
 +
== Suggestions for Point B ==
 +
 
 +
Suggestions and comments from
 +
 
 +
Suggestions and comments from
 +
 
 +
----
 +
 
 +
Then there are a few details:
 +
1. Page 4 after formula 2.7 ''identifies'' should be ''identified''
 +
 
 +
2. Same page, same paragraph the sentence ''In actual calculations, subtraction methods are applied...'' maybe should be rephrased, stating that the proposed standard assumes the use of subtraction methods.
 +
 
 +
3. Among the publications cited in the context of automated evaluation of one-loop amplitudes, it might be appropriate to also mention Automated one-loop calculations: A Proof of concept. A. van Hameren, C.G. Papadopoulos, R. Pittau,  JHEP 0909:106,2009.
 +
 
 +
-----
 +
* Change/response suggestion by Nikolas:
 +
 
 +
We welcome the referee's acknowledgment of the helpfulness of our document for the development of NLO Monte Carlo programs.  The referee raises several valid minor points that have been addressed as follows:
 +
 
 +
[Point A:]
 +
 
 +
In 4.2 under OLP_EvalSubProcess (p. 13): added below bullet point list:
 +
 
 +
"If the OLP can handle MC requests for not-helicity/colour-summed output, which is then summed by the MC, a label or array that defines the requested helicity/colour configuration has to be passed to the function as input.  More generally, if the cooperation between the OLP and MC goes beyond the described minimum additional input or
 +
output variables can be added to the interface, in which case a suggestive extension should be added to the
 +
function name, as for example in OLP_EvalSubProcessNotSummed."
 +
 
 +
The sentence below the box has been modified to:
 +
 
 +
"which correspond to the terms A_2, A_1, A_0, |Born|^2, ..."
 +
 
 +
[Point B:]
 +
 
 +
A standard-compliant interface has to provide unsubtracted information and may provide subtracted information.  If the optional subtracted information is provided or not is indicated with IRsubtractionMethod.  The sentence following the description of IRsubtractionMethod (p. 8/9) is thus clarified:
 +
 
 +
"[Although the IR structure of one-loop amplitudes is universal,] we require that unsubtracted information is provided by the OLP even where subtracted information is also made available.  If the MC uses subtracted information provided by the OLP one has to make sure that the used IR methods match."
 +
 
 +
The last sentence in Sec. 4.2. (p. 14) has been extended with "(also see setting IRsubtractionMethod in Sec. 4.1.1)."
 +
 
 +
In Sec. 5.2 the first sentence in the last paragraph on p. 15 has been changed from
 +
"The OLP directly subtracts the collinear ..." to "The OLP may subtract the collinear ..."
 +
 
 +
On p. 4 after formula 2.7 "identifies" has been replaced by "identified".
 +
In the same paragraph the sentence "In actual calculations, subtraction methods are applied..."
 +
has been changed to "In actual calculations, frequently subtraction methods are applied...".
 +
 
 +
A reference to Automated one-loop calculations: A Proof of concept. A. van Hameren, C.G. Papadopoulos, R. Pittau,  JHEP 0909:106,2009 has been added on p. 2.
 +
 
 +
We hope that our clarifications and modifications are satisfactory.

Current revision

Discuss on the various NLO techniques, identify if and what exactly can be standardized in these NLO calculations. Discuss on automation.

People signed up for this group:

Fawzi, Peter, Gudrun, Giampiero, Ian, Tanju, David, Rikkart, Nicolas, Laura, Stefano, Stefan, Nikolas, Ruth, Thomas (R), Maria Vittoria, Duc Ninh, Marcus, Sunhao, Isabella, Son, Vittorio, Lorenzo, Daniel, Darren, Simon (B), Achilleas, Carlo

Les Houches accord for a standard interface between leading order Monte-Carlo tools and one-loop programs (OLPs)

A view slides which are related to the discussion on standardization can be found here (June 2009) [[1]] The starting point for a concrete interface was provided by Tanju and Daniel in this Draft (June 2009).

After extensive discussions and exchange of ideas we have formulated this (preliminary) proposal [[2]] for a MC/OLP interface in December 2009. Several groups and individuals have provided input for this document and work on implementations now. First working examples are expected to be documented in the Les Houches proceedings. We will try to collect relevant program fragments on this page which may serve as guidelines and help for users and providers of MCs and OLPs.

Report from CPC on the BLHA

Reviewer #1:

The authors of the manuscript ``A proposal for a standard interface between Monte Carlo tools and one-loop programs propose an interface for the communication between programs for the calculation of one-loop amplitudes (OLP), and programs dealing with anything else necessary in a next-to-leading (NLO) order calculation. Since this communication is bound to be non-trivial, the existence of such a standard interface would be of great help in the development of full NLO Monte Carlo programs.

Except for a few points, the paper is clearly written.

Contents

Point A

The first point that may need clarification is related to the proposed MatrixElementSquarType, in case it is not set to CHsummed. In this case, the MC has to perform color and/or helicity summation, and necessarily has to provide color and/or helicity configurations to the OLP. In the discussion about OLP_EvalSubProcess, it is suggested that the OLP can provide more color and helicity information, but is not mentioned whether the OLP could take such information as input. Only momentum configurations are mentioned as input.


Suggestions for Point A

  • Suggestions and comments from Rikkert. In the interface between MadFKS and Rocket, we used a Monte Carlo sum over the helicities, i.e. for a given phase space point we calculated the contributions only for 1 helicity configuration. We simply did this by putting an extra array with the helicities of the external particles in the argument of the call to the OLP_EvalSubProcess(..) subroutine. This was for us by far the easiest solution, in particular because we were looking at process with only massless external particles, so there are no ambiguities in the definition of the spin/helicity, see also the proceedings arXiv:1003.1241. We could, maybe, stress a bit more that the arguments of this call (as written in the paper), are the minimum requirements. It should be left free to the users to extend it if necessary.
  • Question from Daniel: Don't we want to have a common function call? The way this can be handeled in C is to add an opaque pointer to the additional data that is needed (but I don't know if one can do that in Fortran). We can also use the "result" array to pass information to the OLP, and not only to get information back from the OLP.
  • Answer/suggestion from Nikolas: Good point. In principle yes, but we have already some ambiguity in the current text: one scale as d.p. number or alternatively several scales as array --> different function calls. The opaque pointer solution works in C/C++, but not in Fortran77, and there's no simple way to make sure that both implementations agree on what object this pointer points to. (A similar issue arises for common blocks in Fortran77.) In my opinion, the natural solution would be that the OLP offers several function calls: OLP_EvalSubProcess(..) should correspond to the minimal interface with MatrixElementSquareType=CHsummed. For the case MatrixElementSquareType=NOTsummed, I would define a different function OLP_EvalSubProcessNotSummed(..) that has the hel./col. configuration as additional input argument. I consider this structure natural, because one can then implement OLP_EvalSubProcess(..) simply as loop that calls OLP_EvalSubProcessNotSummed(..) for all configurations, resulting in little extra code and no code duplication. I've added a sentence to my response suggestion below that recommends to give the function an extended name if there are additional arguments.
  • Answer from Daniel: If the functions have different name I'm happy.


Suggestions and comments from

Point B

Secondly, the paper propagates, eg. at the beginning of page 9, the philosophy for the OLP to provide un-subtracted information, and not only subtracted information. This seems to conflict with the last paragraph of page 15, where it is mentioned that The OLP directly subtracts the collinear and soft divergences.... This probably has to do with the discussed mass regularization, and could be clarified more.


Suggestions for Point B

Suggestions and comments from 
Suggestions and comments from

Then there are a few details: 1. Page 4 after formula 2.7 identifies should be identified

2. Same page, same paragraph the sentence In actual calculations, subtraction methods are applied... maybe should be rephrased, stating that the proposed standard assumes the use of subtraction methods.

3. Among the publications cited in the context of automated evaluation of one-loop amplitudes, it might be appropriate to also mention Automated one-loop calculations: A Proof of concept. A. van Hameren, C.G. Papadopoulos, R. Pittau, JHEP 0909:106,2009.


  • Change/response suggestion by Nikolas:

We welcome the referee's acknowledgment of the helpfulness of our document for the development of NLO Monte Carlo programs. The referee raises several valid minor points that have been addressed as follows:

[Point A:]

In 4.2 under OLP_EvalSubProcess (p. 13): added below bullet point list:

"If the OLP can handle MC requests for not-helicity/colour-summed output, which is then summed by the MC, a label or array that defines the requested helicity/colour configuration has to be passed to the function as input. More generally, if the cooperation between the OLP and MC goes beyond the described minimum additional input or output variables can be added to the interface, in which case a suggestive extension should be added to the function name, as for example in OLP_EvalSubProcessNotSummed."

The sentence below the box has been modified to:

"which correspond to the terms A_2, A_1, A_0, |Born|^2, ..."

[Point B:]

A standard-compliant interface has to provide unsubtracted information and may provide subtracted information. If the optional subtracted information is provided or not is indicated with IRsubtractionMethod. The sentence following the description of IRsubtractionMethod (p. 8/9) is thus clarified:

"[Although the IR structure of one-loop amplitudes is universal,] we require that unsubtracted information is provided by the OLP even where subtracted information is also made available. If the MC uses subtracted information provided by the OLP one has to make sure that the used IR methods match."

The last sentence in Sec. 4.2. (p. 14) has been extended with "(also see setting IRsubtractionMethod in Sec. 4.1.1)."

In Sec. 5.2 the first sentence in the last paragraph on p. 15 has been changed from "The OLP directly subtracts the collinear ..." to "The OLP may subtract the collinear ..."

On p. 4 after formula 2.7 "identifies" has been replaced by "identified". In the same paragraph the sentence "In actual calculations, subtraction methods are applied..." has been changed to "In actual calculations, frequently subtraction methods are applied...".

A reference to Automated one-loop calculations: A Proof of concept. A. van Hameren, C.G. Papadopoulos, R. Pittau, JHEP 0909:106,2009 has been added on p. 2.

We hope that our clarifications and modifications are satisfactory.

Personal tools