EP R&D Software Working Group Meeting
Zoomiverse
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