Choose timezone
Your profile timezone:
EP R&D Software Working Group Meeting
→
Europe/Zurich
32/1-A24 (CERN)
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
---
tags: eprdet, wp7, minutes
---
Software R&D Working Meeting Minutes
====================================
## 2025-06-18
Room: Andre, Vincenzo, Juan, Witek, Joshua, Leonhard, Peter, Piyush, Florine, Joana, Andi
Remote: Giacomo, Gerri, Aurora, Alberto,
Apologies: Mateusz
## News
## ML FastSim: Piyush
* Is it single step diffusion model? [yes] Why is the time so much faster compared to CaloINN?
* Some numbers are taken from calochallenge paper. GPU and CPU being used are different, but in our case our GPU is even worse than the one used by CaloINN.
* There are a lot more voxels so if you have a fully connected network it's not going to scale as well
* Slide 10, shower shapes seem to be rather fine but total energy is off. Can you combine that with CaloInn?
* That's what we're working on. We are considering that yes.
* We always see 1D plots in these slides, have you looked at the correlation for all the observables?
* I wonder what we can look at.
* You can take points and make a covariance matrix.
* We'll need a lot of data for that. So far we've worked on 1000 showers, we can look at the correlations in the future.
* This is now compared inside your grid or after placing it in the detector? If you change the position of the hits to match the sensitive layers, it will change again.
* In order to properly test it we need to put it in the detector, then the idea is to look at the reconstruction.
* Your grid has a non-uniform binning which makes sense for these showers. But if you place it in CLD the binning will be uniform. What are the requirements you have on your own grid? And is your grid always finer than what is in the detector?
* Yes, even at the circumference it needs to be smaller than the detector. That's why we're investigating the exact granularity needed in case of CLD.
* You have all the future colliders and LHC experiments integrated in a common approach, this is nice to see.
## Fast Sim: Joshua
* In ACTS there is a similar problem, less pronounced because the disk/memory budget is not as big. When we create the material maps to describe the calorimeters, we have more and more granularity and we run into the same issue. For this we've implemented an indexed-view of that, which allows to run some sort of clustering algorithm. Instead of constructing beforehand simmetries in that you need to read, you can make your 130M parametrisations and instead of having an unordered_map of 130M elements, you take this, index them through and run a clustering algorithm and I want to pack the parametrisations, finding simmetries with an a-posteriori algorithm.
* You would only load the parametrisation when needed then.
* It depends. 130M `std::size_t` values can be loaded easily. If that size corresponds into a lookup table into a set of 130K different parametrisations, then you can load it. What you gain is you don't need to define beforehand the simmetries.
* On slide 11 you mention that if it works for ODD it will work for future colliders, how confident are you?
* In principle the only thing needed is take the DD4HEP description, take the parametrisations. What I mean is that in terms of scaling we should be at the same level of future experiments.
* If I can rephrase it, the statement is not saying that parametrisation for ODD will work for any other experiment, that is dependent on the detector, instead it mentions the procedure and the scaling.
* Are you able to already run some of these tests on future detectors like ALLEGRO?
* I think at first we should get it running fully for the ODD, then we can think about other detectors.
* What is the difference in on-disk requirement vs in-memory requirement by using libSpatialIndex?
* Right now we have roughly 50GB of data stored in `.dat` files. When we were using the in-memory map, at some point I couldn't test it anymore because I was hitting the limit on our machine (>>50GB of RAM).
* In the outlook you say you want to eliminate caching, what is the plan?
* For the ODD, if they would be completely symmetrical, then it's easy. You can have one single R-Tree for the lookup (similar for the size we currently have in ATLAS), and scale the position by the corresponding r of the layer. For the ODD this may be roughly true, for the other experiments this will be geometry-dependent.
* Indeed, in FCC someone might come up with another detector and this approach won't be possible anymore.
## AOB
There are minutes attached to this event.
Show them.
