= 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 energy-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".
>>> (Christophe): I would add to the answer that: It is true, on the other hand, that some aspects of the default reconstruction sequence (e.g. focus on transverse quantities) are targeting hadron colliders. Because of the modular design, it is easy to adapt high-level routine to other needs. We now make that clear in a few places in the text.
>>> I would also change the way we speak about the modular aspect. It is not because the code is modular than we can easily simulate the objects. The modular aspect makes it easy to adapt the sequence to particular needs. Therefore: "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. Physics objects that can be used for data analysis are then reconstructed from the simulated detector response. These include tracks and calorimeter deposits and high level objects such as isolated electrons, jets, taus, and missing energy. The new modular design makes it easy to adapt the sequence to particular needs. New features such as the energy-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."