LHCb Core Software Meeting

Date and Location

26. July 2006
10:00 - 11:20
CERN (2-R-030)


Gloria, Hubert, Juan, Marco Ca., Marco Cl. (minutes), Matt, Nicolas, Stefan


Andres, Philippe



  • Application Area Meeting in the afternoon (EuroPython 2006 Highlights).
  • COOL 1.3.3 (bug fixes and minor improvements) will be released this week.
  • Marco Ca. added a page to LHCb computing twiki with links to CERN monitoring pages (LHCbServiceStatusAtCERN).
  • The old lhcb-core-soft mailing list has been disabled (Marco Cl. sent a reminder to all those who didn't subscribe to the new one).

Software Releases

Gaudi (Hubert)

  • Working on the intergration of Atlas modifications to Gaudi (few problems with external dependencies have to be sorted out).
  • Alexander is adapting the PHP script used for the Gaudi web page to LHCb. It will be presented at the Core software meeting when ready.

LHCb, Boole, Brunel (Marco Ca.)

  • The next release is almost ready (the one that will be used for stripping and writes out ETC).
  • The next version with all the new tracking code will be prepared next week.

Gauss (Gloria)

  • Ported to latest Gaudi.
    • Will be tested with 500 events.
  • Changes to MCHit are ready to be included.

DaVinci (Juan)

  • Rec and DaVinci are using the new vertex classes.
  • Since Vanya is away, Loki is temporarily out of DaVinci.
  • Patrick is helping to fix the script to generate the options.
  • Few changes in selections that have to be checked with the authors.
  • Files to test are available, but hidden. Their location will be asked to the production managers.
  • There is a problem with XML file catalog. It should not be needed because data in rDST should be enough, but it does not work.
  • The options for the content of DST should be put in the standar options.


Discussion on the Usage of Conditions in Trigger Algorithms

Marco Cl. mentioned that he restructured XmlConditions to be easier copied to an actual database. He also received from Miriam Gandelman a set of conditions that are being used in the "would be" Muon Alley. Here the discussion started.

There are essentially 3 possibilities to deal with trigger parameters:

  1. We use job options for both structural configuration (sequences etc.) and parameters.
    We store in the CondDB only references to retrive the files from CVS.
  2. We use job options for both structural configuration (sequences etc.) and parameters.
    We store in the CondDB both the reference to the files and a "ready to use" copy of the paramters (for off-line analysis).
  3. We use job options only for structural configuration (sequences etc.).
    The parameters (obtained from the configuration database) will be stored to the CondDB and used by both trigger algorithms and off-line analysis.

From the discussion it seems that having the parameters in the conditions database is good. It is generally accepted that they should not be in two places (this excludes option 2).

The Condition Database is not good for quick tests, so we will need a way of overriding the DB from options (Marco Cl. will add the feature to the Update Manager Service, it is already something he wants to do).

The way conditions will be sent to the event is not well defined. According to Marco Cl., when starting a run, the paramters that need to go to the DB will be sent to it, then a process will take a snapshot of the database and send it to the EFF nodes.

It has been pointed out that there is no document describing the use cases. Without such a document it is hard two guess the best solution.

(Marco Ca. had a chat with Beat about the subject.)
(Marco Cl. had a chat with Philippe, who suggested to implement a declareProperty function that can take the parameter either from the CondDB ot from the option file. Marco Cl. will try it when he comes back.)

Brainstorming Meeting on Alignment in Simulation (Gloria)

Antonis, Chris, Gloria, Juan and Marco Cl. met to discuss how to apply misalignments to simulation.

The outcome is that we should scan the transient store to find the phisical volumes attached to detector elements (reported to a service), then we navigate the phisical volume hierarchy to generate Geant volumes. Whenever we encounter a phisical volume with an associated detector element, we ask the position to the d.e., otherwise we use the one from the phisical volume itself.

Unfortunatley it cannot be done with the current converter schema.

Another new feature will be that by default Gauss will simulate the whole detector. It will be possible to disable subsystems from job options.

Marco Cl. will provide the service to collect the phisical volume/detector element pairs.

-- MarcoClemencic - 28 Jul 2006

Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r5 - 2006-11-17 - unknown
    • 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