March 30, 1999

RESPONSE TO THE

U.S. ATLAS PIXEL INTERNAL REVIEW

**11-12 MARCH 1999**

*This is the response of the Pixel System Team to the reviewer\'s
comments, questions and suggestions. For clarity, the review report is
reproduced in its entirety along with our responses in italics.*

**General Comments**

1.  All changes to the goals that appear in the project management plan
    must be accompanied by baseline change proposals.

*We expect the detailed goals (U.S. deliverables) to be defined at the
time of the baseline review in 2000. Given the evolution of the project,
technical choices made in the last two years and the needs of the
project, it\'s certain that there will be some changes from the goals
appearing in the Project Management plan. Since a baseline will only be
defined after the baseline review (by definition), a BCP would seem
unnecessary, but this is up to the Project Office.*

2.  It is difficult for reviewers to follow progress without clearly
    identified specifications and/or goals.

*We fundamentally disagree with this comment (at this time) but
understand the difficulty of the reviewers and will attempt to provide
the desired information at the next review.*

3.  There is a lot of critical work scheduled to be completed in
    September 1999. It may not be possible to determine project
    readiness for a summer 2000 baseline review until September. A slip
    in completion of those critical milestones should have a
    corresponding slip in the baseline review.

*We agree with the sense of this comment but believe September may be
too early to tell if a baseline review in summer 2000 is feasible. A
more realistic assessment will only be possible after the 2^nd^ internal
review, currently scheduled for December 1999. The date for this 2^nd^
internal review was set before the date for a complete U.S. ATLAS
cost-to-complete exercise was scheduled. We propose to modify the date
of the 2^nd^ internal review so that the review becomes part of the
cost-to-complete activity, and plan to have a draft baseline cost
estimate at that time as well as a technical and schedule update.*

**Electronics**

The U.S.ATLAS pixel group has made significant progress on electronics.
It is believed that they are on the right track in several areas:

1.  By combining the chip design efforts at CPPM, Bonn, and LBNL, all
    teams can share ownership of the final design

> *No comment.*

2.  The two vendor choices are reasonable at this time but cannot
    continue indefinitely. If one vendor is found that meets the basic
    chip requirements, that vendor may need to be chosen due to schedule
    requirements.

> *It is our plan to make a vendor choice after evaluation of the DMILL
> and HSOI prototypes. However, we agree with the statement.*

3.  It is appropriate to work on the DMILL submission first since there
    is more experience with DMILL than HSOI.

> *No comment.*

4.  It is appropriate to isolate each module as much as possible with
    separate power supplies and optical fibers.

> *No comment.*

5.  The removable B-layer is necessary despite the increased complexity
    associated with it, due to the high radiation levels close to the
    beam pipe.

> *No comment.*

There are, however, several weak points in the pixel design effort.

1.  The Honeywell SOI design effort is based on single transistor
    measurements and the HEP community has little experience with the
    HSOI process.

> *We have designed two prototype chips which include complete analog
> designs, with approximately 100 pixel preamplifier/discriminator
> channels, biassing circuitry, current-mode DACs and current
> references. This is all of the critical analog circuitry that exists
> in the present pixel FE chips. These designs were submitted for
> fabrication in an HSOI run in Nov. 98, and are due for delivery in
> early April. We also have individual transistors from these analog
> designs available for characterization. We intend to measure the
> performance of these test chips completely, and compare it against our
> simulations, using the actual performance of single transistors from
> the same run. We believe this will significantly reduce the chances of
> any surprises when we fabricate a complete FE pixel chip in HSOI. This
> information will be available rather early in the design cycle. In
> addition, the CMS collaboration has compared the same preamplifier
> design in both DMILL and HSOI, including irradiation effects. These
> results have been presented at conferences, and indicate that the
> analog performance of the HSOI process after irradiation is at least
> as good as that of DMILL.*

2.  There is only time for one DMILL and HSOI submission before
    baselining. A great deal of checking must be done to insure success.

