%CERTIFY%

Authorship Committee

Membership and mandate
ATLAS Authorship policy
Step-by-step guides
Author Lists
Some hints for the use of the Glance interface may be found below:
Special Comments for Qualifying on Upgrade Activities or other projects involving more than one Activity Area
ATLAS Authorship M&O Information
List of high priority tasks for qualification as ATLAS Author
Other relevant links and documents
- Short-Term Associations (STA)
- Other Authorship Links

Membership and mandate

Composition and selection procedure

The Committee consists of three ATLAS members, which have been selected by the Spokesperson among the Publication Committee members. The choice is endorsed by the CB. Each member serves for three years, and each year, a member of the Publication Committee is selected as a new member of the Authorship Committee (AC), replacing the longest serving member. The member in the third years acts as Chairperson.

The spokesperson and the Publication Committee Chair are ex-officio members of the AC. The Deputy Spokesperon(s) and the Physics Coordinator are invited to attend the AC meetings.

Mandate

The Committee is responsible for:

Implementation of the authorship policies
Correctness of the information stored in the authorship database
Management of the author lists

Current members and roles:

Authorship committee membership (Mar 2015 - Mar 2016)

Davide Costanzo, Sheffield (AC chair, exceptional authorship)
Henri Bachacou, Saclay (qualification start-ups)
Young-Kee Kim, Chicago (end-of-qualifications)

The former chairs are:

Masahiro Kuze, Tokyo Tech (chair 2014-2015)
David Milstead, Stockholm (chair 2013-14)
Isabel Trigger, TRIUMF (chair 2012-13)
Dominique Pallin, Clermont-Ferrand (chair 2011-12)
Markus Schumacher, Freiburg (chair 2010-11)
Shlomit Tarem, Technion (chair 2009-10)
Marina Cobal, Udine (chair 2008-9)
Anna Lipniacka, Bergen (chair 2007-8)

Contact information

In case of question please contact

 atlas-authdb-qual@cern.ch

ATLAS Authorship policy

The ATLAS authorship policy is available at Authorship Policy document

This TWiki provides a practical guide to the most common Authorship Committee related tasks. PLEASE NOTE THAT IN ALL CASES OF DISAGREEMENT BETWEEN INFORMATION IN THE TWIKI AND IN THE AUTHORSHIP POLICY, THE POLICY SHOULD BE CONSIDERED TO BE THE DEFINITIVE SOURCE OF INFORMATION. Please report any discrepancies you notice to the authorship committee.

Rules for qualifying as an ATLAS author

To qualify as an ATLAS author a new member must:

Have been a qualifying ATLAS member for at least one year.
Not be an author of another major LHC collaboration at the time of application (this rule applies to all physicists, but an exception may be made for engineers).
Have spent at least 80 working days doing pre-agreed ATLAS technical work (more details can be found in the Authorship Policy document).

The total of 80 days technical work may be accumulated over more than one year in exceptional circumstances. The original intention of the 80 working day minimum was "at least half of the person's research time over the course of a year" (but that definition ran into difficulties because it forced people with more research time to do more work to qualify as authors than people with less research time, so it was felt to be unfair). "80 working days" does not mean "part time for a couple of months" or "did something related to it on about 80 different days". It means that over the course of a year, the person should have spent a bare minimum of 80 eight-hour working days entirely on the specific topic agreed to with the project leader or activity coordinator and entered in the Glance database. If you spend more time on your physics analysis than you do on your qualification task during the qualification year, you are not taking the qualification work seriously enough! And yes - we know that it is difficult for a new faculty member joining ATLAS from another experiment, who may have a heavy teaching or administrative load, and may be unable to spend much time at CERN, to complete 80 full working days of agreed technical work in a single year, which is why we do allow people to take longer than one year to qualify.

The Glance database

The ATLAS authorship database is used to produce author lists for ATLAS papers, the ATLAS directory and the yearly breakdown of M-and-O and operations tasks quotas. The database supports the work of the Authorship Committee, who are responsible for implementation of policies and the correctness of the information stored. The database (see the technical documentation in ATLAS-COM-GEN-2010-001

) has been developed by Richard Hawkings, in conjunction with various members of the authorship committee over time.

Browsing and editing of authorship data should be done via the Glance Interface.

Roles in the ATLAS Database

Access and modification privileges on the database are granted via the standard NICE login on the basis of your assigned role. The following roles have been defined:

USER: normal access rights, you can only see your full record.
Technical supervisor (TS): A qualified ATLAS member who is responsible for reporting on the qualification progress to the Authorship Committee, and eventually approving the completion of the qualification task (for example: the convener of the combined performance group in which the task is done)
Local Supervisor (LS): The person at the same institute as the new member who is 'supervising' the new member (for example: for a PhD student, the PhD advisor)
Institute Representative (IR): this role is assigned to the Team Leader and, on request by the TL, to the deputies. Institute Representatives have access to the full information of all members in their Institute. Any change of TL and/or deputy should be notified to the ATLAS Secretariat so the roles can be assigned correctly.
Institute Secretariat: same privileges as the Institute Representative; can be assigned to administrative personnel at the Institute who help keeping the records updated, provided they have a NICE login. Requests should be addressed to the ATLAS Secretariat.
Institution Representative: this role is assigned to the representative of an Institution, and ensures full access to all the members of the Institutes in the corresponding cluster.
National Contact Physicist: has access to records for all members of Institutes in the corresponding country and can change the affiliation of members among institutes in the country.

(note that 'supervisor' is intended in a broad sense, for more senior colleagues a supervisor is the person who is helping a new member become a fully qualified ATLAS author)

Step-by-step guides

This section provides step-by-step guides for the main authorship requests

Qualification of a new member

(Full details are given on Appendix A of the Policy document)

The qualification procedure can only be started by the Institute (or Institution) Representative, and it is guided by the interface.

Step 1: the IR accesses the member record and clicks on the green button "Authorship Qualification" in the ATLAS database. Click on the "How do I qualify?" to receive full information and an updated list of high priority qualification tasks
Step 2: the IR accesses the qualification area once again to submit a qualification project and a proposed beginning of qualification date, a technical supervisor and a local supervisor. Note that you will have to select one area of qualification and that the Project Responsible for that area will be notified and will have to approve the proposal, so you should agree on a project beforehand.
Step 3: the proposal is approved/rejected by the Project Responsible
Step 4: the proposal is approved/rejected by the Authorship Committee and a beginning of qualification date is set in case of approval.
Step 5: four months after the start of the project, the Technical Supervisor should evaluate the progress of the task: has the task started? Is progress being made. This is done via the Glance DB by filling the “engagement checkpoint” box.
Step 6: after one year from the beginning of qualification, the Technical Supervisor will have to submit a report in glance, answering explicitly the following question: was the task completed according to the pre-agreed task description?
Step 7: the Authorship Committee sets a qualification date after a final check with the relevant Project Responsible.

NOTE: Step 1 needs to be done before the task starts. Start of qualification can only be back-dated by one month only on very exceptional circumstances a backdate of more than one monthr is allowed.

End of qualification

When the end of a contract is reached authorship is automatically terminated on the same day and the former author automatically becomes a signin-only author for a period of 12 months. To ensure a smooth transition for ATLAS members changing institutes there is a one-month grace period, during which a signing-only author can still access ATLAS-internal information. If a former author joins ATLAS again within a one-month period authorship is reinstated automatically. After one-month the access to ATLAS-internal information is restricted and a request needs to be made to the authorship committee in order to regain authorship and access to the internal information (see below).

Affiliation change or contract update

