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
    32/1-A24 (CERN)

    32/1-A24

    CERN

    40
    Show room on map
    Live Notes
    EP R&D Software Working Group Meeting
    Zoom Meeting ID
    62893115044
    Host
    Graeme A Stewart
    Alternative host
    Andre Sailer
    Useful links
    Join via phone
    Zoom URL
    Hide
     
     

    Software R&D Working Meeting Minutes

    2022-09-19

    Apologies: Andi

    Room: Graeme, Andre, Erica, Paul, Valentin, Witek, Pere, MG, Benedikt

    Remote: Jakob, Anna, Dalila, Marco, Alberto, Gabriele, Javier, Dmitri

    Introduction (Graeme)

    EIC would like to have a f2f meeting with Key4hep around CHEP, taking advantage that many people will be there in person (lots of EIC people at JLab).

    Turnkey Stack (Valentin)

    podio::FRAME can also be used for time slices in a continuous readout system (for EIC).

     

    Q. Pere - Can FRAME’s be used for runs, LBs, IOVs?
    A. FRAMEs can form a heirachy, but don’t pre-define what the interpretation is.

     

    Q. Graeme - Which PODIO backends to we have currently?
    A. SIO and ROOT at the moment. Julia uses these backends ~transparently. JSON is just a dump of data, not a true backend.

     

    Q. Pere - Do we know about the status of the FNAL Spack-Dev work?
    A. Many of the ideas were moved into upstream spack.

    Paul - Custom build steps still seem to be very fragile in Spack; was very painful during a summer student project.

    Bendikt - HSF CMake repo is rather dormant, but would be a good place for updated utilites, macros, etc. The find_package snippets are rather redundant now.

     

    Graeme - Can now build significant pieces of Gaussino, working on the data model transition away from LHCb specific models.

     

    Q. Erica - What did we learn from the conversion to native Key4hep?
    A. Benedikt - Most of the things are ~mechanical, boiler plate updated. We would like to migrate particularly the algorithms that are of interest more widely, which Benedikt will work on. The main advantage is to be able to take advantage of Gaudi Fuctional and make a lot of progress on thread saftey. One also has to manage validation!


    Q. Pere - to convert all algorithms, it would be how much effort?
    A. Benedikt - perhaps 2 months? But of fulltime work!
    A. Valentin - there are a few rabbit holes one can dissapear down, often seeing ways to improve the algorithms.
    Pere - could be a good job for a technical student?

     

    Benedikt - we have rather a lot of trust now in Key4hep, which reflects the good work that people have done in these last few years

     

    Graeme - Documentation, should be careful about who you target, still make things very clear for beginners (especially) and not too overwhelming or confusing.
    Paul - trying to make the ACTS documentation very clear, in terms of what questions each section addresses (that seems to work for the project - it is one site, covering ). Possible to cross-reference between Sphinx instances, which would avoid duplication and information going stale.

     

    Q. Erica - ECFA workshop, raised that testing is very important. Have we had a discussion about this in Key4hep?
    A. Valentine - yes, supportive of this, it does take a lot of work.
    A. Andre - will be tasked to new fellows next year, to build this framework and help with the physics validation.

     
     
    There are minutes attached to this event. Show them.