ITkPixelOrganization

ITk Pixel Organizational structure


Org_-_V6.jpg

  • PL : Paolo Morettini
  • Deputy PL : Philippe Grenier
  • PE : Danilo Giugni
  • Modules: Richard Bates - Fabian Huegging
    • Sensors: Sebastian Grinstein - Anna Macchiolo
    • CMOS: Attilio Andreazza - Mathieu Benoit - Heinz Pernegger
  • Mechanics: Danilo Giugni - Eric Vigeolas
  • Electronics: Tobias Flick
  • Software and Read-out: Joern Grosse-Knetter
  • System Test: Paul Dervan - Susanne Kuehn
  • RD53 contact: Maurice Garcia-Sciveres

General Considerations

This structure is intended for the TDR preparation phase. It's not an organization for the construction phase. It starts from the observation that the individual groups looking into the development of the different detector components will have to follow a number of parallel R&D lines. And, during the R&D phase, will have to reduce the number of open options, trying to select the most promising. But it's clear that the final decision on which technology to choose or which is suited for a particular region of the detector cannot be taken inside the individual groups. It's a decision that must be taken looking at the detector design in a global way. The Design Group is there exactly to do this job. On one side, this group receives input from the working groups, in the form of design options. The Design Group will review the received proposals, especially in term of global integration, quality control and possibility to mass produce. It will provide indications for the next iterations of the R&D activities, and will indicate the milestones for the preparation of the TDR and the strategies to reduce the number of open options in view of the definition of the project. It will prepare the input to the simulation group (the detector layouts to study in more details) and will review the results.

The proposed structure is a starting point. In case we understand that some area cannot be manager efficiently with the present structure, we will modify it accordingly (obviously with the agreement of the IB or of the Group Leaders if the IB is not yet formed).

Steering commette / Design Group

*PL, Deputy, PE, Coordinators of the 4 groups, LTF contact, RD53 contact, Pixel PL

The task is to overview, coordinate and supervise the design of the Pixel detector, stimulating the discussion across the groups, identifying new solutions or trade-offs. The goal is to be ready for the TDR with a solid and design supported by the community.

Main activities:

  • Coordinate and supervise the design of the Pixel detector, stimulating the discussion across the groups, identifying new solutions
  • Identify and coordinate items that cannot be treated inside a specific sub-group. One or two coordinators per item will be appointed.
  • Organize open meetings to discuss common items.
  • Define schedule and milestones. Monitor the evolution of the project.
  • Take design decisions based on the input from the sub-groups.
  • Costing
  • Risk analysis.
  • TDR preparation (with help from the sub-groups).

Modules

Main activities:

Mechanics & integration

Main activities:

  • Local support design
  • Mechanical/Thermal qualification
  • Cooling
  • Interfaces / Services (PP0 / PP1)
  • Repair/replacement procedures
  • Interface with the ITk Common Mechanics group
  • Support design

Detector electronics

Main activities:

  • Stave/Ring power distribution
  • Stave/Ring data distribution
  • Optical transmission
  • DCS
  • Power supplies
  • Grounding and shielding
  • Interface with the ITk Common Electronics group
  • PP0/PP1, PP2 specifications

Readout system & software

Main activities:

  • Interface with the TDAQ group
  • Interface with the ITk software and simulation groups
  • DAQ hw/fw/sw (at the beginning mainly test-beam/irrad support)
  • Trigger
  • Data-bases (connectivity, configuration, calibration)
  • On-line monitoring
  • Pixel specific off-line software

System Test

Main activities

  • Large scale tests coordination
  • Stave and rings prototypes
  • Power distribution and data transmission slices

Questions and Answers

Q: Why a Design Overview group? This is not what the PL and the deputy PL should do?

A: Well yes, PL and deputy PL could do the design overview, and possibly this is the canonical way of doing it. However, ITk will be a complicated project and a large collaboration. So, having a dedicated group helping in the design review can make the decision process more transparent and less dependent on individual points of view.

Q: The Design Overview group is a real group (with manpower) or more a forum?

A: It's an open group, where everyone can go and present ideas. Actually, one of the mandates is exactly to stimulate discussions that cannot be made within the individual working groups but requires a wider or interdisciplinary participation. In this sense it's more a permanent forum chaired and organized by the coordinators. However, it's not excluded that the design group will directly coordinate activities that cannot fit inside another group: a typical example could be the preparation of the input to the simulation group and the analysis of the results. In this case, the organization of the work would be similar to that of the other working groups. Another example could be the design review, where a specific group could be needed to cover engineering issues.

Q: Is the Design Overview group a Steering committee?

A: If we stick to the etymology yes, it will drive the group to the preparation of the TDR. However there is a difference: the design group is an open group coordinated by the coordinators, to help finding design solutions, trade-offs between different technologies, new ideas, better optimizations. As the other groups, it will provide some sort of deliverables: for the "normal" working groups the deliverables are the results of a specific R&D, for the Design Overview group are detector design iterations. The steering group is a closed meeting of all the coordinators, chaired by the PL and the Deputy. It will help in making decisions based on the input from the different groups or, for the most critical items, will prepare the input for the IB, where the decision will be taken.

Q: There is off-line group. Where the off-line activities will be coordinated?

A: We plan to have a specific responsible/contact point for the off-line in the Software and Read-out group. Most of the off-line activity will happen however inside the global ITk simulation and off-line groups. Concerning the coordination of the input to the simulation group (e.g. on the priority for the simulations of different layouts) and the contact with the Upgrade Physics group, this will be coordinated by the Design Overview group.

Q: Local support and detector electronics are highly correlated. How this will be handled?

A:This is a task for the Design Overview group, and may indicate the need for a coordinator with module/electronics/read-out skills (engeneering, mechanics and simulation are other required skills of the coordinators).

Q: How the test beam activities will be coordinated?

A: My nave answer would be by a specific sub-group in the module group, with the external support of the Readout and Software group. But this will be discussed in detail with the coordinators of the relevant groups.

Q: Why there is no separation, at the coordination level, between inner and outer layers, or between barrel and disks.

A: It looks likely that a complicated object like the ITk Pixel will be more efficiently coordinated during the production phase if different parts of the detector will be managed separately. Moreover there are obvious technical considerations that suggest the use of different technologies in different parts of the detector. So, even if I'm convinced that preserving a high level of commonality between the sub-sections will be beneficial, I believe that, in the end, we will naturally split the project in two or more parts. However, and I think there a large consensus on this point, I think the design is not mature enough to operate such a division now. And, in this very fluid phase of R&D and technology investigation, splitting the groups in two parts would be dangerous. So, the proposal is to start all together and converge on a common and complete detector design. The production phase will be managed in a different way, and at that time it will be clear how to partition the project in an efficient way.

Major updates:
-- PaoloMorettini - 26 Jul 2017

Responsible: PaoloMorettini
Last reviewed by: Never reviewed

Edit | Attach | Watch | Print version | History: r10 < r9 < r8 < r7 < r6 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r10 - 2017-07-26 - PaoloMorettini
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Atlas All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback