Abstract

(Pavel's suggestion: Clearly mention the Delphes limitations as, for example, it's done for PGS ​http://www.physics.ucdavis.edu/~conway/research/software/pgs/pgs4-general.htm)

Lines 1 and 2: ”the DELPHES fast-simulation framework is presented” makes the reader think that the content of the article is purely related to the software technicalities, while the paper is instead mostly about the physics content of the fast simulation - if one excepts Section 5. [See related comment about Section 5 below.]

Suggestion : Replace ”fast-simulation framework” by ”fast simulation”, and remove the second sentence, which is out of place in an Abstract.

Lines 5 to 9: The description of DELPHES in the abstract is too software oriented. The journal to which the preprint is submitted is called ”Journal of High-Energy Physics”, not ”Journal of High-Energy Software”. The ca- sual reader does not really care that the program produces ”collections”, he cares instead about the physics content of the simulation. The suggestion here would be to rephrase the end of the abstract to indicate the simulation was enhanced with new features, needed for the simulation of the LHC de- tectors in the coming period (e.g., additional pile-up interactions, which will become crucial in the coming decade, or particle-flow reconstruction, which has become a salient feature in the first years of the LHC for one of the two multi-purpose detectors), and that the program simulates ”physics objects” used for data analysis at hadron colliders such as ”jets”, ”taus”, ”missing energy”, ”electrons”, ”muons”, ”photons”, ”isolation”, ”pile-up mitigation”, etc.

It is indeed important that the concept of ”hadron collider” appears clearly in the abstract. Because the simulation is analysis-oriented, it would take a number of important modifications to make it useable for analysis of e+e- collisions, for example.

(Andrea's temporary comment) I think that his argument is incorrect. There is nothing in Delphes that assumes that the collider is hadronic. One can just generate e+e- or ep events with pythia or any other generator and Delphes would process those events correctly. Therefore, it would be incorrect to write in the abstract, or elsewhere, that it is a simulation for hadron colliders. At most, one could argue that it is not general enough to simulate asymmetric detectors like ALICE or LHCb (which are experiments at hadron colliders...), but we are clearly stating that we want to simulate "multipurpose detectors", and I don't think that ALICE fits that definition (LHCb certainly doesn't).

(Michele) suggested abstract based on ref. comments below

The version 3.0 of the \DELPHES fast-simulation is presented. Its goal is the simulation of a multipurpose detector that includes a track propagation system embedded in a magnetic field, electromagnetic and hadronic calorimeters, and a muon identification system. The new modular design allows to easily simulate physics objects that can be used for data analysis. These include tracks and calorimeter deposits and high level objects such as isolated electrons, jets, taus, and missing energy. New features such as the particle-flow reconstruction approach, crucial in the first years of the LHC, and pile-up simulation and mitigation, which will be needed for the simulation of the LHC detectors in the near future, have also been implemented.

comments: I agree with Andrea's answer, no need to mention hadron colliders, especially no need to mention the LHC nor CMS for that matter. (when he says "for one of the two multipurpose detectors"). Regarding Pavel's comment, maybe it is more appropriate to mention the Delphes limitations in the introduction.

We can answer something along these lines:

• The abstract has been revisited by removing software specific statements and referring only to the simulation aspects (with the exception of the mentioning of the "modular design" which we want to keep since it also a new feature).
• We do not agree with the fact that Delphes is hadron collider specific. Delphes would process e+e- events just fine. Therefore, it would be incorrect to write in the abstract, or elsewhere, that it is a simulation for hadron colliders. At most, one could argue that it is not general enough to be able to simulate asymmetric detectors like ALICE or LHCb (which are experiments at hadron colliders...), but we are clearly stating that we want to simulate "multipurpose detectors".