CWR Review

Comments from Christophe Delaere and Vincent Lemaitre:

General Comments:

We have not yet submitted the full reading of the note to each member of LOUVAIN since we believed that it first needs to be significantly improved prior publication.

Please have a look at the updated draft. We believe that it should address your concerns.

- What's the main improvement and/or additional message with respect to CMS note ref. [5]? The present note should maybe be presented has a continuation and a complementary work? In its present form, the note looks more like an internal technical note than a public CMS note.

Ref. 5 is a very nice reference for the Event Filter and DAQ systems. This CRAFT paper is complementary to it - the emphasis here is on the HLT menu (and not the filter farm), workflows and strategies/procedures for monitoring trigger performance. We respectfully disagree and think that this paper provides for the first time a public description of our trigger menu strategy and detailed plans for trigger DQM. It also establishes the fact that the HLT performed in a robust fashion during an extended period of data-taking with all sub-detectors in.

- We believe the sections describing the tools should be strongly reduced. Especially since it lacks figures and illustrations... making the reading rather difficult to digest. We try to illustrate this point with the more detailed comments below.

This was discussed during the ARC review and the section was shortened to describe the important/relevant information.

- Section 3.1 is very difficult to read. It contains a lot of slang words and definitions are missing. In addition, this section also contains four series of itemization and one long sub-itemization, showing an obvious problem of structure.

We have attempted to define the terms used in this note following your suggestions. It is necessary to introduce the triggers used in the HLT menus during CRAFT, which naturally suggests itemization.

- We suggest to maybe merge section 3.1 and 4 since section 4 defines notions used in 3.2. (and in this context, section 4 could also be further reduced).

Section 4 contains material not appropriate for Section 3 and we believe the merging would unnecessarily complicate the paper.

- Generally speaking, footnotes are to be avoided, according to the author guidelines.

The footnote in Section 3.2 has been removed.

- Our understanding is that for this series of papers the detector will be described in a general introduction. Most of the introduction, and the first paragraph of section 2 are therefore unnecessary.

Actually, each of the CRAFT papers has to be a stand-alone CMS paper. And hence we are required to have a general introduction to the experiment/detector.

Detailed comments:

2 : general purpose -> "general-purpose" or « multi-purpose »

Done

5 : delete the sentence "These broad... ...Standard Model.", and merge the next paragraph to the first one

This paper is supposed to serve as a stand-alone paper. Therefore, we need to have a general introduction to the experiment and detector and hence this line.

8 : Strange sentence... I would not start with "the responsibility ... "

Changed.

17: ? what's the fraction of cosmic muons in the 270 million cosmic ray triggered events?

We are using the default CRAFT description suggested for the papers.

35 : « In addition to the above » delete and start with The CMS

Changed.

37 : « at the full bunch crossing rate » -> "at a bunch crossing rate"

Done

44 : « 200-300 Hz » ref [5] and prior work mention 100 Hz. Precise why/how it changed.

It;s really O(100) Hz. We simply state this now.

53: it contains undefined jargon (regional data unpacking, seeds) and is not really needed.

We have updated this paragraph.

Section 3

70 : Title of section 3: "HLT During CRAFT" rather vague... This section describes the HLT menu and deployment procedure during CRAFT.

76 : " L1 pass-through triggers" slang and actually not defined... unless sentence at line 74 is modified Fixed.

77-80 : Sentences are rather vague... either cancel or be more precise. we are not sure to understand but we would add sth like: ... to select events in nominal conditions. Or “that will be used to select physics events during beam collisions. Additional clarifying text has been added.

84 : " L1 trigger objects" slang... also introduced L1 bit at line 75.... should either be "L1 object" or "L1 trigger object" in contrast to "L1 trigger bit"... or is it the same thing? Later on, at line 87, you talk about "L1 single-object algorithm triggers"... later you talk about "generic trigger", and later, "generic physics event label"... L1 trigger objects have been defined. Term is used in the L1 CRAFT note, which is referenced. "Bit" has been removed. The single-object definition is hopefully clarified with the improved definition of an "object" at L1. The "generic" discussion has been removed.

85: What is the difference between algorithm and technical triggers, for what concerns the HLT? The definitions of algorithm and technical triggers have been improved in the note. There is some (technical) distinction in the HLT, but primarily the HLT cares about receiving and processing the event. If a technical trigger is of no interest to HLT, it should be masked at L1.

