LHCb Core Software Meeting

Date and Location

10 Sep 2008
10:30 - 12:10
CERN (2-R-030)


Andrei, Eoin, Hubert, Joel, Marco Ca., Marco Cl. (minutes), Stuart


The web site evo.caltech.edu was not accessible, so we couldn't start EVO.



  • Eoin Smith just started as fellow. Will work in the MultiCore project trying to see how it can be exploited within Gaudi.
  • Application Area Meeting in the afternoon. Main topic SVN service.
  • (Marco Ca.) Stefan managed to build the HEAD version of RooFit on top of the version of ROOT that we are using. A few fixes were needed, which will be included in the next version of ROOT.
  • (Joel) Created some new mailing lists for Grid/Production operations focused on specific aspects (e.g. lhcb-bookkeeping).

Software Releases

Gaudi (Marco Cl.)

  • Nothing new since last week.
  • There should be the usual report on Gaudi during the Software Week. There is not much to say (two bug-fix release), except for the planning for the next major changes.
    • present a TO-DO list (problems to be addressed)
    • propose a small workshop to discuss the plan and the timescale.

LHCb, Boole, Brunel (Marco Ca.)

  • Released and deployed yesterday, documentation in progress up to Brunel.
    • mainly bugfixes and protections for real data.
    • new defaults for Brunel: 2008 geometry, real data, MDF input.

Gauss (Joel for Gloria)

  • Latest version of Gauss + DecFile are being released for the production requested by Wouter.

Release and Deployment (Hubert)

  • Stack almost ready. Usual problems with win32 and LaTeX errors in the doxygen documentation.

Marco Ca.: the symbolic links to the doxygen documentation are broken again. They should be changed only when the documentation is ready, not before.

Round Table

Marco Cl.
Configured yesterday the tool that writes the conditions in the PIT to use the production database. No conditions yet, but the structure (directories) have been correctly replicated to Tier-1s.
  • The installation of the software on the Grid needs to be validated, possibly in some standard way, so that we can in any moment check any of the applications.
    After some discussion, we agreed to use the QMTest infrastructure. The tests to be for the validation on the grid will not use input files (just initialization and finalization) and will be triggered by a dedicated test suite (sam.qms).
  • DIRAC needs to parse the standard output of a job to extract some informations. Whenever the format of the print-out changes, some adaptations have to be done to the scripts. It would be easier if the developer of the applications maintain the scripts, because they know when something is changing and how (instead of discovering the changes because the scripts do not work).
    Marco Cl. proposes that the list of informations that DIRAC needs are collected in a dedicated service to better control the output format. Since it is important to have progress informations in case of crash, it is mandatory that the service prints to the standard output the informations when they are collected, and that the parsing of the output is done in any case. Marco Ca. points out that the suggested service is tightly correlated to the File Summary Record and the test can be done also reading the output file (if it has been generated).
  • It would be very helpful if the application returns different status codes according to the type of failure, essentially to be able to easily categorize the failures (IO, software, etc.).
    Andrei suggests that it could also be an indirect check, like a script parsing the output and reporting the kind of error.
    Marco Ca. suggests that we can start by simply having different exit codes according to the state for the state machine: it will be already useful to distinguish between a failure during initialization from one during finalization.
Work on install_project.py
  • untar in temporary directories before copying to the install area
  • command line option to generate a static setup script (usingSetupProject.py internally)
  • To do:
    • check installation and improve removal
    • define a list of exit codes to identify different errors
    • stop modifying install_project.py to be able to start a complete refactoring of it (with a different name at least in the beginning), asking for Python >= 2.3
Marco Ca.
  • Archived many versions of the LHCb projects. Some versions of Gaudi should be archived too. During some random discussion starting from the archival, we agreed that we should use install_project.py to install the software also in AFS, and possibly use the same installed libraries on lxplus and CERN computing elements. This will also allow a single source of tar files, simplifying the archival procedure.
DIRAC needs a tool to prepare the environment for externals only (ROOT) possibly specifying the version.
Marco Cl.: SetupProject does it. The concrete needs should be discussed to define the correct way of using SetupProject.

-- MarcoClemencic - 10 Sep 2008

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r2 - 2008-09-10 - MarcoClemencic
    • 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-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback