CMS Detector Description: New Developments Ad Aerts

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 9/29/2004 1

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

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) 9/29/2004 3

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). 9/29/2004 4

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. 9/29/2004 5

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) 9/29/2004 From: CHEP 2003 Poster 6

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

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

DDD API Model (continued) 9/29/2004 9

DDD Description Model XML 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 9/29/2004 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) 10

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 subdetector specific. We need to allow DDD access to these algorithms with a clearly defined C interface and its corresponding XML. Solution: Seal Plugins 9/29/2004 11

DDAlgorithm Design DDD Runtime System ORCA OSCAR IGUANA DDD Services Document Processing External Document Handling CMSIM - RZ CMSIM - ASCII Converters Documents Document Management Editors Detector Experts CMS Offline Software FAMOS Repositories Expanded from CHEP 2003 Poster 9/29/2004 C External Code 12

DDAlgorithm Design (continued) DDD Runtime System DDD Services Document Processing Document Management DDD calls specific plugin via the DDAlgorithm interface. 9/29/2004 External Document Handling Document defines parameters to pass to the Algorithm and specifies which algorithm byDocuments name Algorithm name "hcal:DDHCalBarrelAlg C External Code Via SEAL Plugin The plugin makes(DDAlgorithm) Solids and LogicalParts and positions them in the parent 13

DDAlgorithm XML General Form: Name of SEAL plugin defined by the DDAlgorithm sub-class 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 Name will be Map name “toyNumbers” type “numeric” used to get nEntries “[numToys]” values in the A 3*[maindoc:Var1]/[thisdoc:Var1], algorithm. B 2*[maindoc:Var1]/[thisdoc:Var2], C 2*[maindoc:Var1]/[thisdoc:Var3] Can use other /Map parameters /Algorithm defined in XML. 9/29/2004 14

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 9/29/2004 15

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; } Other int startCount int (nArgs[“start”]); examples: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”]; 9/29/2004 16

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

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. 9/29/2004 18

New: Oracle Database Schema Oracle Schema (A. Aerts & M. Liendl) Data Loaded from the DDD using C and Python. Technology Closely aligned with the DDD Domain Model. Rigorous application of DB design principles. 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” 9/29/2004 19

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. 9/29/2004 20

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. 9/29/2004 21

Summary DDD has been moved into the COBRA framework. A new way of integrating algorithms into the DDD has been developed using the SEAL Plugin 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. 9/29/2004 22

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/ LCG Applications: http://lcgapp.cern.ch/project/ DDD: http://cmsdoc.cern.ch/cms/software/ddd/www/index.html 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/ 9/29/2004 23