sPHENIX EMCal discussion

[Jamie Nagle <jamie.nagle AT colorado.edu>]

Hello John (cc same sPHENIX lists),

Our group in Colorado has divided up some of the pCDR chapters for reading and will be sending comments later today.   Here I am just sending comments on Chapter 8 - Data Acquisition and Trigger.   This Chapter has some significant issues and may need some major restructuring in order not to raise red flags to a review committee.

Sincerely,

Jamie

1.  First, my recommendation is that all Chapters should start with a few sentences before the first subsection (e.g. 8.1) that lays out what is covered in the Chapter and a brief summary.    Here is a list of the key points I would have expected in the DAQ and Trigger Chapter

In this Chapter we detail the architecture of the sPHENIX data acquisition system and the requirements to achieve a 15 kHz data accept and archive rate even in high multiplicity Au+Au at 200 GeV collisions and with > 90% livetime.   In the case of Au+Au collisions, we expect to record with only minimum bias triggers (i.e. a simple interaction trigger) of order 100 billion events in a 22-week running period.    There are also selective jet and photon triggers that can sample additional physics from the entire luminosity.  In p+p and p+A collisions at 200 GeV, selective triggers are detailed utilizing the EMCal, HCal, and potentially from the tracking system.   ???

2.  Right up front, there are disconnects in this section.    One might start with saying that in the reference design (is that the nomenclature in the pCDR), the subsystems include the existing VTX pixels, new silicon strip detectors, EMCal, HCal, and a new BBC.    One can then say that all of these systems would run within a fully pipelined, deadtimeless DAQ architecture similar to PHENIX.   

It would then we good to have a table of the expected data volume from each system in Au+Au minimum bias collisions.   Are we zero suppressing the calorimeter (EMCal or HCal) - that will be an obvious ATLAS person question since they do not zero suppress I believe.    This results in some number that I believe is about a factor of 2 higher data volume per event than current PHENIX and combined with a factor of 3 higher bandwidth - so 6 times archiving rate is needed (?).    That is a key number.

Also, the EMCal and HCal do not buffer and then digitize, they digitize every crossing - so there is no analog pipeline, only a digital pipeline (which is much better and means fully digitized information in available in the trigger).

It would be good to point out that the VTX pixels that exist were tested at 15 kHz and so meet the specification.

What is the data volume per link to the DCM 2 -- a table would be good that shows things are within spec.  Not to hard to calculate.   I would suggest to eliminate all discussion of the DCM, and just focus on the DCM 2 which is what will be exclusively used.   The drawing in Figure 8.1 then needs an update.

3.  Now if we are not in the reference design and use the TPC, then the DAQ is in my mind almost like two separate DAQs.   One that is fully pipelined etc., and one that is free streaming and somehow they are correlated via time stamps in the offline software.    That needs at least a section and reference back to the TPC option description.

4.  I would not mention Level-2 triggers, and then that they are not needed.    One has to demonstrate with numbers as noted above that the bandwidth in the fiber links to the DCM 2 works, and then the back end archiving works.

5.   One switches back and forth between buffering of 4 versus 5 events.   My understanding in PHENIX is that the specification was 5 events, but there is a logic hole (not mean as a negative) with GL1 and the timing, such that one has to run with N-1 or 4 buffering.     If we are not describing a replacement of GL1, then we need to use 4 as you show in Figure 8.2.  

6.   Section 8.1.2 is unclear to me in terms of the benefit of inclusion here.    We are largely asserting that the current EVB architecture would work and that is probably enough, and does not close off other options later.

7.   Triggering needs an overview to start.   First off, I think we have different trigger requirements...

a)   For Au+Au events we need a simple interaction trigger, and what we really need is a Level-1 value for the z-vertex of the collision (ideally with a resolution < 1 cm).   That is important because otherwise we would be wasting a fair bandwidth of events that end up outside the nominal +/- 10 cm acceptance for the inner tracking.    It would be good if this trigger fires on > 90% of the Au+Au inelastic collisions as well (more is better, but 98% or something like that is just not crucial to any of the physics). 

