198th ROOT Parallelism, Performance and Programming Model Meeting

Europe/Zurich
32/S-C22 (CERN)

32/S-C22

CERN

17
Show room on map
Stephan Hageboeck (CERN), Vincenzo Eduardo Padulano (CERN)
Zoom Meeting ID
61666320058
Host
Marta Czurylo
Useful links
Join via phone
Zoom URL

PPP 18.06.2026

Usage of ROOT in nuclear physics community

Direction for graphics

  • Collaboration heavily relies on ROOT GUIs. Not only important to show the plots, but especially to interact with them, including fitting.
  • What is the direction for ROOT graphics and GUIs, what about web graphics?

[Serguei]: We are trying to modernise the ROOT graphics by disentagling from TVirtualX interface. In this idea, ROOT graphics will be natively embeddable in other GUI libraries, such as Qt.
[Jeremie]: One very important feature of ROOT GUIs is how easy it is to create components e.g. buttons, how will this be done in the future?
[Serguei]: If you embed ROOT graphics in another GUI, then it's not in scope for ROOT anymore
[Danilo]: When ROOT started with GUIs, there were no other reliable tools for windowing/GUI systems. And this also happened in other areas. In the end, it's not a lot of work for example to transition from a PROOF-based system to a RDF+Dask-based system. Maybe also for GUI the story will be similar.

[Jeremie]: So for the future of ROOT, there will be no new classes for GUI, e.g. web-based classes for GUI?
[Serguei]: Most code is being migrated to Javascript for the web graphics. We build our own components e.g. for the ROOT browser via OpenUI5. Communication is handled via sockets.

[Jeremie]: What I'm worried about is that in my example on the right in slide 12 I cannot really interact with my data, I'm only displaying the plots with JSROOT. This does not look like a futureproof solution to me
[Serguei]: One can embed a web canvas in a GUI. Through the web canvas, one can have server-side functionality to actually operate on the data shown on the canvas (fitting, calling object methods etc.)

[Vincenzo]: Is it possible for your community to go to one product?

[Antoine]: Our community is fragmented. There has been strong adoption of ROOT tools in the community. Usage is simple. Most people don't develop, they just use plotting functions. Most of the community is made of simple users, complex pieces of software for the control are in the hands of very few people

[Antoine]: If we had a nice web based framework with a clear direction from ROOT we could even think about contributing.

[Danilo]: What is the size of your community?
[Antoine]: In France, permanent physicists I would say it's about 100, depending on the institute. Spread over different facilities. French community for low-energy nuclear physics. Sizeable but also with different goals as pointed out. In this respect, you have collaborations like AGATA which are more organised but also atomic research groups in universities.

[Jeremie]: In HEP, I guess there may be the same problems?
[Danilo]: This depends a lot on the collaboration. There may be large institutional solutions but also smaller ones. What we see is either solutions based on ROOT GUIs, or JSROOT in combination with other GUIs.

Direction for data format

  • Large amounts of data stored in TTree in our community
  • What is the direction towards adoption of RNTuple?
  • Will TTree be removed?

[Danilo]: TTree will continue to work. All new developments go to RNTuple

[Stephan]: Main motivation for moving to RNTuple is that it is smaller on disk and it is faster to read.

  • Event building from timestamps: we have custom code to merge two TTrees according to an integer number representing a timestamp for the event. This is not an identifier though, so we don't use the TTree friendship mechanism. Can RDataFrame do this in a clean way or is there another ROOT recommended pattern?

[Danilo]: RDataFrame does not cover this, but if you have custom code that works for TTree, then we can also reach a working state for RNTuple.

Direction for analysis workflows

[Jeremie]: I have just installed a fresh version of ROOT on my machine and I realised that I cannot use PROOF anymore. My analysis is fully based on PROOF, so I can't update ROOT until I change my code.
[Vincenzo]: PROOF has had a transition period and we suggest moving to RDataFrame.

  • RDataFrame has a high-level API, in our community not everyone is such an expert that they can write good code in this new paradigms.

[Jeremie]: A good starting point would be if I were able to convert my analysis code to use RDataFrame

[Jeremie]: If both me and Antoine are switching to RDF, we are not developing for us but for users. I guess at least 200-300 users.

[Josh]: For the triple loop thing, the actual solution is probably using C++ ranges in C++20 and make those work with the histograms.
[Jonas Hahnfeld]: Food for thought: RDF already broadcasts collections when filling histograms but in this triple loop case we want the cross product. There is a chance to have something in the new histograms but we need to decide what we want.

There are minutes attached to this event. Show them.
    • 16:00 16:30
      Questions from the nuclear physics community on ROOT’s long-term technical direction 30m
      Speakers: Antoine LEMASSON (GANIL/CNRS), Jérémie DUDOUET
    • 16:30 16:40
      RDataFrame: Triple nested loops and event mixing 10m
      Speaker: Stephan Hageboeck (CERN)
    • 16:40 17:00
      Discussion / AOB 20m