LHCb Core Software Meeting

Date and Location

10:30 - 12:15
CERN (2-R-030)


Alex Grecu, Ben, Gloria Corti, Hubert Degaudenzi, Joel Closier, Marco Cattaneo, Marco Clemencic (minutes), Markus Frank, Rob Lambert, Thomas Hartmann (EVO)



  • Introducing Ben
    • He will join LHCb with librarian duties and more
  • ITUM meeting next Wednesday
  • AF Meeting tomorrow
    Marco Ca.: we will be asked in the near future if we want to keep or drop Windows.
  • Gloria: there will be and LHC Physics Workshop and we have been asked to provide a contribution (there is also a part on computing)
  • Deadline for CHEP abstracts is the end of the month
    • Philippe set up an indico agenda to collect abstracts for review
    • we should have the abstracts ready by next week
  • LHCb Week approaching

Discussion about Windows support

A long discussion followed the comment about dropping Windows, which I try to summarize here (including some more information than the one exchanged during the meeting).

The main reasons to build our software on Windows were (not in order of relevance):

  • non-GNU compiler (different/more warnings)
  • better development/debug environment
  • possibility of running offline on laptops
  • different operating system (limit the possibility of using non-portable libraries)

The first three points are already addressed without the need of Windows

  • non-GNU compiler: we are using the Intel compiler (even if there are some licensing issues that should be addressed) and Coverity, in the future we may have support for clang/LLVM
  • development/debug environment: nowadays we almost do not use Visual Studio and Eclipse reduces even more its need
  • running on laptops: we can use CERNVM

The last point is still valid. There is a good value in keeping our software portable and we must do it even if dropping Windows. The main problem is that if we do not force the developers to write code that works on Windows, it will be much more difficult (almost impossible) to keep our code portable.

Despite the fact that portable code is better and our code is portable, the adoption of a new platform is heavily limited by the way we build and configure it (we need LCGCMT binaries and configuration). Moreover, some developers do not see the need of the portability to Windows, or they simply do not care. We may also decide that the portability to POSIX platforms is enough.

We should also take into account the cost (in terms of man power) of the support for Windows.

Building the full LHCb stack on Windows is not a problem (the release is usually smooth, except for few cases).

What really costs is the maintenance of the infrastructure, mainly of the nightly builds, which are the basic tool to test the portability of new code. Most of the problems in the Windows nightly builds are due to limitations of the system and not to the code itself.

Another big cost is the maintenance of the Windows builds of the LCG externals (the AA projects are not really a problem). SFT groups is kindly keeping the Windows builds in sync, wherever possible, with the Linux ones, but it's man-power spent only for LHCb, so it's difficult to justify it for a group that is supposed to work on tasks meant to support more than one experiment.

Note: Gaudi is not considered in this discussion, because it will still support Windows (e. g. for other customers than LHCb). The point of the discussion is if LHCb should still ask SFT/AA to build everything on Windows for us.


Please, add here comments and contributions to the discussion.

-- Marco Cattaneo - 16-Sep-2011: I think it is mandatory that we support a sufficiently different operating system from slcXX to maintain portability. Is Mac OS X sufficiently different?

-- Main.MarcoClemencic - 15-Sep-2011

Round Table

Marco Cl.


  • New LHCbDirac release with support for the new type of persistency (picked up from the XML file catalog)
    • being tested
  • Mails about TCK distribution problem
    • Marco Ca.: the TCK configuration parameters should be distributed via Oracle as the other conditions, and the read out configurations (cabling etc.) should be in the ONLINE partition.


  • Finishing the Windows tarballs for LCG 61
  • Working on LbLogin and install_project
    • introduce the package update hook required by the new distribution mechanism of SQLite databases (CondDB)
  • Convinced the developer of one of the generator libraries to use explicit linkage, so that we can avoid the no-as-needed/as-needed local tricks
    • Gloria: we have to check that it doesn't conflict with our overriding of symbols (used to inject our random seed in Pythia, for example)

Marco Ca.

  • The versions of the projects for the release are in a good shape
    • waiting for SQLDDDB (Marco Cl. will apply the patches and make the global tag)


  • Will not join the meetings for the next month.
  • New bug found in the FSR, already fixed.


  • Solved some problems in the usage of RIVET
  • Need to use latest HepPDT in the implementation of an analysis for RIVET, but the version in LCGCMT is too old.
    • To be checked with Atlas if we can upgrade (we may use the special slot used for HepMC for testing)


  • 2011 production being tested


  • Erratic problem on Windows (fatal error LNK1108: cannot write file at 0x######)
    • tried to add monitoring of the memory/disk usage, but nothing special observed
  • XML intermediate format for the nightly build summary almost ready.
  • Progressing step by step in testing the new LCG Nightly system.

-- MarcoClemencic - 15-Sep-2011

Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r6 - 2011-09-16 - MarcoCattaneo
    • 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-2021 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