As far as I know, we do not have a physics requirement for a start time.    Even a very coarse start time could be helpful in cleaning up backgrounds as is done in PHENIX in p+p with the EMCal.  

b)   EMCal and HCal triggers - these need to be included in this Chapter and can then refer to other sections.   For Au+Au, the photon and jet triggers were shown in the proposal to work to sample the highest energies with the full luminosity (including over the wider z-vertex range which is fine for purely calorimetric measurements - e.g. photon-jet correlations).    This was an important part of the claim to sample 2/3 trillion Au+Au events in these rare channels.

They are also needed for p+p and p+A for photons, jets, and also electrons for the Upsilon -- all of these figures exist in the proposal and may be in other places in the pCDR.   Then just a table of triggers and a few sentences with references in fine.

c)    Multiplicity trigger - this section will be opaque to the reader.  The Figure 8.4 does not indicate p+p, nor does the text detail what physics is being pursued.    What might be quite interesting is a Level-1 silicon trigger that gives a z-vertex in Au+Au -- since we really need that....

Again, I would start with the table and then one needs a clear explanation for each system (e.g. p+A) what trigger rejections are needed and thus to show a bandwidth allocation chart.

Many of the numbers I mention above exist or I have calculated in the past.   Please let me know if there are specific items that I can be most helpful with.

On Tue, Oct 20, 2015 at 8:11 AM, David Morrison <dave AT bnl.gov> wrote:

Hi John et al,

I’ve read a fair bit of the pCDR and to respond to your rallying cry of “crowdsource!” I’d like to touch up the writing in the magnet chapter.  Nothing technical and nothing too extensive, but there are typos and clunky sentences scattered throughout.

Dave

> On Oct 17, 2015, at 9:00 AM, John Haggerty <haggerty AT bnl.gov> wrote:
>
> Hello,
>
> I put version 0.99 of the sPHENIX Pre-Conceptual Design Report on an
> Indico page here:
>
>> https://indico.bnl.gov/conferenceDisplay.py?confId=1483
>
> (the pCDR link) which should be accessible to PHENIX and non-PHENIX
> alike.  There is still work going on to complete the document, but the
> hard deadline is to have it complete for the review committee two weeks
> in advance, on Monday, October 26.  PHENIX tradition is a one week
> comment period which will be up next Saturday (October 24), but the
> sooner comments can be received and acted upon by the many authors and
> editors, the better, so if you could make comments and corrections by
> Thursday, that will give us more time to finalize the TeX and clean up
> any figures that still need cleaning up.
>
> I would like to try crowdsourcing the small grammatical corrections that
> take a lot of time in finalizing a  document like this from many
> authors--if you see small changes in working that are needed, try fixing
> them on the Overleaf site itself:
>
>> https://www.overleaf.com/2657127qghjbm
>
> This document has really been a collaborative effort, with writing,
> editing, figures, simulation, and engineering from a large and diverse
> group of people who have come together around this proposal, and it's
> gratifying to see it come together.  It has always impressed me how
> PHENIX comes together to get a job done, and it looks like sPHENIX is
> following that example.
>
> --
> John Haggerty
> email: haggerty AT bnl.gov
> cell: 631 741 3358
> _______________________________________________

> Sphenix-tracking-l mailing list
> Sphenix-tracking-l AT lists.bnl.gov
> https://lists.bnl.gov/mailman/listinfo/sphenix-tracking-l

David Morrison  Brookhaven National Laboratory  phone: 631-344-5840
                                Physics Department, Bldg 510 C  email: dave AT bnl.gov
                                Upton, NY 11973-5000






_______________________________________________
Sphenix-hcal-l mailing list
Sphenix-hcal-l AT lists.bnl.gov
https://lists.bnl.gov/mailman/listinfo/sphenix-hcal-l

--

||--------------------------------------------------------------------------------
|| James L. Nagle   
|| Professor of Physics, University of Colorado, Boulder
|| EMAIL:   jamie.nagle AT colorado.edu
|| SKYPE:  jamie-nagle        
|| WEB:      http://spot.colorado.edu/~naglej 
||---------------------------------------------------------------------------------