Difference: Run2Preparation (1 vs. 69)

Revision 692018-03-21 - mishino

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation and Operations

Revision 682017-11-09 - mishino

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"
Changed:
<
<

Run-2 Preparation and 2017 Operations

>
>

Run-2 Preparation and Operations

 
<-- 
-->
Line: 10 to 10
 

Point-1 Google Calendar

  • the status for booking "ATLAS_partition (or MP)" (accessible only from GPN)
Changed:
<
<

Milestone Weeks (2014 - 2017)

>
>

Milestone Weeks (2014 - 2018)

 

Data Preparation

  • Information from Data Preparation on Cosmic Data 2014-2017 available here

Revision 672017-05-14 - mishino

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation and 2017 Operations

Revision 662017-05-13 - mishino

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation and 2017 Operations

<-- 
-->
Changed:
<
<

Updated Daily Run Plan from the control room - click here ***

>
>

ATLAS Daily Plan : "Plan of the DAY"

 
Changed:
<
<

P1 Run Preparation Activities:

>
>

Point-1 Google Calendar

  • the status for booking "ATLAS_partition (or MP)" (accessible only from GPN)
 
Changed:
<
<
Subsystems Requests for CTP or Tests in Global Partition (Google Calendar, visible only from GPN, no P1 network)

Milestone Weeks

Information and material of the 2016-2017 Milestone Weeks has been moved to this page.
>
>

Milestone Weeks (2014 -- 2017)

 

Data Preparation

Changed:
<
<
>
>
 

LHC Schedule

Changed:
<
<
Draft 2017 Schedule available here

2016 Schedule available here

>
>
  • Draft 2017 Schedule available here
 

Run-2 Shift Training Preparation Page

Changed:
<
<
Information for ongoing shift training preparation has been prepared here
>
>
  • Information for ongoing shift training preparation has been prepared here
 

Run-2 Operations Model/Shift Organization Discussion

Changed:
<
<
Please note that all of the material and links on Run-2 Operation and Shift Model has been moved to this page.
>
>
  • Please note that all of the material and links on Run-2 Operation and Shift Model has been moved to this page
 
Deleted:
<
<

Run-2 information for combined ATLAS - LHCf

Some information in preparation for the combined running with LHCf is collected on this page.
 
Deleted:
<
<

Beam Splash 2015 preparation

Step-by-step instructions for use by the Run Coordinators in setting up the beam splash combined run are on this page.

First Collisions at 450 GeV (May 6th 2015)

Step-by-step instructions for use by the Run Coordinators in setting up for first collisions at 450 GeV are on this page
 

Running ATLAS with ready For Physics in Quiet Beams

Changed:
<
<
Step-by-step instructions for use by the Run Coordinators in setting up for Quiet Beams are on on this page
>
>
Step-by-step instructions for use by the Run Coordinators in setting up for Quiet Beams are on on this page
 

Pending ATLAS Work requiring access to UX-15, US-15, Tunnel Sect 1-2, Sect 8-1

Pending requests for access are collected on this page
Line: 83 to 69
 
Changed:
<
<
>
>

obsolete

  • Beam Splash (2015) : Step-by-step instructions for use by the Run Coordinators in setting up the beam splash combined run are on this page
  • First Collisions at 450 GeV (May 6th 2015) : Step-by-step instructions for setting up the first collisions at 450 GeV are on this page
  • Combined ATLAS - LHCf : preparation for the combined running with LHCf is collected on this page.
 
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v2.pdf" attr="h" comment="M-Week Schedule version 2" date="1392044436" name="MilestoneWeek_Schedule_v2.pdf" path="MilestoneWeek_Schedule_v2.pdf" size="75964" stream="MilestoneWeek_Schedule_v2.pdf" tmpFilename="/usr/tmp/CGItemp28226" user="zimmerst" version="1"
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v3.pdf" attr="h" comment="M-Week schedule version 3 (Feb 10 2014)" date="1392044455" name="MilestoneWeek_Schedule_v3.pdf" path="MilestoneWeek_Schedule_v3.pdf" size="76926" stream="MilestoneWeek_Schedule_v3.pdf" tmpFilename="/usr/tmp/CGItemp28185" user="zimmerst" version="1"

Revision 652017-01-04 - aohatl

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"
Changed:
<
<

Run-2 Preparation and 2015 - 2016 Operations

>
>

Run-2 Preparation and 2017 Operations

 
<-- 
-->
Deleted:
<
<

Work in progress, this page is being updated with info for 2016

 

Updated Daily Run Plan from the control room - click here ***

P1 Run Preparation Activities:

Subsystems Requests for CTP or Tests in Global Partition (Google Calendar, visible only from GPN, no P1 network)

Changed:
<
<

Milestone Week Page Available Here

Information and material of the 2014-2015 Milestone Weeks has been moved to this page.
>
>

Milestone Weeks

Information and material of the 2016-2017 Milestone Weeks has been moved to this page.
 

Data Preparation

Changed:
<
<
>
>
 
Changed:
<
<

Latest LHC Schedule available

>
>

LHC Schedule

 
Changed:
<
<
Latest official 2015 Schedule available here
>
>
Draft 2017 Schedule available here
 
Changed:
<
<
V.1.7 update: LHC-schedule.png

Latest official 2016 Schedule available here

>
>
2016 Schedule available here
 
Deleted:
<
<
V.0.3 update: LHC-schedule2016.png
 

Run-2 Shift Training Preparation Page

Information for ongoing shift training preparation has been prepared here

Revision 642016-01-12 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation and 2015 - 2016 Operations

Revision 632015-12-09 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"
Changed:
<
<

Run-2 Preparation and 2015 Operations

>
>

Run-2 Preparation and 2015 - 2016 Operations

 
<-- 
-->
Added:
>
>

Work in progress, this page is being updated with info for 2016

 

Updated Daily Run Plan from the control room - click here ***

P1 Run Preparation Activities:

Line: 29 to 29
 V.1.7 update: LHC-schedule.png
Added:
>
>
Latest official 2016 Schedule available here

V.0.3 update: LHC-schedule2016.png

 

Run-2 Shift Training Preparation Page

Information for ongoing shift training preparation has been prepared here

Run-2 Operations Model/Shift Organization Discussion

Please note that all of the material and links on Run-2 Operation and Shift Model has been moved to this page.
Changed:
<
<

Run-2 information for combined ATLAS - LHCf (preliminary)

>
>

Run-2 information for combined ATLAS - LHCf

 Some information in preparation for the combined running with LHCf is collected on this page.

Beam Splash 2015 preparation

Line: 47 to 53
 

Running ATLAS with ready For Physics in Quiet Beams

Step-by-step instructions for use by the Run Coordinators in setting up for Quiet Beams are on on this page
Changed:
<
<

(New!) Pending ATLAS Work requiring access to UX-15, US-15, Tunnel Sect 1-2, Sect 8-1

>
>

Pending ATLAS Work requiring access to UX-15, US-15, Tunnel Sect 1-2, Sect 8-1

 Pending requests for access are collected on this page
Changed:
<
<

(New!) Open Issues from Daily Run Meetings and Operation

>
>

Open Issues from Daily Run Meetings and Operation

 Pending open issues are collected on this page

Check here for the for the instructions on shifting latency.

Line: 72 to 78
 
Changed:
<
<
>
>
 
Line: 102 to 108
 
META FILEATTACHMENT attachment="atlas-shifts-2015.01.png" attr="h" comment="" date="1418746167" name="atlas-shifts-2015.01.png" path="atlas-shifts-2015.01.png" size="135888" stream="atlas-shifts-2015.01.png" tmpFilename="/usr/tmp/CGItemp35347" user="apolini" version="1"
META FILEATTACHMENT attachment="atlas-operation-2015.02.png" attr="h" comment="" date="1424184633" name="atlas-operation-2015.02.png" path="atlas-operation-2015.02.png" size="190052" stream="atlas-operation-2015.02.png" tmpFilename="/usr/tmp/CGItemp13213" user="apolini" version="1"
META FILEATTACHMENT attachment="LHC-schedule.png" attr="" comment="" date="1443110997" name="LHC-schedule.png" path="LHC-schedule.png" size="43601" stream="LHC-schedule.png" tmpFilename="/usr/tmp/CGItemp33216" user="apolini" version="3"
Added:
>
>
META FILEATTACHMENT attachment="LHC-schedule-2016.png" attr="h" comment="LHC schedule 2016" date="1449676675" name="LHC-schedule-2016.png" path="LHC-schedule-2016.png" size="204552" stream="LHC-schedule-2016.png" tmpFilename="/usr/tmp/CGItemp25277" user="apolini" version="1"

Revision 622015-10-09 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation and 2015 Operations

Revision 612015-09-30 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation and 2015 Operations

Revision 602015-09-24 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation and 2015 Operations

Revision 592015-08-18 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation and 2015 Operations

Revision 582015-08-06 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation and 2015 Operations

Revision 572015-07-26 - glehmann

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation and 2015 Operations

Revision 562015-07-06 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation and 2015 Operations

Revision 552015-05-31 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation and 2015 Operations

Revision 542015-05-19 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation and 2015 Operations

Revision 532015-05-14 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"
Changed:
<
<

Run-2 Preparation, 2014 and 2015 Operations and Milestone Weeks

>
>

Run-2 Preparation and 2015 Operations

<-- 
-->
 

Updated Daily Run Plan from the control room - click here ***

Deleted:
<
<
Please note that this being updated for the moment only during milestone runs and planned special activities in ACR)
 

P1 Run Preparation Activities:

Subsystems Requests for CTP or Tests in Global Partition (Google Calendar, visible only from GPN, no P1 network)

Added:
>
>

Milestone Week Page Available Here

Information and material of the 2014-2015 Milestone Weeks has been moved to this page.
 
Changed:
<
<

Milestone Week Dates

Milestone Week Sub-Detector Integration Schedule (2014)

The current version of the M-Week Planning (update 30-10-2014) can be found here.

milestones-v11.jpg

2015 Milestone Run and Shift Schedule

>
>

Data Preparation

 
Changed:
<
<
atlas-operation-2015.02.png

Checklist Form

The Milestone Week Sub-System Checklist Form is avaliable here: docx, pdf

>
>

Latest LHC Schedule available here LHC-schedule.png

 

Run-2 Shift Training Preparation Page

Changed:
<
<
Information for ongoing shift training preparation has been prepared here
>
>
Information for ongoing shift training preparation has been prepared here
 

Run-2 Operations Model/Shift Organization Discussion

Deleted:
<
<
 Please note that all of the material and links on Run-2 Operation and Shift Model has been moved to this page.

Run-2 information for combined ATLAS - LHCf (preliminary)

Line: 83 to 65
 
META FILEATTACHMENT attachment="atlas-operation-2015.01.png" attr="h" comment="" date="1418746958" name="atlas-operation-2015.01.png" path="atlas-operation-2015.01.png" size="131018" stream="atlas-operation-2015.01.png" tmpFilename="/usr/tmp/CGItemp39507" user="apolini" version="2"
META FILEATTACHMENT attachment="atlas-shifts-2015.01.png" attr="h" comment="" date="1418746167" name="atlas-shifts-2015.01.png" path="atlas-shifts-2015.01.png" size="135888" stream="atlas-shifts-2015.01.png" tmpFilename="/usr/tmp/CGItemp35347" user="apolini" version="1"
META FILEATTACHMENT attachment="atlas-operation-2015.02.png" attr="h" comment="" date="1424184633" name="atlas-operation-2015.02.png" path="atlas-operation-2015.02.png" size="190052" stream="atlas-operation-2015.02.png" tmpFilename="/usr/tmp/CGItemp13213" user="apolini" version="1"
Added:
>
>
META FILEATTACHMENT attachment="LHC-schedule.png" attr="" comment="" date="1431595140" name="LHC-schedule.png" path="LHC-schedule.png" size="109146" stream="LHC-schedule.png" tmpFilename="/usr/tmp/CGItemp46017" user="apolini" version="1"

Revision 522015-05-04 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 and 2015 Operations and Milestone Weeks

Updated Daily Run Plan from the control room - click here ***

Line: 52 to 52
 

Beam Splash 2015 preparation

Step-by-step instructions for use by the Run Coordinators in setting up the beam splash combined run are in on this page.
Added:
>
>

First Collisions at 450 GeV (May 6th 2015)

Step-by-step instructions for use by the Run Coordinators in setting up for first collisions at 450 GeV are in on this page
 

Useful online links (preliminary, these will be put in proper locations later, first link from GPN the second from P1)

Revision 512015-04-08 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 and 2015 Operations and Milestone Weeks

Updated Daily Run Plan from the control room - click here ***

Line: 37 to 37
  The Milestone Week Sub-System Checklist Form is avaliable here: docx, pdf
Changed:
<
<

New! Run-2 Shift Training Preparation Page

>
>

Run-2 Shift Training Preparation Page

 
Changed:
<
<
A new page with information for ongoing shift training preparation has been prepared here
>
>
Information for ongoing shift training preparation has been prepared here
 

Run-2 Operations Model/Shift Organization Discussion

Revision 502015-04-02 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 and 2015 Operations and Milestone Weeks

Updated Daily Run Plan from the control room - click here ***

Line: 48 to 49
 Some information in preparation for the combined running with LHCf is collected on this page.
Added:
>
>

Beam Splash 2015 preparation

Step-by-step instructions for use by the Run Coordinators in setting up the beam splash combined run are in on this page.
 

Useful online links (preliminary, these will be put in proper locations later, first link from GPN the second from P1)

Revision 492015-04-01 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 and 2015 Operations and Milestone Weeks

Updated Daily Run Plan from the control room - click here ***

Line: 48 to 48
 Some information in preparation for the combined running with LHCf is collected on this page.
Changed:
<
<

Useful online links (preliminary, these will be put in proper locations later, first link P1, scond GPN)

>
>

Useful online links (preliminary, these will be put in proper locations later, first link from GPN the second from P1)

 
Line: 60 to 60
  P1
Added:
>
>
 

META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v2.pdf" attr="h" comment="M-Week Schedule version 2" date="1392044436" name="MilestoneWeek_Schedule_v2.pdf" path="MilestoneWeek_Schedule_v2.pdf" size="75964" stream="MilestoneWeek_Schedule_v2.pdf" tmpFilename="/usr/tmp/CGItemp28226" user="zimmerst" version="1"

Revision 482015-03-20 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"
Changed:
<
<

Run-2 Preparation, 2014 Operations and Milestone Weeks

>
>

Run-2 Preparation, 2014 and 2015 Operations and Milestone Weeks

 

Updated Daily Run Plan from the control room - click here ***

Please note that this being updated for the moment only during milestone runs and planned special activities in ACR)
Line: 17 to 17
 
Added:
>
>
 
Line: 35 to 36
  The Milestone Week Sub-System Checklist Form is avaliable here: docx, pdf
Changed:
<
<

New! Milestone #8 + Run-2 Shift Training Preparation Page

>
>

New! Run-2 Shift Training Preparation Page

  A new page with information for ongoing shift training preparation has been prepared here

Revision 472015-03-14 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room - click here ***

Line: 35 to 35
  The Milestone Week Sub-System Checklist Form is avaliable here: docx, pdf
Changed:
<
<

New! Milestone #8 + Run-2 Shift Training Preparation Page

>
>

New! Milestone #8 + Run-2 Shift Training Preparation Page

  A new page with information for ongoing shift training preparation has been prepared here

Revision 462015-03-04 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room - click here ***

Line: 51 to 51
 
Changed:
<
<
>
>
 

Revision 452015-02-17 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room - click here ***

Line: 27 to 27
  milestones-v11.jpg
Deleted:
<
<

2015 Restart and Integration Schedule

atlas-shifts-2015.01.png

 

2015 Milestone Run and Shift Schedule

Changed:
<
<
atlas-operation-2015.01.png
>
>
atlas-operation-2015.02.png
 

Checklist Form

Line: 61 to 57
  P1
Added:
>
>
 

META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v2.pdf" attr="h" comment="M-Week Schedule version 2" date="1392044436" name="MilestoneWeek_Schedule_v2.pdf" path="MilestoneWeek_Schedule_v2.pdf" size="75964" stream="MilestoneWeek_Schedule_v2.pdf" tmpFilename="/usr/tmp/CGItemp28226" user="zimmerst" version="1"
Line: 76 to 74
 
META FILEATTACHMENT attachment="milestones-v11.jpg" attr="h" comment="" date="1415296916" name="milestones-v11.jpg" path="milestones-v11.jpg" size="122383" stream="milestones-v11.jpg" tmpFilename="/usr/tmp/CGItemp59168" user="apolini" version="1"
META FILEATTACHMENT attachment="atlas-operation-2015.01.png" attr="h" comment="" date="1418746958" name="atlas-operation-2015.01.png" path="atlas-operation-2015.01.png" size="131018" stream="atlas-operation-2015.01.png" tmpFilename="/usr/tmp/CGItemp39507" user="apolini" version="2"
META FILEATTACHMENT attachment="atlas-shifts-2015.01.png" attr="h" comment="" date="1418746167" name="atlas-shifts-2015.01.png" path="atlas-shifts-2015.01.png" size="135888" stream="atlas-shifts-2015.01.png" tmpFilename="/usr/tmp/CGItemp35347" user="apolini" version="1"
Added:
>
>
META FILEATTACHMENT attachment="atlas-operation-2015.02.png" attr="h" comment="" date="1424184633" name="atlas-operation-2015.02.png" path="atlas-operation-2015.02.png" size="190052" stream="atlas-operation-2015.02.png" tmpFilename="/usr/tmp/CGItemp13213" user="apolini" version="1"

Revision 442015-01-06 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room - click here ***

Line: 39 to 39
  The Milestone Week Sub-System Checklist Form is avaliable here: docx, pdf
Changed:
<
<

New! Milestone #7 + Run-2 Shift Training Preparation Page

>
>

New! Milestone #8 + Run-2 Shift Training Preparation Page

 
Changed:
<
<
A new page with information for ongoing shift training preparation has been prepared here
>
>
A new page with information for ongoing shift training preparation has been prepared here
 

Run-2 Operations Model/Shift Organization Discussion

Revision 432014-12-16 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room - click here ***

Line: 15 to 15
 
Changed:
<
<
>
>
 
Changed:
<
<

Milestone Week Sub-Detector Integration Schedule

>
>

Milestone Week Sub-Detector Integration Schedule (2014)

  The current version of the M-Week Planning (update 30-10-2014) can be found here.

milestones-v11.jpg

Added:
>
>

2015 Restart and Integration Schedule

atlas-shifts-2015.01.png

2015 Milestone Run and Shift Schedule

atlas-operation-2015.01.png

 

Checklist Form

The Milestone Week Sub-System Checklist Form is avaliable here: docx, pdf

Line: 65 to 74
 
META FILEATTACHMENT attachment="milestones-v9.jpg" attr="h" comment="Milestone Schedule v.9" date="1406038265" name="milestones-v9.jpg" path="milestones-v9.jpg" size="118703" stream="milestones-v9.jpg" tmpFilename="/usr/tmp/CGItemp36239" user="apolini" version="1"
META FILEATTACHMENT attachment="milestones-v10.jpg" attr="h" comment="" date="1412083625" name="milestones-v10.jpg" path="milestones-v10.jpg" size="116305" stream="milestones-v10.jpg" tmpFilename="/usr/tmp/CGItemp38060" user="apolini" version="1"
META FILEATTACHMENT attachment="milestones-v11.jpg" attr="h" comment="" date="1415296916" name="milestones-v11.jpg" path="milestones-v11.jpg" size="122383" stream="milestones-v11.jpg" tmpFilename="/usr/tmp/CGItemp59168" user="apolini" version="1"
Added:
>
>
META FILEATTACHMENT attachment="atlas-operation-2015.01.png" attr="h" comment="" date="1418746958" name="atlas-operation-2015.01.png" path="atlas-operation-2015.01.png" size="131018" stream="atlas-operation-2015.01.png" tmpFilename="/usr/tmp/CGItemp39507" user="apolini" version="2"
META FILEATTACHMENT attachment="atlas-shifts-2015.01.png" attr="h" comment="" date="1418746167" name="atlas-shifts-2015.01.png" path="atlas-shifts-2015.01.png" size="135888" stream="atlas-shifts-2015.01.png" tmpFilename="/usr/tmp/CGItemp35347" user="apolini" version="1"

Revision 422014-11-11 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room - click here ***

Line: 31 to 31
  The Milestone Week Sub-System Checklist Form is avaliable here: docx, pdf
Changed:
<
<

Run-2 Operations Model/Shift Organization Discussion

>
>

New! Milestone #7 + Run-2 Shift Training Preparation Page

 
Changed:
<
<
Please note that all of the material and links on Run-2 Operation and Shift Model has been moved to this page.
>
>
A new page with information for ongoing shift training preparation has been prepared here
 
Changed:
<
<

(New!) M7+Run-2 Shift Training Preparation Page

>
>

Run-2 Operations Model/Shift Organization Discussion

 
Changed:
<
<
A new page with information for ongoing shift training preparation has been prepared here
>
>
Please note that all of the material and links on Run-2 Operation and Shift Model has been moved to this page.
 
Changed:
<
<

Run-2 information for combined ATLAS - LHCf (preliminary)

>
>

Run-2 information for combined ATLAS - LHCf (preliminary)

 Some information in preparation for the combined running with LHCf is collected on this page.

Revision 412014-11-06 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room - click here ***

Line: 23 to 23
 

Milestone Week Sub-Detector Integration Schedule

Changed:
<
<
The current version of the M-Week Planning (update 30-09-2014) can be found here.
>
>
The current version of the M-Week Planning (update 30-10-2014) can be found here.
 
Changed:
<
<
milestones-v10.jpg
>
>
milestones-v11.jpg
 

Checklist Form

Line: 64 to 64
 
META FILEATTACHMENT attachment="milestones-v8.jpg" attr="h" comment="Milestone Schedule v.8" date="1403604225" name="milestones-v8.jpg" path="milestones-v8.jpg" size="115492" stream="milestones-v8.jpg" tmpFilename="/usr/tmp/CGItemp42487" user="apolini" version="1"
META FILEATTACHMENT attachment="milestones-v9.jpg" attr="h" comment="Milestone Schedule v.9" date="1406038265" name="milestones-v9.jpg" path="milestones-v9.jpg" size="118703" stream="milestones-v9.jpg" tmpFilename="/usr/tmp/CGItemp36239" user="apolini" version="1"
META FILEATTACHMENT attachment="milestones-v10.jpg" attr="h" comment="" date="1412083625" name="milestones-v10.jpg" path="milestones-v10.jpg" size="116305" stream="milestones-v10.jpg" tmpFilename="/usr/tmp/CGItemp38060" user="apolini" version="1"
Added:
>
>
META FILEATTACHMENT attachment="milestones-v11.jpg" attr="h" comment="" date="1415296916" name="milestones-v11.jpg" path="milestones-v11.jpg" size="122383" stream="milestones-v11.jpg" tmpFilename="/usr/tmp/CGItemp59168" user="apolini" version="1"

Revision 402014-10-27 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room - click here ***

Line: 35 to 35
  Please note that all of the material and links on Run-2 Operation and Shift Model has been moved to this page.
Added:
>
>

(New!) M7+Run-2 Shift Training Preparation Page

A new page with information for ongoing shift training preparation has been prepared here

 

Run-2 information for combined ATLAS - LHCf (preliminary)

Some information in preparation for the combined running with LHCf is collected on this page.

Revision 392014-10-20 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room - click here ***

Line: 15 to 15
 
Changed:
<
<
>
>
 

Revision 382014-10-17 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room - click here ***

Line: 27 to 27
  milestones-v10.jpg
Changed:
<
<
The Milestone Week Sub-System Checklist Form is avaliable here: docx, pdf
>
>

Checklist Form

The Milestone Week Sub-System Checklist Form is avaliable here: docx, pdf

 

Run-2 Operations Model/Shift Organization Discussion

Revision 372014-10-15 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room - click here ***

Line: 40 to 40
 

Useful online links (preliminary, these will be put in proper locations later, first link P1, scond GPN)

Changed:
<
<
GPN
>
>
P1
 
Changed:
<
<
GPN
>
>
P1
 
Changed:
<
<
GPN
>
>
P1
 
Changed:
<
<
GPN
>
>
P1
 
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v2.pdf" attr="h" comment="M-Week Schedule version 2" date="1392044436" name="MilestoneWeek_Schedule_v2.pdf" path="MilestoneWeek_Schedule_v2.pdf" size="75964" stream="MilestoneWeek_Schedule_v2.pdf" tmpFilename="/usr/tmp/CGItemp28226" user="zimmerst" version="1"
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v3.pdf" attr="h" comment="M-Week schedule version 3 (Feb 10 2014)" date="1392044455" name="MilestoneWeek_Schedule_v3.pdf" path="MilestoneWeek_Schedule_v3.pdf" size="76926" stream="MilestoneWeek_Schedule_v3.pdf" tmpFilename="/usr/tmp/CGItemp28185" user="zimmerst" version="1"

Revision 362014-10-14 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room - click here ***

Line: 37 to 37
 Some information in preparation for the combined running with LHCf is collected on this page.
Changed:
<
<

Useful online links (preliminary, these will be put in proper locations later)

>
>

Useful online links (preliminary, these will be put in proper locations later, first link P1, scond GPN)

 
Added:
>
>
GPN
 
Added:
>
>
GPN
 
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v2.pdf" attr="h" comment="M-Week Schedule version 2" date="1392044436" name="MilestoneWeek_Schedule_v2.pdf" path="MilestoneWeek_Schedule_v2.pdf" size="75964" stream="MilestoneWeek_Schedule_v2.pdf" tmpFilename="/usr/tmp/CGItemp28226" user="zimmerst" version="1"
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v3.pdf" attr="h" comment="M-Week schedule version 3 (Feb 10 2014)" date="1392044455" name="MilestoneWeek_Schedule_v3.pdf" path="MilestoneWeek_Schedule_v3.pdf" size="76926" stream="MilestoneWeek_Schedule_v3.pdf" tmpFilename="/usr/tmp/CGItemp28185" user="zimmerst" version="1"

Revision 352014-10-13 - acerri

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Changed:
<
<

Updated Daily Run Plan from the control room here ***

>
>

Updated Daily Run Plan from the control room - click here ***

 Please note that this being updated for the moment only during milestone runs and planned special activities in ACR)

P1 Run Preparation Activities:

Revision 342014-09-30 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room here ***

Line: 24 to 24
 

Milestone Week Sub-Detector Integration Schedule

Changed:
<
<
The current version of the M-Week Planning can be found here.
>
>
The current version of the M-Week Planning (update 30-09-2014) can be found here.
 
Changed:
<
<
milestones-v9.jpg
>
>
milestones-v10.jpg
  The Milestone Week Sub-System Checklist Form is avaliable here: docx, pdf
Line: 45 to 45
 
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v2.pdf" attr="h" comment="M-Week Schedule version 2" date="1392044436" name="MilestoneWeek_Schedule_v2.pdf" path="MilestoneWeek_Schedule_v2.pdf" size="75964" stream="MilestoneWeek_Schedule_v2.pdf" tmpFilename="/usr/tmp/CGItemp28226" user="zimmerst" version="1"
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v3.pdf" attr="h" comment="M-Week schedule version 3 (Feb 10 2014)" date="1392044455" name="MilestoneWeek_Schedule_v3.pdf" path="MilestoneWeek_Schedule_v3.pdf" size="76926" stream="MilestoneWeek_Schedule_v3.pdf" tmpFilename="/usr/tmp/CGItemp28185" user="zimmerst" version="1"
Changed:
<
<
META FILEATTACHMENT attachment="milestones-v4.png" attr="h" comment="Atlas-Milestone-Run-Schedule" date="1399275475" name="milestones-v4.png" path="milestones-v4.png" size="157756" stream="milestones-v4.png" tmpFilename="/usr/tmp/CGItemp26826" user="apolini" version="1"
META FILEATTACHMENT attachment="milestones-v6.png" attr="h" comment="Milestone Schedule v.7" date="1400772132" name="milestones-v6.png" path="Milestone-schedule.png" size="62384" stream="Milestone-schedule.png" tmpFilename="/usr/tmp/CGItemp37270" user="apolini" version="2"
>
>
META FILEATTACHMENT attachment="milestones-v4.png" attr="h" comment="Milestone Schedule v.4" date="1399275475" name="milestones-v4.png" path="milestones-v4.png" size="157756" stream="milestones-v4.png" tmpFilename="/usr/tmp/CGItemp26826" user="apolini" version="1"
META FILEATTACHMENT attachment="milestones-v6.png" attr="h" comment="Milestone Schedule v.6" date="1400772132" name="milestones-v6.png" path="Milestone-schedule.png" size="62384" stream="Milestone-schedule.png" tmpFilename="/usr/tmp/CGItemp37270" user="apolini" version="2"
 
META FILEATTACHMENT attachment="M_Week_Checklist.docx" attr="h" comment="M Week Checklist" date="1400746373" name="M_Week_Checklist.docx" path="M_Week_Checklist.docx" size="19219" stream="M_Week_Checklist.docx" tmpFilename="/usr/tmp/CGItemp33833" user="apolini" version="1"
META FILEATTACHMENT attachment="M_Week_Checklist.pdf" attr="h" comment="M week checklist" date="1400746387" name="M_Week_Checklist.pdf" path="M_Week_Checklist.pdf" size="77681" stream="M_Week_Checklist.pdf" tmpFilename="/usr/tmp/CGItemp33792" user="apolini" version="1"
META FILEATTACHMENT attachment="milestones-v7.png" attr="h" comment="Milestone Schedule v.7" date="1402568408" name="milestones-v7.png" path="milestones-v7.png" size="77369" stream="milestones-v7.png" tmpFilename="/usr/tmp/CGItemp42268" user="apolini" version="1"
META FILEATTACHMENT attachment="milestones-v8.jpg" attr="h" comment="Milestone Schedule v.8" date="1403604225" name="milestones-v8.jpg" path="milestones-v8.jpg" size="115492" stream="milestones-v8.jpg" tmpFilename="/usr/tmp/CGItemp42487" user="apolini" version="1"
Changed:
<
<
META FILEATTACHMENT attachment="milestones-v9.jpg" attr="h" comment="" date="1406038265" name="milestones-v9.jpg" path="milestones-v9.jpg" size="118703" stream="milestones-v9.jpg" tmpFilename="/usr/tmp/CGItemp36239" user="apolini" version="1"
>
>
META FILEATTACHMENT attachment="milestones-v9.jpg" attr="h" comment="Milestone Schedule v.9" date="1406038265" name="milestones-v9.jpg" path="milestones-v9.jpg" size="118703" stream="milestones-v9.jpg" tmpFilename="/usr/tmp/CGItemp36239" user="apolini" version="1"
META FILEATTACHMENT attachment="milestones-v10.jpg" attr="h" comment="" date="1412083625" name="milestones-v10.jpg" path="milestones-v10.jpg" size="116305" stream="milestones-v10.jpg" tmpFilename="/usr/tmp/CGItemp38060" user="apolini" version="1"

Revision 332014-09-26 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room here ***

Line: 17 to 17
 
Changed:
<
<
>
>
 

Revision 322014-09-26 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room here ***

Line: 16 to 16
 
Changed:
<
<
>
>
 

Revision 312014-09-11 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room here ***

Line: 39 to 39
 

Useful online links (preliminary, these will be put in proper locations later)

Changed:
<
<
New CTP page
>
>
 
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v2.pdf" attr="h" comment="M-Week Schedule version 2" date="1392044436" name="MilestoneWeek_Schedule_v2.pdf" path="MilestoneWeek_Schedule_v2.pdf" size="75964" stream="MilestoneWeek_Schedule_v2.pdf" tmpFilename="/usr/tmp/CGItemp28226" user="zimmerst" version="1"
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v3.pdf" attr="h" comment="M-Week schedule version 3 (Feb 10 2014)" date="1392044455" name="MilestoneWeek_Schedule_v3.pdf" path="MilestoneWeek_Schedule_v3.pdf" size="76926" stream="MilestoneWeek_Schedule_v3.pdf" tmpFilename="/usr/tmp/CGItemp28185" user="zimmerst" version="1"

Revision 302014-09-09 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room here ***

Line: 36 to 36
 

Run-2 information for combined ATLAS - LHCf (preliminary)

Some information in preparation for the combined running with LHCf is collected on this page.
Added:
>
>

Useful online links (preliminary, these will be put in proper locations later)

New CTP page

 
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v2.pdf" attr="h" comment="M-Week Schedule version 2" date="1392044436" name="MilestoneWeek_Schedule_v2.pdf" path="MilestoneWeek_Schedule_v2.pdf" size="75964" stream="MilestoneWeek_Schedule_v2.pdf" tmpFilename="/usr/tmp/CGItemp28226" user="zimmerst" version="1"
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v3.pdf" attr="h" comment="M-Week schedule version 3 (Feb 10 2014)" date="1392044455" name="MilestoneWeek_Schedule_v3.pdf" path="MilestoneWeek_Schedule_v3.pdf" size="76926" stream="MilestoneWeek_Schedule_v3.pdf" tmpFilename="/usr/tmp/CGItemp28185" user="zimmerst" version="1"
META FILEATTACHMENT attachment="milestones-v4.png" attr="h" comment="Atlas-Milestone-Run-Schedule" date="1399275475" name="milestones-v4.png" path="milestones-v4.png" size="157756" stream="milestones-v4.png" tmpFilename="/usr/tmp/CGItemp26826" user="apolini" version="1"

Revision 292014-09-01 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room here ***

Line: 33 to 33
  Please note that all of the material and links on Run-2 Operation and Shift Model has been moved to this page.
Added:
>
>

Run-2 information for combined ATLAS - LHCf (preliminary)

Some information in preparation for the combined running with LHCf is collected on this page.
 
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v2.pdf" attr="h" comment="M-Week Schedule version 2" date="1392044436" name="MilestoneWeek_Schedule_v2.pdf" path="MilestoneWeek_Schedule_v2.pdf" size="75964" stream="MilestoneWeek_Schedule_v2.pdf" tmpFilename="/usr/tmp/CGItemp28226" user="zimmerst" version="1"
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v3.pdf" attr="h" comment="M-Week schedule version 3 (Feb 10 2014)" date="1392044455" name="MilestoneWeek_Schedule_v3.pdf" path="MilestoneWeek_Schedule_v3.pdf" size="76926" stream="MilestoneWeek_Schedule_v3.pdf" tmpFilename="/usr/tmp/CGItemp28185" user="zimmerst" version="1"

Revision 282014-08-11 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room here ***

Line: 18 to 18
 
Changed:
<
<
>
>
 

Milestone Week Sub-Detector Integration Schedule

Line: 31 to 31
 

Run-2 Operations Model/Shift Organization Discussion

Changed:
<
<
Please note that all of the material and links on Run-2 Operation and Shift Model has been moved to this page.
>
>
Please note that all of the material and links on Run-2 Operation and Shift Model has been moved to this page.
 
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v2.pdf" attr="h" comment="M-Week Schedule version 2" date="1392044436" name="MilestoneWeek_Schedule_v2.pdf" path="MilestoneWeek_Schedule_v2.pdf" size="75964" stream="MilestoneWeek_Schedule_v2.pdf" tmpFilename="/usr/tmp/CGItemp28226" user="zimmerst" version="1"
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v3.pdf" attr="h" comment="M-Week schedule version 3 (Feb 10 2014)" date="1392044455" name="MilestoneWeek_Schedule_v3.pdf" path="MilestoneWeek_Schedule_v3.pdf" size="76926" stream="MilestoneWeek_Schedule_v3.pdf" tmpFilename="/usr/tmp/CGItemp28185" user="zimmerst" version="1"

Revision 272014-08-05 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room here ***

Line: 19 to 19
 

Added:
>
>
 

Milestone Week Sub-Detector Integration Schedule

Revision 262014-07-22 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room here ***

Line: 22 to 22
 

Milestone Week Sub-Detector Integration Schedule

Changed:
<
<
The current version of the M-Week Planning can be found here.
>
>
The current version of the M-Week Planning can be found here.
 
Changed:
<
<
milestones-v8.png
>
>
milestones-v9.jpg
  The Milestone Week Sub-System Checklist Form is avaliable here: docx, pdf
Line: 40 to 40
 
META FILEATTACHMENT attachment="M_Week_Checklist.pdf" attr="h" comment="M week checklist" date="1400746387" name="M_Week_Checklist.pdf" path="M_Week_Checklist.pdf" size="77681" stream="M_Week_Checklist.pdf" tmpFilename="/usr/tmp/CGItemp33792" user="apolini" version="1"
META FILEATTACHMENT attachment="milestones-v7.png" attr="h" comment="Milestone Schedule v.7" date="1402568408" name="milestones-v7.png" path="milestones-v7.png" size="77369" stream="milestones-v7.png" tmpFilename="/usr/tmp/CGItemp42268" user="apolini" version="1"
META FILEATTACHMENT attachment="milestones-v8.jpg" attr="h" comment="Milestone Schedule v.8" date="1403604225" name="milestones-v8.jpg" path="milestones-v8.jpg" size="115492" stream="milestones-v8.jpg" tmpFilename="/usr/tmp/CGItemp42487" user="apolini" version="1"
Added:
>
>
META FILEATTACHMENT attachment="milestones-v9.jpg" attr="h" comment="" date="1406038265" name="milestones-v9.jpg" path="milestones-v9.jpg" size="118703" stream="milestones-v9.jpg" tmpFilename="/usr/tmp/CGItemp36239" user="apolini" version="1"

Revision 252014-07-21 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room here ***

Please note that this being updated for the moment only during milestone runs and planned special activities in ACR)

Changed:
<
<

Subsystems Requests for CTP/tests in Global Partition

>
>

P1 Run Preparation Activities:

 
Changed:
<
<
(placeholder for the moment)
>
>
Subsystems Requests for CTP or Tests in Global Partition (Google Calendar, visible only from GPN, no P1 network)
 

Milestone Week Dates

Revision 242014-07-21 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room here ***

Please note that this being updated for the moment only during milestone runs and planned special activities in ACR)

Added:
>
>

Subsystems Requests for CTP/tests in Global Partition

(placeholder for the moment)

 

Milestone Week Dates

Revision 232014-06-24 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room here ***

Line: 17 to 17
 

Milestone Week Sub-Detector Integration Schedule

Changed:
<
<
The current version of the M-Week Planning can be found here.
>
>
The current version of the M-Week Planning can be found here.
 
Changed:
<
<
milestones-v7.png
>
>
milestones-v8.png
  The Milestone Week Sub-System Checklist Form is avaliable here: docx, pdf
Line: 27 to 27
  Please note that all of the material and links on Run-2 Operation and Shift Model has been moved to this page.
