Authorship Committee

General issues


Current Members of the authorship committee are:

  • Davide Costanzo, Sheffield
  • Henri Bachacou, Saclay
  • Young-Kee Kim, Chicago

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)

In case of question please contact


Presently requests for exceptional authorship are handled by D. Costanzo, qualification start-ups by H. Bachacou, and end-of-qualifications by Y-K Kim.



The Committee is responsible for:

  • Implementation of the authorship policies

  • Correctness of the information stored in the authorship database

  • Management of the author list

The creation and maintenance of the ATLAS authorship database is done via web interfaces on this separate password protected page https://atglance.web.cern.ch/atglance/authorship/

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.

ATLAS Authorship policy

Rules for qualifying as an ATLAS author

For details see the Authorship Policy document PDF and the Team Leader Guideline for Qualification

  • 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.

Having satisfied the above, it is up to the person's ATLAS team leader to apply to the Chairperson of the Authorship Committee, stating the case for authorship in form of a short e-mail. Based on this case, the Chairperson will make a recommendation to the Spokesperson. The ultimate decision in all cases lies with the Spokesperson, who should consult with the AC and the Collaboration Board Chairperson in case of problems.

Qualification of non-PhD students:

  • No special qualification rules should apply to such students, they are treated as other ATLAS members as regards qualification, and it is up to the team leader if they are registered with a qualification start date.

  • The provisions of the authorship policy document (v7.3) section 3.4.2 paragraph 3 can apply to non-PhD students even if they do not qualify as full authors. It is the responsibility of team leaders to make such cases when appropriate, as stated in the authorship policy.

  • Technical qualification work done as a non-PhD student can be counted retrospectively as qualification work, in the normal manner for new ATLAS members registered for qualification in the Authorship Database

Requests for exceptional authorship for a particular paper

(See Section 3.4.2 of the Authorship Policy) 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. A non-ATLAS member already associated to ATLAS by Short-Term Association, and who 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. In all cases, the AC Chairperson will make a recommendation to the Spokesperson. The ultimate decision lies with the Spokesperson.

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. Please see the Team Leader Guide for details. 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.

In all of these cases, 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. The author list is frozen when the Second Draft is circulated; any changes made after this time will be in response to requests received earlier which are still going through this approval process. It is not possible to change the author list of a paper which has already been submitted to a journal. On the other hand, requests received before there is a first draft also create some minor difficulties (there is no list to add the person to yet, and sometimes the working group conveners do not know yet what the contributions of the person have been and cannot confirm them). The person making such an early request must remind the Authorship Committee about it again when a draft does circulate.

Current ATLAS Publication and Authorship Policy Documents

As approved by the CB during the ATLAS Week in Bern on 11 July 2008 the old publication policy document has been modified and been split up in two parts. Latest version of the documents are :

ATLAS authorship database: where and how to use

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 new 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.
  • Institute Representative: 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.

Hints for keeping the information in the database correct and up to date are provided on the InstituteRepsChecklist page.

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

  • 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.

A step by step guide to the qualification procedure

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. 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: after one year from the beginning of qualification, the IR will receive a reminder by email and will have to submit a report to the Authorship Committee for final approval of the qualification. Prior to contacting the Authorship Committee the IR must have contacted the relevant Project Responsible and discussed the qualification. Only if the Project Responsible agrees should the IR request qualification. The mail should also be copied to the relevant Project Responsible. If the qualification is delayed the Authorship Committee should also be informed.
  • Step 6: the Authorship Committee sets a qualification date after a final check with the relevant Project Responsible.

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

  • 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.
  • Note that the CB on 12 Nov 2013 approved a change to the policy that allows qualification on upgrade tasks for non-students during LS1. This policy will be reviewed towards the end of LS1
  • 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. Usually it is obvious (e.g. upgrade to Muon Small Wheel will be Upgrades and Muons), but since both Project Leaders will need to agree that it is completed, the one who does not sign off in Glance should be asked to e-mail the Authorship Committee to confirm that they also approve.
  • 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

High priority tasks from trigger group


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 NEW
      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 NEW
      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 NEW
      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:
      Knowledge: Python, close interaction with luminosity group
      FTE: 0.2
      Contact: James Frost, Peter Onyisi
    4. History Tool NEW
      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).
      FTE: 0.2 (maintenance)
      Contact: James Frost, Peter Onyisi, Sarah Demers, Anyes Taffard
    5. DQ logbook NEW
      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 NEW
      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 NEW
      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 NEW
      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 NEW
      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 NEW
      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 NEW
      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) 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


High priority tasks from the Inner Detector project


High priority tasks from the Tile Calorimeter project


High priority tasks from the Forward Detectors project

Contact: Marco Bruschi

MB Trigger
Contact: Antonio Sidoti


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

Contact: Davide Caforio

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.

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

Contact: Vincent Hedberg

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

Contact: Antonello Sbrizzi

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

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


Other relevant links and documents

Short-Term Associations (STA)

All information about the ongoing and past Short Term Associations can be found here.
Registration and access to Physics information for STA can be found here.

Other Authorship Links

Major updates:
-- - 30 Jun 2009 -- ManuelaCirilli - 2009-09-09 %RESPONSIBLE% DavideCostanzo1
%REVIEW% Never reviewed

-- DavideCostanzo1 - 2015-06-16

Edit | Attach | Watch | Print version | History: r5 | r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r1 - 2015-06-16 - DavideCostanzo1
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Sandbox All webs login

  • Edit
  • Attach
This site is powered by the TWiki collaboration platform Powered by PerlCopyright &© 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback