Introduction

First (and second) paragraph:

A reference should also be made to the ”fast simulations” developed by CMS and ATLAS, which are two to three orders of magnitude faster than the GEANT-based simulations, while minimizing the loss of accuracy, and allowing the ”complex reconstruction algorithms” to be used.

(Andrea's temporary comment) I don't think it's very relevant, but just for the sake of compromise, we can do. For ATLAS, I know this reference: ​http://inspirehep.net/record/1196761 but it is only for tracking; a more generic one, although it is just a conference proceeding, is ​http://inspirehep.net/record/1211010 (I suggest to cite both, for completeness.) For CMS, the most recent and appropriate is: ​http://inspirehep.net/record/1214935 but there is the delicate point that there is not his name on it ;) So in addition one could also cite ​http://inspirehep.net/record/1117120 (but not this one alone, because some details are now obsolete, like the pileup treatment). Both are conference proceedings, but it is standard practice in CMS to cite them. And, still for CMS, one could argue that also this one should be cited, because it contains comparison to data: ​http://inspirehep.net/record/1230052 Please let me know if you think that these are too many citations.

(Michele) thanks for the references, I think we can include them all (see below in the suggested intro)

Third paragraph:

L4: It’s not enough to say that the magnetic field is uniform (as this adjective qualifies only the absolute value in Tesla). The word ”axial” and the expression ”along the beam direction” could be used to the sake of clarity.

addressed

L5: The energy smearing applies also to all other particles, not only to photons and electrons. Why are these two particles singled out here ?

addressed: photons and electrons have been replaced by

long-lived visible particles"

L6-7: ”Jets and missing energy can be computed with the particle-flow al- gorithm.” is an incorrect sentence. First ”the particle-flow algorithm” would probably need to be somehow defined, or at least given a reference. Sec- ond, ”the particle-flow algorithm” does not deliver jets and missing energy, it delivers a list of reconstructed and identified particle candidates. Jets and missing (transverse) energy can then be obtained from either calorimeter de- posits, or from these particle candidates. Both approaches are conceptually and technically identical for jets and missing energy. This misconception of the PF reconstruction appears in several places in the article, and most likely in several aspects of the simulation implementation too. A number of the comments that follow are related to this aspect.

addressed

We agree that the particle-flow algorithm should be defined. We now call our approach a "particle-flow-like emulation" in the new draft: we don't aim at re-implementing the PF algorithm itself, but at emulating its effects. This would make more clear why we only apply it to jets and MET: there is no PF-like approach that we can follow for muons, electrons, etc., as those are already perfectly identified objects in our simulation.

We'd rather call this energy-flow, since this is what we are doing.

The suggestion regarding the last two comments is to explain that all particle energies are smeared according to parameterized detector resolutions, and that physics objects used in physics analyses (isolated leptons, isolated photons, jets, missing transverse energy, taus) are derived from these smeared energies. The concept of calorimeter and particle flow algorithm is to be kept for the next paragraph.

addressed

Paragraph 4:

L1: Add ”which was only simulating energy deposits in the calorimeters” or anything closer to the truth, after ”predecessor”.

it was actually bugged, and creating photons out of nowhere, but how can we say this to ref.?

L3: Add ”to deliver a list of reconstructed and identified particles as close as possible to the true (generated) list.” after ”sub-detectors”

see prior comment, not mentioning particle-flow at this stage, but just saying that we.

L6: ”fully modular” would need some more explanation for the reader to understand it. But is it so important for a JHEP article ?

It is important to mention the modularity since it is crucial improvement with respect to the prior version. The modular aspects of Delphes are explained in the technical description part, which was moved in the appendix section. At this stage it is enough for the non-software expert reader to know that modular

implies greater flexibility.

Paragraph 5:

L2/L3: Propose to drop. The software implementation is out of context.

Dropped the software description since it will be in the Appendix, but the use cases should be mentioned.

PAGE 3

Par 2:

L5/6/7: This sentence starts with ”As for the tracking efficiency”, but nothing was said about the tracking efficiency settings prior to this sentence. A mention of the fact that this efficiency can be user-defined should appear at the beginning of the paragraph, and replace ”(good)”.

addressed: "Charged particles have a user-defined probability to be seen as tracks"

(Michele suggested introduction)

High energy particle collisions can produce a large variety of final states. Highly sophisticated detectors are designed in order to detect and precisely measure particles originating from such collisions. Experimental collaborations often rely on Monte-Carlo event generation for designing and optimizing specific analysis strategies. Whenever such studies require a high level of accuracy, the interactions of long-lived particles with the detector matter content are fully simulated with the \GEANT package~\cite{bib:geant4}, electronics response is emulated by dedicated routines, and final observables are reconstructed by means of complex algorithms. For preliminary studies, where such a high level of accuracy is not needed, LHC collaborations have developed their own fast-simulation techniques~\cite{bib:atlfast1,bib:atlfast2,bib:cmsfast1,bib:cmsfast2,bib:cmsfast3} which are 2 to 3 orders of magnitude faster than fully GEANT based simulation.

This procedure requires expertise and the deployment of large scale computing resources that can be handled only by large collaborations. For most phenomenological studies, such a level of complexity is not needed and a simplified approach based on the parametrisation of the detector response is in general good enough. In 2009, the \DELPHES framework~\cite{bib:delphes} was designed to achieve such goal. \DELPHES takes as input the most common event generator output data-formats and performs a fast and realistic simulation of a general purpose collider detector. To do so, long-lived particles emerging from the hard scattering are propagated to the calorimeters within a uniform magnetic field along the beam direction. The particle energies are computed by smearing the initial long-lived visible particles momenta according to the resolution of the relevant sub-detectors. As a result, high-level physics objects such as jets, missing energy, isolated leptons and photons, and taus can be computed.

With respect to its predecessor~\cite{bib:delphes}, the present \DELPHES version now includes a technique allowing to combine and optimally use the information of all the sub-detectors. This approach is particularly suitable to the treatment of pile-up, which has also been included in \DELPHES 3.0. Other features such as $b$ and $\tau$-tagging have been revisited, and it is now possible to apply an energy scale correction on jets. From a technical perspective, the code structure is now fully modular, providing a greater flexibility to the user.

The modeling of the detector, as well as the reconstruction and validation of the physical observables will be described. A couple of illustrative use cases of Delphes in the context of LHC studies are presented.