Changed:
<
<
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v2.pdf" attr="" comment="M-Week Schedule version 2" date="1392044436" name="MilestoneWeek_Schedule_v2.pdf" path="MilestoneWeek_Schedule_v2.pdf" size="75964" stream="MilestoneWeek_Schedule_v2.pdf" tmpFilename="/usr/tmp/CGItemp28226" user="zimmerst" version="1"
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v3.pdf" attr="" comment="M-Week schedule version 3 (Feb 10 2014)" date="1392044455" name="MilestoneWeek_Schedule_v3.pdf" path="MilestoneWeek_Schedule_v3.pdf" size="76926" stream="MilestoneWeek_Schedule_v3.pdf" tmpFilename="/usr/tmp/CGItemp28185" user="zimmerst" version="1"
META FILEATTACHMENT attachment="milestones-v4.png" attr="" comment="Atlas-Milestone-Run-Schedule" date="1399275475" name="milestones-v4.png" path="milestones-v4.png" size="157756" stream="milestones-v4.png" tmpFilename="/usr/tmp/CGItemp26826" user="apolini" version="1"
>
>
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v2.pdf" attr="h" comment="M-Week Schedule version 2" date="1392044436" name="MilestoneWeek_Schedule_v2.pdf" path="MilestoneWeek_Schedule_v2.pdf" size="75964" stream="MilestoneWeek_Schedule_v2.pdf" tmpFilename="/usr/tmp/CGItemp28226" user="zimmerst" version="1"
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v3.pdf" attr="h" comment="M-Week schedule version 3 (Feb 10 2014)" date="1392044455" name="MilestoneWeek_Schedule_v3.pdf" path="MilestoneWeek_Schedule_v3.pdf" size="76926" stream="MilestoneWeek_Schedule_v3.pdf" tmpFilename="/usr/tmp/CGItemp28185" user="zimmerst" version="1"
META FILEATTACHMENT attachment="milestones-v4.png" attr="h" comment="Atlas-Milestone-Run-Schedule" date="1399275475" name="milestones-v4.png" path="milestones-v4.png" size="157756" stream="milestones-v4.png" tmpFilename="/usr/tmp/CGItemp26826" user="apolini" version="1"
 
META FILEATTACHMENT attachment="milestones-v6.png" attr="h" comment="Milestone Schedule v.7" date="1400772132" name="milestones-v6.png" path="Milestone-schedule.png" size="62384" stream="Milestone-schedule.png" tmpFilename="/usr/tmp/CGItemp37270" user="apolini" version="2"
META FILEATTACHMENT attachment="M_Week_Checklist.docx" attr="h" comment="M Week Checklist" date="1400746373" name="M_Week_Checklist.docx" path="M_Week_Checklist.docx" size="19219" stream="M_Week_Checklist.docx" tmpFilename="/usr/tmp/CGItemp33833" user="apolini" version="1"
META FILEATTACHMENT attachment="M_Week_Checklist.pdf" attr="h" comment="M week checklist" date="1400746387" name="M_Week_Checklist.pdf" path="M_Week_Checklist.pdf" size="77681" stream="M_Week_Checklist.pdf" tmpFilename="/usr/tmp/CGItemp33792" user="apolini" version="1"
META FILEATTACHMENT attachment="milestones-v7.png" attr="h" comment="Milestone Schedule v.7" date="1402568408" name="milestones-v7.png" path="milestones-v7.png" size="77369" stream="milestones-v7.png" tmpFilename="/usr/tmp/CGItemp42268" user="apolini" version="1"
Added:
>
>
META FILEATTACHMENT attachment="milestones-v8.jpg" attr="h" comment="Milestone Schedule v.8" date="1403604225" name="milestones-v8.jpg" path="milestones-v8.jpg" size="115492" stream="milestones-v8.jpg" tmpFilename="/usr/tmp/CGItemp42487" user="apolini" version="1"

Revision 222014-06-12 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

Run-2 Preparation, 2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room here ***

Line: 17 to 17
 

Milestone Week Sub-Detector Integration Schedule

Changed:
<
<
The current version of the M-Week Planning can be found here.
>
>
The current version of the M-Week Planning can be found here.
 
Changed:
<
<
milestones-v6.png
>
>
milestones-v7.png
  The Milestone Week Sub-System Checklist Form is avaliable here: docx, pdf
Line: 33 to 33
 
META FILEATTACHMENT attachment="milestones-v6.png" attr="h" comment="Milestone Schedule v.7" date="1400772132" name="milestones-v6.png" path="Milestone-schedule.png" size="62384" stream="Milestone-schedule.png" tmpFilename="/usr/tmp/CGItemp37270" user="apolini" version="2"
META FILEATTACHMENT attachment="M_Week_Checklist.docx" attr="h" comment="M Week Checklist" date="1400746373" name="M_Week_Checklist.docx" path="M_Week_Checklist.docx" size="19219" stream="M_Week_Checklist.docx" tmpFilename="/usr/tmp/CGItemp33833" user="apolini" version="1"
META FILEATTACHMENT attachment="M_Week_Checklist.pdf" attr="h" comment="M week checklist" date="1400746387" name="M_Week_Checklist.pdf" path="M_Week_Checklist.pdf" size="77681" stream="M_Week_Checklist.pdf" tmpFilename="/usr/tmp/CGItemp33792" user="apolini" version="1"
Added:
>
>
META FILEATTACHMENT attachment="milestones-v7.png" attr="h" comment="Milestone Schedule v.7" date="1402568408" name="milestones-v7.png" path="milestones-v7.png" size="77369" stream="milestones-v7.png" tmpFilename="/usr/tmp/CGItemp42268" user="apolini" version="1"

Revision 212014-05-23 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"
Changed:
<
<

2014 Operations and Milestone Weeks

>
>

Run-2 Preparation, 2014 Operations and Milestone Weeks

 

Updated Daily Run Plan from the control room here ***

Please note that this being updated for the moment only during milestone runs and planned special activities in ACR)

Line: 13 to 13
 
Added:
>
>
 

Milestone Week Sub-Detector Integration Schedule

The current version of the M-Week Planning can be found here.

Revision 202014-05-22 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room here ***

Line: 28 to 28
 
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v2.pdf" attr="" comment="M-Week Schedule version 2" date="1392044436" name="MilestoneWeek_Schedule_v2.pdf" path="MilestoneWeek_Schedule_v2.pdf" size="75964" stream="MilestoneWeek_Schedule_v2.pdf" tmpFilename="/usr/tmp/CGItemp28226" user="zimmerst" version="1"
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v3.pdf" attr="" comment="M-Week schedule version 3 (Feb 10 2014)" date="1392044455" name="MilestoneWeek_Schedule_v3.pdf" path="MilestoneWeek_Schedule_v3.pdf" size="76926" stream="MilestoneWeek_Schedule_v3.pdf" tmpFilename="/usr/tmp/CGItemp28185" user="zimmerst" version="1"
META FILEATTACHMENT attachment="milestones-v4.png" attr="" comment="Atlas-Milestone-Run-Schedule" date="1399275475" name="milestones-v4.png" path="milestones-v4.png" size="157756" stream="milestones-v4.png" tmpFilename="/usr/tmp/CGItemp26826" user="apolini" version="1"
Changed:
<
<
META FILEATTACHMENT attachment="milestones-v6.png" attr="" comment="Milestone Schedule v.6" date="1400485238" name="milestones-v6.png" path="milestones-v6.png" size="160479" stream="milestones-v6.png" tmpFilename="/usr/tmp/CGItemp33748" user="apolini" version="1"
>
>
META FILEATTACHMENT attachment="milestones-v6.png" attr="h" comment="Milestone Schedule v.7" date="1400772132" name="milestones-v6.png" path="Milestone-schedule.png" size="62384" stream="Milestone-schedule.png" tmpFilename="/usr/tmp/CGItemp37270" user="apolini" version="2"
 
META FILEATTACHMENT attachment="M_Week_Checklist.docx" attr="h" comment="M Week Checklist" date="1400746373" name="M_Week_Checklist.docx" path="M_Week_Checklist.docx" size="19219" stream="M_Week_Checklist.docx" tmpFilename="/usr/tmp/CGItemp33833" user="apolini" version="1"
META FILEATTACHMENT attachment="M_Week_Checklist.pdf" attr="h" comment="M week checklist" date="1400746387" name="M_Week_Checklist.pdf" path="M_Week_Checklist.pdf" size="77681" stream="M_Week_Checklist.pdf" tmpFilename="/usr/tmp/CGItemp33792" user="apolini" version="1"

Revision 192014-05-22 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room here ***

Line: 19 to 19
  milestones-v6.png
Added:
>
>
The Milestone Week Sub-System Checklist Form is avaliable here: docx, pdf
 

Run-2 Operations Model/Shift Organization Discussion

Please note that all of the material and links on Run-2 Operation and Shift Model has been moved to this page.

Line: 28 to 29
 
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v3.pdf" attr="" comment="M-Week schedule version 3 (Feb 10 2014)" date="1392044455" name="MilestoneWeek_Schedule_v3.pdf" path="MilestoneWeek_Schedule_v3.pdf" size="76926" stream="MilestoneWeek_Schedule_v3.pdf" tmpFilename="/usr/tmp/CGItemp28185" user="zimmerst" version="1"
META FILEATTACHMENT attachment="milestones-v4.png" attr="" comment="Atlas-Milestone-Run-Schedule" date="1399275475" name="milestones-v4.png" path="milestones-v4.png" size="157756" stream="milestones-v4.png" tmpFilename="/usr/tmp/CGItemp26826" user="apolini" version="1"
META FILEATTACHMENT attachment="milestones-v6.png" attr="" comment="Milestone Schedule v.6" date="1400485238" name="milestones-v6.png" path="milestones-v6.png" size="160479" stream="milestones-v6.png" tmpFilename="/usr/tmp/CGItemp33748" user="apolini" version="1"
Added:
>
>
META FILEATTACHMENT attachment="M_Week_Checklist.docx" attr="h" comment="M Week Checklist" date="1400746373" name="M_Week_Checklist.docx" path="M_Week_Checklist.docx" size="19219" stream="M_Week_Checklist.docx" tmpFilename="/usr/tmp/CGItemp33833" user="apolini" version="1"
META FILEATTACHMENT attachment="M_Week_Checklist.pdf" attr="h" comment="M week checklist" date="1400746387" name="M_Week_Checklist.pdf" path="M_Week_Checklist.pdf" size="77681" stream="M_Week_Checklist.pdf" tmpFilename="/usr/tmp/CGItemp33792" user="apolini" version="1"

Revision 182014-05-19 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room here ***

Line: 15 to 15
 

Milestone Week Sub-Detector Integration Schedule

Changed:
<
<
The current version of the M-Week Planning can be found here. milestones-v4.png
>
>
The current version of the M-Week Planning can be found here.

milestones-v6.png

 

Run-2 Operations Model/Shift Organization Discussion

Line: 26 to 27
 
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v2.pdf" attr="" comment="M-Week Schedule version 2" date="1392044436" name="MilestoneWeek_Schedule_v2.pdf" path="MilestoneWeek_Schedule_v2.pdf" size="75964" stream="MilestoneWeek_Schedule_v2.pdf" tmpFilename="/usr/tmp/CGItemp28226" user="zimmerst" version="1"
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v3.pdf" attr="" comment="M-Week schedule version 3 (Feb 10 2014)" date="1392044455" name="MilestoneWeek_Schedule_v3.pdf" path="MilestoneWeek_Schedule_v3.pdf" size="76926" stream="MilestoneWeek_Schedule_v3.pdf" tmpFilename="/usr/tmp/CGItemp28185" user="zimmerst" version="1"
META FILEATTACHMENT attachment="milestones-v4.png" attr="" comment="Atlas-Milestone-Run-Schedule" date="1399275475" name="milestones-v4.png" path="milestones-v4.png" size="157756" stream="milestones-v4.png" tmpFilename="/usr/tmp/CGItemp26826" user="apolini" version="1"
Added:
>
>
META FILEATTACHMENT attachment="milestones-v6.png" attr="" comment="Milestone Schedule v.6" date="1400485238" name="milestones-v6.png" path="milestones-v6.png" size="160479" stream="milestones-v6.png" tmpFilename="/usr/tmp/CGItemp33748" user="apolini" version="1"

Revision 172014-05-14 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"
Changed:
<
<

2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room here

>
>

2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room here ***

Please note that this being updated for the moment only during milestone runs and planned special activities in ACR)

 

Milestone Week Dates

Changed:
<
<
  • M1 Run/Week: Feb 17 to 21 2014
>
>
 
Line: 14 to 16
 

Milestone Week Sub-Detector Integration Schedule

The current version of the M-Week Planning can be found here.

Added:
>
>
milestones-v4.png
 
Changed:
<
<

Run-2 Preparation

Operations Model/Shift Organization Discussion

After the Run-1 Operations Workshop in summer 2013 Run Coordination was charged to work out a proposal for the Run-2 Data Taking Operation Model and Shift Organization; the proposal has been presented

  1. In the LS1 Weekly Meeting on Jan 27th 2014 (to the systems and system run coordinators),
  2. In the ATLAS Weekly/Open EB on Tue Jan 28th 2014
  3. In the ATLAS Week on Feb 12 2014
  4. In the Discussion and Wrap-up Meeting March 18 2014

Following the feedback from the collaboration and the discussion at the wrap up meeting a draft version of the document of the Atlas Operation Model (still in preparation) is available as EDMS document in: https://edms.cern.ch/document/1348082/1. This will be soon presented to the collaboration.

Feedback and Input from the Collaboration

Feedback and comments have been requested from the collaboration, as well as from systems and project leaders; in parallel, Run Coordination will actively seek the dialog with sub-detectors and systems; It is planned to wrap up the discussion and arrive at a decision in dedicated workshop on Tue March 18.

In order to facilitate the feedback collection process, comments shall be added to the 2 paragraphs following below directly in the Twiki page.

Run-2 Operations Model Proposal --- Comments, Input, Feedback concerning Shift Crew Composition/Shift Tasks

Name System, experience Comment
Henric Wilkens   Maybe its all decided already, but if this is a proposal for discussion, then I could see alternative ways to reach a shift crew of 6. One which comes naturally to me, close to the ATLAS core organisation would be: Shift leader. Run control / trigger. ID. Calo / Forward. Muons. Slimos / Central DCS. 
This would be much closer to how we have been running, releave the detector system to try to merge the shift tasks of ID/Calo Fwd/Muons into one single shifter. It will also address some of the comments made in the questions following your presentation. 
Marko Mikuz Shift leader in 2012/13 As one of the field soldiers staffing the central desk in the second row I feel obliged to state my opinion from my personal view as shift leader. I shall directly confront the two proposals, although there is certainly a grey zone in-between.
a) Detector Controls, Beam Conditions and Luminosity  vs. separating out detector blocks ( ID(+Beam Conditions), Calo / Forward, Muons) and assigning Central DCS to SLIMOS The detector shifters were among the most busy on a data-taking shift. New challenges in Run 2 (25 ns, 13-14 TeV) could well be offset by higher level of AI in their systems but I sincerely doubt the load shall be reduced, at least at the start and well into first year of running.
b) RC & Trigger vs. RC/Trigger I (my fault ?) very rarely interacted with the Trigger shifter, most of the time with RC, who as a rule was sufficiently knowledgeable of the trigger issues.
c) SLIMOS & DQ vs. SLIMOS(+DQ ?) My personal view was that DQ is the most dispensable shifter and while SLIMOS is a must she/he could be loaded with additional tasks. At least SLIMOS & DQ look complimentary as their load peaks at different times - SLIMOS is most active in-between runs and DQ during data-taking.
Andrej Gorisek BCM I am more for detector-centric approach. I.e.  SL(+DQ), SLIMOS(+DCS), Run Control (+trigger), ID (+BCM/BLM), Calo (+FWD), Muons.
 In such a case also the additional/refreshment training would be kept to the minimum. From point of view of BCM it would be ideal for the task to stay in the same group of (mostly already trained) ID shifters. I also think DQ could be handled by a shift leader. From my experience there were shifts of irregular beams and all sort of machine studies when DQ shifter was just dismissed but there was quite some work for a shift leader. On the other hand the DQ shifter had the most work in shifts when everything was running smoothly and we were collecting lots of good data. In those shifts shift leader was less stressed.
Saverio SCT (personal opinion) just to say that I fully support the scheme you have proposed. The ID shifter merger was a success and I believe the process can be taken further. I particularly liked the question and your answer on the benefits we'd have, and if I may add, this scheme would reduce some of the little hiccups which were due to miscommunication between central and detector shifter. Of course, subdetector which feel they need a shifter are still free to add a shifter in case of periods of potential problems. This scheme actually gives some more flexibility (e.g. adding extra shifters or experts only when needed)  and will push the subdetector communities to further improve the tools for automatic supervision and the overall reliability of the detector.
Joseph Rothberg * The proposal to drop subdetector shifters will only work if each subdetector group provides software tools to detect known and potential subdetector problems and failure modes. There is very little emphasis on this in the proposal. Good problem-detection software is essential.
A time (and deadline) should be scheduled later this year when each subdetector demonstrates its problem-detection tools to the subdetector managers and to representatives from the shift leader/run coordinator/safety teams. The demonstrations should include some simulations of possible problems and the alerts/warnings that appear.
There also must be "written" documentation on the types of problems detected, the types of alerts/warnings issued, the severity, and the suggested responses.
Stefan Schlenker DCS Keeping the sub-detector (group) shifters will most likely allow a more efficient running in the beginning, mainly since we are all used to work like this. However, in the long term perspective to my mind there is no alternative to the merging and removing of having sub-detector (group) structures for shifters and their expert counterparts. For me, the natural separation in terms of operation tools is the detector control, run control/DAQ/trigger operation, and data quality checking. This is how the system was designed.
The question is thus not if we should do it but when we should do it. Nobody can really expect that we will run ATLAS forever with that many shifters and the sizable collection of operator/expert tools here and there all doing similar things. From what I know, many HEP experiments went through this process with almost always the same result. That the transition period will cost time and effort remains undisputed.
Today there was the question asked what we might gain. I think we will on the log term gain not only a reduction of shifters which is the least important part, but the streamlining of the online system and operator tools should finally result in a reduced workload on the operations support team of all systems. This is where we had to fight an increasing lack of manpower/expertise already in run 1.
I think we should invest better now than at a later stage when the detector upgrade will take its toll on the operation and commissioning effort in the subsequent long shutdown periods. Further I would support the suggestion of Dave to try to have sub-detector group discussions with TC/run coordination+maybe central systems first to facilitate a more prepared and structured discussion in the overall workshop.
Dave Robinson SCT I personally agree with much of what Saverio said, but just to avoid possible confusion, this does not (yet) represent the viewpoint of the ID community, as we haven't yet had the discussion.
I would very much welcome the suggestion that Technical Coordination should meet separately with the four sub detector communities to discuss the proposal and any detector-specific concerns,  rather than in an open discussion in a large meeting.  I think the individual subsystems can sometimes have very different concerns.
Adrey Loginov TRT Can we think of something like "Risk Analysis" of possible operation faults for the two shift scenarios discussed so far? (the subsystem-based one and the type-of-task one).
There were some situations in Run 1 when shifters could have been more efficient, although overall it worked well. One can imagine similar situations with the two shift scenarios and see how things will work.
Manpower-wise, if it's only 1 person difference in the two shift crews then it's not the highest concern. All that really matters (as a few of you pointed out at the ATLAS meeting today) is the data quality /efficiency of the detector operation. There are strong points in both shift approaches, so we should make sure we don't overlook the weak ones.
>
>

