LHCb Core Software Meeting

Date and Location

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

Attendees

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

Subjects

News

  • 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 should also take into account the cost (in terms of men 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 men-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 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.

Comments

Please, add here comments and contributions to the discussion.

-- Main.MarcoClemencic - 15-Sep-2011

Round Table

Marco Cl.

Joel

  • 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.

Hubert

  • 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)

Rob

Alex

Gloria

Thomas


-- MarcoClemencic - 15-Sep-2011

Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r3 - 2011-09-15 - 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-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