Changes of affiliations and changes in contract of existing members (e.g. Master's student to PhD student) are handled by the ATLAS secretariat, email them at atlas.secretariat@cernNOSPAMPLEASE.ch for information.

Reinstating a former author

When there is a gap in authorship longer than one-month, authorship is not automatically recovered and the authorship committee needs to be contacted. Guidelines on how to proceed are based on the length of the gap:

less than one month: automatically handled by Glance
between one month and 6 months: usually requires no justification: handled by the authorship committee
between 6 months and 12 months: at the authorship committee discretion, depending on circumstances
after 12 months: member needs to re-qualify as an author. No exceptions.

The rationale behind this is the following. Every ATLAS member will have spent 1 year on ATLAS without being an author (while qualifying). This year is then recovered when the member leaves ATLAS, and continues to sign papers for another year. During this year the paper(s) on which this person worked on should be published. By re-qualifying a former ATLAS author gains another year at the end of their affiliation.

Request to terminate authorship

Team leaders can request to terminate the authorship of one of their team members while maintaining a valid employment record in Glance. Requests should be sent by email to the authorship committee and providing a justification for this. It should be noted that by terminating authorship, access to internal information is lost. Reinstating an author at the same institute may not be possible without re-qualifying.

Request for exceptional authorship

(See Section 3.4.2 of the Authorship Policy) In all cases, the AC Chairperson will make a recommendation to the Spokesperson. The ultimate decision lies with the Spokesperson.

The request for exceptional authorship should be received by the Authorship Committee as early as possible, during the circulation of the First Draft. Approving these requests takes some time, as the Institute Team Leader, the Working Group Conveners, the Project Leader or Activity Coordinator responsible for the qualification task of qualifying members, and sometimes the team responsible for the Paper, all have to be consulted before the request can be approved.

An ATLAS member who has not yet qualified as an active ATLAS author and yet has made a significant contribution to a particular paper may make a request to the AC Chairperson to be included in the paper’s Author list. Team leaders may recommend members of their Institution who would not normally qualify as authors and yet who have made a significant contribution to ATLAS. In particular, it may be very appropriate to recognise key Engineers on papers related to the subsystems on which they have worked.

It should be noted that exceptional authorship is usually considered for only one paper. In particular, even if a still-qualifying author has made some contribution that was crucial for more than one paper, a choice must be made of just one paper on which they will appear as an author, based on that contribution. In cases where second requests for exceptional authorship are made for people who contributed different work to different papers, we generally look very carefully at the progress of their authorship qualification task. If someone has time to make major contributions to two separate physics analyses, that time often comes at the price of taking longer than one year to complete the regular authorship qualification task. This is generally not considered acceptable.

Requests received after the second circulation to ATLAS may still be considered, if there is sufficient time to reach a decision. While it is not possible to change the author list of a paper which has already been submitted to a journal.

Request for authorship for short-term-associates (STA)

(See Section 3.4.2 of the Authorship Policy) In all cases, the AC Chairperson will make a recommendation to the Spokesperson. The ultimate decision lies with the Spokesperson. Non-ATLAS members who are short term associates to ATLAS may request to sign the paper(s) they have been working on in collaboration with ATLAS members as specified in their STA case. Requests should be submitted to the authorship committee by email as early as possible during the circulation of the first draft.

Author Lists

Author lists are generated automatically via glance and are available at this link: ATLAS authorlists

Authorlists have a "reference date" as the date of the first circulation of a paper to ATLAS. All ATLAS members that are authors on that day will be part of the author list
Authorlists are "frozen" when a paper is circulated to ATLAS the second time, and are used for the final paper submission. This is why it is important that exceptional cases are handled before the second circulation.

Some hints for the use of the Glance interface may be found below:

Each member can check whether their own information in the ATLAS Membership Database is correct by logging in with their NICE account https://atglance.web.cern.ch/atglance/authorship/

Normal users can only see their own record and modify a few personal fields - among them the LaTeX First Name, LaTeX Last Name and Initials which are used to generate the names appearing in the author list, and the activities for each employment record.

Institute Representatives can see the full record of all people in their group, and can modify their information, including the start and end date of their contract and their profession (student, physicist, engineer). In case a person has changed profession while being at the same Institute, the IR should close the record and open a new one with the new profession.

Institution Representatives have the same rights as above, but for all the members belonging to Institutes in their cluster. Country Representatives have the same rights as above, but for all the members belonging to Institutes in their countries.

Please be aware that some browsers will not display the updates immediately, since they keep on taking the data from their cache. If you make changes, receive no error messages, and do not see the changes reflected, please wait still some time before contacting the technical support.

Whom to contact in case of questions and problems:
- for questions about qualification, please contact the Authorship Committee at atlas-authdb-qual@cernNOSPAMPLEASE.ch
- for all technical problems concerning the interface (you cannot login, you do not have the correct rights, etc.) send an email to Atlas.Glance@cernNOSPAMPLEASE.ch .
- for moving person from one Institute to another, or insert new members, please contact the ATLAS Secretariat at Atlas.Secretariat@cernNOSPAMPLEASE.ch.

Special Comments for Qualifying on Upgrade Activities or other projects involving more than one Activity Area

Upgrade projects are defined as project for which a TDR is not yet available
Students are allowed to qualify based entirely on upgrade activities; in this case only the Upgrade Project Coordinator is required to approve the project
PhD physicists are required to spend at least half their qualification time on activities related to operation of the current detector. They may get credit for up to half of their qualification activity from upgrades. (see Authorship Policy section 2.1). This means that two different project leaders or activity coordinators (Upgrade and one other) will need to approve these qualification projects.
The Glance interface only allows one Project Responsible to sign off on a project (and get automatic e-mails about progress, etc.) In case a qualification project spans more than one Activity Area, the IR must contact both Project Responsibles to discuss the qualification before entering the project in Glance, and they must both agree to it. It should then be noted explicitly in the project description in Glance which other Activity Area is involved in the project.
There is a very good page at the Upgrades website with many more details.

ATLAS Authorship M&O Information

(The link above is only accessible to ATLAS members who have access to Protected information.)

List of high priority tasks for qualification as ATLAS Author

OTP tasks, which (with the exception of non-expert shift work) are all acceptable for qualification, can be seen using the Operation Task Planner tool
https://pptevm.cern.ch/mao/client/cern.ppt.mao.app.gwt.MaoClient/MaoClient.html#taskList

High priority tasks from trigger group

https://twiki.cern.ch/twiki/bin/view/Atlas/TriggerServiceTasks

High priority tasks from Data Preparation group (last updated May 9th, 2013)

Contact: Eric Torrence, Paul Laycock

Area 1: Event Display
1. VP1 developments, namely improving the representation of full physics events
  Required knowledge: C++, Python, Athena (can be acquired during job)
  FTE: 1+
  Contact: Vakho Tsulaia
2. Atlantis: Maintenance of Atlantis and JiveXML. Improvement to the quality of the user interface, enhancements for more intuitive physics views, performance improvement for higher luminosities (OT).
  Required knowledge: Java, C++
  FTE: 0.5+ for at least 12 months, potential for long term involvement
  Contact: Nikos Konstantinidis
3. Persint: Maintenance and update of the Persint documentation FTE:0.3
  Contact: Laurent Chevalier

Area 2: Luminosity
1. Offline Luminosity in COOL
  Work with the luminosity group to develop a framework and monitoring infrastructure to allow online and offline luminosity determinations to be incorporated into the existing COOL offline folders with much less manual intervention. Work should be done in coordination with existing luminosity DQ efforts to develop, deploy, and support tools to streamline the DQ assessment and production of offline luminosity values for physics. Expanding beyond the existing online measurements to include other offline measures of luminosity (such as primary vertex counting, W/Z counting, and so on) should also be seen as part of this task.
  Required knowledge: Python, C++, Oracle (can be acquired during job) - help to ramp up available at CERN
  FTE: 0.5 (OTP accountable / authorship qualification)
  Contact: Eric Torrence, Witold Kozanecki
2. Online Beam-related measurements in COOL
  Work with online subdetector groups for extracting/processing/storing in COOL subdetector measurements related to understanding luminosity, beam and cavern background related effects on the detector for use in offline analysis. Quantities should be stored at intervals which make correlations between subsystems possible. Subdetectors may be interested in using this information offline as input to better online calibrations.
  Required knowledge: Python, C++, Oracle (can be acquired during job) - help to ramp up available at CERN
  FTE: 0.5 (OTP accounted)
  Contact: Marjorie Shapiro, Witold Kozanecki, Eric Torrence
3. Online Luminosity Calculator (maintenance and development)
  Work maintaining and further developing the OLC, a critical tool for ATLAS and LHC operations. Ideal for student or young post-doc with some c++ experience who wants to work on some operational aspect of the experiment. Needs to commit for 2012 and feel responsible for the tool - but in steady state only about 15% FTE.
  FTE: 0.2 (OTP accounted)
  Contact: Witold Kozanecki

Area 3: Prompt offline reconstruction (PROC) and reprocessing
1. Support for software validation framework integration (TCT, RTT)
  Required knowledge: C++, Python, Athena (can be acquired during job)
  FTE: 0.1
  Contact: Joe Tuggle, Joao Firmino da Costa, James Frost

Area 4: Non-collision background working group
1. Developments of Non-collision background software
  Currently several areas of the non-collision background software need developments. This task includes working on one or more of the following topics: Athena code for background results coding, implementation of the non-collision background identification tools, looking after BackgroundD3PDMaker and related packages, keeping the software up-to-date in the AtlasPhysics cache and making sure that the available results on non-collision backgrounds are available in the ntuples for physics analyses.
  Required knowledge: Running athena, writing algorithms / tools in athena
  FTE: 0.5
  Contact: David Salek, Mika Huhtinen
2. Beam background simulations and validation
  Taking care of beam background simulation production and validation in the ATLAS simulation framework. The task involves to validate and set up MC production and to compare the MC results with data and to try to understand the sources of differences between data and simulations. This task would ideally cover studying beam background characteristics in various ATLAS subdetectors, working in close contact with the subsystem experts.
  A related task would be to set up and perform independent small scale simulations (possibly with stand-alone FLUKA) in order to understand specific features of the beam-backgrounds and to identify the most significant components for ATLAS. This work feeds directly into optimizing the cuts in the production simulations. It can involve also dedicated studies for forthcoming beam conditions and upgrades, i.e. post-LS1 LHC and ATLAS. It requires close collaboration with LHC machine experts who produce the beam-loss simulations in the LHC.
  Depending on the person(s) these two tasks can be separated or joined.
  Required knowledge: Running athena, analyzing ntuples, running FLUKA is an advantage
  FTE: 0.5 each task
  Contact: Mika Huhtinen, David Salek
3. Preparation of cosmic data
  ATLAS took a large amount of cosmic ray data in the past that mainly served for alignment studies. This data has not been part of the reprocessing campaigns, therefore it is necessary to check which data formats are available and produce AOD (or NTUP) using the latest software release. Part of this task is also to check the content of the muon collections and see what is the best reconstruction for studying cosmic ray muons (single beam mode or collisions), and which part of the tracking system gives the best handle on studying cosmic ray multiplicities, momenta or timing signatures.
  Required knowledge: Running athena.
  FTE: 0.5 each task
  Contact: Mika Huhtinen, David Salek

Area 5: Simulation Please see the current list of general open and qualification tasks
Required knowledge: strong interest to learn about how the ATLAS software works
Area 6: Data Quality
1. DQ/DCS calculator
  Description: This critical piece of software automatically uploads defects for detector sub-systems and magnets, based on their DCS data.The task involves development to:
  - check it works correctly in the CONDBR2 instance
  - follow up systems that have not properly implemented their Run 2 DCS
  - help systems to implement changes they need
  - connect it to the messaging service so as to catch problems automatically.
  Long term maintenance of the system is also part of the task. This will require some consultation with the relevant sub-system experts and review/update of the Run-1 logic.
  Knowledge: Python; some understanding of COOL and/or DCS would be helpful but can be learned
  FTE: Development 0.2-0.3 FTE; maintenance 0.1 FTE
  Contact: James Frost, Peter Onyisi, Sarah Demers, Anyes Taffard
  Task covered: Philipp Stole — Goettingen
2. Luminosity Visualisation and GRLs
  Description: The critical tools used in Run-1 DQ to summarise and display the luminosity effects and consequences were:
  - the DQ summary plots in the Atlas Run Query
  - the DQ summary scripts used to produce the official period luminosity and run information ( https://atlas.web.cern.ch/Atlas/GROUPS/DATAPREPARATION/DQSummary/ )
  - the GRLs, which combine the DQ defects and the luminosity information to generate GRLs and their associated luminosity.
  These tools require some maintenance and migration for Run-2 and support during data-taking.
  Has a strong overlap with the next task (Defect Visualization Tools); people may want to take both.
  Knowledge: Python
  FTE: 0.2 FTE (maintenance and support)
  Contact: James Frost, Peter Onyisi, Sarah Demers, Anyes Taffard
  Task covered: Jianming Qian+ student — Michigan
3. RPC service for Run-2 COOL lumi folders
  Description: Run 2 has a different implementation of luminosity information in the COOL database. We would like to make a centralized service that can be queried to provide the luminosity in a simple programmatic manner. The folder design for luminosity information is described here:
  https://twiki.cern.ch/twiki/bin/view/Atlas/Run2LuminosityFolders
  Knowledge: Python, close interaction with luminosity group
  FTE: 0.2
  Contact: James Frost, Peter Onyisi
4. History Tool
  Description: Maintenance and development of system that plots history of various monitored quantities. In particular try to integrate with new luminosity system (enabling things like monitoring Z cross section).
  Knowledge:
  FTE: 0.2 (maintenance)
  Contact: James Frost, Peter Onyisi, Sarah Demers, Anyes Taffard
5. DQ logbook
  Description: The DQ logbook is a central location for DQ run information, allowing discussion between related shifters and a more easily searchable/retrievable place than the elog.
  Knowledge: Python, JavaScript, AJAX, or other web programming experience
  FTE: 0.1-0.2 (maintenance)
  Contact: James Frost, Peter Onyisi, Sarah Demers, Anyes Taffard
  Task covered: Philipp Stole — Goettingen
6. Defect Visualisation Tools
  Description: The basic building blocks of GRLs are the DQ defects and associated logic. As we take data, and when generating GRLs, we need to understand why data are being rejected. Command line scripts exist already to summarize luminosity information for defects, compare different database tags, and indicate when specific defects were present. The development of a web interface for these tools would dramatically increase their utility. Other useful developments would include connecting them to the new Run-2 luminosity service and visualizing how high level virtual defect status is related to the underlying primary defects.
  Knowledge: Python
  FTE: Development 0.2-0.3 FTE
  Contact: James Frost, Peter Onyisi, Sarah Demers, Anyes Taffard
7. Unit Testing
  Description: This would include both command-line RTT tests for DQ infrastructure not tested during usual reconstruction tests (e.g. TCTs), such as histogram consistency and integrity, and also the adoption of a unit testing infrastructure for web-based tools.
  Knowledge: Shell scripting, python, C++
  FTE: 0.3
  Contact: James Frost, Peter Onyisi, Sarah Demers, Anyes Taffard
8. Core Defect Tools
  Description: These are the web interfaces and underlying libraries that shifters use to enter defects into the database, and which the DQ conveners use create new defects, prepare database tags, and so on. These are largely stable but are known to need maintenance from time to time as COOL versions change, usability improvements are identified, and so on.
  FTE: 0.1 (maintenance)
  Knowledge: Python; Javascript very helpful
  Contact: James Frost, Peter Onyisi
9. Histogram web display development
  Description: Tweaks to improve user experience of web display. Use Javascript plotting packages to allow interactive exploration of histograms.
  Knowledge: Python, Javascript
  FTE: 0.2
  Contact: James Frost, Peter Onyisi, Sarah Demers, Anyes Taffard
10. Performance monitoring
  Description: Monitor the performance (CPU and memory use) of the monitoring tools that run in reconstruction. Contact systems with this information and follow up on needed improvements.
  Knowledge: Strong interaction with reconstruction performance monitor (Antonio Limosani), C++
  FTE: 0.1-0.2
  Contact: James Frost, Peter Onyisi, Sarah Demers, Anyes Taffard
11. Web-based OHP
  Description: update for run 2 and maintain.
  FTE: 0.1-0.2
  Contact: Elizaveta Shabalina
  Task covered: Kareem, Mohammad - Goettingen

Area 7: B-Field
1. B-field control (non expert): Monitoring of the 1800 b-sensors which allow the determination of the magnetic field map: - control potential drifts of the b-sensors electronic. - Identify b-sensors with abnormal b-field measurement and/or abnormal temperature. - Implementation of an alarm to trigger a recalculation of the map (i.e: after shut-down, ECT position could change and induce new magnetic field configuration)
  Contact: Laurent Chevalier
2. B-field validation of the tile cal perturbations on the field map (non expert): The determination of these perturbations should be estimated by comparing the magnetic field in different magnets configurations (with solenoid & toroid on / off) with the calculation.
  Contact: Laurent Chevalier
3. Automatic validation of a new B-field map (expert): After a new magnetic field map has been built, an automatic chain should be implemented to minimize the map validation time.
  Contact: Laurent Chevalier

Area 8: Meta-data
1. Meta-data validation. Develop tools to validate in-file meta-data in nightly tests.
  Contact: David Malon

High priority tasks from Software and Computing group (updated July 23, 2014)

Contact: Richard Mount, Eric Lançon

(OT) Simulation tasks
Several physics simulation tasks, see more information above
Contacts : Phil Clark, Daniel Froidevaux

(OT) Job Transforms Coordinator
Maintain the job transform infrastructure and continue to develop features needed by the ATLAS production system and Tier-0.
Contacts : Graeme Stewart,Vakho Tsulaia

(OT) In-file Metadata Retrieval
Develop a new lightweight and scalable tool to retrieve metadata from ATLAS files, helping to optimise ATLAS production.
Contacts : Graeme Stewart,Vakho Tsulaia

(OT) Software Cleanups and Coding Rules Enforcement
Help to ensure that ATLAS coding rules are enforced and that ATLAS software builds cleanly and uses good coding conventions.
Contacts : Graeme Stewart,Vakho Tsulaia

(OT) Volunteer Computing. "Development of a monitoring interface (screensaver, etc.) on local PCs participating to the ATLAS@home project
Contacts : Simone Campana

High priority tasks from Muon Spectrometer project

https://twiki.cern.ch/twiki/bin/view/Atlas/QualificationList

High priority tasks from the Inner Detector project

https://twiki.cern.ch/twiki/bin/view/Atlas/InnerDetectorJobs.

High priority tasks from the Tile Calorimeter project

https://twiki.cern.ch/twiki/bin/view/Atlas/TileTasks

High priority tasks from the Forward Detectors project

Contact: Marco Bruschi

MB Trigger
Contact: Antonio Sidoti

https://twiki.cern.ch/twiki/bin/viewauth/Atlas/TriggerServiceTasks#Service_Tasks_in_Signature_Group

FWD MC
Contact: Antonello Sbrizzi

- Run Time Tester (RTT) and other validation tools for Forward Transport
- Comparison between Forward Transport and full Geant4 Beam Pipe
- D3PD and forward physics

FWD DATA QUALITY
Contact: Davide Caforio

STUDY OF DETECTOR STABILITY
Description: The task is aimed at implementing a set of tools and procedures for checking and monitoring the stability of the detector, both for physics data-taking and for calibrations.

The candidate will work on developing tools such as, e.g., histograms and trending plots showing the results of measurements as a function of different parameters such as time, luminosity, beam intensity etc. The candidate will also work on implementing automatic procedures in order to make these tools always available for both online monitoring and offline analysis.

During his work, the candidate will have the opportunity to understand the detector, to investigate luminosity measurement and forward physics thoroughly, and improve his skills in data analysis by using tools such as Root, C++, Castor, Athena etc.

ALFA
Contact: Karl Heinz Hiller

- checks of the detector and trigger performance
- maintenance of the byte stream converter and check of the data quality
- maintenance of DCS and DAQ
- software developement for alignment methods
- data processing for various data formats (D3PD,...)
- systematic investigations of the high beta* optics
- production of Monte Carlo samples

LUCID
Contact: Vincent Hedberg

- Calibration system for LUCID
- Calibration and analysis of fiber data
- Calibration of LUCID with W and Z data

LUCID MC
Contact: Antonello Sbrizzi

- Run Time Tester (RTT) and other validation tools
- LUCID info for FWD physics in D3PD + diffractive physics
- MC for phase II

ZDC
Contact: Daniela Macina

High priority tasks from Combined Performance Support(updated 12 April 2011)

Contact: Aleandro Nisati, Richard Hawkings

Validation
For each release, verify its performance by comparing a series of plots with a set of reference plots.
Contacts: Combined Performance Group Conveners

Development of special Monte Carlo tunes important for physics and performance group studies, particularly with underlying events.
- 8 FTE-months in 2011-2012.

Migrating old test-beam data so that it can be correctly read in later releases.
- 12 FTE-months in 2009-2010. (being filled)

Tau Performance: Investigation of Detector Level Effects on Tau reconstruction and identification (example: effects of dead OTX regions, bad FEB R/O, dead b-layer,...)
- 12 FTE-months till September 2012

Tau Performance: Reconstruction Algorithm Optimization studies: optimization of identification variables and their definitions, study of new potential identification variables; optimization of track selection for taus; calibration of the tau energy scale
- 18 FTE-months till September 2012

High priority tasks from the Upgrade projects

https://atlas.web.cern.ch/Atlas/Upgrade/Qualification.php