86 : Sentence starting at "During CRAFT..." is too long. The punctuation hopefully aids in the readability of the sentence, thus removing the need for a list.

89-90: ? You mentioned at line 73 that L1 undergone extensive commissioning but here, you mention that there was a L1 commissioning effort... isn't there a contradiction? Line 73 has been removed.

91 : delete "were masked by the GT and" ... slangy and redundant with the next part of the sentence... also Repetition of the end of previous paragraph. Fixed.

92: ... by L1 would however include the results... Rephrased.

96-97: and Bad hyphenation Hyphenation is consistent with the defined term at start of Section 3.

98-99: “All triggers process every event accepted by L1”. Does that mean there is no L1 seed required for CRAFT08 triggers? Please clarify. Besides, this second sentence is obviously redundant and/or trivial By construction, every high level trigger sees all events. At the start of (nearly) all HLTs there is an L1 seed check, this may cause a trigger to stop (reject) the event very early. Other triggers (L1 seed condition met) continue, so the event may be accepted later. The second part of the sentence has been removed.

100-115: That paragraph is a bit difficult to follow, with discussion of some L1 aspects mixed with the HLT discussion. By the way, "GT" or "global GT" both are written... The text has (hopefully) been clarified.

107 "the LHC bunch structure was emulated by CMS during CRAFT..." Too long an explanation to fit within an itemized paragraph. We have attempted to be as brief as possible while satisfying other reviewer requests.

111 Confusing paragraph to just say that in the case of random trigger, a prescale is being applied in the HLT. The paragraph also explains what "random" triggers are and their usefulness for trigger verification.

113: for CRAFT08, I think “limited to few Hz” is more adequate. Fixed.

133: If we do a rough estimate: rate in pixel ~0.1Hz, so P(coincidence)~1E-8 @ 1Hz, ~1E-6 @ 100Hz. Therefore, one expects one pixel event in the random sample every ~1E4s !!! It might be the same for HF, but there we don't have numbers. So, that trigger is useless as a backup. Language has been adjusted to emphasize "validation" nature rather than "backup" (intended use in collisions via Zero Bias seeding).

162: How is the transverse energy defined for cosmics. From the transverse components of P? Using the crystal position + IP hypothesis (beam line)? It's worth clarifying as transverse quantities are used also later on. The algorithms employed by the HLT assume a collision environment. Text has been added to clarify.

157: ...background studies for example for HSCP. Fixed.

section 3.2: 182: Why not something like "Online Deployment of HLT conditions and rules? (Menu is maybe ambiguous or slang). by the way, what is the difference between the title 3.1 and the title of the entire section "HLT during CRAFT"? Again the structure is unclear... The HLT "menu" is defined previously. Section 3.1 discusses the triggers and 3.2 discusses the validation and deployment of those triggers (collected in a menu).

187: (then 350 and 353): avoid footnotes. Footnote removed.

192: "validation farm" what does that mean? try to unify your convention naming Fixed.

195: "to collect (event) data from" why event in parenthesis? event data or/and "non-event data should be better defined. The event is the quantum of the data in the Event Filter Farm". There is no "non-event" data, but including "event" emphasizes the way the data is grouped (hence the parenthesis).

195 : the sentence "The first ... processing" might be unclear for people not involved in the CMS data operation. For instance " How does one collect data from a process? what is a process, a Filter Unit process? A description of the trigger system has been included in Section 2.

207 : How can the rejection power be tested on already selected events? Are you using some zero-bias sample, which is not mentioned? For CRAFT, the HLT rejected no events that had passed L1. This statement has been included in Section 3. This allowed expected rates to be calculated.

Section 4:

208 : “streams” and “primary datasets” are jargon not introduced before section four. The size of this section could also be reduced and re-organized. First a long introduction is given with short subsections (4.1 for instance). Second, there are repetitions and inconsistency naming between streams defined in the itemized part in introduction and the subsection 4.1 and 4.2. Third, there are sentences and paragraphs with slang words and structure such that they are very difficult to read.

Our other reviewers were happy with this section and so we have not changed the length of it. We have taken your comments below into account and improved it though. The HLTDEBUG stream goes by the name of DQM stream these days and hence the two names. But we have removed HLTDEBUG stream now - simply refer to it by the name that was used during CRAFT.

