CWR Review

Comments from Anna Meneguzzo:

General remarks Section 1: Introduction

a) The goals of the paper, i.e. presenting results achieved by HLT commissioning during CRAFT 2008, can be read only in the “Outlook” and is poorly presented in the introduction.

b) There is no mention to the fact that here for the first time you have checked HLTs on real data with almost all detectors included after the extensive studies with simulated pp events. It would be worth mentioning explicitly which HLT channels, valid for HLC, you have tested and why. You should try to give an immediate feeling of the complexity of the procedure for commissioning HLTs even though only few HLTs of pp have been checked ( as an example ..for a not CMS reader ( but also for not HLT expert) the number of detector channels analysed for the reconstruction of the physics objects for HLTs could be useful).

Thank you for these suggestions. We have added some of these points to the Introduction. We have alluded to the gain in operational/commissioning experience but the results, naturally, are presented later.

Section 2

The HLT infrastructure is not explained even if briefly.

Added description, numbers, figure.

Section 3

c) All relevant information of CRAFT period could be summarized in this section (see specific suggestion added below). A short presentation of the strategy for the commissioning of HLTs during CRAFT (also the procedure Online and Offline which are introduced in Section 3.2) could be introduced here before the list of all the HLTs used or investigated for helping on understanding the procedure used and choices.

See responses to specific comments.

d) the number of CPUs participating to the HLT CRAFT exercise with respect to the amount of the hardware foreseen for LHC should be reported. That is quite relevant for understanding how consistent was the hardware commissioning.

Added numbers to section 2.

e) (section 3.1) It could be worth explaining clearly which of the HLTs used in this test were specific for cosmic rays and which ones are also foreseen for LHC. ( line 165 -179 , lines 151- 163 etc)

Some text has been added to the discussion of the non-pass-through triggers regarding collisions/cosmics.

Section 4 OK

Section 5

f) (section 5.3) The CPU time reported in table 1 of 47 ms/events is quite large compared to the figures reported for the required CPU times at LHC per event in section 2 (line 60: 40ms). Need some explanations.

It is not correct to attempt a comparison between those two numbers because the algorithms are optimized for collision events and not for for cosmic events. In addition, trivial prescales and minimal rejection are applied during cosmic runs. For collisions they will be fine tuned. Initially, we had a couple of sentences explaining this, but after interacting with the ARC we opted to drop them. The title of the sections is clear, we do not attempt to measure the cpu-performance for collisions but monitor the timing of the algorithms.

Outlook

g) A number of very important results achieved mentioned in the “Outlook” had no corresponding explanation in any section. Some of them are very important since they point out achievements that can be performed only with real data.

These results were referred to in Section 5.3. We have added more information there now.

Suggestion and specific comments

Abstract Second line Add the year of the CRAFT Second line “candidate trigger menus”: obscure. Remove the word “candidate” or change…

Both done.

Section 1 :Introduction line 3 “The 12,500 tonne detector features nearly 4 complete solid-angle coverage and can precisely measure electrons, photons, muons, jets and 5 missing energy over a large range of particle energies.”

We think that it is better focusing on the description of CMS for what is strictly concerning the HLT functionalities. Like “The 12,500 tonne detector features nearly 4 complete solid-angle coverage and can precisely measure electrons, photons, muons, jets and 5 missing energy over a large range of particle energies--􏰛 based on the readout and analysis of the xxx (??) Millions of the tracker, calorimeters and muon detector channels”

Since this paper is expected to also serve as a stand-alone CMS paper, we have kept the general description as is. But we have expanded on the HLT description.

line 9 Much emphasis that we have 2 instead of 3 trigger level: I would say that it's more relevant to point out that we have 1 hw level and the directly sw. Also, in section two and 5.1.3, L2 and L3 are mentioned: can be confusing. We would suggest removing the last part of line 11 from ” unlike…” . “The experiment has 10 a two-level trigger system, unlike most other hadron collider experiments which have more 11 traditional three-level systems. The first physical level is hardware-based and is called the 12 “Level-1 Trigger” (or L1) and a the second physical level is software-based and is called the 13 “High-Level Trigger” (or HLT). “

