Directory layout of the conditions service in CMSSW

 1. CondCore subsystem contains conditions service which is a client of the EventSetup system of the framework. It includes in following packages:
   --DBCommon  //code common to service implementations
   --ESSources //pool db ESSource implementation of the conditions service
   --IOVService //IOV service code
   --MetaDataService //MetaData service code
   --PluginsSystem //code that handles the dynamic loading of the plugins 
   --XXXPlugins //instantiates the XXX detector related plugins needed to 
deliver the XXX related objects/Records. (where XXX stands for detector 
 2. CondFormats hold persistent conditions data object definitions and 
their associated event setup data record definitions. It includes the 
following packages
  --DataRecord //holds ALL definitions of the Records used by the 
  --XXXObjects  //holds ALL XXX related persistent object definitions, 
their dictionary files and EventSetup data registration macros

3. CondTools hold tools for online-to-offline procedure
  --Utilities //commandline applications needed in the o2o procedure
  --XXX //holds XXX detector related o2o procedure code

The guideline for creating new packages under the cond system is the 
following: the package granularity of CondCore/XXXPlugins and 
CondFormats/XXXObjects should match; the plugins, conditions objects, and 
Data Records are placed in different librarie; the Record classes(in 
CondFormats/DataRecord) are decoupled from the Plugins(in 
CondCore/XXXPlugins) and the directory CondFormats/DataRecord is shared by 
all the detectors. 

The guideline for the granularity of the data record is: each detector has 
its own sets of records; one record per IOV set.

How to add new data object

1. Define the new persistent object in CondFormats/XXXObjects package
  --add its definition in interface; implementation in src
  --add it in the dictionary selection file src/classes_def.xml, and 
include file src/classes.h
  --register the data object to the event setup system in 

2. Use the datarecord code generator "mkrecord" to generate the new record 
entry: related documentation
The right place to hold the new data record is CondFormats/DataRecord

3. Tell the plugin system the new object is associated with which data 
  --in CondCore/XXXPlugins/src/, add the object-record pair in 
the registration macro

How to run the conditions system with Ecal as example

1. cd CondCore/ESSources/test
2. eval `scramv1 runtime -csh`
3. check the following data proxy plugins exist before running the example 
using SealPluginDump|grep Proxy 
4. pure offline writing example: testWriteCalib
    --write out EcalPedestals objects into "EcalPedestals" container; 
      assign IOV to them; 
      write out the pedestal iov object into the "IOV" container
    --register the pedestal iov object token to the metadata service with 
the tag name "EcalPedestals_2008_test"
    --write out the EcalMapping object into "EcalMapping" container; 
      assign infinite IOV to it; 
      write out the mapping iov object into the "IOV" container(note the
       same container name here!)
    --register the mapping iov object token to the metadata service with 
     the tag name "EcalMapping_v1"
    --this one single program can be split into two where one writes 
     pedestals and mappings separately.

5. data reading through EventSetup: 
   cmsRun --parameter-set load_test.cfg     
   //load both EcalPedestals and EcalMapping data
   cmsRun --parameter-set load_mapping.cfg  
   //load only EcalMapping data
   cmsRun --parameter-set load_ped.cfg      
   //load only EcalPedestals data
   --you should see data changes when iov expires.
   --note in the .cfg, the usage the tag name as the entry point to the 

6. the responsibility of the ESSource tests stop at the previous step: 
i.e. to check *if* conditions module delivers new data when iov expires. 
To get/print the real data values from ESHandle should be done in the 
subsequent algorithm EsProducer modules.If you want to check the correctness 
of the data already in this package, there's a quick mock analysis module 
stubs/EcalPedestalsAnalyzer can be used:
  cmsRun --parameter-set print_ped.cfg
  --you should see the printout "mean 0.5,variance0.94" for run<=6 and it 
changes to "mean 0.56,variance0.98 for run>6.

Current known limitations and problems

   --strange problems with plugin manager sometimes: if null pointer error 
or assert error happens, just ignore and try to run a second time.
   --only support runnumber based IOV implementation
   --bool loadAll=false is not supported by EventSetup, Chris is working 
on it.
   --for data reading, if the db is oracle, need to 
        setenv POOL_AUTH_USER yourdb
        setenv POOL_AUTH_PASSWORD yourdbpwd

Last steps of the o2o procedure: an example

1. set environment to work with CMSSW

2. clean your db 
   sqlplus yourdbaccount@devdb10/yourdbpass < clear.sql

3. use buildmapping "dry run" mode to create a mapping file template for 
the desired class
   pool_build_object_relational_mapping -f mapping-template.xml -o 
EcalPedestals-default.xml -b -d CondFormatsEcalObjects -c oracle://devdb10 -u 
yourdb -p yourdbpass -b

4. create your own mapping file
   cp EcalPedestals-default.xml EcalPedestals-custom.xml
   modify EcalPedestals-custom.xml
   --change to different Mapping version(!)
   --change column names and table names as you wish

5. create offline db schema and some mock data population
sqlplus yourdb@devdb10/yourpass < offline-ecalpedestals-oracle.sql
6. build the real mapping
  pool_build_object_relational_mapping -f EcalPedestals-custom.xml -d 
 CondFormatsEcalObjects -c oracle://devdb10 -u yourdb -p yourpass
   --inspect the database to see some POOL tables appeared
   --look at dbsetup.xml

7. build the pool container with data
   pool_setup_database -f dbsetup.xml -d CondFormatsEcalObjects 
   -c oracle://devdb10 -u yourdb -p yourpass

8.  register the db host to the POOL catalog. Necessary *only* if the 
connection string hasn't  been already registered to the catalog. 

    FCregisterPFN -p oracle://devdb10 -t POOL_RDBMS
9. In the offline db, build initial iov of the EcalPedestals data from the 
TIME value in the top level EcalPedestals object table. The command returns the 
result token of the IOV has been built. -s option takes the class id of of 
the EcalPedestals object in the dictionary: i.e. from EcalObjects/src/classes_def.xml

setenv POOL_AUTH_USER yourdb //*only* if use oracle
setenv POOL_AUTH_PASSWORD yourpass  //*only* if use oracle
cmscond_build_iov -h                      //to see the help message

cmscond_build_iov -c oracle://devdb10 -t ECALPEDESTALS -n EcalPedestals -s 

10. assign a tag to the iov token built by the previous command and 
register it to the metadata service
cmscond_build_metadata -h                      //to see the help message

cmscond_build_metadata -c oracle://devdb10 -i "<the output from the 
previous command>" -t "ecalped_fromonline"

11.  get transfered data in offline db from eventsetup. Inspect the 
content of load_onlineped.txt, see data changes when iov expires.

cmsRun --parameter-set load_onlineped.txt
-- Main.lueking - 06 Oct 2005
Edit | Attach | Watch | Print version | History: r22 | r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r1 - 2005-10-07 - unknown

    • 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