EP R&D Software Working Group Meeting

Wednesday 18 Sept 2024, 10:00 → 11:00 Europe/Zurich

32/1-A24 (CERN)

Live Notes

---
tags: eprdet, wp7, minutes
---

Software R&D Working Meeting Minutes
====================================

## 2024-09-18

Room: Andre, Witek, Andrei, Juan C, Swathi, Mateusz, Florine, Severin, Juan, Piyush, Pere, Peter, Aurora

Remote: Joana, Benedikt, Andi, Alberto, 

Apologies: Felice, Graeme

## News - Andre

* Hardware: tracking: made progress on deciding what to buy

## GPU Simulation - Juan + Severin

* Q: Concerning the geometry: did you try to model the geometry as a triangulated mesh? That basically reduces the geometry to just triangle-intersections.
    * A: Can tessellate solids, but required precision explodes the number of triangles
    * Q: Precision in material not better than 2 %, maybe less precision possible?
    * A: When tessellating need to make sure to respect hierarchy levels

* Q: concerning the RungeKutta-propagator. In detray/traccc we have a full implementation (including error transport), so this could be an area of an abstracted runge-kutta-utility that could be shared between EP R&D projects 

    * A: Would be interesting to not re-invent the wheel in this regard. How is this implemented?
        * Header only library, probably no other dependency (vecmem maybe?)
    
* Q: Why the choice for the different surfaces in the surface model?
    * A: First and second order surfaces, some more (Torus, Sphere, ...) surfaces

* Q: CPU Threads vs number of GPUs
    * A: CPU threads used to schedule GPU kernels, and are waiting otherwise. Need to go to async scheduling to not block CPU
* Q: What is "Warp Divergence"
    * A: A 'warp' is a block of 32 threads on the GPU. Has to execute the same instructions and otherwise waits when other "ifs" are executed in some threads

* Q: Are you building Geometry on the host or on the device?
    * A: Single thread on host builds the Geometry, not a bottle neck at the moment.
    * Q: How are things copied to the device?
    * A: About to change how this is done. Before stored as SoA: Array for frame, surface, etc. but this does random memory access to grab small things. Now moving back to AoS to have random memory access to read more bytes in one go.
    * Q: Sort surfaces by bounded volume hierarchy or access pattern?
    * A: too many access patterns, too big for cache lines

 

1 Introduction

Speakers: Andre Sailer (CERN), Graeme A Stewart (CERN)

WP7 Working Meeting Intro 2024-09-18.pdf

2 Simulation GPU Tracking

Speakers: Juan Gonzalez Caminero, Severin Diederichs (CERN)

AdePT SFT R&D Meeting.pdf

3 Roundtable and Discussion