> *We have significantly improved our verification procedures for the*
>
> *these submissions compared to what we did previously for our radsoft*
>
> *chips. We are now doing complete, delay-annotated Verilog
> simulations*
>
> *for the typical, best, and worst case transistor parameters. We
> intend*
>
> *to perform these simulations on the complete chip if possible. We
> will*
>
> *also do more extensive SPICE simulations than before. Finally, we
> plan*
>
> *to do a full flat LVS of the entire chip at least once (in the past,*
>
> *subsets of the complete chips were LVSed due to the extreme*
>
> *CPU/memory/disk requirements of the complete LVS). We are reasonably*
>
> *confident that no significant errors will sneak through these*
>
> *procedures.*

3.  Consideration should be given to the impact of single event upset
    (SEU). A detailed schematic of the minimum size flip-flop should be
    given to Honeywell to review SEU susceptibility.

*We have limited the use of dynamic CMOS logic to circuits whose values*

> *do not need to remain valid for longer than a few microsecs, in part*
>
> *to avoid nodes which are sensitive to small charge depositions from*
>
> *SEU. All FF which must store data for longer periods of time are*
>
> *static designs which require very large charges to change their*
>
> *states. In addition, the only critical FF (in which a change in
> state*
>
> *could affect the operation of the chip for an extended period of
> time)*
>
> *are in control registers at the bottom of the FE chip. These
> registers*
>
> *include a parity bit and continuous parity-check circuitry which
> will*
>
> *flag all events transmitted from the FE chip during the period in
> which*
>
> *the register parity is wrong. We intend to characterize these chips*
>
> *and measure the SEU rate. If it appears to be too high, we will*
>
> *replace these critical registers with more fault-tolerant designs*
>
> *in which injecting charge on a single node is not sufficient to*
>
> *change the stored value. We have discussed rad-hard FF designs with*
>
> *Honeywell, and the techniques which they use in their SRAM\'s could*
>
> *also be used by us, but with some potential speed penalties.*

4.  Corner models for the HSOI do not exist. This makes the performance
    difficult to predict.

> *We agree that this is a significant issue. In studying the DMILL*
>
> *corner models, we have realized that there are a small number of*
>
> *process parameters that the vendor is tracking, and then modifying*
>
> *in the SPICE models. We will discuss with Honeywell to get
> reasonable*
>
> *estimates for the variations in these parameters (mainly thresholds,*
>
> *mobilities, oxide thickness, and some capacitances), and use those*
>
> *for a corner analysis. This will be less rigorous than we would
> like,*
>
> *but should produce a design with decent yield and radiation
> hardness.*

5.  Long power supply leads to the modules may cause chip or performance
    failures due to spikes and transients.

> *We agree that this is a risk, and are beginning to design, simulate,*
>
> *and prototype the proposed power distribution and filtering system.*
>
> *We have some flexibility in the supply lead sizing, and also some*
>
> *space in one patch panel (PPB2) to add additional filtering and*
>
> *transient protection. The next generation of module support cards*
>
> *will allow us to build a realistic prototype of the entire supply*
>
> *plus cable plus module chain and operate it under various worst*
>
> *case scenarios. Until these tests are complete, we agree that this*
>
> *approach retains some significant risks.*

6.  The division of the design work between CPPM, Bonn, and LBNL appears
    reasonable (i.e. CPPM- frontend, LBNL- digital, Bonn- integration
    coordination). However the separation of design activities has its
    problems. A complete chip simulation is highly recommended.

> *We completely agree with this, and are trying to carry out parallel*
>
> *(almost independent and equivalent) simulations of the critical*
>
> *sub-circuits. We believe we will be able to perform a series of*
>
> *Verilog simulations (tuned to give realistic results at the*
>
> *sub-circuit level) on the full chip. We are also trying to review*
>
> *critical schematics and layout separately at two institutions to*
>
> *avoid slippage between different parts of the design. We believe*
>
> *we have established good, open relationships between the critical*
>
> *players at the three institutions, and we maintain frequent
> telephone*
>
> *contact.*

7.  The baseline review in May 2000 is expected to be based on
    well-tested and understood rad hard chip designs from both DMILL and
    HSOI. The schedule for baselining is success oriented. No room is
    left for an extra DMILL run or, in particular, another HSOI run if
    there is a design or foundry problem. Efforts to develop a 100 Mrad
    chip solution should not interfere with development of a 25 Mrad
    solution until a removable B-layer is well in hand.

