Choose timezone
Your profile timezone:
Powered by Indico
v3.3.5-pre
(by B. Hegner)
Explaining challenges for tracking software and motivation for having a common forum and common software.
Proposing a schedule of monthly follow-ups. (*comment from outside*: proposed date conflicts w/ ACAT conference)
Summarizing the software used within the linear collider community. Presenting the usage of AIDA tools like DD4hep, aidaTT and future plans.
Expresses strong wish in bigger share of code. Brings up fast and validated mathematical functions as example for detector-independent code.
Question from Thomas Kuhr (Belle-II): what would be required to use that software within the Belle-II experiment? Its geometry is described in means of TGeo. Answer: A surface model in the geometry is required, DD4hep geometry would be ideal. So manual work required. Implementing a TGeo to DD4hep conversion is something one could consider for the DD4hep project.
Comment from Andi Salzburger (ATLAS):
Runge-Kutta as one example for common software. The ATLAS one even found its way into Geant4. Potential for speedups in there if workload shared.
Question by Wolfgang Liebig (ATLAS): What are the advantages/obstacles of such lightweight software? Answer: it is lightweight because of the small LC community. At the same time it has to support multiple detector concepts. Complex specializations are thus not needed and implemented at this point. Which is both an advantage and a disadvantage. Depending on the use-case.
Giving an en detail overview of GenFit, its internal assumptions and workings. Giving performance figures in the context of Belle-II.
Comment from Gerhard Raven (LHCb)/remote: 20ms per track seems at a different order of magnitude compared to LHC experiments. May show problems of being over-generic in code.
Question by Christian Gumpert (ATLAS): what is your approach for the dE/dx as additional fit parameter? Answer: just adding another dimension to the fit. Straight forward to do as shown by other experiments already doing it.
Question by Wolfgang Liebig: Do you use the DAF fitter for every track or the particularly bad outliers? As it forces 6 iterations on each track it may explain why the tracking is such slow. Answer: yes, in Belle-II it is used per default for every track.
Explaining the track reconstruction in ATLAS and the approaches to have one common set of tracking tools covering very different sub-detectors. The required modularity now allows for adoption of the code by e.g. FCC. Milestone for spring 2016.
Question by Frank Gaende (ILC): what are availability and license? Answer: available to everybody; license still a little bit unclear, but in the process of clarifying.
Comment by Vincenzo Innocente (CMS) on the vectorisation strategy and that external vectorisation is more promising on highly parallel processors like GPGPUs, while the Eigen implementation of the ATLAS Runge-Kutta is an internal vectorisation optimisation. He commented as well that abstraction layers often lead to frequent format transformation, like in places in the CMS extrapolation code.
Explains the overall strategy of LHCb.
no discussion
Proposes approaches to problems of repositories, licenses, and integration in the context of the HSF. License question mainly ignored in the field, e.g. almost none experiment software licensed.
Discussion about proper citation when using other physics software and license situation in experiments.
Question by Andi Salzburger (ATLAS): did you think of a HEP specific license? Answer: Does not make sense given the effort and the fact there are already more than enough around.
Comment by Giulio Eulisse (ALICE): one needs to convince CERN IT to provide proper docker-support.
Follow up on setting up independent builds of some of the packages presented
During the next Connecting The Dots there will be a dedicated session about common SW.