Run-2 Operations Model/Shift Organization Discussion

 
Changed:
<
<
Run-2 Operations Model Proposal --- Comments, Input, Feedback concerning Shift Allocation Scheme, Minimum Number of Shifts, Shift Eligibility Criteria, Training Organization

Name System, experience Comment
Norman Gee * Comments from the perspective of someone doing shifts but not CERN-resident
The Central Shift Call needs to be early enough that flights can be booked for the training at reasonable prices, and also that CERN Hostel room is available;
Collaborators outside CERN often have institute responsibilities, e.g. teaching, or on the other hand may already have to travel to CERN for detector meetings. There was supposed to be some priority in the shift booking system for non-CERN residents to allow for this, but in practise I found that, e.g., the weekend trigger shifts were normally filled within around 10 minutes of opening, and at least half were taken by people I knew were CERN-resident. It would be excellent if your work somehow also took this into account. I’m not clear how this works with the “8 weeks total” in your foil 9.
Tetiana Hryn'Ova * Instead of 21 shifts minimum require 11 shifts minimum with 21 recommended (this will be more inline with our Run 1 numbers). Instead of allocation booking (seems a huge time-waste for run coordinators) keep self-booking with people wanting to do more that 21 shifts having opportunity to book earlier (prebook) & assure training is booked at the same time as shifts
* * I do have serious concerns with the shift allocation scheme, that is too strict and people should have the opportunity to book their shifts themselves, also the minimum number of shifts is too strict and should rather be seen as a guideline with allowed variance, the distributions for run1 were not that bad to justify that rigid scheme.
Nicolas Berger * Two comments on the new model:
21 shifts/person minimum :
According to your own computation, this would mean that only ~200 people could take part in shifts in a given year, which is probably even less than number of new students coming in each year (1000 students in ATLAS / ~4 years). This would mean that some students would not be able to take even 1 block of shift during their studies, which I find regrettable.
This would also mean that the tasks open to non-students would only be "expert" tasks, which are few in number and require a large time-commitment. This would lead to a de facto split between a small pool of experts, and the bulk of the collaboration which would be totally disconnected from detector operations.
I realize that in a sense this is the whole point of the change -- to concentrate the work in the hands of fewer experts to improve efficiency. However this should be balanced against the risk that data-taking becomes a kind of "black box" for most of the collaboration. In my view the current requirements seem too skewed in the first direction.
Switch to "allocation" model :
I don't see the reason to require people to free up 8 full weeks of their schedule in a 6-month period in order to be allowed to take shifts. This will lead to inconvenient bookings, reschedulings, etc. which will just waste everybody's time.
I see there has been an effort to reintroduce some flexibility a posteriori (1 day per week exception, etc.), but this can by definition only help in some particular situations. I think that keeping a signup-based system would be both more convenient for aspiring shifters, and easier to manage for you.
Jessica Leveque DQ feedback from subsystems 1) Number of shifts
- 5 months * 30 days * 3 shifts per day * 6 desks = 2700 shifts
- if 21 shifts minimum required: 6.5% (assuming 2000 ATLAS active members willing to take shifts)
Many more than 6% of newcomers per year: how do we ensure that new student and postdoc get in touch with the detector environment ? By restricting the number of people accessing shifts, we also reduce the possibility for new people to approach the expert on-call tasks (critical point, see number 3) below)
2) Shifts organization
- From the shifter point of view: asking people to block 8 weeks, several months in advanced, and force them to be randomly assigned shifts within this 8 weeks is unrealistic. People with families, teaching duties, limited stays at CERN (often 3 to 6 months for students) or convenership responsabilities in the collaboration can not do that. The "OR" of these 4 points covers a very large fraction of the ATLAS physicists.
- From the run coordination point of view: shift allocation instead of shift booking is a significant overload of work. Past experience in offline DQ showed that designing the shifter planning by hand several months in advance while taking into account the institutes quotas of the past shift periods (trying to provide a fair sharing of the available shifts within institutes), taking into account the shifters personal constraints,the trainings and the shadow shifts to allocate the shift blocks at the right time, and last but not least dealing with the numerous last minute cancellations and shifters swaps, is really a painful and time-consuming job. Something needs to be changed in OTP to help with this task, by either blocking people when the institutes reached their allocated quota, or adding more info about their training to block the shift allocation automatically if the training is not completed. Or maybe we need a "global shift manager" provided by ATLAS to take care of this task for all the desks altogether.
3) Detector experts on-call
- Less shifters in ACR probably implies a much stronger team of 24/7 expert on-call for the sub-systems.
- Experience from the past run shows that it is becoming harder and harder to recruit people for the expert and on-call tasks, as they require quite a long training (a few months at least before being operational), and to be fully based at CERN.
- One problem comes from the institutes, whose finances are being cut pretty much everywhere and are becoming more reluctant to send people at CERN for long periods of time.
- The major problem is that the most indicated people for this type of tasks are postdocs, who do not want to be stuck for a full year or more in technical tasks simply because it is not valued at all for their careers, and they need to do physics analysis. This is a deeper problem, already discussed elsewhere: if being an expert on-call is not considered as critical task and not valued enough by the collaboration, we will not find the people to do it.
- Back to the point of the restricted number of shifts: giving less people the opportunity to work in the control room reduces the pool of new people who could possibly be motivated to take responsabilities in the sub-systems.
Jimmy Proudfoot Tile Calorimeter My comments are based on the written document & I have similar concerns to many of those already stated on the twiki. While I agree with the goal of reducing the operations effort, I think that as proposed (as best I can understand it since the document doesn’t have an implementation plan) this proposal simply moves the effort to the experts on call.
The proposed shift allocation is too strict and needlessly limits the opportunities for graduate students and postdocs to participate in data-taking – I propose dropping the requirement to around 12 days which has been the norm in other experiments I have worked on. I have taken detector data-taking shifts in many different scenarios. My experience is that to have a “long” block of shifts in a short period of time is more effective than a series of short blocks of shift scattered through an extended period since the shifters are up-to-date on current issues/problem. Obviously with the CERN rules there needs to be time in between blocks of three days but it is possible to block out around 12 days of shifts within 3 weeks with appropriate blocks of 3 and 4 day elements.
The proposed plan places a huge burden on the experts on call; quoting the document “No low-level sub-detector actions are expected to be taken by the shifter on a regular basis “. I think this is unmanageable and I suggest that an intermediate level of expertise as placed in the hands of a detector expert in the ACR reduces the total number of pagers that will be required. One way to decide if this is indeed workable is to consult with the systems to find out how they would provide these experts whose knowledge ranges from the luminosity measurement, to readout errors and perhaps failures of stopless recovery. If the number is modest, say 15, then the plan will work, but if it gets to be ~100 then it clearly won’t. The hardest ones to fill are the ones requiring considerable expertise but which are very rarely needed – in this case I think we need to have a mechanism whereby the expert can be anywhere in the world and in contact with a suitably knowledgeable individual in the ACR.
One of the important tasks is taking calibrations and insuring that they are correct in the proposal this requires an Expert System, and there is enough work that the responsibility is shared around various members of the shift team. Again having system experts (Calorimeter, Trigger, Tracking System, Muon System) makes more sense.
I believe that in whatever scheme we approach the shift leader could be able to perform the DQ task since it will only entail reviewing some color coded status flags.
I am dismayed at the lack of any real effort to engage collaborators from outside CERN to be part of the overall scheme, and I hope that the final plan includes such opportunities more broadly around the collaboration. We were very successful in monitoring the Tile LVPS system from outside CERN even when modules were tripping once per minute (we developed a web-based monitoring system which intercepted and parsed the error log entries from the Oracle database). Any low rate “event” involving stopless recovery is a candidate for this type of web-based remote monitoring – and we hope that most of these events are low rate. We are running a modified version of this during LS1. I f you are interested in more details, please contact us – we think that this methodology should be applicable to analogous monitoring in other systems.
Daniel Froidevaux * Here is some feedback on the proposed new scheme for shifts for run-2 as presented to us over the past weeks. I give you my feedback with a rather specific dual viewpoint:
a) that of someone having done numerous TRT, DQ, RunControl and Shift Leader shifts over the whole period of run-1. I enjoyed these shifts and would very much like to continue taking shifts since this is to me an integral part of what we should all do as experimentalists.
b) that of someone responsible (in great part) for an important moment in their careers of many young physicists in ATLAS who are either fellows or staff in the CERN team. It is important for all of them to be able to serve in some role at point 1. This does not necessarily have to be for main shifts, it is and can be in many cases as expert shifters, e.g. for trigger. Nevertheless, the possibility to serve as main shifters should not be excluded.
And here is my feedback, which is mostly about the shift allocation scheme and the minimum number of shifts:
1) When based at CERN and especially when very busy during the week with many meetings etc, most people would benefit from a less rigid scheme than the one proposed, both in terms of the minimum number of shifts which is far too high for someone like me for example over a period of five months. I have filled in in the past on numerous occasions holes in the schedule for night shifts, week-end shifts etc which are the ones which are easiest for me to do, but I believe strongly that the system should allow (at least for CERN-based people) for doing the 20 shifts over a longer period. Otherwise, you will just kill the participation, certainly from my side but also from others I am sure. And this would be very sad. You can see easily for yourselves how many shifts people from the CERN team have done over 2011 and 2012, I cannot collect these statistics myself.
2) The shift allocation scheme should itself be very flexible even if not based on individual bookings anymore. I can really only take my own example as one among many and nothing too special to illustrate this. When signing in for RC or Shift Leader shifts during next year, I would volunteer for night shifts only, preferably not more than one or two in a row, but apart from specific weeks when I am away, this could be regular over the whole year more or less. But it might not fit with a required frequency of 20 shifts over five months, this is just too rigid. I would personally prefer to do 20 shifts over 10 months although I could agree of course to fit better into the periods you might propose.
3) For the young people in the CERN team, it would be nice to see at the same time the possibilities and requirements for main shifts at P1 and also for expert shifts as they will be revised for run-2. I have very little understanding of this at the moment, and I would very much like to see a global picture of how this would work to present it also to our fellows and staff to encourage them to participate (many already do and are indeed expert shifters, but there are also many who do nothing at point-1 or related to point-1 activities).
Stephen Haywood (for the RAL Team) Thoughts on ACR Shifts from the RAL Group
We broadly support the proposal to reduce the numbers of ACR shifts and make the Shift Crew more “professional”. We are concerned that the streamlining of ACR Shifts should be seen in the context of the overall streamlining of OTP activities, namely Class 2 & 3. We are concerned that the whole OTP system has become bloated and created an “arms race”, whereby everyone wants his/her work badged as OTP and no one wants to acknowledge that his/her work could be given lower credit. This all goes to inflate the amount of OTP needed from the Collaboration.
This is going beyond your remit, we guess.
At RAL, we are concerned as to how we as a group will satisfy our OTP obligations. This is because as a national lab, we are expected to spearhead new projects on behalf of the UK, so 2/3 of our effort is dedicated to the Upgrade. (Most of the rest of our effort goes into Operations, with very little available for physic s analysis). Almost all of our team have been on ATLAS for many years and so wish to remain Authors, but find it hard because they are not well-positioned to do Class 2 or 3, while it was easier to do Class 1.
Again this is not your immediate concern and should not be the sort of argument to drive the changes for Class 1: We do not want to inflate Class 1 shifts in order to enable some to fulfil their OTP commitments – this would be to pervert the raison d’etre for OTP. We will have a chance to comment on this when Thorsten undertakes his OTP survey. While shifts can be a burden, precisely because we are removed from the day-to-day operations of ATLAS, many of us find them helpful to keep us connected to the experiment and enable us to feel we are contributing.
We do think shifts serve a role to educate students. We consider it important that if a Student comes to CERN for a year, he/she should be able to engage in the ACR shifts, irrespective of when he/she turns up … may be an issue if the student arrives just after the intake of ACR recruits.
While shifts are valuable to give insight as to how a real detector works (the fact that parts trip, the beam is messy, there can be long delays between fills) and they help the Student feel part of the collaboration, this should not be overstated. There are other ways Students can serve and learn about the experiment.
Suggestion: Ideally, Students should be fully engaged in ACR duties. However, since this will probably be impossible for all Students, a solution might be that Students who cannot do ACR Shifts should be allowed/encouraged to sit a couple of shadow shifts, as observers, not as people trying to qualify.
Suggestion: While it may be impossible for all institutions to have team members undertaking shifts all the time, maybe rotas could be set up to allocate block of shifts to institutions. For example, in Year 1, institutes A, B and C are invited to provide Shifters; Year 2, D, E and F are invited, etc...
Chris Meyer The Tile Calorimeter Team The Tile Calorimeter system strongly supports reducing the number of people shifting in the ATLAS control room during 2015, as well as improving the detector monitoring software. In addition, the new scheme for shift allocation will be necessary for future operations. By requiring a minimum of 21 shifts during the sign-up procedure, and enforcing it when final allocation is performed, a highly experienced team at P1 is guaranteed. Our only concern lies with the currently proposed division of responsibility, which we feel would have difficulty addressing multiple, or unexpected, issues during data taking.
We think that a more detector-oriented desk would provide a faster, more robust response to any issues that may arise during data taking. For example, in the attached plot you can see in blue that around 32/pb of data was lost due to timing in September 2012. This occurred after a stopless removal, when the timing of an entire partition (25% of the sub-detector) was shifted by 25 ns after being restarted. This caused a large impact on the trigger, resulting in data loss.
In this case, a quick investigation was needed by experts familiar with the Tile Calorimeter from the DAQ, DCS, and DQ teams. Because it had never happened before, no amount of automated DQ checks or preparation could have spotted it. It was also important that all three systems were at the same desk, so that the shifter could follow the progression from DCS to DAQ, and finally verify the issue as fixed using DQ information.
A similarly fast response will be crucial in future, unexpected situations like this. In addition, this scheme leaves a separate shifter available to address other problems that may arise with different sub-detector systems in parallel.
We think that with only minor changes to the division of responsibility, which result in a more detector-oriented scheme, the number of shifters can remain at 7 or fewer while still ensuring high-quality results from ATLAS.
Wainer, Bruce, Alex, Anna etc. Trigger Operations and TDAQ System Run Coordinators Shift crew
The two models being debated both require considerable clarification concerning the plan for implementation.Both require effort in order to be implemented so as to evolve to more common methods, tools and automation.This is a requirement if our colleagues are to be trained on all shift aspects as it decreases the spectrum of tools/methods and procedures that need to be learnt. The detector centric model requires less effort, but even in this model the TDAQ project and Trigger activity would like to see more common methods and tools.
An adiabatic evolution should be envisaged, where ATLAS starts with the detector centric model and evolves to the model proposed by Run Coordination (or a possible variant of that model). The rate of change should be based on a plan which includes the effort required (and the proposed responsibilities) for the implementation.
A challenge for the detector centric model is the correct handling of ATLAS wide issues, for example global DQ. Does global DQ include the Trigger DQ? If not, where would the trigger DQ be best monitored? Adding this to the charge of the Run Control Shifter, as currently implied, risks overloading the Run Control Shifter.
There is concern that the potential increase in responsibility born by the Run Control Shifter is beyond what can be reasonably expected for him or her to handle.
Regarding calibration runs between fills, this is a task that, if not already the case, should be automated. The same method and tools, as mentioned, above should be used across all the concerned detector systems. Which member of the shift crew is responsible for the execution of these special runs should be less of an issue, if the optimal common procedures are implemented. However, as mentioned above, the work load on the Run Control shifter during inter-fills has proven to be significant in Run 1 and therefore the responsibility for calibration runs should not fall on the Run Control Shifter. The responsibility for calibration runs best fall elsewhere, most obviously with the detector systems. In this way, it appears that the detector centric model lends itself better to calibration runs.
All shifters should be trained in all duties of the Shift crew regardless of which model is actually adopted.
Shift booking
The emphasis placed on having experienced shifters in the control room is very welcome.
The proposed implementation, as presented, seems to be Run Coordinator centric, i.e. will require significant effort by the ATLAS Run Coordination. The TDAQ project and Trigger activity would like instead to see an evolution of the current method of shift reservation. That is to say that individuals book their own shifts. The tool used to do this should implement the agreed Shift Booking Rules.
Splitting the year into two run periods appears to be too rigid and somewhat poorly motivated. As a minimum evolution, compared to Run 1, the TDAQ project and Trigger activity would like to see the grouping of shifts and would like to propose a model where: one block of shifts at least every three weeks is required, along with mandatory booking of at least of five blocks. Shifts booked by an individual should be for a single type of shift, e.g. Run Control shifter. Splitting the the five blocks over more than type of shift undermines continuity and therefore efficiency.
There is the open issue of the criteria according to which colleagues are required to re-do shifter training.
Roberto Ferrari for the Pavia group We, in Pavia, share several concerns about the proposal for changes in the shift policy. We had some discussions and we would like to provide you with our feedback.

We are concerned with few issues:

a) number of shifts required;
b) the limited number of people allowed to take shifts (the so-called "professional shift crews");
c) the suppression of all sub-detector shifters.

About the first point, we think that setting as a minimum, over 6 months, twice the average over the full run-1 period (according to the statistics shown in the public discussions) is a bit unfair and unjustified. The ATLAS efficiency in data recording provides a good demonstration that it is hardly a real problem. The only rationale for it seems to be the reduction of the number of people to be trained. Finally, to most (or likely all) of us, it looks quite impossible to satisfy the new requirement. We think it could be a much more reasonable compromise, for example, to set the previous average value as the minimum requirement over 6 months (i.e. 10 shifts over 6 months).

About the second point, most of us comes from experiences in which all the physicists were obliged to take control-room shifts. Now you are proposing a scheme in which you want the large majority of the physicists NOT to take shifts, reserved for a bunch of highly trained people. On the contrary, we think it should be much preferable (or even mandatory) that as many physicists as possible, and in particular young students, may have the responsibility of running the experiment. We think this should be a less robust but much more fertile choice.

About last point, we think that setting up the infrastructure (as well as the training) needed for the change is a hard and critical task. You will likely need to train all the shifters, since the sub-detector tasks will be distributed over all of them. Moreover a strong effort for the automatization of such tasks (i.e. calibration runs) will be needed. On the contrary, for the sub-detector shifts, already now quite a lot of people is trained and the tools are in place. If the goal is to reduce to 6 the total number of shifters, have you considered the possibility to simply merge the DQ and SL as well as Trigger and Run Control roles? What do you think about ?
>
>
Please note that all of the material and links on Run-2 Operation and Shift Model has been moved to this page.
 
Deleted:
<
<
  • Atlas-Milestone-Run-Schedule:
    milestones-v4.png
 
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v2.pdf" attr="" comment="M-Week Schedule version 2" date="1392044436" name="MilestoneWeek_Schedule_v2.pdf" path="MilestoneWeek_Schedule_v2.pdf" size="75964" stream="MilestoneWeek_Schedule_v2.pdf" tmpFilename="/usr/tmp/CGItemp28226" user="zimmerst" version="1"
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v3.pdf" attr="" comment="M-Week schedule version 3 (Feb 10 2014)" date="1392044455" name="MilestoneWeek_Schedule_v3.pdf" path="MilestoneWeek_Schedule_v3.pdf" size="76926" stream="MilestoneWeek_Schedule_v3.pdf" tmpFilename="/usr/tmp/CGItemp28185" user="zimmerst" version="1"

Revision 162014-05-14 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room here

Milestone Week Dates

  • M1 Run/Week: Feb 17 to 21 2014
