Go to the Indico Home Page Oldest event Older event Up to category Newer event Newest event Printable version
  • Compact style
  • Indico style
  • Indico style - inline minutes
  • Indico style - numbered
  • Indico style - numbered + minutes
  • Indico Weeks View
    • Switch to the management area of this event
    Login

    EP R&D Software Working Group Meeting

    → Europe/Zurich
    42/3-002 (CERN)

    42/3-002

    CERN

    24
    Show room on map
    Live Notes
    R&D Website (WIP)
    Hide
     

    Software R&D Working Meeting Minutes

    Introduction

    • Good idea to get hosting in the data centre

    • Share machines between tasks

      • New Volta architecture coming soon, so good to get one when available

    • 8 April looks like a good slot for the next meeting - Analysis focus

    • Doodle for the meeting after that - Tracking focus

    Turnkey Software Stack

    • pp and ee machines have very different working points
      • Would algorithms exist for both types of machines?
      • Yes, although one would swap these as needed for particular use cases
    • Is it interesting to look at message passing multi-process frameworks?
      • Gaudi is the framework, but it’s possible to chain steps together
      • Functional approach insulates algorithms/modules from a lot of the details of how the framwork is implemented
        • Offloading to accelerators will be there for sure
    • PODIO should get an RNTuple backend
    • Transient representation is hard as it needs to be optimised per device
      • Define the data relations at high layer
      • Generate optimised code at compile time
      • Decoouple concerns so that interface and backend are independent
        • Even try to use 3rd party algorithms to manage format conversions (e.g. llama)
    • CMS/Patatrack spending a lot of time converting data from SoA to AoS for legacy algorithms
      • Should be copyable with few oprations between devices (copy chunks)
    • EDM4hep - arrows are relationships, not pointers
    • Are indexes in the same objects or separate?
      • Some are completely separate
      • Some are built in
      • Optimisation is tricky and there are trade offs in terms of convenience (1-1 is easy, 1-many is harder)
    • How complete is DD4hep, for building geometries from scratch? e.g. some whacky toroidal detector
      • XML is used (quite awkward to use froom scratch though)
      • Would TkLayout be interesting?
        • Valentin has discussed with the TkLayout developers, although work here is on hold at the moment
        • At least to bootstrap the first XML version
      • DD4hep is very good at plug and play once sub-detectors are defined
        • So envisage a library of detector models

    Roundtable and Discussion

    • What should the granularity be for libraries and packages?
      • Hard to say in general, but large packages scale better than many small ones
      • Also nice that packages have flexible component based builds
     
    There are minutes attached to this event. Show them.