DB Geometry

Complete: 4

Goal of this page

The main goal of this page is to provide instructions for loading the database geometry objects or payloads into the conditions database. At the end of this process the objects are ready to be tested then signed off on and a request is made to the alca hypernews

The master detector description information is in XML files in the Geometry subsystem of every CMSSW release. Various scenarios of the geometry of CMS as described in XML files are loaded into a database and are accessed via the conditions infrastructure. The different sets of XML files (scenarios) are proposed by software developers and physicists responsible for the description of the particular detector configuration. The proposals are tested and if approved by the Level 2 software managers are loaded into the database as any other condition.

Step 1 Gather the Modifications

The first step is to gather together the code to be used to fill the database. The critical pieces are the XML files and the cfi files which specify which XML files to include in each scenario. One also has to specify a version to use for the other code used to fill the database. As I understand it, in the past this has been done by the experts for each particular part of the detector specifying a particular Integration Build to use.

The xml files are in the packages in the Geometry subsystem. The cfi file defines an ESSource which is used to retrieve the data from the xml files. An example is XMLIdealGeometryESSource which is defined in Geometry/CMSCommonData/python/cmsIdealGeometryXML_cfi.py which is then used (through another file, the _cff.py file) in a Configuration/StandardSequences/python file such as Configuration/StandardSequences/python/GeometryIdeal_cff.py. This file brings together not only the XML files but the other sources required to build the Geometry for Reconstruction and Simulation.

This may change with time. Currently, we have the following scenarios: Extended, ExtendedGFlash, LiMax, LiMin, X0Min, X0Max, Ideal.

Step 2 Test the New Code

At this point you can run the validation script described at the link below which runs DOMCount and DDErrorReport, writes the databases into a local database, and compares that local database to the XML files.

XML to Database DDD validation

Make sure the script is run for each of the scenarios that are being modified. You will need to check out all the packages with modifications to ensure the modifications are included in the test.

In addition to running the script above, one can run the unit tests that will run in the IB by checking out all the packages with modifications, and also the packages DetectorDescription/Core, DetectorDescription/Parser, and DetectorDescription/RegressionTest. Give the command "scram b runtests" from the top level of the working area. Then look for the string ERRORS in the output. If it is not there then the unit tests pass. If it is there, then you need to debug the problem.

Step 3 Create the Payloads

Here is the quick recipe.

cmsrel CMSSW_7_1_0_pre5
cd CMSSW_7_1_0_pre5/src
cmsenv
git cms-addpkg CondTools/Geometry
scram b
cd CondTools/Geometry/test
cp writehelpers/* .
./createPayloads.sh 71YV1

There are some things in the scripts this uses that are somewhat fragile. It is probably a good idea to really follow those steps exactly and start by creating a new working area each time.

You will need to know which release to use as a base release. In addition to checking out the CondTools/Geometry package, you will need to check out any other packages with modified code.

The argument to the createPayloads script is the tag you want to be used. The first 3 characters specify the release series these payloads are intended to be used with first. The last 2 characters are just a version number to be used in case more than one set of payloads is needed. Start with 1 and increment the number for each new set of payloads.

If everything goes fine you will see output without exception messages and all payloads will have non zero length.

The createPayloads script does the following:

  1. Edits the metadata files (if any) to include the proper tag.
  2. Reads all the little XML files for the extended scenario and writes one big XML file.
  3. Reads the big XML file, converts it to a blob, and writes that the to the local database in the file myfile.db. In parallel rereads the little XML files and fills the DDCompactView and then from that fills the reco parts of the database in myfile.db.
  4. Repeats the steps above for each scenario, except the reco parts of the database are only filled once not for each scenario.
  5. Splits the different pieces put in to myfile.db into separate database files. These are the payloads.

These are the payloads that should be created:

-rw-r--r--. 1 yana zh    61440 Jun  2 10:31 CASTORRECO_Geometry.db
-rw-r--r--. 1 yana zh    57344 Jun  2 10:31 CSCRECODIGI_Geometry.db
-rw-r--r--. 1 yana zh   151552 Jun  2 10:31 CSCRECO_Geometry.db
-rw-r--r--. 1 yana zh   208896 Jun  2 10:31 CTRECO_Geometry.db
-rw-r--r--. 1 yana zh   688128 Jun  2 10:31 DTRECO_Geometry.db
-rw-r--r--. 1 yana zh  2015232 Jun  2 10:31 EBRECO_Geometry.db
-rw-r--r--. 1 yana zh   495616 Jun  2 10:31 EERECO_Geometry.db
-rw-r--r--. 1 yana zh  2355200 Jun  2 10:31 EPRECO_Geometry.db
-rw-r--r--. 1 yana zh  1081344 Jun  2 10:31 GeometryFileExtended2017.db
-rw-r--r--. 1 yana zh    61440 Jun  2 10:31 HCALParameters_Geometry.db
-rw-r--r--. 1 yana zh   376832 Jun  2 10:31 HCALRECO_Geometry.db
-rw-r--r--. 1 yana zh   536576 Jun  2 10:31 RPCRECO_Geometry.db
-rw-r--r--. 1 yana zh  1294336 Jun  2 10:31 TKExtra_Geometry.db
-rw-r--r--. 1 yana zh    57344 Jun  2 10:31 TKParameters_Geometry.db
-rw-r--r--. 1 yana zh  6356992 Jun  2 10:31 TKRECO_Geometry.db
-rw-r--r--. 1 yana zh    57344 Jun  2 10:31 ZDCRECO_Geometry.db

For each database file there should also be a corresponding metadata file. If it does not exist, the uploadConditions.py script in the path will help to create it. (The script is also in CondCore/Utilities/scripts.) Here is what you see if you examine one:

$ more GeometryFileExtended2017.txt 
{
    "destinationDatabase": "oracle://cms_orcon_prod/CMS_COND_GEOMETRY_000", 
    "destinationTags": {
        "XMLFILE_Geometry_81YV3_Extended2017_mc": {
            "dependencies": {}, 
            "synchronizeTo": "offline"
        }
    }, 
    "inputTag": "XMLFILE_Geometry_81YV3_Extended2017_mc", 
    "since": null, 
    "userText": "Extended 2017 geometry with updated Hcal 2016a"
}

At this point you are ready to move on to the next step, but here is some additional information that may be helpful if you need to debug problems.

At this point none of the payloads have labels. The reco payloads will never have labels, but the others will get a label before being put into the ORACLE database that is referenced by the global tag. This is important if you try to write a test program to access the data in these local databases. You will need the label to get them from ORACLE but not from these local databases.

It is possible to examine the database files directly using sqlite3. Here are some examples: OutputOfSomeSqlite3Interactions.txt

You can examine the script in the file CondTools/Geometry/test/writehelpers/createPayloads.sh and see or run the individual steps used in this process. There are comments in the script to explain what is going on.

Step 4 Upload to the Prep Database

https://twiki.cern.ch/twiki/bin/viewauth/CMS/UserTagsInTheGTProcedure

For each payload that changed, give this command:

uploadConditions.py <sqlitefile>

This script should be in the path. More details here: https://twiki.cern.ch/twiki/bin/view/CMS/ConditionUploader The script will print out the input tag. The destination tag is usually the same as the input tag.

One determines which payloads have changed by running the validation script defined here: DDD versus DataBase Validation. Run with the latest global tag and with all the changes you are using in the local area. Any payload the validation script gives a WARNING about finding differences needs to be uploaded. The run with Extended tells you about the extended scenario and all the reco payloads. You would have to rerun the script to check the other simulation scenario payloads.

These links lead to more information should you ever need to investigate a problem:

Step 5 Test the Payloads

Next we test the payloads in the Prep database. One test reads the payloads in the Prep database and compares that to the local XML files and also local sqlite versions of the database. In the other test, we run the RelVals using the new payloads. For both cases, the easiest way to do this is to make a temporary local global tag database that points to the Prep database instead of the production database.

Make a Candidate Global Tag Queue

For testing purposes one should make an unofficial candidate global tag queue that will refer to the new payloads in the Prod database. This will be used for testing only and then deleted.

The official instructions on how to make a global tag are here: Candidate Global Tag Queue

Run the Comparison Test

To test the payloads in the prep area you will want to rerun the test described here: DDD versus DataBase Validation.

Make sure you use the global tag database you created based on the instructions in the previous section. Use a global tag in that database that contains all the geometry payloads. The "mc" global tag is a good one. Only one global tag need be tested.

Repeat this test for each scenario.

This will compare the uploaded payloads in the prep area to the local area and verify they are correct. This time no differences should be found or something is wrong.

You could repeat this test after an official global tag is made that contains the new payloads if you are being really careful.

Run the CMS.RelVal Tests

First one should follow the instructions above and make a global tag database including all the global tags used in the CMS.RelVal tests for the particular release being used in the test. Then continue with the step below in the working area that contains this database.

addpkg Configuration/PyReleaseValidation
addpkg Configuration/StandardSequences
cp Configuration/PyReleaseValidation/data/*.txt .

Edit one file. The output of diff after the edit is below:

RCS file: /cvs_server/repositories/CMSSW/CMSSW/Configuration/StandardSequences/python/FrontierConditions_CMS.GlobalTag_cfi.py,v
retrieving revision 1.9
diff -r1.9 FrontierConditions_CMS.GlobalTag_cfi.py
7c7
<     connect = cms.string('frontier://FrontierProd/CMS_COND_31X_GLOBALTAG'),
---
>     connect = cms.string('sqlite_fip:myglobaltags.db'),

Then run the test.

scram b
runTheMatrix.py >& matrix.log &

When the test is done several hours later check the log file as follows.

grep ret matrix.log

You should see only lines that look like this:

 ... ret:  0

If any tests returned nonzero values, then you will need to debug the problem. Normally the place to start is in the subdirectory that was created for the test that failed, which will contain a more detailed log for the specific test.

There are several alternative ways you can get the CMS.RelVal and other tests to run on the new payloads. Here is one relatively easy alternative. Instead of editing the file FrontierConditions_CMS.GlobalTag_cfi.py, you can modify the conditions argument to the cmsDriver command to look something like this: "--conditions MC_39Y_V3::All,sqlite_fip:./myglobaltags.db". You need to use the global tag appropriate for the test. You would have to replace all of the conditions arguments in the *.txt files used in the CMS.RelVal tests that contain the cmsDriver commands. The next section mentions some other alternatives. All the approaches are equivalent in the end, it is only a question of which approach you find more convenient as to which is best.

Alternative Ways to Access the Geometry from Database

How to access the geometry directly from CondDB is already explained here

You can cmsRun geometrytest_local.py or using the information in there in a configuration file to access this local version of the database, specifically this source (the tag names need to be edited):

process.load("CondCore.DBCommon.CondDBSetup_cfi")
process.PoolDBESSourceGeometry = cms.ESSource("PoolDBESSource",
                               process.CondDBSetup,
                               timetype = cms.string('runnumber'),
                               toGet = cms.VPSet(cms.PSet(record = cms.string('GeometryFileRcd'),tag = cms.string('XMLFILE_Geometry_TagXX')),
                                            cms.PSet(record = cms.string('IdealGeometryRecord'),tag = cms.string('TKRECO_Geometry_TagXX')),
                                            cms.PSet(record = cms.string('PGeometricDetExtraRcd'),tag = cms.string('TKExtra_Geometry_TagXX')),
                                            cms.PSet(record = cms.string('PTrackerParametersRcd'),tag = cms.string('TKParameters_Geometry_TagXX')),
                                            cms.PSet(record = cms.string('PEcalBarrelRcd'),   tag = cms.string('EBRECO_Geometry_TagXX')),
                                            cms.PSet(record = cms.string('PEcalEndcapRcd'),   tag = cms.string('EERECO_Geometry_TagXX')),
                                            cms.PSet(record = cms.string('PEcalPreshowerRcd'),tag = cms.string('EPRECO_Geometry_TagXX')),
                                            cms.PSet(record = cms.string('PHcalRcd'),         tag = cms.string('HCALRECO_Geometry_TagXX')),
                                            cms.PSet(record = cms.string('HcalParametersRcd'), tag = cms.string('HCALParameters_Geometry_TagXX')),
                                            cms.PSet(record = cms.string('PCaloTowerRcd'),    tag = cms.string('CTRECO_Geometry_TagXX')),
                                            cms.PSet(record = cms.string('PZdcRcd'),          tag = cms.string('ZDCRECO_Geometry_TagXX')),
                                            cms.PSet(record = cms.string('PCastorRcd'),       tag = cms.string('CASTORRECO_Geometry_TagXX')),
                                            cms.PSet(record = cms.string('CSCRecoGeometryRcd'),tag = cms.string('CSCRECO_Geometry_TagXX')),
                                            cms.PSet(record = cms.string('CSCRecoDigiParametersRcd'),tag = cms.string('CSCRECODIGI_Geometry_TagXX')),
                                            cms.PSet(record = cms.string('DTRecoGeometryRcd'),tag = cms.string('DTRECO_Geometry_TagXX')),
                                            cms.PSet(record = cms.string('RPCRecoGeometryRcd'),tag = cms.string('RPCRECO_Geometry_TagXX'))
                                            ),
                               connect = cms.string('sqlite_file:myfile.db')
                               )
If you would like to access the geometry information stored in the local file in a job in which you already use the CondDB you need to define an es_prefer in detail you have to add also this line:
process.es_prefer_geometry = cms.ESPrefer( "PoolDBESSource", "PoolDBESSourceGeometry" )

There is another alternative that can be used as well. In a standard job, one can do the following:

process.GlobalTag.globaltag = autoCond['mc']
process.source = cms.Source("EmptySource")
process.XMLFromDBSource.label=''
process.maxEvents = cms.untracked.PSet(
     input = cms.untracked.int32(1)
)
 
process.GlobalTag.toGet = cms.VPSet(cms.PSet(record = cms.string('GeometryFileRcd'),
                                             tag = cms.string('XMLFILE_Geometry_Extended_TagXX'),
                                             connect = cms.string("sqlite_file:./myfile.db")
                                             )
                                    )

Or, alternatively to use one you have uploaded to the prep account:

    process.GlobalTag.toGet = cms.VPSet(
        cms.PSet(record = cms.string("GeometryFileRcd"),
                 tag = cms.string("XMLFILE_Geometry_ExtendedX0Min_38YV0"),
                 connect = cms.string("frontier://FrontierPrep/CMS_COND_GEOMETRY")
                 )
        )

Here is a full Example to read from the local sqlite file. Note that in it, you change tag = cms.string('XMLFILE_Geometry_Extended_TagXX'), to tag = cms.string('XMLFILE_Geometry_Extended_YOUR-TAG-HERE'),.

If you are using cmsDriver then you can also use the customization fragments. Customization fragments: Example

import FWCore.ParameterSet.Config as cms
def customise(process):
    process.XMLFromDBSource.label = cms.string('ExtendedLiMax')    
    process.GlobalTag.toGet = cms.VPSet(
        cms.PSet(record = cms.string("GeometryFileRcd"),
                 tag = cms.string("XMLFILE_Geometry_ExtendedLiMax_38YV0"),
                 connect = cms.string("frontier://FrontierPrep/CMS_COND_GEOMETRY")
                 )
        )
    return (process)

Step 6 Get the New Payloads Into the Global Tag and Central Database

The final step in the process is to send and email to the hypernews forum named Alignment/Calibration Discussions (hn-cms-alca@cernNOSPAMPLEASE.ch) Alignment/Calibrations hypernews. The email should request that the new payloads be included in the Global Tag and be moved from the prep database to the central database. This email needs to follow a format which is defined here: CMS.AlCaConstantsOperations. (The email is ignored if the format is not followed, in particular make sure the subject starts with "[GT] ") Submit a request via a web site devoted to collecting these requests: https://cms-conddb-int.cern.ch/gtc/new-request

Here you can see which global tags are recommended for each release: Global Tags By Release. If you want to check the contents of a Global Tag go here: Examine Global Tag. Then enter the Global Tag you are interested in the box at the middle top and click "Submit new GT". Then in the box on the right labeled "Search all columns" type "Geometry". Then you will see all the Geometry payloads in that Global Tag (There are a few other payloads that will show up that are unrelated). Note that at the moment (October 2010) some of the geometry tags in the global tag have a format that is different than what you will see in the metadata files. The metadata files the scripts above generate are correct. The format has changed since these payloads were last modified.

Uploading the New Payloads Into the Production Dropbox

The new payloads should contain a tag for an already stored object, namely FileBlob:

[lxplus437] /tmp/yana/CMSSW_4_2_X_2011-02-12-0200/src/CondTools/Geometry/test $ ls -al Geometry*.db
-rw-r--r-- 1 yana zh  531456 Feb 12 16:36 GeometryFileExtended.db
-rw-r--r-- 1 yana zh  545792 Feb 12 16:36 GeometryFileExtendedGFlash.db
-rw-r--r-- 1 yana zh  549888 Feb 12 16:36 GeometryFileExtendedLiMax.db
-rw-r--r-- 1 yana zh  549888 Feb 12 16:36 GeometryFileExtendedLiMin.db
-rw-r--r-- 1 yana zh  549888 Feb 12 16:36 GeometryFileExtendedX0Max.db
-rw-r--r-- 1 yana zh  549888 Feb 12 16:36 GeometryFileExtendedX0Min.db
-rw-r--r-- 1 yana zh  522240 Feb 12 16:36 GeometryFileIdeal.db

[lxplus437] /tmp/yana/CMSSW_4_2_X_2011-02-12-0200/src/CondTools/Geometry/test $ cmscond_list_iov -c sqlite_file:GeometryFileExtended.db -t XMLFILE_Geometry_42YV1_Extended_mc
Tag XMLFILE_Geometry_42YV1_Extended_mc
TimeType runnumber
PayloadContainerName FileBlob
since 	 till 	 payloadToken
1 	 4294967295 	 [DB=00000000-0000-0000-0000-000000000000][CNT=FileBlob][CLID=BF49C6DD-C2A1-CCE1-6357-1F02A369107E][TECH=00000B01][OID=00000001-00000000]
Total # of payload objects: 1

Refer to the instructions on how to upload them to the production dropbox at https://twiki.cern.ch/twiki/bin/viewauth/CMS/DropBoxOffline. Monitor the status of an upload on: https://cms-conddb-prod.cern.ch/popcon/PopConRecentActivityRecorded.html

Note, that the metadata for each payload should look like:

{
    "destinationDatabase": "oracle://cms_orcoff_prep/CMS_COND_GEOMETRY", 
    "destinationTags": {
        "XMLFILE_Geometry_TagXX_Extended2017_mc": {
            "dependencies": {}, 
            "synchronizeTo": "offline"
        }
    }, 
    "inputTag": "XMLFILE_Geometry_TagXX_Extended2017_mc", 
    "since": null, 
    "userText": "Geometry payload for Full DDD XML Extended 2017 config TagXX"
}

To import the IOVs from already existing tags in DB :

conddb_import -f frontier://FrontierProd/CMS_CONDITIONS -i <tag in DB> -c sqlite:file.db -b <first IOV to be imported> 
    -e <last IOV to be imported> -t <target tag to be stored in file.db>

To list the tags inside a local sqlite file:

conddb --db file.db listTags

To list the IOVs inside a particular tag for local sqlite file:

conddb --db file.db list <tag name>

Simulation Geometry Scenarios in DB

Simulation geometry scenarios stored in a DB with the following tags, where TagXX is described in the Payloads sections.

Record Label Tag Comment
GeometryFileRcd Extended XMLFILE_Geometry_TagXX_Extended_mc Default Extended geometry scenario.
GeometryFileRcd ExtendedGFlash XMLFILE_Geometry_TagXX_ExtendedGFlash_mc Extended geometry scenario with GFlash.
GeometryFileRcd Ideal XMLFILE_Geometry_TagXX_Ideal_mc Ideal geometry scenario. Includes PLT.
GeometryFileRcd ExtendedLiMin XMLFILE_Geometry_TagXX_ExtendedLiMin_mc Extended geometry scenario with tracker material variations.
GeometryFileRcd ExtendedLiMax XMLFILE_Geometry_TagXX_ExtendedLiMax_mc Extended geometry scenario with tracker material variations.
GeometryFileRcd ExtendedX0Min XMLFILE_Geometry_TagXX_ExtendedX0Min_mc Extended geometry scenario with tracker material variations.
GeometryFileRcd ExtendedX0Max XMLFILE_Geometry_TagXX_ExtendedX0Max_mc Extended geometry scenario with tracker material variations.
GeometryFileRcd ExtendedPhaseIBeamPipe XMLFILE_Geometry_TagXX_ExtendedPhaseIBeamPipe_mc Extended geometry scenario with Phase I beampipe.
GeometryFileRcd ExtendedPostLS1 XMLFILE_Geometry_TagXX_ExtendedPostLS1_mc Obsolete.
GeometryFileRcd ExtendedPostLS2 XMLFILE_Geometry_TagXX_ExtendedPostLS2_mc Obsolete.
GeometryFileRcd ExtendedFlat10Percent XMLFILE_Geometry_TagXX_ExtendedFlat10Percent_mc Extended geometry scenario with tracker material variations.
GeometryFileRcd ExtendedFlat20Percent XMLFILE_Geometry_TagXX_ExtendedFlat20Percent_mc Extended geometry scenario with tracker material variations.
GeometryFileRcd ExtendedFlat10Services30Percent XMLFILE_Geometry_TagXX_ExtendedFlat10Services30Percent_mc Extended geometry scenario with tracker material variations.
GeometryFileRcd ExtendedFlat20Services30Percent XMLFILE_Geometry_TagXX_ExtendedFlat20Services30Percent_mc Extended geometry scenario with tracker material variations.
GeometryFileRcd ExtendedServices30Percent XMLFILE_Geometry_TagXX_ExtendedServices30Percent_mc Extended geometry scenario with tracker material variations.
GeometryFileRcd ExtendedHFLibraryNoCastor XMLFILE_Geometry_TagXX_ExtendedHFLibraryNoCastor_mc Extended geometry scenario with HFLibrary and no CASTOR.
GeometryFileRcd ExtendedZeroMaterial XMLFILE_Geometry_TagXX_ExtendedZeroMaterial_mc Extended geometry scenario with no material in tracker.
GeometryFileRcd Extended2015 XMLFILE_Geometry_TagXX_Extended2015_mc 2015 Extended geometry scenario.
GeometryFileRcd Extended2017 XMLFILE_Geometry_TagXX_Extended2017_mc 2017 Extended geometry scenario.
GeometryFileRcd Extended2019 XMLFILE_Geometry_TagXX_Extended2019_mc 2019 Extended geometry scenario.
GeometryFileRcd ExtendedTest2014 XMLFILE_Geometry_TagXX_ExtendedTest2014_mc 2014 Extended geometry scenario with more realistic Tracker material description. More realistic cavern. More realistic PLT. More realistic CSC.
GeometryFileRcd Extended2015CastorSystPlus XMLFILE_Geometry_TagXX_Extended2015CastorSystPlus_mc 2015 Extended geometry scenario with CASTOR position measured by the positioning sensors plus an upward shift within the sys uncertainty
GeometryFileRcd Extended2015CastorSystMinus XMLFILE_Geometry_TagXX_Extended2015CastorSystMinus_mc 2015 Extended geometry scenario with CASTOR position measured by the positioning sensors with downward shift within the sys uncertainty
GeometryFileRcd Extended2015CastorMeasured XMLFILE_Geometry_TagXX_Extended2015CastorMeasured_mc 2015 Extended geometry scenario with CASTOR position measured by the positioning sensors

Reconstruction Geometry in DB

Reconstruction Geometry records are as follows, where TagXX is described in the Payloads sections.

Record Label Tag Comment
IdealGeometryRecord   TKRECO_Geometry_TagXX  
PGeometricDetExtraRcd   TKExtra_Geometry_TagXX  
PEcalBarrelRcd   EBRECO_Geometry_TagXX  
PEcalEndcapRcd   EERECO_Geometry_TagXX  
PEcalPreshowerRcd   EPRECO_Geometry_TagXX  
PHcalRcd   HCALRECO_Geometry_TagXX  
PCaloTowerRcd   CTRECO_Geometry_TagXX  
PZdcRcd   ZDCRECO_Geometry_TagXX  
PCastorRcd   CASTORRECO_Geometry_TagXX  
CSCRecoGeometryRcd   CSCRECO_Geometry_TagXX  
CSCRecoDigiParametersRcd   CSCRECODIGI_Geometry_TagXX  
DTRecoGeometryRcd   DTRECO_Geometry_TagXX  
RPCRecoGeometryRcd   RPCRECO_Geometry_TagXX  
GEMRecoGeometryRcd   GEMRECO_Geometry_TagXX  

Payloads In the Prep Database

Tag Description Release Comments
2015_74YV4 Run 2 Extended 2015 scenario Tracker parameters record. CMSSW_7_4_X_2015-02-09-1400 Plus branch ianna:tracker-parameters-fromDB and Martin-Grunewald:TrackerTopologyEP
74YV4 Run 1 Extended scenario Tracker parameters record. CMSSW_7_4_X_2015-02-09-1400 Plus branch ianna:tracker-parameters-fromDB and Martin-Grunewald:TrackerTopologyEP
61YV2 PostLS1 Extended geometry scenario. Integrated latest multianode description with fibre bundle description and use this in tracker variations for LiMax, LiMin, X0Max, and X0Min Extended geometry scenarios. CMSSW_6_1_X_2012-10-11-0200 PostLS1: RE4, new beamPipe, HF PMT

Payloads In the Production Database

Tag Description Release Comments
110YV1 Extended 2021 geometry scenario CMSSW_11_0_0_pre1 + PR #26788  
106YV3 Extended 2021 geometry scenario CMSSW_10_6_0_patch2 Baseline 2021 geometry scenario
106YV2 CTPPS 2018 geometry scenario CMSSW_10_6_X_2019-04-03-2300 Bug fix in timing detector numbering
106YV1 CTPPS 2017 geometry scenario CMSSW_10_6_X_2019-04-03-2300 Bug fix in timing detector numbering
103YV5 Extended 2019 geometry scenario and 2019 GEM reco geometry CMSSW_10_3_X_2018-09-30-2300 + User defined literals which do not change geometry
103YV2 Extended 2018 geometry scenario with detailed Cavern and mb4shields for neutrons CMSSW_10_3_X_2019-02-05-2300 + PR #25879  
103YV1 Extended 2018 geometry scenario CMSSW_10_3_X_2018-09-02-2300  
102YV1 CTPPS 2018 geometry scenario CMSSW_10_2_X_2018-05-22-2300  
101YV6 CTPPS 2018 geometry scenario CMSSW_10_1_X_2018-03-19-2300 + PR#22547 Change in ideal 2018 geometry due to a rotation of the pixel detector packages in pot 56 210 far hor
101YV4 Extended 2018 geometry scenarios without Totem CMSSW_10_1_X_2018-03-18-0000  
101YV3 CTPPS 2017 geometry scenario CMSSW_10_1_X_2018-02-19-1100 Bug fix
101YV2 CTPPS 2018 geometry scenario CMSSW_10_1_X_2018-02-19-1100  
101YV1 CTPPS 2017 geometry scenario CMSSW_10_1_X_2018-02-04-2300  
10YV4 Extended 2018 with GEM geometry bug fix CMSSW_10_1_0 + PR#22730 https://twiki.cern.ch/twiki/pub/CMSPublic/SWGuideDataBaseGeometry/GEMDPG12APR.pdf GEM geometry unit bug fix: duplicated division by cm
10YV4 Extended 2018 Zero Material in Tracker scenario CMSSW_10_1_X_2018-02-19-1100 Tracker materials taken from 2017 Zero Material scenario
10YV4 Extended 2018 with Hcal collapsed depths and GEM detailed info CMSSW_10_0_X_2018-01-15-2300 https://hypernews.cern.ch/HyperNews/CMS/get/calibrations/3457.html
10YV3 Extended 2018 with Hcal Plan 36 and GEM detailed info CMSSW_10_0_X_2018-01-15-2300  
92YV6 Extended 2018 with GEM slice geometry bug fix CMSSW_9_2_X_2017-06-20-1100  
92YV5 Extended 2017 Plan1 with GEM slice geometry bug fix CMSSW_9_2_X_2017-06-20-1100  
92YV4 Extended 2018 with BPix geometry material tuning CMSSW_9_2_X_2017-05-17-2300 + PR#18824  
92YV3 Extended 2017 Plan 1 with BPix geometry material tuning CMSSW_9_2_X_2017-05-17-2300 + PR#18824  
92YV2 Extended 2018 with BPix geometry fix CMSSW_9_2_X_2017-05-09-2300 + PR#18651  
92YV1 Extended 2017 Plan 1 with BPix geometry fix CMSSW_9_2_X_2017-05-09-2300 + PR#18651  
91YV5 Extended 2023 D11 scenario with final Tracker for TDR CMSSW_9_1_X_2017-04-10-2300 + PR#18253  
91YV4 Extended 2017 Plan 1 with Zero material in Tracker CMSSW_9_1_X_2017-03-20-2300 + https://github.com/cms-sw/cmssw/pull/18008 + https://github.com/cms-sw/cmssw/pull/18024  
91YV3 Extended 2018 scenario with HCal TP bugfix CMSSW_9_1_X_2017-03-15-2300 + matz-e/hcal-tp-2018-fix-geometry  
91YV2 Extended 2018 scenario CMSSW_9_1_X_2017-03-07-1100 plus the following branches: ianna:beampipe-2017-v2, ianna:extended-2017-plan1-scenario-scripts, ianna:xml-file-restructuring, ianna:xml-file-restructuring-v2 synchronises updates included in 91YV1 tags for Extended 2017 Plan 1 scenario: updated beampipe and overlap fix in GE11.
91YV1 Extended 2017 Plan 1 scenario CMSSW_9_1_X_2017-03-07-1100 plus the following branches: ianna:beampipe-2017-v2, ianna:extended-2017-plan1-scenario-scripts, ianna:xml-file-restructuring, ianna:xml-file-restructuring-v2 Al 2219 material in a beam pipe middle section, GE11 overlap bug fix and updated shielding (as actually built), xml file restructuring
90YV12 Reserved for data tags built from 90YV11    
90YV11 Extended 2017 Plan 1 scenario CMSSW_9_0_X_2017-02-22-2300 HCal and CaloTower reco geometry tags == 90YV10
90YV10 Extended 2017 Plan 1 scenario CMSSW_9_0_X_2017-02-20-2300 + PR#17581  
90YV9 Extended 2017 scenario   Overlap fix TOB with TIB rail bottom
90YV8      
90YV7 Extended 2018 scenario sync with 90YV6    
90YV6 Extended 2017 scenario with reactivated big pixels for the Phase 1 pixel topology, tracker overlap bug fixes, replace one section Polycone in Pixel Fwd with Tubs CMSSW_9_0_X_2017-02-02-2300 + PR#17384 + PR#17383 + PR#17387  
90YV5 Extended 2018 scenario with HCal 2017 numbering CMSSW_9_0_X_2017-01-23-2300 + PR#17291  
90YV4 Extended 2017 scenario with tuned reco material CMSSW_9_0_X_2017-01-23-2300 + 90YV3 PRs (see beneath) + PR#17280 + PR#17261 Merged branches: ianna:tib-rail-bottom-overlap-fix, rovere/recoMaterialTuning
90YV3 Extended 2017 scenario with HCal 2017a numbering, GEM slice, overlap fixes and Pixel material update CMSSW_9_0_X_2017-01-23-2300 + PR#17198 + PR#17099 + PR#17192 + PR#17156 + PR#17199 + PR#17130 + PR#17131 + PR#17115 + PR#17245 Merged branches: bsunanda/Run2-hcx97, ianna/fpix-overlap-fix-v2, ianna/gem-in-2017-payload-scripts, ianna/tob-connect56-overlap-fix, kpedro88/Phase1-HE14, schneiml/pixel-matbudget-changes-st See slides here
90YV2 Extended 2017 scenario with HCal 2017a numbering (and no GEM slice) CMSSW_9_0_X_2017-01-17-2300 + PR#17198  
90YV1 Extended 2017 scenario with GEM slice CMSSW_9_0_X + PR#17130  
81YV023 Extended 2023 scenario with TDR baseline GEM, ME0, Tilted tracker CMSSW_8_1_0 + PR#17036 Hcal and RPC updated to 2023, no HGCal yet.
81YV15 Extended 2017 scenario CMSSW_8_1_X_2016-11-16-2300 Fix all remaining overlaps in Pixel support structure. Subtraction with Union solid replacement in ES support structure. Note, there are no changes in sensitive volumes and Pixel support structure material density has been corrected to compensate for the (very minimal) shape changes.
81YV14 Extended 2017 scenario CMSSW_8_1_X_2016-11-01-2300 plus PR#16416 Extended2017new becomes Extended2017 scenario. BeamPipe extrusion fix. More realistic Pixel with updated material. Updated Tracker reco material.
81YV13 Extended 2017new scenario with Hcal geometry changes for 2017 CMSSW_8_1_X 26-Oct-2016 Fixes a problem with CutTubs observed in GeometryFileRcd (81YV11)
81YV11 Extended 2017new scenario with Hcal geometry changes for 2017 CMSSW_8_1_0_pre13 Fixes a problem with mixing vector content in an Hcal reco schema (relevant code changes are already in pre13) and aligns sim geometry and Tracker reco geometry to a current one built from xml
81YV9 Extended 2017dev scenario with Hcal geometry changes for 2017 CMSSW_8_1_X_2016-10-18-1100  
81YV8 Extended 2017dev scenario with Hcal geometry changes for 2017 - DO NOT USE (stored parameters order has changed and does not match stored dense index order) CMSSW_8_1_X_2016-09-19-2300 + PR#15918  
81YV7 Extended 2017 scenario with Hcal geometry changes for 2016a CMSSW_8_1_X_2016-09-19-2300  
81YV6 Extended 2017 scenario with new Tracker reco materials. CMSSW_8_1_X_2016-07-03-2300 + PR#15110  
81YV5 Extended 2017 scenario with Hcal geometry changes for 2016a and with new BPIX module cable materials, new FPIX portcard material and dimensions. Changes to BPIX Phase 1 geometry to match latest design. CMSSW_8_1_X_2016-06-02-1100 + PR#14726  
81YV4 Extended 2017 scenario with Hcal geometry changes for 2016a and with new BPIX module cable materials, new FPIX portcard material and dimensions CMSSW_8_1_X_2016-06-02-1100  
81YV3 Extended 2017 scenario with Hcal geometry changes for 2016a CMSSW_8_1_X_2016-05-31-2300 Requested for upgrade2017 GT
81YV2 Extended 2015 scenario with Tracker material variations CMSSW_8_1_X IB + PR#14010 Tags with labels (FlatMinus05Percent, FlatMinus10Percent, FlatPlus05Percent, FlatPlus10Percent) are included in GT queue 80X_mcRun2_asymptotic_2016_v3_GeomVars
2016_81YV1 Hcal geometry changes for 2016 CMSSW_8_1_X IB + PR#13491 2015 PROD geometry + Hcal parameters change for trigger primitives
2017_80YV2 Hcal geometry changes for 2017 CMSSW_8_0_0_pre6 + PR#13139 See summary at https://indico.cern.ch/event/492087/contribution/4/note/
2016_80YV2 Hcal geometry changes for 2016 CMSSW_8_0_0_pre6 + PR#13139 See summary at https://indico.cern.ch/event/492087/contribution/4/note/
80YV1 Alternative geometry scenarios with shifted castor. CMSSW_8_0_X plus PR # 11928 Based on Extended 2015 and 2015 dev geometry scenarios.
Run1_76YV6 CaloTower reco geometry with dense indexing (reflects changes of Hcal reco geometry) CMSSW_7_6_X_2015-10-02-2300 Plus kpedro88:migrate-CT3
Run1_76YV5 CaloTower reco geometry (reflects changes of Hcal reco geometry) - DO NOT USE CMSSW_7_6_X_2015-10-02-2300 Plus kpedro88:migrate-CT3
Run1_76YV4 Sim geometry scenarios including Hcal parameters, excluding Ecal cables - DO NOT USE XMLFILE_Geometry_Run1_76YV4_Extended_mc, XMLFILE_Geometry_Run1_76YV4_ExtendedZeroMaterial_mc, XMLFILE_Geometry_Run1_76YV4_Ideal_mc    
Run2_76YV4
Run1_76YV3 Hcal Reco geometry (small changes - more precise)   HCALRECO_Geometry_Run1_76YV3 is identical to HCALRECO_Geometry_Run1_76YV4
Run2_76YV3
Run1_76YV2 Sim geometry scenarios including Hcal parameters    
Run2_76YV2
Run1_76YV1 Hcal parameters for run 1 and run 2    
2017_75YV1 Extended 2017 scenario CMSSW_7_5_1 2017 Tracker parameters, sim and reco geometry
Run1_75YV4 HCAL Spec pars CMSSW_7_5_X Adding extra constants and regexps for selection - no changes in geometry.
Run2_75YV4
Run1_75YV2 HCAL parameters record CMSSW_7_5_X Run 1 and Run 2 parameters are identical
Run1_75YV1 Run 1 Tracker parameters record CMSSW_7_5_X_2015-04-05-2300 Plus ianna:use-tracker-parameters-fromDB-75x
Run2_75YV1 Run 2 Tracker parameters record CMSSW_7_5_X_2015-04-05-2300 Plus ianna:use-tracker-parameters-fromDB-75x
Run3_75YV1 Run 3 Tracker parameters record CMSSW_7_5_X_2015-04-05-2300 Plus ianna:use-tracker-parameters-fromDB-75x
Run1_71YV6 Run 1 Extended, Ideal and ExtendedZeroMaterial geometries with new default material budget as in ExtendedTest2014 CMSSW_7_1_X_2015-02-22-0200 ianna:default-material-budget-for-run1  
74YV3 Tracker geometry NOT changed: but introducing DetId Shifts in GeometricDet builder CMSSW_7_4_X_2015-01-18-0200 Transient version is already using them, but it should not affect current geometry.
74YV2 2015 Development scenarios CMSSW_7_4_X_2014-12 IB  
74YV1 Sync Ideal2015 with Extended2015 scenario CMSSW_7_4_X_2014-12-16-0200 IB Extended2015 scenario is identical to 2015_71YV5
2015_72YV6 Extended Run 2 geometry alternative scenarios with shifted castor CMSSW_7_2 plus PR #11928  
2015_72YV5 Extended Run 2 geometry with RPC station 4 rotation fix. Sync tracker material changes to Run1_72YV3 CMSSW_7_2_X IB plus PR #5319 Sep 18 2014 Note: RPC sim and reco geometry changes.
2015_72YV4 Extended Run 2 geometry with more realistic material description. Sync tracker material changes to Run1_72YV3 CMSSW_7_2_X IB Sep 10 2014
Run1_72YV3 Extended Run 1 geometry with more realistic material description. Note: ExtendedTest2014 is not backward-compatible. It requires new plugin for BCM1F sensitive detector. CMSSW_7_2_X IB Sep 4 2014
2015_72YV2 Extended2015 geometry for Run 2 with ZeroMaterial CMSSW_7_2_X IB Aug 29 2014
2015_71YV5 Extended Run 2 geometry with RPC station 4 rotation fix. Sync tracker material changes to Run1_71YV4 CMSSW_7_1_X IB (?) Jul 28 2014 Note: RPC sim and reco geometry changes. (-- SalvatoreDiGuida - 21 Oct 2014)
2015_71YV4_Extended2015 Extended geometry from Run 2 CMSSW_7_1_X IB Fix some Geant4 warnings raised by the 2015_71YV3 tags (-- SalvatoreDiGuida - 21 Oct 2014)
2015_71YV3 More realistic Tracker material, PLT, BCM, CSC, cavern. Pilot blades material. New Castor description. CMSSW_7_1_X IB DetIds unchanged for Castor. Extended label is assigned to Extended2015 scenario.
71YV1 Tracker geometry changed: more realistic material description. More realistic cavern. More realistic PLT. More realistic CSC. CMSSW_7_1_X IB Only one tag so far: ExtendedTest2014
62YV6 Tracker geometry changed: a bug fix in TEC XML description - moving the Ring 7 modules to their correct position. Geometry/TrackerCommonData V01-10-00  
62YV5 Upgrade HCAL geometry with HB depth 7 and HE depth 7.    
62YV4 New PCaloGeometry schema in ProdDB CMS_COND_GEOMETRY_000 account   This introduces storage of a dense index for HCAL upgrade geometry which requires PCaloGeometry schema change in the database, and therefore a new Tag for this Condition.
61YV2 PostLS1 Extended geometry scenario. Integrated latest multianode description with fibre bundle description and use this in tracker variations for LiMax, LiMin, X0Max, and X0Min Extended geometry scenarios. CMSSW_6_1_X_2012-10-11-0200 PostLS1: RE4, new beamPipe, HF PMT
50YV4 Improved memory model for PGeometricDet::Item and TKRECO geometry   PGeometricDet::Item members re-arranged to improve padding.
CondFormats/GeometryObjects V00-09-01  
50YV3 A new beampipe and correct HO geometry   More realistic beampipe.
CMSSW_5_0_0_pre2 and  
V01-04-13 Geometry/HcalCommonData  
V01-09-02 Geometry/TrackerCommonData  
V01-07-09 Geometry/HcalTestBeamData  
V05-04-07 Geometry/TrackerGeometryBuilder  
50YV1 Repaired-z-geometry for the endcap and preshower   The z shifts (more than one) are in a combination of the xml files and associated C++ code DDEcalEndcapAlgo.cc/.h - all in Geometry/EcalCommonData.
44YV2 Improved memory model for CMS calo geometry   Performance improvements.
V05-03-11 Geometry/EcalCommonData  
V00-06-04 Geometry/EcalAlgo  
V05-08-01 RecoEcal/EgammaCoreTools  
V03-13-06 Geometry/CaloGeometry  
V01-05-03 Geometry/ForwardGeometry  
V00-09-00 CondFormats/GeometryObjects  
V00-04-01 CondTools/Geometry  
V01-12-00 DataFormats/HcalDetId  
V03-11-03 Geometry/CaloEventSetup  
V00-09-03 Geometry/EcalTestBeam  
V01-07-04 Geometry/HcalTowerAlgo  
V00-04-00 SimDataFormats/EcalTestBeam  
V01-05-04 Geometry/ForwardGeometry  
42YV1 Backporting improved memory model for CMS calo geometry   Performance improvements.
V00-09-00 CondFormats/GeometryObjects  
V00-04-01 CondTools/Geometry  
V01-12-00 DataFormats/HcalDetId  
V03-11-03 Geometry/CaloEventSetup  
V03-13-06 Geometry/CaloGeometry  
V00-06-04 Geometry/EcalAlgo  
V00-09-03 Geometry/EcalTestBeam  
V01-05-04 Geometry/ForwardGeometry  
V01-07-04 Geometry/HcalTowerAlgo  
V05-07-00-01 RecoEcal/EgammaCoreTools  
V00-04-00 SimDataFormats/EcalTestBeam  
42YV1 TOTEM added IB CMSSW_4_2_X_2011-02-12-0200  
311YV1 TOTEM added CMSSW_3_11_1_patch1 plus the following tags:  
Geometry/CMSCommonData V01-07-08  
SimG4CMS/Calo V02-07-03  
SimG4Core/Application V05-15-19  

Default Geometry in GT

Extended label is associated with a default simulation geometry scenario in any given GT.

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
MichaelCase - 12-Sep-2010 Brought up to date as of 3.9.X IB's

Responsible: IannaOsborne
Last reviewed by: Reviewer

Topic attachments
I Attachment History Action Size Date Who Comment
PDFpdf GEMDPG12APR.pdf r1 manage 265.9 K 2018-04-12 - 00:17 HyunyongKim  
Texttxt OutputOfSomeSqlite3Interactions.txt r3 r2 r1 manage 4.7 K 2010-10-20 - 22:32 DavidDagenhart Example interaction with SQLite
Texttxt OutputOfSuccessfulDBWrite.txt r2 r1 manage 4.8 K 2010-10-20 - 22:23 DavidDagenhart How the output of the job to write all payloads should look.
Texttxt dbtoconf.py.txt r1 manage 6.2 K 2010-11-12 - 00:16 DavidDagenhart Creates global tag conf file
Edit | Attach | Watch | Print version | History: r111 < r110 < r109 < r108 < r107 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r111 - 2019-07-16 - 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