CMS Detector Description: New Developments

1. CMS Detector Description: New Developments Ad Aerts Eindhoven University of Technology, Eindhoven, The Netherlands Martin Liendl CERN, Geneva, Switzerland Michael Case University of California, Davis and CERN Asif Jan Muhamad CERN & NUST Pakistan

2. Introduction • CMS Detector Description Database (DDD) • What is the DDD? • Requirements • Model, Software Design, XML • New Developments • DDAlgorithm • Oracle Database • DDStreamer • Integration into COBRA

3. What is the DDD? • “The Detector Description Database is the common source of detector description data for the CMS reconstruction and simulation software. • “It helps application clients to build up a consistent and coherent view of the detector and provides basic services to examine the detector structure and related data. • “It provides means of describing the detector (shapes, materials, geometrical hierarchies, application or sub-detector specific data). • “It is not: a tool for simulation, e.g. particle tracking; a tool for reconstruction; [or visualization.]” From: CMS Week 3 Dec. 2002: DDD Deployment (M. Liendl)

4. Requirements • One Definition Rule • Each part in the detector that is identical should only be defined once then positioned multiple times. • Each material should only be defined once, etc. • Common Application Program Interface (API) for Reconstruction (ORCA), Simulation (OSCAR) and other CMS software. • Similar ease of access and portability of sources as compared to CMSIM (Geant3 based simulation of CMS).

5. Requirements (continued) • It must contain all information necessary to build up application specific internal representations of the detector. • Will not be used as 'internal' representation of the detector within the applications. • Deal only with the ideal detector and not re-alignment or other conditions. • Provide a generic way for client applications to extend the DDD. • Provide a hierarchical querying and filtering mechanism.

6. Model Overview “The 'platform independent' domain model is the base for deriving implementation models. From implementation models the actual models are directly mapped or generated (MDA approach).” --From: CMS Week 3 Dec. 2002: DDD Deployment (M. Liendl) From: CHEP 2003 Poster

7. DDD Domain Model From: CMS Week 3 Dec. 2002: DDD Deployment (M. Liendl)

8. Repositories DDD API Model CMS Offline Software DDD Runtime System External Document Handling ORCA CMSIM - RZ CMSIM - ASCII DDD Services Converters OSCAR DD Language Interface Document Processing Documents DDD API Editors Detector Experts IGUANA Document Management FAMOS C++ External Code Expanded from CHEP 2003 Poster

9. DDD API Model (continued)

10. DDD Description Model - XML C++ Classes: class DDMaterial; class DDSolid; class DDTrap; class DDBox; … class DDLogicalPart; class DDSpecifics; class DDRotation; class DDTranslation; void Ddpos (DDLogicalPart parent, DDLogicalPart child, DDTranslation t, DDRotation r) Example XML: <LogicalPart name=“MF12”> <Trapezoid name="MF12" dz="94.7*cm “ …/> <rMaterial name=“Copper”/> </LogicalPart> <PosPart copyNo=“1”> <rParent name=“MF12”/> <rChild name="MA12"/> <rRotation name="rotations:000D"/> <Translation x="0*fm " y="1.5*cm " z="0*fm " /> </PosPart>

11. New Developments: DDAlgorithm • Required by sub-detector software experts to enable the algorithmic positioning and creation of DDLogicalParts, DDSolids and etc. • Especially in the case where detector symmetry makes this a very useful and fast way to build the geometry. • We do not want to store such sub-detector code with the main DDD when it is sub-detector specific. • We need to allow DDD access to these algorithms with a clearly defined C++ interface and its corresponding XML. • Solution: Seal Plugins

12. Repositories DDAlgorithm Design CMS Offline Software DDD Runtime System External Document Handling ORCA CMSIM - RZ CMSIM - ASCII DDD Services Converters OSCAR DD Language Interface Document Processing Documents DDD API Editors Detector Experts IGUANA Document Management FAMOS C++ External Code Expanded from CHEP 2003 Poster

13. DDAlgorithm Design (continued) DDD Runtime System External Document Handling Document defines parameters to pass to the Algorithm and specifies which algorithm by name DDD Services DD Language Interface Document Processing Documents Document Management <Algorithm name="hcal:DDHCalBarrelAlgo"> C++ External Code Via SEAL Plugin (DDAlgorithm) DDD calls specific plugin via the DDAlgorithm interface. The plugin makes Solids and LogicalParts and positions them in the parent

14. Name will be used to get values in the algorithm. Can use other parameters defined in XML. DDAlgorithm XML Name of SEAL plugin defined by the DDAlgorithm sub-class General Form: <Algorithm name=“global:testAlgorithm”> <rParent name=“thisdoc:myParentVolume”/> <String name=“myName” value=“myValue”/> <Numeric name=“numToys” value=“5”/> <Vector name=“toyColors” numEntries=“[numToys]” type=“string”> blue, red, green, yellow, magenta </Vector> <Map name=“toyNumbers” type=“numeric” nEntries=“[numToys]”> A=3*[maindoc:Var1]/[thisdoc:Var1], B=2*[maindoc:Var1]/[thisdoc:Var2], C=2*[maindoc:Var1]/[thisdoc:Var3] </Map> </Algorithm>

15. DDAlgorithm XML <Algorithm name=“global:linear"> <rParent name=“example:world"/> <Numeric name=“start” value=“1”/> <Numeric name=“incr” value=“1”/> <Numeric name=“end” value=“5”/> <String name=“child” value=“example:box”/> <Numeric name=“phi” value=“0*deg”/> <Numeric name=“theta” value=“90*deg”/> <Numeric name=“delta” value=“0.5*m”/> </Algorithm> y x z IGUANACMS output

16. DDAlgorithm C++ DDTranslation global_linear::translation() { double theta = nArgs["theta"]/rad; double phi = nArgs["phi"]/rad; double delta = nArgs["delta"]; DDTranslation direction( sin(theta)*cos(phi), sin(theta)*sin(phi), cos(theta) ); return (double(curr_)*delta)*direction; } int startCount = int (nArgs[“start”]); int increment = int (nArgs[“incr”]); int endCount = int (nArgs[“end”]); string childName = sArgs[“child”]; map<string, double> = mArgs[“mymap”]; vector<string> = svArgs[“mystringvector”]; vector<double> = vArgs[“vecdouble”]; Other examples:

17. Relational Databases • Previous relational database work was done with MySQL and Java. (A. Muhammad & M. Liendl)

18. Relational Databases (continued) • Reasons to revisit the relational database as a repository for the DDD • The online software project will be writing to relational databases. • DDD gives a hierarchical index of the detector geometry and is accessed by client software that also needs conditions, calibrations, slow controls and other online databases. • It seems logical that we make a map between the DDD and the relational database world.

19. New: Oracle Database Schema • Oracle Schema (A. Aerts & M. Liendl) • Closely aligned with the DDD Domain Model. • Rigorous application of DB design principles. • Data • Loaded from the DDD using C++ and Python. • Technology • Oracle 9i • Intended as a skeleton on which to hang conditions, alignment, calibration and slow controls data. • See poster session “A Database Perspective on CMS Data”

20. New: Streamer • Can be used to write local output file of DDD objects. • Can also be used to read in such files. • COBRA can be triggered using a SimpleConfigurable to write (DDD:WriteCacheFile) and read (DDD:UseCacheFile) the geometry as files. • Speeds up building of initial DDD transient store. This is faster than the XML parsing. • Not currently in use but is there as an option.

21. New: COBRA Integration • As you may have noticed the DDD is now a component of COBRA and no longer on its own as a project. • Software is released with COBRA releases. XML Sources are currently in the Geometry project and this is also where the DDAlgorithms reside at the moment. • This is still in accordance with our original requirement that CMS client software rely on a common API to the geometry information and integration with COBRA simplifies some aspects of software management.

22. Summary • DDD has been moved into the COBRA framework. • A new way of integrating algorithms into the DDD has been developed using the SEAL Plug-in mechanism and will be used in the next major Geometry release. • A new effort is on-going to correlate the DDD with slow controls, conditions and calibration relational databases. In this case a new database model was developed with a more rigorous database design methodology. • A mechanism to stream out DDD objects has been available if users want to gain a slight time advantage at initialization.

23. References • CHEP 2004 Poster: Ad Aerts; A database perspective on CMS data http://indico.cern.ch/contributionDisplay.py?contribId=225&sessionId=24&confId=0 • CMS Note 2003/31 “Migration of XML Detector Description Data and Schema to a Relational Database” ; Asif Jan Muhammad, Martin Liendl, Frank van Lingen, Arshad Ali, Ian Willers; http://cmsdoc.cern.ch/documents/03/note03_031.pdf • CHEP 2003 Poster: “CMS XML-based Detector Description Database System”; M. Case, A. Muhammad, M. Liendl, F. van Lingen; http://chep03.ucsd.edu/?day=poster • CHEP 2001 Presentation: “The Role of XML in the CMS Detector Description”; M. Liendl, F. van Lingen, M. Case, T. Todorov, P. Arce, A. Furtjes, V. Innocente, A. de Roeck; http://www.ihep.ac.cn/~chep01/presentation/8-054.pdf • CMS Note-2001/057 “Detector Descripiton Domain Architecture & Data Model”; M. Case, M. Liendl, F. van Lingen; http://cmsdoc.cern.ch/documents/01/note01_057.pdf • COBRA: http://cobra.web.cern.ch/cobra/ • DDD: http://cmsdoc.cern.ch/cms/software/ddd/www/index.html • LCG Applications: http://lcgapp.cern.ch/project/ • SEAL Plugin documentation: http://seal.web.cern.ch/seal/ • BOOST: http://www.boost.org/ • XML Technologies: http://www.w3c.org/ • MDA: Model Driven Architecture at OMG (Object Management Group, Inc.) http://www.omg.org/mda/