> *We certainly agree that having a baseline review in May 2000 depends
> on a success-oriented schedule for the DMILL and HSOI prototypes. In
> fact, we noted at the review that we currently cannot meet this date
> and are projecting a few month delay. We plan to make every effort to
> restore the HSOI schedule, and thus the schedule for a baseline
> review. No separate development aimed at a 100 Mrad chip is planned at
> this time. However, we will irradiate the FE-D and FE-H (and the
> associated test chips) up to 100 Mrad or until failure. In addition to
> the intrinsic interest, it\'s clearly of importance to understand how
> much \"headroom\" exists even for the 25 Mrad requirement.*

Hybrids

The decision to use flexhybrids seems the right choice for the module
hybridization. The density and feature sizes used are conservative when
compared to other flexhybrids produced for other projects. However:

1.  All materials must be qualified for the radiation environment.

*We agree and these tests are (just) underway and are expected to
continue well into 2000.*

2.  A thermal analysis is needed.

*We are not quite sure what this means. Measurements have been done, for
example, of the temperature of the MCC chip mounted on a flex hybrid and
this does not appear to be a problem.*

3.  Revise hybrid schedule to show milestones for all prototype
    iterations.

*This will be done in time for the May monthly report.*

Module

1.  The pixel group must work with manufacturers to develop a bump
    bonding process that is more reliable and producible.

*The focus of the bump bonding effort so far has been two-fold. One, to
support the electronics + detector testing. Two, to demonstrate a
proof-of-principle that fine-pitch bump bonding is feasible. Both of
these have been successful. Production and quality issues are just
starting to be addressed now and we expect to make 50-100 modules over
the next year to gain valuable experience with at least two vendors and
possibly more.*

RODs

1\. The decision between DSP and FPGA based readout drivers is overdue
and should not be delayed any longer.

*A review to select a design approach is scheduled for March 25-26,
1999.*

Sensors

The work on sensor development is well along and in good shape. A good
understanding of sensor properties and evolution with radiation has been
developed.

1.  We would recommend that the collaboration explore some mechanism to
    certify each batch of sensors to radiation hardness, either by
    developing a test structure on each so that each batch can be
    radiation tested, or by using sample detectors from each batch.

*It was stated at the review that there was no such plan. However, it
would be possible to test single-chip detector assemblies from each
batch after irradiation and we will explore this possibility with the
collaboration.*

# MECHANICS

## OVERVIEW

Some mechanics issues require resolution at a higher level and need
coordination with groups outside of the Pixel System.

*We provided an overview of the mechanics system, including aspects for
which the U.S. has no current responsibility, in order to give the
review committee a global view of the mechanics and integration. We
concur with the statement from the committee but have limited capability
to resolve all interface issues with other systems.*

The timing for the Review is appropriate. It is early enough that the
Committee recommendations may be pursued without adverse impact to
project cost or schedule, as long as the recommendations are considered
now. These recommendations are intended to address weaknesses in the
current design and current development program, as well as identify
issues that are not yet addressed by the Pixel project effort.

## ATLAS LEVEL ISSUES

1.  The ATLAS Project Engineer must define guidelines for acceptable
    resonant frequencies.

*We note that there is a tradeoff between material and resonant
frequencies of the relevant structures. Since material has a direct
impact on track reconstruction, it\'s not the responsibility of the
Project Engineer alone to define guidelines for allowable resonant
frequencies. We have embarked on a careful prototype program to build
and evaluate all components of the mechanical structure. Only after this
evaluation is complete(by early 2000) is it appropriate to establish
firmer guidelines for acceptable resonant frequencies.*

2.  The Pixel Project Engineer responsibilities are being transferred
    and this may impact the schedule. CAD integration is important and
    must be continued.

*We are working hard to avoid any schedule impact. The current Project
Engineer(E. Anderssen) will continue to have integration responsibility
for the collaboration for services and cooling/power interconnect design
and fabrication in general.*

