A Common Naming and Numbering Scheme for ALICE L. Betev, P. Chochula ALICE week Geneva, June 16

2 A Common ALICE Naming and Numbering Scheme 16 June 2003 Acknowledgements: How many naming and numbering schemes? Part identification and description of functional position Rules and examples Part identification scheme Functional position identification scheme Considerations Toward a naming and numbering scheme for ALICE Outline This summary is a result of numerous discussions between: Lennart Jirden, PierLuigi Barberis, Peter Chochula and Latchezar Betev

3 A Common ALICE Naming and Numbering Scheme 16 June 2003 How many naming schemes? Simple answer – as few as possible Extended answer – as many as needed to describe fully the detector both for hardware and software purposes A problem – there is no currently existing universal naming scheme, which meets everybodys needs The talk outlines a proposal for a complementary set of two schemes, which we believe fulfil the current needs of ALICE

4 A Common ALICE Naming and Numbering Scheme 16 June 2003 Naming and numbering Generic type – used for part identification Advantages: Quasi-universal - good for almost any physical object (part) Everybody is forced to use it, no deviation possible Small group can define the rules – no need to coordinate with the detector groups Good for databases, common search methods, traceability Existing examples (multitude of industry standards) Disadvantages: Representation is not human-friendly The naming logic is counterintuitive There is always a case, which cannot be described Need for conversion tables to map the correspondence of the part ID to the functional position in a detector The use in every group should be documented

5 A Common ALICE Naming and Numbering Scheme 16 June 2003 Intuitive type – defines the functional position of a detector part. The names are derivatives of a given detector name, logically following the detector construction. Advantages: Human-friendly names – from the label it is easy to guess the detector part Design of names usually follows the detector construction and software logic Developed by experts, ideally suitable for a given detector Disadvantages: Inflexible – a scheme for one detector almost never fits another The hardware and software names sometimes differ Need for conversion tables for hardware to software name relations External restrictions to a naming scheme: Software limitations - GEANT 3 names Hardware limitations – sticker size (for a small part)

6 A Common ALICE Naming and Numbering Scheme 16 June 2003 Example of generic naming Widely used in industry, ideal for unique part numbering, adopted by ATLAS/CMS Definition: 14 fields, alphanumeric, position dependent information Rules: Fixed prefix followed by a sequential number. The prefix is predetermined and only the sequential number can be used freely

7 A Common ALICE Naming and Numbering Scheme 16 June 2003 The name of a part is unique and does not depend on where it will be installed in a detector A naming system like this with a private definition by every detector group is already used in the DCDB (or other database).

8 A Common ALICE Naming and Numbering Scheme 16 June 2003 Example of intuitive naming Defines the functional position within a detector and does not depend on a given detector component ITS Silicon Pixel Detector layout: -The numbering follows the detector construction, on-line convention and complies to the information provided in the event header - The numbering for off-line reconstruction is at present different, but there is no logical reason not to use identical convention for both (not necessarily true for other detectors)

9 A Common ALICE Naming and Numbering Scheme 16 June 2003 Hierarchical tree of ITS SPD components – the functional position naming convention can be derived fully from it to the deepest possible level Side Sector Half Stave Readout ChipAnalog Pilot Digital Pilot GOLSensorTemp. Probe Group Temp Probe DACPixel MaskTestTH0TH1TH2

10 A Common ALICE Naming and Numbering Scheme 16 June 2003 Example for a deepest component functional position: pixel register TH0 AxxxTH0A AxxxTH0A DetectorRes. ComponentSIDSECHSA1ROWCOL Example for a pixel chip (2 levels up in the hierarchy): AxxxA1A538 AxxxA1A538 DetectorRes. ComponentSIDSECHSA1unused This description is detector specific and will differ for every detector The SPD example is taken from an extended document, containing a full description of the entire detector (author P. Chochula).

11 A Common ALICE Naming and Numbering Scheme 16 June 2003 Considerations The Generic naming scheme is needed for unique part identification, however it is not suitable for detector description since it is one dimensional This function is fulfilled by the hierarchical Intuitive naming scheme, which describes the functional position of every component and can be of several dimensions (usually 2) A given functional position can be taken by many components of the same type (parts replacement), which should carry a generic number for traceability The two schemes should be kept separate and the relation should be assured only through mapping tables Similar mapping tables are needed for the Intuitive naming scheme in case the hardware and software names differ From all of the above F we need extensive documentation for each scheme and detector

12 A Common ALICE Naming and Numbering Scheme 16 June 2003 Considerations 2 (enter the cables, readout) Previous set of considerations is only regarding the detectors Special case – cables: Can have one generic part number Are connecting at least two functional positions May be passing through patch panels (several pieces), splitter, Ethernet hub …. The cables have to be treated as a part of the Intuitive naming scheme for each detector (one more level of hierarchy) allowing for one cable name to have several parts Yet another part of a detector – its readout in DAQ: Unique part ID One functional position Same treatment as for a detector part Did we forget something?

13 A Common ALICE Naming and Numbering Scheme 16 June 2003 Conclusions ALICE experiment will need two naming schemes: Generic for part ID Intuitive for functional position For the generic scheme we can produce the document outlining the rules and logic in a relatively short time centrally The intuitive scheme for every detector has to be outlined by the detector groups Only very weak rules: length of code string, general codes for detector names, can be declared centrally Both the schemes and their application have to be documented extensively We need a central body of experts, under the Technical Coordination, responsible for: Definition of rules for the generic scheme Collection of information from detector experts on the intuitive scheme We have a good document base to work on both schemes simultaneously This work should start immediately to avoid private definitions and the resulting incompatibility (already there to a certain degree)