A 2-level trigger system is rather special and we feel that it deserves to be compared to the more traditional three-level. And therefore, we have kept some of the discussion, However, we have followed your advice and tried to emphasize that the L1 system is hardware based while HLT is software-based.

lines 14-19 are not necessary in the introduction. They should be displaced in one of the following section ( beginning of section 3).

Since the paper guidelines explicitly mention that we have to have an outline of the paper in the first section, we have to introduce CRAFT before that.

line 21 21 Report here explicitly why it is worth to have a paper on HLT performances with cosmic data even thought no reduction was required due to the poor rate. See general comments on the introduction.

We have added some sentences here.

line 35 35 In addition to the above, the CMS experiment has a two-level trigger system. I do not like “In addition” and, since later a “level 2” and a “level 3” are introduced, I would suggest to change lines 35-42 as follow: 35“The trigger of the experiment has a hardware based first L1 trigger and a software based HLT system. The L1 trigger is built mostly of custom hardware and is designed to reduce the event rate to 100 kHz at the LHC design luminosity of 1034 cm−2s−1.

We have removed "In addition" and rephrased.

line 36 36 the design and its implementation can be found in Ref. [3, 4]. The first level trigger (or L1) Remove “ (or L1)” being already defined at line 12.

Done

line 38 Is it the best way for introducing the L1 ? It seems it is software based…

Now we explicitly state earlier that L1 is hardware-based.

line. 43 on: I would avoid description of a "typical" experiment and concentrate on what CMS does. Also, here might be a good place where to describe even quickly the general architecture of filter farm, including definition of FU and SM.

Since the two-level trigger system is not so common, we feel it deserves to be compared to the typical trigger system. We have added some of the DAQ/EvF description.

lines 49-50: "advances" instead of "advancements"? Content at lines 52-55 is rather obscure.

Improved

line 52 on: rather vague: it's a bit scary to read "estimate" for # of CPU for an experiment which will start data taking in months.

Line 58 "It has been estimated...": one expects to know how many processors have been effectively used and which was their real performance during CRAFT and in case how their number should scale for the needs during proton collisions.

Both points are addressed now.

Line 68 "use of non-expert shifters to ensure the quality of data-taking" sounds a strange point.

Removed.

Section 3 We would prefer lines 16-18 and lines 63-69 were displaced at the beginning of section 3. All re-arranged, section 3 is reported below. In the present draft all these information are spread in the introduction, in section 2 and in section 3. May be it is better to have them in the same section and since you defines a section called “HLT during Craft”, that can be the place. A short description of the strategy of the HLT commissioning should be introduced here

We believe a description of the commissioning period naturally belongs in the introduction. Lines 63-69 have been rewritten to provide a more natural introduction to Section 3. Some additional text relating to the strategy of HLT commissioning was added to this section.

line 66 Was the calibration and the alignment performed on HLT CPUs ? is it foreseen to be done in HLT CPUS? The HLT accepts events for alignment and calibration that are analyzed offline.

line 72 "regardless of detector conditions" is extremely vague specification. True, but this avoids iterating all possible cases of detector problems, such as noise, missing regions of a detector, missing a detector entirely, more activity than anticipated from Monte Carlo, etc.

lines 82, 99, 120 and somewhere else specifying that HLT is intended to process L1 passed events sounds quite irritatingly redundant. Line 99: It is important to note that ALL HLTs see every event passed by L1. Removed lines 120 and 146.

line 89-91 and line 91-92. One of the two has to be removed Done.

line 92. remove one of the double “would” Line 91-95 unclear Fixed and rephrased.

line 96. “The triggers present in the HLT menus ...” add for better definition of which triggers .. Rephrased.

line 98-99 The sentence “ All trigger......decision” is already expressed in the previous one and example is presented on the next one. Can be removed ... It is important to note (to prevent confusion) that every trigger sees all L1 events. The second half of the sentence has been removed.

