Detector Geometry Developers Guide

Complete: 5

All developers in Geometry are expected to follow these guidlines.

Goal of this page

This page contains instructions for maintaining the detector description XML files or making new sets of XML files for the CMSSW releases. It is meant for "geometry developers" which may include writing C++ code or not. Some of the XML files use DDAlgorithm and some are generated from Geant4 code.

Future Note: With new (sub)detectors being developed and experimented for possible upgrades this will be used as a reference. It can and should be expanded with any new rules related to whoever is managing the geometry within those projects.

XML file management

Here are the rules during and after development within the Geometry subsystem in regard to DDL XML files. If anything is unclear, please contact IannaOsborne.

  • All XML data files reside in the data subdirectory of your package or of a more general package for the whole of CMS. For example Geometry/CMSCommonData/data contains cms.xml and other xml files common to the top three levels of the geometric hierarchy.

  • All configuration files to read a particular geometry live in one of two places; either
    1. in the package that a developer has responsibility for and thus controls the configuration file themselves
    2. or in the central Geometry/CMSCommonData/python directory for files which can and should be used by all users running more comprehensive physics software so they do not have to worry about which files need to be brought in.

  • Once a developer has tested their code using their own parameter set and configuration file they must inform IannaOsborne, SunandaBanerjee or MikeHildreth so that I can incorporate it into the central configuration file.

  • Additional important technical rules:
    1. All SpecPars must come after the parts have been defined (LogicalParts and PosParts). If SpecPars are in a file by themselves then in the configuration file the SpecPars file must be after or below the file that describes the parts.
    2. The same is true for DDL variables. If you specify a Constant, Parameter or other variable in one file and use it in another file, again, the files should be in sequence since it will fail to evaluate the first expression which refers to the as yet undefined variable.
    3. Please only get DDCompactView objects from XMLIdealGeometryESSource or XMLIdealGeometryESProducer do not have C++ code like this (this may now be actually prohibited by the interface changes made in 2009):
                  DDCompactView cpv;
               

Develop Geometry in CMSSW

These are the expected parameters for the XMLIdealGeometryESSource in the CMSSW framework.

name type description default allowed
geomXMLFiles vstring XML files D.D. None path+filename relative to CMSSW src, FileInPath is used on the list of files.
rootNodeName string set the D.D. graph root to this node cms:OCMS DDLogicalPart node name

Example parameter set file for the Ideal Geometry: http://cmssw.cvs.cern.ch/cgi-bin/cmssw.cgi/CMSSW/Geometry/CMSCommonData/python/cmsIdealGeometryXML_cfi.py?cvsroot=CMSSW

Example parameter set file for the Magnetic Field (note, the es_source name MUST be magfield):

magfield = cms.ESSource("XMLIdealGeometryESSource",
    geomXMLFiles = cms.vstring('Geometry/CMSCommonData/data/normal/cmsextent.xml', 
        'Geometry/CMSCommonData/data/cms.xml', 
        'Geometry/CMSCommonData/data/materials.xml',
        'Geometry/CMSCommonData/data/cmsMagneticField.xml', 
        'MagneticField/GeomBuilder/data/MagneticFieldVolumes_1103l.xml',
        'MagneticField/GeomBuilder/data/MagneticFieldParameters_07_2pi.xml'),
    rootNodeName = cms.string('cmsMagneticField:MAGF')
)

How to add a solid shape to the DetectorDescription subsystem.

How to add a DDSolid:

  1. ) DDSolidShapes.h: Add to DDSolidShapeNames. and DDSolidShape(index) and etc.
  2. ) DDSolid.h: Add interface and class that inherits from DDSolid. Add builder to factory.
  3. ) In DetectorDescription/Core: Add a DDI::yourshapename in yourshapename.h and yourshapename.cc. Look at another one as an example.
  4. ) Add it to DDLElementRegistry in Parser;
  5. ) Add it to Parser/src as it's own DDL processor if necessary, i.e. if the default element is not sufficient does not work for this one.
  6. ) Define it in DDLSchema so that it works.
  7. ) DDG4SolidConverter in SimG4Core/Geometry.

Code development and planning.

No meetings. All business done via hn-cms-geometry@cernNOSPAMPLEASE.ch.

Tutorials

Detector Description Language XML Tutorial

Review Status

Reviewer/Editor and Date (copy from screen) Comments
MichaelCase - 27 Jan 2006 page author
JennyWilliams - 31 Jan 2007 moved text here from SWGuideDetectorDescription and edited for SWGuide

Responsible: IannaOsborne
Last reviewed by: Reviewer

Edit | Attach | Watch | Print version | History: r13 < r12 < r11 < r10 < r9 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r13 - 2012-03-12 - IannaOsborne



 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CMSPublic All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback