CWR Review

Comments from Marcella Diemoz:

The important work done to monitor a crucial part of CMS system which is reported in CFT-09-020 should be acknowledged. We find that at this stage the paper content is more a qualitative and descriptive information rather than providing quantitative results that could be of interest for an external (non CMS) reader. Expected goals and results should be more clearly focussed. The general style of the paper is confidential, not appropriate for a public paper.

Thank you for your comments. The paper may not provide many quantitative results, however, we think it describes in detail the HLT menu used and its commissioning (the reason why we call it a commissioning paper). In addition, it provides a detailed description of our monitoring and dqm strategies for startup/collisions. Having a robust trigger menu and decent monitoring is critical for startup and the stable running of the HLT during CRAFT showed how well it was already performing. We have improved many of the sections and incorporated many of your comments.

Detailed comments

Abstract: it says that the trigger menus are described in the paper but the description in section 3 is rather generic and never fully describes a given trigger menu.

We have changed described to "presented". We do think that there is a lot of information in Section 3 regarding the triggers used during CRAFT. You may not find explicit thresholds in many cases - for eg. muons - but this is simply because we are running with the lowest possible thresholds. A collision menu would be different.


Line 3: "tonne" --> ton (or tons). It would be even better to use SI units, in this and future papers

Switched to ton

Line 8: "good quality" is quite inappropriate. The aim of a trigger system is not to guarantee good quality data, but to select event classes based on their topology and physics quantities associated to their content. The whole sentence can be rephrased as "The CMS trigger and data-acquisition systems ensures that as much as possible of the potentially interesting events are recorded with high efficiency and good quality".

Thank you! We have modified this.

l. 14-20: Authors should specify here that part of CRAFT data have been taken without magnetic field. In sect. 5.3 one run at 0 T is used

We concentrate on the 3.8 T commissioning in the introduction since it's about "CRAFT". In section 5.3 we explicitly mention that we consider one run taken at 0T for our study.

Section 2

Line 52--55: It would be better to rephrase the sentences as "Traditional three- level systems have to use regional information from specific parts of the detector to achieve the O(1000) rejection. In our two-level design, full granularity data from the whole detector (including the tracker) is available to a standard commercial computer." At this point the footnote can be included in the text adding the word "only" between "implemented" and "some".

Thank you for the suggestion. Done

Line 55: "The CMS HLT decision can be" --> "The CMS HLT decision can then be"


Line 60--62: Rephrase: "Therefore the reconstruction algorithms run during the HLT processing must be optimized for performance in order to minimize dead time and, at the same time, collect all interesting events for physics analysis.


Line 63: "menus" should be defined explicitly here. What are the entries of each menu, and what is the expected outcome. As there are several menus, it should be said whether they are exclusive or will run in parallel, and what are the "performances" (l.64) which matter (the global efficiency, the completeness, or what?)

Line 64: omit quotes around "physics"

Menu description added; improved (moved to beginning of Section 3 as per another reviewer's comments.

Line 68: the usage of the word "use" sounds as the shifters are slaves or tools. Maybe "employment" is a better synonym.

Removed altogether.

Section 3

Line 76: removing the "L1" before "pass-through" makes the sentence much more clear. At first reading one can thought you were speaking of another type of trigger.

"L1" has been added to the definition in line 74 to add clarity.

l.87 "the most inclusive L1 single-object algorithm triggers contributed to the global L1 de- cision" do you mean "ONLY the most inclusive..." Fixed.

l. 85-86: here an example of technical trigger is needed for a better comprehension. The definition has been improved using the description from the L1 CRAFT note.

l.89 "an electron or photon ENERGY ABOVE 1 GeV" Fixed.

l.90 "in order to facilitate L1 commissioning efforts": too vague statement. Either make more explicit or remove. Removed.

l.91 repeats lines 89-90 Fixed.

Line 92: "would however would include" --> however includes Fixed.

l.91-94 does it mean that the HLT decision could use L1 bits not used for seeding but available in the event? Yes. Hopefully this has been clarified in the text.

l.95 what do you mean by 'higher quality' objects? In the remaining of the text very often you use the term by-products. Perhaps it would be better to use either object or by-product in the paper. Fixed.

Line 96: "The triggers present in the menus deployed during CRAFT" --> "Triggers deployed in the menus during CRAFT" Fixed.

l.100 "The most basic L1 pass-through triggers at the HLT examined only the global GT decision" a) L1 triggers examined the GT at the HLT !? something went wrong! b) If GT is Global Trigger, what is global GT? Fixed.

