Run-2 Operation, Shift Model, 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

Feedback and Input from the Collaboration

Feedback and comments had 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. The received feedback is presented and summarized at the end of the page. Following that a revised proposal is in preparation.

Revised Proposal and EDMS Document

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 (in preparation) is available as EDMS document in: https://edms.cern.ch/document/1348082/1. This will be soon presented to the collaboration. A very short description on this Revised Proposal is available here. Please send comments, suggestions and remarks on the EDMS document to Run Coordination.

Run-2 Operations Model Proposal --- Received 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 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 ?
Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r7 - 2015-05-14 - apolini
 
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