Difference: ITkPixelOrganization (1 vs. 10)

Revision 102017-07-26 - PaoloMorettini

Line: 1 to 1
Changed:
<
<
META TOPICPARENT name="ITK"
>
>
META TOPICPARENT name="Atlas.AtlasPublicPage"
 
<!-- This is the default ATLAS template. 
Please modify it in the sections indicated to create your topic! In particular, notice that at the bottom there are some sections that must be filled for publicly accessible pages.
If you have any comments/complaints about this template, then please email : Patrick Jussel (patrick dot jussel at cern dot ch) and/or Maria Smizanska (maria dot smizanska at cern dot ch)
Line: 14 to 14
 

ITk Pixel Organizational structure

Added:
>
>
 
Changed:
<
<
Organigram-pixel.jpg
>
>
Org_-_V6.jpg
 
Changed:
<
<
  • Deputy PL : Maurice Garcia-Sciveres
  • Modules: Didier Ferrere - Fabian Huegging
  • Integration and Local Support: Daniel Dobos
>
>
  • 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
Changed:
<
<
  • Design Group: Danilo Giugni, Richard Bates, Claudia Gemme, Philippe Grenier
>
>
  • System Test: Paul Dervan - Susanne Kuehn
  • RD53 contact: Maurice Garcia-Sciveres
 

General Considerations

Changed:
<
<
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 Overview 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 Overview 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.
>
>
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).
Changed:
<
<

Design Overview Group

>
>

Steering commette / Design Group

 
Changed:
<
<
2-3 Coordinators, Coordinators of the 4 groups
>
>
*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:

Changed:
<
<
  • Design overview
  • Overall coordination (TDR preparation)
  • Physics performance. Interface with Simulation and Physics groups
  • Technology tracking
  • Production optimization
  • Definition and review of the interfaces between blocks
  • Test coordination
  • Qualification procedures
  • Schedule
  • Documentation
  • Costing / Human and financial resources
>
>
  • 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:

Changed:
<
<
>
>
 
Deleted:
<
<
  • Trigger support?
 
Changed:
<
<

Support structure design & integration

>
>

Mechanics & integration

  Main activities:
Changed:
<
<
  • Support design
>
>
  • Local support design
 
  • Mechanical/Thermal qualification
  • Cooling
Deleted:
<
<
  • Module integration on support
 
  • Interfaces / Services (PP0 / PP1)
  • Repair/replacement procedures
Changed:
<
<
  • Interface with the ITk Mechanics group
  • System testing
>
>
  • Interface with the ITk Common Mechanics group
  • Support design
 

Detector electronics

Main activities:

Changed:
<
<
  • Power distribution
  • Stave/Disk signal transmission
  • Stave/Disk data interface
>
>
  • Stave/Ring power distribution
  • Stave/Ring data distribution
 
  • Optical transmission
  • DCS
Changed:
<
<
  • Power supplie
  • Grounding
  • Interface with the ITk Electronics group
  • PP0/PP1
>
>
  • Power supplies
  • Grounding and shielding
  • Interface with the ITk Common Electronics group
  • PP0/PP1, PP2 specifications
 

Readout system & software

Line: 101 to 101
 
  • On-line monitoring
  • Pixel specific off-line software
Added:
>
>

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?

Line: 131 to 139
  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.

Changed:
<
<
<!-- For significant updates to the topic, consider adding your 'signature' (beneath this editing box) -->
Major updates:
-- PaoloMorettini - 24 Feb 2014
>
>
<!-- For significant updates to the topic, consider adding your 'signature' (beneath this editing box) -->
Major updates:
-- PaoloMorettini - 26 Jul 2017
 
<!-- Person responsible for the page: 
Either leave as is - the creator's name will be inserted; 
Line: 141 to 149
 
Changed:
<
<

