sPHENIX EMCal discussion

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

Hello John (cc same),

Not hearing any objections, I made the changes I suggested to Chapter 1.   However, right now nothing in Overleaf/gif compiles, and so I cannot check that everything worked and appears as it should.

It might be helpful at some point if Brant as Editor can resolve these issues or how to handle them better in the future (like not using Overleaf).

Sincerely,

Jamie

On Wed, Oct 21, 2015 at 2:28 PM, Jamie Nagle <jamie.nagle AT colorado.edu> wrote:

Hello John (cc same sPHENIX lists),

I have read through Chapter 1 and have the following comments / suggestions.   I include below the comments from one member of the PMG on this Chapter:

"Chapter 1:
========
As the document is for a more technical committee I think chapter 1 has to many "theory" plots instead of plots showing truly the sPHENIX performance.  This means I give a plot which shows the statistical precision  can obtain on a observables which needs to be measured to address a certain theoretical question.  It would be even better if a before and after sPHENIX data could be shown, but I understand that this is difficult in HI physics as many models don't even provide uncertainty bands which could be reduced by new data.  But if there are 1 or 2 observables this would be possible it would be good to have these plots.

The assumptions how to take the data sets are missing"

As advised by Ed O'Brien, I am not suggesting to remove any theory figures.    I do have two additional figures (one a replacement) that include sPHENIX projections and particularly one with the jet quenching calculations with different virtuality assumptions that can be discriminated between.    I have attached these figures to this email.

On the assumptions regarding the data sets - i.e. how long is the running, what are the DAQ livetime, RHIC uptime, etc. requirements - I can write a few paragraphs on this if desired though I am not sure where the management wants to put these in the document...  Right now there is just the footnote #1 in this Chapter 1.

I have already implemented some minor type-Os and do not list those below.  

Sincerely,

Jamie

1.   It would be very helpful (probably even for the review committee) to turn on line numbers for the entire document.  I recommend doing this immediately since it also helps with sending in comments.

2.  Figure 1.4 - it would be good to adjust the right figure to have the same height as the left figure.

3.  Figure 1.5 - also adjust the right figure height to match (looking sharp matters)

4.  Figure 1.6 - right, the attached file is the same figure and now including the sPHENIX projected uncertainties.   I think it would be good to swap this in and add just one sentence to the text...   "Also shown are the sPHENIX projected uncertainties indicating that the experimental measurement can easily discriminate between virtuality evolution scenarios."

5.   First paragraph of section 1.5.2 starting with "Detector upgrades ..."   This seems out of place and I would suggest to remove it.    The "RHIC results" here are supposed to be on jet results compared to the previous LHC jet results section.

6.  Figure 1.10 could easily be removed and just take out the sentence at the end of the first paragraph in section 1.7.1

7.   Suggest after Figure 1.11 to add a new figure as attached with our sPHENIX projected uncertainties for gamma-jet.   One can then add a new paragraph #3 as "Shown in Figure XXX are the projected sPHENIX uncertainies for the highly differential gamma-jet correlation in mid-central Au+Au events as a function of the path through the QGP medium.    In these mid-central events, substantial modification is expected and the backgrounds are dramatically reduced."

8.  Section 1.9.1 heading "J/psi" seems misplaced.   We do not talk about measuring J/Psi in sPHENIX (though we can at very high pT).   These couple of paragraphs were in the proposal motivating why Upsilons were important.  I would remove this subsection heading... and have the title of 1.9 be "Upsilons" instead of "Quarkonia"

9.  Footnote #1 - this is a very brief description justifying the data sample expected.  Do we want more or is that requested - and then where do you want that in the document?

10.   There is also a nice R_pA projected uncertainties figure and the jet FF uncertainties (with theory) figure from the proposal.   If those are desired, they could be added. 

On Wed, Oct 21, 2015 at 10:02 AM, Jamie Nagle <jamie.nagle AT colorado.edu> wrote:

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

--

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

--

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