*There are always problems with sharing CAD data, most stem from lack of
common data and established boundaries, not the actual ability of the
CAD packages to import and export accurate geometry data, though this
can be a problem. For a collaborative effort to proceed there must be
definite check points at which ownership of geometry changes
hands---this is particularly important for sharing of native CAD files.
To affect this, compartments are established, Solid geometry
representing the current design envelopes will be banked centrally
(EDMS) in a neutral format, e.g. IGES and SET and native for those who
can benefit. This geometry is used by all to represent common boundaries
for parts designed in the neighborhood. Changes to envelope geometry
require an Engineering Change Request (ECR). It will be strongly
suggested that no two parties design parts in the same neighborhood at
the same time. This can be affected either through creation of a new
bounding envelope or through a more rigorous checkout procedure where
ownership of part geometries/responsibilities is transferred wholly, if
only temporarily. This is the most reliable way to work without the two
parties sharing a much closer link, namely residing on the same cad
system where this can be achieved via permissions. As designs become
baselined, geometry for baselined designs will be logged in EDMS and
subject to strict controls. Due to current limitations of EDMS, it will
be necessary for the Project Engineer to manually implement the ECR
procedure and to ensure proper design practice.*

*Concerns that remain are specifically tied to the ability to share data
with EUCLID, which is the CAD package CERN is using for the overall
integration of ATLAS. In principle, this should not be a problem as the
Pixel Detector's primary integration path is through the Inner Detector,
which is currently handled by Rutherford Appleton Laboratory (RAL) which
has begun using Pro/Engineer. RAL, however, is not currently effective
in this role. Noting also, that they have very little experience with
Pro/E, it is not reasonable to assume that "CAD Integration" is
something that the Inner Detector will see unless this responsibility is
taken over elsewhere. Directly this means that the Pixel detector must
seek an integration tie with its nearest neighbor, the SCT Barrel that
is currently engineered at the University of Geneva, which uses EUCLID.
It must suffice to say that EUCLID is an extremely primitive package
used mostly due to a large amount of legacy data. Unfortunately, CERN
and most other institutes in France and Switzerland have opted to
maintain it through the life of LEP, and as such are using it to design
the LHC. It is difficult, though not impossible to share data with
EUCLID. Generally, it is easier to get information out of EUCLID than
into it, therefore integration is more of a problem for people with
EUCLID than other users, however this muddles the concept of "sharing"
data and can lead to problems. CERN is, of course working on this
problem, though is typically unhelpful to non-CERN-based users. Some
tools are available, but none are readily supported. We may have to
resort to drawings to share geometry with EUCLID.*

*The rest of the Pixel collaboration, with the exception of our French
collaborator, use Pro/E or I-DEAS, both of which share data fairly
readily. Hytec uses SolidWorks, which is also easy to share data with,
so this is not viewed as a problem area.*

3.  The ATLAS Inner Detector needs Configuration Control. There is
    significant potential for interference and incompatibility between
    the various components of the Inner Detector.

*We couldn\'t agree more with this statement but do not have the
authority to force compliance by the inner detector community. The best
we can do on our own is to institute configuration control (including
interfaces) for our deliverables and we are in the process of doing so.*

4.  A decision must be made soon regarding the cooling system fluid. The
    different cooling systems may have an effect on the vibrations
    transmitted through the cooling lines, and the different fluids may
    present compatibility issues with Pixel components.

*The U.S. has no direct responsibility for the pixel cooling system but
obviously we depend on its success. The review highlighted the need for
us to provide more input into the choice of a cooling fluid and in
general to the design of the cooling system. Just subsequent to the
review, we agreed on a program of measurements (pressure and pressure
cycling tests, distortions under pressure, change in thermal performance
after pressure cycling, etc) that can be completed (we hope) in the next
few months by us. In addition, we will attempt to provide additional
fluid flow calculations to evaluate the feasibility of evaporative
systems with different fluids. Finally, we brought these issues and our
concerns to the attention of the Pixel Project Leader.*

[PIXEL DESIGN ISSUES]{.underline}

