sPHENIX EMCal discussion

[David Morrison <dave AT bnl.gov>]

Hi all,

When I try to build, I get this:

$ make
rubber -fdv 0main
sci_obj_perf/sci_obj_perf.tex:530: graphics `figs/figure_sphenix_gammajet' 
not found
compiling 0main.tex...
There were errors compiling 0main.
sci_obj_perf/sci_obj_perf.tex:530: File `figs/figure_sphenix_gammajet' not 
found.
sci_obj_perf/sci_obj_perf.tex:530: leading text: 
...linewidth]{figs/figure_sphenix_gammajet}}
0main.tex: File `det_overview/det_overview.tex' not found.
0main.tex:74: Emergency stop.
0main.tex:74: leading text: \input{det_overview/det_overview}
make: *** [0main.pdf] Error 1

And sure enough, I don’t see figs/figure_sphenix_gammajet.pdf or 
det_overview/det_overview.tex.

Cheers,
Dave

> On Oct 23, 2015, at 3:35 PM, Jamie Nagle <jamie.nagle AT colorado.edu> wrote:
> 
> 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
> ||---------------------------------------------------------------------------------
> _______________________________________________
> Sphenix-hcal-l mailing list
> Sphenix-hcal-l AT lists.bnl.gov
> https://lists.bnl.gov/mailman/listinfo/sphenix-hcal-l

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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail