ARC Review

Guidelines for response

Insert replies/responses in different color. For eg. Answer: ....

Comments from Sarah (August 14th, 2009):

Major Comments

* I still don't think we need sections 3.2.2.- 3.2.5 We could maybe just mention the number of AlCaRaw's, the range in event sizes (compared to typical event sizes) and the range of rates.

* line 410. what you call an efficiecy is not, to my mind, an efficiency. It is more a kind of acceptance, and, to my mind, not a very interesting acceptance. To my mind, Figure 1 is a plot that only a mother could love. Why are you wasting my time with this plot? smile What am I learning? To me, the only possible response to this plot is a shrug. Since I have no idea what this plot should look like, I have no idea what it is telling me about trigger performance. You say it allows you to "study" the performance, but the conclusion I draw is that you didn't "study" very hard smile Since I trust you actually did study hard, we don't want this paper to give the wrong impression, right? You made a very basic plot. So what? This is not worth publishing. If you did some studies that showed from MC that these acceptances are what we expect, that would be different...

* I also still have problems with section 4.2. It seems to me that this section is not finished or something. Perhaps you could comment if the time in real operation is the same as was expected from the results of the test farm? At least that would be some kind of conclusion. I really have problems with line 453. I guess it would help if you said that you expected it to take 47 ms based on simulations and tests on the test farm, and so this leads support to simulations that say that the real beam menu will take less than 40 ms?

* I'm not convinced we need section 4.3. What does the reader learn from this except that CMS has the same kind of online DQM that every experiment has had since the dawn of time? (or at least in the 25 years that I've been a physicist.) could we maybe shorten this a great deal? The plots don't have any interesting information. I would delete all of them except maybe figure 4 (although, while I like the discussion that goes with this figure, I don't think the figure gives additional useful information or clarifies information beyond what is in the text). To me, the most useful parts were 481-483, 488-497, 501-508, 524-538, 604-614

Anyway, if you don't want readers to just skip most of this section, I'd see how short I could make it without removing the essential information that you think deserves to be archived.

Grammar/Style issues

change title to "Performance of the CMS High Level Trigger during Cosmic Ray Data Taking" (or something like that)

Significantly shorten the current introduction. Move the detailed description of CMS and the trigger to a new second session. (In the intro, the first paragraph is enough of a description). Add text like: "In this paper, we outline the implementation of this method. The method is tested using the W boson mass and width measurements. Only the electron decay channel is discussed, but our method can also be used in the muon decay channel. The detector and selection criteria are described in Section 2. The MC simulation samples used are described in Section 3. We discuss the method in Section 4. In Sections 5 and 6, we assess the uncertainty on the W boson mass and width measurements, and compare the performance of this method with that of a parameterized recoil model. The paper concludes in Section 7." to the end of the new introduction

line 9. but the field is 3.8T, not 4T

line 13: you have not yet defined the rapidity regions corresponding to central and forward

line 14: I'm not sure what is "extensive" about the HF

keep line 15. then move lines 16-48 to a new second section.

line 20. "This two-tier... below" provides no information. delete it.

line 26: do you mean "as a result of" or something more like "in order to allow"

line 38. You say "full-granularity data from the whole detector", but when you describe the muon triggers below, it is clear that the "whole detector data" can not be used immediately, and that some local processing is needed before the full data is, what? reconstructed? is the whole event read in but full reconstruction is postphoned until the "l2" described later is done? Or is the whole event not read into the Event Filter Farm until the "l2" described in the detailed description of the muon trigger. For example, when I look at lines 158-172, it seems clear from this text that our HLT has the same regional restrctions found in a traditional L2.

line 51: need comma after "and"

line 60 replace "with" with "due to"

line 61: I think "expert shifters" and "non-expert shifters" is jargon.

somewhere, please say how many processers were used and maybe even what their models were.

line 75: any -> at least one

line 83. what exactly does "masked" mean? does it mean the global trigger ignored them when making its decision?

line 85: okay, from this it seems "masked" does not mean ignored by the GT. It seems the GT still uses them to do some calculation, but then it ignores then when making the final trigger decision? (or, the GT sends its bits up to something else, that makes the final trigger decision, and that thing ignores the "masked" GT bits?)

line 89 All triggers -> All HLT triggers

lines 130 random triggered -> random L1 triggered

line 135-138. What were the L1 seeds for this trigger?

line 164 the relevant tracker data were used to reconstruct tracks, or were used in a combined fit with the muon information? or? (the raw data themselves are not used.... some kind of track reconstruction is done...)

Section 2.2. I think this needs some sort of introduction. the trigger menu you just finished discussing in the previous section was not designed with these samples. Also, once we have collider data, the design of the trigger menu will be done mostly with real data, not MC samples. We use only MC samples now because we have no data. (so I'm still not convinced that this first statement is true).

For an introduction, say something like "During craft, we were also able to exercise our methodology for the deployment of new hlt trigger menus. When the LHC starts collisions, the intial table will have been designed from MC studies...

line 187. I still find "a minimal set of adjustments" very annoying. What exactly are these adjustments? currently, this "noun" contains no useful information.

line 197. What is "pickup"?

line 201 fed with -> fed (actually, fed??? I didn't think computers eat... animals eat...)

line 201. Again, we have switched (without saying this explicitly) from discussing pp running to cosmic running (or will we typically use cosmic events to verify the tables designed with MC min bias events?)

line 220. need comma after typically (or do you mean that only changing detector conditions that are typical needs modifications? and those that are atypical do not?)

line 268. put quotes around Tier-0

line 397 the tracking -> tracking

line 405: if HLT_OIstateTkMu3 was specially designed for cosmics, why does it accept only a small number of events?

line 406 when you say "a L3 muon reconstruction... beam position", do you mean a track reconstruction algorithm? or was the segment finding and linking within the muon system itself also specialized? In general, if you are going to bother to mention this trigger, describe it fully.

line 476. replace , with ;

line 483. preferred? maybe "has different use cases" or something like that. both are needed, right? even if they have different uses?

line 503. What's a "raw data product"?

line 630: which part of the CRAFT experience led you to think it important to have "simple, inclusive menus with a small set of robust triggers" I thought this was decided before CRAFT. Or, if I am right that this decision had nothing to do with CRAFT, what part of CRAFT confirmed that this was indeed necessary?

line 641-647. You needed CRAFT to make you realize this??? I doubt it.

-- TulikaBose - 07 Aug 2009

Edit | Attach | Watch | Print version | History: r28 < r27 < r26 < r25 < r24 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r26 - 2009-08-17 - TulikaBose
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Sandbox All webs login

  • Edit
  • Attach
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 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