Skip to Content.
Sympa Menu

sphenix-emcal-l - [Sphenix-emcal-l] Fwd: Re: Comments to Draft sPHENIX pCDR, more from PMG

sphenix-emcal-l AT lists.bnl.gov

Subject: sPHENIX EMCal discussion

List archive

Chronological Thread  
  • From: John Haggerty <haggerty AT bnl.gov>
  • To: "sphenix-emcal-l AT lists.bnl.gov" <sphenix-emcal-l AT lists.bnl.gov>, "sphenix-hcal-l AT lists.bnl.gov" <sphenix-hcal-l AT lists.bnl.gov>, sphenix-tracking-l AT lists.bnl.gov
  • Subject: [Sphenix-emcal-l] Fwd: Re: Comments to Draft sPHENIX pCDR, more from PMG
  • Date: Tue, 13 Oct 2015 14:47:40 -0400

Here are some more comments from our PMG advisors.

-------- Forwarded Message --------
Subject: Re: Comments to Draft sPHENIX pCDR
Date: Tue, 13 Oct 2015 11:16:51 -0400
From: Bill Christie <christie AT bnl.gov>
To: Aschenauer Elke-Caroline <elke AT bnl.gov>
CC: Haggerty, John <haggerty AT bnl.gov>, Kotcher, Jonathan <kotcher AT bnl.gov>, Lissauer, David <lissauer AT bnl.gov>, Mueller, Berndt <bmueller AT bnl.gov>, O'Brien, Edward <eobrien AT bnl.gov>, Makdisi, Yousef I <makdisi AT bnl.gov>, Ma, Hong <hma AT bnl.gov>, Thomas Roser <roser AT bnl.gov>, Pile, Philip H <pile AT bnl.gov>, Dunlop, James C <dunlop AT bnl.gov>, Mills, James A <mills AT bnl.gov>, William Christie <christie AT bnl.gov>

Hi All,
I've read various portions of the pCDR over the past week. I'll
have to go through them again to list comments, but below please find
comments on Chapters 2 and 10. As a general statement, this document, as
given to us to read, is very far from the shape it needs to be in for
any useful/valid review of the conceptual design, let alone the cost and
schedule. Through out the document almost all details, discussion,
simulations, plots, etc. that one needs to demonstrate that the
conceptual design can meet the requirements are missing. We can discuss
this in the mtg this afternoon, but I see this as a serious problem.

Chapter 2:
On pg 34, there is a Trigger eff. req. of > 90% for e+- from Upsilon
decay. I'd suggest that there is a purity req. for this trigger as well,
other wise it the trigger could possibly take too much DAQ bandwidth.

Same sect., there is a stringent momentum req. of 1.2 % for Pt up to 10
GeV. Somewhere in the document there needs to be a discussion and
simulation showing what it takes to meet this req. This is a general
comment that applies for most of the requirements listed for the
detector system. In a conceptual design one needs to demonstrate that
the concept can meet the requirements.

I'd like to see, either in this section that gives an overview of the
detector system, or somewhere in the document, a description and fig.
showing how the deadtime of the combined Trigger & DAQ system changes
with the event rate.

For Fig. 2.1 right, to carry any real information, the Energy of the
leading Jet has to be given. Di-jets get kinematically focused to be
back to back in eta as the energy of the jets increases.

Sect. 2.2, 2.3, 2.4, all refer to currently non existent discussions,
simulations, and figs. These missing details have to get included.

The document needs more details on the Trigger system in particular, but
also on the DAQ. In particular it should list the timing req. for when
the L1 trigger decision must be made, as well as the time when this
decision is available at all f the FEMs. With these numbers, and the
interaction rate, one can get a good idea on the possible deadtime
characteristics of the overall system. The Trigger system description
talks about making Jet patch triggers, correlating Silicon measured
multiplicities with other Trigger info., etc. This requires very fast
collection and assembly of the Trigger data, yet all the Trigger system
states is that a Trigger system design is needed.

Ch. 10:
In section 10.1.1, there is a "Clearance Req. of 2 inches between
subsystems. This requirement seems far too broad. If the EMCAL rails
attach to the inner HCAL, how does one get 2 inches of separation? I
suggest deleting this req.

The req. on positional accuracy of all components of the magnet and
entire detector assembly is too broad, and will not be met. A overall
system level Req. on this could be that each sub system will define
there particular positional accuracy reqs., and between the internal sub
system req. and as relevant the infrastructure system will have to allow
these reqs. to be met.