233: What is a "reduced event data" ? We suppose this is an event containing a reduced amount of information. Why not call it this way. If reduced data is to be used often in the paper, then clear definition should be given.

Changed.

235: what do you mean by "homogenous information"

event content should be the same/homogenous; we give an example

235: The event content used for physics stream comprises the full detector ... --> The event information written in the physics stream includes...

We now define event content earlier following your suggestion.

242: Items: we would give less details since most of them are introduced again in subsections 4.1 and 4.2. Why the calibration and physics stream do not deserve dedicated subsections?

We have kept the minimal description here in order to distinguish between the streams. Dedicated sections are used for the specialized streams only.

251: "For example, ..." We do not understand this sentence...

Removed.

267: title: why has this stream a double naming? We would call it DQM stream and, as said, this stream includes HLT by-products (to be defined as well...).

This stream was called HLTDEBUG during CRAFT08 and is currently called DQM stream and hence the two names. In the latest version we use only DQM.

276: "directly off it" ?

Fixed.

284: what is a " reconstruction-level objects" ? purely CMS slang DONE, remove the sentence because it is also not true: we are using Reco objects but at HLT...

281: you introduce "reduced event content" and then on line 286 "small portion of the event data" do you talk about the same reduction here? if yes, use the same English words to name it. By the way, 281 and 286 information is almost identical...

We are talking of the same reduction. We have removed the first instance - keep the second in order to explain it fully.

297: "PDG Pi0 mass" --> "Pi0 mass" simply... PDG not defined and here, it is irrelevant anyway... DONE

Section 5:

We understand that section 5 is the main actual results (and not a description) motivating this publication. It could therefore be extended and content maybe more actual results.

The important lessons from CRAFT for the HLT are not actually numbers but rather the operational experience (how reliably did it run, what were the problems and what tools do we have to catch and fix them). We do have some global efficiency numbers and some cpu performance but we know that these will change with collisions. What is relevant is that we ran stably with only a couple of problems (these are described in Section 5.3) and that we have since then ensured that these will not be an issue for collision data. And we know how things change with varying operating parameters (noise, data corruption etc.) This experience was one of the reasons which prompted the trigger reviews earlier this year which lead the advent of the "lean" menus for first collisions.

322 referring to a specific sub section as an introductory paragraph is not correct. Here, you should give general words on the section or list the actual message of each sub-section.

Fixed.

368 avoid HLT_L1MuOpen especially since it is even not what is in the axis of Fig. 1 and also because it is actually not used later in the paper. It is not in the x-axis, but it is in y-axis. The rate (y-axis) is caluculated using the events passing the HLT_L1MuOpen.

383 : "... offline DQM are: all reconstruct ...; and..." we would avoid : and ; and cut the whole sentence into two. We like it as it is.

Figure 2: Redo the figure with TDR style and higher quality.

It was difficult to reformat the originally chosen figure, as the parent root file was not readily available. It has been replaced with the equivalent occupancy plot for CRAFT08 run 66676, for which the .root file could be readily regenerated. The figure now abides by tdr standards. The caption has been elaborated. The text has been elaborated to describe how the geometry of actively triggering DT sectors can be identified through the offline monitoring.

415: “especially for L1 trigger performances”... is this part of the sentence really relevant in a HLT paper? L1 performance has direct bearing on HLT performance, obviously. The software therefore includes some basic L1 diagnostics, otherwise how can you tell which system is responsible for a problem? The software has the capability so it is described that way for completeness.

423: idem: “...studies of level-one and...”. This is not a L1 paper.

452: Which one? Be a bit more precise, maybe.

We have changed these few sentences following the kind suggestions from another reviewer. Hopefully it will be clearer now. However, we believe that naming the algorithm will not help the reader understand the idea of our monitoring of the system.

461: could this be monitored in the FU by online DQM?

Here we talk about the expected variations among the runs/menus tested. Of course, they can not be directly compared to collisions because the algorithms are not optimized for cosmic events. We have opted to drop this last sentence without affecting our results

We hope this helps, best, Christophe Delaere and Vincent Lemaitre, for the LOUVAIN group christohe.delaere@cernNOSPAMPLEASE.ch vincent.lemaitre@uclouvainNOSPAMPLEASE.be

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r3 - 2009-10-30 - TulikaBose
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Sandbox All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright &© 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback