TWiki> LHCb Web>LHCbComputing>RecommendedTags (revision 10)EditAttachPDF

Recommended DataBase tags


This is based on Thomas Ruf's talk at T-rec on 13/7/09.

Why different tags for MC?

For real data, new tags mean better description of existing detector. For MC data, the best description is the one used during the simulation step. Therefore, why different Tags for MC ?
  • Special settings, Velo open, B field off, ... are identified with a Tag and this Tag needs to be used when reconstructing and analysing the data
  • There can be changes in the software which require changes in the databases. Newer software versions might not work anymore with old Tag of database. Requires some intelligence for defining compatible tags.

Why is setting tags required?

Which database tag to use may change, such as when a new mandatory datapoint is added, or when a genuine and post-correctable error is noticed, or if there are updates on ancilliary information, such as (in the future) luminosity information.

So in general it is best to allow the tags to change, which is difficult in the book-keeping, so requires user-input. However, core-software is working on a solution to this issue where the tags are stored in the file itself, and may be overwritten with a centrally maintained map should such updates occur.


DataType, DDDBtag, CondDBtag, Simulation flag. The DaVinci and Brunel configurable has a variable called DataType, which is the main knob for most use cases. The information is forwarded to the LHCbApp configurable. Known DataTypes are:
LHCbApp().DataType = 'MC09' # or 'DC06, '2008', '2009'
If nothing else specified, the LHCbApp will be instrumented to use the default tag:
LHCbApp().DDDBtag = 'default' 
LHCbApp().ConDBtag = 'default' 
The simulation flag is used to switch from LHCbCONDto SIMCOND database for conditions.
LHCbApp().Simulation = 'True' # or 'False'
In some cases, 'DC06', 'MC09', implicitly set by choice of DataType.

Leaving the choice of Tag to the DDDB configurable will solve most use cases. Only needed to specify the DataType corresponding to the data to be used. NOTE: Only one set of tags can be used in one execution. It is not possible to mix data which would require different Tags.

Default tags

The default tag is resolved by DDDB/ Which means, the actual Tag used depends on the version of LHCb. The person changing DDDB/ has to make sure that a new Tag is compatible with the DataType. For example LHCB v27r3:
  • 'DC06': “DC06-20081002“ for DDDB and LHCBCONDNote: SIMCOND does not exist for DC06, Simulation flag set to False, bfield polarity = -1 forced
  • '2008': “head-20090330” for DDDB, “head-20090402” for LHCBCOND and “sim-20090212” for SIMCOND
  • 'MC09': “MC09-20090602” for DDDB and “sim-20090402-vc-md100” for SIMCOND, Simulation flag ignored
  • '2009': “head-20090617” for DDDB, “head-20090508” for LHCBCOND and “sim-20090508-vc-md100” for SIMCOND. Simulation flag for switching between SIMCOND and LHCBCOND

Where do I find information about used tags:

  • Start of job, tells what will be used:
    • # WARNING: Default tag requested for partition DDDB (using DC06-20081002)
    • # WARNING: Default tag requested for partition LHCBCOND (using DC06-20081002)
  • In each event, Rec/Header for example contains information which Tag had been used during reconstruction
>>> evt['Rec/Header']
      • { randomSeeds : [340212, 5501, 540002744, 0] ...
      • condDBTags : [(DDDB, head-20081002), (SIMCOND, head-20081002)]
  • Bookkeeping using dirac tools (SetupProject Dirac, lhcb-proxy-init):
    • dirac-bookkeeping-production-informations 4918
      • Step0:Gauss-v37r2 Option files: $APPCONFIGOPTS/Gauss/;$APPCONFIGOPTS/Conditions/;$DECFILESROOT/options/30000000.opts;$LBPYTHIAROOT/options/Pythia.opts DDDb: MC09-20090602 ConDDb: sim-20090402-vc-md100; ...
      • Step2:Brunel-v34r7 Option files: $APPCONFIGOPTS/Brunel/; $APPCONFIGOPTS/Conditions/ DDDb: MC09-20090602, ConDDb: sim-20090402-vc-md100
  • Bookkeeping GUI (lhcb_bkk)
    • If you know the production ID, check the "Production Lookup" check box, type in the production ID and click OK. This gives a table with the same information as the dirac-bookkeeping-production-informations tool.
    • Otherwise, locate a processing pass, e.g. LHCb - Collision09 - Beam450GeV-VeloOpen-MagDown - RealData+RecoToDST-07+2009-Stripping02
      • Right click on the processing pass name and choose "More Information"
      • Click on the tab corrsponding to the step you are interested in (e.g. 2009-Stripping02 in above example)

Where do I find information about global tags

  • All available tags are listed in the CondDB release notes,
  • Example 1 "DC06-20081002":
    • DDDB: based on "DC06-20080930"
    • LHCBCOND: based on "DC06-20080930" plus:calo-DC06-20081002 …
      • Global tag "DC06-20080930": DDDB: based on "DC06-20080904" plus:calo-20080923, calo-20080905
        • 2008-09-23 - Olivier Deschamps
        • DDDB: calo-20080923 (show files)
        • LHCBCOND: calo-20080923 (show files)
        • SIMCOND: calo-20080923 (show files)
        • Reorganized conditions with some new ones.
  • Example 2 "MC09-20090602":
    • DDDB: based on "MC09-20090526" plus: ot-20090519
      • DDDB: ot-20090519 Fixed wrong material for the Roha component of a coupling.
        • Global tag "MC09-20090526": DDDB: based on "MC09-20090519" plus:velo-20090526, particles-20090526

When should I use the Oracle CondDB?

If you get an error like:
ONLINE_201005       ERROR Database not up-to-date. Latest known update is at 1274248453.0, event time is 1274595459.928
it means that the real data you are analysing was taken after the last release of SQLDDDB. In this case you have to take the ONLINE information from the Oracle DB. You do this by adding to your job the lines:
from Configurables import CondDB
CondDB(UseOracle = True)
This should be the only reason for using the Oracle CondDB. If you are analysing older data, or MonteCarlo, you are much better off keeping the default (UseOracle = False) If you do need to use Oracle, you need a valid grid proxy (which is propagated automatically to your job if you use the Dirac back end of Ganga)

Temporary workaround for "Persistency/LFC" problem (April 2010, DaVinci versions earlier than v25r4)

If you have CondDB(UseOracle = True), and you are using the Dirac back end of Ganga, you should also add the option
It will ensure that your jobs bypass the Persistency/LFC lookup and are therefore much more likely to succeed

If you have CondDB(UseOracle = True), and you are not using the Dirac back end of Ganga, you have a high probability of running into the Persistency/LFC problem and, worse, you are making the problem worse for yourself and for everybody else.

-- ThomasRuf - 14 Jul 2009 -- MarcoCattaneo - 20-Apr-2010

Edit | Attach | Watch | Print version | History: r21 | r12 < r11 < r10 < r9 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r10 - 2010-06-11 - PeterJones
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb 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