The temp. and humidity req. in this section is way too broad, and again
can never be met as stated. Light weight, sensitive structures like TPC
gas vessels and silicon wafers onto support structures typically can't
survive the thermal stresses of large temp. swings. We alarm and take
action for any temp swing of more than 10 F for the STAR TPC at anytime
since it was fabricated. If this is the spec. on your complete design
all environmental control for the IR can be eliminated, other than
heaters to keep the temp greater than -10 C. This reads like an
electronics spec. that has been stated as a system wide req., and has to
be fixed.

The IR cooling req. talks about 50 F water for rack cooling. It is fine
t spec. that the system can deliver water this cold, but I'd suggest
that the cooling systems in the racks be designed to be able to cool
sufficiently with water temps up to about 58 F. It may take a bit more
flow, or radiators in the racks with a bit more surface area (you could
look at the STAR rack radiators), but will result in more achievable
humidity/dew point reqs. for the IR environmental control system. In the
Spring we often reach dew points in the STAR IR as high as 58 F.

Check/correct all Fig. numbers. The text refers to them as though in Ch
9, and also have incorrect sub numbers.

In sect. 10.1.6 there is a req. that all comp. of all sub sys must be
accessible during a shutdown of three months or more. I seriously doubt
that the design will be able to creditably allow this. It can be
softened to indicate that any particular component, with the exception
of the Magnet, can be made accessible.

On pg 186 it is discussed that the roller system will allow both
East-West and North-South movement of the CP. Unless this is required
for the assembly process outside the IR, I don't understand the req. to
translate the detector along the beam line direction. If movement in
this other direction is required for the assembly, then a spec. on how
far off axis it has to be translated should be listed somewhere.

On the same page s a description of what reads like a thick steel plate
that makes the CP. If this is a thick plate of steel it is going to suck
in magnetic flux lines. This could perhaps lead to strong enough fields
to impact the voltage transformers in the racks. Suggestion is to think
about it a bit in the design for the CP.

On page 189, and I believe other places, it describes a design for the
rail system that supports the EMC modules that allows for alignment and
positioning during the EMC installation. I think this would be a very
challenging system to design. As I recall for STAR, we did careful
alignment of the EMC rails when the rails themselves were installed, and
then left sufficient tolerance between the emc modules so that the
movement allowed by the roller bearing assemblies at the various
orientations didn't lead to interferences during installation. We also
picked a deliberate order for the installation, to account for the sage
of the modules on the sides due to gravity (i.e. slop in the bearing
assemblies). I guess the comment is to consider carefully whether a rail
alignment adjustment during EMC installation is necessary.

On pg 191 it is described that after a partial assembly of the detector
it is rolled into the IR and mapped. A question that comes to my mind is
whether enough of the internal structures (inner HCAL, support rings)
are present so that the map represents the filed for the assembled
detector. I understand that these other structures will be made from
"non-magnetic" S. Steel, but it would be good to at least address this.
A req. that would be good to list here is the precision that is needed
for the field map to allow the overall detector system to achieve it's
very stringent Pt resolution requirements.

Side comment, I'd be curious to hear how the heavy monorail beam used
for the HCAL installation gets both inserted, and then removed, for the
HCAL installation. This looks like a bit of an engineering challenge.

On pg 93, as the assembly seq. progresses, you finally get to the
installation of the tracker. What is missing is any discussion of the
beam pipe through the center of the detector, and how it gets supported.
My guess is that the central portion of the beam pipe will have to be
supported by the tracker structure, and inserted with the assembled
tracker. For a sense of completeness for the overall conceptual design
it would be good to include some discussion of the plan.

On page 194, sect. 10.5, it mentions an alternative design where the
flux return endcaps are on separate (from the CP) carriages. If not too
difficult or costly I'd suggest you give this serious consideration.
This is what we did in STAR, and although we designed rail system in the
Assembly Bldg in case we ever wanted to bring the poletips out of the IR
with the detector we've never used them. Having these separate carraiges
would allow you to leave the end flux return structures behind, and free
up valuable space in the Assembly Bldg when work is required on the
detector.
Greetings,
Bill





--
John Haggerty
email: haggerty AT bnl.gov
cell: 631 741 3358





  • [Sphenix-emcal-l] Fwd: Re: Comments to Draft sPHENIX pCDR, more from PMG, John Haggerty, 10/13/2015

Archive powered by MHonArc 2.6.24.

Top of Page