lines 105-107 Obscure. How LHC bunch structure is simulated in cosmic? By who ? L1, HLT, DAQ? The important point is that the arrival of the "gap" calibration trigger is reliable, regardless of whether or not CMS is using the LHC clock. Additional details tend to place more emphasis on this trigger than is necessary, and is not suited for this paper.

line.121: a bit strange to define "physics" technical trigger It depends entirely on how the technical triggers are configured. The HF technical trigger is configured to record collision events. Any non-physics bit can be masked, but the algorithm and technical bits are given the same event type by GT.

line 165 can the “near the L1 muon seed” be more precise..as it is, is quite useless as definition... Removed.

line 181 The adverb “reliable” is a little too poor for explaining the performance of all your effort during CRAFT. Changed to a forward reference to Section 5.

lines 184-185 are obscure. Rephrased.

line 203 "behavior" should be "beaviour"; the whole sentence sound quite vague. Fixed.%Details are fairly technical and we think best avoided.

Section 3.2 Throughout these section sometimes one has verbs with different tense even in the same sentence. After editing, tenses appear to be (more) aligned.

Not clear what is meant with offline and online .The strategy used during CRAFT could be introduced at beginning of section 3. That could help for understanding all steps described in section 3.2 Some introduction has been provided, and hopefully the meaning is more clear.

line 215: error stream is analyzed on-line to try a second guess or off-line, post-mortem to see what went wrong? Not clear. Added "offline" to the sentence to hopefully clarify the issue.

Section 4. line 228: should emphasize that the stream definition here is for cosmic, and not for real pp collision. Some confusion concerning stream and PD: a stream is a subset of events or contains a fraction of each single events (namely, some collection is dropped), or a mixture of the two? The description at the beginning is generic - applies to collisions as well. A stream is made of a group of triggers which have the same event content (products). A stream is split into PDs where a PD is a (sub)-group of triggers that has similar selection - for eg. "Muon PD", "Electron PD"..

Sec 4.2: line 300: worth mentioning that ECAL has zero suppression, otherwise is funny that a pi_0 takes 1.5 kB and the whole ECAL 5 kB, namely as 3 pi_0. Do not think so because it is not only due to zero suppression (which is BTW zero suppression + selective readout so more complicate to explain), but it is also due to the fact that we are running on minimum bias events so with a few RecHits and RecHits size is negligeable, the main event size is due to event header and not the content of the event.

Line 370-371: It is not clear how plot of fig 1 quantify HLT performance. The plot shows the ratio of each trigger path. The rate is simply calculated by "# of events passing * trigger/ # of events passing HLT_L1MuOpen trigger". We add some more texts why we show this plot.

Sec 5.1.3 See above: here L2/ L3 muons, elsewhere said that we have just 2 levels in total (L1 included). We start the sentence like "subdivides HLT processing into two logical steps", and this means the steps are substeps of HLT processing and not the trigger design per se.

line 354: "as is standard" : drop DONE

line 370: "this allows us to" seem more a statement about what can be done and will be done in some future rather than a report on the work done. Likewise line 366 : "we can use". We remove this sentence to avoid confusion

section 5.3 line 456: in some place (eg muon reco) regional reconstruction is mentioned as a way to speed up things: seems to contradict with fix data-unpacking CPU time. Maybe worth emphasize that regional reco does not include of regional unpacking.

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 decision.

Table 1 47 ms is a good timing for HLT with almost all the detectors in, but in most of the case there were just one muon passing in CMS and little else. How this 47 ms can be compared to a more complex pp collision?

Ditto the answer for you previous comment, i.e., we can't compare the two timing numbers because the algorithms (prescales/rejection) are not optimized for cosmics.

Section 6. Outlook is fine for a work-in-progress presentation: would use conclusion. line 463/69: is quite general and not much informative. CMS always knew that HLT was critical, cannot be a conclusion of current work. Need rephrasing.

Re-phrased.

line 478: the information here is very important, but is mentioned only in the conclusion. I would said that this part has been a significant part of the commissioning work, maybe it deserve to be described in the core of the text.

A couple of lines of text has been added to Section 5.3 to explicitly discuss this point.

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r2 - 2009-10-30 - unknown
 
    • 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