Calorimeter Review Report (Draft)

Introduction

This review was held between 16 June (kickoff meeting) and 28 June 2005 (closeout meeting). The detailed review page can be found at CalorimetryLArAndTile.

Goals

The common goals for all reviews are:

• Encourage some self-analysis - what did the developers think that they were required to do, and did they deliver?
• Get some client/user feedback on :
  • Ease of use (documentation, examples, user support,...)
  • Performance ( Did it work? Did it work well enough? What is the testing policy ?)
  • Requirements (what was thought to be missing?)
• What were the lessons learned from DC2 and from CTB?
• Trigger some forward planning. In the light of the review, enable the sub-system coordinateurs to formulate a plan for future developement.

Scope

The review covered common calorimetry software, as well as software specific to the liquid argon calorimeter and to the tile calorimeter.

Findings

• The two calorimeter groups have adopted a common approach to software development, using common base classes, event data model, Algorithms and Tools whereever possible. The individual calorimeters are then treated as specializations of these common classes.

• it is not easy from the downstream EDM to determine the input quality of the data and whether it includes dead or noisy channels.

• The calorimeter group have developed their own tools for tracking long term trends in calibrations and do not feel that global tools are needed.

• Both the topological and sliding window clustering algorithms are supported. Physics performance will be used to decide whether the baseline one of these. The size overhead is small.

• Zero suppression at the ROD level is considered dangerous. Data size has been reduced to 0.5 MB/event for raw data, which meets the computing model goals.

• Lack of navigation from the ESD to ByteStream restricts the ability to use physics analysis tools to access e.g. ADC information.

• Only e-gamma is currently running in RTT. A common calorimetry strategy is planned and much should be inplace for release 11.0.0.

• Database access in the HLT environment is still an unresolved issue.

• A uniform mechanism for handling error messages and exceptions within the TDAQ, HLT and offline is needed.

Comments

• Many committee members commented on the good documentation, both in quantity and quality.

• The strength of the calorimeter software group has meant that in several cases they have been involved in early proof-of-principle prototypes, which later incorporated some modification before being adopted more widely. Thus in some cases more work is needed by this community in order to match the final common software.

• The calorimetry coordinators suggest that validation requires better organization at the ATLAS level. Some of the tests that are proposed as part of the Computing System Commissioning address this, but it still needs more overall coordination and division into components so as to isolate problems.

• There should be one source of detector description for both simulation and reconstruction.

• It's not clear if alignment and deformations are covered by GeoModel.

• The committee encourages the planned use of RTT by release 11.0.0 for more testing.

• The level of agreement between G4 data and the data is still under investigation.

• The review committee support the ongoing evaluation of COOL by the TileCal and the plan to use it for the upcoming LAr commissioning.

• Early experience from analysis shows that the current limit of 50 events per file is inefficient and will result in many small files. The file merging at the AOD level helps, but things would better if it were applied upstream. This needs to be addressed globally within ATLAS.

• Several recommendations that follow are apply more broadly than just to the calorimetry, but rather to the ATLAS software as a whole.

Recommendations

Calorimeter-specific Recommendations

• C1. Further practical documentation should be provided. The current Missing Et documentation which documents algorithms, containers and job options could act as an example. Another desirable feature, as found in the Atlas workbook, is to have all the documentation in one place. This effort should be co-ordinated with the physics analysis tools group.

• C2. There should be an increased emphasis on documentation via Doxygen. The very detailed use of Doxygen by the Inner Detector and Tracking groups could act as an example.

• C3. The review panel recognises the current work on Alignment and Co-ordinate systems, and Detector description, and encourages it to continue.

• C4. The calorimeter code should plan on migrating to GeoModel for detector description for both reconstruction and simulation by release 11.

• C5. The calorimeter code should use the timedHitContainer for digitisation to decrease long term maintenance load.

• C6. A tight coupling should be established between the calorimeter algorithms, the Calibration and Alignment groups (DC3), and cosmic commissioning.

• C7. A quality factor should be provided for calorimeter reconstruction objects which provides the fraction of bad/dead cells.

• C8: The calorimeter should develop a plan for a full migration to COOL from other technologies (e.g. NOVA) for both commissioning and ongoing CTB work.

General ATLAS Recommendations

• G1. The Atlas code should be validated using tools such as the RunTimeTester. The validation should be done at a detailed level that permits problems to be identified once detected. This level of validation will allow the source of the problems to be found.

• G2. Validation should include computing performance metrics as well as physics metrics.

• G3. An event file merging phase should be added early to the Tier 0 processing chain to reduce the necessity of dealing with numerous small files.

• G4. It is recommended to access condition data via the IOVSvc and not through the BeginRun incident. The IOV service should be thoroughly tested. The subsystem used for these tests need not be the calorimeter.

• G5. There should be an effort to co-ordinate error reporting among the TDAQ, HLT and core services.

• G6. The Data Management group should provide a concrete plan for back navigation from ESD to byte stream by release 12.

• G7. A study should be performed to better understand how ATLAS should react to hardware failure ranging from a few channels to substantial detector failure. The physics groups will be involved in this study. It is likely that some detector components (ranging from a few channels to substantial portions of a subsystem) will fail during data taking. Software needs to be developed to be able to write and access information on the state of the hardware and the reconstruction software needs to be prepared to make adequate use of this information

Appendix A: The Review Committee

Authors:

• Srini Rajagopalan
• David Rousseau
• Alexander Solodokov

Chairman/Moderator:

• David Quarrie

Secretary:

• Peter Sherwood

Reviewers:

• Jerome Schwindling
• Richard Teuscher
• Stephane Willocq
• Martine Bosman
• Paolo Calafiura
• Fabiola Gianotti (ex. officio)
• Dario Barberis(ex. officio)

-- DavidQuarrie - 04 Jul 2005