Thank you very much. Hi. My name is Christian. I'm a research software engineer with
the Center for Advanced Research Computing at the University College London. And I'm also a
particle physicist and I was in collision data from the Large Hadron Collider or LHC.
And today I want to talk to you a little bit about how we preserve LHC analysis, once
they're done for the long run, using a tool called rivet. So this talks me to give you
a little bit of an insight into why we need a common tool to analyze Monte Carlo simulations.
How rivet has become that standard tool and some of the challenges that we've encountered
along the way. But before we get into that, let me set the stage a little better.
So the LHC is the world's largest particle accelerator. It's housed in a 27-kilometer
tunnel beneath the Swiss-French border. You can see the sort of indicated in this aerial view
here. If you squint your eyes, you can see the city of Geneva and the background is along
with the Alps. And inside this tunnel, we accelerate protons to nearly the speed of light and
then we smash them together in foreign direction points. And that's where the LHC experiments
are located. We have LHCMS, LHCB and the Atlas experiment, which the one that I'm working on.
The LHC generates enormous amounts of data. Just last year in July, both Atlas and CMS each
surpassed the one exabyte threshold, which maybe unit that we don't use at often. But
ShetchyBT tells me it's the equivalent of about 3,000 years of uninterrupted Netflix streaming.
So I'm not sure it makes it more tangible. But even that is only about 10% of the full data
set that we expect to record over the lifetime of the LHC. It's a huge data set. This data
doesn't just include the experimental results. It also includes simulated data, coming from
the Monte Carlo-Vencher generators. And these are used to model the physics processes that
we expect to observe in nature. Simulated data allows us to compare or experimental measurements
against theoretical predictions. And so they play a crucial role in understanding our data
and interpreting our data. Just to illustrate the scope of what we measure a little
bit better, this plot, and I'm showing you here illustrates the various processes that the
Atlas experiment has observed so far. So in the horizontal axis, you just see the various
processes that we look for listed there. And the vertical axis represents the cross section,
which is a measure for how likely a process is to occur. And I want you to note that this
axis spends an incredible 15 orders of magnitude. So from the most common processes on the left,
to the extremely rare ones on the right. I think this is probably my favorite plot that the
Atlas experiment released and they sort of update this a couple of times here. And even though
I've worked on some of these processes, I still find the range of this mind-blowing. So understanding
and precisely measuring these processes requires a robust framework to compare data and theory
hence the need for tool like Reddit. We compare or experimental measurements to the
theoretical predictions, for example, from the standard model of particle physics, which is sort of
a current best quantum field theory describing the fundamental interactions. And these theoretical
these theoretical simulations are created with complex theoretical tools that are developed by the
theory community. And they include Monte Carlo mentioned writers, but also part of the distribution
functions, which is a thing that sort of describes how the momentum of the approach on the shared
between its constituents. However, these these theory tools continuously improve over time,
which makes it really important that we preserve our past analyses in such a way that we can
go back and reinterpret them with updated theoretical models in the future. Without that, we lose the risk
without that we risk losing the ability to go back and even compare our old data to new physics
models, because at some level the theory is slacking a bit behind here, compared to the sheer
precision from this huge experimental data set. At the same time, producing high quality simulations
is computationally really expensive, and so large-scale validation is crucial in order to ensure
that our tools remain reliable. And when I'm showing you here is a simplified view of a sort of
typical Monte Carlo event generation chain to translate these collisions. We have various
sophisticated specialized tools that focus on different aspects of quantum mechanical interactions
and typically you have more than one option available to reflect different modeling approaches.
And these are then linked to simulate an event collision that could occur at the LFC,
and at the end this is written out in a standard format called HAPMC. You can see that sort of
you have the bottom filtering down to the HAPMC format, and once such an event is generated you can
either analyze it directly with a tool like rivet, or you can first pass it through dedicated
detector simulation software to model how the experimental apparatus would have responded.
And then finally there's a bunch of statistical inference tools available to
further to assess the agreement with the data which then feeds back into the theoretical development.
So analyses and high energy physics face several challenges for once complex analysis workflows
which you've just seen on the previous slide, but also complex vent records. So each of these
simulated events contains hundreds of particles and interaction vertices and different generators
choose to typically choose to combine them slightly differently, which makes standardize analysis
quite difficult. Limited portability, so many experiments specific analysis frameworks
cannot easily be shared outside the collaboration which then restricts raw reviews and risk of knowledge
and because without proper preservation and risk losing, valuable analysis insights
once the original authors leave the field. So what we really need is a tool that allows us to
analyze Monte Carlo events in an standardized experiment in an independent way and that's exactly
a rivet comes in. So rivet stands for robust and independent validation of experiment and theory.
Since its first release in 2007 it's been sort of now widely adopted as a common language to analyze
Monte Carlo analysis, Monte Carlo Generate events, I should say, and last year we released rivet
for the latest major version. rivet is the provides a framework that allows theorists and experimental
physicists to analyze Monte Carlo events in a standard reproducible way. rivet was designed with
three key principles in mind first of all ease of use because it's ultimately physicists and not
software developers who are the primary users. Flexibility is written in C++ with additional
Python bindings and supports essentially all of the main Monte Carlo generators and the specific
analysis routines so come back to those later and can be loaded as plugins as well.
Efficiency and scalability is another one. So we have built in caching systems
which help optimize performance and not makes it then suitable for large data sets.
So the way this works in practice is that rivet takes the generated events from the Monte Carlo
generators and processes them with a bunch of predefined analysis routines and then writes out
histograms effectively in the older format and those can then be used for further statistical analysis
or plotting with a built-in plotting machinery that produces plots that look a bit like this.
Speaking of Yoda, but by that I mean the statistics library that rivet uses internally
for a sister gromming that's another great open source tool that we use in high energy physics.
And if you're interested in Yoda's design and capabilities I encourage you to check out the
Yoda talk tomorrow morning in the HPC track. So why is a rivet routine? As essentially
a C++ class which is compiled into the shared object library and it encapsulates the analysis
logic in software and code for given analysis and these can be plugged in at runtime.
All of these analysis classes inherit from rivets analysis based class and they follow a
standard structure. So they all have a little mini example here, very simplified but still
and they all have sort of initialization phase where you book histograms define standard algorithms.
There's a per event analysis which is used to construct the variables, observables and fill the
histograms and then there's a finalization phase which is used to normalize the histograms
or to construct derived quantities like ratios and efficiencies and such. So this standard
structure ensures consistency across analyses and it helps to hide complexity or technical noise
from the user. You can see an example here at the bottom of a user little pre-process and macro
that hides the technical noisy complex logic that the shared object library needs in order to
register itself to the core library but physicists don't care about that so we'll hide that away from
them so they can concentrate on the physics. So by now the rivet library has grown to about
2000 of these routines covering decades of different measurements from different experiments
I think I'm back to 70 years or so and all of these are open source providing clear documentation
of the analysis logic. Having a rivet routine makes it really easy to reproduce
a measurement and that helps ensuring that they get sighted as well which also enhances the visibility
for the experimental results. So there's a sort of feedback loop between people being able to use
that and then actually sighting our results as well which makes a popular.
So the time rivet has sort of become kind of the de facto standard for comparing
Monte Carlo of engineers with LEC data. It provides a common framework that allows theorists
and experimentalists. It provides a common framework for theorists and experimentalists that sort of
has helped but also continues to help align best practices between them. It's maintained in workshops
and training sessions and community engagement are driving rivets evolution of a time.
Also the LEC experiments have embedded rivet by now into their official analysis preservation
efforts which is great news for the community. rivet is also useful for searching for new physics
and understand a model which is sort of a main theory is not complete so there is a deeper theory
and so theorists that develop extensions to the standard model they might want to compare
their models against the existing data against the LEC data. Now rivet has a large pool of the
data and that makes it easy for them to scan a parameter space in the theory to quickly scan
over that and check which bits of the parameter space have already been ruled out the existing
data. That's kind of illustrated here for some theory model, decas only matter that has sort of
two parameters and a different colors essentially refer to different processes that have been measured
and that we have rivet routines for and you can see how different processes become sensitive
depending on what region of the parameter space you're in. Then you can do a likelihood fit for
example and compare that against experimental data that has been measured and rule out parts of
this parameter space at 95 or 68% confidence level which is what the lines mean and this whole process
can be extended over time as new measurements come in or as the theoretical calculations become more
precise. So the key takeaways from developing rivet balance generality and usability
because the target audience are physicist and also for developers. Interfacing with experiment
and theories important and having a common framework forced its collaboration.
Robust validation is essential to use automated regression tests to ensure that the rivet routines
once submitted remain correct all the time. Standardization matters consistency enables best practices.
Community engagement is vital for sustainability and likewise sustainability requires effort
academic software needs active maintenance and onboarding.
So just to summarize rivet has become over time a standard tool for
Monte Carlo event generator analysis and LHC analysis preservation.
It bridges experiment and theory by providing a shared framework and looking at we want to focus on
automation, usability improvements and also adapting to the next generation of LHC data challenges
coming away. And of course strengthening analysis preservation efforts remains a key priority.
Thanks very much for your attention. I'll take in questions.
That's great.
The root files are a bit only given a file for that matter.
Do I have to do some where or is it just a really just tool of storing it from my side for just
storing and generating randoms for myself to share with everyone. And then after I did that
let's say Gions simulation and we get my detector hits out of that. Do I also store the work
rivet? No, none of this in fact. So the question is how this works in principle. What is the
thing that you actually have to provide? I guess that's a fairly summarize it. The analysis logic
but you actually do in the analysis. What cuts to your apply? How do you select an event?
Do you have the constant flux of events coming in? Some on your analysis you decide this is the
thing that is interesting that I want to measure that you're filtering out your apply selection
cuts filtering whatever. And this is described in a paper and the way that is essentially
not reproducible because you have this small section and if you're trying to code this up
you're almost certainly going to get it wrong. What you need is a C++ snippet. It doesn't have to
be C++ but in this case we we that's what we use and that's what the experiment of frameworks
are written in. And essentially it's just a library of C++ snippets that encode the analysis
logic. How did the analysis actually work? And so in the future with someone comes well you use
this on this calculation back then we've got something that is much better nowadays. How does
that compare to the stuff that you've measured? Then you need to be able to reproduce that analysis
logic and this is what rivet helps you with. It maintains the logic for the future and helps you
analyze this and an automated reproducible way so that you can then go back to your
data that you've actually measured and reinterpreted with much better calculations in the future.
That's the principle.
Is this the format? Yeah it depends a little bit on the experiment. So sorry the question is
are there guidelines or standard practices and how you extract that code logic from your original
analysis framework? It depends on the analysis. So the collaboration sorry so I know that for
instance CMS allows you to or just use the rhythm classes directly in the original analysis and
basically becomes a copypacing exercise at some level. The people in Atlas tend to write it from scratch
because they realize it's an independent framework and we can actually cross-check that we haven't
got any bugs and everything and occasionally they find things and are able to fix it before they
actually reuse the result. So it depends how people want to use it but yeah. That's a question now.
I work at Sarah in the idea in the open source problem office as well. So I have to
question questions one is on the analyzing the old data from the data preservation. So there's
all this like a half data preservation move but there is a little bit of push also on the
cell sites so do you work with them etc. And the second one is to you do you work with the
Reana people with reproducible analysis frameworks etc. And if the answer is no maybe we can
also have it because I know sometimes connecting it is a bit tricky and yeah that's a good
question. So have data the questions you know there are other tools available surrounding that
kind of things such as have data or explain a second what that is for the people who don't know
and whether we engage with these other communities. Have data is a great tool. I don't have any
time unfortunately in my talk to talk about it. It's essentially an online database where the
people once they've made an measurement they use the digitized data I mean this is all just floating
points ultimately what we measure but hundreds of them and so that people don't have to actually
go to the paper and copy the tables we don't do tables anymore we put a plot and we upload
the digitized record to a central repo essentially which is open source and everyone can go
and download all the particle physics measurements from the past I know 70 years or so and do
with them whatever they want because they're open. Fantastic tool and we work with the
update of developers quite frequently we sync or repo against that because we pull the
snapshot for every plus plus snippet that encodes the analysis we pull a snapshot of the numerical
data so that we can then superimpose it on plots like this automatically. So I'm happy with this
product we helped some guides were like open source in some previews like let analysis framework
yeah these are really for the experimental data lot more and I think there's there's a bit of over
luck but more than that. Yeah update there's more about the numerical points that you want to put
in your plot but the actual values of that rivet is more about how did you arrive at that histogram
what do you have to do in a few moments
go interrupt it by drum and you're not here
you just use a git to store the rivets of it yes get up but yeah
and do you happen to know people actually have a rivet or a gsi found that are already also
rivet or is it leaving an atmosphere. No it's all of have we've got all of the left stuff we've got
bass as well rake all of it and we welcome people to contribute more we don't have all of it unfortunately
but we've got a big coverage of staff we'd love to have all of it we don't yet but
we are very keen for experiments to actually contribute their analysis themselves because they know
best what they've done.
Spread the word spread the word
Thank you