Presentation is loading. Please wait.

Presentation is loading. Please wait.

9/29/2004 1 CMS Detector Description: New Developments Ad Aerts Eindhoven University of Technology, Eindhoven, The Netherlands Martin Liendl CERN, Geneva,

Similar presentations


Presentation on theme: "9/29/2004 1 CMS Detector Description: New Developments Ad Aerts Eindhoven University of Technology, Eindhoven, The Netherlands Martin Liendl CERN, Geneva,"— Presentation transcript:

1 9/29/2004 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 9/29/2004 2 Introduction CMS Detector Description Database (DDD) CMS Detector Description Database (DDD) What is the DDD? What is the DDD? Requirements Requirements Model, Software Design, XML Model, Software Design, XML New Developments New Developments DDAlgorithm DDAlgorithm Oracle Database Oracle Database DDStreamer DDStreamer Integration into COBRA Integration into COBRA

3 9/29/2004 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 9/29/2004 4 Requirements One Definition Rule One Definition Rule Each part in the detector that is identical should only be defined once then positioned multiple times. 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. Each material should only be defined once, etc. Common Application Program Interface (API) for Reconstruction (ORCA), Simulation (OSCAR) and other CMS software. 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). Similar ease of access and portability of sources as compared to CMSIM (Geant3 based simulation of CMS).

5 9/29/2004 5 Requirements (continued) It must contain all information necessary to build up application specific internal representations of the detector. 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. 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. 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 generic way for client applications to extend the DDD. Provide a hierarchical querying and filtering mechanism. Provide a hierarchical querying and filtering mechanism.

6 9/29/2004 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 9/29/2004 7 DDD Domain Model From: CMS Week 3 Dec. 2002: DDD Deployment (M. Liendl)

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

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

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

11 9/29/2004 11 New Developments: DDAlgorithm Required by sub-detector software experts to enable the algorithmic positioning and creation of DDLogicalParts, DDSolids and etc. 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. 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 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. We need to allow DDD access to these algorithms with a clearly defined C++ interface and its corresponding XML. Solution: Seal Plugins Solution: Seal Plugins

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

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

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

15 9/29/2004 15 DDAlgorithm XML </Algorithm> x y z IGUANACMS output

16 9/29/2004 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 = mArgs[“mymap”]; vector = svArgs[“mystringvector”]; vector = vArgs[“vecdouble”]; Other examples:

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

18 9/29/2004 18 Relational Databases (continued) Reasons to revisit the relational database as a repository for the DDD Reasons to revisit the relational database as a repository for the DDD The online software project will be writing to relational databases. 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. 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. It seems logical that we make a map between the DDD and the relational database world.

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

20 9/29/2004 20 New: Streamer Can be used to write local output file of DDD objects. Can be used to write local output file of DDD objects. Can also be used to read in such files. 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. 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. 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. Not currently in use but is there as an option.

21 9/29/2004 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. 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. 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. 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 9/29/2004 22 Summary DDD has been moved into the COBRA framework. 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 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 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. A mechanism to stream out DDD objects has been available if users want to gain a slight time advantage at initialization.

23 9/29/2004 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 CHEP 2004 Poster: Ad Aerts; A database perspective on CMS data http://indico.cern.ch/contributionDisplay.py?contribId=225&sessionId=24&confId=0 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 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 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 2003 Poster: “CMS XML-based Detector Description Database System”; M. Case, A. Muhammad, M. Liendl, F. van Lingen; http://chep03.ucsd.edu/?day=posterhttp://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 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 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 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.pdfhttp://cmsdoc.cern.ch/documents/01/note01_057.pdf COBRA: http://cobra.web.cern.ch/cobra/ COBRA: http://cobra.web.cern.ch/cobra/http://cobra.web.cern.ch/cobra/ DDD: http://cmsdoc.cern.ch/cms/software/ddd/www/index.html DDD: http://cmsdoc.cern.ch/cms/software/ddd/www/index.htmlhttp://cmsdoc.cern.ch/cms/software/ddd/www/index.html LCG Applications: http://lcgapp.cern.ch/project/ LCG Applications: http://lcgapp.cern.ch/project/http://lcgapp.cern.ch/project/ SEAL Plugin documentation: http://seal.web.cern.ch/seal/ SEAL Plugin documentation: http://seal.web.cern.ch/seal/http://seal.web.cern.ch/seal/ BOOST: http://www.boost.org/ BOOST: http://www.boost.org/http://www.boost.org/ XML Technologies: http://www.w3c.org/ XML Technologies: http://www.w3c.org/http://www.w3c.org/ MDA: Model Driven Architecture at OMG (Object Management Group, Inc.) http://www.omg.org/mda/ MDA: Model Driven Architecture at OMG (Object Management Group, Inc.) http://www.omg.org/mda/ http://www.omg.org/mda/


Download ppt "9/29/2004 1 CMS Detector Description: New Developments Ad Aerts Eindhoven University of Technology, Eindhoven, The Netherlands Martin Liendl CERN, Geneva,"

Similar presentations


Ads by Google