Changed:
<
<
  • M2 Run/Week: Mar 31 to Apr 4 2014
  • M3 Run/Week: May 19 to May 23 2014
  • M4 Run/Week: Jul 7 to Jul 11 2014
  • M5 Run/Week: Sep 8 to Sep 12 2014
  • M6 Run/Week: Oct 13 to Oct 17 2014
  • Extended Cosmics Data Taking: (UPDATED) November 24th - December 7th (cooling/cryo yearly maintenance afterwards)
>
>
 

Milestone Week Sub-Detector Integration Schedule

Revision 152014-05-05 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

2014 Operations and Milestone Weeks

Updated Daily Run Plan from the control room here

Line: 13 to 13
 

Milestone Week Sub-Detector Integration Schedule

Changed:
<
<
The current version of the M-Week Planning can be found here.
>
>
The current version of the M-Week Planning can be found here.
 

Run-2 Preparation

Operations Model/Shift Organization Discussion

Line: 22 to 22
 
  1. In the LS1 Weekly Meeting on Jan 27th 2014 (to the systems and system run coordinators),
  2. In the ATLAS Weekly/Open EB on Tue Jan 28th 2014
  3. In the ATLAS Week on Feb 12 2014
Added:
>
>
  1. In the Discussion and Wrap-up Meeting March 18 2014
 
Changed:
<
<
and is described in detail in the EDMS document https://edms.cern.ch/document/1348082/1.
>
>
Following the feedback from the collaboration and the discussion at the wrap up meeting a draft version of the document of the Atlas Operation Model (still in preparation) is available as EDMS document in: https://edms.cern.ch/document/1348082/1. This will be soon presented to the collaboration.
 

Feedback and Input from the Collaboration

Feedback and comments have been requested from the collaboration, as well as from systems and project leaders; in parallel, Run Coordination will actively seek the dialog with sub-detectors and systems; It is planned to wrap up the discussion and arrive at a decision in dedicated workshop on Tue March 18.
Line: 59 to 61
 
Wainer, Bruce, Alex, Anna etc. Trigger Operations and TDAQ System Run Coordinators Shift crew
The two models being debated both require considerable clarification concerning the plan for implementation.Both require effort in order to be implemented so as to evolve to more common methods, tools and automation.This is a requirement if our colleagues are to be trained on all shift aspects as it decreases the spectrum of tools/methods and procedures that need to be learnt. The detector centric model requires less effort, but even in this model the TDAQ project and Trigger activity would like to see more common methods and tools.
An adiabatic evolution should be envisaged, where ATLAS starts with the detector centric model and evolves to the model proposed by Run Coordination (or a possible variant of that model). The rate of change should be based on a plan which includes the effort required (and the proposed responsibilities) for the implementation.
A challenge for the detector centric model is the correct handling of ATLAS wide issues, for example global DQ. Does global DQ include the Trigger DQ? If not, where would the trigger DQ be best monitored? Adding this to the charge of the Run Control Shifter, as currently implied, risks overloading the Run Control Shifter.
There is concern that the potential increase in responsibility born by the Run Control Shifter is beyond what can be reasonably expected for him or her to handle.
Regarding calibration runs between fills, this is a task that, if not already the case, should be automated. The same method and tools, as mentioned, above should be used across all the concerned detector systems. Which member of the shift crew is responsible for the execution of these special runs should be less of an issue, if the optimal common procedures are implemented. However, as mentioned above, the work load on the Run Control shifter during inter-fills has proven to be significant in Run 1 and therefore the responsibility for calibration runs should not fall on the Run Control Shifter. The responsibility for calibration runs best fall elsewhere, most obviously with the detector systems. In this way, it appears that the detector centric model lends itself better to calibration runs.
All shifters should be trained in all duties of the Shift crew regardless of which model is actually adopted.
Shift booking
The emphasis placed on having experienced shifters in the control room is very welcome.
The proposed implementation, as presented, seems to be Run Coordinator centric, i.e. will require significant effort by the ATLAS Run Coordination. The TDAQ project and Trigger activity would like instead to see an evolution of the current method of shift reservation. That is to say that individuals book their own shifts. The tool used to do this should implement the agreed Shift Booking Rules.
Splitting the year into two run periods appears to be too rigid and somewhat poorly motivated. As a minimum evolution, compared to Run 1, the TDAQ project and Trigger activity would like to see the grouping of shifts and would like to propose a model where: one block of shifts at least every three weeks is required, along with mandatory booking of at least of five blocks. Shifts booked by an individual should be for a single type of shift, e.g. Run Control shifter. Splitting the the five blocks over more than type of shift undermines continuity and therefore efficiency.
There is the open issue of the criteria according to which colleagues are required to re-do shifter training.
Roberto Ferrari for the Pavia group We, in Pavia, share several concerns about the proposal for changes in the shift policy. We had some discussions and we would like to provide you with our feedback.

We are concerned with few issues:

a) number of shifts required;
b) the limited number of people allowed to take shifts (the so-called "professional shift crews");
c) the suppression of all sub-detector shifters.

About the first point, we think that setting as a minimum, over 6 months, twice the average over the full run-1 period (according to the statistics shown in the public discussions) is a bit unfair and unjustified. The ATLAS efficiency in data recording provides a good demonstration that it is hardly a real problem. The only rationale for it seems to be the reduction of the number of people to be trained. Finally, to most (or likely all) of us, it looks quite impossible to satisfy the new requirement. We think it could be a much more reasonable compromise, for example, to set the previous average value as the minimum requirement over 6 months (i.e. 10 shifts over 6 months).

About the second point, most of us comes from experiences in which all the physicists were obliged to take control-room shifts. Now you are proposing a scheme in which you want the large majority of the physicists NOT to take shifts, reserved for a bunch of highly trained people. On the contrary, we think it should be much preferable (or even mandatory) that as many physicists as possible, and in particular young students, may have the responsibility of running the experiment. We think this should be a less robust but much more fertile choice.

About last point, we think that setting up the infrastructure (as well as the training) needed for the change is a hard and critical task. You will likely need to train all the shifters, since the sub-detector tasks will be distributed over all of them. Moreover a strong effort for the automatization of such tasks (i.e. calibration runs) will be needed. On the contrary, for the sub-detector shifts, already now quite a lot of people is trained and the tools are in place. If the goal is to reduce to 6 the total number of shifters, have you considered the possibility to simply merge the DQ and SL as well as Trigger and Run Control roles? What do you think about ?
Added:
>
>
  • Atlas-Milestone-Run-Schedule:
    milestones-v4.png
 
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v2.pdf" attr="" comment="M-Week Schedule version 2" date="1392044436" name="MilestoneWeek_Schedule_v2.pdf" path="MilestoneWeek_Schedule_v2.pdf" size="75964" stream="MilestoneWeek_Schedule_v2.pdf" tmpFilename="/usr/tmp/CGItemp28226" user="zimmerst" version="1"
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v3.pdf" attr="" comment="M-Week schedule version 3 (Feb 10 2014)" date="1392044455" name="MilestoneWeek_Schedule_v3.pdf" path="MilestoneWeek_Schedule_v3.pdf" size="76926" stream="MilestoneWeek_Schedule_v3.pdf" tmpFilename="/usr/tmp/CGItemp28185" user="zimmerst" version="1"
Added:
>
>
META FILEATTACHMENT attachment="milestones-v4.png" attr="" comment="Atlas-Milestone-Run-Schedule" date="1399275475" name="milestones-v4.png" path="milestones-v4.png" size="157756" stream="milestones-v4.png" tmpFilename="/usr/tmp/CGItemp26826" user="apolini" version="1"

Revision 142014-04-02 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

2014 Operations and Milestone Weeks

Added:
>
>

Updated Daily Run Plan from the control room here

 

Milestone Week Dates

  • M1 Run/Week: Feb 17 to 21 2014
  • M2 Run/Week: Mar 31 to Apr 4 2014

Revision 132014-03-18 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

2014 Operations and Milestone Weeks

Milestone Week Dates

Line: 56 to 56
 
Stephen Haywood (for the RAL Team) Thoughts on ACR Shifts from the RAL Group
We broadly support the proposal to reduce the numbers of ACR shifts and make the Shift Crew more “professional”. We are concerned that the streamlining of ACR Shifts should be seen in the context of the overall streamlining of OTP activities, namely Class 2 & 3. We are concerned that the whole OTP system has become bloated and created an “arms race”, whereby everyone wants his/her work badged as OTP and no one wants to acknowledge that his/her work could be given lower credit. This all goes to inflate the amount of OTP needed from the Collaboration.
This is going beyond your remit, we guess.
At RAL, we are concerned as to how we as a group will satisfy our OTP obligations. This is because as a national lab, we are expected to spearhead new projects on behalf of the UK, so 2/3 of our effort is dedicated to the Upgrade. (Most of the rest of our effort goes into Operations, with very little available for physic s analysis). Almost all of our team have been on ATLAS for many years and so wish to remain Authors, but find it hard because they are not well-positioned to do Class 2 or 3, while it was easier to do Class 1.
Again this is not your immediate concern and should not be the sort of argument to drive the changes for Class 1: We do not want to inflate Class 1 shifts in order to enable some to fulfil their OTP commitments – this would be to pervert the raison d’etre for OTP. We will have a chance to comment on this when Thorsten undertakes his OTP survey. While shifts can be a burden, precisely because we are removed from the day-to-day operations of ATLAS, many of us find them helpful to keep us connected to the experiment and enable us to feel we are contributing.
We do think shifts serve a role to educate students. We consider it important that if a Student comes to CERN for a year, he/she should be able to engage in the ACR shifts, irrespective of when he/she turns up … may be an issue if the student arrives just after the intake of ACR recruits.
While shifts are valuable to give insight as to how a real detector works (the fact that parts trip, the beam is messy, there can be long delays between fills) and they help the Student feel part of the collaboration, this should not be overstated. There are other ways Students can serve and learn about the experiment.
Suggestion: Ideally, Students should be fully engaged in ACR duties. However, since this will probably be impossible for all Students, a solution might be that Students who cannot do ACR Shifts should be allowed/encouraged to sit a couple of shadow shifts, as observers, not as people trying to qualify.
Suggestion: While it may be impossible for all institutions to have team members undertaking shifts all the time, maybe rotas could be set up to allocate block of shifts to institutions. For example, in Year 1, institutes A, B and C are invited to provide Shifters; Year 2, D, E and F are invited, etc...
Chris Meyer The Tile Calorimeter Team The Tile Calorimeter system strongly supports reducing the number of people shifting in the ATLAS control room during 2015, as well as improving the detector monitoring software. In addition, the new scheme for shift allocation will be necessary for future operations. By requiring a minimum of 21 shifts during the sign-up procedure, and enforcing it when final allocation is performed, a highly experienced team at P1 is guaranteed. Our only concern lies with the currently proposed division of responsibility, which we feel would have difficulty addressing multiple, or unexpected, issues during data taking.
We think that a more detector-oriented desk would provide a faster, more robust response to any issues that may arise during data taking. For example, in the attached plot you can see in blue that around 32/pb of data was lost due to timing in September 2012. This occurred after a stopless removal, when the timing of an entire partition (25% of the sub-detector) was shifted by 25 ns after being restarted. This caused a large impact on the trigger, resulting in data loss.
In this case, a quick investigation was needed by experts familiar with the Tile Calorimeter from the DAQ, DCS, and DQ teams. Because it had never happened before, no amount of automated DQ checks or preparation could have spotted it. It was also important that all three systems were at the same desk, so that the shifter could follow the progression from DCS to DAQ, and finally verify the issue as fixed using DQ information.
A similarly fast response will be crucial in future, unexpected situations like this. In addition, this scheme leaves a separate shifter available to address other problems that may arise with different sub-detector systems in parallel.
We think that with only minor changes to the division of responsibility, which result in a more detector-oriented scheme, the number of shifters can remain at 7 or fewer while still ensuring high-quality results from ATLAS.
Wainer, Bruce, Alex, Anna etc. Trigger Operations and TDAQ System Run Coordinators Shift crew
The two models being debated both require considerable clarification concerning the plan for implementation.Both require effort in order to be implemented so as to evolve to more common methods, tools and automation.This is a requirement if our colleagues are to be trained on all shift aspects as it decreases the spectrum of tools/methods and procedures that need to be learnt. The detector centric model requires less effort, but even in this model the TDAQ project and Trigger activity would like to see more common methods and tools.
An adiabatic evolution should be envisaged, where ATLAS starts with the detector centric model and evolves to the model proposed by Run Coordination (or a possible variant of that model). The rate of change should be based on a plan which includes the effort required (and the proposed responsibilities) for the implementation.
A challenge for the detector centric model is the correct handling of ATLAS wide issues, for example global DQ. Does global DQ include the Trigger DQ? If not, where would the trigger DQ be best monitored? Adding this to the charge of the Run Control Shifter, as currently implied, risks overloading the Run Control Shifter.
There is concern that the potential increase in responsibility born by the Run Control Shifter is beyond what can be reasonably expected for him or her to handle.
Regarding calibration runs between fills, this is a task that, if not already the case, should be automated. The same method and tools, as mentioned, above should be used across all the concerned detector systems. Which member of the shift crew is responsible for the execution of these special runs should be less of an issue, if the optimal common procedures are implemented. However, as mentioned above, the work load on the Run Control shifter during inter-fills has proven to be significant in Run 1 and therefore the responsibility for calibration runs should not fall on the Run Control Shifter. The responsibility for calibration runs best fall elsewhere, most obviously with the detector systems. In this way, it appears that the detector centric model lends itself better to calibration runs.
All shifters should be trained in all duties of the Shift crew regardless of which model is actually adopted.
Shift booking
The emphasis placed on having experienced shifters in the control room is very welcome.
The proposed implementation, as presented, seems to be Run Coordinator centric, i.e. will require significant effort by the ATLAS Run Coordination. The TDAQ project and Trigger activity would like instead to see an evolution of the current method of shift reservation. That is to say that individuals book their own shifts. The tool used to do this should implement the agreed Shift Booking Rules.
Splitting the year into two run periods appears to be too rigid and somewhat poorly motivated. As a minimum evolution, compared to Run 1, the TDAQ project and Trigger activity would like to see the grouping of shifts and would like to propose a model where: one block of shifts at least every three weeks is required, along with mandatory booking of at least of five blocks. Shifts booked by an individual should be for a single type of shift, e.g. Run Control shifter. Splitting the the five blocks over more than type of shift undermines continuity and therefore efficiency.
There is the open issue of the criteria according to which colleagues are required to re-do shifter training.
Added:
>
>
Roberto Ferrari for the Pavia group We, in Pavia, share several concerns about the proposal for changes in the shift policy. We had some discussions and we would like to provide you with our feedback.

We are concerned with few issues:

a) number of shifts required;
b) the limited number of people allowed to take shifts (the so-called "professional shift crews");
c) the suppression of all sub-detector shifters.

About the first point, we think that setting as a minimum, over 6 months, twice the average over the full run-1 period (according to the statistics shown in the public discussions) is a bit unfair and unjustified. The ATLAS efficiency in data recording provides a good demonstration that it is hardly a real problem. The only rationale for it seems to be the reduction of the number of people to be trained. Finally, to most (or likely all) of us, it looks quite impossible to satisfy the new requirement. We think it could be a much more reasonable compromise, for example, to set the previous average value as the minimum requirement over 6 months (i.e. 10 shifts over 6 months).

About the second point, most of us comes from experiences in which all the physicists were obliged to take control-room shifts. Now you are proposing a scheme in which you want the large majority of the physicists NOT to take shifts, reserved for a bunch of highly trained people. On the contrary, we think it should be much preferable (or even mandatory) that as many physicists as possible, and in particular young students, may have the responsibility of running the experiment. We think this should be a less robust but much more fertile choice.

About last point, we think that setting up the infrastructure (as well as the training) needed for the change is a hard and critical task. You will likely need to train all the shifters, since the sub-detector tasks will be distributed over all of them. Moreover a strong effort for the automatization of such tasks (i.e. calibration runs) will be needed. On the contrary, for the sub-detector shifts, already now quite a lot of people is trained and the tools are in place. If the goal is to reduce to 6 the total number of shifters, have you considered the possibility to simply merge the DQ and SL as well as Trigger and Run Control roles? What do you think about ?
 
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v2.pdf" attr="" comment="M-Week Schedule version 2" date="1392044436" name="MilestoneWeek_Schedule_v2.pdf" path="MilestoneWeek_Schedule_v2.pdf" size="75964" stream="MilestoneWeek_Schedule_v2.pdf" tmpFilename="/usr/tmp/CGItemp28226" user="zimmerst" version="1"
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v3.pdf" attr="" comment="M-Week schedule version 3 (Feb 10 2014)" date="1392044455" name="MilestoneWeek_Schedule_v3.pdf" path="MilestoneWeek_Schedule_v3.pdf" size="76926" stream="MilestoneWeek_Schedule_v3.pdf" tmpFilename="/usr/tmp/CGItemp28185" user="zimmerst" version="1"

Revision 122014-03-18 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

2014 Operations and Milestone Weeks

Milestone Week Dates

Line: 55 to 55
 
Daniel Froidevaux * Here is some feedback on the proposed new scheme for shifts for run-2 as presented to us over the past weeks. I give you my feedback with a rather specific dual viewpoint:
a) that of someone having done numerous TRT, DQ, RunControl and Shift Leader shifts over the whole period of run-1. I enjoyed these shifts and would very much like to continue taking shifts since this is to me an integral part of what we should all do as experimentalists.
b) that of someone responsible (in great part) for an important moment in their careers of many young physicists in ATLAS who are either fellows or staff in the CERN team. It is important for all of them to be able to serve in some role at point 1. This does not necessarily have to be for main shifts, it is and can be in many cases as expert shifters, e.g. for trigger. Nevertheless, the possibility to serve as main shifters should not be excluded.
And here is my feedback, which is mostly about the shift allocation scheme and the minimum number of shifts:
1) When based at CERN and especially when very busy during the week with many meetings etc, most people would benefit from a less rigid scheme than the one proposed, both in terms of the minimum number of shifts which is far too high for someone like me for example over a period of five months. I have filled in in the past on numerous occasions holes in the schedule for night shifts, week-end shifts etc which are the ones which are easiest for me to do, but I believe strongly that the system should allow (at least for CERN-based people) for doing the 20 shifts over a longer period. Otherwise, you will just kill the participation, certainly from my side but also from others I am sure. And this would be very sad. You can see easily for yourselves how many shifts people from the CERN team have done over 2011 and 2012, I cannot collect these statistics myself.
2) The shift allocation scheme should itself be very flexible even if not based on individual bookings anymore. I can really only take my own example as one among many and nothing too special to illustrate this. When signing in for RC or Shift Leader shifts during next year, I would volunteer for night shifts only, preferably not more than one or two in a row, but apart from specific weeks when I am away, this could be regular over the whole year more or less. But it might not fit with a required frequency of 20 shifts over five months, this is just too rigid. I would personally prefer to do 20 shifts over 10 months although I could agree of course to fit better into the periods you might propose.
3) For the young people in the CERN team, it would be nice to see at the same time the possibilities and requirements for main shifts at P1 and also for expert shifts as they will be revised for run-2. I have very little understanding of this at the moment, and I would very much like to see a global picture of how this would work to present it also to our fellows and staff to encourage them to participate (many already do and are indeed expert shifters, but there are also many who do nothing at point-1 or related to point-1 activities).
Stephen Haywood (for the RAL Team) Thoughts on ACR Shifts from the RAL Group
We broadly support the proposal to reduce the numbers of ACR shifts and make the Shift Crew more “professional”. We are concerned that the streamlining of ACR Shifts should be seen in the context of the overall streamlining of OTP activities, namely Class 2 & 3. We are concerned that the whole OTP system has become bloated and created an “arms race”, whereby everyone wants his/her work badged as OTP and no one wants to acknowledge that his/her work could be given lower credit. This all goes to inflate the amount of OTP needed from the Collaboration.
This is going beyond your remit, we guess.
At RAL, we are concerned as to how we as a group will satisfy our OTP obligations. This is because as a national lab, we are expected to spearhead new projects on behalf of the UK, so 2/3 of our effort is dedicated to the Upgrade. (Most of the rest of our effort goes into Operations, with very little available for physic s analysis). Almost all of our team have been on ATLAS for many years and so wish to remain Authors, but find it hard because they are not well-positioned to do Class 2 or 3, while it was easier to do Class 1.
Again this is not your immediate concern and should not be the sort of argument to drive the changes for Class 1: We do not want to inflate Class 1 shifts in order to enable some to fulfil their OTP commitments – this would be to pervert the raison d’etre for OTP. We will have a chance to comment on this when Thorsten undertakes his OTP survey. While shifts can be a burden, precisely because we are removed from the day-to-day operations of ATLAS, many of us find them helpful to keep us connected to the experiment and enable us to feel we are contributing.
We do think shifts serve a role to educate students. We consider it important that if a Student comes to CERN for a year, he/she should be able to engage in the ACR shifts, irrespective of when he/she turns up … may be an issue if the student arrives just after the intake of ACR recruits.
While shifts are valuable to give insight as to how a real detector works (the fact that parts trip, the beam is messy, there can be long delays between fills) and they help the Student feel part of the collaboration, this should not be overstated. There are other ways Students can serve and learn about the experiment.
Suggestion: Ideally, Students should be fully engaged in ACR duties. However, since this will probably be impossible for all Students, a solution might be that Students who cannot do ACR Shifts should be allowed/encouraged to sit a couple of shadow shifts, as observers, not as people trying to qualify.
Suggestion: While it may be impossible for all institutions to have team members undertaking shifts all the time, maybe rotas could be set up to allocate block of shifts to institutions. For example, in Year 1, institutes A, B and C are invited to provide Shifters; Year 2, D, E and F are invited, etc...
Chris Meyer The Tile Calorimeter Team The Tile Calorimeter system strongly supports reducing the number of people shifting in the ATLAS control room during 2015, as well as improving the detector monitoring software. In addition, the new scheme for shift allocation will be necessary for future operations. By requiring a minimum of 21 shifts during the sign-up procedure, and enforcing it when final allocation is performed, a highly experienced team at P1 is guaranteed. Our only concern lies with the currently proposed division of responsibility, which we feel would have difficulty addressing multiple, or unexpected, issues during data taking.
We think that a more detector-oriented desk would provide a faster, more robust response to any issues that may arise during data taking. For example, in the attached plot you can see in blue that around 32/pb of data was lost due to timing in September 2012. This occurred after a stopless removal, when the timing of an entire partition (25% of the sub-detector) was shifted by 25 ns after being restarted. This caused a large impact on the trigger, resulting in data loss.
In this case, a quick investigation was needed by experts familiar with the Tile Calorimeter from the DAQ, DCS, and DQ teams. Because it had never happened before, no amount of automated DQ checks or preparation could have spotted it. It was also important that all three systems were at the same desk, so that the shifter could follow the progression from DCS to DAQ, and finally verify the issue as fixed using DQ information.
A similarly fast response will be crucial in future, unexpected situations like this. In addition, this scheme leaves a separate shifter available to address other problems that may arise with different sub-detector systems in parallel.
We think that with only minor changes to the division of responsibility, which result in a more detector-oriented scheme, the number of shifters can remain at 7 or fewer while still ensuring high-quality results from ATLAS.
Changed:
<
<
-- Main.apolini - 2014-02-03
>
>
Wainer, Bruce, Alex, Anna etc. Trigger Operations and TDAQ System Run Coordinators Shift crew
The two models being debated both require considerable clarification concerning the plan for implementation.Both require effort in order to be implemented so as to evolve to more common methods, tools and automation.This is a requirement if our colleagues are to be trained on all shift aspects as it decreases the spectrum of tools/methods and procedures that need to be learnt. The detector centric model requires less effort, but even in this model the TDAQ project and Trigger activity would like to see more common methods and tools.
An adiabatic evolution should be envisaged, where ATLAS starts with the detector centric model and evolves to the model proposed by Run Coordination (or a possible variant of that model). The rate of change should be based on a plan which includes the effort required (and the proposed responsibilities) for the implementation.
A challenge for the detector centric model is the correct handling of ATLAS wide issues, for example global DQ. Does global DQ include the Trigger DQ? If not, where would the trigger DQ be best monitored? Adding this to the charge of the Run Control Shifter, as currently implied, risks overloading the Run Control Shifter.
There is concern that the potential increase in responsibility born by the Run Control Shifter is beyond what can be reasonably expected for him or her to handle.
Regarding calibration runs between fills, this is a task that, if not already the case, should be automated. The same method and tools, as mentioned, above should be used across all the concerned detector systems. Which member of the shift crew is responsible for the execution of these special runs should be less of an issue, if the optimal common procedures are implemented. However, as mentioned above, the work load on the Run Control shifter during inter-fills has proven to be significant in Run 1 and therefore the responsibility for calibration runs should not fall on the Run Control Shifter. The responsibility for calibration runs best fall elsewhere, most obviously with the detector systems. In this way, it appears that the detector centric model lends itself better to calibration runs.
All shifters should be trained in all duties of the Shift crew regardless of which model is actually adopted.
Shift booking
The emphasis placed on having experienced shifters in the control room is very welcome.
The proposed implementation, as presented, seems to be Run Coordinator centric, i.e. will require significant effort by the ATLAS Run Coordination. The TDAQ project and Trigger activity would like instead to see an evolution of the current method of shift reservation. That is to say that individuals book their own shifts. The tool used to do this should implement the agreed Shift Booking Rules.
Splitting the year into two run periods appears to be too rigid and somewhat poorly motivated. As a minimum evolution, compared to Run 1, the TDAQ project and Trigger activity would like to see the grouping of shifts and would like to propose a model where: one block of shifts at least every three weeks is required, along with mandatory booking of at least of five blocks. Shifts booked by an individual should be for a single type of shift, e.g. Run Control shifter. Splitting the the five blocks over more than type of shift undermines continuity and therefore efficiency.
There is the open issue of the criteria according to which colleagues are required to re-do shifter training.
 
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v2.pdf" attr="" comment="M-Week Schedule version 2" date="1392044436" name="MilestoneWeek_Schedule_v2.pdf" path="MilestoneWeek_Schedule_v2.pdf" size="75964" stream="MilestoneWeek_Schedule_v2.pdf" tmpFilename="/usr/tmp/CGItemp28226" user="zimmerst" version="1"
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v3.pdf" attr="" comment="M-Week schedule version 3 (Feb 10 2014)" date="1392044455" name="MilestoneWeek_Schedule_v3.pdf" path="MilestoneWeek_Schedule_v3.pdf" size="76926" stream="MilestoneWeek_Schedule_v3.pdf" tmpFilename="/usr/tmp/CGItemp28185" user="zimmerst" version="1"

Revision 112014-03-14 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

2014 Operations and Milestone Weeks

Milestone Week Dates

Line: 8 to 8
 
  • M4 Run/Week: Jul 7 to Jul 11 2014
  • M5 Run/Week: Sep 8 to Sep 12 2014
  • M6 Run/Week: Oct 13 to Oct 17 2014
Changed:
<
<
  • Extended Cosmics Data Taking: beginning to mid Dec 2014, exact dates to be defined
>
>
  • Extended Cosmics Data Taking: (UPDATED) November 24th - December 7th (cooling/cryo yearly maintenance afterwards)
 

Milestone Week Sub-Detector Integration Schedule

Revision 102014-03-07 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

2014 Operations and Milestone Weeks

Milestone Week Dates

Line: 53 to 53
 
Jessica Leveque DQ feedback from subsystems 1) Number of shifts
- 5 months * 30 days * 3 shifts per day * 6 desks = 2700 shifts
- if 21 shifts minimum required: 6.5% (assuming 2000 ATLAS active members willing to take shifts)
Many more than 6% of newcomers per year: how do we ensure that new student and postdoc get in touch with the detector environment ? By restricting the number of people accessing shifts, we also reduce the possibility for new people to approach the expert on-call tasks (critical point, see number 3) below)
2) Shifts organization
- From the shifter point of view: asking people to block 8 weeks, several months in advanced, and force them to be randomly assigned shifts within this 8 weeks is unrealistic. People with families, teaching duties, limited stays at CERN (often 3 to 6 months for students) or convenership responsabilities in the collaboration can not do that. The "OR" of these 4 points covers a very large fraction of the ATLAS physicists.
- From the run coordination point of view: shift allocation instead of shift booking is a significant overload of work. Past experience in offline DQ showed that designing the shifter planning by hand several months in advance while taking into account the institutes quotas of the past shift periods (trying to provide a fair sharing of the available shifts within institutes), taking into account the shifters personal constraints,the trainings and the shadow shifts to allocate the shift blocks at the right time, and last but not least dealing with the numerous last minute cancellations and shifters swaps, is really a painful and time-consuming job. Something needs to be changed in OTP to help with this task, by either blocking people when the institutes reached their allocated quota, or adding more info about their training to block the shift allocation automatically if the training is not completed. Or maybe we need a "global shift manager" provided by ATLAS to take care of this task for all the desks altogether.
3) Detector experts on-call
- Less shifters in ACR probably implies a much stronger team of 24/7 expert on-call for the sub-systems.
- Experience from the past run shows that it is becoming harder and harder to recruit people for the expert and on-call tasks, as they require quite a long training (a few months at least before being operational), and to be fully based at CERN.
- One problem comes from the institutes, whose finances are being cut pretty much everywhere and are becoming more reluctant to send people at CERN for long periods of time.
- The major problem is that the most indicated people for this type of tasks are postdocs, who do not want to be stuck for a full year or more in technical tasks simply because it is not valued at all for their careers, and they need to do physics analysis. This is a deeper problem, already discussed elsewhere: if being an expert on-call is not considered as critical task and not valued enough by the collaboration, we will not find the people to do it.
- Back to the point of the restricted number of shifts: giving less people the opportunity to work in the control room reduces the pool of new people who could possibly be motivated to take responsabilities in the sub-systems.
Jimmy Proudfoot Tile Calorimeter My comments are based on the written document & I have similar concerns to many of those already stated on the twiki. While I agree with the goal of reducing the operations effort, I think that as proposed (as best I can understand it since the document doesn’t have an implementation plan) this proposal simply moves the effort to the experts on call.
The proposed shift allocation is too strict and needlessly limits the opportunities for graduate students and postdocs to participate in data-taking – I propose dropping the requirement to around 12 days which has been the norm in other experiments I have worked on. I have taken detector data-taking shifts in many different scenarios. My experience is that to have a “long” block of shifts in a short period of time is more effective than a series of short blocks of shift scattered through an extended period since the shifters are up-to-date on current issues/problem. Obviously with the CERN rules there needs to be time in between blocks of three days but it is possible to block out around 12 days of shifts within 3 weeks with appropriate blocks of 3 and 4 day elements.
The proposed plan places a huge burden on the experts on call; quoting the document “No low-level sub-detector actions are expected to be taken by the shifter on a regular basis “. I think this is unmanageable and I suggest that an intermediate level of expertise as placed in the hands of a detector expert in the ACR reduces the total number of pagers that will be required. One way to decide if this is indeed workable is to consult with the systems to find out how they would provide these experts whose knowledge ranges from the luminosity measurement, to readout errors and perhaps failures of stopless recovery. If the number is modest, say 15, then the plan will work, but if it gets to be ~100 then it clearly won’t. The hardest ones to fill are the ones requiring considerable expertise but which are very rarely needed – in this case I think we need to have a mechanism whereby the expert can be anywhere in the world and in contact with a suitably knowledgeable individual in the ACR.
One of the important tasks is taking calibrations and insuring that they are correct in the proposal this requires an Expert System, and there is enough work that the responsibility is shared around various members of the shift team. Again having system experts (Calorimeter, Trigger, Tracking System, Muon System) makes more sense.
I believe that in whatever scheme we approach the shift leader could be able to perform the DQ task since it will only entail reviewing some color coded status flags.
I am dismayed at the lack of any real effort to engage collaborators from outside CERN to be part of the overall scheme, and I hope that the final plan includes such opportunities more broadly around the collaboration. We were very successful in monitoring the Tile LVPS system from outside CERN even when modules were tripping once per minute (we developed a web-based monitoring system which intercepted and parsed the error log entries from the Oracle database). Any low rate “event” involving stopless recovery is a candidate for this type of web-based remote monitoring – and we hope that most of these events are low rate. We are running a modified version of this during LS1. I f you are interested in more details, please contact us – we think that this methodology should be applicable to analogous monitoring in other systems.
Daniel Froidevaux * Here is some feedback on the proposed new scheme for shifts for run-2 as presented to us over the past weeks. I give you my feedback with a rather specific dual viewpoint:
a) that of someone having done numerous TRT, DQ, RunControl and Shift Leader shifts over the whole period of run-1. I enjoyed these shifts and would very much like to continue taking shifts since this is to me an integral part of what we should all do as experimentalists.
b) that of someone responsible (in great part) for an important moment in their careers of many young physicists in ATLAS who are either fellows or staff in the CERN team. It is important for all of them to be able to serve in some role at point 1. This does not necessarily have to be for main shifts, it is and can be in many cases as expert shifters, e.g. for trigger. Nevertheless, the possibility to serve as main shifters should not be excluded.
And here is my feedback, which is mostly about the shift allocation scheme and the minimum number of shifts:
1) When based at CERN and especially when very busy during the week with many meetings etc, most people would benefit from a less rigid scheme than the one proposed, both in terms of the minimum number of shifts which is far too high for someone like me for example over a period of five months. I have filled in in the past on numerous occasions holes in the schedule for night shifts, week-end shifts etc which are the ones which are easiest for me to do, but I believe strongly that the system should allow (at least for CERN-based people) for doing the 20 shifts over a longer period. Otherwise, you will just kill the participation, certainly from my side but also from others I am sure. And this would be very sad. You can see easily for yourselves how many shifts people from the CERN team have done over 2011 and 2012, I cannot collect these statistics myself.
2) The shift allocation scheme should itself be very flexible even if not based on individual bookings anymore. I can really only take my own example as one among many and nothing too special to illustrate this. When signing in for RC or Shift Leader shifts during next year, I would volunteer for night shifts only, preferably not more than one or two in a row, but apart from specific weeks when I am away, this could be regular over the whole year more or less. But it might not fit with a required frequency of 20 shifts over five months, this is just too rigid. I would personally prefer to do 20 shifts over 10 months although I could agree of course to fit better into the periods you might propose.
3) For the young people in the CERN team, it would be nice to see at the same time the possibilities and requirements for main shifts at P1 and also for expert shifts as they will be revised for run-2. I have very little understanding of this at the moment, and I would very much like to see a global picture of how this would work to present it also to our fellows and staff to encourage them to participate (many already do and are indeed expert shifters, but there are also many who do nothing at point-1 or related to point-1 activities).
Added:
>
>
Stephen Haywood (for the RAL Team) Thoughts on ACR Shifts from the RAL Group
We broadly support the proposal to reduce the numbers of ACR shifts and make the Shift Crew more “professional”. We are concerned that the streamlining of ACR Shifts should be seen in the context of the overall streamlining of OTP activities, namely Class 2 & 3. We are concerned that the whole OTP system has become bloated and created an “arms race”, whereby everyone wants his/her work badged as OTP and no one wants to acknowledge that his/her work could be given lower credit. This all goes to inflate the amount of OTP needed from the Collaboration.
This is going beyond your remit, we guess.
At RAL, we are concerned as to how we as a group will satisfy our OTP obligations. This is because as a national lab, we are expected to spearhead new projects on behalf of the UK, so 2/3 of our effort is dedicated to the Upgrade. (Most of the rest of our effort goes into Operations, with very little available for physic s analysis). Almost all of our team have been on ATLAS for many years and so wish to remain Authors, but find it hard because they are not well-positioned to do Class 2 or 3, while it was easier to do Class 1.
Again this is not your immediate concern and should not be the sort of argument to drive the changes for Class 1: We do not want to inflate Class 1 shifts in order to enable some to fulfil their OTP commitments – this would be to pervert the raison d’etre for OTP. We will have a chance to comment on this when Thorsten undertakes his OTP survey. While shifts can be a burden, precisely because we are removed from the day-to-day operations of ATLAS, many of us find them helpful to keep us connected to the experiment and enable us to feel we are contributing.
We do think shifts serve a role to educate students. We consider it important that if a Student comes to CERN for a year, he/she should be able to engage in the ACR shifts, irrespective of when he/she turns up … may be an issue if the student arrives just after the intake of ACR recruits.
While shifts are valuable to give insight as to how a real detector works (the fact that parts trip, the beam is messy, there can be long delays between fills) and they help the Student feel part of the collaboration, this should not be overstated. There are other ways Students can serve and learn about the experiment.
Suggestion: Ideally, Students should be fully engaged in ACR duties. However, since this will probably be impossible for all Students, a solution might be that Students who cannot do ACR Shifts should be allowed/encouraged to sit a couple of shadow shifts, as observers, not as people trying to qualify.
Suggestion: While it may be impossible for all institutions to have team members undertaking shifts all the time, maybe rotas could be set up to allocate block of shifts to institutions. For example, in Year 1, institutes A, B and C are invited to provide Shifters; Year 2, D, E and F are invited, etc...
Chris Meyer The Tile Calorimeter Team The Tile Calorimeter system strongly supports reducing the number of people shifting in the ATLAS control room during 2015, as well as improving the detector monitoring software. In addition, the new scheme for shift allocation will be necessary for future operations. By requiring a minimum of 21 shifts during the sign-up procedure, and enforcing it when final allocation is performed, a highly experienced team at P1 is guaranteed. Our only concern lies with the currently proposed division of responsibility, which we feel would have difficulty addressing multiple, or unexpected, issues during data taking.
We think that a more detector-oriented desk would provide a faster, more robust response to any issues that may arise during data taking. For example, in the attached plot you can see in blue that around 32/pb of data was lost due to timing in September 2012. This occurred after a stopless removal, when the timing of an entire partition (25% of the sub-detector) was shifted by 25 ns after being restarted. This caused a large impact on the trigger, resulting in data loss.
In this case, a quick investigation was needed by experts familiar with the Tile Calorimeter from the DAQ, DCS, and DQ teams. Because it had never happened before, no amount of automated DQ checks or preparation could have spotted it. It was also important that all three systems were at the same desk, so that the shifter could follow the progression from DCS to DAQ, and finally verify the issue as fixed using DQ information.
A similarly fast response will be crucial in future, unexpected situations like this. In addition, this scheme leaves a separate shifter available to address other problems that may arise with different sub-detector systems in parallel.
We think that with only minor changes to the division of responsibility, which result in a more detector-oriented scheme, the number of shifters can remain at 7 or fewer while still ensuring high-quality results from ATLAS.
  -- Main.apolini - 2014-02-03

Revision 92014-03-03 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

2014 Operations and Milestone Weeks

Milestone Week Dates

Line: 51 to 51
 