META FILEATTACHMENT attachment="Organigram-pixel.jpg" attr="h" comment="" date="1393090720" name="Organigram-pixel.jpg" path="Organigram-pixel.jpg" size="63238" user="morettin" version="1"
>
>
META FILEATTACHMENT attachment="Org_-_V6.jpg" attr="h" comment="" date="1501079986" name="Org_-_V6.jpg" path="Org_-_V6.jpg" size="155709" user="morettin" version="1"

Revision 92014-07-15 - PaoloMorettini

Line: 1 to 1
 
META TOPICPARENT name="ITK"
<!-- This is the default ATLAS template. 
Please modify it in the sections indicated to create your topic! In particular, notice that at the bottom there are some sections that must be filled for publicly accessible pages.

Revision 82014-05-01 - PaoloMorettini

Line: 1 to 1
 
META TOPICPARENT name="ITK"
<!-- This is the default ATLAS template. 
Please modify it in the sections indicated to create your topic! In particular, notice that at the bottom there are some sections that must be filled for publicly accessible pages.
Line: 19 to 19
 
Added:
>
>
  • Modules: Didier Ferrere - Fabian Huegging
  • Integration and Local Support: Daniel Dobos
  • Electronics: Tobias Flick
  • Software and Read-out: Joern Grosse-Knetter
  • Design Group: Danilo Giugni, Richard Bates, Claudia Gemme, Philippe Grenier
 

General Considerations

Revision 72014-03-14 - AlexanderRozanov

Line: 1 to 1
 
META TOPICPARENT name="ITK"
<!-- This is the default ATLAS template. 
Please modify it in the sections indicated to create your topic! In particular, notice that at the bottom there are some sections that must be filled for publicly accessible pages.
Line: 50 to 50
  Main activities:
Changed:
<
<
  • Sensors
>
>
 

Revision 62014-03-13 - AlexanderRozanov

Line: 1 to 1
 
META TOPICPARENT name="ITK"
<!-- This is the default ATLAS template. 
Please modify it in the sections indicated to create your topic! In particular, notice that at the bottom there are some sections that must be filled for publicly accessible pages.
Line: 51 to 51
 Main activities:

  • Sensors
Changed:
<
<
  • FE (RD53 interface)
>
>
 
  • Hybridization
  • Module assembly
  • Module testing

Revision 52014-02-24 - PaoloMorettini

Line: 1 to 1
 
META TOPICPARENT name="ITK"
<!-- This is the default ATLAS template. 
Please modify it in the sections indicated to create your topic! In particular, notice that at the bottom there are some sections that must be filled for publicly accessible pages.
Line: 24 to 24
  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 Overview 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 Overview 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.
Added:
>
>
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).
 

Design Overview Group

2-3 Coordinators, Coordinators of the 4 groups

Line: 114 to 116
  Q: Local support and detector electronics are highly correlated. How this will be handled?
Changed:
<
<
A:
>
>
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?
Line: 122 to 124
  Q: Why there is no separation, at the coordination level, between inner and outer layers, or between barrel and disks.
Changed:
<
<
A:
>
>
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.
 
<!-- For significant updates to the topic, consider adding your 'signature' (beneath this editing box) -->
Major updates:
-- PaoloMorettini - 24 Feb 2014

Revision 42014-02-24 - PaoloMorettini

Line: 1 to 1
 
META TOPICPARENT name="ITK"
<!-- This is the default ATLAS template. 
Please modify it in the sections indicated to create your topic! In particular, notice that at the bottom there are some sections that must be filled for publicly accessible pages.
Line: 100 to 101
 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?

Deleted:
<
<
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.
 
Changed:
<
<
<!-- For significant updates to the topic, consider adding your 'signature' (beneath this editing box) -->
Major updates:
-- PaoloMorettini - 22 Feb 2014
>
>
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:

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:

<!-- For significant updates to the topic, consider adding your 'signature' (beneath this editing box) -->
Major updates:
-- PaoloMorettini - 24 Feb 2014
 
<!-- Person responsible for the page: 
Either leave as is - the creator's name will be inserted; 

Revision 32014-02-24 - PaoloMorettini

Line: 1 to 1
 
META TOPICPARENT name="ITK"
<!-- This is the default ATLAS template. 
Please modify it in the sections indicated to create your topic! In particular, notice that at the bottom there are some sections that must be filled for publicly accessible pages.
Line: 22 to 22
 

General Considerations

Changed:
<
<
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
>
>
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 Overview 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 Overview 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.
 

Design Overview Group

Revision 22014-02-23 - PaoloMorettini

Line: 1 to 1
 
META TOPICPARENT name="ITK"
<!-- This is the default ATLAS template. 
Please modify it in the sections indicated to create your topic! In particular, notice that at the bottom there are some sections that must be filled for publicly accessible pages.
Line: 22 to 22
 

General Considerations

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

Design Overview Group

2-3 Coordinators, Coordinators of the 4 groups

Line: 94 to 96
 

Questions and Answers

Added:
>
>
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.

 
<!-- For significant updates to the topic, consider adding your 'signature' (beneath this editing box) -->
Major updates:
-- PaoloMorettini - 22 Feb 2014

<!-- Person responsible for the page: 

Revision 12014-02-22 - PaoloMorettini

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="ITK"
<!-- This is the default ATLAS template. 
Please modify it in the sections indicated to create your topic! In particular, notice that at the bottom there are some sections that must be filled for publicly accessible pages.
If you have any comments/complaints about this template, then please email : Patrick Jussel (patrick dot jussel at cern dot ch) and/or Maria Smizanska (maria dot smizanska at cern dot ch)

By default the title is the WikiWord used to create this topic if you want to modify it to something more meaningful, just replace ITkPixelOrganization below with i.e "My Topic" ======= you can remove the lines above ========================================= -->

ITkPixelOrganization

<!-- this line is optional -->

ITk Pixel Organizational structure


Organigram-pixel.jpg

General Considerations

Design Overview Group

2-3 Coordinators, Coordinators of the 4 groups

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:

  • Design overview
  • Overall coordination (TDR preparation)
  • Physics performance. Interface with Simulation and Physics groups
  • Technology tracking
  • Production optimization
  • Definition and review of the interfaces between blocks
  • Test coordination
  • Qualification procedures
  • Schedule
  • Documentation
  • Costing / Human and financial resources

Modules

Main activities:

  • Sensors
  • FE (RD53 interface)
  • Hybridization
  • Module assembly
  • Module testing
  • Trigger support?

Support structure design & integration

Main activities:

  • Support design
  • Mechanical/Thermal qualification
  • Cooling
  • Module integration on support
  • Interfaces / Services (PP0 / PP1)
  • Repair/replacement procedures
  • Interface with the ITk Mechanics group
  • System testing

Detector electronics

Main activities:

  • Power distribution
  • Stave/Disk signal transmission
  • Stave/Disk data interface
  • Optical transmission
  • DCS
  • Power supplie
  • Grounding
  • Interface with the ITk Electronics group
  • PP0/PP1

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

Questions and Answers

<!-- For significant updates to the topic, consider adding your 'signature' (beneath this editing box) -->
Major updates:
-- PaoloMorettini - 22 Feb 2014

<!-- Person responsible for the page: 
Either leave as is - the creator's name will be inserted; 
Or replace the complete REVINFO tag (including percentages symbols) with a name in the form TwikiUsersName -->
Responsible: PaoloMorettini
<!-- Once this page has been reviewed, please add the name and the date e.g. StephenHaywood - 31 Oct 2006 -->
Last reviewed by: Never reviewed

META FILEATTACHMENT attachment="Organigram-pixel.jpg" attr="h" comment="" date="1393090720" name="Organigram-pixel.jpg" path="Organigram-pixel.jpg" size="63238" user="morettin" version="1"
 
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