1.  There is a need to define thermal barrier requirements for the Pixel
    detector. This may be an ATLAS issue. The current design is
    anticipating the use of heater strips to prevent condensation. This
    will drive up the power consumption for the overall detector.

*The existence or not of thermal barriers is certainly an ATLAS issue.
We have taken the lead in the conceptual design and prototyping of a
thermal barrier but, as was presented to the committee, are exploring
means to eliminate the need for such barriers*

*There are two types of thermal barriers bounding the volume of the
Silicon Trackers (SCT + Pixels). For lack of any terminology, I will
refer to them as types I and II. Type I is active at all times and is
necessary to maintain the thermal gradients between the SCT and the TRT,
and between the end faces of the Forward SCT and the LAr Endcap
Calorimeter. Because of the limited space available to maintain this
\~30Deg C gradient, Type I thermal barriers require heat input on the
exterior surface and cooling channels on the interior surface. The Type
I boundary at the end face actually seals to the Beam-Pipe, but is made
of two annular parts. The innermost annulus is removable for B-Layer
and/or SCT Forward Removals (B-layer is always removed before removal of
SCT Forward). These interfaces must be kept thermally neutral at all
times to prevent cooling of the TRT/Cryostat, or conversely heating of
the SCT Barrel/Forward. During shutdown periods, these surfaces must be
maintained above the dewpoint to deter condensation. Because the cooling
and heating channels are sized to establish thermal neutrality, they to
not contribute to the power budget of the detector as it relates to
cooling.*

*Type II thermal barriers lie between detector volumes that are at the
same temperature during detector operation, i.e. between SCT Barrel and
Forward, Pixel Layer 1 and B-Layer, and SCT Forward and Beampipe volume
(bounded by the Type I barrier at the end of the bore). The B-Layer is
enclosed in this last volume during detector operation. Type II thermal
barriers are only in operation (heated) during maintenance periods that
require access to the bore of the detector, during which,
13DegC-dewpoint cavern air is introduced into the bore of the detector.
ATLAS requires that no condensation be allowed on any surface anywhere
within the cavern. To accomplish this in the limited space, heat is
input on the exterior surface of the Type II barrier. For mass reasons,
it is deemed unfeasible to also include a cooled interior surface so
there will be a net heat influx into the detector volume from the Type
II thermal barriers. A design comprised of two thin GFRP shells with a
non-convecting gas gap as insulation and custom Al-kapton heater has
been proposed. For the 1.6m section that runs through the volume of the
Pixel Detector, this design requires a heat input of 330W to maintain an
exterior surface temperature of 13.5DegC. This is \~2% of the heat
already budgeted for module and cable dissipation---15kW, implying that
the thermal barrier may be run with all of the electronics running,
however this is not the intention. It is foreseen that the detector will
be off (all FE-electronics will not be powered) during detector opening
scenarios, however the volume will be cooled using the detector cooling
system. This makes available the 15kW of cooling power from the Pixel
detector, however the thermal coupling to Layer 1 and the disks has not
been determined; local affects could still be a problem. Because there
is no thermal gradient across these barriers during detector operation,
they require no heat input, and thus do not affect the power budget of
the detector as it relates to cooling of an operating detector.*

*All space allocations for the thermal barriers, including power cables,
cooling circuits and insulation thickness have already been included in
the current Inner Tracker layout. However, structural designs do not yet
include thermal barrier supports, constraints or other effects. Power
budgets already include the dissipation of the power and cooling supply
lines of the thermal barriers both types II and I. Type II barriers are
only necessary if detector must remain cold during maintenance
operations. Work within the sensor group on the effects of warm-up on
depletion voltage are ongoing, but promising. Type I barriers are
fundamental to the interface between TRT and SCT and must be installed.*

2.  The electrical design currently has no margin for an increase in
    power requirements. This is not advisable this early in the design
    effort.

3.  There did not seem to be any extra cooling capacity in the Pixel
    thermal management system.

*Items 2 and 3 are related. It was an oversight on our part to not
present a more coherent picture of the power requirements and the
uncertainties, and of the thermal measurements done to assess margin in
the cooling system. We recognize that appropriate margins have not yet
been defined for power requirements and cooling capacity. Measurements
are underway to assess the \"headroom\" available in the cooling system.
For example, the average temperature of an ESLI prototype sector
increased by 1.4 degrees C when the power density was increased from 0.6
W/cm\*\*2 to 0.7 W/cm\*\*2, or by about 1.4 degrees C per Watt per
module. Temperature increases of this scale can likely be offset, if
necessary, by lowering the exhaust pressure of the evaporative C4F10
system. However, this statement has only had limited validation by
measurements. Furthermore, we must understand the cooling headroom in
the context of a complete system design, which will only begin later
this year.*

*Services are sized based on electronics that met the power budget of
0.6W/cm\^2 for the worst case cable lengths. A packing factor of 2 is
used for ribbons and slightly more for round cable leading to only a 40%
occupancy for our quoted envelope section. It was assumed that
electronics would make or beat the power budget which was considered to
be a limit. Therefore, no margin was placed on top of the cable size,
which was already viewed at the time to be conservative via conservatism
in the power budget, and the use of longest routing lengths. It was also
considered unreasonable to oversize the cables at that point due to
extreme material budget constraints and to allow some freedom in the
choice of routing. It should be noted that our envelope is not tied to
what space is available or a specific physical routing; as such it is
not strictly an envelope. Our envelope is essentially just a measure of
the section of particular bundles and a quantity of bundles. It is
somewhat misleading to say that any increase in power leads to our
exceeding our envelope as our envelope, by definition, is sized based on
our power budget. Our service bundle envelope is more of a size
parameter, which is then taken and routed through the service volumes.
Any change in the size of the bundle (what has been termed our envelope)
may or may not change the routing, depending on local effects.
Unfortunately, it is not easy to determine if there is a problem as we
are not responsible for the external routing of services. Only global
figures and percentages are available. For instance certain areas have a
70% volume occupancy for bundles---with packing factor \~2. Particular
problems occur at the patch panels which are not based on cable sizing.
Pixel cables represent only \~ 10% of the entire cross section, so to
first order we could double and not change the situation much. This does
not address localized problems, but these cannot be easily assessed as
the only CAD integration being done right now on this is in 2D at
Rutherford (RAL). CAD integration for the Inner Detector stops at the
second Patch Panel (PPB/F2). Afterward, service integration is handled
by ATLAS Technical Coordination. The CAD situation is abysmal as the
part up to PPB2 is only in 2D, and the parts after are all in EUCLID.
Physical models of the PPB2 and PPB1 region are being fabricated to
alleviate this problem. The models will include surrounding geometry to
simulate the runs into and out of the areas.*

*Cooling as a system is poorly understood at best, however it is
presently designed to have an overhead on the order of factor 2. This is
based on tubing sized to deliver twice the mass flow necessary to
extract the heat of 80W/stave (72W is nominal if electronics are in
spec---0.6W/cm\^2). It is unclear if the tubing is sized properly
however, and work is being done to verify this as quickly as possible.*

4.  The Committee views the sector cooling tube joint as a concern.
    There is a risk to the Pixel project schedule and the sector design
    development if the proposed tubing joint prototype is not
    successful.

*We have started to build prototypes of the cooling tube joint and will
test them over the next few months.*

5.  Final design for B-Layer depends upon finalization of bake-out
    jacket design, beam pipe support design and vacuum system design. To
    this end, the B-layer design requires close coordination with beam
    tube and bake-out jacket design. The NEG changes discussed in the
    Review (moving NEG inboard) is viewed as good for B-layer design.

*No comments.*

6.  ATLAS must define the B-layer installation method (insertion tool
    versus rails) now. This has a significant impact on B-Layer and
    Inner Detector design and is viewed as the very next step to be
    resolved before B-Layer and adjacent systems mechanical design may
    continue. Several systems may need modification if the rail option
    is adopted. The insertion tool may need to be developed further.

*We agree with these statements and are working towards resolving these
issues.*

7.  B-layer cable routing must be developed by ATLAS before more of the
    Pixel System mechanics can be designed, and must be done in
    conjunction with the installation and beam tube vacuum development.
    It may be very difficult to have cables connected to each end if the
    barrel is removable.

*We agree with this also.*

8.  During the Review it was stated that the alignment tolerance is 25
    -- 50 μm, but this was not critical because Pixel systems can rely
    upon x-ray for alignment calibration. However, the viability of the
    x-ray alignment is not well known for Pixels.

*Strictly speaking this was the placement tolerance and we expect to
also do optical surveys of each module on each sector, as well optical
or CMM measurements of all sectors within a disk. The X-ray measurements
are done after the system is assembled. There is an extensive program of
development, including prototype measurements, underway for X-ray
alignment of the SCT system by Oxford. So far, the responsibility for
similar measurements and the possibility to utilize the SCT system for
the pixels has not been fully developed. We are working to help resolve
this but it will likely require either new groups or groups not
currently involved in the pixel mechanics to become involved.*

9.  The Committee recommends the Pixel Project evaluate the
    repeatability of distortion on sectors under temperature cycling
    (hysterisis).

*Some such measurements have already been done but not in a systematic
way and we appreciate the suggestion.*

10. The global support progress is encouraging. The decision to go to a
    flat panel configuration as opposed to a truss structure should save
    both time and construction costs. A continued concern is the effect
    of services (which include both cables and cooling tubes) on the
    mechanical stability of the system. A strain relief system must be
    well thought out to avoid putting oblique forces on this precision
    structure.

*We agree and will have to do measurements on prototype structures to
really assess this problem.*

11. ATLAS needs to be determining whether the flat side of the omega
    section will warp and potentially contribute to the dimensional
    instability.

*This is not a U.S. responsibility but we will bring this concern to the
attention of the party responsible.*

12. The interconnect flex hybrid should be connected to the silicon with
    a flexible adhesive to avoid distortion. The CTEs for Kapton and
    silicon differ substantially. There is a potential for distortion of
    the silicon if a rigid adhesive is used. This should be evaluated.

*This is a good point that we have not yet addressed. We believe it will
be possible to make these measurements, to some extent, using flex 1.0
prototypes mounted on sectors with dummy silicon(unpowered) by lowering
the temperature and measuring the distortion with TV holography. Clearly
this has to be done also after irradiation.*

13. There is a lot of work done on 3-D modeling for the Pixel System.
    This is a good approach, and permits some early evaluation of
    interference. However, mock-ups also should be constructed to ensure
    all potential interference is identified.

*We are doing this and have an extensive mockup program in place.*

14. The current disk design uses a continuous disk. These disks are
    captive on a welded beam tube. Since the pipe must be installed
    after the detector is in place, detector delays could affect the
    beam-commissioning schedule. Disk repair also requires beam line
    cutting. The consequences of a captive disk system should be fully
    recognized before the disk and beam pipe designs are finalized.

*This was fully recognized some years ago. The flanges on the beam pipe
are capable of passing through the pixel detector (B-layer not in
place).*

## PIXEL PROGRAMMATIC ISSUES

1.  Final Design Reviews must be conducted before the PRR. In addition
    the design must be finalized before the PRR.

*We have not been entirely consistent in enumerating design reviews and
will fix this.*

2.  This Review indicated the stave and cooling tube back-up designs
    would be pursued right up to the PRR. We need to make the decision
    before the PRR. The purpose of the PRR is not a design blessing, but
    a determination of readiness to proceed to production (design is
    complete, drawings completed, validation testing is completed, QA
    program in place, etc.). If the design cannot be finalized in time
    for the PRR, then perhaps we need to recommend later dates for the
    CERN PRRs.

*This was stated in the case of the European development of the stave.
We agree with the comment of the committee. We do not intend to do this
for the sectors and related items, a U.S. responsibility. We will make a
final choice relatively early so that a final design is done on only one
choice.*

3.  Schedules need refinement; for example, the test of the second
    prototype occurs only three weeks after the second prototype design
    review. Design reviews must be scheduled so their findings may
    influence the design they are reviewing; e.g. the second prototype
    design review should be scheduled sufficiently in advance of
    commencement of second prototype fabrication so issues and
    conclusions may be addressed in the second prototype.

*We will revise the schedule as needed to clarify this issue.*