EP R&D Software Working Group Meeting

Europe/Zurich
Zoomiverse

Zoomiverse

Videoconference
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
 

Software R&D Working Meeting Minutes

2021-12-15

Apologies: André

Introduction

No date yet for R&D 2021 report input - we anticipate end of January or into February.

ACTS paper has been accepted in CSBS, which is our first EP R&D supported journal article - congratulations!

Track Reconstruction

For Python examples, is parallelism available? (Or is it not used for multi-threaded jobs?).

  • For parallelism TBB is used

Delegate<> is very lightweight and hides complexity from the compilation unit.

Acts::SourceLink is similar, very light baseclass.

Valentin - reduction of build resources is very welcome; DD4hep and Gaudi use ninja as a backend build tool, that helps reduce the build resources by controlling parallelism.

New fitters in good shape - production ready early next year.

Surface becomes a thin volume, which simlifies navigation a lot. How does this relate to the GPU work?

OpenDataDetector has realistic passive material, which is relly important for realism.

Erica - on the material budget, how did you model things? Is it detailed or an average? And does the solenoid really contribute?

  • The solenoid really is outside, but it is an option and would be important for a calorimeter
  • Short stips end material budget is for services, cables and cooling
  • Serious discussions on having the ODD with a calorimeter and with some muon stations as well
    • Will be indepedent of ACTS plugins, using vanilla DD4hep
    • Gives us reach into the anaysis/CP realm
    • Graeme - we should probably have a dedicated meeting on the ODD next year

John - what does the name ‘portal’ represent? It seems a bit confusing.

  • They are interfaces between volumes, that carry you from one volume into another.
  • The complexity goes down a lot with these portals and it works very well in detray, which is why it has been ported back into the core
    • This is used in the fast simulation; in full sumulation it’s probably too complex to use this setup

Pere - a philisophical question… the simplifications seem to reimplement functionality that exists elsewhere, e.g., the configuration could be handled by Gaudi, and also for the Python bindings

  • Yes, but we could not tie ourselves to Gaudi
  • Tools were deliberately got rid of, which was to remove of virtual function calls that exist in Gaudi

Pere - So is C++ the wrong language for this?

  • There is so much experience in C++ though; the Run 1 ATLAS experience was that too much flexibility cost a great deal in runtime and in complexity
    • There is a line between internal exposure for experts (at compile time) and external exposue, which is a runtime issue
 
There are minutes attached to this event. Show them.