l. 102: Authors should specify here the rate of "physics" events Done

Line 109: this is my ignorance: does the physics trigger is suppressed during calibration events or during calibration cycles? I mean, the suppression is based on the fact that a calibration trigger arrived or is based on the fact that we are in the gap? In the latter case do not use the word "event". The designed arrival of the calibration trigger (in 1 out of every 112 gaps) initiates physics trigger suppression.

Line 113: omit parenthesis around "high-rate". Fixed.

l.116: 'to ensure that all events...': you have already said in ll.96-99 that all events are processed. So what is to be ensured? The HLT processes, but does not necessarily accept, all events. This language of this statement is meant to clarify that point.

ll.121-123 repeats lines 102-104 Paragraph removed.

l.121 any events -> all events Paragraph removed.

133-142: The expected rates at LHC of these two HLT paths, seeded by random L1 triggers, should be pointed out. The expected rate of these paths, if L1 is performing as designed, should be zero when seeded by random triggers. The explanation of the L1 logic (priority of Random/Calibration/Physics events) seems more suited to the L1 note. Furthermore, the random rate is varied run to run during commissioning so no reasonable numbers can be provided.

l.135 'would be' -> are Fixed.

l.137 'if the event was not flagged' -> if not flagged Rephrased.

139 HF -> forward calorimeter HF definition provided in the introduction.

ll.146-147 repeats ll.74-75 and ll.96-99 Removed.

ll.148-150 repeats ll.98-99 Lines 98-99 removed.

ll.151-181: perhaps it could help the reader to use a trigger label for each bullet This was discussed, and adding the trigger names does not add to the understanding of the trigger functionality. Line 155: the description of this trigger seems to be just a pass-through trigger. In this case its description is useless. If this is not the case the description must be wrong or not very precise. It is indeed a pass-through trigger, but the important point is that this is a physics trigger intended to collect background data for a physics analysis.

ll.157: you are say that these events collected during CRAFT 'will be' used in the future. Indeed.

Line 162: "transverse energy": it may seem obvious, but for cosmics measuring the transverse energy does not make sense. This is clearly a "remnant" of the fact that the triggers are developed, in fact, for LHC operation. We must tell somewhere that, despite that for cosmics the concepts of transverse energy and momentum does not make sense, they are used in the HLT to make them as similar as possible to LHC triggers. Then you can profit of this comment to mention the fact that later you will use the pseudorapidity eta as a measure of the polar angle with respect to the beam axis, for consistency with measurements in LHC, even if for cosmics, again, this quantity does not make sense. It is just useful to compare with MC. A comment has been added preceeding the discussion of the triggers applying some physics selection.

Line 167: here momenta are indicated in GeV, somewhere else (line 172) in GeV/c. Use consistent units. Also, define implicitly a symbol used below adding $p_T$ after "transverse momentum" Fixed.

Line 177: The sentence starting with "This trigger could only be implemented..." is obscure. Fixed.

l.183 online and offline are in italics, then normal and again in italics in the footnote. Fixed.

l.183 "the offline-tested menu" this jargon can be understood only after the reading of the whole paragraph. Rephrase... Fixed.

l.184 the run numbers can be skipped ???

l.184 "The HLT uses the same software to run on Monte Carlo and previously collected data events offline and record collision or cosmic ray data online. " the sequence is rather cumbersome. Fixed.

l.187: Event Filter Farm: you use capitals but never actually describe this farm. later (l.191) becomes lower case Fixed.

l.190 add (validation farm) at the end of the sentence since you later use it at l.192 Fixed. Thanks.