* * I do have serious concerns with the shift allocation scheme, that is too strict and people should have the opportunity to book their shifts themselves, also the minimum number of shifts is too strict and should rather be seen as a guideline with allowed variance, the distributions for run1 were not that bad to justify that rigid scheme.
Nicolas Berger * Two comments on the new model:
21 shifts/person minimum :
According to your own computation, this would mean that only ~200 people could take part in shifts in a given year, which is probably even less than number of new students coming in each year (1000 students in ATLAS / ~4 years). This would mean that some students would not be able to take even 1 block of shift during their studies, which I find regrettable.
This would also mean that the tasks open to non-students would only be "expert" tasks, which are few in number and require a large time-commitment. This would lead to a de facto split between a small pool of experts, and the bulk of the collaboration which would be totally disconnected from detector operations.
I realize that in a sense this is the whole point of the change -- to concentrate the work in the hands of fewer experts to improve efficiency. However this should be balanced against the risk that data-taking becomes a kind of "black box" for most of the collaboration. In my view the current requirements seem too skewed in the first direction.
Switch to "allocation" model :
I don't see the reason to require people to free up 8 full weeks of their schedule in a 6-month period in order to be allowed to take shifts. This will lead to inconvenient bookings, reschedulings, etc. which will just waste everybody's time.
I see there has been an effort to reintroduce some flexibility a posteriori (1 day per week exception, etc.), but this can by definition only help in some particular situations. I think that keeping a signup-based system would be both more convenient for aspiring shifters, and easier to manage for you.
Jessica Leveque DQ feedback from subsystems 1) Number of shifts
- 5 months * 30 days * 3 shifts per day * 6 desks = 2700 shifts
- if 21 shifts minimum required: 6.5% (assuming 2000 ATLAS active members willing to take shifts)
Many more than 6% of newcomers per year: how do we ensure that new student and postdoc get in touch with the detector environment ? By restricting the number of people accessing shifts, we also reduce the possibility for new people to approach the expert on-call tasks (critical point, see number 3) below)
2) Shifts organization
- From the shifter point of view: asking people to block 8 weeks, several months in advanced, and force them to be randomly assigned shifts within this 8 weeks is unrealistic. People with families, teaching duties, limited stays at CERN (often 3 to 6 months for students) or convenership responsabilities in the collaboration can not do that. The "OR" of these 4 points covers a very large fraction of the ATLAS physicists.
- From the run coordination point of view: shift allocation instead of shift booking is a significant overload of work. Past experience in offline DQ showed that designing the shifter planning by hand several months in advance while taking into account the institutes quotas of the past shift periods (trying to provide a fair sharing of the available shifts within institutes), taking into account the shifters personal constraints,the trainings and the shadow shifts to allocate the shift blocks at the right time, and last but not least dealing with the numerous last minute cancellations and shifters swaps, is really a painful and time-consuming job. Something needs to be changed in OTP to help with this task, by either blocking people when the institutes reached their allocated quota, or adding more info about their training to block the shift allocation automatically if the training is not completed. Or maybe we need a "global shift manager" provided by ATLAS to take care of this task for all the desks altogether.
3) Detector experts on-call
- Less shifters in ACR probably implies a much stronger team of 24/7 expert on-call for the sub-systems.
- Experience from the past run shows that it is becoming harder and harder to recruit people for the expert and on-call tasks, as they require quite a long training (a few months at least before being operational), and to be fully based at CERN.
- One problem comes from the institutes, whose finances are being cut pretty much everywhere and are becoming more reluctant to send people at CERN for long periods of time.
- The major problem is that the most indicated people for this type of tasks are postdocs, who do not want to be stuck for a full year or more in technical tasks simply because it is not valued at all for their careers, and they need to do physics analysis. This is a deeper problem, already discussed elsewhere: if being an expert on-call is not considered as critical task and not valued enough by the collaboration, we will not find the people to do it.
- Back to the point of the restricted number of shifts: giving less people the opportunity to work in the control room reduces the pool of new people who could possibly be motivated to take responsabilities in the sub-systems.
Changed:
<
<
>
>
Jimmy Proudfoot Tile Calorimeter My comments are based on the written document & I have similar concerns to many of those already stated on the twiki. While I agree with the goal of reducing the operations effort, I think that as proposed (as best I can understand it since the document doesn’t have an implementation plan) this proposal simply moves the effort to the experts on call.
The proposed shift allocation is too strict and needlessly limits the opportunities for graduate students and postdocs to participate in data-taking – I propose dropping the requirement to around 12 days which has been the norm in other experiments I have worked on. I have taken detector data-taking shifts in many different scenarios. My experience is that to have a “long” block of shifts in a short period of time is more effective than a series of short blocks of shift scattered through an extended period since the shifters are up-to-date on current issues/problem. Obviously with the CERN rules there needs to be time in between blocks of three days but it is possible to block out around 12 days of shifts within 3 weeks with appropriate blocks of 3 and 4 day elements.
The proposed plan places a huge burden on the experts on call; quoting the document “No low-level sub-detector actions are expected to be taken by the shifter on a regular basis “. I think this is unmanageable and I suggest that an intermediate level of expertise as placed in the hands of a detector expert in the ACR reduces the total number of pagers that will be required. One way to decide if this is indeed workable is to consult with the systems to find out how they would provide these experts whose knowledge ranges from the luminosity measurement, to readout errors and perhaps failures of stopless recovery. If the number is modest, say 15, then the plan will work, but if it gets to be ~100 then it clearly won’t. The hardest ones to fill are the ones requiring considerable expertise but which are very rarely needed – in this case I think we need to have a mechanism whereby the expert can be anywhere in the world and in contact with a suitably knowledgeable individual in the ACR.
One of the important tasks is taking calibrations and insuring that they are correct in the proposal this requires an Expert System, and there is enough work that the responsibility is shared around various members of the shift team. Again having system experts (Calorimeter, Trigger, Tracking System, Muon System) makes more sense.
I believe that in whatever scheme we approach the shift leader could be able to perform the DQ task since it will only entail reviewing some color coded status flags.
I am dismayed at the lack of any real effort to engage collaborators from outside CERN to be part of the overall scheme, and I hope that the final plan includes such opportunities more broadly around the collaboration. We were very successful in monitoring the Tile LVPS system from outside CERN even when modules were tripping once per minute (we developed a web-based monitoring system which intercepted and parsed the error log entries from the Oracle database). Any low rate “event” involving stopless recovery is a candidate for this type of web-based remote monitoring – and we hope that most of these events are low rate. We are running a modified version of this during LS1. I f you are interested in more details, please contact us – we think that this methodology should be applicable to analogous monitoring in other systems.
Daniel Froidevaux * Here is some feedback on the proposed new scheme for shifts for run-2 as presented to us over the past weeks. I give you my feedback with a rather specific dual viewpoint:
a) that of someone having done numerous TRT, DQ, RunControl and Shift Leader shifts over the whole period of run-1. I enjoyed these shifts and would very much like to continue taking shifts since this is to me an integral part of what we should all do as experimentalists.
b) that of someone responsible (in great part) for an important moment in their careers of many young physicists in ATLAS who are either fellows or staff in the CERN team. It is important for all of them to be able to serve in some role at point 1. This does not necessarily have to be for main shifts, it is and can be in many cases as expert shifters, e.g. for trigger. Nevertheless, the possibility to serve as main shifters should not be excluded.
And here is my feedback, which is mostly about the shift allocation scheme and the minimum number of shifts:
1) When based at CERN and especially when very busy during the week with many meetings etc, most people would benefit from a less rigid scheme than the one proposed, both in terms of the minimum number of shifts which is far too high for someone like me for example over a period of five months. I have filled in in the past on numerous occasions holes in the schedule for night shifts, week-end shifts etc which are the ones which are easiest for me to do, but I believe strongly that the system should allow (at least for CERN-based people) for doing the 20 shifts over a longer period. Otherwise, you will just kill the participation, certainly from my side but also from others I am sure. And this would be very sad. You can see easily for yourselves how many shifts people from the CERN team have done over 2011 and 2012, I cannot collect these statistics myself.
2) The shift allocation scheme should itself be very flexible even if not based on individual bookings anymore. I can really only take my own example as one among many and nothing too special to illustrate this. When signing in for RC or Shift Leader shifts during next year, I would volunteer for night shifts only, preferably not more than one or two in a row, but apart from specific weeks when I am away, this could be regular over the whole year more or less. But it might not fit with a required frequency of 20 shifts over five months, this is just too rigid. I would personally prefer to do 20 shifts over 10 months although I could agree of course to fit better into the periods you might propose.
3) For the young people in the CERN team, it would be nice to see at the same time the possibilities and requirements for main shifts at P1 and also for expert shifts as they will be revised for run-2. I have very little understanding of this at the moment, and I would very much like to see a global picture of how this would work to present it also to our fellows and staff to encourage them to participate (many already do and are indeed expert shifters, but there are also many who do nothing at point-1 or related to point-1 activities).
  -- Main.apolini - 2014-02-03

Revision 82014-02-17 - zimmerst

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

2014 Operations and Milestone Weeks

Milestone Week Dates

Line: 48 to 48
 
Name System, experience Comment
Norman Gee * Comments from the perspective of someone doing shifts but not CERN-resident
The Central Shift Call needs to be early enough that flights can be booked for the training at reasonable prices, and also that CERN Hostel room is available;
Collaborators outside CERN often have institute responsibilities, e.g. teaching, or on the other hand may already have to travel to CERN for detector meetings. There was supposed to be some priority in the shift booking system for non-CERN residents to allow for this, but in practise I found that, e.g., the weekend trigger shifts were normally filled within around 10 minutes of opening, and at least half were taken by people I knew were CERN-resident. It would be excellent if your work somehow also took this into account. I’m not clear how this works with the “8 weeks total” in your foil 9.
Tetiana Hryn'Ova * Instead of 21 shifts minimum require 11 shifts minimum with 21 recommended (this will be more inline with our Run 1 numbers). Instead of allocation booking (seems a huge time-waste for run coordinators) keep self-booking with people wanting to do more that 21 shifts having opportunity to book earlier (prebook) & assure training is booked at the same time as shifts
Changed:
<
<
Hasko Stenzel * I do have serious concerns with the shift allocation scheme, that is too strict and people should have the opportunity to book their shifts themselves, also the minimum number of shifts is too strict and should rather be seen as a guideline with allowed variance, the distributions for run1 were not that bad to justify that rigid scheme.
>
>
* * I do have serious concerns with the shift allocation scheme, that is too strict and people should have the opportunity to book their shifts themselves, also the minimum number of shifts is too strict and should rather be seen as a guideline with allowed variance, the distributions for run1 were not that bad to justify that rigid scheme.
 
Nicolas Berger * Two comments on the new model:
21 shifts/person minimum :
According to your own computation, this would mean that only ~200 people could take part in shifts in a given year, which is probably even less than number of new students coming in each year (1000 students in ATLAS / ~4 years). This would mean that some students would not be able to take even 1 block of shift during their studies, which I find regrettable.
This would also mean that the tasks open to non-students would only be "expert" tasks, which are few in number and require a large time-commitment. This would lead to a de facto split between a small pool of experts, and the bulk of the collaboration which would be totally disconnected from detector operations.
I realize that in a sense this is the whole point of the change -- to concentrate the work in the hands of fewer experts to improve efficiency. However this should be balanced against the risk that data-taking becomes a kind of "black box" for most of the collaboration. In my view the current requirements seem too skewed in the first direction.
Switch to "allocation" model :
I don't see the reason to require people to free up 8 full weeks of their schedule in a 6-month period in order to be allowed to take shifts. This will lead to inconvenient bookings, reschedulings, etc. which will just waste everybody's time.
I see there has been an effort to reintroduce some flexibility a posteriori (1 day per week exception, etc.), but this can by definition only help in some particular situations. I think that keeping a signup-based system would be both more convenient for aspiring shifters, and easier to manage for you.
Jessica Leveque DQ feedback from subsystems 1) Number of shifts
- 5 months * 30 days * 3 shifts per day * 6 desks = 2700 shifts
- if 21 shifts minimum required: 6.5% (assuming 2000 ATLAS active members willing to take shifts)
Many more than 6% of newcomers per year: how do we ensure that new student and postdoc get in touch with the detector environment ? By restricting the number of people accessing shifts, we also reduce the possibility for new people to approach the expert on-call tasks (critical point, see number 3) below)
2) Shifts organization
- From the shifter point of view: asking people to block 8 weeks, several months in advanced, and force them to be randomly assigned shifts within this 8 weeks is unrealistic. People with families, teaching duties, limited stays at CERN (often 3 to 6 months for students) or convenership responsabilities in the collaboration can not do that. The "OR" of these 4 points covers a very large fraction of the ATLAS physicists.
- From the run coordination point of view: shift allocation instead of shift booking is a significant overload of work. Past experience in offline DQ showed that designing the shifter planning by hand several months in advance while taking into account the institutes quotas of the past shift periods (trying to provide a fair sharing of the available shifts within institutes), taking into account the shifters personal constraints,the trainings and the shadow shifts to allocate the shift blocks at the right time, and last but not least dealing with the numerous last minute cancellations and shifters swaps, is really a painful and time-consuming job. Something needs to be changed in OTP to help with this task, by either blocking people when the institutes reached their allocated quota, or adding more info about their training to block the shift allocation automatically if the training is not completed. Or maybe we need a "global shift manager" provided by ATLAS to take care of this task for all the desks altogether.
3) Detector experts on-call
- Less shifters in ACR probably implies a much stronger team of 24/7 expert on-call for the sub-systems.
- Experience from the past run shows that it is becoming harder and harder to recruit people for the expert and on-call tasks, as they require quite a long training (a few months at least before being operational), and to be fully based at CERN.
- One problem comes from the institutes, whose finances are being cut pretty much everywhere and are becoming more reluctant to send people at CERN for long periods of time.
- The major problem is that the most indicated people for this type of tasks are postdocs, who do not want to be stuck for a full year or more in technical tasks simply because it is not valued at all for their careers, and they need to do physics analysis. This is a deeper problem, already discussed elsewhere: if being an expert on-call is not considered as critical task and not valued enough by the collaboration, we will not find the people to do it.
- Back to the point of the restricted number of shifts: giving less people the opportunity to work in the control room reduces the pool of new people who could possibly be motivated to take responsabilities in the sub-systems.

Revision 72014-02-16 - zimmerst

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

2014 Operations and Milestone Weeks

Milestone Week Dates

Line: 32 to 32
 
Run-2 Operations Model Proposal --- Comments, Input, Feedback concerning Shift Crew Composition/Shift Tasks

Name System, experience Comment
Changed:
<
<
* SCT just to say that I fully support the scheme you have proposed. The ID shifter merger was a success and I believe the process can be taken further. I particularly liked the question and your answer on the benefits we'd have, and if I may add, this scheme would reduce some of the little hiccups which were due to miscommunication between central and detector shifter. Of course, subdetector which feel they need a shifter are still free to add a shifter in case of periods of potential problems. This scheme actually gives some more flexibility (e.g. adding extra shifters or experts only when needed)  and will push the subdetector communities to further improve the tools for automatic supervision and the overall reliability of the detector.
>
>
Henric Wilkens   Maybe its all decided already, but if this is a proposal for discussion, then I could see alternative ways to reach a shift crew of 6. One which comes naturally to me, close to the ATLAS core organisation would be: Shift leader. Run control / trigger. ID. Calo / Forward. Muons. Slimos / Central DCS. 
This would be much closer to how we have been running, releave the detector system to try to merge the shift tasks of ID/Calo Fwd/Muons into one single shifter. It will also address some of the comments made in the questions following your presentation. 
Marko Mikuz Shift leader in 2012/13 As one of the field soldiers staffing the central desk in the second row I feel obliged to state my opinion from my personal view as shift leader. I shall directly confront the two proposals, although there is certainly a grey zone in-between.
a) Detector Controls, Beam Conditions and Luminosity  vs. separating out detector blocks ( ID(+Beam Conditions), Calo / Forward, Muons) and assigning Central DCS to SLIMOS The detector shifters were among the most busy on a data-taking shift. New challenges in Run 2 (25 ns, 13-14 TeV) could well be offset by higher level of AI in their systems but I sincerely doubt the load shall be reduced, at least at the start and well into first year of running.
b) RC & Trigger vs. RC/Trigger I (my fault ?) very rarely interacted with the Trigger shifter, most of the time with RC, who as a rule was sufficiently knowledgeable of the trigger issues.
c) SLIMOS & DQ vs. SLIMOS(+DQ ?) My personal view was that DQ is the most dispensable shifter and while SLIMOS is a must she/he could be loaded with additional tasks. At least SLIMOS & DQ look complimentary as their load peaks at different times - SLIMOS is most active in-between runs and DQ during data-taking.
Andrej Gorisek BCM I am more for detector-centric approach. I.e.  SL(+DQ), SLIMOS(+DCS), Run Control (+trigger), ID (+BCM/BLM), Calo (+FWD), Muons.
 In such a case also the additional/refreshment training would be kept to the minimum. From point of view of BCM it would be ideal for the task to stay in the same group of (mostly already trained) ID shifters. I also think DQ could be handled by a shift leader. From my experience there were shifts of irregular beams and all sort of machine studies when DQ shifter was just dismissed but there was quite some work for a shift leader. On the other hand the DQ shifter had the most work in shifts when everything was running smoothly and we were collecting lots of good data. In those shifts shift leader was less stressed.
Saverio SCT (personal opinion) just to say that I fully support the scheme you have proposed. The ID shifter merger was a success and I believe the process can be taken further. I particularly liked the question and your answer on the benefits we'd have, and if I may add, this scheme would reduce some of the little hiccups which were due to miscommunication between central and detector shifter. Of course, subdetector which feel they need a shifter are still free to add a shifter in case of periods of potential problems. This scheme actually gives some more flexibility (e.g. adding extra shifters or experts only when needed)  and will push the subdetector communities to further improve the tools for automatic supervision and the overall reliability of the detector.
 
Joseph Rothberg * The proposal to drop subdetector shifters will only work if each subdetector group provides software tools to detect known and potential subdetector problems and failure modes. There is very little emphasis on this in the proposal. Good problem-detection software is essential.
A time (and deadline) should be scheduled later this year when each subdetector demonstrates its problem-detection tools to the subdetector managers and to representatives from the shift leader/run coordinator/safety teams. The demonstrations should include some simulations of possible problems and the alerts/warnings that appear.
There also must be "written" documentation on the types of problems detected, the types of alerts/warnings issued, the severity, and the suggested responses.
Added:
>
>
Stefan Schlenker DCS Keeping the sub-detector (group) shifters will most likely allow a more efficient running in the beginning, mainly since we are all used to work like this. However, in the long term perspective to my mind there is no alternative to the merging and removing of having sub-detector (group) structures for shifters and their expert counterparts. For me, the natural separation in terms of operation tools is the detector control, run control/DAQ/trigger operation, and data quality checking. This is how the system was designed.
The question is thus not if we should do it but when we should do it. Nobody can really expect that we will run ATLAS forever with that many shifters and the sizable collection of operator/expert tools here and there all doing similar things. From what I know, many HEP experiments went through this process with almost always the same result. That the transition period will cost time and effort remains undisputed.
Today there was the question asked what we might gain. I think we will on the log term gain not only a reduction of shifters which is the least important part, but the streamlining of the online system and operator tools should finally result in a reduced workload on the operations support team of all systems. This is where we had to fight an increasing lack of manpower/expertise already in run 1.
I think we should invest better now than at a later stage when the detector upgrade will take its toll on the operation and commissioning effort in the subsequent long shutdown periods. Further I would support the suggestion of Dave to try to have sub-detector group discussions with TC/run coordination+maybe central systems first to facilitate a more prepared and structured discussion in the overall workshop.
Dave Robinson SCT I personally agree with much of what Saverio said, but just to avoid possible confusion, this does not (yet) represent the viewpoint of the ID community, as we haven't yet had the discussion.
I would very much welcome the suggestion that Technical Coordination should meet separately with the four sub detector communities to discuss the proposal and any detector-specific concerns,  rather than in an open discussion in a large meeting.  I think the individual subsystems can sometimes have very different concerns.
Adrey Loginov TRT Can we think of something like "Risk Analysis" of possible operation faults for the two shift scenarios discussed so far? (the subsystem-based one and the type-of-task one).
There were some situations in Run 1 when shifters could have been more efficient, although overall it worked well. One can imagine similar situations with the two shift scenarios and see how things will work.
Manpower-wise, if it's only 1 person difference in the two shift crews then it's not the highest concern. All that really matters (as a few of you pointed out at the ATLAS meeting today) is the data quality /efficiency of the detector operation. There are strong points in both shift approaches, so we should make sure we don't overlook the weak ones.
 