l.200 validation system -> validation farm Fixed.

ll.203-205 already written in ll.187-189 Removed lines 188-189.

l.213 DAQ farm is not defined Fixed.

footnote page 5: databases and data streams drop 'need to be' Removed footnote.

Section 4

l. 245-248: An example of HLT reconstruction by-product is appropriate

We have improved this description.

l.246 for allowing -> to allow


l.251-252 "For example, it allows for the monitoring of the drift time by pulsing of the muon drift tube chambers" Obscure. In any case, an outsider has no idea of what we are talking about.


Line 255: "this data" --> these data


Line 261: the sentence starting "These PDs were defined..." is obscure.


l.262 "a set of triggers that performed similar selection were grouped into a primary dataset" primary dataset should contain events, not triggers Changed.

l.266 "helped commission the full workflow that will be used at LHC startup" again this is a vague statement; either you say how it has been helpful, or remove.

It helped commissioning the (Tier-0) data processing workflow.

Line 269: trigger paths are undefined


l.270 "The DQM stream included the calibration triggers" -> "The DQM stream included events selected by the calibration triggers"


l.272 "HLT by-products" what are they?

Described earlier now.

l.286 drop 'for most alignment and calibration purposes' at the end of the sentence "most" is needed because some time you want to full event to be able to select correctly your object to be used for calibration or JES calibration needs full events as CaloTask force tuning or JPT...

l.297 "PDG pi0 mass" the pi0 mass window is not such to change significantly with the last digit of the pi0 mass. Remove PDG. DONE, but perhaps the request was coming from the ARC?

Line 300: phi is never defined. "relies on the phi" --> relies on the azimuthal angle phi DONE

l. 303: Hcal -> HCAL DONE

Section 5

l.318 drop 'As was discussed in sec. 2' for the beginning of the sentence DONE

ll.318-319 already stated earlier DONE, I (lorenzo) removed the sentence, OK?

l.321 'such as this' -> such as CRAFT DONE

l.341 'each path' : you have not described what a path is DONE

l.343 'selects any events' -> select events (drop 'any') NOT DONE, followed other previous suggestion

l.344 the HLT bits NOT DONE, followed other previous suggestion

l.351 section 5.1.3 why describe in detail only the muon example and not the others? would be worth adding a sentence about this in the introductory text of section 5 Introduction improved.

l.354 rephrase 'As is standard' We remove it

l.362 muon -> muons We change as muon trajectory, and the tracking region of interest is decided by each L2 muon

l.362 'shortens time' -> shortens the time DONE

l.366 drop 'obtain' We rephrase the sentence

l.366 of muon HLT -> of the muon HLT DONE l.369 replace 'cuts' with selection criteria or something else DONE

Line 368: Figure 1 left part does not add any useful information and makes the understanding of what follows much more difficult. It would be better to show figure 1 right part only and rewrite the paragraph as "Figure 1 shows the fraction of L2 muons with respect to L1 triggers as a function of the eta. The L1 triggers do not require any momentum threshold nor quality cuts. As a result, the ration can be taken as a measurement of the trigger efficiency. As it can be seen such a ratio is close to 1 in almost all the barrel region, as expected". Of course, change the caption accordingly. That plot is important to show the performance of HLT triggers. We add some more text about this.

l.378 'Tier 0' while earlier at l.259 you wrote Tier-0. Use the same notation DONE

l.378 why 'introduces' ? Changed.

l.379 'software modules': you never used the (jargon) term 'modules' in the online section. Either define/introduce what a module is earlier or remove it. The rest of this section makes heavy use of the term so probably it's worth spending a couple of words to say what you mean. "Modules" has been expunged.

l.390 is a repetition

l.391 something odd in the sentence. it reads as if the modules were histograms. Revise the entire sentence REPHRASED

l.394 'analyzer module' is jargon and not described earlier for the reader FIXED

l.397 'HLT analyzers' is jargon FIXED

Line 400: the shape of the occupancy plot must be explained. It is not trivial for non-CMS members. In the picture you should omit "CMS Preliminary" (there is nothing that can be possibly wrong in this picture) as well as the statistics box (useless). The axis should be labelled with the symbols phi and eta defined in the text. Why do you specify "online"? Probably because the reconstruction happens online and not offline, but probably there is not a significant difference and, if needed, you can explain this in the text. 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.

l.401 this paragraph is full of jargon and has to be revised. 'plotted objects' -> displayed/monitored quantities


Figure 2: improve/increase the quality of the image. The statistics box is useless. The axes titles should be consistent with the symbols defined in the text.


Figure 3: a higher quality image is needed and many words on the left are hardly readable The Figure has been removed.

Line 403: The rest of the paragraph starting with "For example" is obscure, it is not clear what do you mean. You compare the object histograms with some reference histogram, but the example it is not understandable. Moreover in the example you cite the minimum-bias trigger that probably has nothing to do with cosmics. What is a "turn-on curve"? The fact that it is in quotes sounds as it is not something known to the community, so it should be better defined. Reread it, it is a perfectly straightforward way to estimate trigger efficiency. "turn-on curve" is expunged.

Table 1: Run 66279 is at 0 T. So, strictly speaking, is not a CRAFT run. Why did you choose this run? Is there any specific reason?

Run 66279 was taken during CRAFT. The reason for choosing the 0T run was precisely to compare it to a 3.8T run. We wanted to monitor the performance of the HLT cpu timing under pronounced variations of conditions.

l. 406 "the test path trigger efficiency “turn-on curve” " really needed all this specifications? if yes, then add some hyphen to guide the reader. This was rephrased.

l.414 "to confirm in more detail" ?? either is to confirm, or to add more detail l.419 "longer integration times of proton collision runs will allow for unique monitoring uses there" sounds obscure. This was rephrased.

Line 449: as stated it seems that 47 ms are added to the CPU-time of the previous case. Better to say "in an increase of the average CPU time of about 3 times".

True. Fixed

Line 451: "we found one algorithm..." seems we are admitting some stupid mistake in the algorithm. You may say, starting from the previous sentence: "Taking runs with noisy sub-detectors allows us to gauge the impact of non-optimal operating conditions on the performance of the HLT. After few runs in this condition we found only one algorithm to be non-optimal in terms of CPU performance. The data collected during these special runs were used to develop much more robust algorithms that were subsequently deployed online".


Line 454: data unpacking must depend on the size of the data. You say that this is approximately the same for all studies, so it has to be assumed that this time is needed in both runs 66279 and 68021, despite the fact that in the latter there are many more detectors. It will be very useful to measure the data unpacking time vs the data size and extrapolate this time to LHC conditions.

This can be confusing indeed. We have updated the text to explain better that the baseline cpu time of 3-4 msec is due to the unpacking of the L1 data and that after that detector unpacking can be performed (on demand) based on the L1 decisions.

l. 457: "this is generally carried out only once per event." Why the word generally is used here ? Is this not true in 100% of the events ? If I'm wrong, a footnote could be added to explain the reason for a repeated unpacking.

Yes, it is done 100% of the events. It's been fixed.

l.460 "The results are encouraging, and differences among the various cases are as expected." Actually, one should give some comment on the average times reported in the table 1: are they satisfactory? What did we expect? is that a proof that we will be able to process all the data with the farm? If we are not in the condition to make precise statements, then the sentence in l.460 should be dropped

The sentence was dropped. The absolute cpu-timing numbers for cosmics cannot be directly compared to our expectations for collisions due to the algorithms (prescales and the way rejection is handled) not being optimal for the former case. Our "expectations" were relative to the results presented here and not to real collisions.


l. 463 "the commissioning efforts.. build on the progress..." something missing?


l. 478-480 "we see that changes in data quality delivered by the CMS detector (e.g. noisy or corrupt data) can dramatically influence the trigger behaviour." what is the message? "we have seen..." or "we could expect..." and then? what is the conclusion we can draw?

Rephrased. The conclusion is that HLT DQM is critical for checking the trigger performance , detect problems and get fixes... Hopefully, it reads better now.

Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r5 - 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