Run-2 Operations Model Proposal --- Comments, Input, Feedback concerning Shift Allocation Scheme, Minimum Number of Shifts, Shift Eligibility Criteria, Training Organization

Name System, experience Comment
Changed:
<
<
*   Instead of 21 shifts minimum require 11 shifts minimum with 21 recommended (this will be more inline with our Run 1 numbers). Instead of allocation booking (seems a huge time-waste for run coordinators) keep self-booking with people wanting to do more that 21 shifts having opportunity to book earlier (prebook) & assure training is booked at the same time as shifts
>
>
Norman Gee * Comments from the perspective of someone doing shifts but not CERN-resident
The Central Shift Call needs to be early enough that flights can be booked for the training at reasonable prices, and also that CERN Hostel room is available;
Collaborators outside CERN often have institute responsibilities, e.g. teaching, or on the other hand may already have to travel to CERN for detector meetings. There was supposed to be some priority in the shift booking system for non-CERN residents to allow for this, but in practise I found that, e.g., the weekend trigger shifts were normally filled within around 10 minutes of opening, and at least half were taken by people I knew were CERN-resident. It would be excellent if your work somehow also took this into account. I’m not clear how this works with the “8 weeks total” in your foil 9.
Tetiana Hryn'Ova * Instead of 21 shifts minimum require 11 shifts minimum with 21 recommended (this will be more inline with our Run 1 numbers). Instead of allocation booking (seems a huge time-waste for run coordinators) keep self-booking with people wanting to do more that 21 shifts having opportunity to book earlier (prebook) & assure training is booked at the same time as shifts
 
Hasko Stenzel * I do have serious concerns with the shift allocation scheme, that is too strict and people should have the opportunity to book their shifts themselves, also the minimum number of shifts is too strict and should rather be seen as a guideline with allowed variance, the distributions for run1 were not that bad to justify that rigid scheme.
Nicolas Berger * Two comments on the new model:
21 shifts/person minimum :
According to your own computation, this would mean that only ~200 people could take part in shifts in a given year, which is probably even less than number of new students coming in each year (1000 students in ATLAS / ~4 years). This would mean that some students would not be able to take even 1 block of shift during their studies, which I find regrettable.
This would also mean that the tasks open to non-students would only be "expert" tasks, which are few in number and require a large time-commitment. This would lead to a de facto split between a small pool of experts, and the bulk of the collaboration which would be totally disconnected from detector operations.
I realize that in a sense this is the whole point of the change -- to concentrate the work in the hands of fewer experts to improve efficiency. However this should be balanced against the risk that data-taking becomes a kind of "black box" for most of the collaboration. In my view the current requirements seem too skewed in the first direction.
Switch to "allocation" model :
I don't see the reason to require people to free up 8 full weeks of their schedule in a 6-month period in order to be allowed to take shifts. This will lead to inconvenient bookings, reschedulings, etc. which will just waste everybody's time.
I see there has been an effort to reintroduce some flexibility a posteriori (1 day per week exception, etc.), but this can by definition only help in some particular situations. I think that keeping a signup-based system would be both more convenient for aspiring shifters, and easier to manage for you.
Jessica Leveque DQ feedback from subsystems 1) Number of shifts
- 5 months * 30 days * 3 shifts per day * 6 desks = 2700 shifts
- if 21 shifts minimum required: 6.5% (assuming 2000 ATLAS active members willing to take shifts)
Many more than 6% of newcomers per year: how do we ensure that new student and postdoc get in touch with the detector environment ? By restricting the number of people accessing shifts, we also reduce the possibility for new people to approach the expert on-call tasks (critical point, see number 3) below)
2) Shifts organization
- From the shifter point of view: asking people to block 8 weeks, several months in advanced, and force them to be randomly assigned shifts within this 8 weeks is unrealistic. People with families, teaching duties, limited stays at CERN (often 3 to 6 months for students) or convenership responsabilities in the collaboration can not do that. The "OR" of these 4 points covers a very large fraction of the ATLAS physicists.
- From the run coordination point of view: shift allocation instead of shift booking is a significant overload of work. Past experience in offline DQ showed that designing the shifter planning by hand several months in advance while taking into account the institutes quotas of the past shift periods (trying to provide a fair sharing of the available shifts within institutes), taking into account the shifters personal constraints,the trainings and the shadow shifts to allocate the shift blocks at the right time, and last but not least dealing with the numerous last minute cancellations and shifters swaps, is really a painful and time-consuming job. Something needs to be changed in OTP to help with this task, by either blocking people when the institutes reached their allocated quota, or adding more info about their training to block the shift allocation automatically if the training is not completed. Or maybe we need a "global shift manager" provided by ATLAS to take care of this task for all the desks altogether.
3) Detector experts on-call
- Less shifters in ACR probably implies a much stronger team of 24/7 expert on-call for the sub-systems.
- Experience from the past run shows that it is becoming harder and harder to recruit people for the expert and on-call tasks, as they require quite a long training (a few months at least before being operational), and to be fully based at CERN.
- One problem comes from the institutes, whose finances are being cut pretty much everywhere and are becoming more reluctant to send people at CERN for long periods of time.
- The major problem is that the most indicated people for this type of tasks are postdocs, who do not want to be stuck for a full year or more in technical tasks simply because it is not valued at all for their careers, and they need to do physics analysis. This is a deeper problem, already discussed elsewhere: if being an expert on-call is not considered as critical task and not valued enough by the collaboration, we will not find the people to do it.
- Back to the point of the restricted number of shifts: giving less people the opportunity to work in the control room reduces the pool of new people who could possibly be motivated to take responsabilities in the sub-systems.

Revision 62014-02-16 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

2014 Operations and Milestone Weeks

Milestone Week Dates

Line: 33 to 33
 
Name System, experience Comment
* SCT just to say that I fully support the scheme you have proposed. The ID shifter merger was a success and I believe the process can be taken further. I particularly liked the question and your answer on the benefits we'd have, and if I may add, this scheme would reduce some of the little hiccups which were due to miscommunication between central and detector shifter. Of course, subdetector which feel they need a shifter are still free to add a shifter in case of periods of potential problems. This scheme actually gives some more flexibility (e.g. adding extra shifters or experts only when needed)  and will push the subdetector communities to further improve the tools for automatic supervision and the overall reliability of the detector.
Added:
>
>
Joseph Rothberg * The proposal to drop subdetector shifters will only work if each subdetector group provides software tools to detect known and potential subdetector problems and failure modes. There is very little emphasis on this in the proposal. Good problem-detection software is essential.
A time (and deadline) should be scheduled later this year when each subdetector demonstrates its problem-detection tools to the subdetector managers and to representatives from the shift leader/run coordinator/safety teams. The demonstrations should include some simulations of possible problems and the alerts/warnings that appear.
There also must be "written" documentation on the types of problems detected, the types of alerts/warnings issued, the severity, and the suggested responses.
 
Run-2 Operations Model Proposal --- Comments, Input, Feedback concerning Shift Allocation Scheme, Minimum Number of Shifts, Shift Eligibility Criteria, Training Organization

Name System, experience Comment
*   Instead of 21 shifts minimum require 11 shifts minimum with 21 recommended (this will be more inline with our Run 1 numbers). Instead of allocation booking (seems a huge time-waste for run coordinators) keep self-booking with people wanting to do more that 21 shifts having opportunity to book earlier (prebook) & assure training is booked at the same time as shifts
Added:
>
>
Hasko Stenzel * I do have serious concerns with the shift allocation scheme, that is too strict and people should have the opportunity to book their shifts themselves, also the minimum number of shifts is too strict and should rather be seen as a guideline with allowed variance, the distributions for run1 were not that bad to justify that rigid scheme.
Nicolas Berger * Two comments on the new model:
21 shifts/person minimum :
According to your own computation, this would mean that only ~200 people could take part in shifts in a given year, which is probably even less than number of new students coming in each year (1000 students in ATLAS / ~4 years). This would mean that some students would not be able to take even 1 block of shift during their studies, which I find regrettable.
This would also mean that the tasks open to non-students would only be "expert" tasks, which are few in number and require a large time-commitment. This would lead to a de facto split between a small pool of experts, and the bulk of the collaboration which would be totally disconnected from detector operations.
I realize that in a sense this is the whole point of the change -- to concentrate the work in the hands of fewer experts to improve efficiency. However this should be balanced against the risk that data-taking becomes a kind of "black box" for most of the collaboration. In my view the current requirements seem too skewed in the first direction.
Switch to "allocation" model :
I don't see the reason to require people to free up 8 full weeks of their schedule in a 6-month period in order to be allowed to take shifts. This will lead to inconvenient bookings, reschedulings, etc. which will just waste everybody's time.
I see there has been an effort to reintroduce some flexibility a posteriori (1 day per week exception, etc.), but this can by definition only help in some particular situations. I think that keeping a signup-based system would be both more convenient for aspiring shifters, and easier to manage for you.
Jessica Leveque DQ feedback from subsystems 1) Number of shifts
- 5 months * 30 days * 3 shifts per day * 6 desks = 2700 shifts
- if 21 shifts minimum required: 6.5% (assuming 2000 ATLAS active members willing to take shifts)
Many more than 6% of newcomers per year: how do we ensure that new student and postdoc get in touch with the detector environment ? By restricting the number of people accessing shifts, we also reduce the possibility for new people to approach the expert on-call tasks (critical point, see number 3) below)
2) Shifts organization
- From the shifter point of view: asking people to block 8 weeks, several months in advanced, and force them to be randomly assigned shifts within this 8 weeks is unrealistic. People with families, teaching duties, limited stays at CERN (often 3 to 6 months for students) or convenership responsabilities in the collaboration can not do that. The "OR" of these 4 points covers a very large fraction of the ATLAS physicists.
- From the run coordination point of view: shift allocation instead of shift booking is a significant overload of work. Past experience in offline DQ showed that designing the shifter planning by hand several months in advance while taking into account the institutes quotas of the past shift periods (trying to provide a fair sharing of the available shifts within institutes), taking into account the shifters personal constraints,the trainings and the shadow shifts to allocate the shift blocks at the right time, and last but not least dealing with the numerous last minute cancellations and shifters swaps, is really a painful and time-consuming job. Something needs to be changed in OTP to help with this task, by either blocking people when the institutes reached their allocated quota, or adding more info about their training to block the shift allocation automatically if the training is not completed. Or maybe we need a "global shift manager" provided by ATLAS to take care of this task for all the desks altogether.
3) Detector experts on-call
- Less shifters in ACR probably implies a much stronger team of 24/7 expert on-call for the sub-systems.
- Experience from the past run shows that it is becoming harder and harder to recruit people for the expert and on-call tasks, as they require quite a long training (a few months at least before being operational), and to be fully based at CERN.
- One problem comes from the institutes, whose finances are being cut pretty much everywhere and are becoming more reluctant to send people at CERN for long periods of time.
- The major problem is that the most indicated people for this type of tasks are postdocs, who do not want to be stuck for a full year or more in technical tasks simply because it is not valued at all for their careers, and they need to do physics analysis. This is a deeper problem, already discussed elsewhere: if being an expert on-call is not considered as critical task and not valued enough by the collaboration, we will not find the people to do it.
- Back to the point of the restricted number of shifts: giving less people the opportunity to work in the control room reduces the pool of new people who could possibly be motivated to take responsabilities in the sub-systems.

  -- Main.apolini - 2014-02-03

Revision 52014-02-14 - zimmerst

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

2014 Operations and Milestone Weeks

Milestone Week Dates

Line: 32 to 32
 
Run-2 Operations Model Proposal --- Comments, Input, Feedback concerning Shift Crew Composition/Shift Tasks

Name System, experience Comment
Changed:
<
<
Saverio SCT, personal opinion just to say that I fully support the scheme you have proposed. The ID shifter merger was a success and I believe the process can be taken further. I particularly liked the question and your answer on the benefits we'd have, and if I may add, this scheme would reduce some of the little hiccups which were due to miscommunication between central and detector shifter. Of course, subdetector which feel they need a shifter are still free to add a shifter in case of periods of potential problems. This scheme actually gives some more flexibility (e.g. adding extra shifters or experts only when needed)  and will push the subdetector communities to further improve the tools for automatic supervision and the overall reliability of the detector.
>
>
* SCT just to say that I fully support the scheme you have proposed. The ID shifter merger was a success and I believe the process can be taken further. I particularly liked the question and your answer on the benefits we'd have, and if I may add, this scheme would reduce some of the little hiccups which were due to miscommunication between central and detector shifter. Of course, subdetector which feel they need a shifter are still free to add a shifter in case of periods of potential problems. This scheme actually gives some more flexibility (e.g. adding extra shifters or experts only when needed)  and will push the subdetector communities to further improve the tools for automatic supervision and the overall reliability of the detector.
 
Run-2 Operations Model Proposal --- Comments, Input, Feedback concerning Shift Allocation Scheme, Minimum Number of Shifts, Shift Eligibility Criteria, Training Organization

Name System, experience Comment
Changed:
<
<
Tetiana Hryn'Ova   Instead of 21 shifts minimum require 11 shifts minimum with 21 recommended (this will be more inline with our Run 1 numbers). Instead of allocation booking (seems a huge time-waste for run coordinators) keep self-booking with people wanting to do more that 21 shifts having opportunity to book earlier (prebook) & assure training is booked at the same time as shifts
>
>
*   Instead of 21 shifts minimum require 11 shifts minimum with 21 recommended (this will be more inline with our Run 1 numbers). Instead of allocation booking (seems a huge time-waste for run coordinators) keep self-booking with people wanting to do more that 21 shifts having opportunity to book earlier (prebook) & assure training is booked at the same time as shifts
  -- Main.apolini - 2014-02-03

Revision 42014-02-13 - zimmerst

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"

2014 Operations and Milestone Weeks

Milestone Week Dates

Line: 13 to 13
 

Milestone Week Sub-Detector Integration Schedule

The current version of the M-Week Planning can be found here.

Added:
>
>
 

Run-2 Preparation

Added:
>
>

Operations Model/Shift Organization Discussion

After the Run-1 Operations Workshop in summer 2013 Run Coordination was charged to work out a proposal for the Run-2 Data Taking Operation Model and Shift Organization; the proposal has been presented

  1. In the LS1 Weekly Meeting on Jan 27th 2014 (to the systems and system run coordinators),
  2. In the ATLAS Weekly/Open EB on Tue Jan 28th 2014
  3. In the ATLAS Week on Feb 12 2014

and is described in detail in the EDMS document https://edms.cern.ch/document/1348082/1.

Feedback and Input from the Collaboration

Feedback and comments have been requested from the collaboration, as well as from systems and project leaders; in parallel, Run Coordination will actively seek the dialog with sub-detectors and systems; It is planned to wrap up the discussion and arrive at a decision in dedicated workshop on Tue March 18.

In order to facilitate the feedback collection process, comments shall be added to the 2 paragraphs following below directly in the Twiki page.

Run-2 Operations Model Proposal --- Comments, Input, Feedback concerning Shift Crew Composition/Shift Tasks

Name System, experience Comment
Saverio SCT, personal opinion just to say that I fully support the scheme you have proposed. The ID shifter merger was a success and I believe the process can be taken further. I particularly liked the question and your answer on the benefits we'd have, and if I may add, this scheme would reduce some of the little hiccups which were due to miscommunication between central and detector shifter. Of course, subdetector which feel they need a shifter are still free to add a shifter in case of periods of potential problems. This scheme actually gives some more flexibility (e.g. adding extra shifters or experts only when needed)  and will push the subdetector communities to further improve the tools for automatic supervision and the overall reliability of the detector.
 
Added:
>
>
Run-2 Operations Model Proposal --- Comments, Input, Feedback concerning Shift Allocation Scheme, Minimum Number of Shifts, Shift Eligibility Criteria, Training Organization
 
Added:
>
>
Name System, experience Comment
Tetiana Hryn'Ova   Instead of 21 shifts minimum require 11 shifts minimum with 21 recommended (this will be more inline with our Run 1 numbers). Instead of allocation booking (seems a huge time-waste for run coordinators) keep self-booking with people wanting to do more that 21 shifts having opportunity to book earlier (prebook) & assure training is booked at the same time as shifts
  -- Main.apolini - 2014-02-03

Revision 32014-02-10 - zimmerst

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"
Changed:
<
<
Initial template for Run-2 Preparation documentation
>
>

2014 Operations and Milestone Weeks

Milestone Week Dates

  • M1 Run/Week: Feb 17 to 21 2014
  • M2 Run/Week: Mar 31 to Apr 4 2014
  • M3 Run/Week: May 19 to May 23 2014
  • M4 Run/Week: Jul 7 to Jul 11 2014
  • M5 Run/Week: Sep 8 to Sep 12 2014
  • M6 Run/Week: Oct 13 to Oct 17 2014
  • Extended Cosmics Data Taking: beginning to mid Dec 2014, exact dates to be defined

Milestone Week Sub-Detector Integration Schedule

The current version of the M-Week Planning can be found here.

Run-2 Preparation

 
Deleted:
<
<
Information and Schedule of ATLAS Milestone Runs
 

-- Main.apolini - 2014-02-03 \ No newline at end of file

Added:
>
>

META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v2.pdf" attr="" comment="M-Week Schedule version 2" date="1392044436" name="MilestoneWeek_Schedule_v2.pdf" path="MilestoneWeek_Schedule_v2.pdf" size="75964" stream="MilestoneWeek_Schedule_v2.pdf" tmpFilename="/usr/tmp/CGItemp28226" user="zimmerst" version="1"
META FILEATTACHMENT attachment="MilestoneWeek_Schedule_v3.pdf" attr="" comment="M-Week schedule version 3 (Feb 10 2014)" date="1392044455" name="MilestoneWeek_Schedule_v3.pdf" path="MilestoneWeek_Schedule_v3.pdf" size="76926" stream="MilestoneWeek_Schedule_v3.pdf" tmpFilename="/usr/tmp/CGItemp28185" user="zimmerst" version="1"

Revision 22014-02-10 - apolini

Line: 1 to 1
 
META TOPICPARENT name="AtlasOperation"
Changed:
<
<
initial template for Run-2 Preparation documentation
>
>
Initial template for Run-2 Preparation documentation
  Information and Schedule of ATLAS Milestone Runs

Revision 12014-02-03 - apolini

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="AtlasOperation"
initial template for Run-2 Preparation documentation

Information and Schedule of ATLAS Milestone Runs

-- Main.apolini - 2014-02-03

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding ATLAS?Please contact the page author (see Topic revision above) or the Run Coordinator of the specific system.
Contact SysAdmins support only for technical issues